[RTX 3050 Mobile] VRAM stuck at 810 MHz (P5 state / SW Power Cap) during PyTorch compute (ComfyUI)

System Environment:

  • Hardware: Lenovo IdeaPad Gaming 3 15ARH7 (Laptop)
  • GPU: NVIDIA RTX 3050 Mobile
  • OS: Replicated on CachyOS, Linux Mint, and Xubuntu (Not present on Windows)
  • Driver Version: [610.57.04]
  • Power state: Laptop plugged into AC power, ‘Performance’ profile active

Description of the Problem:
When running CUDA/PyTorch compute workloads in ComfyUI (tested across text-to-image, text-to-video, and image-to-video workflows), the NVIDIA driver incorrectly categorizes the workload and heavily throttles the VRAM clock to 810 MHz (Performance State P5).

Running nvidia-smi -q -d PERFORMANCE,CLOCK during the workload shows SW Power Cap: Active, preventing the memory from boosting to its maximum frequency. This severely cripples generation speeds.

The Workaround & Its Instability:
To test if this was a strict hardware limit, I ran a lightweight 3D application (glxgears) alongside the compute workload.

  • About 50% of the time, this successfully lifts the SW Power Cap, allowing the driver to shift the GPU to a higher P-state and max out the VRAM clocks.
  • However, even when this workaround succeeds, it only lasts for a few minutes before the driver aggressively forces the GPU back down to P5 / 810 MHz, despite both the 3D app and ComfyUI still running.

Reproduction Steps:

  1. Boot into Linux on a rtx 3050 mobile GPU.
  2. Launch a CUDA/PyTorch compute workload (ComfyUI t2i, t2v, or i2v).
  3. Observe nvidia-smi locking memory clocks to 810 MHz under SW Power Cap.
  4. Launch glxgears to force a 3D state—observe clocks either failing to boost, or boosting temporarily before aggressively throttling back down a few minutes later.

Attached Evidence:
I have attached the nvidia-bug-report.log.gz file. I specifically ran the bug report script at the exact moment the ComfyUI Workflow throttled and the driver forced the clocks back down to 810 MHz, which should capture the aggressive throttling event.

Please let me know if there are any specific module parameters or configurations I can test to prevent compute-only workloads from being aggressively throttled on rtx 3050 laptop GPUs.

nvidia-bug-report.log.gz (470.2 KB)

Update on this issue:

I’ve done some further testing and wanted to provide some new information, as this bug is broader than initially reported.

1. Expanded Scope (Not limited to ComfyUI): I have confirmed that this throttling issue is not specific to ComfyUI. The exact same bug (VRAM stuck at 810 MHz / P5 state with SW Power Cap : Active) also triggers when running AI models in:

  • Unsloth Studio

  • LM Studio

This indicates the driver is incorrectly classifying general AI/compute workloads and aggressively capping the power, rather than it being an isolated edge case with one app.

2. Driver Update: I have updated my NVIDIA Linux drivers to version 615.71.09 to see if the regression was addressed, but the same bug is still present. The glxgears workaround still occasionally lifts the cap temporarily, but it still aggressively throttles back down within a few minutes. For some reason i have also observed the gpu being limited to 33w/85w with the laptop being plugged in.

Please let me know if you need me to generate and attach a fresh nvidia-bug-report.log.gz captured during the throttling event on the 615.71.09 driver, or if you need logs specifically from Unsloth/LM Studio.

I have discovered a much more reliable workaround and critical diagnostic information regarding why the GPU gets stuck in the 810 MHz / P5 / SW Power Cap state during compute workloads:

1. Restarting nvidia-powerd Instantly Fixes the Throttle (Mid-Workload):

  • If I restart the nvidia-powerd service (sudo systemctl restart nvidia-powerd) in the middle of an active inference job in LM Studio or ComfyUI, the SW Power Cap immediately releases.

  • VRAM clock speeds immediately jump from 810 MHz to 6000MHz without needing to launch a 3D app or restart the workload.

  • This strongly indicates that nvidia-powerd (Dynamic Boost daemon) is getting stuck in a bad power state when CUDA/PyTorch compute workloads initiate.

2. Thermal Throttling Ruled Out:

  • GPU and CPU temperatures have been monitored continuously and remain completely normal/cool throughout testing. Thermal throttling is not the cause of this state.

3. Linux vs. Windows Power Behavior:

  • Windows 11: VRAM clocks easily reach maximum speeds (~5500 MHz) even when running on battery power.

  • CachyOS / Linux: VRAM clock speeds are hard-capped at 810 MHz both on AC power during compute workloads (until nvidia-powerd is restarted) and while on battery power.