POCKET-35B

VIDRAFT quantizes its Darwin-36B-Opus MoE model into a 35B GGUF that runs on stock llama.cpp with no GPU, trading GPQA Diamond score for CPU and phone portability.

POCKET-35B

POCKET-35B is a GGUF release from the Seoul startup VIDRAFT, built to answer a narrow question: how much of a 35-billion-parameter reasoning model survives once you strip out the GPU requirement completely. It's a quantized descendant of VIDRAFT's own Darwin-36B-Opus, a model bred (not trained) from Qwen 3.6-35B-A3B using the company's evolutionary merging engine, Darwin V7.

TL;DR

  • 35B sparse MoE (256 experts, 8 active) quantized down to four GGUF sizes from 21.2GB to 8.24GB, runs on stock llama.cpp with no GPU and no fork
  • 262,144-token context confirmed in the GGUF metadata itself, but GPQA Diamond drops to 68.7% (Q4_K_M) or 60.1% (Q2_K) versus 73.2% for the unquantized Qwen 3.6-35B-A3B base
  • Beats the comparable Bonsai-27B build on CPU and laptop generation speed by roughly 2x to 4x, but loses on GPU prompt processing because MoE prefill has to wake every expert

Overview

VIDRAFT is a 12-person startup operating out of Seoul AI Hub, a Seoul Metropolitan Government facility, founded in 2024 by CEO Min-sik Kim, who was a fourth-year computer engineering student at Korea Cyber University before taking leave to run the company. It has no large funding round to point to. What it has instead is a NIPA GPU allocation rated "Excellent" for 2026, KOITA recognition as a corporate research institute, and access to 24 GPUs (16 Blackwell B200s and 8 H200s), which is a modest fleet by frontier-lab standards but enough to run its core product: Darwin, a gradient-free model-merging engine that recombines the weights of existing checkpoints instead of training new ones.

Darwin-36B-Opus, the model POCKET-35B is quantized from, is the highest-scoring member of that family. VIDRAFT bred it from two parents that share a common base: Qwen/Qwen3.6-35B-A3B supplied the MoE architecture and expert topology, while hesamation/Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled, a LoRA fine-tune trained on 14,233 chain-of-thought traces distilled from Claude Opus 4.6, supplied the reasoning behavior. Darwin V7 merges the two through what VIDRAFT calls per-tensor compatibility analysis rather than any further gradient descent, and the whole process reportedly finishes in under 10 minutes on a single B200 GPU.

POCKET-35B strips that merged model down for hardware that has none of that. It ships as four GGUF quantizations, from a 21.2GB top-quality build to an 8.24GB build small enough for a 16GB RAM box, all built to load in unmodified llama.cpp rather than a custom fork.

A macro photograph of an Intel Xeon E3-1225V2 processor, showing the printed model and speed markings POCKET-35B's headline CPU numbers come from a 16-thread Xeon server, the kind of hardware VIDRAFT is targeting instead of a GPU. Source: commons.wikimedia.org

Key Specifications

SpecificationDetails
ProviderVIDRAFT (FINAL-Bench / VIDRAFT_LAB)
Model FamilyPOCKET (quantized from Darwin-36B-Opus)
Parameters34.7B total / ~3B active per token
ArchitectureSparse MoE, 256 routed experts + 1 shared, top-8 routing
Context Window262,144 tokens (confirmed in GGUF metadata)
Quantization FormatsQ4_K_M (21.2GB), Q3_K_M (16.8GB), Q2_K (12.9GB), IQ1_M (8.24GB)
Input PriceFree (Apache 2.0, self-hosted only)
Output PriceFree (Apache 2.0, self-hosted only)
Release DateJuly 22, 2026
LicenseApache 2.0
RuntimeStock llama.cpp, Ollama, LM Studio, PocketPal, Apple MLX

The parameter count is worth a note. VIDRAFT markets this as a "35B" model, and the GGUF file metadata reports 34,660,610,688 total parameters, close enough to round to 35B and consistent with the Darwin-36B-Opus parent's own spec sheet. The architecture field in that same metadata is labeled qwen35moe, a naming holdover from the underlying model class rather than a claim about which Qwen generation it descends from. Darwin-36B-Opus's own model card is explicit that the base parent is Qwen 3.6-35B-A3B, not 3.5, even though POCKET's own README describes the lineage as "Qwen3.5-family MoE" in one place. That's a real inconsistency between VIDRAFT's own documents, and it's the kind of detail worth checking yourself before citing a model's lineage secondhand.

