A glitch that turns a mining card into an inference object

Kate's documentation does not describe a simple overclock. It describes a hardware hacking intervention that starts from a CMP 170HX, a card designed for mining, and arrives at a device with 80 GB of usable HBM, NVLink and PCIe Gen4 re-enabled, plus a number of streaming multiprocessors higher than retail A100 cards. The starting point is segmentation decided upstream: the silicon contains about 80 GB of memory, but fuses expose only 8. Software unlocks could reach 64 GB, but voltage fault injection made it possible to go beyond. The result is not linear: FP16 performance moves from 72.5 to 85.9 TFLOPS, but above all it makes available a memory capacity that changes the product's positioning.

For those observing on-prem LLM inference, the first element is not peak speed. It is VRAM availability. With 80 GB of HBM, larger models can be hosted without pushing them toward aggressive quantization, and bandwidth can make token generation smoother. The glitch does not create new capacity: it removes a constraint imposed by a commercial decision. That is the main signal, and it deserves to be read beyond the single experiment.

The mod is also a reverse engineering experiment. It shows that the boundary between a mining card and a data center GPU is not physical, but activated or deactivated at configuration level. The same silicon base can feed products with very different prices, warranties and support. This is not entirely new in semiconductors, but Kate's documentation makes the scale visible on a GPU that many watch for AI workloads.

The immediate consequence is that VRAM should not be treated as a simple specification line. It should be read as the most contested resource for local language models, and as a lever that manufacturers can use to delimit markets. When an artisanal intervention succeeds in moving that boundary, questions emerge about the real value of hardware and the sustainability of segmentation policies.

Why fuse-based segmentation matters more than the benchmark

NVIDIA segments the same commercial die with fuses, not with different silicon. For the company it is an efficient choice: a single manufacturing design can feed mining, workstation and data center cards, reducing line complexity. The downside is that product differences become partly a decision. Fuses establish how much memory is visible, which interconnects are active and how many streaming multiprocessors work. This is not a defect: it is a product policy.

For the market, fuse-based segmentation has an ambivalent effect. On one hand it allows different configurations without multiplying production costs. On the other it creates a constant incentive to dig into the disabled part. Kate's mod is not an isolated case in logic: it is a symptom of demand that official price lists do not fully satisfy. Those looking for abundant VRAM for local inference also look at the used market, mining cards and unlock possibilities, because official options can be expensive or overbuilt in other respects.

The second effect concerns specification transparency. An enterprise buyer reads a card with 8 GB of HBM and treats it as such. But the silicon contains far more capacity. This does not mean the additional capacity is guaranteed or usable: fuses and production tests exist to isolate non-compliant areas or to limit positioning. Yet the gap between what is physically present and what is exposed to software widens the space for unofficial interventions.

From an on-prem perspective, fuse-based segmentation complicates TCO evaluation. A modified card may have attractive specifications, but it has neither homogeneous yield nor support. The real cost is not just purchase: it includes modification time, failed attempts, brick risk and lack of spare parts. That is why the benchmark should not guide infrastructure decisions.

The TCO of a modified card: why the mod does not scale

The procedure documented by Kate is not replicable in production. It requires wiring on the card, an STM32-based glitcher and from 1 to 48 hours of attempts per unit. Out of ten treated cards, one still had only 64 GB working. This data is sufficient to rule out the mod as a basis for an on-prem cluster. Variability between units is a planning problem: a cluster with heterogeneous capacity complicates load balancing, memory availability estimates and failure management.

The risk of bricking hardware is real. In an enterprise context, even a modest failure rate translates into downtime, replacement costs and loss of predictability. There is no vendor to call for support, and no warranty covers a voltage fault injection intervention. Those designing infrastructure for LLM inference need stable specifications and a reliable supply pipeline.

The point is not to condemn experimentation. Kate's work has value as research and as a market signal. But the TCO of a fleet of modified cards is incalculable because success rates are not guaranteed and capacity gains are not homogeneous. For a university lab or a hobbyist, the risk may be acceptable. For a self-hosted deployment serving real users, variability becomes a hidden cost.

