170tune

Reported 8 GB and 10 GB

170tune is a tuning and qualification harness for the CMP 170HX: SM clock ceiling and undervolt (clock offset), live HBM memory clock, DRAM timings and refresh, each gated by a hot full-VRAM write and read-back plus a bit-exact compute check. It applies settings live over BAR0, with no driver rebuild or VBIOS flash, so the card always boots stock. It is built around the card's failure mode: silent memory corruption. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04.

Upstream: https://github.com/cachenetics/170tune (Cachenetics, commits by studebaker8, MIT). Last commit 2026-09-28.
Fork with 10 GB support: https://github.com/vektorprime/170tune, branch fbpa-first-active (2026-10-07), meant to pair with https://github.com/vektorprime/cmpunlocker branch fbpa-pll-170tune. Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @rh3dai, 2026-10-04.

Requirements

A CMP 170HX: 0x20C2 (8 GB, 64 GB unlocked) or 0x2082 (10 GB, 40 GB unlocked); any other device is refused. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04.
The cmpunlocker memory unlock, reference driver 610.43.03, iomem=relaxed on the kernel command line, NVML and a CUDA toolkit to build the sm_80 probes, root. sudo 170tune preflight checks all of it. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04.
Warning The unlock must open the right register window. The live memory clock tool reads and writes the unicast FBPA0 PLL window (0x00903c7c / 0x00903c98). An unlock that only opens the broadcast window (asm64-hooligan's cmpunlocker opens only 0x009a3c7c) makes those reads return a PRI error (0xBADF...), and preflight reports the window as fenced. Use a cmpunlocker lineage that 170tune targets, or set the memory clock with the unlock's driver bake (--mclk-ndiv=N) and do not use 170tune's live memory clock. A driver built with --mclk-ndiv is refused by 170tune. Source: @rh3dai, 2026-10-04
Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04. Which unlock builds open which window is on Driver unlock.

What it found on the reference card

All numbers are from one 8 GB card on the 300 W VBIOS (92.00.6D.00.0A), PCIe Gen2 x4. The authors insist you qualify your own card. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04.

Memory clock = NDIV x 27 MHz. Stock points, detected automatically: 10 GB card NDIV 45 (1215 MHz), 8 GB 250 W VBIOS NDIV 54 (1458 MHz), 8 GB 300 W VBIOS NDIV 64 (1728 MHz). The two 8 GB VBIOS variants cannot be told apart by PCI ID; STOCK_NDIV=<n> overrides.
Serving default: SM offset +250 with a 1400 MHz ceiling, HBM NDIV 70, REFRESH 24, fan driven by HBM temperature: +10 percent read bandwidth with zero Xids as long as HBM stays at or below about 76 C. NDIV up to 76 (+19 percent) is bench only: NDIV 72 corrupts as it heats past about 75 C, 74 to 76 crash on the first real load.
SM offsets +300 and +350 pass cool benchmarks and then fault in a long serving soak with Xid 13 on weak SMs; under a 200 W cap +280 and +290 threw Xid 13 then Xid 43. Serving-qualified offsets on this card: +200 and +250.
Stock BF16 tensor GEMM 184.3 TFLOPS at 199.2 W; +250 at 1400 MHz gives 186.5 TFLOPS at 142.2 W (29 percent less power at stock performance). Stock HBM read 1679 GB/s.
Single-stream decode is not bandwidth bound, so the HBM overclock buys almost nothing there. A 175 W cap is the efficiency knee for unattended serving.

Rules from its changelog

Warning

Never change NDIV while a CUDA context is active: the GPU wedges (Xid 45 or 119) and needs a power cycle.
Drive the GPU fan from HBM temperature whenever the card serves.
Four or more hot sweeps are the gate. Two clean sweeps once shipped a profile that later returned memory errors.
nvidia-smi reports 1728 MHz at every NDIV. Read the real value with 170tune -i N status.
An NVML clock-offset write can return success while the driver drops it; only a read-back proves it applied. A 150 W power ceiling on some cards is a VBIOS value that neither 170tune nor cmpunlocker changes.

Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04.
Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @rh3dai, 2026-10-04.

Persistence

170tune persist save writes a receipt that binds the card serial, PCI ID, driver and VBIOS; a driver or VBIOS change invalidates it. persist enable installs a one-shot systemd unit that applies the settings after the driver loads, and 170tune-bootcheck.service reverts to stock if the previous boot's apply never checked in. To undo: 170tune persist disable or systemctl mask 170tune-persist.service. Select cards with -i N or --gpu N. Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04.

10 GB card

Only on the vektorprime fork branch fbpa-first-active, which finds the PLL window through the first live memory partition instead of FBPA0 and stops reporting 10 GB tuning that never applied. On the test 10 GB card (VBIOS 92.00.66.00.02) the GPC clock-offset range is [0, +0], so there is no SM undervolt, and the SM clock tops out at 1410 MHz. NDIV 55 corrupted on the first sweep and wedged the card; NDIV 50 passed a 4-sweep screen and gave +14.2 percent read bandwidth over stock (1418 GB/s measured stock read). Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @rh3dai, 2026-10-04.

Experience in the Discord

Contested Offsets differ per card. The reference card serves at +250. @cibernox ran the 170tune stability gate at +250, found his card unstable in practice, and settled on +150. Source: @cibernox, 2026-10-07 @ichundes followed the full procedure including workload tests and still saw sporadic errors on a 2-card box, with no way to tell which card. Source: @ichundes, 2026-10-07
Preflight fails with "FBPA privilege masks". @rh3dai hit [FAIL] FBPA privilege masks (unlock). Source: @rh3dai, 2026-10-04 @drew_2 got the same with the latest cachenetics/170tune on amoghmunikote master, and again with the vektorprime pair. Source: @drew_2, 2026-10-12 @vektor_prime's first question: are you on the fbpa-pll-170tune branch? Source: @vektor_prime, 2026-10-08 On @rh3dai's 36 cards, all but one tuned on the vektorprime build on the first try. Source: @rh3dai, 2026-10-11
The HOT pass on water. Water-cooled cards whose HBM stays at 45 to 50 C never reach the hot gate's threshold, so the HOT pass never completes. Source: @rh3dai, 2026-10-07
Source: @rh3dai, 2026-10-14
LACT accepts more. The LACT curve editor sets voltage and frequency curves that 170tune refuses, for example a curve from 210 MHz up to 1695 MHz. Source: @vcore2191, 2026-10-07
Idle settings. @robbbbbb7973's idle gate output (driver 610.57.04, VBIOS 92.00.6D.00.0A): IDLE_CLK=210 IDLE_NDIV=30 COOL_REFRESH=24 IDLE_REFRESH=48 BUSY_NDIV=64 BUSY_REFRESH=6 COOL_C=60 HOT_C=63; his three cards idle at 23, 25 and 26 W. Source: @robbbbbb7973, 2026-10-10
Source: @robbbbbb7973, 2026-10-11
No combined build yet. @gnasherrr asked for a fork that does both P2P and 170tune; nobody named one. Source: @gnasherrr, 2026-10-26