Your GB10 cluster is slower than it should be.
We make it fast.
Alongside our own AI work, we offer engineering services for NVIDIA DGX Spark and Grace-Blackwell (GB10) hardware — the platform where numbers from H100 and B200 simply don't transfer. We reproduce your exact problem on real GB10 silicon, find the root cause, and hand back a measured fix.
Measured, not marketed
Every number below is labeled with what it actually measures — decode is what your users feel, prefill is prompt ingestion, aggregate is many streams at once. Vendor numbers often mix these without saying so; we label every one. Single-stream figures are medians or n≥15 benchmarks at temperature 0, concurrency figures are single runs, decode and aggregate figures count tokens actually delivered to the client, and prefill figures count prompt tokens processed.
| workload | hardware | metric | result |
|---|---|---|---|
| ~1-trillion-parameter MoE (4-bit), 256k context | 8 nodes over an ordinary 100 Gbps switch | decode | 27.8 ± 2.3 tok/s delivered on code, single stream (mean of n=15, 95% CI) |
| ~320B MoE (GLM-5.3-Flash), up from our 47.7 tok/s entry; now on knapcio's open-source (MIT/Apache-2.0) stack with an MIT drafter and our changes | 4 GB10 nodes · 100 Gbps switch | decode | 98.8 tok/s code · 73.2 prose (n=15) |
| same model, configured for a team instead of one user | same 4 nodes | aggregate | 535 tok/s total across 128 simultaneous requests (prose; ~4 tok/s each) · worst first token 2.8 s |
| 35B-A3B MoE, tuned from a 25.5 tok/s eager-mode starting config | one GB10 node | decode | 45.2 tok/s code · 41.2 dialogue |
| large sparse-MoE, after one collective-protocol fix | 8-node cluster | prefill | 699 → 1,520 tok/s · TTFT halved |
| same class, 16 concurrent streams | same cluster | aggregate | 170 tok/s · with prefix caching, 8 agents sharing a 24k-token prefix took 5.1 s vs 342 s with unique contexts |
What we fix
Narrow on purpose: the problems we solve on our own cluster, applied to yours.
Multi-node bring-up
vLLM, SGLang, TRT-LLM. The NCCL, interconnect, and topology issues that only appear at world size > 1 — and never show up in the single-GPU tutorials.
Throughput & latency
CUDA-graph capture, speculative decoding, quantization (nvfp4 / fp8 / w4a16), KV-cache and long-context tuning, and the choice between fast-for-one-user and fast-for-a-team configs. Measured tokens/sec from paired runs on identical hardware, with confidence intervals wherever the quantity is a throughput we sample repeatedly, and a quality check on every speed change.
"It won't load"
Weight-load stalls, memory leaks, silent misconfig, aarch64 kernel fallbacks, and benchmark artifacts that make a fast system look slow.
Start with our free check: is your GB10 stuck in low-power mode? It takes 45 seconds, makes no network connections, and tells you whether a slow node is the silent half-speed power state or something that needs a deeper look. Not that? Walk the "Why is my DGX Spark slow?" checklist.
Why this is rare
Almost every published GPU-inference playbook targets x86 + datacenter GPUs at single-node scale. Grace-Blackwell is ARM64, unified-memory, sm_121 — the numbers do not transfer, and we've measured exactly where they break. Our own multi-node GB10 cluster doubles as a reproduction lab, so we can stand up your configuration and test a fix, often the same day for models already on our lab.
How it works
Low-risk to start. You never float our costs; we never waste your time.
1 · Scoped diagnostic
One problem, one or two nodes. We reproduce it on real GB10 hardware and deliver written root-cause findings plus a recommended fix. Paid up front — and if we find nothing actionable, it's free.
2 · Cluster audit
The full workup for 4–8 node and production deployments: fabric, loading, memory, serving stack, and benchmark forensics — every layer measured, every finding written up with the recoverable headroom ranked. Same guarantee.
3 · The fix
Hourly with an honest estimate, or a fixed price for a well-scoped target ("get model X to N tok/s"). Billed in advance, milestone by milestone. Ongoing retainer available for production teams.
4 · Emergency
Production cluster down or degraded and burning money? Your work goes ahead of everything else in our queue. For now the emergency channel is email: write to contact@anantus.net with "Emergency" in the subject (we don't yet have a business phone line). Minimum 4 hours.
Every engagement, same path: you write and we check fit (free) → you sign one client authorization → invoice, paid up front → the work, in our lab or through temporary access you control, every command recorded → your written report and the session record. See a sample report, written from a case on our own cluster, and the FAQ.
Bring us your slowest node.
Tell us the model, the config, and the number you're stuck at. If it's a fit, we start with the 1-day diagnostic.
Start here →Every engagement ships measurements backed by paired runs on identical hardware, with same-vs-same controls and confidence intervals wherever the quantity is a throughput we sample repeatedly. We state the protocol so you can re-run it, and restart variance is reported, not hidden.