DGX Station GB300: Day One — Delivered, Debugged, and Talking
The NVIDIA DGX Station GB300 (Exxact-built, MSI XpertStation WS300 chassis) came off a freight pallet this morning. By evening it was serving GLM-5.3 Flash from local NVMe at 141 tokens/second with a 2.7-million-token KV cache. The middle of that sentence contains a dead power button, a misidentified video port, a missing kernel module, and ten failed container launches. Day one, honestly told.
The Hardware
| Component | Spec |
|---|---|
| Superchip | NVIDIA GB300: Blackwell Ultra GPU with 288 GB HBM3e (269 GB visible to CUDA) + 72-core Grace Neoverse-V2, coherent 744 GiB total |
| Add-in GPU | RTX PRO 4000 SFF (70 W, 4× mini-DP 2.1b) — display/console only, hidden from Docker by DGX OS |
| Storage | 1.9 TB NVMe RAID (md0) |
| OS | DGX OS — Ubuntu 24.04.4, kernel 6.17-nvidia-64k, arm64 |
| Power | Dedicated 20 A circuit; ~146 W GPU idle, 613 W observed during model load |
First Power: Three Small Panics
The dead button. Rear rocker on, front button did nothing. This is normal: the BMC takes its time coming up, and the machine announces readiness by suddenly spinning fans and lighting up on its own schedule, not yours. If you're setting one of these up: wait, don't mash.
The USB-C monitor that can't work. The chassis USB-C ports are data, not DisplayPort-alt-mode. Video comes only from the RTX card. And the tiny port near the BMC Ethernet is a 1024×768 management console — not where your monitor goes.
The port that wasn't mini-HDMI. The RTX PRO 4000 SFF has four mini DisplayPort connectors that look deceptively like mini-HDMI. A JetKVM needs HDMI in, so the console path is mini-DP → active mini-DP-to-HDMI adapter → JetKVM. Know the logo difference before you order cables.
The GPU That Wasn't There
First nvidia-smi: couldn't communicate with the NVIDIA driver. The factory image was built on kernel 6.17.0-1018 with matching NVIDIA modules, but an update had installed kernel 1031 — without the 1031 driver modules. The machine booted a kernel that had never met its GPU.
sudo apt-get install -y linux-modules-nvidia-595-open-6.17.0-1031-nvidia-64k
sudo rebootOne package, one reboot, and both GPUs appeared — the B300 showing 256,703 MiB of HBM. If your Station's GPU is missing, check ls /lib/modules/$(uname -r)/kernel | grep nvidia before anything else.
Serving GLM-5.3 Flash: Ten Launches to First Token
Target: LibertAIDAI/GLM-5.3-Flash-NVFP4 (195 GB, revision-pinned) from our Milo-Ark archive, copied to local NVMe over 10GbE at 2.3 GiB/s peak. The model is too new for every released serving stack, and each launch failed one layer deeper:
| Attempt | Wall hit |
|---|---|
| Recipe-pinned SGLang v0.5.16 image | transformers too old for glm5_next |
| + upgrade transformers | qwen3_asr AutoConfig registration collision (both SGLang and new transformers claim it) |
| sglang:latest release | No native Glm5Next model — generic Transformers backend dies on MLA TP plan (mla_kv_a_proj) |
| SGLang main branch | Same — GLM-5.3 support not merged yet |
| PR #36507 (glm-5.3-flash-support) + latest transformers | Loaded. Served. Done. |
Notable dead end: the checkpoint bundles no remote code (auto_map: null), so --trust-remote-code can't save you — and its config.json claims transformers_version: 5.16.0, a version that does not actually know the architecture. The quantizer ran a dev build. Trust nothing but the load succeeding.
The working stack is frozen as a local image (glm53-nvfp4-sglang:gb300-v1) so restarts skip the whole saga, and the full receipt — image digests, PR commit f6d43097, launch command, failure ledger — is archived alongside the weights.
First Words
Day-One Benchmarks
Operational probes against the live OpenAI-compatible endpoint, run on-box (localhost, no LAN in the path), streamed with usage accounting. TTFT counts the first delta of any kind — this is a thinking model, so waiting for visible content would overstate prefill. Cold prefill uses a nonce at the start of the prompt to defeat prefix caching. These are probes, not a formal harness run.
| Probe | Result | Notes |
|---|---|---|
| Decode, 1 stream, 512 tok | 141.8 tok/s | Three runs, all 141.8 — deterministic scheduler |
| Cold prefill, 8,197 tok | 0.89 s TTFT ≈ 9,200 tok/s | nonce-prefixed, max_tokens=2 |
| Cold prefill, 32,495 tok | 1.17 s TTFT ≈ 27,700 tok/s | a full novella of context in ~1 second |
| 4 concurrent streams | 372 tok/s aggregate, TTFT 0.43 s | 93 tok/s per stream |
| 8–32 concurrent streams | ~220 tok/s aggregate, TTFT ~15 s | unexplained throughput cliff — see below |
The honest anomaly: beyond 4 concurrent streams, aggregate throughput plateaus near 220 tok/s and time-to-first-token jumps to ~15 seconds — a consistent, suspicious number that smells like CUDA-graph capture or scheduler behavior for unseen batch sizes rather than a hardware limit. Untuned day-one server flags; not yet investigated. The single-digit-concurrency numbers are the trustworthy ones today.
What's Proven, What Isn't
Proven: hardware healthy end-to-end; GLM-5.3-Flash-NVFP4 serves from a revision-pinned archive snapshot; decode/prefill probes above; reproducible container image with full provenance.
Not yet: DFlash2 speculative decoding (should raise interactive speed well past 142 tok/s), long context beyond 32k, tool-calling smoke, any formal harness (Terminal-Bench etc.), the concurrency-cliff investigation, and wiring the endpoint into the Hermes fleet.
Provenance: all figures measured September 1, 2026 on the machine described, SGLang PR #36507 at f6d43097 on lmsysorg/sglang:latest base, transformers 5.16.1, driver 595.84, CUDA 13.2. Probe scripts and the runtime receipt live in the Milo-Ark archive next to the weights. Related: the Milo-Ark model archive this model shipped from.