There is a wave of CMP 170HX listings right now advertising "80GB VRAM" and "basically an A100", so I unlocked one and measured it properly. Posting the numbers because most of what is circulating is either marketing or repeated hearsay.
Background for anyone who missed it: the 170HX is the only CMP card built on GA100, the same die as the A100. NVIDIA crippled memory, compute and PCIe in firmware and registers rather than physically - the board carries full 16GB HBM2e stacks all along. The community unlock is a driver-level exploit, not a vBIOS flash (the vBIOS is signed, so the "just flash an A100 BIOS" advice you see around does not work).
MEASURED ON OUR CARD (device ID 10de:20c2, stock desktop chassis)
Memory ............. 8192 MiB stock -> 65536 MiB unlocked
PCIe ............... Gen1 x4 stock -> Gen2 x4 unlocked
FP32 ............... throttled -> 12.2 TFLOPS
FP16 ............... 164 TFLOPS
BF16 ............... 174 TFLOPS
Memory bandwidth ... 1263 GB/s (copy R+W)
Compute capability . 8.0
70B AWQ on this single card: 27.2 tok/s single stream, 207.2 tok/s at 8 concurrent, 58.8 GB resident.
TWO THINGS WORTH CORRECTING
Tensor cores are not disabled. This gets repeated constantly. 164 TFLOPS FP16 / 174 BF16 is about 85% of A100 once you normalise for SM count. For vLLM / AWQ / FlashAttention it behaves as a real sm_80 device.
The memory is genuinely there. An nvidia-smi screenshot proves nothing, so we wrote 58 GiB of unique patterns in 2 GiB chunks and read them back: zero corrupted chunks, no address aliasing.
Also worth noting: our card is nominally the "8GB" SKU, which the specs say is 56 SMs. It reports 70. SKU labels do not predict what you get.
WHAT THE UNLOCK DOES NOT GIVE YOU
- ECC cannot be enabled. Present in hardware, GSP will not bring it up. 64GB without ECC on long inference runs is a real risk, not a footnote.
- No NVLink at all. Tensor parallelism across cards would have to cross PCIe Gen2 x4 - an all-reduce per layer over that is hopeless. Pipeline parallelism only.
- Gen3/Gen4 is fused off in silicon. You can solder the missing coupling caps to get x16 width back, but not the link rate.
- 56 or 70 SMs against the A100's 108. Even fully unlocked that is 52-65% of A100 compute.
- The whole thing lives in a patched kernel module pinned to one driver version, needs Secure Boot off, and breaks on routine upgrades.
GOTCHA THAT IS NOT IN THE TOOL'S DOCS
On Ubuntu the stock driver installs via DKMS into /lib/modules/$(uname -r)/updates/dkms/, and the patched modules land in updates/cmpunlocker/. Both are under updates/ with equal priority and depmod picks the DKMS copy. The install looks perfectly successful, then after reboot the card reports 8192 MiB again with zero SEC2_DEBUG lines in dmesg. Cost us an evening. Fix is an explicit override:
printf 'override nvidia * updates/cmpunlocker\noverride nvidia-drm * updates/cmpunlocker\n' > /etc/depmod.d/cmpunlocker.conf
depmod -a $(uname -r) && update-initramfs -u -k $(uname -r) && reboot
Verify with modinfo -n nvidia - it must point at updates/cmpunlocker/nvidia.ko.
TELLING A 170HX FROM AN A100 BEFORE YOU PAY
Run these on a stock, unpatched driver. The unlock only works on a specially prepared kernel, so on any normal machine the card reports itself honestly.
Device ID ......... A100: 20b0 / 20b2 / 20b5 / 20f1 | 170HX: 20c2 / 2082
SM count .......... A100: 108 | 170HX: 56 or 70
PCIe max gen/width A100: Gen4 x16 | 170HX: Gen1-2, x4
ECC ............... A100: enabled | 170HX: unavailable
nvlink -s ......... A100: links present | 170HX: nothing
SM count is the most honest single indicator, and PCIe generation cannot be faked - it is a fuse plus twelve unpopulated capacitor positions on the PCB.
Full write-up with sources, plus our other notes on running LLMs on pre-Ampere hardware (V100 NVLink diagnostics, the open-driver trap on Volta, used-kit acceptance, thermals) is on GitHub: redlinedtm-jpg/vllm-v100-2080ti-recipes
Disclosure: we assemble and sell GPU servers, so this hardware passes through our hands regularly. The measurements are from our own bench and I am happy to run additional tests if anyone wants a specific number.
Curious whether anyone here has run one of these for an extended period. The thing I have no data on is long-run stability of the upper memory region without ECC.
Background for anyone who missed it: the 170HX is the only CMP card built on GA100, the same die as the A100. NVIDIA crippled memory, compute and PCIe in firmware and registers rather than physically - the board carries full 16GB HBM2e stacks all along. The community unlock is a driver-level exploit, not a vBIOS flash (the vBIOS is signed, so the "just flash an A100 BIOS" advice you see around does not work).
MEASURED ON OUR CARD (device ID 10de:20c2, stock desktop chassis)
Memory ............. 8192 MiB stock -> 65536 MiB unlocked
PCIe ............... Gen1 x4 stock -> Gen2 x4 unlocked
FP32 ............... throttled -> 12.2 TFLOPS
FP16 ............... 164 TFLOPS
BF16 ............... 174 TFLOPS
Memory bandwidth ... 1263 GB/s (copy R+W)
Compute capability . 8.0
70B AWQ on this single card: 27.2 tok/s single stream, 207.2 tok/s at 8 concurrent, 58.8 GB resident.
TWO THINGS WORTH CORRECTING
Tensor cores are not disabled. This gets repeated constantly. 164 TFLOPS FP16 / 174 BF16 is about 85% of A100 once you normalise for SM count. For vLLM / AWQ / FlashAttention it behaves as a real sm_80 device.
The memory is genuinely there. An nvidia-smi screenshot proves nothing, so we wrote 58 GiB of unique patterns in 2 GiB chunks and read them back: zero corrupted chunks, no address aliasing.
Also worth noting: our card is nominally the "8GB" SKU, which the specs say is 56 SMs. It reports 70. SKU labels do not predict what you get.
WHAT THE UNLOCK DOES NOT GIVE YOU
- ECC cannot be enabled. Present in hardware, GSP will not bring it up. 64GB without ECC on long inference runs is a real risk, not a footnote.
- No NVLink at all. Tensor parallelism across cards would have to cross PCIe Gen2 x4 - an all-reduce per layer over that is hopeless. Pipeline parallelism only.
- Gen3/Gen4 is fused off in silicon. You can solder the missing coupling caps to get x16 width back, but not the link rate.
- 56 or 70 SMs against the A100's 108. Even fully unlocked that is 52-65% of A100 compute.
- The whole thing lives in a patched kernel module pinned to one driver version, needs Secure Boot off, and breaks on routine upgrades.
GOTCHA THAT IS NOT IN THE TOOL'S DOCS
On Ubuntu the stock driver installs via DKMS into /lib/modules/$(uname -r)/updates/dkms/, and the patched modules land in updates/cmpunlocker/. Both are under updates/ with equal priority and depmod picks the DKMS copy. The install looks perfectly successful, then after reboot the card reports 8192 MiB again with zero SEC2_DEBUG lines in dmesg. Cost us an evening. Fix is an explicit override:
printf 'override nvidia * updates/cmpunlocker\noverride nvidia-drm * updates/cmpunlocker\n' > /etc/depmod.d/cmpunlocker.conf
depmod -a $(uname -r) && update-initramfs -u -k $(uname -r) && reboot
Verify with modinfo -n nvidia - it must point at updates/cmpunlocker/nvidia.ko.
TELLING A 170HX FROM AN A100 BEFORE YOU PAY
Run these on a stock, unpatched driver. The unlock only works on a specially prepared kernel, so on any normal machine the card reports itself honestly.
Device ID ......... A100: 20b0 / 20b2 / 20b5 / 20f1 | 170HX: 20c2 / 2082
SM count .......... A100: 108 | 170HX: 56 or 70
PCIe max gen/width A100: Gen4 x16 | 170HX: Gen1-2, x4
ECC ............... A100: enabled | 170HX: unavailable
nvlink -s ......... A100: links present | 170HX: nothing
SM count is the most honest single indicator, and PCIe generation cannot be faked - it is a fuse plus twelve unpopulated capacitor positions on the PCB.
Full write-up with sources, plus our other notes on running LLMs on pre-Ampere hardware (V100 NVLink diagnostics, the open-driver trap on Volta, used-kit acceptance, thermals) is on GitHub: redlinedtm-jpg/vllm-v100-2080ti-recipes
Disclosure: we assemble and sell GPU servers, so this hardware passes through our hands regularly. The measurements are from our own bench and I am happy to run additional tests if anyone wants a specific number.
Curious whether anyone here has run one of these for an extended period. The thing I have no data on is long-run stability of the upper memory region without ECC.
