Theme
Reflections · DGX Station · DeepSeek-V4.1 Flash · QAD

A Datacenter at Home

400+ tok/sec single stream DSV4.1 Flash, up to 60K tok/sec prefill. Comfy thermals. Scales to 64 concurrent very well (2400 tok/sec.

What we have here is the Asus variant of the NVIDIA DGX Station, which Asus is calling: ExpertCenter Pro ET900N G3

When Asus reached out and offered to send me a demo unit for review, I wasn't sure what to expect. Historically, working with the previous Grace Hoppers, software left a lot to be desired and it was a pretty difficult architecture to work with, but I still had to give it a shot.

I expected to probably prefer a 4x RTX Pro 6K build with a gen 5 switch, but I have been pleasantly surprised by the DGX Station/GB300, and can easily say I would recommend this machine over a 4-6x RTX Pro 6K build, though I would suggest you spec yours with an RTX Pro 6K instead of the 4K mine has (had). I did testing here with an RTX Pro 6K in that slot.

the DGX Station tower
the machine itself · GB300 superchip inside, RTX PRO 4000 for display
01The Machine
53.3 cm (21") tall 58.4 cm (23") deep 22.9 cm (9") wide
the box: 53.3 cm tall × 58.4 cm deep × 22.9 cm wide (21 × 23 × 9 in)
headline specs, measured on az300 unless marked spec
componentdetail
CPU 72× Grace Neoverse V2, up to 3.37 GHz, 64 KiB L1 + 1 MiB L2 per core, 114 MiB shared L3
GPU GB300, SM 2070 MHz, 8192-bit HBM3e bus, up to 20 PFLOPS sparse FP4 (vendor figure, unverified)
HBM3e 252 GB, up to 7.1 TB/s (spec), NUMA node1
LPDDR5X 496 GB, up to 396 GB/s (spec), NUMA node0 (all 72 CPUs). free -h reports 744 GiB total because HBM counts in MemTotal; budget node0 alone
coherent memory 748 GB across NVLink-C2C (dist 80), 9 NUMA nodes, nodes 2-8 present but unpopulated on this driver
networking ConnectX-8 SuperNIC, one chip, two ports (ibdev2netdev), up to 800 Gb/s station-to-station
other PCIe RTX PRO 4000 SFF 24 GB on Gen5 x16 (display only), 2 empty Gen5 x8 slots, 4× NVMe Gen5 x4
power 1600 W PSU; GB300 window 200-1500 W, this box capped at 1300 W
bandwidth, measured LPDDR5X memcpy pinned to node0: 149 GB/s copied at 32 threads (~300 GB/s read+write traffic), 13 GB/s on one core, worse past 32 threads. HBM not benchmarked, model was live

Both memory pools sit in one coherent address space. The CPU can touch HBM directly, and the GPU can dereference host pointers through UVA and read LPDDR5X from inside a kernel, no staging buffers or copies. This is what lets dsv4.1 flash keep expert weights and the Engram n-gram tables in Grace RAM and read them in place from device code.

02Scaling DSV4.1 Flash
bring-up, serving stack, and getting DeepSeek-V4.1 Flash running at full scale on one box

Update: As of the time of publishing this too, DeepSeek just released an Oct 17th version of DSV4.1F (1017), and it looks to be legitimately the best open source model overall now.

DeepSeek-V4.1 Flash was the first model I brought up at full scale on this box. It is a big mixture-of-experts model: 384 routed experts per layer across 40 layers, plus two Engram n-gram tables it reads like an addressable memory. None of that fits in 252 GiB of HBM.

Instead, we're using a recipe from EL8 from github.

This model is a full DGX Station experience, where the GB300 holds 230GB worth of model weights, KV cache, and 285 experts. The RTX Pro 6K holds 99 of the cold experts, and then the Grace LPDDR5X RAM holds the 254GB ngram table along with 139GB of page cache.

where the model lives, measured 2026-10-06 from the live service, read-only, no restart
pooltotal GiBused GiBcarries
GB300 HBM · node 1 250.69 246.95 weights and hot experts 230.75 GiB (285/layer × 40), KV fp8_ds_mla 2.97 GiB, peak activation 3.31 GiB
RTX PRO 6000 · sidecar 95.59 71.57 99 cold experts/layer × 40 = 3,960 experts, 70.6 GiB
Grace LPDDR5X · node 0 494.51 470.78 Engram tables 264.0 GiB pinned and unevictable, plus 145.7 GiB page cache left over from loading the 476 GiB checkpoint

The results for this recipe are very nice, and definitely would make me suggest to anyone buying a DGX Station that they definitely put an RTX Pro 6K in there too.

decode throughput vs concurrency

tok/s
C1
C2
C4
C8
C16
C32
C64
C128
general
237237
390195
603151
919115
133884
154448
152324
151812
codegen
407407
632316
909227
1079135
1879117
211266
241938
241619
large number: aggregate output tok/s across all in-flight requests · small number: aggregate ÷ clients = average per stream · general: 8K real-text input, forced 1,024-token output, effort 75 · codegen: five-turn Flask conversations, natural EOS · temp 0 · DSpark depth 5
24 active sequences: past C24 clients queue, TTFT 3.4 s at C32 and 68 s at C128 on general · DSpark accepts 2.61 of 5 drafted tokens on prose, 4.58 on code

Based on these findings, I'd say the sweet spot is serving an average of 16 concurrent requests. 32, 64, and 128 are all possible, but you get no further aggregate token gain.

Besides being fast tok/sec decode, prefill is boringly consistent, but also insanely fast:

~44Kinput tok/s
39.9K at C1 · 42.5–44.2K from C4 through C128
41.0K at 16K input · 38.8K at 64K input
~61K peak on the approximate-replay decoder lane, not this stock path
cold, zero prefix hits · includes scheduling and one decode step

These prefill speeds are exceptional. As high as 60K+ tok/sec, where normally I see 10-15K on 4x RTX Pro 6Ks.

decode · five-turn Flask codegen · aggregate tok/s 0 400 800 1200 1600 C1 C2 C4 C8 C16 GB300 · cap 16 4x RTX PRO 6000 · Andromeda, P2P 1215 975 cold prefill · 8K real text · input tok/s 33.7K GB300 9.4K 4x RTX · Andromeda 3.6× same QAD checkpoint · GB300 W4A4 · Andromeda 4x RTX A16/A4, direct P2P, ACS clear
GB300 vs a proper 4x RTX PRO 6000 rig (Andromeda, direct P2P): 3.6× ahead on prefill, ahead on decode from C4 through C16
the RTX reference is Andromeda, a proper P2P rig: same QAD checkpoint, same software, four RTX PRO 6000 with direct peer transfers and ACS cleared; clearing ACS lifted that rig from 4.9K to 9.4K prefill and 931 to 1532 tok/s peak codegen, and it even leads at C1 (317 vs 242 aggregate) before the GB300 pulls ahead from C4 through C16
our az300 RTX path is not this comparison: no P2P on this board, TP collectives host-staged over one shared Gen5 x8 uplink, 3.8K prefill and 832 peak codegen, dead flat across concurrency and input length, the signature of a transport-bound pipeline · the published Karmic Kraken run adds memory overclocks on the same cards and reports ~18K prefill and ~331 tok/s at C1, a different basis, not our measurement
GB300 caps at 16 sequences, Andromeda at 32 · GB300 prefill falls with input length, 24.6K at 16K and 21.5K at 64K, while the RTX prefill stays flat at 9.2–9.4K

Here, we can see that actually on concurrency 1, we are slightly faster locally, but then after 2-4 or more, the DGX Station begins to perform better, but the cold prefills are again staggeringly different.

And how hot did all of this get? The whole sweep carries a 2-second telemetry loop giving us 2,005 samples across the GB300, the RTX sidecar, and the Grace CPU. Peak 75 °C on the GB300 is...impressive to say the least. That's cold for a 1000+W GPU.

30 °C60 °C90 °C
sensors
idle
load avg
peak
GB300 °C
35
61
75
sidecar °C
30
50
55
Grace °C
53
68
74
module W
413
1116
1525
GPU-only W
208
897
1290
sidecar W
17
233
304
total W
428
1349
1769
module W = Grace CPU plus GB300 GPU; total W adds the RTX sidecar · temperature color: green 30 °C to red 90 °C · the GB300 idles at 35 °C, averages 61 under load, peaks at 75; the RTX sidecar never passes 55 · zero thermal slowdown events on either GPU for the entire run
measured compute = Grace + GB300 module + RTX sidecar, sampled every 2 s, 2,005 samples; not whole-machine wall power · the GB300's only clock event is its own software power cap, active on 153 of 472 samples, about a third of the run — the 1,300 W cap working as designed, not a thermal wall · for scale, four RTX Pro 6000 boards are rated up to 600 W each, 2.4 kW of card budget before the host
energy per output token, codegen: 2.24 J at C1, 1.12 J at C8, 0.59 J at C64 and C128 · general: 1.42 J at C8, 0.94 J at C32
general pf 8K cg 4K codegen 32K peak 75 GB300 °C sidecar °C Grace °C 0102030405060 minutes into the sweep · three sessions: 0–15.7 the main sweep, 18–67.2 the 32K codegen run, 68.4+ the long-input prefill checks
GB300, sidecar, and Grace CPU temperatures across the whole sweep · color scale as above (green 30 °C to red 90 °C) · each column is one minute, shaded by its hottest sample
hottest minute of the whole run is the C128 8K prefill burst at minute 12: GB300 75 °C, Grace 74 · the 22-minute codegen C128 cell rides cooler, 42 to 66 °C · the sidecar never passes 55 °C anywhere in the timeline

Okay, so it's clear the DGX Station with an RTX Pro 6K is quite enjoyable, but what about a model that runs purely on the HBM of the GB300 instead?

03The QAD Question
what QAD is, and what it does on the GB300 vs a proper RTX rig

The QAD checkpoint is local-inference-lab's GLM-5.3-Flash-NVFP4-MXFP8-CSF-QAD, revision dec48abd, 179 GB across 36 shards. CSF, the third name in the list, is the container: a lossless compression format that packs the routed experts' block scales so tightly that every original byte comes back out, and we re-inflate all 36,288 of them on the CPU at load. QAD is quantization-aware distillation.

The sales pitch of QAD is performance closer to full BF16 than NVFP4, and faster.

same checkpoint, two machines · decode rows re-measured Oct 16, sustained single-turn waves · aggregate tok/s, average per stream in parentheses
metricGB3004x RTX Pro 6K
C1347.5335.0
C2396.3 (198.2)416.0 (208.0)
C4780.5 (195.1)652.5 (163.1)
C8817.1 (102.1)866.9 (108.4)
C161215.5 (76.0)1209.2 (75.6)
TTFT, 8K input240 ms387 ms
cold prefill, 8K33.7K tok/s9.4K tok/s
cold prefill, 64K21.5K tok/s9.4K tok/s
MTP accept length3.2–3.33.2–3.3
big number: aggregate tok/s across the whole cell · in parentheses: aggregate divided by concurrent conversations, the average one stream gets · at C1 the two are the same by definition · decode rows re-measured 2026-10-16 with the same harness on both machines, on an RTX rig re-verified ACS-cleared (a reboot since the Oct 9 run had silently re-enabled it) · GB300 C16 kept from the Oct 9 published run · TTFT, cold prefill and MTP rows unchanged from Oct 9

Lately, GLM 5.3 Flash has been my favorite model, but the latest Deepseek V4.1 Flash 1017 model is probably my new favorite. That said, it doesn't appear that the GLM 5.3 Flash architecture benefits much from this machine.

The interesting thing I've found so far though is even models that aren't stellar on this machine, they're still just as good as on Pro 6Ks, but when a model works well on the GB300/DGX Station, it really flies. Let's check out a model that performs literally the best I've ever seen any model scale out in concurrency next.

04Nemotron 120B A12B
The best-scaling model I think I've ever seen

Nemotron 3.5 Super VL is a 120B-parameter hybrid MoE with 12B active per token: 512 routed experts, 22 of them active, alternating Mamba, MoE and attention blocks. NVIDIA's EA NVFP4 checkpoint fits on one GB300 at TP1/PP1 with MTP3, FP8 KV. Room for 28M KV pool. It is a vision-language model and good at agentic coding tasks. But the real incredible part is how well this model scales to extreme concurrency.

On the GB300, codegen aggregate decode goes from 524 tok/s at C1 to 7,282 tok/s at C64. That is 13.9× the throughput for 64× the concurrency, so the median stream only falls from 538 to 130 tok/s. The model is not free at high concurrency, but it is remarkably close to linear and I have just never seen a model scale this well. Most models tend to scale out decently to 16ish concurrents, but this model just keeps giving on the GB300.

Nemotron-3.5-Super-VL 120B-A12B · GB300 NVFP4 EA · codegen decode sweep, 1K-token outputs
concurrent streamsmedian per-stream decode tok/saggregate output tok/s
C1537.8524.0
C2418.1791.5
C4341.11,235.5
C8264.21,931.6
C16211.42,960.2
C32170.74,725.5
C64129.97,282.2
These are codegen speeds at concurrency. These numbers are actually insane.

Prefill is also lighting fast:

Nemotron-3.5-Super-VL 120B-A12B · codegen prefill, exact raw-token inputs, one generated token
input tokensprefill tok/snote
~8.7K51.9Klean client; our heavier client reads 13.7K because fixed TTFT overhead dominates
~68K45.8Kclean comparison; TTFT overhead is negligible
client TTFT includes scheduling, transport and the first decode step, not isolated GPU-kernel throughput · prefill is flat from 8.7K to 68K while decode is still climbing at C64

This is not the smartest model of the open source models, but the ability to work on agent swarms is exceptionally unique and this is no slouch of a model either. I plan to dig in deeper into using agent swarms with this model, and I am excited to see some of the next models from NVIDIA and if any other model provider ends up offering something like this one that scales in this way.

05Closing Thoughts
final takeaways

Obviously, compute's getting expensive and we're all sort of adjusting to a new normal of pricing, but that compute is getting expensive because it's also getting a heck of a lot more useful, especially with local models that you can run and achieve much faster performance than via APIs, protect IP, and not deal with random outages out of your control. Since having the ability to run the models shown here, I've moved almost entirely off API/frontier models for my own dev work.

With that in mind, the DGX station is a really cool offering that I would definitely recommend for professional/enterprise use. I do like my custom 4x RTX Pro 6K build, it is cheaper, but it's wires and cables going everywhere, takes up more space than this, draws more power, generates more heat, and makes more noise from fans dissipating that heat.

I will be certainly very sad to send this incredible machine back home!