NVIDIA SW Power Cap: power limiting or thermal throttling?

SW Power Cap means NVIDIA’s software power-management mechanism is limiting clocks to respect a power limit. It does not, by itself, establish overheating or a defective card. Thermal slowdown and external power braking have separate reason fields. Read those alongside the workload evidence before deciding what to change.

This guide interprets official documentation checked on October 19, 2026, using a generic test bench. No event trace, temperature fault or counter interval was measured for this article. The arithmetic example below is deliberately hypothetical. For measured cap-selection results, use the separate NVIDIA power-limit guide.

Separate power, thermal and external-brake reasons

NVIDIA’s NVML definitions distinguish the mechanisms below. The final column proposes a diagnostic question; it is not a conclusion from a captured run.

Reported reason	Documented category	Question to investigate
SW Power Cap	Software power-limit action	Was the intended limit applied, and did useful throughput change?
SW Thermal Slowdown	Software thermal action	What do the available GPU/memory temperatures and limits show?
HW Thermal Slowdown	Hardware thermal action	What thermal evidence and cooling checks are needed?
HW Power Brake	External power-brake assertion	What does the card/system documentation require checking?

A power-limit reason is not interchangeable with a thermal reason. NVML’s software-thermal definition includes GPU and memory temperature limits; one available temperature reading is not a complete diagnosis. Use the fields supported by the actual device.

For external power braking, NVIDIA gives a system power supply as an example of a source. The flag alone does not prove that a PSU is faulty. Preserve the surrounding evidence and follow the relevant hardware guidance rather than replacing a component from this label alone.

Start with a read-only view

The nvidia-smi manual documents query output and comma-separated display selections. This query requests performance, power and temperature information:

nvidia-smi -q -d PERFORMANCE,POWER,TEMPERATURE

These are documented query examples, not commands whose output we recorded on the bench. With multiple GPUs, keep each device’s results separate; the tool’s -i selector can target a device. Do not accidentally compare a flag from one card with a counter from another. Planning the hardware too? Start with the recorded two-GPU build and slot map.

For a proposed observation, record the hardware under test, driver/tool version, workload and relevant settings. Observe while that workload is running. A reading taken after it finishes can describe a different state. Preserve workload throughput or completion evidence too, since a reason flag does not measure useful work.

Some fields depend on device and environment support. NVIDIA documents unavailable data as N/A; that is missing evidence, not a measured zero. Check the query help supplied with the installed tool:

nvidia-smi --help-query-gpu

Do not treat the absence of a field as proof that its event never occurred.

A current flag and a duration counter answer different questions

A current event reason describes the state at the time of observation. A duration counter describes time accumulated under a named reason. NVIDIA documents the clock-event counters in microseconds. A previously accumulated duration can remain relevant history without showing what is active at the instant of a later query.

Where the installed query help and hardware support these fields, the documented counter-query form is:

nvidia-smi --query-gpu=clocks_event_reasons_counters.sw_power_cap,clocks_event_reasons_counters.sw_thermal_slowdown --format=csv

For a proposed interval check, read the relevant counters before and after a workload window on the same device, recording the actual elapsed time. Keep the device and driver context uninterrupted. Do not assume an undocumented counter lifetime or reset epoch.

If the later reading is lower, the device/context changed, or a value is unavailable, do not calculate an interval percentage from those readings. Start a new observation with a valid baseline. A current inactive flag also does not reconstruct every event between observations.

A hypothetical counter-delta example

The following numbers are invented arithmetic inputs, not copied driver output or a benchmark. Assume a 20-second observation window, with a counter reading 2,000,000 microseconds before and 7,000,000 after.

The SI micro prefix means one millionth, so the conversion is:

Counter time (seconds) = (after − before) ÷ 1,000,000
Window share (%) = counter time ÷ elapsed window × 100

Before counter	After counter	Delta	Counter time	Window	Window share
2,000,000 µs	7,000,000 µs	5,000,000 µs	5 s	20 s	25%

That is 5 seconds associated with the named reason during the assumed window. It is not 25% application slowdown, GPU utilisation, or a prediction of how many tokens a different power limit would produce. There is no throughput measurement in these inputs.

Do not add reason-counter percentages into a performance-loss total. They do not partition application execution into exclusive causes of lost work. If application performance matters, compare comparable useful output and elapsed time, not just reason durations.

For an Ollama comparison, keep model residency beside the clock readings: our RTX 3060 Ti vs RTX 2060 results separate fully resident runs from CPU-offload runs.

Choose a next check before changing the limit

If model capacity is the real constraint, choose between a GPU desktop and a unified-memory mini PC. For a slim workstation, the low-profile GPU guide tackles the separate space-and-power decision.

For software power limiting, first ask whether the intended limit is applied and whether the workload meets its performance requirement. Seeing the reason under a deliberate cap does not establish that a change is needed. The measured cap-selection guide addresses that separate trade-off on its named card and workload.

For thermal reasons, inspect available temperatures, reported limits and the cooling evidence during the workload. This guide supplies no universal temperature threshold. For external power braking, use the system/card documentation and correlated evidence rather than assuming that raising a software limit will remove it.

If a workload runs inside a VM or another container architecture, establish which operating system owns the GPU and its driver. The Proxmox versus Docker architecture guide explains that boundary; an observation from the wrong layer may not describe the intended device context.

Keep a record of the observation, proposed change and repeated workload result. A diagnostic report can identify a limiting mechanism; an application test establishes whether the change actually helped. Neither a current flag nor the hypothetical percentage above supplies a measured performance gain.