by Chris DePuy, 650 Group / November 1, 2026
A two-box DGX Spark operator capped the CPU side of a GB10 pair on Friday, October 30. The operator’s post reports the peak system-on-chip temperature under a ten-core load falling from 94 to 74 degrees Celsius, at a cost of 5 percent in prefill throughput and nothing measurable in decode. The notable part, I think, is the category the measure falls into: the operator calls the cap “a fuse for when software pegs the CPU, not a performance knob” — a thermal safeguard, not a tuning dial.
Why do DGX Spark-class machines shut down before the GPU looks hot?
Because on the GB10 class, the binding thermal constraint often sits outside the GPU’s own sensor range. Measured receipts collected in mid-October across four NVIDIA developer forum threads show abrupt power-offs arriving with no log entry, no Xid code, and no out-of-memory condition, while the GPU temperature reported through nvidia-smi still read 82 degrees Celsius or below. Which mitigation fits depends on the workload: prefill-heavy long-context jobs and always-on agent hosts are the exposed profiles. As of late October 2026, the receipts point to pairing clock caps on both sides with logging of the SoC thermal zones.
NullBurn: the CPU cap as a fuse. The Friday post came from an operator running DeepSeek-V4.1-Flash-1017 on two DGX Sparks. The operator pinned the Cortex-X925 performance cores at 2808 MHz, down from 3900, while the A725 efficiency cores stayed at stock settings, keeping the GPU lock at the nvidia-smi -lgc 0,2000 setting already in use. The recorded deltas: SoC peak under a 10-core CPU load fell from 94 to 74 degrees Celsius; 32K-token prefill moved from 2082 to 1984 tokens per second, a 5 percent cut; four-way concurrent decode moved from 95.3 to 94.6 tokens per second, inside noise. The stated mechanism is that on this platform both prefill and decode lean on the GPU and on memory bandwidth, so the 28 percent cut to CPU-only throughput carried almost no inference cost — the cap matters only when software pegs the CPU.
The mid-October forum round: four measured failure modes. A compilation posted by a community member on October 17 gathered four first-hand reports from the NVIDIA developer forums, all on GB10-class machines. One documented Nemotron-3.5-Super-VL-120B-A12B running NVFP4 with LiLiCorr speculative decoding on a single Spark at 34–49 tokens per second decode, with hard power-offs at context depths of 32K and above arriving with no preceding log entry, no Xid code, and no out-of-memory condition, while nvidia-smi showed the GPU at 82–85 degrees Celsius in the second before the cutoff. A second report on an eight-month-old unit logged the hottest /sys/class/thermal zone at 95.2 degrees Celsius against a peak GPU reading of 82 degrees, with software thermal slowdown counters accumulating 242.9 seconds and software power capping near 1,199 seconds in a monitored 2.1-hour window during 122B-class inference. A third report from a ThinkStation PGX recorded the hottest ACPI thermal zone climbing from 69.1 to 97.8 degrees Celsius in roughly 20 seconds at about 85 watts, followed by a shutdown well below the 104.8-degree critical trip point the zones expose. A fourth documented a Gigabyte AI TOP ATOM stuck at 500–800 MHz SM clocks with every throttle-reason flag at zero, unaffected by reboots, cleared only after the AC adapter sat unplugged.
The compiler’s own practice. In the reply carrying his summary of the round, the same community member reported his own control pair: nvidia-smi put the GPU at 81 to 85 degrees Celsius while, at the same moment, the hottest /sys/class/thermal zone had already reached 93 to 96 degrees. He runs two Sparks with GPU clocks locked at 1800 MHz, reports no sustained cooling pressure, and recommends recording the thermal-zone temperatures alongside nvidia-smi output for anyone running long jobs — the two scales diverge exactly where the shutdowns occur.
The detector lane. The stuck-clock thread doubled as a tooling post: its author published a detector that runs a roughly 15-second matrix multiply and samples clock, power, and throttle state, returning one of three verdicts — stuck below 1000 MHz under load with no throttle reasons, healthy at 1400 MHz or above, indeterminate otherwise — scheduled by a boot timer because the author needed eight hours to notice the fault by hand. A separate read-only diagnostic CLI, Spark Doctor, collects system, GPU, memory, Docker, runtime, and network data in one command and applies DGX Spark-specific rules, with the project’s own examples naming the GPU stuck in a low-power state and thermal shutdowns among the recurring faults.
The receipts do not settle the root causes. The monitored thread’s own author notes the USB-C PD controller firmware moved from 0x00000507 to 0x00000516 in mid-October and states plainly that he does not know whether the update is related, and the stuck-clock author lists power delivery or PD negotiation as an open root-cause hypothesis. What the week establishes is an operator practice: cap both sides of the package, log both temperature scales, and run a detector at boot, because on this hardware the last 20 degrees hide on the CPU side of the die. As firms such as 650 Group have been tracking in their AI infrastructure research, thermal headroom on desk-side GB10-class machines is becoming a first-class capacity-planning variable next to memory and token throughput.