ZGX Fury LLM Benchmark: 3,000 Tok/s Tested [2026]

The ZGX Fury is a Grace-Blackwell-class desktop AI computer — the scaled-up "big brother" of the ZGX Nano, itself a sibling of Nvidia's DGX Spark — built around a large pool of unified CPU/GPU memory instead of a discrete graphics card. It matters right now because a single YouTube video claiming it hits 3,000 tokens per second in a local LLM benchmark went viral on 2026-10-30, pulling 25,053 views within hours, and not one written analysis of that tokens number exists anywhere.

So this is the first text breakdown of the ZGX Fury local LLM benchmark. I haven't had a Fury on my own bench — it surfaced today, and nobody outside the demo has one — so I won't pretend I measured it. What I can do is apply the same benchmark methodology I use across the local-LLM benchmark database I maintain at kunalganglani.com/llm-benchmarks: take the 3,000 tok/s headline apart, spell out exactly what configuration would produce it, and compare it honestly against the hardware you'd actually cross-shop.

Key takeaways:

• The 3,000 tokens/sec figure is real but it is aggregate throughput across many parallel requests on a small, heavily quantized model — not the speed you feel talking to one chatbot.
• The ZGX Fury is a unified-memory box in the DGX Spark family, so its advantage is loading huge models, not winning single-stream decode races against a discrete GPU.
• An RTX 5090 will still out-decode it on one conversation; the Fury wins on concurrency and on models too big for 32GB of VRAM.
• No official specs, price, or availability have been published as of 2026-10-30 — treat every spec number here as lineage-based estimate, not datasheet fact.
• A single tok/s number with no model, quant, batch size, and context length is marketing, not a benchmark.

What Is the ZGX Fury?

The ZGX Fury is, by the only description that exists, "the big brother of the ZGX Nano (DGX Spark)." That framing comes from Sam Witteveen, the AI YouTuber whose hands-on video is currently the sole public coverage of the machine. His channel is a verified tech source, and his clip hit 106 comments and a ~48,000 views/day pace almost immediately — which tells you how starved the market is for "3,000 tok/s locally" content.

Here's the lineage that actually matters. Nvidia's DGX Spark is a desktop AI box built on the GB10 Grace Blackwell Superchip: an Arm CPU and a Blackwell GPU fused onto one package, sharing 128GB of LPDDR5X as unified memory. The ZGX Nano sits in that same entry tier. The Fury is the scaled-up sibling — bigger memory pool, more compute, and almost certainly a jump to a GB300-class "Ultra" superchip with HBM-grade bandwidth rather than plain LPDDR5X.

That single architectural fact — unified memory, not a discrete card — is the whole story. It decides which models fit, how fast they run, and who should care. A box like this isn't competing with a graphics card on frame-rate-style throughput. It's competing on capacity: can it hold a 200B+ parameter model in memory at all, which a 32GB GPU simply cannot.

Full Specs Breakdown: What We Actually Know

I'm going to be blunt about the thing every other future post will fudge: as of 2026-10-30, there is no published ZGX Fury datasheet. No official memory figure, no bandwidth number, no TDP, no price. Across more than a dozen searches that day — exact phrase, brand, specs, price, Reddit threads — the indexed written results came back empty.

What we can infer from the "big brother of DGX Spark" lineage:

• Memory: A unified pool well above the Nano's 128GB. A GB300-class part would land somewhere in the 256GB–784GB coherent-memory range. Call it unconfirmed.
• Memory bandwidth: This is the number that governs decode speed. The DGX Spark's ~273 GB/s is its biggest weakness. A Fury built on HBM3e would multiply that into the multi-TB/s range — the single most important upgrade for LLM work.
• Compute: Blackwell-generation tensor cores with native FP4/FP8 support, which is exactly why a 3,000 tok/s aggregate number is even plausible.
• Networking: DGX Spark ships with ConnectX-7 for clustering two units; a Fury almost certainly keeps that, so multi-box scaling is on the table.

Treat all of that as estimate. The honest spec sheet today has one confirmed cell: the claimed throughput. Everything else is lineage inference, and I'll update this post the moment Nvidia (or whoever is behind the ZGX branding) publishes real numbers. For how memory capacity maps to model size across every tier, the site's local LLM hardware requirements guide is the reference I'd pair with this.

Can the ZGX Fury Really Hit 3,000 Tokens/Sec?

Yes — and no. Both answers are true, which is exactly why a raw headline number is useless without context.

Yes, 3,000 tokens per second is achievable on hardware in this class. No, you will not see 3,000 tok/s typing to a single chatbot. That figure is almost certainly aggregate decode throughput: dozens of concurrent requests batched together, on a small model (think 7B–8B or an MoE with a tiny active-parameter count), quantized to FP4 or similar, with the KV cache tuned for batch size. Divide 3,000 by a realistic batch of 32–64 and you're back to a per-stream speed in the 50–90 tok/s range — fast, pleasant, but not magic.

