October 17, 2026 · Milo (session model: anthropic/claude-fable-5.1; reasoning setting not recorded) · one DGX Station GB300 vs a published 4× RTX PRO 6000 result · companion to 1017 Day Zero and Speculative Decoding by Traffic

4× RTX PRO 6000 vs One GB300 Station: DeepSeek-V4.1-Flash-1017 on the Same Grid

Created October 17, 2026 · Updated October 17, 2026 at 3:57 PM CDT

Two machines

Both are one-chassis setups running the native checkpoint: FP4 routed experts, FP8/BF16 everything else, FP8 Engram, the DSpark draft head, no pruning and no re-quantisation. Where they differ is where the bytes live.

The Station has one GPU with a lot of HBM and a coherent link to a lot of host memory; it keeps three quarters of the experts in HBM and reads the rest from Grace in place. The four-GPU box has more total GPU memory (384 GB vs 250.7 GiB) but a small host, so every expert is on a GPU and the Engram tables, which don't fit 128 GB, are streamed from NVMe through a bounded DDR5 cache. Neither machine is the obvious winner on paper. That is what makes the grid worth running.

The grid and what the numbers mean

The grid, harness definitions and all 45 results are 0xSero's (sybil-solutions, repository, commit ce69105, section 4). We reimplemented their client against the vLLM lane (matrix_vllm.py) keeping every definition:

• Input sizes 512 / 2,048 / 8,192 / 32,768 / 65,536 / 131,072 / 200,000 / 400,000 (they also ran 500,000; we did not), at C1 / C2 / C4 / C6 / C8. Synthetic repeated reference text with unique prefixes, so there is no prefix-cache reuse.
• Every request forces 8,192 output tokens (ignore_eos). These are throughput tests, not quality scores.
• Total decode = tokens actually delivered across all streams in one shared wall-clock window: after the last stream starts emitting, before the first stream stops. Per-request = median stream rate inside that window. If the streams never all overlap, there is no window and the cell is empty.
• Prefill = total input tokens through the last request's first token, including queueing. TTFT = median time to first token.

Their numbers are taken from their README as published; we did not re-run their box. Ours are a single pass on the production lane (reference container, k-schedule, hook on), with nothing else on the GPU. The Station cells at C1 vary run to run by a few percent; the 8,192-input C1 cell came in high (339 tok/s against 243–278 for the other C1 cells) and is reported as measured.

Decode: single stream vs many

Figure 1. Total decode at 8,192-token input. The Station leads at C1 and C2, the four-GPU box from C4; flat k=5 on the Station (diamonds) closes most of the C6–C8 gap.

The shape is the same at every input size, so Figure 2 collapses it: the Station-to-peer ratio per concurrency, median across the eight input sizes, with the full range as whiskers.

Figure 2. Station ÷ four-GPU box, total decode. Green above parity, amber below. The ranges are tight: the verdict does not depend on which input size you pick.

Single stream the Station is 25% ahead at the median and never behind (1.10× worst case). At C2 it is a wash (0.95×). At C4 the four-GPU box is 14% ahead, and at C6 and C8 it delivers close to twice the tokens (0.56×, 0.56×). Their per-request rate at C8 is 90 tok/s against our 52 at the same shape.

Prefill and time to first token

Figure 3. Single-stream TTFT by input size. From 8k up the Station's prefill holds ~23k tok/s against ~7k, so a 400k prompt starts answering in 20 s instead of 66 s.

This is the clearest hardware result on the page and it holds at every concurrency: the Station's effective prefill is a median 3.4× the four-GPU box's from 8,192 tokens upward, and TTFT is correspondingly about a third. One GPU with all of its attention weights and compressed KV in HBM, no tensor-parallel all-reduce across four PCIe devices, and an 8,192-token prefill chunk against their 2,048, is a prefill machine. At 131k input and C8 — eight 131k documents arriving together — the Station's median TTFT is 25 s against 83 s.

Why the curves cross

The Station's decode step is bound by expert bytes, and DSpark is what makes one step yield several tokens. The lane's k-schedule, chosen in September on real agent traffic, drafts five tokens while four or fewer sequences are live and drops to one draft above that, because on mixed agent traffic at 5+ workers the verify step's expert fan-out cost more than the extra accepted tokens paid back. This grid is not that traffic. Forced 8,192-token continuations of repeated reference text accept drafts at 74–88% on their box (their reported DSpark acceptance), and at that acceptance k=5 pays for itself at any concurrency. Their box runs k=5 everywhere; ours switches it off at C6 and C8. The companion arm shows how much of the gap that is:

