# CMP.WIKI > The community reference for the NVIDIA CMP 170HX (8 GB and 10 GB cards): unlocks, inference recipes, platforms, cooling and power, troubleshooting and test results. Every fact is credited to the person who posted it. Text is licensed CC BY-SA 4.0. - Wiki home: https://cmp.wiki/wiki/Main_Page - Lead section of every article in one file: https://cmp.wiki/llms-full.txt - News: https://cmp.wiki/news/ (RSS: https://cmp.wiki/feed/, news sitemap: https://cmp.wiki/news-sitemap.xml) - For software that reads this site (plain text, wikitext, search, data tables as JSON): https://cmp.wiki/wiki/CMP_Wiki:For_agents - Data tables as daily JSON snapshots: https://cmp.wiki/data/index.json - MCP server for AI agents (read-only, no login, Streamable HTTP): https://cmp.wiki/mcp (Claude Code: claude mcp add --transport http cmpwiki https://cmp.wiki/mcp) - Sitemaps: https://cmp.wiki/wp-sitemap.xml and https://cmp.wiki/sitemap-wiki/sitemap-index-cmpwiki.xml ## Tools on the front door - [CMP 170HX tools](https://cmp.wiki/tools/): the hub: Setup matrix, Will it fit, Card check, Prices, Ask the wiki and the Benchmark protocol - [Setup matrix](https://cmp.wiki/setup/): pick card variant, count, memory, SMs, PCIe link, P2P and ECC; see which wiki recipes run and how fast, each speed labelled Measured, Estimated or Unknown - [Will it fit](https://cmp.wiki/fit/): memory calculator: weights plus KV cache for a model, quant, context and users against your cards, every step of the arithmetic shown - [Card check](https://cmp.wiki/check/): paste lspci, nvidia-smi and dmesg output; get the card, the unlock state, the PCIe link, the driver and what each Xid means, all in the browser, nothing uploaded - [Prices](https://cmp.wiki/prices/): every reported CMP 170HX price point by date, charted from the wiki Price log - [Ask the wiki](https://cmp.wiki/ask/): a question box that answers from the wiki pages and news posts with numbered sources (rate limited, Turnstile) ## News - [CMP 170HX news, November 6 to 9, 2026: a new DeepSeek engine, ECC on 10 GB cards, VM reports](https://cmp.wiki/news/cmp-170hx-news-november-6-to-9-2026/) (2026-11-10): The newest CMP 170HX items: the Anemone engine for four cards, an ECC boot problem on some 10 GB cards, new prices and two virtual machine reports. - [Full GLM-5.3 (753B) on eight CMP 170HX plus two Blackwells: recipe and repo published](https://cmp.wiki/news/glm-5-3-eight-cmp-170hx-two-blackwells/) (2026-11-06): A published recipe serves the full GLM-5.3 with a 524k context on eight CMP 170HX plus two RTX PRO 6000 Blackwells, building on cebeuq's eight-card recipe. - [CMP 170HX 8 GB card floorsweep: gated, not dead, and fuse-locked at 64 GB](https://cmp.wiki/news/floorsweep-8gb-gated-not-dead-fuse-locked/) (2026-11-06): A read of seven 8 GB CMP 170HX cards finds about 80 GB physically latent but fuse-locked: 64 GB and 74 SMs stay the ceiling, and 96 GB is not supported. - [CMP 170HX news, November 3 to 5, 2026: ECC without a patched driver, P2P behind switches](https://cmp.wiki/news/news-november-3-to-5-2026/) (2026-11-06): The newest CMP 170HX items: ECC shown on an 8 GB card without a patched driver, P2P behind PCIe switches, two hardware warnings and 3,000 USD cards. - [vGPU for the CMP 170HX is ready for testing, with a new cmptools repo](https://cmp.wiki/news/vgpu-ready-for-testing/) (2026-11-05): The cmpunlocker maintainer asks for vGPU testers: the driver side is on the vGPU-and-others branch and a new cmptools repo manages the vGPU settings. - [CMP 170HX news, week of November 3, 2026: NVLink, P2P, prices](https://cmp.wiki/news/news-week-of-november-3-2026/) (2026-11-03): The newest CMP 170HX items: a 10 GB NVLink rework, gpu-unlock 3.0 announced, new DeepSeek and Mistral runs, and 8 GB cards still offered at 3,350 USD. - [CMP 170HX driver warning: nvidia-open 615.78.08 breaks cmpunlocker](https://cmp.wiki/news/driver-615-78-08-breaks-cmpunlocker/) (2026-11-03): On nvidia-open 615.78.08 the CMP 170HX unlock installs cleanly but cards drop out of nvidia-smi; owners report 615.71.09 as the version that works. - [CMP 170HX 300 W VBIOS flash procedure published for the 8 GB card](https://cmp.wiki/news/300w-vbios-flash-procedure-8gb/) (2026-11-03): A tested procedure flashes the factory 300 W VBIOS onto 8 GB CMP 170HX cards, opening the undervolt range and raising the HBM clock to 1728 MHz. - [cmpunlocker v0.5 for CMP 170HX: what it unlocks and what it does not](https://cmp.wiki/news/cmpunlocker-v0-5-what-it-unlocks/) (2026-11-03): cmpunlocker v0.5 brings the 8 GB card to 64 GB and the 10 GB card to 40 GB, adds 4 SMs and ECC, and still leaves Gen3, NVLink and 80 GB locked. - [Fastest proven CMP 170HX recipes: GLM 5.3 Flash leads at 442 tok/s](https://cmp.wiki/news/fastest-proven-recipes/) (2026-11-03): Nine CMP 170HX recipes are Proven; GLM 5.3 Flash on four 8 GB cards leads at 442.1 tok/s, with seven owners reproducing it. - [CMP 170HX 10 GB memory: 40 GB Proven, 48 GB Reported, 80 GB Contested](https://cmp.wiki/news/10gb-card-memory-40-48-80/) (2026-11-03): The 10 GB CMP 170HX unlocks to 40 GB, about one card in five reaches 48 GB, and 80 or 96 GB has not been made usable as of late October 2026. - [CMP 170HX P2P and multi-card servers: what is proven so far](https://cmp.wiki/news/p2p-multi-card-servers/) (2026-11-03): BAR1 P2P between CMP 170HX cards is Proven on one root or switch, mailbox P2P is Proven since November 6, 2026 (updated), and a dual-socket server passed 504 of 504 checks. ## Start ### Start here Source: https://cmp.wiki/wiki/Start_here This wiki collects what the cmpunlocker Discord has worked out about the CMP 170HX: how to unlock it, what to run on it, and how to keep it cool and fed. There are two versions of the card and they unlock differently, so start by finding out which one you have: run lspci -nn | grep -i 10de. 10de:20c2 is the 8 GB card, 10de:2082 the 10 GB card. Not sure? Which card do I have. Every fact on this wiki links to the Discord message or repo it came from. A badge on each entry shows how far to trust it: Proven (reproduced by a second person), Reported (one person's result), Theory (untested idea), Contested (people disagree, both sides shown) or Warning (damaged hardware or lost data). See Status taxonomy. Words you do not know are in the Glossary. ### Which card do I have Source: https://cmp.wiki/wiki/Which_card_do_I_have There are two production versions of the CMP 170HX: the 8 GB card and the 10 GB card. They look the same from the outside, use the same board and the same cooler, and both unlock with cmpunlocker. They do not unlock to the same thing. Find out which one you have before you buy parts, burn fuses or pick a recipe. The short version: run lspci -nn. 10de:20c2 is the 8 GB card. 10de:2082 is the 10 GB card. If lspci -nnv shows device 20c2 with subsystem 10de:1586, it is a 32 GB card, not a normal 8 GB card. ### CMP 170HX Source: https://cmp.wiki/wiki/CMP_170HX The NVIDIA CMP 170HX is a cryptocurrency mining card built on GA100, the same die as the A100 data-center GPU. NVIDIA sold it in 2021 with most of the chip switched off. Since July 2026 the community has been switching it back on, and an unlocked card is now a 40-64 GB HBM card for local AI at a fraction of an A100's price. It exists in two versions, the 8 GB card and the 10 GB card; see Which card do I have. ### 8 GB card Source: https://cmp.wiki/wiki/8_GB_card The 8 GB card is the CMP 170HX with PCI ID 10de:20c2 and SK hynix HBM2e. It is the more common version and the one most recipes are written for. After the public unlock it is a 64 GB, 74 SM GA100 card on a PCIe Gen2 link. Not sure which card you have? See Which card do I have. New owner? Start with Start here#8gb. ### 10 GB card Source: https://cmp.wiki/wiki/10_GB_card The 10 GB card is the CMP 170HX with PCI ID 10de:2082 and Samsung HBM2e. It has less memory than the 8 GB card after unlock, but its RIR fuse records are unused, which opens a path to most of a full GA100: up to 128 SMs, PCIe Gen3 and more. Plan on 40 GB of memory; 48 GB is a lottery. Not sure which card you have? See Which card do I have. New owner? Start with Start here#10gb. ### Variant comparison Source: https://cmp.wiki/wiki/Variant_comparison The 8 GB card and the 10 GB card side by side. Prices are reported figures from the Discord on the dates given, not quotes. How to tell which card you have: Which card do I have. ## Unlocks ### 8 GB compute and HBM: limits and open questions Source: https://cmp.wiki/wiki/8_GB_compute_and_HBM:_limits_and_open_questions All eight 8 GB lab cards report 74 SMs and 64 GiB after the existing unlock. No additional usable VRAM or working SMs were demonstrated in this research. The November 10-11, 2026 evidence combines a configuration census, a read-only bridge map and offline analysis of driver/GSP 615.71.09. It does not include a fresh full-range memory test or a new performance result. Source: @darkmaniac7, 2026-11-11 (lab notes) For installation, use Driver unlock. For current priorities and the register index, return to Developer status. ### Cmpunlocker forks Source: https://cmp.wiki/wiki/Cmpunlocker_forks cmpunlocker (amoghmunikote) is the mainline. Several forks exist, each adding one thing the mainline lacks. The forks of the mainline driver are GPL-2.0 and build the same way (download the stock NVIDIA open modules, apply patches, build locally). Pick by what you need; do not stack them. Most of the forks below are snapshots from July and August 2026 that lack later mainline features such as ECC and 615.x; the fork comparison at the bottom shows what each one carries. Standalone tools that share only the name or the goal (pearlfortune, zerobitcopy, d3dx9) work differently, are not GPL builds of mainline, and are flagged in their sections. Repos that only make claims are under Unverified and fake claims. ### Driver compatibility Source: https://cmp.wiki/wiki/Driver_compatibility This page answers one question: does NVIDIA driver X with cmpunlocker version Y work on the 8 GB and the 10 GB CMP 170HX? Each row is one driver version and one outcome, built only from reports already on this wiki, and each row carries the credits of the reports it rests on. It is not a list of everything that works, not a test matrix, and not a replacement for the pages it summarizes: Driver unlock, Driver and unlock failures, Known bad combinations and Operating systems and kernels have the full story. cmpunlocker refuses any driver version not listed in its driver/VERSION file (at commit 2c7e2ec: 615.78.08, 615.71.10, 615.71.09, 610.57.04, 610.43.03, 610.43.02). Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @rh3dai, 2026-10-08 615.71.09 is the safe pick; 615.78.08 failed for several owners in October 2026. Source: @.henrykrinkle, 2026-10-20 ### Driver unlock Source: https://cmp.wiki/wiki/Driver_unlock cmpunlocker is the mainline unlock for the CMP 170HX, by Amogh Munikote (@_j3ns on Discord, GitHub amoghmunikote). It is an installer plus a set of patches against NVIDIA's open GPU kernel modules; it rebuilds nvidia.ko and friends so the card comes up with its real memory size, full SM compute throughput, PCIe Gen2, ECC, BAR1, JTAG, profiling and VFIO passthrough. It is driver-side only: nothing is flashed, nothing is burned. On the 8 GB card that is the whole story; the 10 GB card can go further with the RIR fuse burn. Source: @globalapathy, 2026-10-18 Repository: amoghmunikote/cmpunlocker (GPL-2.0; patched NVIDIA files keep their MIT / dual notices). The current release is v0.5, released 2026-10-04 (64 GB, +4 SM, ECC). Source: @_j3ns, 2026-10-04 Which NVIDIA driver works with which cmpunlocker version, on the 8 GB and on the 10 GB card, with a credit per report: Driver compatibility. ### ECC Source: https://cmp.wiki/wiki/ECC Software-based ECC landed in cmpunlocker v0.5 on 2026-10-04 and is credited to Amogh. It is one of the main reasons prices rose after the release. Source: @_j3ns, 2026-10-04 The Morrowmake P2P fork's master drops the ECC patches, but its p2p-ecc branch (commit 87cb5fd) carries both: the lab runs it with ECC Enabled on all 8 cards and P2P still passing (see Memory errors and ECC). Source: @darkmaniac7, 2026-10-27 (lab notes) ### Flashing the 300 W VBIOS Source: https://cmp.wiki/wiki/Flashing_the_300_W_VBIOS Most 8 GB cards ship with VBIOS 92.00.67.00.01, the 250 W image. On it the driver reports a GPC and memory VF-offset range of [0 .. +0], so no undervolt can be applied, whatever a tool says it set. The factory 300 W image 92.00.6D.00.0A, which NVIDIA shipped on the same board part number (900-11001-0108-000), exposes an offset range of [-1000 .. +1000], boots the HBM at 1728 MHz instead of 1458 MHz, raises the SM ceiling from 1410 to 1695 MHz, and keeps a 250 W default cap (300 W is the maximum it allows). This page is the flash procedure as run on eight cards in one night, with the numbers before and after. It does not touch the memory or compute unlock, which stays in the driver; see Driver unlock. The 10 GB card has no 300 W image (its only VBIOS is 92.00.66.00.02); this page is for 8 GB cards. See VBIOS and firmware for the full image inventory. ### Full SM unlock Source: https://cmp.wiki/wiki/Full_SM_unlock The stock card exposes 70 of 128 SMs. There are three tiers: 74 SM on both cards: cmpunlocker's +4 SM step (70 + 4). This is the ceiling for the 8 GB card. Source: @lia_oc, 2026-10-22 74 to 80 SM on the 10 GB card: software only, no fuse override needed. Source: @djpandaman, 2026-10-10 80 to 128 SM on the 10 GB card: needs EN_SW_OVERRIDE, which needs the RIR fuse burn. ### Gen2 link retrain Source: https://cmp.wiki/wiki/Gen2_link_retrain The stock CMP 170HX links at PCIe Gen1. cmpunlocker raises it to Gen2 on both cards. This is pure software (no fuse burn) and is the ceiling the mainline repo claims; Gen3 is a separate, 10 GB-only story (see PCIe Gen3 on the 10 GB card). Gen2 alone is a 2x bandwidth step over stock Gen1. Link speed (Gen1 to Gen2) and link width (x4 to x16) are separate problems. Gen2 is software; x16 width needs the hardware capacitor mod on lanes 4-15. Without the caps the maximum width is x4. Source: @djpandaman, 2026-10-17 Whether Gen2 trains depends heavily on the host: results by board, CPU, OS and kernel are on Gen2 by platform, and Gen2 inside a virtual machine is on Proxmox Gen2 passthrough. ### Kernel parameters and module options Source: https://cmp.wiki/wiki/Kernel_parameters_and_module_options Reference for every kernel command-line and nvidia module option that appears in the unlock work. The modprobe lines usually live in /etc/modprobe.d/cmp-pcie-gen2.conf (or -gen3), written by the installer; kernel-cmdline options go in GRUB or /etc/kernel/cmdline. Confirm what the running kernel actually got with cat /proc/cmdline, and what the driver actually read with grep RegistryDwords /proc/driver/nvidia/params, after every reboot. ### Memory unlock on the 10 GB card Source: https://cmp.wiki/wiki/Memory_unlock_on_the_10_GB_card The 8 GB card unlocks to a flat 64 GB (see Driver unlock). The 10 GB card is different and the ceiling is a lottery. Do not expect 80 GB. In short: 40 GB (48 GB on some cards; 80 GB not achieved). ### NVLink Source: https://cmp.wiki/wiki/NVLink NVLink is not publicly unlocked on the CMP 170HX, on either card. It is fused off and also missing board components. The 8 GB card has no NVLink path at all; the 10 GB card may be reachable with a hardware mod that is not public. Source: @lia_oc, 2026-10-22 ### P2P Source: https://cmp.wiki/wiki/P2P GPU-to-GPU P2P works on the CMP 170HX with a patched driver: the mailbox path is Proven on both cards since the October builds, and BAR1 P2P is Proven where the board opens the 64 GB BAR1 on one root complex or behind one switch. On the stock driver GSP reports PCIe P2P unsupported on the CMP, although the GA100 mailbox P2P hardware is present. P2P matters for tensor parallelism; without it, pipeline parallel is usually the better default on these PCIe-only cards. There are two paths: the mailbox (works inside the stock 64 MB BAR1; proven, see below) and BAR1 P2P (needs the 64 GB BAR1, the path most content-checked results use). Whatever you install, prove it with a content check (see Verify). ### PCIe Gen3 on the 10 GB card Source: https://cmp.wiki/wiki/PCIe_Gen3_on_the_10_GB_card 10 GB card only. It needs the permanent RIR fuse burn first. The 8 GB card cannot reach Gen3: its Gen3-disable fuse register is locked and there is no free RIR to clear it (see below). ### PCIe x16 capacitor mod Source: https://cmp.wiki/wiki/PCIe_x16_capacitor_mod The CMP 170HX trains its PCIe link at x4 because the AC-coupling capacitors on 12 of its 16 lanes were never fitted at the factory. Soldering in the 24 missing capacitors gives a full x16 link. It is the only hardware step in the usual unlock, it needs no software of any kind, and it works the same on the 8 GB and the 10 GB card. The mod changes link width only, never the PCIe generation. A modded card with no unlock installed reports Gen1 x16; with cmpunlocker it reports Gen2 x16. Generation is a separate, software problem: see Gen2 link retrain and PCIe Gen3 on the 10 GB card. ### Resizable BAR and BAR1 64 GB Source: https://cmp.wiki/wiki/Resizable_BAR_and_BAR1_64_GB The stock card exposes BAR1 at 64 MiB. cmpunlocker can resize it to 64 GB, which is what large-BAR GPU-to-GPU P2P uses. It is in the README feature table as Working, credited to asm64-hooligan (JP). Whether it actually allocates depends on the motherboard. Several cards behind one PCIe switch also need a patched host kernel (see Behind a PLX switch). ### RIR fuse burn Source: https://cmp.wiki/wiki/RIR_fuse_burn This is a permanent, irreversible fuse write. A wrong address can brick the card. It applies only to the 10 GB card (10de:2082). Do not do this unless you understand it. ### Unlock history: who found what, and when Source: https://cmp.wiki/wiki/Unlock_history:_who_found_what,_and_when A dated record of how the CMP 170HX unlock came about, from the card's launch in 2021 to the state at the end of October 2026, with credit for each finding. Dates are the dates of the Discord messages (UTC) unless a post gives another. Where accounts disagree, every side is shown with its source and no verdict. This page records who found what and when; it does not describe how the exploit works inside. How to run the unlock today is on Driver unlock, and what each feature gives is on Unlocks. ### Unlock internals: detailed research notes Source: https://cmp.wiki/wiki/Unlock_internals:_detailed_research_notes This page is for people working on the unlocks themselves. It pools what the community and the lab know at register and fuse level about the hardware NVIDIA gated on the CMP 170HX, says where each target stands, who is working on it and what the next concrete step is. It is a hub: each section is a summary, and the long form with every post and source stays on the page it links to. If you only want to unlock a card, start at Unlocks and Driver unlock instead. Three rules of thumb before the detail: Use reviewed read allowlists; some registers clear or advance state when read. Keep the driver bound when using gpcprobe. Writing fuses is permanent. On a card that cmpunlocker's passthrough service had armed, unbinding the driver to read BAR0 left the card unable to rebind until a cold power cycle. Source: @darkmaniac7, 2026-11-05 (lab notes) See HBM identity tools for the read-to-advance case. Source: @darkmaniac7, 2026-11-10 (lab notes) Disabled and defective masks identify investigation candidates; they do not prove that healthy, connected HBM is present. mrpandagod reported: "if it's marked defective I've found it's truly defective. disabled can be enabled and I haven't found any time that logic failed". Keep that experience separate from a capacity measurement. Source: @djpandaman, 2026-10-17Source: @zorg33, 2026-10-22 Source: @darkmaniac7, 2026-11-10 (lab notes) A capacity claim counts only after a dense write of address-dependent data over every reported byte and a full read-back. Writes above 40 GB on a 10 GB card completed without errors and changed the contents of the first 40 GB. Source: @lxtend, 2026-08-10 Statuses follow Status taxonomy. "Dead end" is not a status badge: it marks a route that was tried or argued down and is listed on Dead ends: what was tried and did not work. ### Unlock internals: status and what is next Source: https://cmp.wiki/wiki/Unlock_internals:_status_and_what_is_next Current baseline: 64 GiB and 74 SMs on the eight 8 GB lab cards. No further capacity or compute unlock was demonstrated in the latest research pass. For installation, use Driver unlock; for feature availability, Unlocks. ### Unlocks Source: https://cmp.wiki/wiki/Unlocks CMP unlocks is the map of what the community has restored on the NVIDIA CMP 170HX, a GA100 card that NVIDIA shipped with most of its features clamped in firmware and OTP fuses. Each unlock has its own page with steps, numbers and sources. Measured speeds for the unlocked cards are on CMP benchmarks; new unlock releases and driver warnings are posted as CMP news. There are two cards and they unlock very differently. Know which one you have first: see Which card do I have. 8 GB card (PCI ID 10de:20c2): its redundancy rows (RIR) were burned at the factory, so there is no software path past what cmpunlocker already does. It gives 64 GB of memory and 74 SM. 10 GB card (PCI ID 10de:2082): it has 16 empty RIR rows. Burning two of them clears one gate fuse, after which almost everything else (full 128 SM, PCIe Gen3, the 6th HBM stack) can be done in volatile software. It gives 40 GB (48 GB on a lucky card) but much more compute and interconnect. Source: @wakeupmbrc1, 2026-10-07 Source: @_orrorin, 2026-10-19 There is no 8 GB equivalent of the 10 GB RIR path yet, for Gen3 or anything else (2026-10-26). Froggo found no free RIRs on one of his 8 GB cards, and Humvee55 says no Ampere-era NVIDIA part except the 10 GB card will take the path. Asked when an 8 GB Gen3 unlock is coming, _L_ answered that it depends on someone finding a different way to unlock the card, and there is no clear way yet. Source: @froggao, 2026-10-22 Source: @scallion_9883, 2026-10-22 Source: repo github.com/evanrodgers/cmp-170hx-rir-burn-util by evanrodgers on GitHub, posted by @hezz1891, 2026-10-26 Source: @lia_oc, 2026-10-26 Source: @lia_oc, 2026-10-26 In short, as of November 2026: the 8 GB card goes to 64 GB and 74 SM with cmpunlocker (Proven) and has no software path beyond that; the 10 GB card goes to 40 GB (Proven, 48 GB on some cards, 80 GB not achieved) and, after the RIR fuse burn, to 128 SM and PCIe Gen3 (Proven). ECC enablement is Proven on the 8 GB card and Reported on the 10 GB card; error correction remains Contested. Mailbox P2P is Proven on both cards since the October builds and BAR1 P2P with the 64 GB BAR1 is Proven. NVLink has no path on the 8 GB card and is Theory on the 10 GB card. The table below carries every status with its source. ### VBIOS and firmware Source: https://cmp.wiki/wiki/VBIOS_and_firmware The 170HX VBIOS is signed, and the memory/compute unlock does not come from flashing a modified VBIOS; it comes from the driver patch (cmpunlocker). Most VBIOS work on these cards is either identification, power-limit editing, moving an 8 GB card between NVIDIA's own signed images, or dead ends. Treat anything that writes the flash chip as high-risk. The step-by-step flash of the signed 300 W image is on Flashing the 300 W VBIOS. ## Recipes ### All recipes Source: https://cmp.wiki/wiki/All_recipes Every recipe on the wiki: a model running on CMP 170HX cards, with the settings and the numbers. Click a column heading to sort; long values are cut to one line, hover for the full text or open the recipe. Filter by card variant: 8 GB only · 10 GB only · recipes for both · Category:Recipes for 8 GB · Category:Recipes for 10 GB. Status is computed: means someone else reproduced it (see Status taxonomy). Find a recipe for your setup: the Recipe finder filters by card variant, number of cards, model, engine, P2P, PCIe link and status, and keeps decode with one user, decode with many users and prefill apart. ### Benchmarks Source: https://cmp.wiki/wiki/Benchmarks CMP benchmarks: throughput numbers for the CMP 170HX in two tables: first one row per recipe page, generated from the recipe infoboxes, then every single measurement with the setup it was measured on and its source. The numbers depend on which CMP unlocks the cards carry (memory, SM count, PCIe link, P2P); new runs and records are posted as CMP news. Click a column header to sort. The recipe pages give the full conditions; these tables are for comparing. Measuring your own numbers: follow the Benchmark protocol and run its script, cmpbench.py, which prints the Recipe and Confirmation fields ready to paste. Read before comparing. Numbers differ by protocol and setup: Most recipe authors use the MiaAI-Lab protocol (400-token answers, temperature 0, thinking off) and report three columns, structured / code / prose. The lab's bench uses 1,024-token answers and lists code / structured / prose; rows say which order applies when it differs. "1 user" is single-stream decode in tok/s. "Many users" is aggregate tok/s across all streams, with the user count in brackets. Prefill is prompt-reading tok/s; cold unless marked warm. Prompt length is in brackets where known. Power caps (140 to 250 W), link width (Gen2 x4 or x16), P2P and the host CPU all move the numbers. Speculative decoding (DFlash2, DSpark, MTP) is on in most rows; temperature-0 benchmarks inflate draft acceptance against real use. Lab rows were measured on the lab's eight-card server and are marked "lab notes". All other rows are one person's report unless the recipe page shows a confirmation. Rows marked "repo report" copy the figure a recipe repository publishes (README or results file); it has not been re-measured here. Rows from July to September 2026 often predate the 74-SM unlock (2026-09-24) and today's engines, and the earliest predate the Gen2 retrain: compare them with care. Read #How to report numbers before you add a row. Card count is CMP 170HX 8 GB-variant cards unlocked to 64 GB unless stated. In short: the tables cover one to eight cards, both card variants, llama.cpp, vLLM, SGLang, ExLlamaV3 and the community forks, and three workloads (single-user decode, many-user aggregate decode, prefill). Most rows are one person's report (Reported); a row is Proven only when its recipe page shows a confirmation by a second person. Power cap, link width, P2P and speculative decoding move the numbers, so read the setup columns before comparing two rows. ### DeepSeek V4 Flash 0731 on 3x 8 GB (PP3 DSpark) Source: https://cmp.wiki/wiki/DeepSeek_V4_Flash_0731_on_3x_8_GB_(PP3_DSpark) DeepSeek-V4-Flash-0731 (about 284B total, 13B active) on three 64 GB cards, served by vLLM with pipeline parallel 3 and DSpark speculative decoding. The engine is the same patched build as the four-card reference recipe (DeepSeek V4 Flash 0731 on 4x 8 GB (allover326 PP4 DSpark)); the difference is the layer split, 15,15,13, and a tighter memory budget. Three cards are the smallest set that holds the official MXFP4 + FP8 checkpoint, and a fourth card mainly buys context, not speed. DeeJay runs it on three cards daily and called three cards at about $1,200 each by far the cheapest way to run the model locally. tim-odonnell's repo (posted on Discord by irythros) documents a production setup at 100 W per card: about 93 tok/s decode with a 691,968-token context. The infobox shows that repo's own readings. Source: @deejay9983, 2026-08-05 Source: repo github.com/tim-odonnell/cmp170hx-deepseek-v4-flash by tim-odonnell on GitHub, posted by @irythros, 2026-08-19 ### DeepSeek V4 Flash 0731 on 4x 8 GB (allover326 PP4 DSpark) Source: https://cmp.wiki/wiki/DeepSeek_V4_Flash_0731_on_4x_8_GB_(allover326_PP4_DSpark) The reference recipe for the first DeepSeek V4 Flash checkpoint, DeepSeek-V4-Flash-0731 (about 284B total, 13B active), not the later V4.1 (see Related). DeeJay (GitHub allover326) serves the official MXFP4 + FP8 weights on four 64 GB cards at PCIe Gen2 x4 with no P2P, using vLLM pipeline parallel 4 and DSpark speculative decoding, a combination vLLM refuses until the repo's patches enable it. The repo reports 98.1 tok/s single-stream decode, about 5,300 tok/s prefill and a verified 1,047,736-token one-shot context at 180 W per card. Several owners reproduced it on four cards (Other people's numbers, and the Confirmation pages). Infobox numbers are the repo's own readings. Source: repo github.com/allover326/deepseek-v4-cmp170hx by allover326 on GitHub, posted by @deejay9983, 2026-08-05 ### DeepSeek V4 Flash pruned on 4x 10 GB Source: https://cmp.wiki/wiki/DeepSeek_V4_Flash_pruned_on_4x_10_GB DeepSeek V4 Flash on four 10 GB cards with about 37 GB usable each. The full model would not load in vLLM on 37 GB cards, so cuddylac997 pruned 25% of its experts. He got 48.2 tok/s without DSpark and said it still gave good responses; two days later he reported about 50 tok/s. The pruned checkpoint was not published. Source: @cuddylac997, 2026-08-12 Source: @cuddylac997, 2026-08-12 Source: @cuddylac997, 2026-08-14 Source: @cuddylac997, 2026-08-14 ### DeepSeek V4.1 Flash heretic on 4x 8 GB Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_heretic_on_4x_8_GB Morrowmake's recipe for DeepSeek-V4.1-Flash on four CMP 170HX, unchanged except for a few .env lines, with pqhaz's heretic patch written into the official checkpoint in place. Nothing was retrained or requantized. The result answers prompts the stock model refuses, keeps tool calls and long-context copying accurate, and reasons longer. Source: @darkmaniac7, 2026-10-29 (lab notes) ### DeepSeek V4.1 Flash on 2x 8 GB (Project Maya) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_2x_8_GB_(Project_Maya) Most of DeepSeek-V4.1-Flash does not fit on two cards, so this setup keeps the hot experts and KV in VRAM and moves the rest between host RAM and NVMe as needed. The best documented run on two cards is in SeriousRising's repository: about 47 tok/s decode at temperature 1 and about 52 at temperature 0, on a patched Maya fork with the GSQ-RCO 2-bit GGUF. Strata, the engine Maya started from, gives 100+ tok/s on CMPs with default settings for models that fit. pcsv posted a figure of about 63 tok/s for DeepSeek 4.1 Flash on two 8 GB-variant cards, with no host or quant named; the Project Maya README has no DeepSeek row for CMP cards, so that figure rests on the post alone. Source: @pcsv., 2026-10-25 Source: @pcsv., 2026-10-25 Source: repo github.com/SeriousRising/ds41-flash-cmp170hx by SeriousRising on GitHub, posted by @seriousrising, 2026-10-29 ### DeepSeek V4.1 Flash on 4x 8 GB (alanoo fidelity build) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_4x_8_GB_(alanoo_fidelity_build) A fidelity-first configuration of DeepSeek V4.1 Flash on 4x 8 GB (GNmac), aimed at agentic and concurrent work. It grafts 3-bit experts from LibertAI's 3.5 bpw pack into layers 18-22 of the 2.9 bpw pack (so every expert layer is 3-bit), turns the DSpark drafter off to free KV room, loads the Engram tables from a tmpfs, and runs at 0.98 memory utilization for a 2.7M-token KV pool. Single-user decode is lower than the speed-tuned builds; 8-user throughput stays around 450 to 550 tok/s. The author calls it a first rough version. Infobox decode is one user on code without DSpark. Source: @alanoo, 2026-10-27 Source: repo github.com/alanoo81/deepseek-v41-flash-4x-cmp170hx by alanoo81 on GitHub, posted by @alanoo, 2026-10-27 ### DeepSeek V4.1 Flash on 4x 8 GB (CurtisAccelerate TC-MoE) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_4x_8_GB_(CurtisAccelerate_TC-MoE) A weight-selection recipe plus benchmark record for DeepSeek-V4.1-Flash-1017 on four 64 GB cards at 140 W on a dual-socket Broadwell host with no P2P. Its hybrid layout (EXL3 routed experts, everything else from the official checkpoint) is the one GNmac-lab and alanoo build on. It runs on Morrowmake's vLLM fork with the author's tensor-core MoE kernels (CurtisAccelerate/DeepSeekv41-Flash-EXL3-TC-MoE). No weights, engine or patches live in the repo itself. Infobox numbers are the 2026-10-22 published configuration, one user on code. Source: repo github.com/CurtisAccelerate/DeepSeekv41-Flash-1017-EXL3-CMP170HX by CurtisAccelerate on GitHub, posted by @anon33anon, 2026-10-20 Source: @anon33anon, 2026-10-20 ### DeepSeek V4.1 Flash on 4x 8 GB (GNmac with copy fix and faster prefill) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_4x_8_GB_(GNmac_with_copy_fix_and_faster_prefill) GNmac-lab's DeepSeek V4.1 Flash recipe for four 8 GB cards, release 1.2.0 (DeepSeek V4.1 Flash on 4x 8 GB (GNmac)), with three changes from the lab on top: the fix for the long-context copy errors listed on that page, offered to GNmac-lab's repository as pull request 2, and two prefill changes. Measured on the same four cards in the same session against the plain 1.2.0 image, cold prefill is 21% faster (2,732 against 2,258 tok/s; 2,941 against 2,417 at 17k tokens), long prompts copy paths and names correctly again (0 of 32 paths wrong on the six-conversation test), and decode is unchanged. Everything else (the engine build, the hybrid checkpoint, the settings and the benches) is GNmac-lab's recipe: set that up first, then add the changes below. Source: repo github.com/GNmac-lab/deepseek-v41-flash-1017-cmp170hx by GNmac-lab on GitHub, posted by @greencandle9753, 2026-10-21 Source: @darkmaniac7, 2026-11-09 (lab notes) ### DeepSeek V4.1 Flash on 4x 8 GB (GNmac) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_4x_8_GB_(GNmac) DeepSeek-V4.1-Flash-1017 on four 64 GB cards with vLLM and a patch stack for sm_80, an OpenAI-compatible API with tools, reasoning and images, and up to 1M tokens of context. The checkpoint is a hybrid (Curtis White's layout): EXL3 routed experts plus the official FP8 dense tensors, with the 189 GiB Engram n-gram tables streamed from NVMe instead of loaded, so it needs far less host RAM than the Morrowmake recipe. Infobox numbers are release 1.2.0, one user on code. Source: repo github.com/GNmac-lab/deepseek-v41-flash-1017-cmp170hx by GNmac-lab on GitHub, posted by @greencandle9753, 2026-10-21 Source: @greencandle9753, 2026-10-21 Read the long-context copy finding under Known issues before using it for work that must copy names or paths exactly. ### DeepSeek V4.1 Flash on 4x 8 GB (Morrowmake) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_4x_8_GB_(Morrowmake) DeepSeek-V4.1-Flash-1017 on four 64 GB cards with tool calls, reasoning, images and the checkpoint's own DSpark drafter. The served checkpoint is a hybrid built locally from links: routed experts from LibertAI's EXL3 2.9 bpw export, every other weight in DeepSeek's own FP8/BF16, and the two Engram lookup tables (about 189 GiB) in host RAM, or read from SSD on smaller hosts. Same engine family and tooling as GLM 5.3 Flash on 4x 8 GB. Infobox numbers are the author's "up to" figures for one user on code and cold prefill on a 2,048-token prompt. jjb: heavy lifting for the 4x 8 GB owners. Source: repo github.com/Morrowmake/dsv41-flash-cmp170hx-recipe by Morrowmake on GitHub, posted by @lia_oc, 2026-10-24 Source: @lia_oc, 2026-10-24 Source: @jjb01957, 2026-10-24 ### DeepSeek V4.1 Flash on 4x 8 GB plus RTX PRO 6000 (ExLlamaV3 TP5) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_4x_8_GB_plus_RTX_PRO_6000_(ExLlamaV3_TP5) DeepSeek-V4.1-Flash-1017 at the 3.5 bpw EXL3 quant with a full 1,048,576-token FP16 context, served by tensor parallel over four unlocked CMP 170HX plus one RTX PRO 6000 Blackwell, through ExLlamaV3 and TabbyAPI forks. The PRO card adds the memory that lets 3.5 bpw fit (it does not fit on four 64 GB cards) and holds the MTP draft. Infobox decode is the mean over nine C-coding requests; prefill is the 26K-token run. Source: repo github.com/anoane/09-deepseek-v41-flash-1017-exl3-tp5-1m by anoane on GitHub, posted by @anon33anon, 2026-10-20 Source: @anon33anon, 2026-10-20 ### DeepSeek V4.1 Flash on 5x 8 GB (PP5 full residency) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_5x_8_GB_(PP5_full_residency) DeepSeek-V4.1-Flash on five 64 GB cards with every expert in VRAM, served by a fork of wtdcode/vllm-backport with pipeline parallel 5 and a 1,048,576-token context. thcleaner (dkpoulsen) shared the repo on 2026-09-22 and reported 70+ tok/s on 5x 170HX with 256 GB of DDR4 system RAM. The layout is pipeline parallel only: tensor parallel 5 is impossible because the model's 64 attention heads and 1 KV head do not divide by 5, and full residency leaves no memory for DSpark or MTP. The 320-expert variant further down prunes the model to make room for DSpark. The decode speed is not settled: the repo's own docs give about 30 to 40 tok/s (see Measured numbers). The infobox shows the repo's readings; prefill is the 60K-token figure. Source: repo github.com/344303947/dsv41-flash-pp5-170hx by 344303947 on GitHub, posted by @dkpoulsen, 2026-09-22 ### DeepSeek V4.1 Flash on 6x 8 GB (Deepinfer-SM80 TP2 x PP3) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_6x_8_GB_(Deepinfer-SM80_TP2_x_PP3) Deepinfer-SM80 ports the ideas of DeepSeek's DeepInfer (Blackwell-only kernels) to Ampere as two vLLM patches plus 30 drop-in Python, Triton and TileLang modules, for serving DeepSeek-V4.1-Flash at 1M context with DSpark. Every headline number was measured on "NVIDIA GA100 64GB (SM80, 74 SMs)" nodes, which is the unlocked CMP 170HX (the source comments say so). On six cards the measured shape is TP2 x PP3. Infobox numbers are one stream on code and cold prefill at 16K. Source: repo github.com/HalfVulpes/Deepinfer-SM80 by HalfVulpes on GitHub, posted by @reala7096, 2026-10-20 Source: @segmond, 2026-10-20 ### DeepSeek V4.1 Flash on 6x 8 GB (TP6) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_6x_8_GB_(TP6) A deployment record for DeepSeek-V4.1-Flash-1017 on six 64 GB cards at tensor-parallel 6, with the DSpark drafter at K=5, including a full snapshot of the author's patched SM80 vLLM source. It is an evidence package rather than an installer: the serving stack starts through a private local console that is not published, and the host is Windows with WSL2. The README is in Chinese. Infobox decode is end-to-end tok/s on code including reasoning tokens. Source: repo github.com/wgkbfcp/deepseek-v4.1-flash-1017-cmp170hx-recipe by wgkbfcp on GitHub, posted by @dale063629, 2026-10-19 Source: @dale063629, 2026-10-19 ### DeepSeek V4.1 Flash on 8x 8 GB (Deepinfer-SM80 TP4 x PP2) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_8x_8_GB_(Deepinfer-SM80_TP4_x_PP2) The full DeepSeek-V4.1-Flash-1017 checkpoint on eight 64 GB cards with the Deepinfer-SM80 patches, at TP4 x PP2. It holds 13.3M tokens of KV on the GPUs (12.69 full 1M-token sequences). Build steps are the same as the six-card page: DeepSeek V4.1 Flash on 6x 8 GB (Deepinfer-SM80 TP2 x PP3). Infobox decode is concurrency 1 on code. Source: repo github.com/HalfVulpes/Deepinfer-SM80 by HalfVulpes on GitHub, posted by @reala7096, 2026-10-20 ### DeepSeek V4.1 Flash on 8x 8 GB (Zanooda PP8) Source: https://cmp.wiki/wiki/DeepSeek_V4.1_Flash_on_8x_8_GB_(Zanooda_PP8) A complete serving recipe for DeepSeek-V4.1-Flash-1017 on eight 64 GB cards with vLLM pipeline parallel 8: a 20-patch series on the open vLLM PR #56201 plus haosdent's sm_80 layer, a prebuilt sm_80-only Docker image, launch scripts and benchmark harnesses. It serves the official checkpoint without conversion or EXL3, gives a 6.2M-token KV pool and 1M context, and has the best prefill of the DeepSeek recipes. It builds on allover326/deepseek-v4-cmp170hx and is independent of the Morrowmake recipes. Justinjja found it a bit faster than the alternatives at the time. Source: repo github.com/Zanooda/deepseek-v4.1-flash-cmp170hx by Zanooda on GitHub, posted by @gnasherrr, 2026-10-17 Source: @gnasherrr, 2026-10-17 Source: @justinjja, 2026-10-17 ### Engines Source: https://cmp.wiki/wiki/Engines The CMP 170HX is a GA100 die with compute capability 8.0 (sm_80, the A100 family), 64 GB of HBM after the unlock (Driver unlock), no NVLink and PCIe Gen2 at best (Unlocks). Engines built for Hopper or Blackwell kernels do not run on it as shipped, and engines that assume NVLink lose time in all-reduce. This page lists what runs, which recipes use it, and the flags and traps that matter. For the per-model setups see Recipes. ### GLM 5.2 on 3x 10 GB (llama.cpp CPU offload) Source: https://cmp.wiki/wiki/GLM_5.2_on_3x_10_GB_(llama.cpp_CPU_offload) GLM-5.2 at Q4 on three 10 GB cards at the 40 GB profile, with most of the model left in host RAM and DDR4. This is a slow way to run a model this size: the cards add decode speed over the CPU alone, and the PCIe link limits prefill. Eksitus says 64 GB cards suit offloading a model of this size much better. Source: @eksitus, 2026-07-20 Source: @eksitus, 2026-07-24 ### GLM 5.2 on 8x 8 GB Source: https://cmp.wiki/wiki/GLM_5.2_on_8x_8_GB In late July 2026 DeeJay rented a server of RedPandaMining's unlocked 8 GB cards (64 GB each) for most of a day to see how GLM-5.2 runs on the CMP 170HX. All links ran at PCIe Gen1 x4: the run came before the rig's Gen2 update. Con3po's notes list eight rented cards on 2026-07-27 at driver 610.43.02, Gen1 x4, with no capacitor mod. On vLLM with pipeline parallel, GLM-5.2 at 4 bits gave about 2,600 tok/s prefill and 30 tok/s decode, without MTP. His results file went up on 2026-07-27. Source: @deejay9983, 2026-07-26 Source: @deejay9983, 2026-07-26 Source: @deejay9983, 2026-07-27 Source: @deejay9983, 2026-07-27 Source: @redpandamining, 2026-07-27 Source: @deejay9983, 2026-07-27 Source: @deejay9983, 2026-07-27 Source: @con3po7016, 2026-09-09 ### GLM 5.3 Flash on 2x 8 GB (ExLlamaV3 layer split) Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_2x_8_GB_(ExLlamaV3_layer_split) GLM-5.3-Flash entirely in HBM on two 64 GB cards, using turboderp's ExLlamaV3 and his 3.05 bpw EXL3 quant, with a DFlash2 drafter (converted locally to EXL3 6 bpw) or the model's own MTP head. Layers are split across the two cards and data moves through host memory, so it needs no P2P and no x16 mod. It is the base the two-card TP build extends (GLM 5.3 Flash on 2x 8 GB (ExLlamaV3 TP2)) and the EXL3 alternative to the vLLM path that needs four cards. Source: repo github.com/Flun/glm53-flash-cmp170hx-exl3 by Flun on GitHub, posted by @wingrimez_40467, 2026-10-20 Source: @wingrimez_40467, 2026-10-20 ### GLM 5.3 Flash on 2x 8 GB (ExLlamaV3 TP2) Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_2x_8_GB_(ExLlamaV3_TP2) GLM-5.3-Flash entirely in HBM on two 64 GB cards, as the layer-split EXL3 build (GLM 5.3 Flash on 2x 8 GB (ExLlamaV3 layer split)) extended with tensor parallel over NCCL and GPU P2P, vision input, DFlash2 speculative decoding with hybrid drafting, two concurrent requests and idle sessions parked in host RAM. Infobox decode is the author's single-request code figure. Mountains calls it the number one recipe for two cards and listed it on localairecipes as "GLM-5.3-Flash EXL3 3.05bpw on 2x CMP 170HX TP2 DFlash2 K7 hybrid". Source: repo github.com/alexvnesta/glm53-flash-cmp170hx-tp by alexvnesta on GitHub, posted by @nestaa51, 2026-10-12 Source: @mountains1605, 2026-10-13 Nestaa51's announcement: on his x16-modded pair of 8 GB cards, decode is up to about 28% faster than Flun's layer split, about 120 tok/s and 134-147 tok/s on code edits and JSON. Idle sessions' KV cache is parked in system RAM and two agents run at once (about 320K context each, 393K max per request), which is not vLLM-style concurrency. Most of his time went into the code, so real-world testing was still thin; the cards were limited to about 170 W with a modest memory overclock for these numbers. Source: @nestaa51, 2026-10-12Source: @nestaa51, 2026-10-14 ### GLM 5.3 Flash on 2x 8 GB (Project Maya) Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_2x_8_GB_(Project_Maya) Project Maya is a self-tuning inference engine with a web chat and OpenAI- and Anthropic-compatible APIs. It runs GLM-5.3-Flash, DeepSeek-V4.1-Flash-1017 and MiniMax-M3.1-Flash by tiering MoE experts across VRAM, RAM and NVMe, so it also works when the model does not fit in the cards. It needs compute capability 7.0 or newer, so the CMP 170HX (sm_80) is supported. 68x names it, with the Flun forks, as the way to run GLM 5.3 Flash on two CMPs. Source: @pcsv., 2026-10-25 Source: @68x0, 2026-10-26 ### GLM 5.3 Flash on 3x 8 GB Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_3x_8_GB GLM-5.3-Flash on three cards, leaving the fourth free for image generation, mining or rental. Shirogeek runs a W4A16 quant of about 4.3 bpw (163 GiB) on three 64 GB cards. His own recipe converged with Morrowmake's, so his instruction is: use Morrowmake's recipe with PP3. He quantizes the KV cache to 8 bits and gets a context window of about 1M tokens. No tok/s figure was posted. Source: @shirogeek, 2026-10-19 Source: @shirogeek, 2026-10-19 ### GLM 5.3 Flash on 4x 8 GB Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_4x_8_GB The community's reference build for four cards: GLM-5.3-Flash in W4A16 on Morrowmake's Ampere vLLM fork, with a DFlash2 speculative drafter, tool calls, reasoning, images and video, behind an OpenAI-compatible API. Most 4-card owners run W4A16 on this recipe, and Impactic says nobody really cares to upgrade past it. Infobox numbers are the author's TP4 release figures for one user on code. Source: @gnasherrr, 2026-10-27 Source: repo github.com/Morrowmake/glm53-flash-cmp170hx-recipe by Morrowmake on GitHub, posted by @ob88594, 2026-10-06 Source: @impactic, 2026-10-24 ### GLM 5.3 Flash on 4x 8 GB (kaka86mm EXL3 + Marlin sidecar + DFlash2) Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_4x_8_GB_(kaka86mm_EXL3_%2B_Marlin_sidecar_%2B_DFlash2) GLM-5.3-Flash on four 8 GB cards unlocked to 64 GB, with kaka86mm's deployment overlay for hyd998877's EXL3 vLLM fork: EXL3 4 bpw weights, a Marlin INT4 sidecar generated offline for decode, and the incoai DFlash2 drafter at k=7, in pipeline parallel 4 over PCIe Gen2 x4 with no P2P. The repository reports a 512k context window, about 2,077 tok/s cold prefill and, at one stream, 158-161 tok/s on JSON, 96-100 on code and 40-42 on prose, at 200 W per card. thcleaner, who posted it on Discord, saw upwards of 160 tok/s with it, about 90 on average. Infobox numbers are the repository's own readings on its v24 build (decode is the low end of the code figure). The final production build is v30, which runs without the CPU KV tier that the README still describes (Known issues). Source: repo github.com/kaka86mm/glm53-flash-170hx by kaka86mm on GitHub, posted by @dkpoulsen, 2026-09-19 ### GLM 5.3 Flash on 8x 8 GB (promisezackr PP8 NVFP4 DFlash2) Source: https://cmp.wiki/wiki/GLM_5.3_Flash_on_8x_8_GB_(promisezackr_PP8_NVFP4_DFlash2) promisezackr's patch set serves GLM-5.3-Flash (320B MoE, 18B active, 1M context) on eight 64 GB cards at PCIe Gen2 x4 with no P2P: vLLM pipeline parallel 8, the LibertAIDAI NVFP4 checkpoint and the DFlash2 drafter with 7 draft tokens. The repo reports 123 tok/s single stream on code, 276 tok/s aggregate at 16 streams, a 960k-token prompt in 208 s and a 6.62M-token KV pool. Zanooda posted it on Discord and runs the same patches on six cards (The six-card variant). The numbers on this page are the repo's own readings: nobody has posted a matching eight-card run yet, and one owner stalled at 20 tok/s (Known issues). Source: repo github.com/promisezackr/glm53-flash-170hx-pp8 by promisezackr on GitHub, posted by @zanooda, 2026-08-31 ### GLM 5.3 on 8x 8 GB (cebeuq glm53-cmp170hx-recipe) Source: https://cmp.wiki/wiki/GLM_5.3_on_8x_8_GB_(cebeuq_glm53-cmp170hx-recipe) cebeuq's recipe serves the full GLM-5.3 with a 524,288-token context on eight unlocked 8 GB cards at TP2 x PP4. The model has 753B total parameters (744B without the MTP draft layer). The recipe runs lazymio's sm_80 vLLM image unmodified underneath a set of mounted patches, converts the abliterated NVFP4 checkpoint offline, and adds PCIe peer-to-peer with vLLM's custom all-reduce, an int8-tile latent KV cache, MTP speculative decoding with a fix for pipeline parallelism, and PipeSpec. The drafter is the model's own MTP layer, shipped inside the public checkpoint, so there is nothing separate to download. It builds on Morrowmake's GLM-5.3-Flash recipe (GLM 5.3 Flash on 4x 8 GB) and on Morrowmake's TRAP31 P2P driver patch. The recipe is MIT licensed; the patches keep vLLM's Apache-2.0 headers. Source: repo github.com/cebeuq/glm53-cmp170hx-recipe by cebeuq on GitHub ### GLM 5.3 on 8x 8 GB (Int4-Int8Mix PP8) Source: https://cmp.wiki/wiki/GLM_5.3_on_8x_8_GB_(Int4-Int8Mix_PP8) The full GLM-5.3 on eight cards with plain pipeline parallel and the model's MTP head. It runs, at about 25 tok/s, slowing to about 10 tok/s at high context. DFlash would not cooperate on this setup. The cards ran at 200 W each with a cardboard-box fan shroud, so no overclock. It is the baseline the vllm-170hx-glm5 build later beat on the same 8 cards. Source: @1a2b3c0967, 2026-10-07 Source: @1a2b3c0967, 2026-10-07 Source: @1a2b3c0967, 2026-10-08 ### GLM 5.3 on 8x 8 GB (vllm-170hx-glm5) Source: https://cmp.wiki/wiki/GLM_5.3_on_8x_8_GB_(vllm-170hx-glm5) The full GLM-5.3 (744B total, 40B active) on eight to ten 64 GB cards under pipeline parallel, with the DFlash2 speculative drafter and a 1M-token context. It pins a commit of Morrowmake's vLLM fork and applies a set of patches that port the DSA sparse-attention path to sm_80. The kit descends from bayley's bayley/vllm-170hx-glm5, published on 2026-08-13: the original patch-the-venv kit, which patches an installed stock vLLM 0.26.0 to serve GLM-5.2 (GLM-5.3 scripts since 2026-09-09) on 8 cards with PP8 and MTP. arvkmr/vllm-170hx-glm5 is its successor: reala moved it onto Morrowmake's fork (vLLM 0.30.1rc1) and replaced MTP with DFlash2, first announced on 2026-09-28 and published on Discord on 2026-10-08. Infobox numbers are the author's single-stream run on 10 cards (the 8-card layout came later). Source: repo github.com/bayley/vllm-170hx-glm5 by bayley on GitHub, posted by @bayley_w, 2026-08-13 Source: @reala7096, 2026-09-28 Source: @reala7096, 2026-10-08 Source: repo github.com/arvkmr/vllm-170hx-glm5 by arvkmr on GitHub, posted by @reala7096, 2026-10-08 reala's own summary on Discord: 45 tok/s on short context, never below 30 on long context, and still about 30 tok/s per stream at concurrency 8: "still slow, but it feels quite usable now". Source: @reala7096, 2026-10-08 ### GLM 5.3 on 8x 8 GB plus 2x RTX PRO 6000 (vLLM TP2 x PP5) Source: https://cmp.wiki/wiki/GLM_5.3_on_8x_8_GB_plus_2x_RTX_PRO_6000_(vLLM_TP2_x_PP5) The full GLM-5.3 with a 524,288-token context, served across two hosts. The base is cebeuq's recipe for eight CMPs, GLM 5.3 on 8x 8 GB (cebeuq glm53-cmp170hx-recipe): his converted checkpoint, his vLLM patches, the int8-tile KV cache, the PCIe all-reduce, and MTP with PipeSpec. The lab extended it to two hosts. Two RTX PRO 6000 Blackwell cards run the first pipeline stage (30 of the 78 layers plus the embedding). Eight unlocked 8 GB cards run the other four stages as TP2 pairs of 12 layers each; the last pair also holds the final norm, the LM head and the MTP layer. The model has 753B total parameters (744B without the MTP draft layer). The drafter is the model's own MTP layer, shipped inside the public checkpoint, so there is nothing separate to download. The Blackwells are a non-CMP stage: the card count on this page is the eight CMPs. Source: repo github.com/cebeuq/glm53-cmp170hx-recipe by cebeuq on GitHub Source: @darkmaniac7, 2026-11-05 (lab notes) The lab's software additions (the sm_120 build for the two-host layout, the pipeline hand-off fix, the grammar-bitmask fix and probabilistic drafts) are published in the lab's repository, glm53-cmp170hx-blackwell-recipe, and the three engine fixes are offered to cebeuq's repo as pull requests 1 to 3; the rest of the software is in cebeuq's repo. Download: the overlays as a tarball (sha256 9730cad004ffa391..., mirrors the repository at commit 380b6f5; file page with the full hash and licence). The two structured-output options measured later on 2026-11-05 (g5 and jor, see #The lab's additions) are not in that tarball. Source: repo github.com/darkmaniac7/glm53-cmp170hx-blackwell-recipe by darkmaniac7 on GitHub Against cebeuq's recipe on the eight CMPs alone, run with the lab's additions, the Blackwell stage adds about 10% single-stream speed, 43% more KV cache, about 50% faster prefill at 17k tokens and 13 to 28% more aggregate at 8 streams. Hardware: 8x CMP 170HX (8 GB cards unlocked to 64 GB, PCIe Gen2 x16, four TP2 pairs on one host) plus 2x RTX PRO 6000 Blackwell (pipeline stage 0, on a second host), with one direct 100 GbE link (ConnectX-5) between the two hosts. Source: @darkmaniac7, 2026-11-05 (lab notes) ### Image, video, voice and training Source: https://cmp.wiki/wiki/Image,_video,_voice_and_training Owners also use the unlocked CMP 170HX for image and video diffusion (mostly in ComfyUI), for voice and audio models, and for some training. An unlocked 8 GB card has 64 GB, enough to hold a full video model such as MiniMax H3 at INT8 on one card, so the usual layout is one render job per card; diffusion does not split well across cards. The card has no native FP8 and modest FP32 throughput, so INT8 ConvRot and BF16 paths do best. Training is the contested part: single-card LoRA work runs, multi-card training is limited by the PCIe link. Numbers are one owner's report unless the entry says Proven. LLM serving is on Recipes. ### Laguna-S-2.1 on 2x 10 GB Source: https://cmp.wiki/wiki/Laguna-S-2.1_on_2x_10_GB Laguna-S-2.1 in NVFP4 GGUF on two 10 GB cards, split evenly, at 131,072 tokens of context. bigfoot asked for working setups on 10 GB cards; squishysquare posted his. The service is called vllm but runs a custom llama-server backend from ciruinference; NVFP4 works through a fallback path because the cards lack native FP4. He measured 53 tok/s decode and did not measure prefill ("pretty snappy"). Source: @bigfoot1144, 2026-08-11 Source: @squishysquare, 2026-08-11 Source: @squishysquare, 2026-08-12 Source: @squishysquare, 2026-08-12 Source: @squishysquare, 2026-08-12 Source: @squishysquare, 2026-08-12 ### Llama.cpp on CMP cards Source: https://cmp.wiki/wiki/Llama.cpp_on_CMP_cards llama.cpp runs on the CMP 170HX out of the box and is the easiest engine to start with, but on these cards it is clearly slower than vLLM or SGLang with INT4 or INT8 weights, above all in prefill. Owners keep it for models that do not fit in VRAM with their context, for rigs that mix GPU generations or machines (RPC), for low power draw, and for quick benchmarks that compare across hardware. This page collects what applies to llama.cpp on every model: when to pick it, how to build it, how to split a model across cards, RPC, MTP, the measured runs, the patch script for stock (not unlocked) cards and the work on other CMP cards. Engine choice in general is on Engines; vLLM's own traps are on vLLM on sm_80: known bugs and patches. ### MiMo V2.6 Flash on 4x 8 GB Source: https://cmp.wiki/wiki/MiMo_V2.6_Flash_on_4x_8_GB Xiaomi's MiMo-V2.6-Flash-RL on four 64 GB cards: the ProCreations NVFP4 checkpoint, tensor parallel 4, the full 1M-token context, MiMo's own DFlash drafter, reasoning and tool calls, with image input. It runs Morrowmake's engine image as released apart from one mounted vision fix. Scripts descend from Morrowmake's Qwen recipe and the launch configuration from kaka86mm/vllm-mimo-170hx, the first MiMo-V2.6 deployment on these cards. Infobox numbers are one user on code. Source: repo github.com/ElectroHobo/mimo-v26-flash-cmp170hx-recipe by ElectroHobo on GitHub, posted by @nathang6866, 2026-10-18 Source: @nathang6866, 2026-10-18 ### Mistral Large 4 on 8x 8 GB (llama.cpp lab trial) Source: https://cmp.wiki/wiki/Mistral_Large_4_on_8x_8_GB_(llama.cpp_lab_trial) Mistral Large 4 ("Le Chonk", 1T total, about 52B active) runs on eight 64 GB cards with llama.cpp, but only as a trial: it works, and it is far too slow for chat at long contexts. The model is 72 layers with DeepSeek-style compressed attention (MLA, KV rank 512) plus a DSA sparse indexer, cross-layer KV sharing, and 128 routed experts with 4 active and 1 shared. llama.cpp supports it since PR #31376, together with its DSpark drafter, but runs it with a layer split, so each token passes through the eight cards one after another. A real recipe (tensor-parallel vLLM with an Ampere-servable quant) does not exist yet; see #What would make it usable. Source: @darkmaniac7, 2026-11-01 (lab notes) ### Parallelism over the PCIe link Source: https://cmp.wiki/wiki/Parallelism_over_the_PCIe_link The CMP 170HX has no working NVLink, so every multi-card setup talks over PCIe: Gen1 x4 on a stock card, Gen2 x4 after the Gen2 link retrain, Gen2 x16 with the PCIe x16 capacitor mod. Tensor parallel (TP) splits every layer across cards and runs all-reduces inside each layer, so it is limited by that link. Pipeline parallel (PP) gives each card a block of layers and passes one hidden state per stage boundary, so it barely notices the link. Expert parallel (EP) spreads MoE experts over cards; data parallel (DP) runs one full copy per card. On stock x4 links owners run one model per card or PP. On x16 links with P2P, TP4 or TP2 x PP2 can win single-user decode on some models while PP keeps the prefill lead. Where owners disagree, both sides are below with their numbers. ### Quantization on the 170HX Source: https://cmp.wiki/wiki/Quantization_on_the_170HX The CMP 170HX is sm_80: it has INT8 and INT4 tensor cores and BF16/FP16, but no FP8 or FP4 hardware. That decides which quants are fast. This page collects what people measured; the per-model setups are on the Recipes pages and every number is on Benchmarks. ### Qwen3.6 27B and 35B-A3B on one card (July and August 2026) Source: https://cmp.wiki/wiki/Qwen3.6_27B_and_35B-A3B_on_one_card_(July_and_August_2026) Before Qwen3.8 arrived, Qwen3.6 27B (dense) and Qwen3.6 35B-A3B (MoE, about 3B active) were the models most owners ran on one unlocked card. This page collects the single-card reports from July and August 2026 by engine: the first vLLM references, the 10 GB card at its 40 GB profile, llama.cpp, vLLM tuning, SGLang, the 35B-A3B MoE, and the July argument about MTP. Every number is one person's or one repository's reading, with its own quant, engine version, power cap and benchmark method, so compare rows with care. For the model that replaced it on one card, see Qwen3.8 27B on 1x 8 GB (W4A16 vLLM). ### Qwen3.6 27B on 1x 10 GB (llama.cpp MTP) Source: https://cmp.wiki/wiki/Qwen3.6_27B_on_1x_10_GB_(llama.cpp_MTP) Qwen3.6-27B from unsloth's MTP GGUF on one 10 GB card at the 40 GB profile, unlocked with cmpunlocker, at PCIe Gen1 x4 (no mod yet) and 250 W maximum power. Eksitus compared stock llama.cpp and ik_llama.cpp, with and without MTP, at Q4 and Q8. The infobox numbers are Q4 on stock llama.cpp with draft MTP; he puts a few tok/s of error on each run. Source: @eksitus, 2026-07-22 ### Qwen3.6 27B on 1x 10 GB (SGLang W8A8) Source: https://cmp.wiki/wiki/Qwen3.6_27B_on_1x_10_GB_(SGLang_W8A8) A published benchmark of Qwen3.6-27B (W8A8) on SGLang 0.5.16 on one 10 GB card at 40 GiB, at a 250 W limit, with and without MTP. The repository holds the scripts, configs and results; its author also ran an 8 GB card at 64 GiB separately (two runs, not a controlled A/B). makesier and yuiayanami posted it on the Discord. Source: repo github.com/Ciender/CMP-170HX-SGLang-Qwen3.6-Benchmarks by Ciender on GitHub, posted by @makesier, 2026-08-01 Source: @yuiayanami, 2026-08-01 ### Qwen3.8 27B on 1x 8 GB (W4A16 vLLM) Source: https://cmp.wiki/wiki/Qwen3.8_27B_on_1x_8_GB_(W4A16_vLLM) The dense Qwen3.8-27B in W4A16 on one 64 GB card under vLLM, from Miséricorde's r/LocalLLM post "Qwen3.8-27B W4A16 on one 64 GB CMP 170HX: 160+/70+ decode" (2026-08-30): 160+ tok/s decode on short context and 70+ near the long end, with variants for native context and about 500k via YaRN at 170 to 210 tok/s. The setup is vLLM with DFlash2 speculative decoding plus his own vLLM patches, written to be handed to an AI agent that applies everything, and suited to solo or low-concurrency inference; his prefill optimisation attempts topped out around +15%. He paid about 1.6k per card and was inspired by a Reddit post about 130 tps on a 3090 with DFlash2. His numbers, with the GPU overclocked (about +20% inference speed): short prompts W8A16 120.3 tok/s (3.30 tokens per step) and W4A16 169.5 tok/s (3.25), favourable UI turns 190 to 210; a 23.75K prompt W8A16 82.9 and W4A16 104.8 tok/s (2.97); a 65,920-token hot prefix W8A16 57.9; at 85,514 tokens an older W4/INT8 run mostly 42 to 46 tok/s (16/16 general and 6/6 crash-point passes) and the current W4 FP8/DFlash build 119.3 tok/s strict hot decode, 1.76 s hot TTFT and 84.8 tok/s hot end-to-end. In practice 200+ tok/s at the start, 80 to 110 tok/s at 100K KV and 100+ for agentic coding. Infobox decode is his short-prompt W4A16 figure. Reproductions: kellertreppe123 copied the recipe and reached about 170 tok/s at 262k context, 60 to 70 near long context (Confirmation 2); on 2026-08-31 he already ran the 27B on one card for n8n workflows at "not lower then 90 tok/s but depends" and called the post a good summary. Dino reproduced it on one card at 3,000 tok/s prefill and 160 tok/s decode (W4A16) against about 1,000 / 50 with llama.cpp and ran an INT8 version at 120 tok/s, but could not get the post's repo to work; Miséricorde offered help by DM. dottoreargus got 142 tok/s at small context but struggled at larger contexts (see the prefix-caching pointer under Speculative decoding). chonsworth's run on the same model is Confirmation 1; AmishRakeFightr planned to try it. Source: @1a2b3c0967, 2026-08-30 Source: @wakeupmbrc1, 2026-08-30 Source: @kellertreppe123, 2026-08-31 Source: @dino_38975, 2026-08-31 Source: @dottoreargus, 2026-09-01 Source: @kellertreppe123, 2026-10-05 Source: @kellertreppe123, 2026-10-05 Source: @kellertreppe123, 2026-10-05 Source: @amishrakefightr, 2026-10-05 Source: @kellertreppe123, 2026-10-05 Source: @chonsworth, 2026-10-05 ### Qwen3.8 Flash Next on 1x 8 GB (ElectroHobo 3 bpw) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_1x_8_GB_(ElectroHobo_3_bpw) Qwen3.8-Flash-Next on one 64 GB card with the full 262,144-token context. It joins klee100's mixed 2/3-bit AutoRound checkpoint (47 GiB on the card) with halt95's FP8 n-gram table held in host RAM, or since 0.2.0 in a disk file read through HMM, and serves up to 48 requests. It is the one-card sibling of Qwen3.8 Flash Next on 2x 8 GB (ElectroHobo W4A16 TP2) and shares its engine, patches and table. Mountains called it the fastest Qwen Next on a single card he had seen (quality and quant not yet checked). Infobox numbers are one user on code. Source: repo github.com/ElectroHobo/qwen38-flash-next-3bpw-1x-cmp170hx-recipe by ElectroHobo on GitHub, posted by @nathang6866, 2026-10-24 Source: @mountains1605, 2026-10-27 ### Qwen3.8 Flash Next on 1x 8 GB (iIIusi0n SSD PLE) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_1x_8_GB_(iIIusi0n_SSD_PLE) Qwen3.8-Flash-Next on one 64 GB card with only 15 GiB of host RAM: a downstream vLLM patch keeps the 95.37 GiB BF16 PLE (n-gram) table on SSD and streams rows with native Linux AIO. It was the first single-card Qwen3.8 Flash Next recipe and is listed on localairecipes as "Qwen3.8-Flash-Next 3bpw MTP on 1x CMP 170HX SSD PLE AIO (iIIusi0n)". Asked on 2026-10-27 for the go-to model on one 64 GB card, 68x answered Qwen3.8 Flash Next with PLE patches and Mountains named this recipe. Infobox numbers are the author's single-request decode and fresh 8K prefill. Source: repo github.com/iIIusi0n/qwen3.8-flash-next-cmp170hx by iIIusi0n on GitHub, posted by @c133, 2026-10-09 Source: @c133, 2026-10-09 Source: @68x0, 2026-10-27 Source: @mountains1605, 2026-10-27 ### Qwen3.8 Flash Next on 2x 8 GB (DUFRelic PP2) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(DUFRelic_PP2) A single-README production recipe for Qwen3.8-Flash-Next on two cards unlocked to 64 GiB and 74 SMs, under stock vLLM v0.30.0 with zankich's INT4-PLE plugin and six upstream patch layers, pipeline parallel 2 and MTP depth 3. It does not use the Morrowmake fork. The INT4 PLE table (about 26.8 GiB) stays in pinned host memory. No scripts, Dockerfile or compose file are published; the image and manifests are private, so reproducing it means re-applying the patches by hand. Infobox numbers are concurrency 1 decode and prefill from the author's benchmark. Source: repo github.com/DUFRelic/qwen38-flash-next-recipe by DUFRelic on GitHub, posted by @dufrelic, 2026-10-05 DUFRelic posted the repo on 2026-10-05 and later asked Morrowmake what x4 links cost; Morrowmake had not tested it but expects x4 to hurt prefill. Source: @dufrelic, 2026-10-05Source: @dufrelic, 2026-10-16Source: @voidgiraffe, 2026-10-16 ### Qwen3.8 Flash Next on 2x 8 GB (ElectroHobo W4A16 TP2) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(ElectroHobo_W4A16_TP2) Qwen3.8-Flash-Next in W4A16 on two 64 GB cards with inco.ai's DFlash 2 drafter, full 262,144-token context, vision, reasoning and tool calls, and up to 128 concurrent requests. It runs Morrowmake's engine image as released with a few patch files mounted over it. It exists for old CPUs: the 48 GiB n-gram (PLE) table stays in host RAM (or, since 0.3.0, in a disk file the cards read through HMM), so the whole decode step runs as one CUDA graph instead of a Python-driven piecewise step. It is the fastest two-card recipe on code and prose and needs x16 links and P2P. Infobox numbers are release 0.2.0, one user on code. Source: repo github.com/ElectroHobo/qwen38-flash-next-w4a16-2x-cmp170hx-recipe by ElectroHobo on GitHub, posted by @nathang6866, 2026-10-24 Source: @nathang6866, 2026-10-20 Other ways to run Flash Next on two cards (PP2 on stock x4 cards, NVFP4, SGLang, llama.cpp, 10 GB cards) are compared under Other two-card recipes and reports. Facts that hold for every Flash Next recipe (model size, the n-gram table, speculative decoding, quant choice) are on Qwen3.8 Flash Next on 4x 8 GB#Facts shared by every Flash Next recipe. ### Qwen3.8 Flash Next on 2x 8 GB (mannydelrio PP2) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(mannydelrio_PP2) An uncensored Qwen3.8-Flash-Next on two stock 8 GB-variant cards (PCIe Gen2 x4, no capacitor mod, no P2P) in a Ryzen desktop with only 16 GB of RAM. Two "tinybeast" vLLM plugins quantize the 29.8 GB PLE table to INT4 and stream it from the NVMe, freeing VRAM for MTP speculative decoding. Pipeline parallel, not tensor parallel, because without P2P TP pays a host-memory sync per layer. It reads prompts faster than any other two-card recipe. Infobox numbers are one user on code and cold prefill on the cross-recipe protocol. Source: repo github.com/mannydelrio/qwen38-flash-next-2x-cmp170hx by mannydelrio on GitHub, posted by @mrmannyatx, 2026-10-06 MrManny posted the repo on 2026-10-06 as a Claude-assisted setup that works for him and asked for improvements; fiiireface had his own 2-card setup to publish. A later MTP5 revision listed on localairecipes reports 240 / 225 / 156 tok/s for one user (structured / code / prose), 1,044 / 715 / 625 at eight users and 6,964 tok/s cold prefill, with a measured run file; his MTP3 revision 109 prose / 159 code and about 7,700 prefill. Source: @mrmannyatx, 2026-10-06Source: @fiiireface, 2026-10-06Source: @darkmaniac7, 2026-10-27 (lab notes) ### Qwen3.8 Flash Next on 2x 8 GB (Morrowmake EXL3) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(Morrowmake_EXL3) Morrowmake's Qwen3.8-Flash-Next recipe on two cards with his vLLM fork's EXL3 path (release 1.0.0, engine tag qwen38-recipe-1.0.0). He chose 5.05 bpw because a 1M-token KV cache still fit, and said on 2026-10-16 that W4A16 is probably a better choice than EXL3. The ElectroHobo two-card recipe descends from its scripts and runs the same engine image. Infobox numbers are the published one-user code figure and cold prefill, as quoted in ElectroHobo's README. Source: @voidgiraffe, 2026-10-15 Source: @voidgiraffe, 2026-10-16 Source: repo github.com/ElectroHobo/qwen38-flash-next-w4a16-2x-cmp170hx-recipe by ElectroHobo on GitHub, posted by @nathang6866, 2026-10-24 Morrowmake released this recipe as a first attempt alongside the GLM update, after two weeks spent moving his custom code behind vLLM plugins. On x4 links he expects it to hurt prefill (untested) and planned a PP2 version. Source: @voidgiraffe, 2026-10-15Source: @voidgiraffe, 2026-10-15Source: @voidgiraffe, 2026-10-16 ### Qwen3.8 Flash Next on 2x 8 GB (Plean PP2) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(Plean_PP2) Plean's setup for Qwen3.8 Flash Next on two 64 GB cards: vLLM pipeline parallel 2, MTP speculative decoding, and the full BF16 PLE (n-gram) table offloaded to NVMe instead of held on the cards. It uses Minachist's mixed INT4 AutoRound checkpoint and runs up to 6 concurrent requests with a 256K context window. P2P is off on his rig because of a chipset issue with how lanes are assigned between his motherboard and CPU, so it needs neither P2P nor the x16 mod. The full write-up is on his site, linked in the infobox. Infobox numbers are from the localairecipes listing of this build (predictable output; see below). Source: @plean., 2026-10-07 Source: @plean., 2026-10-07 Source: @plean., 2026-10-07 ### Qwen3.8 Flash Next on 2x 8 GB (Qwen-Flash-SM80, GDS TEP2) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(Qwen-Flash-SM80,_GDS_TEP2) Qwen-Flash-SM80 is a vLLM runtime for Qwen3.8-Flash-Next in NVFP4 on two 64 GB cards. It runs tensor plus expert parallel across the pair (TEP2) and MTP with 6 draft tokens. The 51.2 GB FP8 PLE lookup table (the n-gram table) stays on an NVMe SSD: one GPU reads the rows it needs straight from the SSD with GPUDirect Storage (cuFile over NVMe P2PDMA) and passes them to the other. ti posted it on Discord on 2026-09-09 at "200 token/s", and clee pointed two-card owners to it on 2026-10-01. The infobox shows the 2026-09-08 single-request run at 8K input; the current release, v0.3.0, reports 749.67 tok/s aggregate at 10 concurrent requests. Every number on this page is the repository's own reading from one machine, and nobody has posted a reproduction yet. The recipe needs working GPU P2P and a validated GDS path and will not start without P2P. Source: repo github.com/nguyenthimy2022kg-alt/Qwen-Flash-SM80-170HX by nguyenthimy2022kg-alt on GitHub, posted by @jovial_dolphin_29796, 2026-09-09 Source: @c133, 2026-10-01 ### Qwen3.8 Flash Next on 2x 8 GB (vektorprime PP2) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_2x_8_GB_(vektorprime_PP2) A build recipe and vLLM patch set that serves an AWQ INT4 Qwen3.8-Flash-Next on two 64 GB cards with pipeline parallel 2 plus PLE CPU offload, a combination upstream vLLM refuses in six places. The author avoids TP2 because these cards sit on slow PCIe lanes and TP all-reduce dies there. Later parts add prefix-caching fixes, an FP8 PLE table, a deterministic-MoE patch and sampled MTP drafting; the author's production moved to PP3 (two 64 GB cards plus a 40 GB card). Infobox decode is single stream with MTP k=1. Source: repo github.com/vektorprime/qwen38-flash-next-pp2 by vektorprime on GitHub, posted by @vektor_prime, 2026-10-07 ### Qwen3.8 Flash Next on 3x 8 GB (clee PP3) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_3x_8_GB_(clee_PP3) Qwen3.8-Flash-Next on three unmodded 64 GB cards (x4 links, no P2P) with pipeline parallel 3, a 1M-token context and a 7.36M-token KV pool, on a pinned vLLM nightly plus the author's fork. The BF16 PLE table is streamed live from the checkpoint's safetensors shards on NVMe, and a tiered GPU / CPU / NVMe KV prefix cache survives server restarts, so a long agent session resumes quickly after a restart. It also runs on two cards at PP2 with less KV. Infobox numbers are the author's cold single-stream run of 2026-10-10 (the tested date in the infobox) at 1K (decode) and 64K (prefill). The recipe was first posted on 2026-10-04, and 68x reproduced it on 2026-10-08 on the branch as it stood then (confirmation). Source: repo github.com/clee/qwen3.8-flash-next-3x170hx by clee on GitHub, posted by @c133, 2026-10-04 clee's posts: his cards are not lane-modded at all, which is why the setup uses PP3, and it should also work on two cards at PP2 with less KV cache. The 2026-10-11 update added NVMe storage for a persistent KV cache between server restarts, so a long agent session resumes quickly after a restart; with it he can hardly tell 2 cards from 3, and switching between sessions is seamless even on a Gen3 NVMe SSD. He had no benchmark yet for loading a large session from NVMe after a fresh start. Source: @c133, 2026-10-04Source: @c133, 2026-10-04Source: @c133, 2026-10-11Source: @c133, 2026-10-11Source: @c133, 2026-10-11 ### Qwen3.8 Flash Next on 3x or 4x 8 GB (zebgop-ops FP8 PP) Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_3x_or_4x_8_GB_(zebgop-ops_FP8_PP) The official FP8 checkpoint of Qwen3.8-Flash-Next served with vLLM pipeline parallel, MTP speculative decoding and prefix caching all at once, on three or four 64 GB cards at PCIe Gen2 x4 with no P2P and a 200 W cap. flipnburn (GitHub zebgop-ops) first posted it on three cards (76 tok/s decode, about 10,000 tok/s prefill) and moved to four cards on 2026-09-02: PP4 with full CUDA graphs reaches 89 tok/s single-stream, 429 to 433 tok/s at 8 concurrent and about 11,000 tok/s prefill, with a 2.5M-token KV pool. The repo also fixes the bug that made PP, MTP and prefix caching unusable together (constant-token "ductductduct" loops, patch 0010) and JSON mode under PP plus speculative decoding (patch 0016). Infobox numbers are the repo's own readings at 200 W; nobody else had re-run them on these cards when this was written. Source: repo github.com/zebgop-ops/qwen38-flashnext-pp by zebgop-ops on GitHub, posted by @flipnburner, 2026-08-29 ### Qwen3.8 Flash Next on 4x 8 GB Source: https://cmp.wiki/wiki/Qwen3.8_Flash_Next_on_4x_8_GB Qwen3.8 Flash Next on four cards in one docker-compose file, on the wtdcode/vllm-backport image, with only 32 GB of host RAM: the n-gram (PLE) table stays on the GPUs (VLLM_PLE_CPU_OFFLOAD=0), so the host needs little memory. TP4 with expert parallel, MTP with 3 draft tokens, YaRN for a 1M-token context. matstatman calls it a huge upgrade over Qwen3.8 27B, which "thinks forever". Infobox decode is fresh code generation; prefill is the 32K run. Source: @matstatman, 2026-10-16 Source: @matstatman, 2026-10-16 Other four-card setups (official FP8 with pipeline parallel reaches about 200 tok/s) are compared under Other four-card setups. Facts that hold for every Qwen3.8 Flash Next recipe (model size, the n-gram table, speculative decoding, quant choice, concurrency) are collected once, under Facts shared by every Flash Next recipe. ### Recipe finder Source: https://cmp.wiki/wiki/Recipe_finder Find a recipe that fits your cards. Choose the card variant, how many cards you have, the model, the engine and what your links can do (P2P, PCIe generation and width); an empty box matches anything. The results list every matching recipe page with its numbers and keep decode with one user, total decode with many users and prefill apart, because they measure different things. "not stated" means the recipe page does not give that value: open the recipe, and add the value there if you know it. Have a whole setup in mind (card count, memory per card, PCIe link, P2P, ECC)? The Setup matrix sorts every recipe by whether it runs on that setup and labels each speed as measured, estimated or unknown. ### Recipes Source: https://cmp.wiki/wiki/Recipes A recipe is a model running on CMP 170HX cards with the exact settings and the numbers that came out. Each recipe page has an infobox (model, quant, engine, cards, topology, tok/s, power, status), the steps, the measured numbers with their conditions, known issues and credits. All recipes lists every recipe page as a sortable table. The Recipe finder filters them by card variant, number of cards, model, engine, P2P, PCIe link and status, and shows decode with one user, decode with many users and prefill side by side. How to read the numbers: unless a page says otherwise, the infobox decode is one user on code, and prefill is a cold prompt read. Most recipe authors use the MiaAI-Lab protocol (400-token answers, temperature 0, thinking off) and report three columns, structured / code / prose; code is usually the middle one and prose the slowest. Numbers from different protocols, power caps (140 to 250 W) and link widths (x4 or x16) are not directly comparable. Every number with its setup is on Benchmarks. Almost everything here runs on the 8 GB card unlocked to 64 GB with the 74-SM unlock (see 8 GB card and Driver unlock). Five runs on the 10 GB card (at the 40 GB profile) have recipe pages; they and the other runs posted for it are in the variant section below. ### Running one model across two hosts (100 GbE, RDMA, vLLM and SGLang) Source: https://cmp.wiki/wiki/Running_one_model_across_two_hosts_(100_GbE,_RDMA,_vLLM_and_SGLang) Two hosts can serve one model when each host runs whole pipeline stages and only a small hand-off crosses the network. The lab runs the full GLM-5.3 (753B) this way: two RTX PRO 6000 Blackwell cards in one host run the first pipeline stage, eight unlocked 8 GB cards in a second host run the other four, and one direct 100 GbE cable joins the two (GLM 5.3 on 8x 8 GB plus 2x RTX PRO 6000 (vLLM TP2 x PP5)). It has also split prefill and decode of GLM-5.3-Flash between the same two hosts. This page is the general procedure: the link, the GPU-to-GPU data paths that skip host memory, the vLLM settings, prefill/decode disaggregation, and the traps. Inside one host the same ideas run over PCIe; those are on P2P and Parallelism over the PCIe link and are only summarised here. Every lab number on this page was measured on vLLM. SGLang is covered with pointers to its documentation. ### Speculative decoding on the 170HX Source: https://cmp.wiki/wiki/Speculative_decoding_on_the_170HX Speculative decoding lets a small drafter propose several tokens that the full model then checks in one forward pass; every accepted token saves a decode step, and the target model still verifies every token it keeps. Three drafters come up on the CMP 170HX: MTP, the multi-token-prediction head that Qwen and GLM models ship; DFlash2, a separate small draft model; and DSpark, the drafter of the DeepSeek V4 and V4.1 Flash ports, also used in some Qwen3.8 27B benchmarks. How much they help depends on the work: acceptance is high on code edits, structured output and short synthetic prompts, lower on prose and real codebases, and the gain shrinks as context grows. Temperature moves it as well. State model, drafter, quant, temperature and context with every tok/s figure, and compare recipes only on equal benchmarks (Benchmarks). Engine background is on Engines and llama.cpp on CMP cards; vLLM bugs that involve MTP (prefix caching, the PP drafter embedding, schema-constrained output) are on vLLM on sm_80: known bugs and patches. ### VLLM on sm 80: known bugs and patches Source: https://cmp.wiki/wiki/VLLM_on_sm_80:_known_bugs_and_patches The CMP 170HX is a GA100 card, compute capability sm_80. Upstream vLLM targets Hopper, Blackwell and Ada first, has no sm_80 path for some attention kernels, and rarely runs the pipeline parallel plus speculative decoding layouts that CMP rigs depend on, so every CMP vLLM recipe carries a patch set. The entries below are the bugs owners hit, what fixed them and which patch set carries the fix. Engine choice and the list of forks are on Engines; drafter tuning is on Speculative decoding on the 170HX; layouts are on Parallelism over the PCIe link. First checks when a vLLM setup misbehaves, each explained below: Use the exact vLLM build or nightly the recipe's patches target; patch scripts break silently on newer ones. When a setup that used to work breaks, clear the compile and kernel caches before anything else. For wrong or garbled output, make the fault reproducible as M out of N runs, then bisect with MTP off and CUDA graphs off. With MTP, DSpark or DFlash, send temperature 0 and check the logged acceptance; a very low acceptance under PP points to a drafter bug, not the model. Serve schema-constrained requests (forced tool calls, JSON schema) from a config without speculative decoding unless the build fixes structured output under speculation. Measure with vLLM's own benchmark or a wall clock, not with other tools' numbers or vLLM's logged rates. ## Platforms ### All platforms Source: https://cmp.wiki/wiki/All_platforms Every platform report: boards and servers people ran CMP 170HX cards in, with the settings that mattered. Click a column heading to sort; long values are cut to one line, hover for the full text or open the report. Filter by card variant: 8 GB only · 10 GB only · tested with both. Most results (Gen2, BAR1, P2P) differ between the two variants, so check the variant before copying settings. ### ASRock Rack ROMED8-2T Source: https://cmp.wiki/wiki/ASRock_Rack_ROMED8-2T A single-socket SP3 board with seven x16 slots, often named as the turnkey EPYC board for multi-card builds. ### ASUS P9X79 WS Source: https://cmp.wiki/wiki/ASUS_P9X79_WS Fernando Delfini could not unlock a card on his X79 WS board at first and asked whether the platform's MMIO limits were the cause. Source: @fdelfini, 2026-10-19 ### ASUS Pro WS WRX80E-SAGE SE WIFI Source: https://cmp.wiki/wiki/ASUS_Pro_WS_WRX80E-SAGE_SE_WIFI ASUS's sWRX8 workstation board for Threadripper Pro. Two board-specific problems are on record: it holds the cards in a hardware power brake through PCIe pin B30 until that pin is taped, and at least one owner could not get the 64 GB BAR1 assigned. ### ASUS Pro WS WRX90E-SAGE SE Source: https://cmp.wiki/wiki/ASUS_Pro_WS_WRX90E-SAGE_SE GhostInTheDatacenter has the same BAR1 problem on an ASUS WRX90 board as Trust Inter on his WRX80E, with no fix found; his agent ended up suggesting an ASUS support ticket for a BIOS change. Source: @ghostinthedatacenter_87281, 2026-10-07Source: @ghostinthedatacenter_87281, 2026-10-11 He tried AnalyticETH's beta BAR1 work in AnalyticETH/cmpunlocker (https://github.com/AnalyticETH/cmpunlocker, link dead as of 2026-11-09) without luck. Source: @analyticeth, 2026-10-07Source: @ghostinthedatacenter_87281, 2026-10-07 The curiouspixel P2P patch in the Morrowmake fork fixed P2P for him, but not BAR1. Source: @ghostinthedatacenter_87281, 2026-10-07 He later warned anyone buying new to watch out for ASUS boards because of BAR sizing. Source: @ghostinthedatacenter_87281, 2026-10-22 (The board was given as "Asus wrx90"; the Pro WS WRX90E-SAGE SE is ASUS's WRX90 board.) ### ASUS X99-E WS Source: https://cmp.wiki/wiki/ASUS_X99-E_WS matstatman runs four cards on a used ASUS X99-E WS (PCIe Gen3) with an E5-2695 v4 (15 USD) and DDR4 UDIMM. Source: @matstatman, 2026-10-07Source: @matstatman, 2026-10-07Source: @matstatman, 2026-10-15 The board has a PLX switch (Miséricorde). Source: @wakeupmbrc1, 2026-10-18 In the September thread on this board the switch is a PLX PEX 8747. Source: @matstatman, 2026-09-11 ### ASUS Z10PE-D8 WS Source: https://cmp.wiki/wiki/ASUS_Z10PE-D8_WS This page is one owner's report, nothing more: GitHub user ahnguyen17 posted it as issue 2 on the Consensus-Protocol research wiki's repository on 2026-08-31, after testing on 2026-08-30 and 31. Nobody else has posted a result on this board. On it the memory unlock and the 64 GB BAR1 work on both card variants, and the Gen2 retrain never took. Source: repo github.com/Consensus-Protocol/cmp170hx/issues/2 by Consensus-Protocol on GitHub ### BAR1 64 GB on ESXi Source: https://cmp.wiki/wiki/BAR1_64_GB_on_ESXi How to give CMP 170HX cards that VMware ESXi passes through to a Linux guest a real 64 GB BAR1. ESXi does not do it by itself. It takes two parts: a small UEFI program that resizes BAR1 on the host before ESXi boots, and a guest-side hook that restores the card's override after every VM power-on. Everything here was measured on one host in October 2026; the code, the build files and the full write-up are in darkmaniac7/cmp170hx-esxi. Source: repo github.com/darkmaniac7/cmp170hx-esxi by darkmaniac7 on GitHub, posted by @darkmaniac7, 2026-10-21 (lab notes) For passthrough in general (Proxmox, the in-guest unlock, Gen2, P2P) see Virtual machines and passthrough. For BAR1 on bare metal see Resizable BAR and BAR1 64 GB and Server BIOS setup. ### Consumer motherboards Source: https://cmp.wiki/wiki/Consumer_motherboards What works on desktop, HEDT and workstation boards: which BIOS settings matter, how to split lanes, and how many cards fit. Server boards are on Platforms and Server BIOS setup. ### Dell OptiPlex 7040m Source: https://cmp.wiki/wiki/Dell_OptiPlex_7040m Asked whether anyone had run the card as an eGPU, GlobalApathy described his: a Dell OptiPlex 7040m micro PC (16 GB single stick), an M.2-to-OcuLink adapter in place of the SATA M.2 drive (moved to a 2.5 inch carrier), an OcuLink external GPU frame and a spare 1000 W PSU. Source: @tchelobh, 2026-10-18Source: @globalapathy, 2026-10-18Source: @globalapathy, 2026-10-19 ### Dell PowerEdge R720 Source: https://cmp.wiki/wiki/Dell_PowerEdge_R720 Nobody has reported a CMP 170HX in an R720 yet. mlx4 used 32 GB LRDIMMs in one and wondered whether a 170HX would fit. Source: @mlx4, 2026-10-09Source: @mlx4, 2026-10-09 ### Dell PowerEdge R730 Source: https://cmp.wiki/wiki/Dell_PowerEdge_R730 ElectroHobo had 170HX cards and V100s in the same Dell R730 under Proxmox while first testing the 170HX, in separate VMs rather than one model across both kinds of card. Source: @nathang6866, 2026-10-25 ### Dell PowerEdge R740 Source: https://cmp.wiki/wiki/Dell_PowerEdge_R740 No full CMP 170HX result on an R740 has been posted yet. A testing task for Gen2 and BAR1 on an R740 is a good candidate for the board. ### Dell Precision T5810 Source: https://cmp.wiki/wiki/Dell_Precision_T5810 Shudza suggested a T5810 instead of Chinese X99 boards. kellertreppe123 owns one with a CMP: Source: @shudza, 2026-10-07 you need unusual cables just to power one card; the fan PWM controls are locked down on Linux; there is very little space in front of the card; otherwise solid if you find one for about 120 EUR with 32 to 64 GB DDR4. For a second machine he would pick the Lenovo workstation of the same era. Source: @kellertreppe123, 2026-10-07Source: @kellertreppe123, 2026-10-07Source: @kellertreppe123, 2026-10-07Source: @kellertreppe123, 2026-10-07 endsjeremy, who did Dell warranty support, warns that Dell systems lock you into Dell parts; swapping PSUs, for example, was a fire risk. Source: @endsjeremy, 2026-10-07 ### Gen2 by platform Source: https://cmp.wiki/wiki/Gen2_by_platform Gen2 doubles the PCIe link rate of a CMP 170HX from 2.5 to 5 GT/s, and whether it trains depends far more on the host than on the card. This page collects the reported results by board, CPU, operating system, kernel and driver, from the first Gen2 branch in July 2026 to early October 2026: a table first, then the detail behind each row. How the unlock works and how to install it is on Gen2 link retrain; how to check the link is on Verifying an unlock. Most rows date from July to September 2026 and name the branch or fork where the post did, so retest a board that failed on an early branch with a current release before you call it bad. Gen2 inside a virtual machine has its own section below and its own page, Proxmox Gen2 passthrough. ### Gigabyte G292-Z20 Source: https://cmp.wiki/wiki/Gigabyte_G292-Z20 A 2U single-socket EPYC GPU server that takes 8 cards. Several members run it; the trade-off is noise. ### Gigabyte G481-HA0 Source: https://cmp.wiki/wiki/Gigabyte_G481-HA0 RedPandaMining runs all his cards at x16 in a G481-HA0 bought for about 500 USD with dual Xeon Gold 6152, 384 GB DDR4-2666 and 4 TB NVMe. He still has access to a US seller with many of these servers but cannot name them. Like other GPU servers it is not apartment friendly. Source: @redpandamining, 2026-10-04Source: @redpandamining, 2026-10-04 ### Gigabyte MZ31-AR0 Source: https://cmp.wiki/wiki/Gigabyte_MZ31-AR0 Finishtilt14 runs CMPs on an MZ31-AR0. It has 5 physical x16 slots (one of them wired x8) and 2 physical x8 slots, so two of his cards are limited to x8 by the slots. Source: @finishtilt14, 2026-10-09Source: @finishtilt14, 2026-10-09 He also runs Morrowmake's 4-card recipe without the x16 capacitor mod, in TP or PP. Source: @finishtilt14, 2026-10-13 ### Gigabyte MZ32-AR0 Source: https://cmp.wiki/wiki/Gigabyte_MZ32-AR0 A single-socket SP3 EPYC board with 16 DIMM slots. zorg33 runs 14x 8 GB CMP 170HX on one (photo posted). Source: @zorg33, 2026-10-23 ### Huananzhi H12D-8D Source: https://cmp.wiki/wiki/Huananzhi_H12D-8D A Chinese single-socket EPYC (SP3) board (华南金牌 H12D-8D). Every slot comes from the CPU (128 lanes, nothing on a chipset, one root port per slot), which is what P2P wants. Some notes call it a Supermicro board; it is Huananzhi's. ### Huananzhi X99-F8 Source: https://cmp.wiki/wiki/Huananzhi_X99-F8 Miséricorde runs two cards on a Huananzhi X99-F8 (DDR4) and calls the Huanan boards the best base for two 8 GB cards: cheap, PCIe 3.0, NVMe, working sleep, fast boot, and better behaved than typical AM5 boards. Source: @wakeupmbrc1, 2026-10-07Source: @wakeupmbrc1, 2026-10-07 ### Hyve Edge Metal G10 Source: https://cmp.wiki/wiki/Hyve_Edge_Metal_G10 port00 has two of these servers. They have two PCIe 4.0 x24 slots, and an x16 riser cable in an x24 slot "works flawlessly". Source: @port00, 2026-10-23 ### Large rigs (8 or more cards) Source: https://cmp.wiki/wiki/Large_rigs_(8_or_more_cards) Several members run eight or more CMP 170HX cards from one host, and a few run 16 to 45. This page collects what they posted: how many cards are worth it, where hosts run out of PCIe lanes, the builds on record by size, and what that many cards cost in heat, power and noise. Most of these rigs split models with pipeline parallel over PCIe (Parallelism over the PCIe link). Switch-board hosts are on PCIe switch boards, the most common 8-card server on Gigabyte G292-Z20, mining-case builds on Octominer X12 Ultra builds and enclosures on Chassis builds. ### Minisforum MS-01 Source: https://cmp.wiki/wiki/Minisforum_MS-01 A small Intel workstation with the cards on an external PLX 88096 switch board. It works for the VRAM unlock; the 64 GB BAR1 and P2P are where it struggles. ### Octominer X12 Ultra builds Source: https://cmp.wiki/wiki/Octominer_X12_Ultra_builds Octominer mining cases house, power and cool a row of GPUs, which makes them a ready-made frame for passive CMP 170HX cards. Two members describe builds in the X12 Ultra laid out two different ways; segmond's holds 12 cards (reala did not give his card count). Summary of their posts; see Discord for the photos. The short version from the older history: the case, its PSUs and its fans are excellent; the stock board (x1 slots, a weak CPU, little RAM, no NVMe) is not. Most builders keep the case and replace or bypass the board. ### Operating systems and kernels Source: https://cmp.wiki/wiki/Operating_systems_and_kernels Which operating systems, kernels and driver versions people run unlocked CMP 170HX cards on, and what broke. Linux with the patched open kernel modules is the normal path. The unlock itself is covered on Unlocks; this page is about the host software around it. ### PCIe switch boards (PEX88096, PEX88064, PEX8747, PLX8749) Source: https://cmp.wiki/wiki/PCIe_switch_boards_(PEX88096,_PEX88064,_PEX8747,_PLX8749) A PCIe switch board takes one host link, usually Gen4 x16, and fans it out to several cards. A Broadcom PEX88096 gives 5 slots at x16, 10 at x8 or 20 at x4; the PEX88064 is a smaller, slightly cheaper sibling; the older PEX8747 and PLX8749 cards (Gen3) turn one x16 slot into x16+x16 or 4x4. Cards behind the same switch can exchange data directly (P2P) without going through the CPU, so owners use these boards to run 5 to 10 cards from a consumer board, a mini PC or a host short on lanes. With several cards and 64 GB BAR1 behind a switch, Linux needs a large MMIO window, ACS redirect turned off on the switch ports and, on most hosts, two kernel patches (see Kernel side). For Gen2 retrain problems behind a switch see Driver and unlock failures. ### Platforms Source: https://cmp.wiki/wiki/Platforms Which motherboards, servers and hosts people run CMP 170HX cards on, and what worked on each. Every row links to a page with the details and sources. For a step-by-step on a server, start at Server BIOS setup; for desktop and workstation boards, Consumer motherboards; for slots, risers and switches, Risers and bifurcation and PCIe switch boards; for hypervisors, Virtual machines and passthrough and Proxmox Gen2 passthrough; for distros and kernels, Operating systems and kernels. Hosts with 8 or more cards: Large rigs (8 or more cards). The live list of every platform report, with computed status, is All platforms. To add yours, use Form:Platform. ### Proxmox Gen2 passthrough Source: https://cmp.wiki/wiki/Proxmox_Gen2_passthrough Under Proxmox (QEMU/KVM with VFIO) an unlocked CMP 170HX gets its 64 GB inside a VM, but the PCIe Gen2 link does not come up by itself. The guest cannot retrain the physical root port the card hangs off, and QEMU intercepts the bus resets the bare-metal Gen2 patch uses. Every method that worked has the Proxmox host retrain the root port to Gen2 at the right moment: from a VM hookscript, from a host daemon the guest asks, or from a host watcher that fires once during guest driver init. This page is the dated history of those methods and the two published tools. Where to run the unlock and the general VM setup are on Virtual machines and passthrough; the bare-metal retrain is on Gen2 link retrain. All reports here are 8 GB cards or do not say. ### Risers and bifurcation Source: https://cmp.wiki/wiki/Risers_and_bifurcation How cards get connected when the board has too few slots, the wrong slot widths, or slots too close together: riser cables, M.2 and OcuLink adapters, SlimSAS cabling, PCIe switch boards and slot bifurcation. For BIOS settings see Server BIOS setup; for boards see Platforms and Consumer motherboards; for switch boards in depth see PCIe switch boards (PEX88096, PEX88064, PEX8747, PLX8749). ### Server BIOS setup Source: https://cmp.wiki/wiki/Server_BIOS_setup How to get a CMP 170HX to PCIe Gen2 and a 64 GB BAR1 on a server, and what to check when it does not happen. It comes from getting 8 cards to Gen2 x16 with 64 GB BAR1 on bare metal, and 4 cards to Gen2 with 64 GB BAR1 under ESXi passthrough. The page works as a checklist. Source: @darkmaniac7, 2026-10-29 (lab notes) For what the two features are, see Gen2 link retrain and Resizable BAR and BAR1 64 GB. For desktop boards, see Consumer motherboards. For hypervisors, see Virtual machines and passthrough. ### Supermicro H12DSG-O-CPU Source: https://cmp.wiki/wiki/Supermicro_H12DSG-O-CPU The reference box for Server BIOS setup: 8 cards, all at Gen2 x16 with a 64 GB BAR1, on bare metal. Source: @darkmaniac7, 2026-10-29 (lab notes) The infobox shows Reported because no second owner has confirmed this board yet (see Status taxonomy); the P2P result below is the lab's own measurement with numbers, so that fact carries Proven. ### Supermicro SYS-1028GQ-TRT Source: https://cmp.wiki/wiki/Supermicro_SYS-1028GQ-TRT A 1U dual-socket Supermicro server on the X10DGQ board that takes four double-width GPUs lying flat. Used units sold for under 200 USD in 2026, which makes it the cheapest four-card host on record. One owner runs four 10 GB cards in it at Gen2 x4 with no power-brake throttling. Nobody has posted an 8 GB card result, a P2P test or a tensor-parallel test on it yet. It is very loud. ### Supermicro SYS-4028GR-TRT2 Source: https://cmp.wiki/wiki/Supermicro_SYS-4028GR-TRT2 A 4U dual-socket GPU server with 10 GPU slots, all on CPU1 behind two PCIe 3.0 switches. Humvee55 and bayley_w call it the cheapest platform with working P2P; it is where the first working CMP P2P was built. ### Supermicro X11SPA-TF Source: https://cmp.wiki/wiki/Supermicro_X11SPA-TF djpandaman used this workstation board for multi-card testing before deploying his builds, and called it "kind of trash". Source: @djpandaman, 2026-10-09Source: @djpandaman, 2026-10-09 ### Tyan S8030GM2NE Source: https://cmp.wiki/wiki/Tyan_S8030GM2NE djpandaman runs a Tyan S8030GM2NE with an EPYC 7R13 (48 cores, ex-datacenter stock) and 256 GB DDR4; CPU and board cost about 850 USD together. It has five x16 slots: enough for four cards at x16 plus a PLX switch. He thinks EPYC 7002 is probably better value than 7003. Source: @djpandaman, 2026-10-12Source: @djpandaman, 2026-10-12 He picked it after a lot of research. Source: @djpandaman, 2026-10-22 Earlier he gave the best value as a Tyan board plus EPYC 7R13 for 5500 yuan (about 820 USD). Source: @djpandaman, 2026-10-10 He bought the board from the Taobao shop 苏锐服务器 (shop id 69496519); a new one in box should be about 3000 yuan. Source: @djpandaman, 2026-10-12Source: @djpandaman, 2026-10-12Source: @djpandaman, 2026-10-12Source: @djpandaman, 2026-10-12 He runs his cards behind a 10-port PLX 88096 switch board (2x 8i connection). Source: @djpandaman, 2026-10-22Source: @djpandaman, 2026-10-22 His 10 GB cards were at Gen3, and he validated Gen4 on his PLX switch while still on a Gen3 board. Source: @djpandaman, 2026-10-09Source: @djpandaman, 2026-10-09 ### Virtual machines and passthrough Source: https://cmp.wiki/wiki/Virtual_machines_and_passthrough Running CMP 170HX cards inside a virtual machine works, with more moving parts than bare metal. The short version: Unlock where the NVIDIA driver runs. Under Proxmox/QEMU most people unlock on the host and pass the unlocked card in; in-guest unlocks also work on some stacks, and which route is better is contested (below). Under ESXi the unlock runs inside the guest. 64 GB VRAM works in a VM. It does not need a big BAR1. Gen2 works in a VM, but how it is done differs per hypervisor, and the Gen2 path has caused guest hangs under Proxmox for some people. The guest cannot retrain the physical port by itself. 64 GB BAR1 in a VM is hard (ESXi needs a pre-boot step on every host boot). P2P between CMPs inside a VM has not been shown to work. One Proxmox owner says it runs for him but posted no configuration or numbers; every verified CMP P2P result is on bare metal or a host kernel. On 2026-11-07 an ESXi owner posted a screenshot of P2P enabled, also without details (see below). Source: @.nightdays, 2026-11-07 Bare metal is much simpler. Source: @darkmaniac7, 2026-10-29 (lab notes) See also Server BIOS setup (case D), Operating systems and kernels, Gen2 link retrain, Proxmox Gen2 passthrough, Gen2 by platform, Resizable BAR and BAR1 64 GB, P2P. ## Cooling and power ### ASRock PG-1600G Source: https://cmp.wiki/wiki/ASRock_PG-1600G The ASRock PG-1600G is a 1600 W ATX power supply, not a motherboard. It is on the platforms list because people pair it with CMP builds and because its modular connector pinout differs from cables made for other PSU brands. For power in general see Cooling and power. ### Blowers Source: https://cmp.wiki/wiki/Blowers A blower (a centrifugal or "turbine" fan) fixed to the intake end of the card is the most common way to air-cool a CMP 170HX outside a server chassis. It builds pressure at a lower speed than an axial fan, keeps the card two slots wide and does not depend on case airflow. The costs are length (a card with a blower adapter can pass 40 cm) and a sound that some owners cannot live with. The usual choice is a 97 x 97 x 33 mm (9733) 12 V 4-pin PWM blower rated 1 A or more, on a printed adapter or taped on, with its speed driven from the card temperature. Axial fans, shrouds, fan control and header current limits are on Fans and ducts; printable files are indexed on Printable shrouds and ducts. ### Chassis builds Source: https://cmp.wiki/wiki/Chassis_builds Two cards fit in most desktops with a shroud and a pair of fans. Past four cards the questions change: where the air comes from and where it goes, how many circuits you have, and how loud the room can be. This page collects the builds people posted, with their cooling and power. Photos were posted in the linked Discord messages; the descriptions below are the posters' own words, since the images are not part of the import. ### Cooling and power Source: https://cmp.wiki/wiki/Cooling_and_power The CMP 170HX is a passive data-center card. It has a large copper heatsink and no fan. It was built for a server that forces air through its fins, so on a desk or in a normal case it overheats unless you add that airflow yourself or fit a water block. This page is the short version. The detail lives on the pages listed at the end. ### Disassembly and cleaning Source: https://cmp.wiki/wiki/Disassembly_and_cleaning Ex-mining CMP 170HX cards usually arrive dirty inside, with stock paste gone hard and thermal pads sometimes missing, even when the shroud and the outer fins look clean. This page covers protecting yourself, what to expect inside, opening the card, getting the stock cooler off without breaking parts, and cleaning it. Paste, pads and phase-change material are on Thermal interface: paste, pads and phase-change, water blocks on Water cooling, and the x16 capacitor mod, which also needs the card open, on PCIe x16 capacitor mod. Testing a newly arrived card is on Acceptance checklist. ### Fans and ducts Source: https://cmp.wiki/wiki/Fans_and_ducts The CMP 170HX has no fan of its own. You add one, and you make sure its air goes through the heatsink fins and not around the card. This page collects what people run, with the numbers they posted. Start with Cooling and power if you have not read it. Blowers and printable parts have their own pages with more detail: Blowers and Printable shrouds and ducts. ### P-states and idle power Source: https://cmp.wiki/wiki/P-states_and_idle_power A stock CMP 170HX idles at about 30 to 45 W per card (about 27 W on one 10 GB card), and more with a model loaded. That is heat a passive card still has to get rid of, and it adds up in a multi-card box. The card has only two p-states, so the usual p-state tools do nothing. With 170tune's idle settings and the idle gate patches people reach 23 to 29 W per card, close to what A100 PCIe screenshots show at P8 (what an A100 really idles at is contested, below). ### Power supplies and cabling Source: https://cmp.wiki/wiki/Power_supplies_and_cabling The CMP 170HX takes all its power through one EPS12V socket. Most failures in the Discord came from feeding that socket wrongly: one PSU cable split two ways, pigtails, thin adapters, or a modular cable from a different PSU brand. Read the rules below before you plug anything in. Burned and failed hardware is collected under Power and cabling warnings. ### Printable shrouds and ducts Source: https://cmp.wiki/wiki/Printable_shrouds_and_ducts The CMP 170HX is a passive card: an air-cooled card needs a shroud, duct, plenum or housing that forces air through its fin stack. This page indexes the printable designs members use, with the fan each one takes, how many cards share a fan, the best result on record and who made it. Public models on Thingiverse, Printables, MakerWorld and Cults3D are linked. Files that were only posted as Discord attachments are listed with credit and a link to the post; they are not hosted on this wiki, so ask the author before re-sharing one, and where a file is a remix of a public model, use the public original. Fan choice, static pressure and sealing are on Fans and ducts; blower models and sizing are on Blowers. ### Thermal interface: paste, pads and phase-change Source: https://cmp.wiki/wiki/Thermal_interface:_paste,_pads_and_phase-change The GA100 die and its HBM2e stacks on the CMP 170HX sit under an integrated heat spreader (IHS), so the card has two thermal interfaces in series: a factory one between the die and the IHS, held under a glued lid, and the one between the IHS and the cooler, which is what you replace when you repaste. Around the package, pads (or putty) carry heat from the power components and the small parts near the core into the heatsink. On used cards the paste on top of the IHS is often dry and pads are missing, but a fresh interface on top gains anywhere from nothing to a large drop, and many owners blame the old paste under the lid. Opening and cleaning the card are on Disassembly and cleaning, temperature limits on Thermal limits and water blocks on Water cooling. ### Thermal limits Source: https://cmp.wiki/wiki/Thermal_limits The CMP 170HX runs hot for its power, and it has two temperatures that matter: the GPU core and the HBM memory. Under load the HBM is usually the hotter one, and it is the one that limits memory overclocks and corrupts data first. Keep the core under about 80 C and the HBM under about 80 to 85 C for daily use. The driver itself lists 85 C as the core's maximum operating temperature, 95 C as slowdown, 98 C as shutdown and 95 C as the memory's maximum. ### Undervolting and power limits Source: https://cmp.wiki/wiki/Undervolting_and_power_limits 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. ### Undervolting guide: where it came from Source: https://cmp.wiki/wiki/Undervolting_guide:_where_it_came_from Where the community's undervolting guidance came from, in date order. The Discord thread "Undervolting CMP170HX 8GB version GUIDE" is not where it began: the thread opened on 2026-10-02 as a request, and the first written guide had been posted more than two months earlier, on 2026-07-27. The method in every guide is cachenetics' 170tune, a V/F-offset undervolt through NVML. How to undervolt today is on Undervolting and power limits; this page records who wrote what, and when. Long guides by one person appear here as pointers until their authors agree to have them hosted. ### Water cooling Source: https://cmp.wiki/wiki/Water_cooling Water is the quiet option. The card's stock heatsink needs server-class airflow; a full-cover block on a loop runs silently at 45 to 60 C. It costs more than fans and you have to take the card apart, which on used cards usually means cleaning and new pads too. Pads, paste and phase-change material have their own page, Thermal interface: paste, pads and phase-change, and so does opening the card: Disassembly and cleaning. ## Troubleshooting ### Card failure rates and longevity Source: https://cmp.wiki/wiki/Card_failure_rates_and_longevity How many CMP 170HX cards arrive bad, fail the 64 GB unlock or die in service is one of the most argued questions on the Discord. Owner counts posted from July to October 2026 run from 0% (several all-good batches) through single digits and about 20% to 50% (one buyer who lost 2 of 4). The counts are self-reported and not standardized; @n2dcrypt asked for standardized community testing in August 2026. This page collects the counts with their sources, the early-death reports, and the competing explanations for why cards fail and how long they last. What to test on arrival is on Acceptance checklist and Testing and burn-in, temperature limits on Thermal limits, and buying advice on Buying. ### Card not detected or BAR allocation fails Source: https://cmp.wiki/wiki/Card_not_detected_or_BAR_allocation_fails This page covers a CMP 170HX that does not show up, shows up in the wrong state (missing from nvidia-smi, wrong PCIe link width or speed), or cannot get its large BAR1 window. Work from the lowest layer up: do not reinstall a driver when the host cannot see the card.Source: repo github.com/PixelML/club-170hx by PixelML on GitHub, posted by @c133, 2026-10-20 For which card you have and what it unlocks to, see Which card do I have. For the unlock itself, see Driver unlock. ### Dead ends: what was tried and did not work Source: https://cmp.wiki/wiki/Dead_ends:_what_was_tried_and_did_not_work Things owners tried on the CMP 170HX (and a few relatives) that did not work, one line each, grouped by area. Each line links to the "What was tried and did not work" section of the page that holds the full entry, with the date, who tried it, the outcome and the sources. Read the full entry before you try the same thing again: several of these cost a card a reset, a reflash or a day. A dead end here means it was tried, or argued down, and did not work at the time. Some July 2026 dead ends work now; they are in the table at the end, not in the lists. ### DeepSeek V4 and V4.1: tool-call leaks, loops and crashes Source: https://cmp.wiki/wiki/DeepSeek_V4_and_V4.1:_tool-call_leaks,_loops_and_crashes DeepSeek V4 Flash (the 0731 checkpoint) and V4.1 Flash, served with the sm_80 vLLM forks on the CMP 170HX, share a family of agentic failures: tool calls that come back as raw DSML markup, reasoning text that leaks into the reply and is then sent back as conversation history, "Let me check..." loops that never make the call, and, deep into long contexts, wrong tokens and engine crashes. Most leaks are parser and chat-template gaps with published patches; the repetition loops past about 100k tokens are mitigated, not solved. Recipes: DeepSeek V4 Flash 0731 on 4x 8 GB (allover326 PP4 DSpark) for V4 and the V4.1 pages under Related. Engine-wide bugs are on vLLM on sm_80: known bugs and patches. ### Driver and unlock failures Source: https://cmp.wiki/wiki/Driver_and_unlock_failures If a CMP 170HX still shows 8 GB or 10 GB after the unlock, or is missing from nvidia-smi, check four things first: use driver 615.71.09 and not 615.78.08, do a cold boot and not an OS reboot, confirm the patched module ran with sudo dmesg | grep SEC2_DEBUG (no output means the stock module loaded), and make sure the installer ended with its summary table. Each of these has a section below. The rest of the page covers the other failures while installing or running the patched driver (cmpunlocker and its forks), the tools built on it (170tune, the RIR tools), a link that stays at Gen1, kernel and GSP problems, P2P, and the operations that cannot be undone. For the unlock procedure itself see Driver unlock; for what each variant can unlock see Unlocks; for the checks that prove an unlock see Verifying an unlock. ### HW Power Brake (PWRBRK) Source: https://cmp.wiki/wiki/HW_Power_Brake_(PWRBRK) PWRBRK# is an optional PCIe sideband signal on edge pin B30 that lets a platform force a GPU into an emergency low-power state. Some motherboards and risers assert it all the time, and the CMP 170HX obeys it. A braked card unlocks, links and loads models normally, but sits at about 80-88 W and 1140 MHz and runs roughly 4x slower than a healthy one. nvidia-smi shows it as "HW Power Brake Slowdown: Active". The fix is tape over pin B30 or a riser that does not carry B30. Most boards never assert it, so check before you tape anything. ### Instability under load Source: https://cmp.wiki/wiki/Instability_under_load This page covers a CMP 170HX that works at idle but crashes, drops off the bus, throttles or returns wrong output under load. Most reports trace to one of five things: power delivery, heat, too much undervolt, too high an HBM clock, or (on 10 GB cards) unlocked SMs that are not good. A card stuck near 80-88 W and 1140 MHz is usually a board asserting the PCIe power brake (see the HW Power Brake subsection under Power, and HW Power Brake (PWRBRK)). Some "bad output" is an engine bug, not the card; that is near the end of the page, followed by host faults that look like card faults. ### Known bad combinations Source: https://cmp.wiki/wiki/Known_bad_combinations Combinations that failed for at least one person, with what happened and what worked instead. A single report does not prove a part is bad for everyone; it tells you what to try first when you hit the same thing. Each row links to the page with the full story. If something here works for you, say so on the talk page with your setup. ### Memory errors and ECC Source: https://cmp.wiki/wiki/Memory_errors_and_ECC This page covers memory faults on the CMP 170HX: what they look like, how to test a card, how people work around bad regions, what the ECC added in cmpunlocker v0.5 does and does not show, and host-side memory problems that look like card faults. Crashes from heat and clocks are on Instability under load; error numbers are on Xid errors. Full-VRAM crashes and Xid 31 from the reserved top of unlocked VRAM are not bad HBM: they are summarized in their own section below and detailed on Xid 31 and the reserved top of VRAM. ### Power and cabling warnings Source: https://cmp.wiki/wiki/Power_and_cabling_warnings This page lists every community report of hardware that burned, melted, blew, shorted, shut down or arrived damaged, with the exact failure as reported. How to power and cool the card properly is on Cooling and power; load-related crashes without damage are on Instability under load. ### Recovery Source: https://cmp.wiki/wiki/Recovery How people got unresponsive cards and hosts working again, from the cheapest step to the most drastic, what cannot be undone, and what board-level repair has worked on dead cards. Error numbers are explained on Xid errors. ### Troubleshooting Source: https://cmp.wiki/wiki/Troubleshooting Start here when a CMP 170HX does not do what it should. Find what you see in the first column, check the usual cause, and follow the link for the full story and the sources. Every fact on the linked pages is credited to the person who reported it; badges follow the Status taxonomy. ### Verifying an unlock Source: https://cmp.wiki/wiki/Verifying_an_unlock An install that reports success can still leave the stock driver running. After every install, kernel change or driver change, check three things in this order: the patched module is the one loaded, the unlock fired, and BAR1 was resized. Then confirm the link, the memory and the compute. Install steps are on Driver unlock, fixes are on Driver and unlock failures, and the full procedure for a newly bought card is on Acceptance checklist. Quick check after a cold boot (details and sources in the sections below): ### Xid 31 and the reserved top of VRAM Source: https://cmp.wiki/wiki/Xid_31_and_the_reserved_top_of_VRAM Xid 31 is the NVIDIA driver's GPU memory page fault: the MMU refused a memory access. On unlocked CMP 170HX cards it has two main sources. The first is the unlocker: early cmpunlocker builds handed the protected top of VRAM, which backs the GSP firmware's WPR2 region, to the driver's memory allocator, so ordinary allocations could land there and crash the card when VRAM was nearly full or under heavy allocation churn. That bug is fixed in cmpunlocker v0.3 (2026-08-30) and later. The second is the inference engine: int32 address overflows and oversized transient buffers in vLLM kernels raise Xid 31 at repeatable context lengths whatever unlocker you run. A short summary is on Memory errors and ECC; every Xid number is on Xid errors. First checks after an Xid 31, each explained below: Run cmpunlocker v0.3 or later, built from a fresh checkout. A failed git pull leaves the old late-PMA code in place without any error. Read the kernel log from the last driver load. A build with the fix logs that the late-PMA extension was skipped; a late-PMA range that overlaps the firmware WPR range means the fix is missing. Note the context length at the crash. An Xid 31 that comes back at the same depth or KV pool size is an engine bug: look for the engine's int64 patch. Count the Xid lines with dmesg, then reboot the host before restarting the engine. Do not reload nvidia_uvm. Test the card with cuda_memtest over 100% of memory. memtest_vulkan, and gpu-burn at its default 90% fill, do not reach the top blocks. ### Xid errors Source: https://cmp.wiki/wiki/Xid_errors An Xid is an error code the NVIDIA kernel driver writes to the kernel log when a GPU faults. This page lists every Xid number reported on CMP 170HX cards, with the cause and the fix as the person who hit it reported them. NVIDIA's own definitions are in its Xid documentation; the meanings below are what people saw on these cards. For problems that do not print an Xid, start at Troubleshooting. ## Tools ### 170hx-rir-tool Source: https://cmp.wiki/wiki/170hx-rir-tool 170hx-rir-tool reads the GA100 fuse block and can permanently burn RIR (Redundancy Information Row) records. On the 10 GB card its purpose is to burn one record pair that clears the gate fuse blocking software fuse overrides, which the Gen3 and SM unlocks build on. Author: @lxtend (lxwx, GitHub lixiangwuxian), MIT. Repository: https://github.com/lixiangwuxian/170hx-rir-tool (Chinese README: README.zh-CN.md). Source: @lxtend, 2026-10-10Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-10. A RIR write is permanent and one-shot. Fuse bits only go from 0 to 1, there is no undo, and a wrong write can cost records or brick the card. Read first. Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-10. "Use at your own risk, you can only write once." Source: @68x0, 2026-10-17 How the burn fits into the 10 GB unlocks is on Unlocks. ### 170tune Source: https://cmp.wiki/wiki/170tune 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. ### Benchmark protocol Source: https://cmp.wiki/wiki/Benchmark_protocol One way to measure a CMP 170HX inference setup, so that numbers from different people can be compared. The script cmpbench.py runs it against any OpenAI-compatible server (vLLM, SGLang, llama.cpp server, TabbyAPI) and prints the results as lines for a Recipe infobox and a Confirmation. Protocol 1.0, script 1.0. Cmpbench.py (59.5 KB, by @ImportBot, details)sha256 52b88304593b3af57dd516f2e458832a21f4f801ba3adee58d2e33724e686adc Get it with curl -L -o cmpbench.py https://cmp.wiki/wiki/Special:Redirect/file/Cmpbench.py and check its sha256 against the one shown above. ### Cmp-170hx-rir-burn-util Source: https://cmp.wiki/wiki/Cmp-170hx-rir-burn-util cmp-170hx-rir-burn-util (it calls itself cmp170hx-rir-gen3) is an all-in-one tool for the 10 GB CMP 170HX (10de:2082). It does the permanent one-shot RIR fuse burn that clears the software-override gate, then adds a volatile PCIe Gen3 unlock on top of an existing cmpunlocker Gen2 install. The burn payload comes from 170hx-rir-tool and the Gen3 register recipe from lixiangwuxian/170hx_tips; this tool adds preflight gates, state tracking, a driver patch, a retrain helper, a stress test and rollback. Author: GitHub evanrodgers, MIT. Repository: https://github.com/evanrodgers/cmp-170hx-rir-burn-util Source: repo github.com/evanrodgers/cmp-170hx-rir-burn-util by evanrodgers on GitHub, posted by @hezz1891, 2026-10-26.Source: @hezz1891, 2026-10-26 The burn is irreversible and has no retry. A failed preflight or a second write can brick the card. Rollback restores modules and configuration but never the burn. Source: repo github.com/evanrodgers/cmp-170hx-rir-burn-util by evanrodgers on GitHub, posted by @hezz1891, 2026-10-26. Read Unlocks first; members advise not spending RIR records yet (see 170hx-rir-tool#Before you burn). ### Cmp170hx-testsuite Source: https://cmp.wiki/wiki/Cmp170hx-testsuite cmp170hx-testsuite is an acceptance test suite for unlocked CMP 170HX cards (64 GB on the 8 GB card 10de:20c2, 40 GB on the 10 GB card 10de:2082). It was written to catch HBM faults that pass light tests, most memtest_vulkan runs and every compute test. Each command says what it does, shows the exact command and the pass rule, shows live output, ends with PASS or FAIL, and saves raw logs per card serial and date, so a session can be filmed or shared with a seller. Source: repo github.com/dev-boz/cmp170hx-testsuite by dev-boz on GitHub, posted by @boz._., 2026-10-09. Author: @boz._. (GitHub dev-boz), MIT. "i got claude to build a test suite for new cards"; he invites people to add to it or fork it. Source: @boz._., 2026-10-09 Repository: https://github.com/dev-boz/cmp170hx-testsuite ### Gds-nvme-patch Source: https://cmp.wiki/wiki/Gds-nvme-patch gds-nvme-patch restores NVIDIA GPUDirect Storage (cuFile and nvidia-fs, direct NVMe-to-VRAM transfers) on Linux kernels where NVIDIA's own NVMe patch no longer applies. It patches the kernel's NVMe driver, not the GPU, and was built and tested on an unlocked CMP 170HX. Author: GitHub cachenetics, GPL-2.0. Repository: https://github.com/cachenetics/gds-nvme-patch Source: repo github.com/cachenetics/gds-nvme-patch by cachenetics on GitHub, posted by @mountains1605, 2026-10-20. @markshowa asked whether GDS can run on the 170HX for model loading and KV cache; @mountains1605 pointed to this repository and said someone had done it a while ago. Source: @markshowa, 2026-10-20Source: @mountains1605, 2026-10-20Source: @mountains1605, 2026-10-20 Expected gains: faster model loading without going through CPU and system RAM, and a place for n-gram tables, PLE and other low-bandwidth parts of inference. Neither poster had tried it. Source: @mountains1605, 2026-10-21Source: @mountains1605, 2026-10-21 ### Gpcprobe Source: https://cmp.wiki/wiki/Gpcprobe gpcprobe reads a GA100 card's floorsweep fuses and its InfoROM black box without touching the card's state. Use it to see which compute clusters and memory partitions are disabled or fused defective, and to read a card's history before you buy or keep it. Author: @matstatman (GitHub matstatman). Repository: https://github.com/matstatman/gpcprobe ### Hbmmon Source: https://cmp.wiki/wiki/Hbmmon hbmmon is an nvtop-style terminal monitor for the CMP 170HX that shows each HBM stack separately: its temperature, vendor, density, date code and which memory partitions are live, harvested or defective, next to the GPC fuse map, PCIe link and power. It reads these from the card rather than from tables. Author: @matstatman (GitHub matstatman). Repository: https://github.com/matstatman/hbmmon Source: repo github.com/matstatman/hbmmon by matstatman on GitHub, posted by @matstatman, 2026-10-05. ### Llm-inference-bench Source: https://cmp.wiki/wiki/Llm-inference-bench llm-inference-bench measures an LLM server's prefill and decode throughput over a grid of concurrency and context lengths, against vLLM, SGLang or any OpenAI-compatible API. It also ships lil-bench (a standard in-container benchmark), p2pmark (GPU peer-to-peer bandwidth and all-reduce) and a peer-read stall probe whose kernel targets sm_80. Nothing in it is CMP-specific, but the fabric checks matter for multi-card 170HX boxes running tensor parallel over PCIe without NVLink. Author: GitHub local-inference-lab, MIT. Repository: https://github.com/local-inference-lab/llm-inference-bench Source: repo github.com/local-inference-lab/llm-inference-bench by local-inference-lab on GitHub, posted by @mountains1605, 2026-10-12.Source: @mountains1605, 2026-10-12 ### Llm-visuals Source: https://cmp.wiki/wiki/Llm-visuals llm-visuals is a live terminal dashboard for a local inference server. It auto-detects llama-server, ollama, vLLM, SGLang and several other engines and shows decode and prefill speed, time to first token, per-GPU utilisation, power, HBM temperature, clock-throttle reasons and the VRAM split between weights and KV cache. Not CMP-specific, but its author verified the HBM temperature readout on a CMP 170HX. Author: GitHub DingoOz, MIT, Rust. Repository: https://github.com/DingoOz/llm-visuals Source: @trustinter, 2026-10-17Source: repo github.com/DingoOz/llm-visuals by DingoOz on GitHub, posted by @trustinter, 2026-10-17. ### Mmapeak Source: https://cmp.wiki/wiki/Mmapeak mmapeak is a small CUDA benchmark that measures peak tensor-core throughput for each data type. In the Discord it is the tool to ask a seller to run before you buy, to show the card's tensor cores work at full rate; a PyTorch GEMM benchmark is the second option. Source: @jimtjames, 2026-10-11 Author: GitHub ReinForce-II. Repository: https://github.com/ReinForce-II/mmapeak ### Monitoring Source: https://cmp.wiki/wiki/Monitoring What to watch on a running CMP 170HX and which tools show it. Cooling fixes are on Cooling and power, fault diagnosis on Troubleshooting, and health tests on Testing and burn-in. ### Testing and burn-in Source: https://cmp.wiki/wiki/Testing_and_burn-in How to find out whether a CMP 170HX is healthy: after buying it (Acceptance checklist), after an unlock or driver change (Verifying an unlock covers checking that the unlock took), and when it starts misbehaving (Troubleshooting). The tools are listed on Tools. ### Tools Source: https://cmp.wiki/wiki/Tools Software people in the cmpunlocker Discord use to inspect, test, tune and monitor CMP 170HX cards. The unlock itself (cmpunlocker and its forks) is on Driver unlock and Unlocks; the base of the server is https://github.com/amoghmunikote/cmpunlocker. Source: @globalapathy, 2026-10-18 How to put the tools together: Acceptance checklist, Testing and burn-in, Monitoring. Most tools on this page read the card's registers through BAR0 and need root. The ones marked write to the card; read their page first. ## Hardware variants ### 32 GB cards (subsystem 10de:1586) Source: https://cmp.wiki/wiki/32_GB_cards_(subsystem_10de:1586) Some cards sold as 8 GB CMP 170HX cards unlock to 32 GB, not 64 GB. They report the 8 GB card's device ID 10de:20c2, but PCI subsystem 10de:1586, board number 699-11001-0109-RC1 and VBIOS 92.00.6D.00.01; a normal 8 GB card reads subsystem 10de:1585 and board 900-11001-0108-000. They were first documented on 2026-08-31, several buyers lost money on them, and sealed, new-looking stock is no protection. Ask the seller for the subsystem ID, board number and VBIOS version before paying, buy where returns are possible, and check the unlocked capacity on arrival (Verifying an unlock). The other variants are on Which card do I have and Odd variants and engineering samples. ### CMP 90HX unlock hub Source: https://cmp.wiki/wiki/CMP_90HX_unlock_hub The CMP 90HX is not a CMP 170HX. It is a GA102 card, the same chip family as the RTX 3080 and 3090, with 10 GB of GDDR6X on a 320-bit bus, and it is the card the cmpunlocker Discord talks about most after the 170HX. None of the work on this page is the cmpunlocker 170HX tool: it is a set of separate projects by separate people. The 90HX has no HBM, so there is no hidden memory to unlock as on the 170HX; what people unlock on it is compute throughput, graphics (GR), the power limit and the PCIe link. Every unlock below is driver-side and volatile: a full power-off re-locks the card and the unlock reapplies at the next driver load. Read a project before running it, and do not confuse a 90HX with the 10 GB 170HX (Which card do I have). ### Compute, data types and missing features Source: https://cmp.wiki/wiki/Compute,_data_types_and_missing_features The CMP 170HX is a GA100 part, the A100's sm_80 architecture with fewer SMs enabled: 70 SMs on a standard unlock (more with the Full SM unlock). Its tensor cores work and do BF16, FP16, TF32 and INT8; there is no FP8 or FP4 hardware, and whether INT4 runs at its full rate is disputed. The card has no video encoder or decoder, no RT cores, no ECC on its HBM, and only one MIG instance. Most figures below come from 8 GB cards unlocked to 64 GB with cmpunlocker. Few runs share a method or tool, so read every number with its benchmark, clocks and power limit. Head-to-head comparisons with other GPUs are on How the 170HX compares; which quant formats to run follows from this page and is on Quantization on the 170HX. ### Floorsweep read of the 8 GB card: gated versus defective partitions Source: https://cmp.wiki/wiki/Floorsweep_read_of_the_8_GB_card:_gated_versus_defective_partitions The 8 GB card's disabled memory partitions and compute clusters are software-gated, not all physically dead, but the gate that would re-enable them is fuse-locked. The reversible unlock ceiling of 64 GB and 74 SM therefore stands. This settles, for a set of eight cards, whether the 80 or 96 GB claim has a physical basis: about 80 GB of framebuffer is physically latent, but 96 GB is not reachable and even 80 GB would need an irreversible fuse burn the 8 GB card does not allow in software. ### Fuses and floorsweep maps Source: https://cmp.wiki/wiki/Fuses_and_floorsweep_maps Every CMP 170HX carries a full GA100 die with parts of it switched off at the factory. The switches are fuses: one-time-programmable bits on the die that disable GPCs (graphics processing clusters, which hold the TPCs and SMs), FBPs and FBPAs (the frame buffer partitions behind the HBM stacks) and features such as PCIe Gen3, NVLink and ECC. The pattern of what is switched off on one card is its floorsweep map. This page covers how to read your own card's map with read-only tools, the fuse model as the community understands it, what the census of many cards found for memory and compute, the RIR records that separate the 8 GB card from the 10 GB card, and what the fuses do and do not let anyone change. Reading fuses with the tools below is safe. Writing fuses is permanent and can brick a card: the one fuse write in use, on the 10 GB card only, is on RIR fuse burn, and the SM unlock is on Full SM unlock. ### Odd variants and engineering samples Source: https://cmp.wiki/wiki/Odd_variants_and_engineering_samples Most cards sold as a CMP 170HX are one of the two production versions, the 8 GB card and the 10 GB card (Which card do I have). This page collects the rest: cards with fewer SMs than normal, engineering samples (ES) of the 170HX and of the A100, and single cards that did not behave. ES boards are pre-production cards that NVIDIA did not intend for sale; they can carry different board numbers, firmware and floorsweeping, and several did not unlock or did not boot. The 8 GB-looking boards that unlock only to 32 GB have their own page, 32 GB cards (subsystem 10de:1586). ### Other CMP cards and other NVIDIA GPUs Source: https://cmp.wiki/wiki/Other_CMP_cards_and_other_NVIDIA_GPUs Scope. This page collects what the cmpunlocker Discord said about cards that are not the CMP 170HX: the other CMP mining models, the A100 that the 170HX is cut from, and unlock projects for GeForce and other NVIDIA cards. Nothing on this page is CMP 170HX unlock work unless the entry says so. The wiki is about the 170HX; these notes are here because the questions keep coming, and they are thinner than the 170HX pages. For the 170HX itself start at Which card do I have, 8 GB card and 10 GB card. The Discord export behind this page starts on 2026-10-04, so older talk about these cards is missing. ### The 10 GB card: provenance and the 80 GB question Source: https://cmp.wiki/wiki/The_10_GB_card:_provenance_and_the_80_GB_question The 10 GB card (device 10de:2082, Samsung HBM on five active stacks) unlocks to 40 GB. From July to early October 2026 owners and developers tried to take it to 80 GB, the figure its bus width and stack count seem to promise. Every attempt hit the same wall: 80 GB shows up in nvidia-smi, and kernels can even write and read much of it, but loading, copying or freeing data above about 40 GB crashes the program, the driver or the GSP firmware. This page keeps that history, and where the cards came from, so that 10 GB card and Memory unlock on the 10 GB card can stay short. For what to do with a 10 GB card today, start on those pages. Where it stands: 40 GB is the stable unlock (Proven). 48 GB is reported on some cards whose sixth stack is intact (Reported; the September doubts below were answered by owner reports in October, see Memory unlock on the 10 GB card). 80 GB has not been achieved: it can be made visible, not used. Every claim of a working 80 GB below is marked Contested. ## Buying ### Acceptance checklist Source: https://cmp.wiki/wiki/Acceptance_checklist What to do when a card arrives, in order, so you can keep it with confidence or send it back inside the return window with evidence. The tests themselves are explained on Testing and burn-in. Why each step matters is on Buying. Plan about an hour per card for steps 4 to 8, plus the time to install the unlock the first time. ### Alibaba Trade Assurance, cancellations and disputes Source: https://cmp.wiki/wiki/Alibaba_Trade_Assurance,_cancellations_and_disputes Alibaba's Trade Assurance holds a buyer's payment until the order is delivered and gives a dispute route when a seller does not ship. From July to October 2026, when CMP 170HX prices jumped, members of the Discord put it to the test: sellers stalled, asked for extra fees or pushed buyers to cancel, and buyers answered with Alibaba disputes, card chargebacks, eBay cases and China's 12315 complaint channel. General buying advice and scam patterns are on Buying, buying from abroad on Buying from China as a foreigner, dated prices on Price history, July to October 2026. No seller is named here; named sellers are under Sellers and suppliers on the Buying page. ### Alternatives at these prices Source: https://cmp.wiki/wiki/Alternatives_at_these_prices As CMP 170HX prices rose from about $1,200 in late July 2026 to about $2,300-2,500 by late September, members kept asking what else the money buys: V100s, A100 SXM4 conversions, AMD MI50 and MI250X, Intel Gaudi 2, Apple's Mac Studio, the DGX Spark and more. This page collects those comparisons by hardware family. Every price is as of the date of its post, in the currency the member used; they moved fast and many listings were one-offs. Measured speed against the RTX 3090, A100, DGX Spark and Mac Studio is on How the 170HX compares; the CMP's own price series is on Price history, July to October 2026 and Price history and market; unlocks on other NVIDIA cards are on Other CMP cards and other NVIDIA GPUs. ### Buying Source: https://cmp.wiki/wiki/Buying Every CMP 170HX on the market is a used ex-mining card. In October 2026 prices moved every week, a share of the cards sold were broken, mislabelled or never shipped, and several buyers in the Discord lost money to scams. This page collects what those buyers learned. It is written for someone about to buy their first card. Named sellers and suppliers, with what buyers reported about them, are under #Sellers and suppliers. Reports age fast; ask in #suppliers-chat on the Discord before you buy. ### Buying from China as a foreigner Source: https://cmp.wiki/wiki/Buying_from_China_as_a_foreigner Members outside China who bought CMP 170HX cards, or tried to, straight from Chinese marketplaces, agents and forwarders posted what worked and what did not. This page collects those reports from July to October 2026: which platform, getting an account and paying, agents and middlemen, buying in person, shipping terms, returns, and one member's route through Kazakhstan. General buying advice and scam patterns are on Buying, payment protection and disputes on Alibaba Trade Assurance, cancellations and disputes, dated prices on Price history, July to October 2026. No seller is named here. Names as posted: Goofish and Xianyu are the same marketplace (Goofish is the English name and web front). RMB, CNY and yuan are the same currency. DAP and DDP are shipping terms: on DAP the buyer pays import duty and tax on arrival, on DDP the seller's price is meant to include them. ### How the 170HX compares Source: https://cmp.wiki/wiki/How_the_170HX_compares Members compared the unlocked CMP 170HX with what a buyer would otherwise consider: the RTX 3090, the A100, the DGX Spark, Apple's Mac Studio, and larger rigs built from V100, RTX 5060 Ti or RTX 5090 cards. Most figures are for the 8 GB card unlocked to 64 GB. Few runs used the same model, quant and engine on both sides, and llama.cpp or ollama results against the 3090 differ from vLLM results, so read every number with its engine and settings. The view most members share is under Positioning; prices and other options are on Alternatives at these prices and Price history and market. Two matched runs are still wanted: one 170HX against an RTX 3090 on vLLM with matched quants (single stream, concurrency 4 and 16, prefill TFLOPS achieved), and one 170HX against a DGX Spark with NVFP4 prefill in vLLM and Qwen 3.6 or 3.8 27B decode on the same quant and engine. ### Price history and market Source: https://cmp.wiki/wiki/Price_history_and_market Prices for the CMP 170HX as members reported them on the Discord, each with the date it was posted. This is not a price list. Most rows are one person's quote, listing or purchase, in the currency that person used; no conversions were added. For what to buy, how to pay and how to check a card, see Buying and Acceptance checklist. The dated prices on this page, Buying, Seller history and Variant comparison are also in Price log, one row per report in a single table; the price chart on the front door reads that table. Names as posted: Alifond (also written Ailfond, alifond) is the Alibaba volume seller most members mention; @kellertreppe123 says Huateng Technology is the same company under another name. Source: @kellertreppe123, 2026-10-23 Every buyer report about a named seller, with its source and label, is in Seller history. ### Price history, July to October 2026 Source: https://cmp.wiki/wiki/Price_history,_July_to_October_2026 Dated prices for the CMP 170HX as members posted them on the Discord, from the weeks before the unlock went public (early July 2026) to early October 2026. Each fact is one or a few members' quotes, listings, purchases or recollections, in the currency they used; conversions appear only where the poster gave one. A quote or an asking price is not a sale. The summary table and the later months are on Price history and market; how to buy and check a card is on Buying and Acceptance checklist. Names and units as posted: Alifond, the Alibaba volume seller most posts mention, also appears as Ailfond, AiLFond and AILFond; this page writes Alifond. RMB, CNY and yuan are the same currency. "Recalled" marks a price someone remembered later; the Source date is the day it was posted. ### Price log Source: https://cmp.wiki/wiki/Price_log Every CMP 170HX price that members reported on the Discord, one row per report, at the date it was posted and credited to the member who posted it. This is a log of reports, not a price index: a row is one person's listing, quote, offer, sale or purchase, per card, in the currency that person used, and nothing is converted. For the story behind the numbers see Price history and market; reports about named sellers are on Seller history; how to buy and check a card is on Buying. The price chart on the cmp.wiki front door (cmp.wiki/prices) reads this table: it plots the USD rows by date, 8 GB and 10 GB apart, and lists the other currencies on their own. ### Seller history Source: https://cmp.wiki/wiki/Seller_history Seller history collects what members of the cmpunlocker Discord reported about named sellers of CMP 170HX cards and related parts from 2026-07-19 to 2026-11-02: what was advertised, what arrived or happened, how it ended, and who reported it. Every row is one report, checked against the cited Discord message. A row says what that member posted; it is not a finding by this wiki. Before you pay, read Buying and the Acceptance checklist. 110 reports about 44 sellers: 20 fraud, 57 product disputes, 33 good reports. Labels: 25 firsthand reports, 32 independently corroborated, 20 unresolved allegations, 33 good reports. ## Help and contributing ### Board how-to Source: https://cmp.wiki/wiki/Board_how-to The board at cmp.wiki/board is where testing tasks and ongoing work live. Anyone can read it; sign in with Discord to take or move cards. ### Contributing Source: https://cmp.wiki/wiki/Contributing CMP Wiki is written by the people running CMP 170HX cards. Discord stays the place to talk; this is where answers land once they work. ### Glossary Source: https://cmp.wiki/wiki/Glossary Terms you will meet on the Discord and on this wiki, in plain words. For the card itself see CMP 170HX; for which version you have see Which card do I have. ### Press and coverage Source: https://cmp.wiki/wiki/Press_and_coverage Press articles, videos, Reddit threads and Telegram posts about the CMP 170HX unlock, from a Russian resale channel mocking the news in late June 2026 to Tom's Hardware's article on the consumer-card port in late October 2026, as members posted them on the Discord. Each entry gives the outlet, the date, the link and what members said about it, including how they thought each wave of coverage moved card prices. Dates are publication dates where a post gives one, otherwise the day the item was shared in the server. The dated prices are on Price history, July to October 2026 and Price history and market; who found what and when, including the card's 2021 history and first press, is on Unlock history: who found what, and when. ### Reference library Source: https://cmp.wiki/wiki/Reference_library The guides, reviews, schematics, papers, talks, research notes and benchmark sites that members point newcomers and researchers to, with what each one covers, how current it is and who pointed to it. Where an outside source and a wiki page disagree, the wiki page carries the newer measurements and its sources. Sources that are AI-generated or unvetted are listed under Unvetted or AI-generated sources so they can be recognised. Papers and talks about how the unlock was found are listed as pointers only. This wiki describes what the published tools do and how to check they worked; it does not carry keys, decrypted firmware or exploit details. Material that would reproduce one person's long write-up waits for the author. ### Rumours and claims to verify Source: https://cmp.wiki/wiki/Rumours_and_claims_to_verify Claims made on the cmpunlocker Discord that nobody has reproduced, and claims that were checked and turned out to be false. Each entry gives the claim, who made it and when (in the credit line), what would settle it, and the board card if there is one. Where another page already covers the claim with its sources, the entry is short and links there. Older history (July to early October 2026) sits in each section next to the October entries. on this page: a claim with no evidence posted and no second person. : people disagree. Both sides are listed in the order they were posted, with no verdict. : one account of a claim, or one check that showed a claim to be false. : a fake or a sales pitch that has already cost buyers money, or a claim that can cost you a card if you act on it. To settle one, post the evidence on Discord with the card variant, driver and method, and move the card on the board. A settled claim moves to the page it belongs on. Firmware and VBIOS claims appear here only as claims. This wiki does not carry keys, decryption or ways around NVIDIA's firmware protection. ### Status taxonomy Source: https://cmp.wiki/wiki/Status_taxonomy Every recipe, platform report and unlock carries one status badge, and any single fact on any page may carry one too ({{Status|Theory}}). The badge tells a reader at a glance how far to trust it. ## More articles ### Main Page Source: https://cmp.wiki/wiki/Main_Page CMP Wiki collects what the cmpunlocker community has worked out about the CMP 170HX, the 8 GB and the 10 GB card side by side: unlocks, recipes, platforms, cooling and power, with credit to whoever found it. New here? Start at Start here: which card you have, what it can run and where to go next. Unlocks: what the driver and firmware work has unlocked so far Developers: register map, current unlock status, experiments and open research tasks Interactive tools and Software & utilities: check a card, plan a setup or find software to install All recipes: models running on these cards, with the numbers CMP benchmarks: measured speeds, one row per recipe and one per posted run, each with its source Recipe finder: pick your card variant, number of cards and model, and get the recipes that match, with their numbers Setup matrix: choose your cards, memory, link, P2P and ECC, and see which recipes run on that setup and how fast All platforms: boards and servers, and the settings that mattered Buying: what to check before you pay, and the Seller history of named sellers, one sourced report per row Status taxonomy: what Proven, Reported, Theory, Contested and Warning mean Contributing: sign in with Discord, add a recipe, confirm someone else's Board: testing tasks anyone can take For agents: how software reads this site (plain text, search, data tables, feeds)