AMD RX580 ejecutó un LLM localmente: cómo superar ROCm, Ollama y lograr inferencia en GPU

Ejecutar una LLM en una antigua AMD RX580 resultó ser no una cuestión de un comando afortunado, sino una investigación de ingeniería completa. El autor intentaba obtener una inferencia adecuada de GPU a través de ROCm y Ollama en Kubernetes, pero en lugar de generación estable, obtuvo signos falsos de éxito, fallos de memoria y, en algunos casos, texto sin sentido en la salida.

Síntomas y Trampas

Al principio, todo lucía prácticamente funcional. La tarjeta gráfica se detectaba, los contenedores se levantaban, la VRAM se llenaba, lo que significaba que el sistema aparentemente estaba usando la GPU. Pero era una trampa: memoria ocupada no significa necesariamente que los cálculos estén ocurriendo correctamente en el procesador gráfico.

El principal problema se manifestaba en el momento de la inferencia real — las solicitudes fallaban con errores hipMemGetInfo o terminaban en generación extraña que superficialmente parecía el funcionamiento del modelo, pero en realidad no producía ningún resultado significativo.

GPU se detectaba, VRAM se ocupaba, contenedores se ejecutaban — pero

la inferencia fallaba con errores hipMemGetInfo.

Este caso ilustra bien un error típico al ejecutar LLM localmente: mirar solo la "apariencia de vida" de la infraestructura. Si Kubernetes lanzó el contenedor, Ollama vio el modelo, y la GPU ocupó varios gigabytes, esto aún no confirma que la pila ROCm esté realmente ejecutando operaciones matriciales correctamente. Para tarjetas antiguas como la RX580, es especialmente importante verificar no solo la disponibilidad del dispositivo, sino también el compute-path real, porque el fallo puede estar oculto bajo el nivel de la propia aplicación.

Cómo Encontraron la Causa

La raíz del problema se redujo no a través de otra reinstalación de paquetes, sino a través del diagnóstico del circuito computacional. El autor comparaba signos de funcionamiento en diferentes capas del sistema y separaba éxitos cosméticos de la ejecución real de inferencia. Vulkan se convirtió inesperadamente en la herramienta clave aquí: ayudó a verificar si la GPU podía realizar tareas computacionales de forma estable y, por lo tanto, evidenció que el problema no era reducible solo a Ollama o a la configuración del contenedor.

Esencialmente, la investigación fue de los síntomas a hipótesis comprobables. En lugar de adivinar por los registros, el autor eliminó sistemáticamente explicaciones falsas y armó una configuración mínimamente funcional, verificando cada capa por separado: desde contenedores y runtime hasta drivers y el propio modelo. Este orden es importante porque permite entender dónde termina la "infraestructura se levantó" y comienza el pipeline computacional real.

En el análisis, se veía paso a paso así:

• Verificación del compute real de GPU, no solo uso de VRAM
• Comparación del comportamiento de ROCm y Vulkan
• Filtrado de problemas de contenedor y orquestación
• Búsqueda de versiones compatibles de kernel y ROCm
• Control de la calidad de la salida del propio 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, el fallo puede no estar en la carga de pesos, sino en el funcionamiento incorrecto de la computación, incompatibilidad de drivers o un backend parcialmente funcional que solo parece vivo en la superficie. Estos estados semifuncionales típicamente consumen más tiempo que el fallo completo porque se disfrazan de bugs aleatorios de la aplicación.

Configuración Funcional en RX580

El experimento concluyó no con "ajuste mágico", sino con una combinación encontrada de versiones y componentes bajo la cual la antigua RX580 realmente produce resultados estables. El autor escribe que versiones específicas de ROCm y del kernel Linux resultaron funcionales, y después de resolver conflictos, la inferencia dejó de fallar y comenzó a producir texto normal. Esta es una conclusión importante para quien intenta ejecutar modelos locales en gráficos AMD no tan nuevos: el éxito aquí depende menos del soporte nominal de hardware que del alineamiento exacto de las capas de driver, sistema y runtime.

El resultado práctico se ve convincente: en la RX580, lograron obtener aproximadamente 42 tokens por segundo. Para una tarjeta gráfica doméstica de la generación pasada, esto no es solo una demostración sino un modo operacional en el que puedes probar asistentes locales, prototipos de escenarios RAG y servicios de inferencia personales sin necesariamente actualizar a una pila NVIDIA fresca. Pero la lección principal no está en la cifra de velocidad, sino en el método: si la GPU está "aparentemente funcionando", eso no es suficiente. Lo que necesita verificarse es la estabilidad de los cálculos, la corrección de la salida y la reproducibilidad de los resultados.

Qué Significa

La historia de la RX580 muestra que la inferencia LLM local en hardware AMD antiguo es posible, pero requiere disciplina en el diagnóstico. Para desarrolladores, esta es una buena pauta: no confundir VRAM ocupada con operación real del modelo, verificar toda la pila desde kernel hasta runtime, y tratar salida extraña como un error completo, no como un pequeño problema. Para laboratorios caseros, esto es prácticamente una lista de verificación lista para no gastar días persiguiendo signos falsos de éxito.