Benchmark Performance

VIDRAFT benchmarks POCKET-35B's IQ1_M build against Bonsai-27B Q1_0, the 1-bit build of PrismML's Bonsai 27B, on the same hardware with the same stock llama.cpp binary. The comparison is self-reported by VIDRAFT, not independently reproduced, but the methodology (same tools, same machine, disclosed losses) is more transparent than most vendor benchmarks.

MetricPOCKET-35B IQ1_MBonsai-27B Q1_0Result
CPU generation, Xeon 16-thread27.0 tok/s10.1 tok/sPOCKET 2.69x faster
GPU generation, H100197 tok/s89 tok/sPOCKET 2.22x faster
GPU prompt processing, H100753 tok/s1,816 tok/sPOCKET 0.41x (slower)
HellaSwag quality (400q)61.0%60.0%Statistical tie
MacBook M3 Pro Metal generation25.4 tok/s12.8 tok/sPOCKET 1.99x faster
MacBook M3 Pro CPU generation13.8 tok/s4.4 tok/sPOCKET 3.13x faster

"MoE prefill wakes every expert, so sparsity stops helping there," VIDRAFT writes in its own README, describing why POCKET loses the GPU prompt-processing test.

That line matters more than the wins do. Sparse MoE only pays off during generation, where the router activates a handful of the 256 experts per token. Prompt processing has to touch a much wider slice of the expert pool across a long input, so the "3B active parameters" pitch collapses on an H100 doing prefill, and Bonsai's dense-leaning 27B design comes out over twice as fast there. On a laptop, that gap disappears. VIDRAFT's own numbers show POCKET winning every axis on a MacBook M3 Pro, including prompt processing (240.7 versus 73.4 tok/s over Metal), because there's no longer enough raw GPU throughput for a dense model to out-brute-force a sparse one.

Reasoning quality tells a separate story. Quantizing the model costs real accuracy on GPQA Diamond's 198 questions under greedy decoding: the unquantized Qwen 3.6-35B-A3B base scores 73.2%, POCKET-35B's Q4_K_M build drops to 68.7%, and Q2_K falls further to 60.1%. VIDRAFT hasn't published a GPQA figure for the smallest IQ1_M build. That 73.2% baseline is also worth cross-checking against our scientific reasoning leaderboard: Alibaba's own materials for Qwen 3.6-35B-A3B report 86.0% GPQA elsewhere, a 13-point gap from VIDRAFT's greedy run on the same base model that has nothing to do with quantization and everything to do with eval harness and prompting differences. Treat any single GPQA number, from any vendor, as harness-dependent until proven otherwise.

Key Capabilities

Where the parent model's score actually comes from

Darwin-36B-Opus's headline 88.4% GPQA Diamond score, the number that put VIDRAFT on Hugging Face's community leaderboard with 397B-parameter dense models, isn't a single-pass result. VIDRAFT's own evaluation methodology scores it in two phases: a greedy first pass across all 198 questions lands at 73.2% (145 correct), and a second pass re-runs every miss with 8-way majority voting plus a 16-vote tiebreaker round for close calls, lifting the final score to 88.4% (175 correct). That's a 15.2 percentage point gain from stochastic retry alone. POCKET-35B doesn't inherit that benefit, since nobody runs an 8-way majority vote on a phone; its GPQA numbers above are single-pass greedy, which is the fairer comparison for how the model actually gets used on-device.

Positioned against a real leaderboard, not just Bonsai

VIDRAFT's own README places Darwin-36B-Opus tied for third on an April 23, 2026 snapshot of Hugging Face's GPQA Diamond leaderboard, level with the 397B-parameter Qwen3.5-397B-A17B and behind two entries from TNSA. A BigGo Finance report published five days later, on April 28, put the same model in fifth place. Leaderboard rank shifts fast as new entries land, so treat any specific ordinal as a snapshot rather than a fixed fact. The score itself (88.4%, Pass 2) has held up across VIDRAFT's own model card, its Hugging Face metadata, and third-party coverage.

The underlying research is documented in arXiv:2605.14386, "Darwin Family: MRI-Trust-Weighted Evolutionary Merging for Training-Free Scaling of Language-Model Reasoning," published May 14, 2026 by a seven-person VIDRAFT-affiliated author group as a NeurIPS 2026 submission. Its headline claim is actually about a different sibling: Darwin-27B-Opus at 86.9% GPQA Diamond, ranked 6th among 1,252 assessed models. Darwin-36B-Opus, the model POCKET-35B descends from, is the newer and higher-scoring release that came after the paper's own reported results.