Those evaluating hardware for on-prem LLM should focus on verifiable parameters: VRAM, bandwidth, power consumption, support and specification predictability. Extreme solutions attract attention but do not provide the foundation for a stable service. The CMP 170HX case is useful precisely because it shows the boundary between interesting and operational.

What changes for on-prem LLM inference

For inference workloads, VRAM is often the bottleneck before compute power. A language model must reside in memory to generate tokens without continuous transfers. When capacity is insufficient, quantization is used, reducing weight precision to fit the model. Quantization can reduce footprint, but it has quality impacts and requires attention. With 80 GB of HBM, some models can be served without pushing toward extreme configurations.

Bandwidth matters equally. Token generation alternates weight reads and calculations; fast memory helps keep latency under control. The HBM on the CMP 170HX has high bandwidth, which explains why the operation attracts those working with open models. The ability to host the larger model without aggressive cuts and smooth generation are two advantages that go beyond peak TFLOPS.

The return of NVLink and PCIe Gen4, disabled in the mining version, also raises the question of interconnects. For distributed inference across multiple GPUs, card-to-card communication can become a determining factor. A mining card without these interconnects is poorly suited to high-density clusters. Kate's mod shows that connectivity was disabled, not removed. But relying on an unofficial intervention to restore it is not a deployment strategy.

The message for teams managing on-prem LLM is twofold. On one side, the market confirms demand for abundant VRAM and cards suited to local inference. On the other, the do-it-yourself route does not solve the predictability problem. Products with declared configurations, measurable consumption and support are needed; or one must accept that used and modded hardware occupies an experimental niche, not the backbone of a service.

Who loses and who gains from unlockable VRAM

Kate's mod does not redistribute the market evenly. Individual experimenters and small labs can benefit from a card that, after intervention, offers more memory and more compute units than a retail A100, at least on the reported FP16 numbers. But the advantage is fragile: it depends on glitch success, individual unit quality and absence of support. It is not a basis for scaling.

NVIDIA and board partners have an interest in maintaining segmentation. Fuses protect price lists and steer customers toward products with different margins. If unlocking spread, the boundary between mining and data center would become more porous. However, the volume and complexity of the intervention limit the real risk for vendors. The mod remains a technical niche, but it signals that segmentation policies are under observation.

System integrators and infrastructure managers have little incentive to follow this path. Variability of modified units makes it difficult to design a homogeneous cluster. Lack of support, possible warranty violations and brick risk push TCO toward uncertainty. For those accountable for service availability, reliability is worth more than a few extra TFLOPS.

The true beneficiary of the signal is the debate on hardware for local inference. The episode makes a tension visible: the market asks for more VRAM at sustainable costs, while manufacturers segment silicon to protect product lines. This tension is not resolved with a glitcher, but it can influence next-generation GPUs and the choices of those building on-prem solutions.

What to watch in the coming months

The first signal to monitor is the evolution of memory capacity on consumer and professional cards. If demand for local LLMs keeps growing, VRAM will become a competitive battleground. Manufacturers may increase memory configurations, or introduce specific inference products with more HBM or GDDR. The CMP 170HX episode will not determine these choices alone, but it is an indicator of bottom-up pressure.

The second signal is vendor response to unlock practices. Voltage fault injection techniques have long been known in security research, but when applied to AI GPUs the conversation changes. Possible countermeasures include harder-to-bypass fuses, additional checks or new warranty policies. At the same time, vendors might choose to reduce the gap between physical silicon and exposed specifications to remove incentives.

The third signal concerns the self-hosted ecosystem. At AI-RADAR we continue tracking frameworks and configurations for on-prem because hardware choice is not separate from software choice. VRAM availability conditions the model that can be served, acceptable quantization and generation fluidity. Modified cards will not enter data centers, but they influence the perception of what is possible with unofficial hardware.

Finally, homogeneity remains a theme to watch. Any cluster built on variable foundations, even far from voltage glitching, pays a management cost. The CMP 170HX lesson is that one card in ten may not reach expected capacity. For those planning a self-hosted deployment, predictability is a requirement, not an option. Specifications matter when they are stable across the installed fleet.