A single tokens-per-second number with no model, quantization, or batch size attached isn't a benchmark. It's a billboard.

This is the gap the viral clip leaves wide open. It shows the big number without the breakdown, so the 106 commenters are left guessing which model and which config produced it. That's not a knock on the video — it's a 10-minute demo, not a methodology paper. But it's why a written post can own this query: searchers want the asterisk, and nobody has published it.

Here's Sam Witteveen's actual demonstration for context:

For a sense of scale, the fastest single-stream numbers I track for consumer hardware sit well below this in raw per-token terms but win on latency. The point of a box like the Fury isn't to beat a 5090 on one prompt. It's to serve a small team's worth of concurrent agent traffic from one quiet desktop.

What Model and Quantization Produced 3,000 Tok/s?

The honest answer is that the viral clip never says, and that omission is the whole reason this query needs a written answer. But you can reverse-engineer the plausible configurations, because a number that high only comes from a narrow set of ingredients.

Start with the arithmetic. If 3,000 tok/s is aggregate throughput across a batch of 64 concurrent streams, each conversation is decoding at roughly 47 tokens per second. Across 32 streams it's about 94 tok/s per stream. Both are completely ordinary single-stream numbers for a small model — which is the tell. The headline is a serving metric, not a speed record.

Now the model. A figure in the low thousands almost certainly came from a 7B–8B dense model (think a Llama-3-class 8B) or a sparse Mixture-of-Experts checkpoint with a small active-parameter count, where most of the weights sit idle per token. Run a 400B-parameter dense model and that number collapses by an order of magnitude regardless of hardware.

Then quantization. Blackwell-generation tensor cores have native FP4 support, and FP4 roughly doubles decode throughput over FP8 for the same model while halving memory footprint. A GGUF, GPTQ, or EXL2 choice shifts both speed and quality, and the quality cliff is model-family-specific — a blanket "just use Q4" recommendation is wrong often enough that I treat it as a per-model test, not a default. Pair FP4 weights with a batching engine like vLLM or TensorRT-LLM and a tuned KV cache, and 3,000 aggregate tok/s stops being surprising. Without the model, quant, batch size, and context length stated together, the figure simply can't be reproduced — which is the definition of content, not data.

Benchmark Methodology: How to Actually Test ZGX Fury Tokens/Sec

If you want to verify a 3,000 tok/s claim instead of repeating it, run the test the way a benchmark should be run. This is the standard I hold every machine to in the site's local LLM benchmark methodology, and it's the only way the Fury's number becomes data instead of content.

Report these as separate, labeled figures — never a single blended number:

1. Time To First Token (TTFT) — how long before the first token appears, measured at a fixed prompt length. This is latency, and it's what makes a machine feel responsive.
2. Steady-state decode tok/s, single stream — the honest "how fast does it type to me" number with batch size 1.
3. Aggregate throughput, batched — total tok/s across N concurrent requests. State N. This is almost certainly where 3,000 lives.
4. Model and quantization — exact checkpoint, parameter count, and quant format. A GGUF, GPTQ, or EXL2 choice can swing throughput by 2x and quality off a cliff.
5. Context length and KV cache settings — a 2K-token prompt and a 128K-token prompt are different machines. Note KV cache precision too; 8-bit KV cache changes both speed and memory headroom.
6. Reproducibility — publish the command and the config so someone else can rerun it.

Skip any of those six and the result can't be trusted. A benchmark you can't reproduce is a screenshot. The same discipline applies whether you're testing a Fury, an RTX 5090, or a Raspberry Pi — the numbers only mean something relative to a stated workload shape. TTFT and latency tuning deserve their own attention because a high aggregate tok/s can still hide an ugly first-token delay.

Setup & Configuration Notes Nobody Else Has Published

This is the section the video can't give you in searchable text, and it's where Grace-Blackwell boxes trip people up. I'm drawing here on how this class of hardware behaves, not a Fury on my own bench — but the failure modes are consistent across the family.

The software stack is the real question, not the silicon. On a previous head-to-head, RTX 4090 vs RX 7900 XTX, the deciding factor for real-world usability wasn't spec-sheet throughput at all — it was driver and ecosystem maturity. CUDA worked; ROCm fought me. A brand-new box with a brand-new name inherits that risk double. The question for the Fury isn't "how fast is the GPU" — it's "does vLLM, llama.cpp, Ollama, or TensorRT-LLM have working support for this exact chip on day one?"

