Undervolting and power limits
From CMP Wiki
More actions
Two levers decide how much power a CMP 170HX burns: the power cap, which every card has, and the undervolt (a V/F offset), which only some VBIOS versions allow. Most owners serve at 140 to 200 W. This page covers both, plus the HBM clock, which changes power and heat as well.
What undervolting means on this card
- Undervolting is not lowering the clock. It shifts the V/F curve so the same frequency runs at a lower voltage. On this card it cuts power by up to 30 to 35 %. Source: @wakeupmbrc1, 2026-10-12 At a lower clock a bigger offset is usually stable. Source: @sojun80, 2026-10-07
Source: @wakeupmbrc1, 2026-10-12 - In practice you raise the V/F offset (in MHz) and cap the clock with
nvidia-smi -lgc; the card then reaches the capped clock at a lower voltage. On the 170tune reference card +250 MHz with a 1,400 MHz ceiling ran bf16 tensor GEMM at stock speed (186.5 against 184.3 TFLOPS) at 142.2 W instead of 199.2 W (29 % less), and the undervolt cut power 24.4 % (174.6 to 132.0 W) at a fixed 1,350 MHz. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04 (MIT license) - It is per card. Unlocked SMs and memory that were fused off as weak may not hold the same voltage as the factory parts, so step the offset up and find each card's limit. Source: @_orrorin, 2026-10-12
- The A100 PCIe cannot be undervolted and sits at its 300 W limit on compute-bound work; that is a large efficiency edge for the 170HX. Source: @wakeupmbrc1, 2026-10-14
Before you start
- Check your VBIOS. Read it with
nvidia-smi --query-gpu=index,vbios_version --format=csv. The V/F offset is only exposed by some versions:- 8 GB, 300 W VBIOS 92.00.6D.00.0A: NVML offset range -1000 to +1000. (branch fbpa-first-active) Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @rh3dai, 2026-10-04 (MIT license; fork of cachenetics/170tune)
- 8 GB, 250 W VBIOS 92.00.67.00.01: range [0..0]. The set fails and reads back 0, and 170tune's gate still reports GATED because it tests whatever the card runs. Source: repo github.com/PixelML/club-170hx by PixelML on GitHub, posted by @c133, 2026-10-20 (Apache-2.0 license)
- 10 GB VBIOS 92.00.66.00.02: range [0..+0], so there is no SM undervolt lever; max SM clock 1,410 MHz. Source: repo github.com/vektorprime/170tune by vektorprime on GitHub
- An offset call can return success while the driver drops it; only a readback proves it applied. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub On Ivan's cards a miner's own core-offset call failed with "an internal driver error". Source: @darkmaniac7, 2026-10-28 (lab notes)
- Contested Many Discord owners run offsets of +150 to +270 without saying which VBIOS they have Source: @cibernox, 2026-10-07
Source: @rh3dai, 2026-10-08; check yours before you assume it works.
- Unlock first. 170tune needs the cmpunlocker memory unlock that opens the FBPA privilege masks, the kernel option
iomem=relaxed, NVML and a CUDA toolkit; reference driver 610.43.03.sudo 170tune preflightchecks all of it. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub Some unlock builds leave the masks closed and preflight fails ("FBPA privilege masks (unlock)"); see Troubleshooting. Source: @rh3dai, 2026-10-04
Source: @drew_2, 2026-10-12 - Know your fuse map before tuning the memory clock. Warning On two of Ivan's eight cards, which have FBPA0 fused off (one dead HBM stack each, read with matstatman/gpcprobe), a memory-PLL tuning driver build made the card fail at boot, because the PLL tools write FBPA0. Another unlock lineage runs those cards fine. Source: @darkmaniac7, 2026-10-27 (lab notes)
Steps with 170tune
These are the commands from the 170tune README; read 170tune explain first. Gate one card at a time.
Source: repo github.com/cachenetics/170tune by cachenetics on GitHub
git clone https://github.com/cachenetics/170tune && cd 170tune
sudo ./install.sh # builds the helpers, installs to /usr/local/bin
sudo 170tune preflight # card, driver, unlock, iomem access, stock clock
sudo 170tune snapshot-stock # this card's stock values as its revert baseline (once)
sudo 170tune gate 250 1400 4 --workload /path/to/your-serving-check.sh # offset +250, ceiling 1400 MHz, 4 sweeps
sudo 170tune persist save --offset 250 --clk 1400 # refuses without a passing gate receipt
sudo 170tune persist enable # re-applies after boot; the card still boots stock first
sudo 170tune persist status
- Start lower than +250. Several owners passed 170tune's gate and still saw errors days later: @cibernox went from +250 to +150 on one card Source: @cibernox, 2026-10-07; @ichundes lowered his offset by 50 Source: @ichundes, 2026-10-07. A slow ladder (30 MHz steps on the V/F shift) is what @wakeupmbrc1 suggests. Source: @wakeupmbrc1, 2026-10-14
- Gate at the temperature you will serve at. 170tune's default gate temperature is 60 C; PixelML serves at HBM 72 to 75 C and gated at 75 C. Gates soak at 300 W and 170tune's recover path sets 250 W, so re-apply your power cap afterwards. Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
- Back out with
170tune persist disableorsystemctl mask 170tune-persist.service; the card boots stock either way. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub - Other tools: the LACT curve editor accepts V/F curves that 170tune refuses, such as a curve from 210 MHz up to 1,695 MHz. Source: @vcore2191, 2026-10-07
Signs the undervolt is too deep
Back off by 50 MHz and retest if you see any of these:
- Proven
Xid 48"uncorrectable ECC error ... in GPC0 GCC" withXid 172"Uncorrectable SRAM error in GPC 0", thenXid 13Graphics Exception killing the vLLM worker. Lowering the offset by 50 fixed it Source: @ichundes, 2026-10-07; a second owner stopped daily errors the same way (+250 to +150). Source: @cibernox, 2026-10-07 With ECC on, the engine crashes instead of producing garbage. Source: @ichundes, 2026-10-07 - Gibberish output once or twice a day; gone after +250 to +150. Source: @cibernox, 2026-10-07
Xid 31. Source: @wakeupmbrc1, 2026-10-12Xid 13on the weakest SMs after a long soak, thenXid 43(+280 and above under a 200 W cap on the 170tune reference card; +300 and +350 profiles pass cool benchmarks and fail under long serving). Source: repo github.com/cachenetics/170tune by cachenetics on GitHub- Random crashes on a multi-card model: suspect the weakest card. @cibernox's GLM-5.3-Flash failures stopped after he eased the undervolt on one of four cards. Source: @cibernox, 2026-10-06
Source: @voidgiraffe, 2026-10-06
See Troubleshooting for Xid meanings.
Power limits
sudo nvidia-smi --persistence-mode=1
sudo nvidia-smi -i 0 --power-limit=150 # per card; omit -i for all cards
nvidia-smi --query-gpu=index,power.draw,power.limit,temperature.gpu,temperature.memory --format=csv
Source: repo github.com/PixelML/club-170hx by PixelML on GitHub (per-card form: Source: @xeax, 2026-10-15)
- A driver reload or a guest reboot resets the cap to the VBIOS default (250 W on most 8 GB cards), and services can overwrite it after boot. Set it from a unit that runs after everything else and check the live value. Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
- A power cap bounds heat whatever the workload does; a clock ceiling does not. 170tune recommends a cap for any box you cannot watch. (power-cap-curve.md) Source: repo github.com/cachenetics/170tune by cachenetics on GitHub
- Draw goes above the cap in short spikes: up to 380 W on cards capped at 250 W Source: @n2dcrypt, 2026-10-05; over a 185 W cap during long 1M-token prefills Source: @c133, 2026-10-09; one card drew 260 W at a 250 W cap Source: @moliminous, 2026-10-19. Size PSUs for the spikes (Power supplies and cabling).
- Reported Lowering the cap fixed instability: five cards on an external GPU switch board dropped off PCIe on large prompts until the cap went from 250 W to 180 W. Source: @moliminous, 2026-10-19 See Troubleshooting.
- A cap is also the fix for poor cooling: 135 W while without proper fans Source: @wakeupmbrc1, 2026-10-07; 200 W when a card hits 85 C Source: @xeax, 2026-10-15. See Thermal limits.
- Check for hardware power-brake slowdown with
nvidia-smi -q | grep -A1 'HW Power Brake Slowdown'. Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
Caps people serve at
| Cap | Who and what | Source |
|---|---|---|
| 110 to 165 W | four-card GLM-5.3-Flash TP4 sweep; 140 W chosen | Source: repo github.com/PixelML/club-170hx by PixelML on GitHub |
| 140 W | DeepSeek V4.1 Flash on four cards, TP4 | Source: repo github.com/CurtisAccelerate/DeepSeekv41-Flash-1017-EXL3-CMP170HX by CurtisAccelerate on GitHub, posted by @anon33anon, 2026-10-20 (license in repo) |
| 150 W | four cards, GLM-5.3-Flash TP with P2P on a consumer desktop | Source: @domrockt2, 2026-10-15 |
| 160 W | nine and ten-card rigs | Source: @reala7096, 2026-10-05 |
| 170 W | one card, Qwen 3.8 27B w8a8 and w8a16 in vLLM | Source: @programmer_007, 2026-10-15 |
| 175 W | the 170tune efficiency knee for unattended serving | Source: repo github.com/cachenetics/170tune by cachenetics on GitHub |
| 180 to 210 W | four cards "work perfectly fine if tuned properly" | Source: @wakeupmbrc1, 2026-10-04 |
| 180 W | Morrowmake's GLM-5.3-Flash recipe on stock cards | Source: @wakeupmbrc1, 2026-10-16 |
| 180 to 230 W | Ivan's eight-card server, set by an inlet-temperature governor (see Chassis builds) | Source: @darkmaniac7, 2026-10-28 (lab notes) |
| about 202 W | four cards with 170tune --ndiv 66 --offset 270 --clk 1410 --timings "REFRESH 24" |
Source: @rh3dai, 2026-10-08 |
| 200 W | four cards, +200 offset, clock 1,500 MHz, stock memory clock | Source: @alanoo, 2026-10-14 |
| 230 W | 18 water-cooled cards at +210 to +240 offset, about 1,455 MHz | Source: @rh3dai, 2026-10-14 |
| 300 W | four cards on one 1,600 W PSU | Source: @okrasit., 2026-10-05 |
| 150 to 180 W, rarely above 200 W | seven cards on a mining rack; an apartment breaker sets the ceiling, and above that the returns are minimal unless the cards are loaded all the time | Source: @munisix, 2026-10-25 |
| 200 W | four cards for inference are "perfectly fine if properly undervolted and tuned" | Source: @wakeupmbrc1, 2026-10-25 |
- @wakeupmbrc1 holds that GA100 is much more energy efficient for inference than GB202 (the RTX PRO 6000) in memory bandwidth per watt. Source: @wakeupmbrc1, 2026-10-25
Source: @wakeupmbrc1, 2026-10-25 @siriusrhi plans to start his cards at 200 W and go to 250 W once his wiring is fixed. Source: @siriusrhi, 2026-10-25
Measured watts against throughput
Four cards, GLM-5.3-Flash TP4
Reported PixelML, 2026-10-02, HBM at 1,728 MHz on all cards, cap set live, structured output:
| Cap per card | 1 user tok/s | 8 users tok/s | GPU power, 4 cards | 8-user tok/s per W |
|---|---|---|---|---|
| 165 W | 418.6 | 822.4 | 650 W | 1.27 |
| 150 W | 418.0 | 816.5 | 582 W | 1.40 |
| 140 W | 412.7 | 814.2 | 537 W | 1.52 |
| 130 W | 394.9 | 785.9 | 517 W | 1.52 |
| 120 W | 374.4 | 756.5 | 476 W | 1.59 |
| 110 W | 340.1 | 706.8 | 436 W | 1.62 |
| 100 W | 291.9 | 627.4 | 398 W | 1.58 |
At 150 W every card sits on the cap at about 1,320 MHz, yet 165 W adds only 0.1 to 1.1 %: decode waits on memory and on the four-way synchronization. Below 130 W the core clock falls fast (1,290 to 1,050 MHz). At 165 W the HBM ran 82 to 83 C; the card with the worst airflow reached 80 to 85 C core on long prefill at 180 W. (power and heat table) Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
One card, Qwen3.8-27B-FP8, offset +250
Reported 170tune reference card (8 GB, 300 W VBIOS), vLLM 0.26.0 with MTP:
| Cap | Sustained clock | Prefill (6.6k tokens) | Decode, one stream | Decode per request, 6-way load |
|---|---|---|---|---|
| 150 W | about 918 MHz | 1,421 tok/s | about 60 tok/s | 45 tok/s |
| 175 W | about 1,140 MHz | 1,712 tok/s | about 78 tok/s | 60 tok/s |
| 200 W | about 1,320 MHz | 1,929 tok/s | about 87 tok/s | 62 tok/s |
| 250 W | about 1,490 MHz | not measured | about 94 tok/s | not measured |
175 W is the knee: decode under load is flat from 175 to 200 W while the HBM runs about 6 C cooler. A 10-minute 6-way soak at 200 W held HBM at 84 to 85 C and the GPU at 78 C with zero Xids. Sustained clock against cap at +250: 250 W 1,490 MHz; 230 W 1,419; 200 W 1,291; 180 W 1,104; 150 W 901; 120 W 560; 110 W 517. (power-cap-curve.md) Source: repo github.com/cachenetics/170tune by cachenetics on GitHub Source: repo github.com/cachenetics/170tune by cachenetics on GitHub At 24 concurrent requests on Qwen3.6-27B INT8: +200/1,200 MHz under a 200 W cap gave 303.0 decode and 2,329 prefill tok/s at 149 W (2.03 tok/s per W); +250/1,400 MHz under 300 W gave 342.9 and 2,669 at 178 W. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub
Eight cards, sustained compute load at fixed caps
Reported Ivan's server, four cards per run, stock clocks, fans at 20 % (a proof-of-work miner as the load, not an LLM): 180 W was the best point. 150 W cost 13 to 22 % of throughput for 17 % less power; locking the clock at 1,200 MHz at 180 W cost 1 to 5 %; the miner's own core-offset option did not apply. At the same 180 W two of the four cards ran 81 to 84 C and the other two 58 to 68 C, depending on the slot. Source: @darkmaniac7, 2026-10-28 (lab notes)
HBM clock (NDIV) and refresh
Memory clock = NDIV x 27 MHz. Stock NDIV is 54 (1,458 MHz) on the 8 GB 250 W VBIOS, 64 (1,728 MHz) on the 8 GB 300 W VBIOS and 45 (1,215 MHz) on the 10 GB card. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub Raising it costs power and heat; lowering it saves both.
- Proven NDIV 70 is the usual ceiling: @alanoo's four cards do 70, maybe 72, and fail at 74. Source: @alanoo, 2026-10-14 Hynix memory usually goes from 54 to 68 to 70. Source: @wakeupmbrc1, 2026-10-12 170tune qualifies NDIV 70 for serving only with HBM at or below about 76 C; NDIV 72 corrupts as it heats; 74 to 76 crash on the first real load. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub
- Contested What it buys depends on the workload. @alanoo found zero gain on real MoE loads up to NDIV 72 and runs stock memory Source: @alanoo, 2026-10-14; on dense Qwen 3.8 27B NDIV 54 to 70 gave +10.5 % at one stream Source: @wakeupmbrc1, 2026-10-14, NDIV 70 gave 3 to 4 % token generation for @fnerdman Source: @fnerdman, 2026-10-14, and about 5 % decode for @reala7096 Source: @reala7096, 2026-10-08. 170tune: single-stream decode is not bandwidth bound, so the memory overclock buys nearly nothing there Source: repo github.com/cachenetics/170tune by cachenetics on GitHub. PixelML raised two slow cards to NDIV 64 and gained 5.8 to 6.3 % single-user and 3.1 to 3.8 % eight-user decode on GLM-5.3-Flash TP4. Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
- Warning Never change NDIV under an active CUDA context: it wedges the GPU (Xid 45/119) and needs a power cycle. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub
- Contested @markshowa found NDIV cannot be changed at runtime and has to be set at boot Source: @markshowa, 2026-10-26; 170tune changes it live with no CUDA context open, and the idle p-state settings switch between an idle and a busy NDIV (see P-states and idle power). Source: repo github.com/cachenetics/170tune by cachenetics on GitHub
- Lower NDIV for heat: NDIV 45 with REFRESH 24 saves heat with no loss on a proof-of-work load; raise it again for LLM work. Source: @markshowa, 2026-10-26
- Refresh interval is an idle-power lever: at NDIV 76, REFRESH 24 cut idle from 41.0 to 34.9 W and load from 78.7 to 67.7 W with flat bandwidth; under a serving load it saves only about 2.5 % (206 against 201 W). Keep stock refresh if HBM goes above 85 C. Source: repo github.com/vektorprime/170tune by vektorprime on GitHub
- Theory Headroom: @zorg33 thinks most cards can reach 1.9 to 2.0 TB/s with NDIV and timing tuning, which would put TP4 decode near 550 to 600 tok/s. Source: @zorg33, 2026-10-06
10 GB cards
- Reported After the SM unlock the 10 GB card is power bound. @djpandaman's card at 122 SMs hit the power cap and lost memory bandwidth even with the clock locked at 1,095 MHz; there was no difference between 108 and 122 SMs, and it capped even at 94 SMs. Source: @djpandaman, 2026-10-12
Source: @emogop, 2026-10-12 - The 10 GB VBIOS has no SM offset range (see above), so the usual undervolt does not apply. Source: repo github.com/vektorprime/170tune by vektorprime on GitHub
- Contested Can a fully SM-unlocked 10 GB card be undervolted? The question came up after @djpandaman's 122-SM card spiked to about 400 W at a 250 W limit (see Power supplies and cabling#PSU sizing). In the order posted:
- @djpandaman could not set the GPU clock by hand on that card the way he sets the memory clock, though he did not try hard, and presumes the SM clock is dynamic. Source: @djpandaman, 2026-10-23
- @wakeupmbrc1: set a GPU curve offset, so the card holds the same frequency at a lower voltage. Source: @wakeupmbrc1, 2026-10-23
Source: @wakeupmbrc1, 2026-10-23 - The 170tune fork reads the offset range of the 10 GB VBIOS 92.00.66.00.02 as [0..+0] (the bullet above). Source: repo github.com/vektorprime/170tune by vektorprime on GitHub
- Safe power limits for fully SM-unlocked cards are not known yet. Source: @xeax, 2026-10-23
- Contested What to do about it:
- @wakeupmbrc1: undervolting is necessary, and a shunt mod, better with the four unpopulated power phases soldered in (DrMOS, chokes, caps). Source: @wakeupmbrc1, 2026-10-12 Untested in the posts. Theory
- Asked whether he added power phases or limits power, @scallion_9883 said he swaps in the 300 W power curve from the 8 GB overclock VBIOS. Source: @globalapathy, 2026-10-16
Source: @scallion_9883, 2026-10-16 - @djpandaman: "seemingly solved" by a method @lxtend found; details are not in the imported posts. Source: @djpandaman, 2026-10-17
- Warning @xanthefin advises against the 300 W VBIOS: a photo of a burned 170HX was posted earlier, and the board lacks some power-delivery parts of the full layout. Source: @xanthefin, 2026-10-18 The photo itself is not in the imported history.
- Theory @matstatman found an unreleased "high power mode" that can be enabled even on 8 GB cards; he does not know what it does and will not release it. Defective-marked HBM may simply run too hot. Source: @matstatman, 2026-10-20