VIDRAFT POCKET's sparse MoE models run a 180B-parameter LLM on an 8 GB VRAM laptop

What VIDRAFT POCKET is

According to a dev.to post that credits a November 1, 2026 report from China's NetEase as its original source, VIDRAFT POCKET is a family of GGUF-format language models built specifically for consumer hardware. Three rules govern the project: every file must load into the stock, unmodified llama.cpp build — and by extension Ollama, LM Studio and PocketPal — with no custom forks, no CUDA requirement and no cloud calls; the models use a sparse Mixture-of-Experts (MoE) design so only a small slice of the total weights fires for any given token; and every performance figure comes from same-machine, same-binary measurements rather than theoretical projections.

Adoption has been substantial. As of November 1, 2026, the family's Hugging Face repositories had logged a combined 1,113,164 downloads over the prior 30 days and 3,154,913 downloads in total. The flagship POCKET-Darwin-180B had been live for less than a month at that point, so its 30-day and lifetime counts are identical.

How sparse MoE changes the math

The engineering bet behind POCKET is the gap between a sparse MoE model's total parameter count and the number of parameters actually activated on each forward pass. A 180B-parameter MoE model may engage only a fraction of those weights per token, which sharply reduces the memory bandwidth and compute that inference demands compared with a dense model of the same nominal size.

The models ship as GGUF files, the standard interchange format for llama.cpp-based runtimes, and GGUF supports mixed-precision quantization — different layers can be compressed at different bit widths. That is how the 26B model in the family stays close to baseline quality at 2-bit quantization, and how POCKET-Darwin-180B's 4-bit variant scores 87.65% on the quality benchmark used in the source, a figure the article says matches the BF16 baseline. The dev.to post is candid that the specific benchmark suite is not named, so that percentage is best read as an internal consistency check rather than a standardized result.

Measured throughput

The dev.to post reports same-binary, same-machine comparisons. On a 16-thread Xeon CPU, POCKET-35B generated 27.0 tokens per second against 10.1 tok/s for the comparison model, Bonsai-27B. On an H100 GPU, POCKET-35B reached 197 tok/s versus 89 tok/s for Bonsai-27B.

One caveat the article flags: generation speed and prefill speed are distinct metrics, and on H100 prompt processing the comparison model came out ahead — 1,816 tok/s against 753 tok/s for POCKET-35B. Workloads dominated by long prompts should weigh both numbers.

Hardware requirements

File sizes set the floor. POCKET-35B in Q2_K weighs 13 GB, runs on a CPU-only machine, and was measured at 19.5 tok/s on a MacBook M3 Pro's CPU. POCKET-Darwin-180B at 4-bit is a 111 GB file and was measured at 4.17 tok/s on a laptop pairing 8 GB of VRAM with 32 GB of RAM — a combined 40 GB, which the dev.to post does not reconcile with the file size, so the exact serving mechanism goes unexplained. The same variant also ran entirely on CPU in a mini-PC equipped with 128 GB of RAM.

How to run it

The models sit on Hugging Face, and the dev.to post shows the standard path: fetch files with the huggingface-cli download tool, then launch them with llama.cpp using -ngl 0 to keep all layers on CPU and -t set to the machine's physical core count. That last flag matters — the article warns that using the logical, hyperthreaded thread count can noticeably reduce throughput, because LLM inference is memory-bandwidth-bound and hyperthreads contend for the same physical resources. The same GGUF files drop into Ollama, LM Studio and PocketPal with no extra configuration, and a browser-based option called POCKET Image Studio exists for users who would rather not install anything.

Why it matters

POCKET is a concrete demonstration that "too big for consumer hardware" increasingly depends on architecture rather than raw parameter count. A 180B model running — slowly — on a laptop is only possible because sparse MoE plus aggressive mixed-precision quantization breaks the link between total parameters and per-token cost, and the requirement that everything work with stock llama.cpp rather than a patched fork lowers the barrier further. The limitations are real: 4.17 tok/s is functional for batch jobs but below comfortable chat reading speed, prefill can trail smaller dense models, and the headline quality number rests on an unnamed internal benchmark. Still, 3.15 million downloads in short order suggest a large audience for frontier-scale weights on machines people already own.