DGX Spark (GB10) GPU clock pinned at 721 MHz under full load — no throttling, not liftable via nvidia-smi

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

Summary

On my DGX Spark the GB10 GPU appears hard-capped at ~721 MHz SM clock even under 96% utilization, while the reported max is 3003 MHz. There is no active throttle reason, the GPU is cool (~55 °C) and drawing only ~10 W. nvidia-smi -lgc has no effect. I’d like to know whether this is expected behavior, a firmware/BSP issue, or something I can change via a supported power/performance mode.

System

  • Device: NVIDIA DGX Spark (GB10)
  • DGX OS: 7.5.0
  • Kernel: 6.17.0-1026-nvidia
  • Driver: 580.159.03
  • CUDA: 13.0
  • GPU: 48 SMs / 6144 FP32 cores

Symptoms

nvidia-smi under a sustained custom CUDA compute kernel:

clocks.sm clocks.max.sm utilization.gpu power.draw temp
721 MHz 3003 MHz 96 % ~10 W 55 C

  • Performance State: P0
  • Clock Event Reasons: all Not Active (Idle, SW Power Cap, HW Slowdown, SW/HW Thermal, Sync Boost all inactive)
  • All power-limit fields (Current/Default/Min/Max Power Limit) report N/A
  • Clock stays at exactly 721 MHz whether idle or at 96% utilization — it never boosts.

Throughput confirms the clock is real (not a telemetry misreport)

A high-ILP FP32 FMA microbenchmark delivers only ~3.75 TFLOPS. The theoretical peak at 3003 MHz (6144 cores × 2 × 3.003 GHz) is ~37 TFLOPS, so even accountinsistent with a genuine sub-GHz clock, not a misreported telemetry value.

What I’ve tried

  • sudo nvidia-smi -lgc 3003 → silently has no effect; clock stays 721 MHz. nvidia-smi -q -d SUPPORTED_CLOCKS
    reports Supported Clocks : N/A, so locked/ear to be supported on this part.
  • No nvpmodel, jetson_clocks, or GPU devfreq nodes are present on DGX OS.
  • Persistence mode is enabled; not runtime
  • Thermals are fine across all zones (~52–55 °C); nothing suggests thermal or power-cap throttling.

Questions

  1. Is a sustained 721 MHz cap under full load expected on GB10 / DGX Spark, or is this a defect?
  2. What is the supported way to raise the performance power mode on DGX Spark? Is itexposed through the DGX Dashboard, and if so where?
  3. Is this addressed by a firmware/BSP OTAta-update-meta 26.04.1 available and canapply it.)

Any guidance appreciated — happy to provide full nvidia-smi -q output or additional logs.

2

i had a similar issue where it was pinning at 550MHz no matter what. unplugging the power, having a coffee and re plugging the power fixed it. just make sure you unplug the USB and AC

3

Thanks for the detailed report. Your throughput measurement (~3.75 TFLOPS vs ~37 TFLOPS expected) confirms this is a real clock constraint, not a telemetry artifact. The fact that all throttle reasons are inactive and thermals/power are nominal (~55°C, ~10W) rules out the usual suspects.

A community member reported a similar issue (550 MHz pin) that was resolved by a power cycle (unplug power/USB, wait, replug). Did this workaround resolve your 721 MHz clock constraint? Please confirm the current clock behavior after the power cycle.

4

I had a same issue ,GPU clock pinned at 721MHz under full load。
And that was not resolved by a power cycle (unplug power/USB, wait-up to 8Hours , replug)。

image
image657×343 7.51 KB

image
image388×360 4.28 KB

5

If you have two units - try swapping PSU between them. I have a suspicion that it’s not Spark’s fault but PSU goes into thermal condition (they do get very hot and have no fans) and limits voltage output, throttling unit down. The power drain is not to reset unit but to resent PSU, drain capacitors and cause power management control board to reset.

6

Hello everyone,

I confirm that unplogging the Spark from power, waiting for a few minutes, and then connecting and booting the machine again resolved the issue.

So it seems to have been a power negotiation issue. In another forum post I read that this can happen after your Spark runs out of memory and freezes. This is exactly what happend to me as well.

7

Or just drain power - disconnect from socket, press power button for 10s and connect back again.
My theory is it’s not OOM being the cause, but during OOM all CPU/GPU go to 100% trying to swap, overboost power and PSU locks into safety mode and caps voltage output. Then you get low power and CX7 issues because voltage is on the lowest bound. Power drain helps to reset power control circuits in PSU. Just theory but ducks line up.