De dos RTX A5000 a tres tarjetas de minería NVIDIA CMP 170HX. Cómo he construido un sistema de inteligencia artificial local con 192 GiB de VRAM, los problemas que he encontrado y por qué considero que ha merecido la pena.
Introducción
Llevo bastante tiempo experimentando con modelos de inteligencia artificial ejecutados localmente. Como desarrollador de software, una de mis principales motivaciones es disponer de un entorno propio en el que pueda probar modelos de lenguaje, trabajar con agentes de programación y experimentar con distintas configuraciones sin depender exclusivamente de proveedores externos.
En septiembre de 2026 publiqué un primer artículo sobre las NVIDIA CMP 170HX, unas tarjetas originalmente diseñadas para minería de criptomonedas que esconden un hardware especialmente interesante para ejecutar modelos de inteligencia artificial.
Desde entonces, mi configuración ha evolucionado considerablemente. He pasado de utilizar dos tarjetas con 104 GiB de memoria desbloqueada a tener tres CMP 170HX funcionando simultáneamente, cada una con 64 GiB de VRAM.
En total, 192 GiB de VRAM, una cantidad que abre posibilidades interesantes para ejecutar modelos de lenguaje de gran tamaño.
Pero llegar hasta aquí no ha sido tan sencillo como comprar tres tarjetas y conectarlas al ordenador.
1. El punto de partida: dos NVIDIA RTX A5000
Antes de descubrir las CMP 170HX, utilizaba dos NVIDIA RTX A5000 de 24 GB.
Estas tarjetas me ofrecían un total de 48 GB de VRAM, suficiente para ejecutar muchos modelos cuantizados, pero cada vez más limitado cuando quería experimentar con modelos de mayor tamaño, cuantizaciones de más calidad o contextos extensos.
La memoria de vídeo es uno de los recursos más importantes cuando trabajamos con modelos de lenguaje locales.
No solo necesitamos almacenar los pesos del modelo. También debemos reservar memoria para la caché KV, los búferes de cálculo y otros recursos necesarios durante la inferencia.
Además, aunque las dos RTX A5000 podían utilizarse conjuntamente, sus 48 GB no constituían un único espacio de memoria compartida. Era necesario distribuir el modelo entre ambas tarjetas.
Fue entonces cuando empecé a investigar alternativas que ofrecieran una mayor capacidad de VRAM sin tener que realizar la enorme inversión que supone adquirir aceleradores profesionales actuales.
Y así descubrí las CMP 170HX.
2. ¿Qué tienen de especial las NVIDIA CMP 170HX?
La NVIDIA CMP 170HX pertenece a una familia de tarjetas diseñadas específicamente para la minería de criptomonedas.
A diferencia de una tarjeta gráfica convencional, carece de salidas de vídeo y no está concebida para ejecutar juegos ni para utilizarse como adaptador gráfico de escritorio.
Sin embargo, incorpora un procesador NVIDIA GA100, perteneciente a la arquitectura Ampere y relacionado con el utilizado en los aceleradores profesionales NVIDIA A100.
También dispone de memoria HBM2e, una tecnología caracterizada por proporcionar un ancho de banda interno muy elevado.
Lo verdaderamente interesante es que determinadas variantes de estas tarjetas incorporan físicamente más memoria de la que el fabricante permite utilizar en su configuración original.
Gracias al trabajo de la comunidad, es posible modificar el comportamiento del controlador para acceder a una cantidad considerablemente mayor de memoria.
En mi caso, he trabajado con dos variantes:
| Variante | Memoria original | Memoria desbloqueada |
|---|---|---|
| CMP 170HX de 8 GB | 8 GB | 64 GiB |
| CMP 170HX de 10 GB | 10 GB | 40 GiB |
Conviene aclarar que el desbloqueo no añade memoria físicamente. Permite utilizar memoria que ya está presente en determinadas unidades, pero cuyo acceso está restringido.
Tampoco convierte estas tarjetas en NVIDIA A100 completas. Existen diferencias importantes en conectividad, funcionalidades y soporte.
Aun así, su relación entre capacidad de memoria y coste puede resultar extraordinariamente atractiva para determinados proyectos de inteligencia artificial.
3. Mi primera configuración: 104 GiB de VRAM
Mi primera experiencia consistió en montar dos CMP 170HX.
Una de ellas era la variante de 8 GB, que conseguí desbloquear hasta 64 GiB. La segunda era la variante de 10 GB, que permitió acceder a 40 GiB.
La suma proporcionaba 104 GiB de memoria de vídeo.
Para alguien acostumbrado a trabajar con dos RTX A5000 y 48 GB en total, el salto era considerable.
Por primera vez podía experimentar con modelos mucho más grandes y reservar cantidades de memoria que antes resultaban difíciles de asumir.
Además, podía utilizar cuantizaciones de mayor precisión sin preocuparme tanto por las restricciones de VRAM.
Los resultados fueron suficientemente buenos como para tomar una decisión: vender las RTX A5000 y continuar ampliando mi sistema con las CMP 170HX.
No fue una decisión motivada únicamente por la capacidad de memoria. También influyó el hecho de que los modelos que estaba ejecutando ofrecían resultados muy satisfactorios en tareas reales de desarrollo de software.
4. La evolución hasta tres CMP 170HX y 192 GiB
Con el tiempo fui adquiriendo nuevas unidades de la variante de 8 GB.
En noviembre de 2026 he conseguido tener tres CMP 170HX conectadas y reconocidas correctamente por Linux.
Las tres cuentan con 64 GiB de memoria desbloqueada, lo que proporciona un total de 192 GiB de VRAM.
Mi equipo principal tiene la siguiente configuración:
| Componente | Configuración |
|---|---|
| Procesador | AMD Ryzen 9 7950X3D |
| Placa base | MSI MPG X870E Carbon WiFi |
| Memoria RAM | 96 GB DDR5 |
| GPU | 3 × NVIDIA CMP 170HX |
| VRAM por GPU | 64 GiB |
| VRAM agregada | 192 GiB |
| Sistema operativo | Ubuntu Linux |
| Motor principal de inferencia | llama.cpp |
La capacidad de memoria que reporta NVIDIA es la siguiente:
GPU 0: NVIDIA CMP 170HX - 65536 MiB
GPU 1: NVIDIA CMP 170HX - 65536 MiB
GPU 2: NVIDIA CMP 170HX - 65536 MiBEs importante no confundir memoria agregada con memoria unificada.
Cada GPU dispone de sus propios 64 GiB y el software de inferencia debe gestionar cómo distribuye los pesos y las operaciones entre ellas.
Esto significa que contar con tres tarjetas no equivale exactamente a disponer de una única GPU con 192 GiB.
Sin embargo, para determinadas estrategias de ejecución de modelos de lenguaje, la memoria combinada puede aprovecharse de forma muy eficaz.
Todavía dispongo de otra CMP 170HX de 40 GiB que podría incorporar en el futuro, aunque por el momento prefiero centrarme en optimizar la configuración actual.
5. El desbloqueo de memoria: la clave del proyecto
Una parte fundamental de esta experiencia ha sido el proyecto de código abierto cmpunlocker.
Su objetivo es permitir el acceso a la memoria restringida de determinadas NVIDIA CMP 170HX mediante modificaciones del controlador.
En mi caso, el procedimiento ha funcionado correctamente.
Las herramientas de verificación han confirmado las siguientes capacidades:
CMP 170HX de 8 GB:
65536 MiB - Verificación correcta
CMP 170HX de 10 GB:
40960 MiB - Verificación correctaEl resultado es especialmente interesante porque permite utilizar cantidades de memoria que normalmente asociaríamos con aceleradores profesionales mucho más costosos.
Naturalmente, existe una contrapartida.
Estamos utilizando controladores modificados y una configuración que no cuenta con el soporte convencional de NVIDIA.
Una actualización del kernel, una modificación del controlador o un cambio en las herramientas de desbloqueo pueden introducir problemas de compatibilidad.
Por ese motivo, considero fundamental mantener un entorno estable, documentar los cambios y evitar actualizaciones innecesarias cuando todo funciona correctamente.
Esta solución resulta muy atractiva para quienes disfrutan experimentando con hardware, pero no la recomendaría como primera opción para un entorno de producción que necesite soporte oficial y mantenimiento mínimo.
6. El desafío de conectar tres tarjetas
Uno de los mayores problemas no ha sido el software, sino el montaje físico.
Las CMP 170HX no están diseñadas para instalarse en una estación de trabajo doméstica convencional.
Sus características de alimentación, refrigeración y conectividad complican considerablemente el proceso.
Al ampliar la configuración tuve que buscar soluciones para instalar tarjetas adicionales, incluyendo el uso de conexiones PCIe externas.
Para ello he experimentado con OCuLink, una interfaz que permite extender conexiones PCIe fuera del chasis del ordenador.
Esto resulta especialmente útil cuando ya no disponemos de espacio suficiente dentro de la caja o cuando las ranuras de expansión disponibles no permiten instalar las tarjetas directamente.
Sin embargo, añadir una GPU externa implica prestar atención a otros factores: alimentación independiente, orden de encendido, estabilidad de la conexión y refrigeración.
Son detalles que pueden parecer secundarios, pero que terminan siendo fundamentales cuando intentamos mantener varias tarjetas funcionando simultáneamente.
7. PCIe: una limitación que conviene conocer
Una vez conectadas las tres tarjetas, decidí analizar su topología utilizando las herramientas de NVIDIA.
El comando utilizado fue:
nvidia-smi topo -mEl resultado fue:
GPU0 GPU1 GPU2
GPU0 X PHB PHB
GPU1 PHB X PHB
GPU2 PHB PHB XLas tres tarjetas aparecen conectadas mediante rutas PHB, es decir, rutas PCIe que atraviesan el puente PCIe del sistema anfitrión.
No existe una conexión NVLink entre ellas.
Posteriormente comprobé la velocidad y anchura de los enlaces PCIe:
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=csvLos resultados fueron los siguientes:
| GPU | VRAM | PCIe actual | PCIe máximo reportado |
|---|---|---|---|
| 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 |
Por tanto, las tres funcionan actualmente mediante conexiones PCIe 2.0 x4.
Esto proporciona aproximadamente 2 GB/s de ancho de banda teórico por dirección y por enlace, antes de considerar la sobrecarga de las transferencias.
Es una cifra modesta si la comparamos con las conexiones de las tarjetas modernas.
Sin embargo, aquí aparece una de las características más interesantes de la inferencia de modelos de lenguaje.
Cuando distribuimos un modelo por capas utilizando llama.cpp, una parte importante del cálculo puede realizarse directamente en la memoria local de cada GPU.
La cantidad de datos que necesita viajar entre tarjetas depende de cómo se distribuya el modelo, del tamaño de las activaciones y de la estrategia de ejecución.
Por eso, una conexión PCIe relativamente lenta no implica necesariamente que el rendimiento sea malo.
En mis pruebas prácticas, el comportamiento del sistema ha sido satisfactorio, aunque todavía tengo pendiente realizar comparativas sistemáticas para determinar cuánto rendimiento se pierde debido a las limitaciones de conectividad.
La conclusión es que tener mucha VRAM resulta extremadamente útil, pero debemos tener presente que la comunicación entre GPUs también influye en el rendimiento final.
8. Refrigeración: uno de los mayores retos
Otro de los aspectos que más trabajo me ha dado ha sido la refrigeración.
Las CMP 170HX fueron diseñadas para entornos en los que existe ventilación forzada y un flujo de aire adecuado.
No son tarjetas pensadas para instalarse en una caja de ordenador y confiar únicamente en los ventiladores habituales del equipo.
Durante mis primeras pruebas observé temperaturas en reposo próximas a los 55-60 °C.
Bajo carga, las temperaturas podían situarse aproximadamente entre los 70 y los 77 °C, dependiendo del sistema de ventilación utilizado.
Para mejorar la situación he experimentado con diferentes ventiladores, conductos de aire y soportes fabricados mediante impresión 3D.
Mi impresora Bambu Lab P1S ha resultado especialmente útil para diseñar y fabricar piezas adaptadas a las necesidades concretas del montaje.
Una de las ventajas de disponer de una impresora 3D es que no necesito depender exclusivamente de accesorios comerciales.
Puedo diseñar un conducto de aire, imprimirlo, comprobar su funcionamiento y modificarlo hasta conseguir un resultado satisfactorio.
Mi objetivo es mantener las tarjetas, siempre que sea posible, por debajo de los 75 °C durante las sesiones habituales de inferencia, sin convertir el ordenador en una fuente de ruido insoportable.
GPU Protector: una herramienta propia
Para mejorar el control térmico también he desarrollado una utilidad llamada GPU Protector.
Se trata de una herramienta escrita en Rust para Linux, destinada a supervisar las temperaturas de las GPU NVIDIA y ajustar dinámicamente sus límites de potencia.
La idea surgió de una necesidad real: disponer de un mecanismo de protección y control que me permitiera trabajar con varias tarjetas sin tener que vigilar continuamente sus temperaturas.
Este pequeño proyecto es otro ejemplo de cómo una necesidad de hardware puede terminar convirtiéndose en una herramienta de software.
La gestión térmica sigue siendo uno de los aspectos en los que quiero continuar trabajando, especialmente si finalmente incorporo una cuarta tarjeta al sistema.
9. La verdadera recompensa: ejecutar modelos de IA locales
Aunque el montaje de las tarjetas resulta entretenido, mi objetivo no es coleccionar hardware.
Lo que realmente me interesa es utilizarlo para desarrollar software y experimentar con modelos avanzados de inteligencia artificial.
Durante estos meses he probado numerosos modelos de lenguaje, especialmente aquellos que ofrecen buenos resultados en programación, razonamiento y utilización de herramientas.
Entre los más interesantes destacaría los siguientes.
Qwen3.8 Flash Next
Es uno de los modelos que más he utilizado.
Me gusta especialmente su equilibrio entre capacidad de razonamiento, comprensión del código y ejecución de tareas de desarrollo.
También he experimentado con diferentes cuantizaciones, buscando un equilibrio entre consumo de memoria, velocidad y calidad de respuesta.
Su comportamiento ha sido suficientemente bueno como para convertirse en una de mis referencias habituales.
De hecho, llegué a publicar en Hugging Face una versión propia basada en la combinación de diferentes variantes del modelo.
Nemotron 3.5 Super
Otro de los modelos que más me ha sorprendido ha sido Nemotron 3.5 Super.
Lo he utilizado con OpenCode en tareas reales de programación, ejecutándolo en formato GGUF con cuantización Q8.
Su calidad de respuesta me ha resultado especialmente convincente.
He encontrado alguna dificultad puntual relacionada con la elección de herramientas, pero, una vez aclarado el contexto, ha sido capaz de continuar trabajando correctamente.
Es uno de esos modelos que demuestran hasta qué punto ha evolucionado la inteligencia artificial abierta.
Ornith 1.5
También he obtenido resultados satisfactorios con Ornith 1.5, especialmente en tareas de desarrollo y comprensión de instrucciones.
Su comportamiento en español ha sido una de las características que más me han gustado.
En determinadas pruebas, los resultados generados por el modelo local fueron suficientemente buenos como para que un modelo externo de mayor capacidad apenas tuviera que realizar correcciones.
Otros modelos
También he experimentado con diferentes variantes de Qwen, modelos orientados específicamente a programación y modelos de gran tamaño cuantizados en GGUF.
Una de las ventajas de disponer de tanta memoria es que puedo probar cuantizaciones de mayor precisión sin tener que recurrir siempre a formatos muy comprimidos.
Esto no significa que una cuantización más grande produzca automáticamente mejores respuestas en todas las tareas.
Pero sí me permite elegir con mayor libertad y comparar resultados sin estar condicionado constantemente por la capacidad de las tarjetas.
10. Mi forma de trabajar: IA local supervisada por un modelo externo
Una de las conclusiones más importantes que he obtenido durante estos meses no tiene que ver directamente con el hardware.
Tiene que ver con la forma de utilizar los modelos.
Actualmente, una de las estrategias que mejores resultados me proporciona consiste en utilizar un modelo local para realizar las tareas de programación y otro modelo de mayor capacidad, accesible mediante API, para supervisar el resultado.
El modelo local analiza el proyecto, modifica archivos, genera código y ejecuta las herramientas disponibles.
Posteriormente, el modelo externo revisa el trabajo realizado y detecta posibles errores, omisiones o problemas de implementación.
Lo interesante es que, en muchas ocasiones, el modelo supervisor apenas necesita intervenir.
Esto demuestra que determinados modelos abiertos han alcanzado un nivel de calidad muy elevado para tareas reales de desarrollo.
Además, esta estrategia tiene una ventaja económica evidente.
En lugar de utilizar constantemente un modelo comercial de alto coste para todas las operaciones, puedo realizar gran parte del trabajo localmente y reservar el modelo externo para aquellas tareas en las que realmente aporta valor.
Para mí, esta es una de las mayores ventajas de disponer de una infraestructura propia de inteligencia artificial.
No se trata únicamente de ejecutar modelos grandes, sino de construir un flujo de trabajo eficaz, flexible y económicamente razonable.
11. ¿Qué problemas he encontrado?
Después de varios meses utilizando estas tarjetas, también tengo bastante claras sus limitaciones.
- La conectividad PCIe es reducida. Las tres tarjetas funcionan actualmente mediante PCIe 2.0 x4. Esto puede limitar determinadas estrategias de inferencia distribuida, especialmente cuando requieren transferencias frecuentes entre GPUs.
- La refrigeración requiere soluciones específicas. No son tarjetas que puedan instalarse sin prestar atención al flujo de aire y a las temperaturas.
- El desbloqueo depende del software. Una actualización del kernel o del controlador puede introducir incompatibilidades que obliguen a realizar ajustes.
- El montaje es complejo. Alimentación, espacio físico, conexiones externas, soportes, ventiladores y orden de encendido añaden dificultades que no aparecen en un equipo convencional.
- La compatibilidad no es equivalente a la de una GPU profesional moderna. Aunque el hardware es muy interesante, existen limitaciones funcionales y de soporte que deben tenerse en cuenta.
- Más VRAM no significa necesariamente más velocidad. Distribuir un modelo entre varias GPUs permite ejecutar modelos de mayor tamaño, pero también introduce costes de comunicación y sincronización.
Por todo ello, considero que las CMP 170HX son una opción especialmente interesante para entusiastas de la tecnología y desarrolladores dispuestos a experimentar.
No las recomendaría a alguien que necesite una solución sencilla, con soporte oficial y sin complicaciones de mantenimiento.
12. ¿Ha merecido la pena sustituir las RTX A5000?
En mi caso, la respuesta es claramente afirmativa.
He pasado de disponer de 48 GB de VRAM con dos RTX A5000 a tener un sistema con 192 GiB de VRAM distribuida entre tres CMP 170HX.
El incremento de capacidad es enorme.
Naturalmente, las RTX A5000 ofrecen ventajas importantes: mejor compatibilidad general, conexiones PCIe más modernas, refrigeración convencional y una integración más sencilla en estaciones de trabajo.
Pero mi prioridad ha cambiado.
Actualmente me interesa mucho más poder ejecutar modelos grandes, trabajar con cuantizaciones de alta calidad y experimentar con contextos extensos que disponer de una GPU especialmente versátil para tareas gráficas.
Además, el rendimiento que estoy obteniendo con mis modelos locales es suficientemente bueno como para utilizarlos de forma habitual en mis proyectos de desarrollo.
Por tanto, aunque las CMP 170HX presentan numerosas peculiaridades, considero que el cambio ha sido acertado para mis necesidades concretas.
13. Próximos pasos
Mi configuración todavía tiene margen de mejora.
En primer lugar, quiero seguir optimizando la refrigeración y el control de los ventiladores.
También tengo pendiente realizar pruebas más detalladas del rendimiento de llama.cpp al utilizar una, dos y tres tarjetas, así como estudiar las diferencias entre distintas estrategias de distribución del modelo.
Otro aspecto que me interesa es comprobar hasta qué punto puedo mejorar la utilización de la memoria y la velocidad de inferencia con modelos especialmente grandes.
Y, por supuesto, seguiré pendiente de la evolución del proyecto de desbloqueo, ya que cualquier mejora de compatibilidad o rendimiento puede resultar especialmente interesante para quienes utilizamos estas tarjetas.
A más largo plazo, tampoco descarto incorporar la cuarta CMP 170HX que todavía tengo disponible.
Pero antes quiero conocer bien las posibilidades y limitaciones de la configuración actual.
Conclusión
Cuando empecé a investigar las NVIDIA CMP 170HX, no imaginaba que terminarían convirtiéndose en el elemento principal de mi infraestructura de inteligencia artificial local.
Lo que comenzó como un experimento con unas tarjetas de minería ha terminado evolucionando hasta un sistema con tres GPU y 192 GiB de VRAM.
Por el camino he tenido que aprender y experimentar con controladores NVIDIA, desbloqueo de memoria, topologías PCIe, refrigeración, alimentación y distribución de modelos de lenguaje.
También he comprobado que disponer de mucha memoria no resuelve todos los problemas.
La velocidad de cálculo, las conexiones entre tarjetas, el software de inferencia y la forma de distribuir los modelos siguen siendo factores fundamentales.
Sin embargo, la experiencia ha sido extraordinariamente positiva.
Hoy puedo ejecutar modelos de lenguaje que hace relativamente poco tiempo habrían quedado fuera del alcance de mi equipo personal.
Y lo más importante: no los utilizo únicamente para realizar pruebas. Forman parte de mi trabajo cotidiano como desarrollador de software.
Para mí, ese es el verdadero valor de las CMP 170HX: haber convertido un hardware originalmente destinado a minería en una plataforma útil para experimentar, aprender y desarrollar con inteligencia artificial local.
No son tarjetas perfectas, ni mucho menos.
Pero, después de todo lo que he aprendido y de los resultados que estoy obteniendo, puedo afirmar que han sido una de las inversiones en hardware más interesantes que he realizado.
Y, probablemente, todavía no he descubierto todo lo que pueden ofrecer.
Referencias y recursos
- Mi primer artículo sobre las NVIDIA CMP 170HX
- Proyecto cmpunlocker en GitHub
- Proyecto de investigación y modificaciones CMP 170HX
- Mis proyectos y artículos en TakeOnMe
Artículo relacionado: NVIDIA CMP 170HX: de tarjetas de minería a 104 GB de VRAM para IA local