• vLLM / TensorRT-LLM are where that 3,000 aggregate number comes from. They batch. If you want serving throughput, this is the path — but expect to pin specific CUDA and container versions, because Blackwell-generation parts routinely need bleeding-edge builds.
• Ollama and llama.cpp are what most people will actually install first. Georgi Gerganov's llama.cpp will likely run via its CUDA backend, but single-stream decode won't show you anything close to 3,000 — that's expected, not a defect.
• Unified memory paging is the sharp edge. Load a model that spills past the physical pool and throughput collapses as the system pages. Size your model-pack to leave KV-cache headroom.
• Cooling and power on these compact boxes throttle under sustained batched load far sooner than during a short demo. A 10-minute video rarely surfaces the 30-minute thermal reality.
• First boot on prerelease hardware usually means a kernel/driver update before any inference engine will enumerate the GPU at all. Budget an afternoon, not ten minutes.

Every time I've benchmarked unified-memory machines for the site's hardware guides, the same pattern repeats: the memory pool lets enormous models load, but throughput is the tax you pay for that freedom. The Fury's HBM-class bandwidth is what would make it the exception — if the drivers cooperate.

ZGX Fury vs DGX Spark vs RTX 5090 vs Mac Studio M3 Ultra

Here's the comparison buyers will actually search for. Fury cells are lineage-based estimates; the other three columns are confirmed public specs.

Read this through the unified-memory lens and the tradeoffs snap into focus. The RTX 5090's ~1,792 GB/s crushes everything on bandwidth, which is why it wins single-stream decode — but 32GB caps the models it can hold. The Mac Studio M3 Ultra trades bandwidth for a 512GB pool, so it loads models the 5090 can't touch, just slower per token. The DGX Spark's 128GB at only ~273 GB/s is the cautionary tale: capacity without bandwidth feels sluggish. The Fury's entire reason to exist is fixing that last cell — pairing a big unified pool with HBM-class bandwidth. If the estimates hold, it's the first box in this group that doesn't force the capacity-versus-speed compromise. The Mac Studio vs RTX PC breakdown digs further into that exact tension.

Across the Apple Silicon and NVIDIA runs in the local-LLM benchmark database I maintain at kunalganglani.com/llm-benchmarks, the pattern that holds is that memory bandwidth predicts single-stream decode tok/s almost linearly within a fixed model and quant — unified memory lets enormous models load, but throughput is the tax you pay for that freedom. A machine at ~273 GB/s and one near ~1,792 GB/s aren't in the same conversation for interactive use. That's roughly a 6.5x gap, which is exactly why the Fury's rumored HBM jump is the spec that decides everything, not its core count. The same math is why the M3 Ultra's 512GB pool at ~819 GB/s feels usable for 70B models while the DGX Spark's larger-per-dollar capacity disappoints the moment you start decoding.

Pricing, Availability, and Who Should Buy It

There is no price. There is no ship date. Anyone quoting one today is guessing. Given the DGX Spark anchors around $3,000–4,000 and the Fury is the bigger, HBM-equipped sibling, a four- to low-five-figure range is the sane expectation — but that's inference, not fact, and I won't dress it up as more.

So who is this actually for?

• Buy it if you need to serve concurrent LLM or agent traffic locally — a small team, a RAG backend, or an on-prem inference endpoint — and you want big models in one quiet box instead of a multi-GPU rig. The aggregate throughput is the whole point.
• Skip it if you're a single user who wants the snappiest possible chat. An RTX 5090 gives you better single-stream decode for a fraction of the money, and the RTX 5090 vs RTX 4090 comparison covers that tier in full.
• Think twice if your workload is cost-sensitive. A desktop AI box only pays off past a real utilization threshold; run the LLM cost break-even math before you spend four figures chasing a headline.

As Simon Willison has argued repeatedly about running models locally, the number that matters for a single human is interactive responsiveness, not peak aggregate throughput — a reminder that the 3,000 figure answers a serving question, not a personal-assistant one. If you're building production-grade local serving, the AI in production patterns matter more than any one spec, and the broader local AI hardware picture is where I'd start before committing budget. For a free, immediately usable setup to experiment while you wait, the Hermes Agent Desktop local LLM walkthrough gets you running today.

The ZGX Fury's 3,000 tok/s isn't a lie and it isn't magic — it's a serving-throughput number wearing a single-user costume. Once real specs land and an inference stack actually ships for it, the question won't be whether it hits the headline. It'll be whether a Grace-Blackwell desktop finally kills the capacity-versus-bandwidth compromise that has defined local LLM hardware since the first large language model was too big for a single card. If the Fury does that, every "which GPU" buying guide — including mine — gets rewritten. I'll have the reproducible numbers up the day one lands on a bench.

Photo by Fredrick Tendong on Unsplash.