> ## Documentation Index > Fetch the complete documentation index at: https://docs.tokios.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel. > Use 'connector' for the local tokios-connector process. > Use 'deployment' for the public model name in the API model field. > Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend. > API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-. # CMP 170HX unlock guide: 64 GB HBM2e for $250-800 > Unlock the NVIDIA CMP 170HX mining card from 8 GB to 64 GB HBM2e. Vix Loader method (no flashing), benchmarks, and setup requirements. The NVIDIA CMP 170HX is an Ampere GA100 mining card that ships artificially capped at 8 GB VRAM. The full 64 GB HBM2e can be unlocked, giving you 732-1,100 GB/s bandwidth and 74 SMs for \$250-800 — the most compelling budget story in local LLM inference. > [!WARNING] > > **Unsupported path**: This guide documents a community-discovered unlock method. NVIDIA may patch it in future drivers. The card has no display outputs, passive cooling (requires directed airflow), and is not covered by warranty for this use case. Proceed only if you accept the risk and enjoy tinkering. > [!NOTE] > > Last verified: 2026-10-21. Driver versions and unlock methods may change. Check the [Panchovix Vix Loader repo](https://github.com/Panchovix/nvidia-windows-vbios-vix-loader) and [PixelML club-170hx community](https://github.com/PixelML/club-170hx) for the latest information. ## What is the CMP 170HX? The CMP 170HX is NVIDIA's Cryptocurrency Mining Processor based on the Ampere GA100 GPU — the same architecture as the A100 datacenter card. NVIDIA artificially limited the card to 8 GB VRAM and disabled display outputs to comply with export controls and segment the market. **Hardware specs (before unlock):** * GPU: Ampere GA100 (74 SMs) * Memory: 8 GB HBM2e (artificially capped) * Bandwidth: \~732 GB/s (limited by capped memory) * TDP: 250W * Interface: PCIe 4.0 x16 * Display outputs: None * Cooling: Passive (requires server chassis or custom fans) **After unlock:** * Memory: 64 GB HBM2e (full capacity) * Bandwidth: 732-1,100 GB/s (varies by workload) * All 74 SMs active * Full CUDA support > [!TIP] > > **Why HBM2e matters:** High Bandwidth Memory (HBM2e) is the same technology used in A100 and H100 datacenter cards. It delivers 2-3x the bandwidth of GDDR6X at lower power. For LLM inference, memory bandwidth is the bottleneck — HBM2e gives you datacenter-class performance at mining-card prices. ## Unlock methods There are 2 primary unlock methods: 1. **Vix Loader (Windows, recommended)**: No-flashing unlock via registry keys. Fully reversible. 2. **Linux kernel patching**: For server deployments. Requires Proxmox VE or bare-metal Linux. ### Method 1: Vix Loader (Windows, no flashing) The Vix Loader method loads a modified VBIOS via Windows registry keys without permanently flashing the card. It's fully reversible and the safest option. **Requirements:** * Windows 10/11 (64-bit) * NVIDIA driver 616.56 or later * CMP 170HX card * Administrator privileges **Steps:** 1. **Install NVIDIA driver 616.56 or later** Download from [NVIDIA's driver portal](https://www.nvidia.com/Download/index.aspx). Do not use DDU (Display Driver Uninstaller) — the unlock relies on specific driver state. 2. **Download Vix Loader** Clone or download from [Panchovix/nvidia-windows-vbios-vix-loader](https://github.com/Panchovix/nvidia-windows-vbios-vix-loader). 3. **Run the Vix Loader script** Open PowerShell as Administrator and run: ```powershell theme={"theme":{"light":"github-light","dark":"css-variables"}} .\vix-loader.ps1 ``` The script modifies registry keys to load the modified VBIOS at boot. It does not flash the card. 4. **Reboot** After reboot, the card reports 64 GB HBM2e. Verify with: ```powershell theme={"theme":{"light":"github-light","dark":"css-variables"}} nvidia-smi ``` You should see: ``` +-----------------------------------------------------------------------------+ | NVIDIA-SMI 560.xx Driver Version: 560.xx CUDA Version: 12.6 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 CMP 170HX Off | 00000000:01:00.0 Off | 0 | | N/A 45C P0 50W / 250W | 0MiB / 65536MiB | 0% Default | +-------------------------------+----------------------+----------------------+ ``` 5. **Verify the unlock** Run a CUDA sample or inference workload to confirm the full 64 GB is accessible: ```powershell theme={"theme":{"light":"github-light","dark":"css-variables"}} python -c "import torch; print(torch.cuda.get_device_properties(0).total_memory / 1e9, 'GB')" ``` Should output: `64.xxxxx GB` **Reversibility:** To revert to stock 8 GB mode, run: ```powershell theme={"theme":{"light":"github-light","dark":"css-variables"}} .\vix-loader.ps1 --revert ``` Then reboot. The card returns to factory 8 GB configuration. ### Method 2: Linux kernel patching (servers) For headless server deployments, the Linux method patches the NVIDIA kernel module to expose the full 64 GB. This is more permanent than Vix Loader but requires more setup. **Requirements:** * Linux (Ubuntu 22.04 or 24.04 recommended) * NVIDIA driver 550.xx or later * Kernel headers and build tools * CMP 170HX card **Steps:** 1. **Install prerequisites** ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} sudo apt update sudo apt install build-essential linux-headers-$(uname -r) git ``` 2. **Install NVIDIA driver** Download and install the latest NVIDIA driver from [NVIDIA's Linux driver portal](https://www.nvidia.com/en-us/drivers/unix/). Do not use the `nvidia-driver-xxx` package from Ubuntu repos — you need the runfile installer. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} wget https://us.download.nvidia.com/XFree86/Linux-x86_64/560.xx/NVIDIA-Linux-x86_64-560.xx.run sudo sh NVIDIA-Linux-x86_64-560.xx.run ``` 3. **Clone the unlock repository** ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} git clone https://github.com/PixelML/club-170hx.git cd club-170hx ``` 4. **Apply the kernel module patch** The community maintains patches for specific driver versions. Check the repo for the latest patch that matches your driver: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} ls patches/ # Output: 550.120.patch 550.144.patch 560.28.patch ... ``` Apply the patch: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} sudo ./apply-patch.sh 560.28 ``` This patches the NVIDIA kernel module to expose the full 64 GB. 5. **Reboot and verify** ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} sudo reboot nvidia-smi ``` Should show 65536 MiB (64 GB). **Community recipes:** The [PixelML club-170hx repo](https://github.com/PixelML/club-170hx) maintains tested configurations for: * Single-card setups * 4x CMP 170HX in a single workstation * 8x CMP 170HX in a mining rig chassis * Proxmox VE passthrough Check the `recipes/` directory for step-by-step guides for each configuration. ## Performance benchmarks Community benchmarks show the unlocked CMP 170HX delivers datacenter-class performance at mining-card prices. ### Single-card performance | Model | Quantization | Memory usage | tok/s | Notes | | - | - | - | - | - | | Llama 3.1 8B | Q4\_K\_M | 4.5 GB | \~60 | Entry-level benchmark | | Qwen3 14B | Q4\_K\_M | 8.5 GB | \~55 | Mid-size dense model | | Qwen3.6-35B-A3B | Q4\_K\_M | 20 GB | \~70 | 35B MoE, 3B active | | Qwen3 70B | Q4\_K\_M | 40 GB | \~45 | Fits with 24 GB headroom | | Qwen3 70B | Q8 | 70 GB | \~35 | Higher quality, tight fit | | GLM-4.5-Air | Q4\_K\_M | 53 GB | \~40 | 106B MoE, 12B active | > [!TIP] > > **HBM2e bandwidth advantage:** The 732-1,100 GB/s bandwidth puts CMP 170HX in the same class as A100 (1,555 GB/s) and faster than RTX 4090 (1,008 GB/s). For memory-bound workloads (large batch sizes, long context), CMP 170HX outperforms consumer cards despite lower raw compute. ### Multi-card performance The real power of CMP 170HX is in multi-card configurations. PCIe 4.0 x16 (64 GB/s per direction) is the bottleneck, not the cards themselves. | Configuration | Total VRAM | Model | tok/s | Notes | | - | - | - | - | - | | 4x CMP 170HX | 256 GB | GLM-5.3-Flash | 816 (aggregate) | Community-reported, 204 tok/s per card | | 4x CMP 170HX | 256 GB | DeepSeek V4-Flash-0731 | \~120-150 (estimated) | Mixed FP8+MXFP4, needs validation | | 8x CMP 170HX | 512 GB | GLM-5.2 | \~30 | 753B params at 4-bit, tight fit | | 8x CMP 170HX | 512 GB | Qwen3.5-397B | \~45-60 (estimated) | 397B MoE at Q4, needs validation | > [!WARNING] > > **PCIe bottleneck:** 4x CMP 170HX in a single workstation saturates PCIe bandwidth. Tensor parallelism over PCIe is 10-20% slower than NVLink. For maximum throughput, use 2x cards with NVLink (if supported) or accept the PCIe overhead. ### Comparison to other hardware | Hardware | VRAM | Bandwidth | Price | 70B Q4 tok/s | \$/GB | | - | - | - | - | - | - | | CMP 170HX (unlocked) | 64 GB HBM2e | 732-1,100 GB/s | \$250-800 | \~45 | \$4-12 | | Tesla V100 (used) | 32 GB HBM2 | 900 GB/s | \$400-600 | \~70 | \$12-19 | | Tesla P40 (used) | 24 GB GDDR5X | 346 GB/s | \$150-250 | \~35 | \$6-10 | | RTX 3090 (used) | 24 GB GDDR6X | 936 GB/s | \$700-900 | \~118 | \$29-38 | | RTX 4090 | 24 GB GDDR6X | 1,008 GB/s | \$1,600-2,000 | \~120 | \$67-83 | | RTX 5090 | 32 GB GDDR7 | 1,792 GB/s | \$1,999 | \~162 | \$62 | | RTX PRO 6000 | 96 GB GDDR7 | 1,792 GB/s | \$16,000 | \~140 | \$167 | > [!TIP] > > **CMP 170HX is 5-10x cheaper per GB than consumer cards.** At \$4-12/GB, it's the most cost-effective path to 64+ GB VRAM. The trade-off is no display outputs, passive cooling, and an unsupported unlock path. ## Setup requirements Running unlocked CMP 170HX cards requires attention to cooling, power, and chassis selection. ### Cooling CMP 170HX ships with passive cooling — no fans on the card. It relies on airflow from the chassis. **Single card in a workstation:** * Add a custom fan shroud (3D-printed or acrylic) to direct airflow over the heatsink * Use a 92mm or 120mm fan mounted to the card's heatsink * Target: 20-30 CFM airflow over the card **Multi-card (4x or 8x):** * Use a mining rig chassis with integrated fans * Or a 4U server chassis with high-CFM fans (e.g., Norco RPC-4224) * Target: 50+ CFM per card, with intake/exhaust balance > [!WARNING] > > **Thermal throttling:** Without adequate cooling, CMP 170HX throttles at 85°C. Community reports show 60-75°C with proper airflow. Monitor temperatures with `nvidia-smi -q -d TEMPERATURE` and adjust fan speeds if needed. ### Power Each CMP 170HX draws up to 250W under load. **Single card:** * 1x 8-pin PCIe power connector (or 12VHPWR with adapter) * 750W+ PSU recommended (headroom for CPU, storage, fans) **4x cards:** * 4x 8-pin PCIe power connectors (or 12VHPWR) * 1,600W+ PSU recommended (4x 250W = 1,000W + headroom) * Use a PSU with multiple 12V rails or a server PSU with breakout board **8x cards:** * 8x 8-pin PCIe power connectors * 2,500W+ PSU (or dual PSUs) * Mining rig chassis with integrated power distribution ### Chassis **Single card:** * Standard ATX workstation case works * Ensure adequate airflow (front intake, rear exhaust) * Add custom fan shroud for directed cooling **4x cards:** * 4U server chassis (e.g., Rosewill RSV-L4411U, Norco RPC-4224) * Or a workstation case with 4x full-length PCIe slots (e.g., Fractal Design Define 7 XL) * Check PCIe slot spacing — some motherboards have slots too close for blower-style coolers **8x cards:** * Mining rig chassis (e.g., Antminer S9, or open-frame mining rigs) * Or a rack-mount server with PCIe risers * Requires PCIe bifurcation support on motherboard (x16 → 2x x8 or 4x x4) ### Software stack **Recommended OS:** * Linux (Ubuntu 22.04 or 24.04) for production serving * Windows 10/11 for Vix Loader unlock method * Proxmox VE for virtualized multi-card setups **Inference backends:** * **vLLM**: Production-grade, concurrent batching, best for API serving * **SGLang**: High-throughput, RadixAttention for prefix caching * **llama.cpp**: CPU+GPU offloading, GGUF quantization, flexible * **Ollama**: Simplest setup, single-user, good for experimentation **Multi-card serving:** * Use tensor parallelism (TP=4 or TP=8) to split models across cards * vLLM and SGLang support tensor parallelism natively * PCIe bandwidth is the bottleneck — expect 10-20% overhead vs NVLink ## Common issues and troubleshooting ### Issue: Card still shows 8 GB after unlock **Cause:** Vix Loader script did not apply correctly, or driver version mismatch. **Fix:** 1. Verify driver version: `nvidia-smi` should show 616.56 or later 2. Re-run Vix Loader script with administrator privileges 3. Check Windows Event Viewer for errors 4. Try a different driver version (560.xx series is well-tested) ### Issue: Thermal throttling under load **Cause:** Insufficient airflow over the card. **Fix:** 1. Add a 92mm fan directly to the card's heatsink 2. Increase chassis intake fan speed 3. Lower power limit: `nvidia-smi -pl 200` (reduces TDP from 250W to 200W) 4. Undervolt the card (advanced): Use `nvidia-smi --set-gpu-voltage-offset` to reduce voltage ### Issue: PCIe bandwidth bottleneck in multi-card setup **Cause:** 4x or 8x cards saturate PCIe bandwidth. **Fix:** 1. Use fewer cards (2x instead of 4x) for better per-card throughput 2. Upgrade to a workstation/server motherboard with PCIe 5.0 (2x bandwidth) 3. Accept the 10-20% overhead — it's still cheaper than NVLink solutions 4. Use pipeline parallelism instead of tensor parallelism (less inter-GPU communication) ### Issue: Out-of-memory (OOM) on large models **Cause:** Model + KV cache exceeds 64 GB. **Fix:** 1. Use lower quantization (Q4 instead of Q8) 2. Reduce `--max-model-len` to limit KV cache size 3. Use `--gpu-memory-utilization 0.90` to reserve 10% for overhead 4. Offload layers to CPU: `--cpu-offload` in llama.cpp ### Issue: NVIDIA patches the unlock in a future driver **Cause:** NVIDIA releases a driver update that blocks the Vix Loader or kernel patch. **Fix:** 1. **Do not update drivers** until the community confirms the unlock still works 2. Pin your driver version: `sudo apt-mark hold nvidia-driver-xxx` 3. If already updated, check the [Panchovix repo](https://github.com/Panchovix/nvidia-windows-vbios-vix-loader) or [PixelML club-170hx](https://github.com/PixelML/club-170hx) for a new patch 4. As a last resort, revert to stock 8 GB mode (Vix Loader `--revert`) > [!WARNING] > > **Driver updates are the biggest risk.** NVIDIA has not publicly acknowledged the unlock, but they could patch it in a future driver. Pin your driver version and monitor the community repos for updates. Do not auto-update drivers on production CMP 170HX systems. ## Is CMP 170HX right for you? **Choose CMP 170HX if:** * You need 64+ GB VRAM on a budget (\$250-800) * You enjoy tinkering and accept the unsupported path * You're comfortable with Linux or Windows command-line setup * You need HBM2e bandwidth for memory-bound workloads * You're building a multi-card inference server **Avoid CMP 170HX if:** * You need display outputs (use RTX 3090/4090 instead) * You want a plug-and-play experience (use RTX 5090 or Mac Studio) * You need warranty support and professional drivers (use RTX PRO 6000) * You're uncomfortable with the risk of NVIDIA patching the unlock * You need low power consumption (250W per card is not efficient for small models) ## Next steps > **[Hardware reference](/guides/hardware-reference.md)** > > Compare CMP 170HX against consumer GPUs, RTX PRO, and unified memory platforms. > **[RTX PRO Blackwell variants](/guides/rtx-pro-blackwell-variants.md)** > > Professional alternative: RTX PRO 4000/4500/5000/6000 with warranty support. > **[Model sharding](/guides/model-sharding.md)** > > Configure tensor parallelism across multiple CMP 170HX cards. > **[vLLM remote access](/guides/vllm-remote-access.md)** > > Serve models from your CMP 170HX rig through Tokios. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.