Every device tier gets a different repo, not just a different quant

A close-up photo of a hand holding a black iPhone, showing its camera module and rear Apple logo POCKET's phone-capable builds live in sibling repos, not in POCKET-35B-GGUF itself - the iPhone MLX build is a separate, smaller download. Source: unsplash.com

It's worth being precise about what "POCKET" actually ships, because the collection is bigger than the one repo this article covers. POCKET-35B-GGUF, the subject here, targets PC and server CPUs with no GPU. A sibling repo, POCKET-KR-MLX, ships a 2-bit Apple MLX build sized for iPhone and Mac and tuned for Korean. POCKET-EN-GGUF covers English on both PC and phone with a 5.3GB "iPhone-mix" build meant to run through the PocketPal app. There's also POCKET-26B, a Gemma4-based sibling scoring 67% on GPQA Diamond that trades some quality for broader app compatibility today. VIDRAFT's iPhone and Android throughput claims apply to those sibling builds, not to POCKET-35B-GGUF's own four files, which VIDRAFT itself lists as not yet benchmarked on phone hardware.

Pricing and Availability

A macro product photo of a green laptop RAM module with visible memory chips and gold connector pins Every POCKET-35B tier is sized against system RAM, not VRAM - the whole pitch is that no GPU line item is needed at all. Source: unsplash.com

POCKET-35B-GGUF is free, hosted on Hugging Face under FINAL-Bench, released under Apache 2.0 with no usage restrictions and no API tier. There's nothing to subscribe to. The only cost is hardware, and VIDRAFT is explicit about matching each quantization to a RAM budget rather than a GPU tier:

  • Q4_K_M (21.2GB) - top quality, needs roughly 32GB RAM
  • Q3_K_M (16.8GB) - a 24GB RAM machine
  • Q2_K (12.9GB, VIDRAFT's recommended "daily driver") - 16 to 24GB RAM
  • IQ1_M (8.24GB) - the smallest full build, fits a 16GB RAM box

Quickstart is a single llama-cli invocation with -ngl 0 to force CPU-only execution, no custom build flags:

llama-cli -m POCKET-35B-Q2_K.gguf -p "your prompt" -ngl 0 -t 8

VIDRAFT recommends capping -t at physical core count rather than logical thread count, since oversubscribing threads reportedly slows generation rather than speeding it up. For anyone weighing this against a conventional quantized deployment, our guide to running open-source LLMs locally and the LLM quantization impact leaderboard both cover the tradeoffs of running Q2-class quantizations more broadly.

Strengths and Weaknesses

Strengths

  • Runs on stock llama.cpp, Ollama, and LM Studio with no fork or custom build, unlike VIDRAFT's own claim that a comparable Bonsai GGUF build fails to load without a PrismML-patched runtime
  • CPU generation beats the comparable Bonsai-27B build by 2.69x on a 16-thread Xeon and by more than 3x on a MacBook M3 Pro's CPU cores
  • Retains the full 262,144-token context window inherited from Qwen 3.6-35B-A3B, confirmed directly in the GGUF file metadata rather than just marketing copy
  • Four quantization tiers give a real choice between quality (Q4_K_M) and footprint (IQ1_M) rather than one-size-fits-all compression
  • Apache 2.0 licensing with no usage restrictions and no pricing tier to negotiate

Weaknesses

  • GPQA Diamond drops from the base model's 73.2% to 68.7% at Q4_K_M and 60.1% at Q2_K; quality loss is real and gets worse fast at lower bit-widths
  • Loses to Bonsai-27B on GPU prompt processing by more than half (753 versus 1,816 tok/s on an H100), since sparse MoE routing doesn't help during prefill
  • VIDRAFT's own documentation contains a lineage inconsistency, describing the base architecture as both "Qwen3.5-family" and explicitly Qwen 3.6-35B-A3B in different documents
  • The 88.4% flagship GPQA score belongs to the unquantized Darwin-36B-Opus parent under expensive 8-way majority voting, not to anything POCKET-35B can reproduce in a single pass on a phone
  • No GPQA figure disclosed for the smallest IQ1_M quantization, the build most likely to run on the lowest-memory devices

Sources

✓ Last verified July 26, 2026

James Kowalski
About the author AI Benchmarks & Tools Analyst

James is a software engineer turned tech writer who spent six years building backend systems at a fintech startup in Chicago before pivoting to full-time analysis of AI tools and infrastructure.