Chip guide · with community benchmarks
GB10 is NVIDIA's Grace-Blackwell superchip: an ARM64 Grace CPU and a Blackwell GPU sharing one 128 GB memory pool. We run it in production — with clearly-labelled community benchmarks for the hardware class below.
The chip
| Design | Grace-Blackwell superchip — Grace CPU + Blackwell GPU on one package |
|---|---|
| Memory | 128 GB unified, shared CPU/GPU — one pool, no separate VRAM |
| CPU architecture | ARM64 (Grace) |
| Ships in | NVIDIA DGX Spark — the rentable product |
| At AxForge | Live in production in Sweden (eu-se-1) — rentable as dedicated DGX Spark machines |
Unified memory changes the sizing question. On a conventional GPU, the model must fit in VRAM. On GB10, weights, KV cache and the host share one 128 GB pool — so model weights up to roughly 100 GB can load on a single chip without sharding across devices, with room left for cache and the system. For the 7B–35B models we serve, that means the whole model plus a 131,072-token context fits with headroom.
Community data
Not our numbers: SparkBench measures models on a single GB10 at 4k context with its PBM methodology, and ranks decode throughput after a fixed context fill. Useful for comparing what the chip can do across model families and runtimes.
| Model | Architecture | Quant / optimization | Workload | Speed @ 4k |
|---|---|---|---|---|
| Qwen3.6-35B-A3B | 35B / 3B active MoE | NVFP4 + MTP | Agents / general / reasoning | 86.3 t/s |
| Mellum2 12B MoE Opus Thinking | 12B / 2.5B active | Q4 | Code / reasoning | 83.8 t/s |
| Ornith 1.5 35B-A3B | 35B / 3B active MoE | NVFP4 + MTP | Agents / code / reasoning | 70.8 t/s |
| Qwen3-Coder-Next | 80B / 3B active MoE | NVFP4 | Agents / code | 58.9 t/s |
| Ornith 1.0 35B | 35B / 3B active | NVFP4 | General | 46.5 t/s |
| Qwen3-Coder-30B-A3B-Instruct | 30B / 3B active MoE | Q4_K_M | Agents / code | 42.1 t/s |
| Qwen AgentWorld 35B-A3B | 35B / 3B active | — | General | 29.6 t/s |
| Laguna S 2.1 | 118B / 8B active MoE | NVFP4 + DFlash | Agents / code | 29.1 t/s |
| Qwen3.6 27B Aeon | 27B dense | NVFP4 + DFlash | General | 26.0 t/s |
| Qwen3.8-27B MTP | 27B dense | NVFP4 + MTP | Agents / general / reasoning | 25.1 t/s |
| DeepSeek V4 Flash 0731 | 180B / 13B active | EXL3D / SparkInfer | Code / reasoning | 23.4 t/s |
| Gemma 4 26B-A4B-IT | 26B / 4B active MoE | — | Multimodal / reasoning | 23.0 t/s |
| Laguna XS 2.1 | 33B / 3B active | DFlash | Agents / code | 21.4 t/s |
| Step-3.7-Flash | 198B / 11B active | IQ4_XS | Agents / multimodal | 20.5 t/s |
| Gemma 4 12B IT | 12B dense | Q4_K_M | General / multimodal | 19.8 t/s |
| Gemma 4 12B Coder | 12B dense | Q4 | Code | 19.1 t/s |
| Qwen3.6-27B | 27B dense | FP8 + DFlash | Agents / reasoning | 17.3 t/s |
| Qwythos 9B Claude Mythos | 9B dense | — | General | 12.6 t/s |
Community results vary by runtime, quantization, context length and serving configuration. We serve this hardware in production but have not published our own tuned numbers yet — these tables carry the honest picture meanwhile.
Community data
From a llama.cpp size sweep on GB10 (Q4_K_M, batch size 1) — the clearest demonstration of how the chip behaves across model sizes:
| Model | Params | Decode @ 512 | Decode @ 2048 | Prompt proc @ 512 | PP @ 16k |
|---|---|---|---|---|---|
| Qwen3 1.7B | 1.7B | 161.4 t/s | 146.1 | 11,947 | 5,208 |
| Ministral 3B | 3.4B | 91.9 | 86.6 | 6,961 | 3,166 |
| Qwen3 8B | 8.2B | 43.7 | 42.0 | 3,167 | 1,862 |
| Ministral 8B | 8.5B | 41.7 | 40.1 | 3,020 | 1,868 |
| Ministral 14B | 13.5B | 26.4 | 25.7 | 1,853 | 1,284 |
| Qwen3 30B-A3B MoE | 30.5B / ~3B active | 89.3 t/s | 83.8 | 2,541 | 2,059 |
| Qwen3 32B dense | 32.8B | 10.7 t/s | 10.5 | 762 | 481 |
30B MoE ≈ 8× a 32B dense
Almost the same parameter count — 89 vs 11 tokens/s. GB10 has plenty of compute but roughly 273 GB/s of LPDDR5X memory bandwidth: dense decode is bandwidth-limited, while a sparse MoE only reads its active experts per token.
Software moves the numbers
Older llama.cpp runs put Qwen3 30B-A3B at ~44–46 t/s shallow-context; newer builds of the same setup reach ~61 t/s, and optimized NVFP4/MTP stacks go higher still. A six-month-old GB10 benchmark understates the same box today.
Community data
From the official llama.cpp DGX Spark benchmark set, Qwen3-Coder 30B-A3B (Q8) — the same model and machine produce very different, equally correct numbers:
| Context depth | Single-stream decode |
|---|---|
| ~0 | 61.1 t/s |
| 4k | 54.8 t/s |
| 8k | 48.0 t/s |
| 16k | 40.2 t/s |
| 32k | 30.2 t/s |
Decode slows as the KV cache grows — "60 t/s" and "30 t/s" can both be true for the same model, at different context depths.
| Concurrent batches | Aggregate decode @ 4k |
|---|---|
| 1 | 53.5 t/s |
| 2 | 62.8 t/s |
| 4 | 83.8 t/s |
| 8 | 120.4 t/s |
| 16 | 165.0 t/s |
| 32 | 216.8 t/s |
Aggregate throughput across many streams — not 216 tokens/s for one user. A dedicated machine cares about single-stream speed; an API serving many users cares about both.
The shape of the machine
Boiling all of the above down: GB10 is not "small = fast, big = slow". A 35B MoE can be eight times faster than a 32B dense model on it. Large-model capacity at workstation economics — not an H100 replacement, and not trying to be.
| Model type | Typical GB10 experience |
|---|---|
| 1–4B dense | Very fast — ~90–160+ t/s |
| 7–9B dense | Fast — ~30–45 t/s |
| 12–14B dense | Good — ~20–30 t/s |
| 27–32B dense | ~10–25 t/s — heavily optimization-dependent |
| 30–35B MoE, ~3B active | Excellent — ~40–90 t/s |
| ~80B MoE, ~3B active | Can still reach ~60 t/s |
| 100–200B MoE | Fits and runs depending on quant — often ~20–30 t/s |
| >100B dense | Fits only with aggressive quantization; tends to be slow |
Ranges assembled from the labelled community sources above, 2026-09. Your model, quantization and serving stack decide where in the range you land — an engineer can scope it with you.
Data & privacy
Our GB10 systems run in Sweden. On a dedicated machine: your model, your traffic, our hardware — prompts never persisted. Only request metadata (token counts, timestamps, status) is kept for billing and operations. Full policy at axforge.ai/privacy.
FAQ
GB10 is NVIDIA's Grace-Blackwell superchip: a Grace ARM64 CPU and a Blackwell GPU sharing 128 GB of unified memory in one pool. It powers the NVIDIA DGX Spark.
128 GB of unified memory, shared between CPU and GPU. There is no separate VRAM pool — weights, KV cache and the host share the same 128 GB.
Community benchmarks (SparkBench, llama.cpp) span roughly 10 tokens/s for 30B-class dense models up to ~90 tokens/s for 30–35B MoE at 4k context, with small dense models faster still. Architecture, quantization and serving stack dominate — see the labelled tables on this page. We haven't published our own tuned numbers yet.
Yes — as a dedicated NVIDIA DGX Spark from AxForge, available now in Sweden on monthly rental. €495/month launch pricing.
The 128 GB unified pool means model weights up to roughly 100 GB can load on a single GB10 without sharding across devices, leaving room for KV cache and the system. Our measured production workloads are 7B–35B class models.
Yes. The Grace CPU is ARM64, so software must be built for ARM64. Our own serving stack runs on it in production — every number we publish was measured there.