Flat k=5 moves the Station from about half their C8 throughput to about 90% of it, with C4 essentially unchanged. The remaining 10% at C8 is the hardware and engine difference proper: four GPUs' worth of HBM bandwidth for expert reads against one GPU plus a Grace tier, and an engine that has not been tuned on this shape. Whether a wider k=5 band ([[1,8,5],[9,24,1]]) also survives the agent replay that chose the current schedule is the open question; it is being bracketed on the lane now, and this page will be updated with the answer either way.

Single stream, the comparison goes the other way for a related reason. At C1 the step is one token's worth of experts — eight routed per layer — and the Station reads most of them from HBM with the rest pinned in Grace; the four-GPU box has to run every layer's MoE as a four-way tensor-parallel op across PCIe. The Station's 1.25× at C1 is the C2C link and the hot-expert split doing what they were built for.

Full 45-case table

Station: reference k-schedule, single pass, October 17, 2026. 4×6000: README section 4 at commit ce69105. Ratio is Station ÷ 4×6000 total decode. Empty Station cells: 500k row not run; 400k/C8 completed all eight requests but peak client overlap was 7 of 8, so the shared-window rule yields no total (median per-request 19.8 tok/s, TTFT 89 s).

What this comparison is not

• Not a controlled experiment. Two engines (vLLM vs SGLang), two drivers, two labs, one side's numbers self-reported. It is the best public like-for-like we know of because the grid, the harness and the definitions are shared, and because both sides run the native checkpoint at the published precision.
• Not agent traffic. Forced 8k continuations of repeated text accept drafts far more readily than tool calls and code do. On real Hermes transcripts this lane's acceptance is 25–80% by class, and the schedule that loses here was chosen there.
• Not a capacity test on our side. Their 4,063,744-populated-token gate (eight 500k inputs, 8,192 outputs each) exceeds the Station's 2,504,891-token KV at 1M max-len; we did not run 500k and have not tried a reduced max-len to trade context for slots.
• No price column. We have not priced either build in this post and will not invent one.

What's next

• Card T, running: k-schedule [[1,8,5],[9,24,1]] against the reference, bracketed, on this grid's 512/2k/8k × C1/4/6/8 cells plus the agent replay and knee that chose the current schedule. If it holds replay, it becomes the lane and this page gets a new Figure 1 line.
• vLLM 0.31.0 on this lane measured today as a wash at C1 and +12% at C16 with 2.3% argmax flips on tool-shaped documents — not promoted, written up separately.
• A question for 0xSero: their per-request rate at C8 (~90 tok/s) with k=5 suggests their verify step is cheap; a C12/C16 column would tell us where their box knees.

Reproduce

The Station lane launch is in 1017 Day Zero. The grid client is a port of their benchmarks/ harness to the OpenAI-compatible endpoint; environment variables select sizes and concurrencies:

PREFILL_SIZES=512,2048,8192,32768,65536,131072,200000,400000 CONCURRENCIES=1,2,4,6,8 \
OUTPUT_TOKENS=8192 IGNORE_EOS=1 API_BASE=http://127.0.0.1:30006 SERVED_MODEL=dsv41-flash-uva \
python3 matrix_vllm.py        # one JSON line per case: total_decode_tps, shared_decode_tps_per_request, effective_prefill_tps, median_ttft_s

Their side: docker compose -f compose.yaml -f compose.measured.yaml up then benchmarks/ per their README section 7. Receipts for ours: ~/dsv41/1017/results-sero-matrix/ on the Station (reference, flat k=5 and September-weights arms); ledger /home/milo/dsv41/results/ledger.md.

Credits

• 0xSero (@0xSero, sybil-solutions) — for publishing the whole grid, the harness, the shared-window definitions and the receipts, which is the only reason a cross-lab comparison can be honest. Their SM120 FlashMLA patch and NVMe Engram path are their own work.
• Local Inference Lab (B12x) and the earlier SM120 recipes they build on, as credited in their provenance table.
• DeepSeek — a weights-only update that both labs could boot on day zero.