Is your GB10 stuck in low-power mode? A 45-second check, and the fix
Field note + free tool · measured on our 8-node GB10 cluster (7× ASUS Ascent GX10, 1× NVIDIA DGX Spark)
Two of our eight GB10 machines spent days running at less than half speed without telling anyone. Every model on them was slow, nothing was in the logs, and every diagnostic said the GPU was fine. If you've been up late wondering why your Spark is suddenly slower than everyone else's numbers, this may be why.
The signature: under full load the GPU sits around 500–850 MHz and ~20 W instead of ~2,300 MHz and ~90 W, utilization still reads ~96%, and no throttle reason is reported. A normal reboot doesn't clear it, and nvidia-smi -lgc is accepted and ignored.
1. Run the 45-second check
First, stop anything else using the GPU (model servers, training, ComfyUI). A busy GPU gives a falsely low score. The script warns you if it sees other GPU processes.
Step 1: download it on the GB10 you want to test (or download gb10_clockcheck.py and copy it over):
curl -O https://anantus.org/tools/gb10_clockcheck.pyStep 2 (optional): check it's the genuine file. The result should match this SHA-256 exactly:
sha256sum gb10_clockcheck.py
# 17e80f05f489142eab72998c48d2c01da215030f4a34032e69d66a0b65127cfcStep 3: see if PyTorch is installed on the machine itself:
python3 -c "import torch; print(torch.cuda.is_available())"Step 4a: if that printed True, run it directly:
python3 gb10_clockcheck.pyStep 4b: if it printed an error or False, run it inside the container you already use for vLLM or PyTorch (replace YOUR_IMAGE with that image's name; docker images lists them):
docker run --rm --gpus all --entrypoint python3 \
-v "$PWD":/w YOUR_IMAGE /w/gb10_clockcheck.pyThe test runs for about a minute (warm-up plus 45 seconds) and then prints the result. One file, about 160 lines, MIT license.
Privacy: the script runs entirely on your own machine. It makes no network connections, sends nothing anywhere (not to us, not to anyone), collects nothing and writes no files. It runs a bf16 matrix multiply on your GPU for 45 seconds and reads nvidia-smi locally, nothing else. We checked it with a Python audit hook and with strace: zero network connections. Read it before you run it; it's short.
It prints your throughput (TFLOP/s), median clock, power and throttle reasons, then a verdict: HEALTHY, OK (lower-power chassis), or LIKELY STUCK.
2. Compare with healthy and stuck units
| unit (same 45 s bf16 8192³ test) | throughput | clock under load | power |
|---|---|---|---|
| ASUS Ascent GX10, healthy (7 units) | 88.8–93.7 TFLOP/s | 2,275–2,333 MHz | ~89–92 W |
| NVIDIA DGX Spark, healthy (1 unit) | ~77 TFLOP/s | same silicon, lower chassis power envelope | |
| ASUS Ascent GX10, stuck (2 units) | 42.5 TFLOP/s | 851 MHz | 20.7 W |
Other brands (Dell, HP, MSI, Gigabyte, Lenovo…) may sit lower or higher than the GX10 when healthy, like the DGX Spark does. The stuck state is far below all of them: if you're well under ~60 TFLOP/s with a low clock and no throttle reason, it's almost certainly the stuck state, not your chassis.
3. The fix: a full power drain, in this exact order
A reboot leaves the power hardware energized, so the stuck state survives it. You have to fully drain power, including the external power brick:
- Shut the unit down completely.
- Unplug everything: the power cord from the wall outlet, the cord from the power brick (the little converter box), and the brick's cable from the back of the unit. Unplug USB devices too.
- Leave everything disconnected for at least 5 minutes.
- Reconnect in this order: the cord into the wall outlet first → then into the power brick → then the brick's cable into the back of the unit last.
- Power on and run the check again.
The order matters. If the unit is reconnected before the power brick has fully reset, the brick may not reset, and the stuck state can come back. On our two units this sequence restored 93.5 and 95.3 TFLOP/s (~2.2 GHz, ~88 W), and both were still healthy in a full-cluster test ten days later.
4. Still stuck after the drain?
Other owners report needing longer drains (up to several hours), and a few units haven't recovered. Contact your vendor, and add your numbers to the NVIDIA forum thread where an NVIDIA moderator is collecting cases: forums.developer.nvidia.com/t/386060. That thread's author also maintains a broader open-source GB10 forensics toolkit (blackbox) with a stuck-clock detector of its own; this script is a standalone single-file check plus our reference numbers.
Help us grow the reference table
Ran the check? Reply in the forum thread with your score and your unit's brand and model, or email contact@anantus.net, and we'll add your chassis to the table so the next owner knows what "healthy" looks like for their machine.
Healthy clock, but still slower than it should be?
The stuck clock is one of several silent GB10 slowdowns we've root-caused. Book a one-day diagnostic: we reproduce your setup on our 8-node lab and hand you the measured before/after.
Book a 1-day diagnostic →Free to read, use and share. Numbers are from hardware we've measured directly; your unit will differ, so measure your own.