From two RTX A5000s to three NVIDIA CMP 170HX mining cards. How I built a local artificial intelligence system with 192 GiB of VRAM, the problems I ran into, and why I believe it has been worth it.
Introduction
I have been experimenting with locally run artificial intelligence models for quite a while. As a software developer, one of my main motivations is having my own environment where I can test language models, work with coding agents and experiment with different configurations without depending exclusively on external providers.
In September 2026 I published a first article about the NVIDIA CMP 170HX, cards originally designed for cryptocurrency mining that hide some particularly interesting hardware for running artificial intelligence models.
Since then, my setup has changed considerably. I have gone from using two cards with 104 GiB of unlocked memory to having three CMP 170HX cards running simultaneously, each with 64 GiB of VRAM.
That makes a total of 192 GiB of VRAM, an amount that opens up interesting possibilities for running large language models.
But getting here has not been as simple as buying three cards and plugging them into the computer.
1. The starting point: two NVIDIA RTX A5000
Before discovering the CMP 170HX, I was using two 24 GB NVIDIA RTX A5000 cards.
Those cards gave me a total of 48 GB of VRAM, enough to run many quantized models, but increasingly limited when I wanted to experiment with larger models, higher-quality quantizations or long contexts.
Video memory is one of the most important resources when working with local language models.
We do not only need to store the model weights. We also have to reserve memory for the KV cache, compute buffers and other resources required during inference.
In addition, although the two RTX A5000s could be used together, their 48 GB did not form a single shared memory space. The model had to be distributed across both cards.
That is when I started looking into alternatives offering more VRAM without having to make the enormous investment required to buy current professional accelerators.
And that is how I discovered the CMP 170HX.
2. What makes the NVIDIA CMP 170HX special?
The NVIDIA CMP 170HX belongs to a family of cards designed specifically for cryptocurrency mining.
Unlike a conventional graphics card, it has no display outputs and is not intended to run games or to be used as a desktop display adapter.
However, it incorporates an NVIDIA GA100 processor, part of the Ampere architecture and related to the one used in NVIDIA A100 professional accelerators.
It also has HBM2e memory, a technology known for providing a very high internal bandwidth.
The truly interesting part is that some variants of these cards physically include more memory than the manufacturer allows to be used in their original configuration.
Thanks to the community's work, it is possible to modify the driver's behavior to access a considerably larger amount of memory.
In my case, I have worked with two variants:
| Variant | Original memory | Unlocked memory |
|---|---|---|
| CMP 170HX 8 GB | 8 GB | 64 GiB |
| CMP 170HX 10 GB | 10 GB | 40 GiB |
It is worth clarifying that the unlock does not add memory physically. It allows using memory that is already present in certain units, but whose access is restricted.
Nor does it turn these cards into full NVIDIA A100s. There are important differences in connectivity, features and support.
Even so, their ratio between memory capacity and cost can be extraordinarily attractive for certain artificial intelligence projects.
3. My first setup: 104 GiB of VRAM
My first experience consisted of installing two CMP 170HX cards.
One of them was the 8 GB variant, which I managed to unlock to 64 GiB. The second was the 10 GB variant, which allowed access to 40 GiB.
Together they provided 104 GiB of video memory.
For someone used to working with two RTX A5000s and 48 GB in total, the leap was considerable.
For the first time I could experiment with much larger models and reserve amounts of memory that had previously been difficult to assume.
I could also use higher-precision quantizations without worrying so much about VRAM constraints.
The results were good enough to make a decision: sell the RTX A5000s and keep expanding my system with the CMP 170HX.
That decision was not driven solely by memory capacity. It was also influenced by the fact that the models I was running delivered very satisfactory results in real software development tasks.
4. Moving up to three CMP 170HX and 192 GiB
Over time I kept acquiring new units of the 8 GB variant.
In November 2026 I managed to have three CMP 170HX cards connected and correctly recognized by Linux.
All three have 64 GiB of unlocked memory, which provides a total of 192 GiB of VRAM.
My main machine has the following configuration:
| Component | Configuration |
|---|---|
| Processor | AMD Ryzen 9 7950X3D |
| Motherboard | MSI MPG X870E Carbon WiFi |
| RAM | 96 GB DDR5 |
| GPU | 3 × NVIDIA CMP 170HX |
| VRAM per GPU | 64 GiB |
| Aggregate VRAM | 192 GiB |
| Operating system | Ubuntu Linux |
| Main inference engine | llama.cpp |
The memory capacity reported by NVIDIA is the following:
GPU 0: NVIDIA CMP 170HX - 65536 MiB
GPU 1: NVIDIA CMP 170HX - 65536 MiB
GPU 2: NVIDIA CMP 170HX - 65536 MiBIt is important not to confuse aggregate memory with unified memory.
Each GPU has its own 64 GiB, and the inference software must manage how it distributes weights and operations across them.
This means that having three cards is not exactly the same as having a single GPU with 192 GiB.
However, for certain language model execution strategies, the combined memory can be used very effectively.
I still have another 40 GiB CMP 170HX that I could add in the future, although for now I prefer to focus on optimizing the current configuration.
5. Unlocking the memory: the key to the project
A fundamental part of this experience has been the open source project cmpunlocker.
Its goal is to allow access to the restricted memory of certain NVIDIA CMP 170HX cards through driver modifications.
In my case, the procedure has worked correctly.
The verification tools confirmed the following capacities:
CMP 170HX 8 GB:
65536 MiB - Verification successful
CMP 170HX 10 GB:
40960 MiB - Verification successfulThe result is particularly interesting because it allows using amounts of memory that we would normally associate with much more expensive professional accelerators.
Naturally, there is a trade-off.
We are using modified drivers and a configuration that does not have conventional NVIDIA support.
A kernel update, a driver modification or a change in the unlock tools can introduce compatibility problems.
For that reason, I consider it essential to keep a stable environment, document the changes and avoid unnecessary updates when everything works correctly.
This solution is very attractive for those who enjoy experimenting with hardware, but I would not recommend it as a first option for a production environment that needs official support and minimal maintenance.
6. The challenge of connecting three cards
One of the biggest problems has not been the software, but the physical build.
The CMP 170HX cards are not designed to be installed in a conventional home workstation.
Their power, cooling and connectivity characteristics make the process considerably more complicated.
When expanding the setup I had to find ways to install additional cards, including the use of external PCIe connections.
To that end I have experimented with OCuLink, an interface that allows extending PCIe connections outside the computer chassis.
This is particularly useful when we no longer have enough space inside the case, or when the available expansion slots do not allow the cards to be installed directly.
However, adding an external GPU means paying attention to other factors: independent power, power-on order, connection stability and cooling.
These are details that may seem secondary, but they end up being fundamental when trying to keep several cards running simultaneously.
7. PCIe: a limitation worth knowing
Once the three cards were connected, I decided to analyze their topology using NVIDIA's tools.
The command used was:
nvidia-smi topo -mThe result was:
GPU0 GPU1 GPU2
GPU0 X PHB PHB
GPU1 PHB X PHB
GPU2 PHB PHB XAll three cards appear connected through PHB paths, that is, PCIe paths that traverse the host system's PCIe bridge.
There is no NVLink connection between them.
I then checked the speed and width of the PCIe links:
nvidia-smi --query-gpu=index,name,memory.total,pcie.link.gen.current,pcie.link.width.current,pcie.link.gen.max,pcie.link.width.max --format=csvThe results were the following:
| GPU | VRAM | Current PCIe | Maximum reported PCIe |
|---|---|---|---|
| GPU 0 | 64 GiB | Gen 2 x4 | Gen 2 x16 |
| GPU 1 | 64 GiB | Gen 2 x4 | Gen 2 x16 |
| GPU 2 | 64 GiB | Gen 2 x4 | Gen 2 x16 |
Therefore, all three currently run over PCIe 2.0 x4 connections.
That provides approximately 2 GB/s of theoretical bandwidth per direction and per link, before considering transfer overhead.
It is a modest figure compared with the connections of modern cards.
However, this is where one of the most interesting characteristics of language model inference comes in.
When we distribute a model by layers using llama.cpp, a significant part of the computation can be performed directly in each GPU's local memory.
The amount of data that needs to travel between cards depends on how the model is distributed, the size of activations and the execution strategy.
That is why a relatively slow PCIe connection does not necessarily mean poor performance.
In my practical tests, the system's behavior has been satisfactory, although I still need to run systematic comparisons to determine how much performance is lost due to connectivity limitations.
The conclusion is that having a lot of VRAM is extremely useful, but we must keep in mind that communication between GPUs also affects final performance.
8. Cooling: one of the biggest challenges
Another aspect that has given me the most work has been cooling.
The CMP 170HX cards were designed for environments with forced ventilation and adequate airflow.
They are not cards intended to be installed in a computer case and rely solely on the system's usual fans.
During my first tests I observed idle temperatures close to 55-60 °C.
Under load, temperatures could range roughly between 70 and 77 °C, depending on the ventilation system used.
To improve the situation I have experimented with different fans, air ducts and mounts manufactured through 3D printing.
My Bambu Lab P1S printer has been particularly useful for designing and manufacturing parts tailored to the specific needs of the build.
One of the advantages of having a 3D printer is that I do not need to rely exclusively on commercial accessories.
I can design an air duct, print it, check how it performs and modify it until I get a satisfactory result.
My goal is to keep the cards, whenever possible, below 75 °C during regular inference sessions, without turning the computer into an unbearable source of noise.
GPU Protector: a tool of my own
To improve thermal control I have also developed a utility called GPU Protector.
It is a tool written in Rust for Linux, intended to monitor NVIDIA GPU temperatures and dynamically adjust their power limits.
The idea came from a real need: having a protection and control mechanism that would let me work with several cards without having to constantly watch their temperatures.
This small project is another example of how a hardware need can end up becoming a software tool.
Thermal management remains one of the aspects I want to keep working on, especially if I eventually add a fourth card to the system.
9. The real reward: running local AI models
Although building the cards' setup is entertaining, my goal is not to collect hardware.
What really interests me is using it to develop software and experiment with advanced artificial intelligence models.
Over these months I have tested numerous language models, especially those offering good results in programming, reasoning and tool use.
Among the most interesting ones I would highlight the following.
Qwen3.8 Flash Next
It is one of the models I have used the most.
I especially like its balance between reasoning capacity, code understanding and execution of development tasks.
I have also experimented with different quantizations, looking for a balance between memory consumption, speed and response quality.
Its behavior has been good enough to make it one of my regular references.
In fact, I even published a version of my own on Hugging Face based on combining different variants of the model.
Nemotron 3.5 Super
Another model that has surprised me the most has been Nemotron 3.5 Super.
I have used it with OpenCode on real programming tasks, running it in GGUF format with Q8 quantization.
Its response quality has been particularly convincing.
I have encountered some occasional difficulty related to tool selection, but once the context was clarified, it was able to continue working correctly.
It is one of those models that show just how far open artificial intelligence has come.
Ornith 1.5
I have also obtained satisfactory results with Ornith 1.5, especially in development tasks and instruction comprehension.
Its performance in Spanish has been one of the features I have liked the most.
In certain tests, the results generated by the local model were good enough that a larger external model barely had to make any corrections.
Other models
I have also experimented with different Qwen variants, models specifically oriented toward programming and large models quantized in GGUF.
One of the advantages of having so much memory is that I can try higher-precision quantizations without always having to resort to heavily compressed formats.
This does not mean that a larger quantization automatically produces better responses in all tasks.
But it does allow me to choose with greater freedom and compare results without being constantly constrained by the cards' capacity.
10. How I work: local AI supervised by an external model
One of the most important conclusions I have reached during these months is not directly related to hardware.
It is related to how the models are used.
Currently, one of the strategies that gives me the best results consists of using a local model to carry out programming tasks and a larger model, accessible through an API, to supervise the result.
The local model analyzes the project, modifies files, generates code and executes the available tools.
Afterwards, the external model reviews the work done and detects possible errors, omissions or implementation problems.
The interesting part is that, on many occasions, the supervising model barely needs to intervene.
This shows that certain open models have reached a very high quality level for real development tasks.
In addition, this strategy has an obvious economic advantage.
Instead of constantly using an expensive commercial model for every operation, I can do most of the work locally and reserve the external model for those tasks where it really adds value.
For me, this is one of the greatest advantages of having my own artificial intelligence infrastructure.
It is not only about running large models, but about building an effective, flexible and economically reasonable workflow.
11. What problems have I found?
After several months using these cards, I am also quite clear about their limitations.
- PCIe connectivity is limited. All three cards currently run over PCIe 2.0 x4. This can limit certain distributed inference strategies, especially when they require frequent transfers between GPUs.
- Cooling requires specific solutions. These are not cards that can be installed without paying attention to airflow and temperatures.
- The unlock depends on software. A kernel or driver update can introduce incompatibilities that force adjustments.
- The build is complex. Power, physical space, external connections, mounts, fans and power-on order add difficulties that do not appear in a conventional computer.
- Compatibility is not equivalent to that of a modern professional GPU. Although the hardware is very interesting, there are functional and support limitations that must be taken into account.
- More VRAM does not necessarily mean more speed. Distributing a model across several GPUs allows running larger models, but it also introduces communication and synchronization costs.
For all these reasons, I consider the CMP 170HX cards an especially interesting option for technology enthusiasts and developers willing to experiment.
I would not recommend them to someone who needs a simple solution, with official support and no maintenance complications.
12. Was it worth replacing the RTX A5000?
In my case, the answer is clearly yes.
I have gone from having 48 GB of VRAM with two RTX A5000s to a system with 192 GiB of VRAM distributed across three CMP 170HX cards.
The capacity increase is enormous.
Naturally, the RTX A5000s offer important advantages: better general compatibility, more modern PCIe connections, conventional cooling and easier integration into workstations.
But my priorities have changed.
Right now I am much more interested in being able to run large models, work with high-quality quantizations and experiment with long contexts than in having an especially versatile GPU for graphics tasks.
Moreover, the performance I am getting from my local models is good enough to use them regularly in my development projects.
Therefore, although the CMP 170HX cards have numerous peculiarities, I consider the change to have been the right one for my specific needs.
13. Next steps
My setup still has room for improvement.
First, I want to keep optimizing cooling and fan control.
I also still need to run more detailed tests of llama.cpp performance when using one, two and three cards, as well as study the differences between various model distribution strategies.
Another aspect I am interested in is checking how far I can improve memory utilization and inference speed with especially large models.
And, of course, I will keep an eye on the evolution of the unlock project, since any compatibility or performance improvement can be especially interesting for those of us using these cards.
In the longer term, I do not rule out adding the fourth CMP 170HX that I still have available.
But first I want to fully understand the possibilities and limitations of the current configuration.
Conclusion
When I started researching the NVIDIA CMP 170HX, I never imagined they would end up becoming the main element of my local artificial intelligence infrastructure.
What began as an experiment with some mining cards has ended up evolving into a system with three GPUs and 192 GiB of VRAM.
Along the way I have had to learn and experiment with NVIDIA drivers, memory unlocking, PCIe topologies, cooling, power and language model distribution.
I have also confirmed that having a lot of memory does not solve every problem.
Compute speed, connections between cards, inference software and the way models are distributed remain fundamental factors.
However, the experience has been extraordinarily positive.
Today I can run language models that, relatively recently, would have been out of reach for my personal machine.
And most importantly: I do not use them only for testing. They are part of my daily work as a software developer.
For me, that is the true value of the CMP 170HX: having turned hardware originally intended for mining into a useful platform for experimenting, learning and developing with local artificial intelligence.
They are not perfect cards, far from it.
But, after everything I have learned and the results I am getting, I can say they have been one of the most interesting hardware investments I have made.
And, probably, I have not yet discovered everything they can offer.