I run two DGX Sparks (GB10) as a TP=2 cluster, and I’ve been planning to move them to solar so I wanted to know out of curiosity where their actual energy sweet spot is for llm inference respectively to KWh / 1 Million token metrics.
Setup: 2 x DGX Spark, TP=2 over the 200G QSFP56 link. My daily driver is DeepSeek-V4-Flash-0731 FP8 on vLLM (with speculative decoding and prefix caching), and I run it 14-16 hours a day, every day - so small per-watt differences add up fast over a month/year.
I swept 17 clock points, from uncapped (2400 MHz) down to 400 MHz, capping BOTH nodes with nvidia-smi -lgc (TP=2 runs them in lockstep, so a head-only cap measures nothing). Throughput came from vLLM’s own counters; power I read off a wall-socket meter covering the whole two-node rack - because nvidia-smi only accounts for ~12-27% of the real draw on GB10. All the power figures below are for BOTH Sparks together, not one.
The headline: uncapped is not even the fastest setting. Decode speed is basically flat across the top of the range - memory-bandwidth-bound, so raising the clock just makes the SMs wait faster:
Cap Decode tok/s Wall power Wh per 1M tokens
2400 (uncapped) 51.34 330 W 1,688
2200 51.43 274 W 1,480
1900 50.74 252 W 1,381
1700 49.80 242 W 1,350
1400 47.74 234 W 1,362
800 34.90 211 W 1,679
*The figures above are the combined power consuption of 2 sparks.
From 2400 down to ~1400 you lose a couple of tok/s while cutting wall power by ~90-100 W. The best energy ROI per million tokens is a band around 1400-1800 MHz - about 25% better than uncapped for a ~3% speed loss. Below ~1000 MHz the curve turns back up: generation itself costs ~190 W regardless of clock, so you’re just stretching that bill over more hours.
So if your sparks is running uncapped (or even above ~1800 MHz) you’re likely eating +100 W or more and getting no additional tokens for it plus the heat and occasionally the power transient that makes these boxes shut down. The cap is actually not a sacrifice in the top part of the range it’s close to a free win.
On my two-box setup that difference is not a rounding error. At 14-16 hours a day, moving from uncapped to ~1400-1700 MHz saves roughly 30-50 kWh a month for essentially no major throughput loss depending on the load profile you have. If you own 4+ Sparks running nonstop, these numbers get even more interesting especially when load is dominant.
I’m still a little disappointed my two-node setup idles at ~100-105 W with the model resident. But the flip side is that active inference now tops out around 220 W for both boxes at the sweet spot - far more economical than I anticipated, and that’s the number that matters when the nodes are actually working and under constant load.
For my pair, with four abrupt self-shutdowns in its history, I settled on 1400 MHz: same energy as the whole band within measurement noise, but the smallest power transient (the thing that actually kills the box). If you’re nervous about capping, 1800 MHz keeps ~97.5% of peak speed and is still inside the sweet spot.
Two practical notes: -lgc does NOT survive a reboot (re-apply it or you silently come back up uncapped), and always read the real clock back - the GB10 snaps to discrete steps (ask for 1200, get 1098).
Two more things worth knowing. Prefill is the one phase that does scale with clock (it’s compute-bound, not memory-bound), so in agentic loops with cold prefills 1400 MHz costs ~14% prefill throughput vs uncapped - but with prefix caching you only pay full prefill on the first turn of a session, so in practice the decode number is what you feel. And on thermals: capping barely cools the GPU (63 to 56 C over the whole range), and my head node’s SoC hot zone sits at 90-96 C at every clock - the cap leaves the Grace cores untouched, so don’t expect it to fix a heat problem, only the power transient.
