AMD RX580 ejecuta LLM en casa: cómo domar ROCm y Ollama y lograr inferencia en GPU

Ejecutar LLM en una vieja AMD RX580 no se resolvió con un único comando afortunado: acabó siendo una investigación de ingeniería en toda regla. El autor intentó obtener una inferencia en GPU normal con ROCm y Ollama en Kubernetes, pero en lugar de una generación estable se encontró con falsas señales de éxito, caídas por memoria y, en algunos casos, texto sin sentido en la salida.

Síntomas y trampas

Al principio todo parecía casi funcionar. La tarjeta gráfica se detectaba, los contenedores arrancaban y la VRAM se llenaba, así que el sistema aparentemente sí usaba la GPU. Pero era una trampa: que la memoria esté ocupada no significa que los cálculos se ejecuten correctamente en el procesador gráfico. El problema principal aparecía en el momento de la inferencia real: las peticiones fallaban con errores de hipMemGetInfo o terminaban en una generación extraña, que por fuera parecía el trabajo del modelo pero en la práctica no producía un resultado coherente.

La GPU se detectaba, la VRAM se ocupaba, los contenedores arrancaban,

pero la inferencia fallaba con errores de hipMemGetInfo.

Este caso ilustra bien un error típico al ejecutar LLM en local: fijarse solo en las «señales de vida» de la infraestructura. Que Kubernetes haya arrancado el contenedor, que Ollama haya visto el modelo y que la GPU haya ocupado varios gigabytes todavía no confirma que el stack de ROCm esté ejecutando las operaciones matriciales como debe. En tarjetas antiguas como la RX580 es especialmente importante comprobar tanto la disponibilidad del dispositivo como la ruta de cómputo real, porque el fallo puede esconderse por debajo del nivel de la propia aplicación.

Cómo se encontró la causa

El origen del problema no se acotó con otra reinstalación de paquetes, sino diagnosticando el circuito de cómputo. El autor comparó las señales de funcionamiento en distintas capas del sistema y separó los éxitos cosméticos de la ejecución real de la inferencia. La herramienta clave resultó ser, inesperadamente, Vulkan: sirvió para comprobar si la GPU era capaz de completar tareas de cómputo de forma estable y, con ello, dejó claro que el problema no se limitaba a Ollama o a la configuración del contenedor.

En esencia, la investigación avanzó de los síntomas a hipótesis verificables. En lugar de adivinar a partir de los logs, el autor fue descartando explicaciones falsas una a una y montó una configuración mínima funcional, verificando cada capa por separado: del contenedor y el runtime a los drivers y el propio modelo. Ese orden importa, porque es lo que permite ver dónde termina «la infraestructura está levantada» y dónde empieza el pipeline de cómputo real.

En el análisis, el proceso fue este, paso a paso:

• Comprobación del cómputo real en GPU, no solo del uso de VRAM
• Comparación del comportamiento de ROCm y Vulkan
• Descarte de problemas del contenedor y la orquestación
• Búsqueda de versiones compatibles del kernel y de ROCm
• Control de calidad de la propia salida del modelo

Este enfoque es importante porque el texto sin sentido en la salida también es una señal de diagnóstico. Si el modelo responde pero genera basura, la avería puede no estar en la carga de los pesos, sino en un cálculo incorrecto, en una incompatibilidad de drivers o en un backend parcialmente funcional que solo parece vivo en la superficie. Precisamente estos estados a medio funcionar suelen consumir más tiempo que un fallo total, porque se camuflan como bugs aleatorios de la aplicación.

La combinación que funciona en la RX580

El experimento no terminó con un «ajuste mágico», sino con una combinación de versiones y componentes con la que la vieja RX580 sí ofrece un resultado estable. El autor explica que funcionaron determinadas versiones de ROCm y del kernel de Linux, y que, tras eliminar los conflictos, la inferencia dejó de fallar y empezó a producir texto normal. Es una conclusión importante para quien intente ejecutar modelos locales en gráficas AMD no tan recientes: el éxito depende menos del soporte nominal del hardware que de que coincidan con precisión las capas de drivers, sistema y runtime.

El resultado práctico es convincente: en la RX580 se lograron unos 42 tokens por segundo. Para una tarjeta doméstica de la generación anterior, esto ya va más allá de una demostración: es un modo de trabajo en el que se pueden probar asistentes locales, prototipos de escenarios RAG y servicios de inferencia personales sin necesidad de actualizar a un stack reciente de NVIDIA. Pero la lección principal está en el método más que en la cifra de velocidad: que la GPU «parezca funcionar» no basta. Hay que comprobar precisamente la estabilidad del cómputo, la corrección de la salida y la reproducibilidad del resultado.

Qué significa esto

El caso de la RX580 demuestra que la inferencia local de LLM en hardware AMD antiguo es posible, pero exige disciplina en el diagnóstico. Para los desarrolladores es una buena referencia: no confundir VRAM ocupada con el funcionamiento real del modelo, revisar todo el stack del kernel al runtime y tratar una salida extraña como un error en toda regla, no como un fallo menor. Para los laboratorios domésticos, es casi una checklist lista para usar para no perder días con falsas señales de éxito.