πΌοΈ POCKET-Image β the POCKET series goes visual: character-perfect text in any language, on-device
A new model in VIDRAFT's POCKET family. POCKET put 35B-class models on phones and no-GPU PCs. POCKET-Image carries the same "big capability, small hardware" idea into image generation β and fixes the one thing nearly every image model gets wrong: text.
What it is: β’ 100% accurate text, any language β where global models produce gibberish β’ Any background from a prompt β text is optional (empty β a pure image) β’ No GPU, no NPU β runs on plain CPU + RAM via the POCKET-Core engine β’ Measured footprint: 8.6 GB (RTX 3050/4060) Β· 4.5 GB (offloaded, 6 GB cards) Β· 13.4 GB (MacBook, 16 GB+) β’ Windows Β· macOS Β· Linux Β· fully local, no cloud
Built on the open, commercial-friendly Z-Image (Apache-2.0) foundation.
Honest note: the text is the guaranteed-correct part β the surrounding scene is ordinary generation, so a busy foreground can crowd the letters. We say so; clean backgrounds stay razor-sharp.
POCKET now speaks Gemma 4 β a 26B model that loads in every app, and runs on your PC with no GPU
We're adding a Gemma-4 sibling to POCKET: POCKET-26B, built from Google's Gemma-4-26B-A4B (Apache-2.0). Our flagship POCKET-35B is a Qwen-family MoE and needs a recent llama.cpp; POCKET-26B trades a little size for the thing people kept asking for β it just loads, everywhere, today: Ollama, LM Studio, PocketPal, MLX, any stock llama.cpp. No fork, no bleeding-edge runtime, no CUDA, no cloud.
It's a sparse Mixture-of-Experts (25.2B total, ~4B active per token), so the work per token stays small β a real 26B that generates on a CPU with no graphics card.
Two things make it stand out:
1) Universal compatibility. Gemma 4 is a standard, widely-supported architecture, so POCKET-26B runs on the tools you already have β no waiting for your app to add a new model type.
2) Quality that survives compression. Measured GPQA-Diamond (198 q, greedy): β’ Full base: 67.7% β’ POCKET-26B Q4_K_M (17 GB): 67.7% β lossless β’ POCKET-26B Q2_K (11 GB): 67.2% β near-lossless, at 11 GB
Live, on a CPU-only box (our demo Space β POCKET-26B vs Bonsai-27B, same machine, same stock llama.cpp): POCKET-26B β 19 tok/s vs Bonsai β 6 tok/s β about 3Γ faster generation, no GPU. (Honest notes: shared CPU box, sequential race; a dedicated machine is faster.)
Where it fits in the family: β’ POCKET-35B (Qwen MoE) β bigger, top-tier, needs a recent llama.cpp. β’ POCKET-26B (Gemma 4) β loads in any app, quality-robust when compressed. The demo runs the Q4_K_M build; Q2_K (11 GB) is the smallest footprint. For a true β€8 GB phone, the 5 GB POCKET-KR (Qwen) is still the pick.
π± POCKET β a 35-billion-parameter model that runs on your iPhone, and on your PC with no GPU
We're releasing POCKET, VIDRAFT's flagship Darwin-36B-Opus compressed for on-device use. No fork, no CUDA, no cloud β it runs on stock llama.cpp. It's a sparse Mixture-of-Experts model (256 experts, only 8 active per token), so the file can be large while the work per token stays small. That's what lets a 35B model run on a phone, and generate fast on a CPU with no graphics card.
Measured (POCKET-35B IQ1_M vs Bonsai-27B Q1_0): β’ CPU generate (Xeon, 16 threads): 27.0 vs 10.1 tok/s β 2.69Γ faster β’ GPU generate (H100): 197 vs 89 tok/s β 2.22Γ faster β’ GPU prompt processing (H100): 753 vs 1816 β 0.41Γ (Bonsai wins this one β MoE prefill wakes every expert, so sparsity stops helping there. We say so.) β’ Quality (HellaSwag, 400 q): 61.0% vs 60.0% β a tie (confidence intervals overlap)
On a real consumer laptop β MacBook M3 Pro (18 GB) β POCKET wins every axis, prompt processing included: β’ Metal generate: 25.4 vs 12.8 β 1.99Γ β’ CPU generate: 13.8 vs 4.4 β 3.13Γ β’ Metal prompt: 240.7 vs 73.4 β 3.28Γ
One more quiet fact: the same-size, quality-oriented rival Ternary-Bonsai-27B (7.2 GB) fails to load in upstream llama.cpp at all β it needs the PrismML fork. POCKET runs on the tools you already have: LM Studio, Ollama, PocketPal, MLX.