VKUE: Can a 34.7B Reasoner Run on a Laptop Without a GPU?

VIDRAFT_LAB posts Ourbox-35B-JGOS to Hugging Face: 20 tok/s on an 8GB laptop GPU, ~17 tok/s on a CPU-only server, 86.4% on GPQA Diamond.

A laptop screen displaying lines of source code in a darkened room, a visual stand-in for running a 34-billion-parameter model on commodity hardware.

On July 12, 2026, a community blog post on Hugging Face claimed something the local-AI beat has been chasing for two years: a 34.7-billion-parameter reasoning model, Ourbox-35B-JGOS, running at 20.01 tokens per second on a stock 8 GB laptop GPU and roughly 17 tokens per second on a CPU-only server. The model card is published under Apache 2.0, the GGUF weights are downloadable, and the authors left two live Spaces where anyone with a Hugging Face account can compare GPU and CPU paths on the same prompts. If the numbers survive independent benchmarking, this is the first credible demonstration of a 30-billion-class reasoner running on hardware a reader already owns, without a discrete GPU at all.

What VIDRAFT_LAB actually claims

The blog post, authored under the handle SeaWolf-AI and published under the FINAL-Bench author profile, frames the project around the inference engine rather than the weights alone. The headline numbers come from one machine, run with llama-bench at tg64 and reported with an uncertainty of plus or minus 0.24 tokens per second:

  • Datacenter B200 (single card, VIDRAFT serving): 18,057 tok/s aggregate.
  • A10G cloud GPU, single-stream: 126 tok/s.
  • 8 GB laptop RTX 5060: 20.01 tok/s.
  • CPU-only server, no GPU: roughly 17 tok/s.

The same GGUF file is used across all four tiers; only the hardware changes. The Q3_K_M quantization is the one in the headline number; the model card also lists IQ1_M at 8.24 GB, Q2_K at 12.9 GB, Q3_K_M at 16.8 GB, and Q4_K_M at 21.2 GB. The author’s recommended llama.cpp flag on the 8 GB card is --n-cpu-moe 99, with the note that “partially offloading experts to the GPU was slower,” which is the practical reason a fully-CPU path can hold its own against a small consumer GPU.

The headline-versus-baseline number is the comparison against dense Qwen2.5-32B at the same Q3_K_M quantization on the same 8 GB laptop. Dense 32B hit 5.36 tok/s; Ourbox hit 20.01 tok/s. That is the 3.7x gap the authors attribute to sparsity, not to any new quantization trick.

Why a sparse Mixture-of-Experts changes the laptop math

Ourbox-35B-JGOS is a sparse MoE from the Qwen3.5-MoE / Qwen3-Next family, the same A3B active-parameter architecture that has anchored the open-weight MoE story since Qwen3-30B-A3B landed in early 2026. The model card lists 256 experts with top-8 routing, Gated-DeltaNet linear attention interleaved with full attention, and roughly 3 billion active parameters per token out of 34.7 billion total (an “A3B” configuration). The decode cost therefore scales with the active subset, not with the full model.

The blog post translates that into memory traffic: a dense 34B moves about 16.7 GB per token, while the A3B Ourbox moves about 1.45 GB per token - “about 11x less memory traffic.” On a GPU with limited VRAM, the practical implication is that the bulk of the experts can sit in system RAM while only the attention, router, and shared layers need to live on the device. On a CPU-only box, the same logic means the model never needed a GPU in the first place.

The reasoning quality number on the post is GPQA Diamond at 86.4 percent under maj@8 and 70.7 percent greedy. Both numbers are labelled “measured, conditions labeled.” The blog post does not independently re-benchmark Qwen2.5-32B or any other 30B dense reasoner on GPQA Diamond in the same table, so the speedup claim (3.7x) is grounded in the same author’s throughput measurement while the reasoning-quality claim is grounded in the published benchmark numbers of the underlying Qwen3.5-MoE / Qwen3-Next family.

Two engines, one weight file

The blog post introduces VKUE (VIDRAFT Kernel Ubiquitous Engine) and its faster sibling VKAE (VIDRAFT Kernel Acceleration Engine), with the tagline “VKAE is fast; VKUE is everywhere.” VKAE is the speed-optimized serving stack - it is what the 18,057 tok/s B200 number was measured against. VKUE is the ubiquity-optimized stack - it is what the laptop and CPU numbers were measured against. The post positions VKUE as the path readers will actually use, and VKAE as the path datacenters will pay for.

The authors include a “Honest caveats” section. Two lines are worth quoting in full. First: “These are one machine’s live measurements, not universal claims.” Second: “The CPU path proves the model runs without a GPU - it is not claimed to beat a GPU.” The 17 tok/s CPU figure is therefore a floor, not a ceiling - the practical read for a reader with an M-series MacBook or a Ryzen laptop is that the model will run, not that it will set speed records.

There is one out-of-band number worth flagging. The blog notes that “with weights held entirely in a 24 GB card’s VRAM, an A3B reaches 87 to 196 tok/s.” That range is wider than the laptop number because the 24 GB card keeps experts on-device rather than streaming them from system RAM, and the range is presented as the team’s measurement rather than as a third-party benchmark. Readers with a 24 GB consumer card (RTX 3090, 4090, or the workstation-class equivalents) should treat that range as the realistic local-AI target.

What This Means

For readers who follow intelligibberish’s local-AI VRAM tier comparisons, this is the first credible re-shuffling of the 8 GB tier in 2026. Until now, the 8 GB tier has been the home of small chat models (7B to 12B dense at low quant) and the upper bound of any “real” reasoner was a 13B to 14B at aggressive quantization. The Ourbox claim - 30B-class reasoning quality at 20 tok/s on hardware you already own - changes that math if it holds up.

Three things to watch. First, an independent re-run on a different 8 GB laptop; the 20.01 tok/s number has a stated uncertainty of plus or minus 0.24, but a different CPU, different memory, or a different llama.cpp build could shift the absolute number materially. Second, an independent GPQA Diamond run; the post inherits the family-level benchmark rather than reporting a clean re-run, so a third-party eval would close that loop. Third, real Ollama and LM Studio integration; the GGUF file exists and the live GPU demo is open, but until the model shows up in the standard local-AI runners - the same Ollama and Open WebUI path our self-host ChatGPT guide walks through - with documented install commands, the practical lift stays on the Hugging Face Spaces.

If you want to try it today, the path is huggingface.co/FINAL-Bench/Ourbox-35B-JGOS-GGUF plus llama.cpp with --n-cpu-moe 99, or the CPU-only demo Space for a no-install feel. Either route gives a reader a 30B-class reasoner on hardware that, six months ago, was firmly in “7B chat only” territory.

The Bottom Line

VIDRAFT_LAB’s Ourbox-35B-JGOS is a 34.7-billion-parameter sparse MoE reasoner (about 3B active per token, 256 experts, top-8 routing) published under Apache 2.0 with GGUF weights and live CPU and GPU demo Spaces. The blog post reports 20.01 tok/s on an 8 GB RTX 5060 laptop, roughly 17 tok/s on a CPU-only server, and GPQA Diamond at 86.4 percent (maj@8). The numbers come from one machine, are openly reproducible, and have not yet been independently re-benchmarked - so the right read is “the first credible 30B-class reasoner on commodity laptop silicon,” not “every laptop will hit 20 tok/s.”