ROCm frente a Vulkan para la implementación local de LLM en AMD: Guía 2026

ROCm y Vulkan aceleran tanto las GPU de AMD para el alojamiento local de LLM, pero no son intercambiables. La elección correcta depende del motor, la GPU y la carga de trabajo.

En el alojamiento local de LLM, los dos backends se ubican en capas diferentes. ROCm es la plataforma de cálculo de AMD bajo PyTorch, vLLM y SGLang, mientras que Vulkan es una API de GPU portable que los motores de la clase llama.cpp utilizan para ejecutar modelos cuantizados en una amplia variedad de hardware.

Esta guía compara ambos motores uno por uno — llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI y LocalAI — con comandos de compilación, verificaciones de dispositivo y modos de fallo que se disfrazan de problemas de rendimiento. Si eres nuevo en el panorama de alojamiento, comienza con la Visión general del alojamiento de LLM, que mapea las familias de herramientas en las que este artículo profundiza.

ROCm vs Vulkan: la respuesta corta

Esta tabla es una política de inicio, no un resultado de referencia cruzada. Un backend que detecta la GPU pero deja algunas operaciones en la CPU puede parecer saludable mientras tiene un mal rendimiento, por lo que cada decisión final necesita inspección de registros y una prueba de prompt extremo a extremo.

Qué son realmente ROCm y Vulkan

ROCm es una plataforma de cálculo

ROCm incluye el runtime HIP, el compilador, las librerías matemáticas, la comunicación colectiva, los analizadores de rendimiento y los paquetes de framework necesarios para ejecutar cargas de trabajo de cálculo en AMD. Es el fundamento del lado de AMD bajo las compilaciones de PyTorch y motores como vLLM y SGLang, y también puede acelerar llama.cpp a través de su backend HIP.

Esa amplitud es la ventaja de ROCm y su costo. El controlador del host, el objetivo de la GPU, las librerías de espacio de usuario, la rueda del framework, la versión del kernel y la imagen del contenedor deben formar un conjunto compatible; cuando lo hacen, ROCm ofrece mucho más que la generación de tokens a través de un único ejecutable local.

ROCm 10.0.0, lanzado el 26 de agosto de 2026, está construido sobre TheRock (el sistema de compilación y lanzamiento de AMD desde ROCm 7.14), valida PyTorch 2.13, vLLM 0.27 y SGLang 0.5.15, y agrega formalmente el soporte para RDNA 4 para gfx1200 (RX 9060/9060 XT/9050) y gfx1201 (RX 9070/9070 XT/9070 GRE, serie Radeon AI PRO R9700). La matriz de compatibilidad de ROCm sigue siendo la autoridad para una combinación exacta de GPU y sistema operativo, no una publicación en un foro que casualmente utiliza la misma familia de marketing.

Vulkan es una interfaz de GPU portable

Vulkan es una API de gráficos y cálculo implementada por un controlador de GPU. En el alojamiento local de LLM, normalmente significa que un motor de inferencia empaqueta o compila shaders de cálculo que se ejecutan a través de una implementación de Vulkan, como Mesa RADV en Linux o el controlador del proveedor en Windows.

Vulkan no proporciona una plataforma PyTorch de reemplazo directo comparable a ROCm. Su fortaleza práctica es más estrecha y útil: un motor de estilo llama.cpp puede utilizar el mismo diseño de backend en AMD, Intel, Nvidia y otros hardware compatibles con Vulkan sin instalar una pila de aprendizaje automático específica del proveedor.

Esta distinción explica la mayor parte de la decisión. Si la aplicación ofrece solo una ruta HIP o PyTorch, Vulkan no puede rescatarla; si la aplicación ya está basada en llama.cpp y GGUF, instalar toda la pila ROCm puede resolver un problema que no tenías.

Matriz de soporte de motores en 2026

ROCm no implica Safetensors, y Vulkan no implica formalmente GGUF. La asociación útil proviene de los motores: llama.cpp puede leer el mismo GGUF con su compilación HIP o Vulkan, mientras que los servidores nativos de PyTorch usan ROCm y generalmente consumen repositorios de modelos de Hugging Face.

Eso convierte el inventario de modelos en una restricción arquitectónica. Una biblioteca de cuantizaciones GGUF seleccionadas cuidadosamente apunta naturalmente hacia llama-server, Ollama, LM Studio o LocalAI; un despliegue construido en torno a la paralelización de tensores, el loteo continuo y los pesos nativos del framework apunta hacia ROCm con vLLM o SGLang. Para el panorama más amplio de motores más allá de los backends de AMD — madurez de API, llamado de herramientas y preparación para producción a través de una docena de herramientas — consulta nuestra comparación de Ollama, vLLM, LM Studio, LocalAI y otras herramientas de alojamiento local de LLM.

llama.cpp: la comparación ROCm vs Vulkan más limpia

llama.cpp expone ambos backends sin cambiar el archivo del modelo o el cliente HTTP. Este es el lugar más justo para comparar ROCm y Vulkan porque el tokenizador, los ajustes de muestreo, la plantilla de chat, la cuantización y el comportamiento del servidor pueden permanecer fijos.

La documentación actual de compilación de llama.cpp utiliza GGML_HIP para ROCm y GGML_VULKAN para Vulkan. Los artículos antiguos que recomiendan GGML_ROCM o los flags de Makefile eliminados no deben ser confiados sin verificar las opciones CMake actuales del proyecto.

Compilar el backend Vulkan en Ubuntu

Instala las cabeceras de Vulkan, el compilador de shaders y las cabeceras de SPIR-V, luego verifica que el controlador pueda enumerar la GPU prevista:

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

En un sistema con iGPU mixto y GPU discreta, el orden de enumeración merece atención. GGML_VK_VISIBLE_DEVICES puede restringir llama.cpp a un dispositivo Vulkan específico, y el registro de inicio debe nombrar la tarjeta seleccionada en lugar de informar simplemente que existe un dispositivo Vulkan.

Compilar el backend ROCm o HIP

Primero confirma que ROCm identifica la GPU e informa el objetivo gfx esperado. El objetivo puede omitirse para compilar para las GPUs del sistema actual, pero fijarlo reduce el trabajo de compilación cuando conoces el hardware del despliegue.

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

Reemplaza gfx1201 con el objetivo informado para la tarjeta real — ese valor mapea a la familia RX 9070/9070 XT/9070 GRE y Radeon AI PRO R9700 en RDNA 4, mientras que gfx1200 cubre la serie RX 9060 y gfx1100/gfx1101/gfx1102 cubren las líneas RX 7900/7800/7700/7600 de RDNA 3. No copies HSA_OVERRIDE_GFX_VERSION a un servicio de producción simplemente porque ayudó a alguien a iniciar una GPU no soportada; una superposición puede hacer que el código cargue, pero no convierte ese hardware en una plataforma validada.

Hacer referencia cruzada de la misma carga de trabajo, no de dos valores predeterminados

Usa un archivo GGUF, la misma configuración de flash-attention, el mismo offload de capas y ejecuciones repetidas. El procesamiento de prompts (pp) y la generación de tokens (tg) ejercitan el sistema de manera diferente, mientras que un servidor de contexto largo también agrega la asignación de KV-cache y la presión de memoria que una referencia cruzada sintética corta perderá.

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

Los resultados de la comunidad ilustran por qué un ganador universal es engañoso, y el objetivo gfx1201 de RDNA 4 es el ejemplo reciente más claro. En una presentación de RX 9070 XT en la misma máquina, Vulkan alcanzó alrededor de 143 token/s contra 128 token/s de ROCm en la prueba de generación 7B Q4_0, pero presentaciones posteriores mostraron diferencias menores a medida que cambiaban las compilaciones; las discusiones de Vulkan y ROCm también contienen grandes diferencias en los resultados de procesamiento de prompts y las condiciones de prueba. Una ejecución separada y más detallada de OpenBenchmarking.org en una RX 9070 XT con llama.cpp b6401 encontró que Vulkan iba por delante en decodificación en varios modelos de clase 8B (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0) pero iba por detrás de HIP en el procesamiento de prompts con longitudes de prompt más largas — los dos backends intercambian el liderazgo dependiendo de qué fase se mida.

La brecha también puede correr en la dirección opuesta, y con mucha diferencia, para formas de modelos específicas. Un problema abierto de llama.cpp documenta que Vulkan en gfx1201 se vuelve 4,7–6,7 veces más lento que HIP en la generación de tokens una vez que el tamaño oculto del modelo alcanza 4096 o más (el ancho de banda efectivo de decodificación colapsa a aproximadamente 70–100 GB/s en una tarjeta de 640 GB/s), mientras que un modelo 4B más pequeño con tamaño oculto 2560 no muestra tal regresión en ningún backend. Trata cada número aquí como una instantánea de una compilación, un controlador y una forma de modelo — no como una regla que se generalice a través del tipo de cuantización, la arquitectura del modelo, la atención flash, los tamaños de lote, la versión del controlador, el estado térmico o el commit de llama.cpp.

Ollama en AMD: conveniente, pero verifica el backend

Ollama soporta oficialmente las GPUs AMD listadas a través de ROCm y ahora documenta una cobertura adicional de AMD a través de Vulkan en Windows y Linux. Su actual página de soporte de hardware dice que Vulkan está habilitado por defecto cuando el backend está instalado, soporta GGML_VK_VISIBLE_DEVICES para la selección de dispositivo y puede deshabilitar Vulkan con OLLAMA_VULKAN=0.

Esta es una mejora significativa frente al período cuando el consejo de Vulkan dependía de compilaciones experimentales. También hace que algunos tutoriales antiguos queden desactualizados: configurar un interruptor no documentado y asumir que el servicio seleccionó Vulkan es una evidencia más débil que leer el registro del servidor.

sudo systemctl edit ollama

Para diagnósticos, añade un drop-in en lugar de exportar variables solo en una shell interactiva:

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

Luego recarga, reinicia e inspecciona tanto la ubicación del proceso como los mensajes de descubrimiento:

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

Busca la GPU nombrada, la librería seleccionada, la asignación del modelo y el porcentaje de GPU. Un registro que muestra un timeout de descubrimiento seguido de una respuesta HTTP exitosa puede significar que Ollama retrocedió silenciosamente a la CPU. Para el conjunto de comandos cotidianos alrededor de este servicio, la hoja de referencia de Ollama CLI es la referencia más rápida.

Ollama es excelente cuando la adquisición del modelo y una API local estable importan más que el control del backend. Si la prueba repetible de ROCm contra Vulkan es el objetivo, llama-server puro es el instrumento mejor porque el directorio de compilación hace que el backend sea explícito.

vLLM y SGLang hacen de ROCm la decisión — pero verifica primero la cobertura de kernels de la familia de GPU

vLLM y SGLang no son aplicaciones de Vulkan. Sus rutas AMD se basan en ROCm, PyTorch y kernels HIP optimizados, por lo que elegir uno de estos motores ya ha seleccionado la plataforma de cálculo.

La actual guía de vLLM en ROCm de AMD recomienda un contenedor precompilado y publica imágenes correspondientes para ROCm, PyTorch, Python y vLLM. Ese acoplamiento es útil: reemplaza un gran ejercicio de resolución de dependencias con una unidad de despliegue versionada.

En el momento de escribir esto, AMD documenta esta imagen ROCm 10 para vLLM 0.27:

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

Usa la imagen seleccionada para la familia exacta de GPU en la documentación de AMD; las imágenes RDNA y CDNA no siempre han sido intercambiables. Para un servidor de producción, fija la etiqueta completa o el digest y valida el controlador del host antes de culpar a vLLM por un fallo de inicialización.

Las generaciones de GPU de nueva creación son el caso límite más agudo, y RDNA 4 es un ejemplo real y documentado, no un riesgo teórico. Pruebas independientes en una RX 9070 XT (gfx1201) a principios de 2026 encontraron que vLLM en ROCm 7.2 retrocedía silenciosamente a la descuantización FP32 para pesos de modelo FP8 — porque gfx1201 aún no era reconocido en la detección de plataforma de vLLM — lo que evitaba por completo los aceleradores de matriz de la GPU y producía solo 48 tokens/s, en comparación con 62 tokens/s de llama-server en Vulkan ejecutando una cuantización GGUF de un modelo comparable en la misma tarjeta. La lección se generaliza: un stack ROCm/PyTorch puede cargar exitosamente en una nueva arquitectura y aún así ejecutar una ruta de retroceso no optimizada sin mensaje de error. Confirma siempre qué ruta de kernel se ejecutó realmente (vía rocprof, notas de perfilado del proveedor o una línea base de throughput conocida para la GPU) antes de confiar en un solo resultado de “se inició bien” en hardware lanzado dentro del último ciclo de lanzamiento o dos.

La razón para aceptar la mayor superficie operativa de ROCm, una vez confirmada la cobertura de kernels, es la arquitectura de throughput — no meramente algunos tokens/s más en una prueba de usuario único. El loteo continuo, la cuantización nativa del framework, la paralelización de tensores, el comportamiento del programador y las herramientas PyTorch circundantes son el caso real para migrar a vLLM, y si estás evaluando si esa migración está justificada en absoluto, nuestra guía de migración de Ollama a vLLM lista las señales de carga de trabajo.

TGI: soporte ROCm con un objetivo más estrecho

Hugging Face documenta una imagen AMD para Text Generation Inference, pero su validación publicada está centrada en el hardware Instinct MI210, MI250 y MI300. La guía de TGI para AMD usa la imagen 3.3.5-rocm y lista características ROCm no soportadas, por lo que no debe generalizarse en una promesa para cada tarjeta Radeon. Nuestra guía de instalación de TGI cubre esa configuración de imagen ROCm en más detalle.

No hay una ruta Vulkan para TGI con la que comparar. Si TGI es un requisito fijo, elige hardware ROCm soportado y reproduce el contenedor documentado; si el motor es negociable, el soporte actual de vLLM y SGLang merece evaluación antes de comenzar un nuevo despliegue AMD.

LM Studio: cambia runtimes en lugar de recompilar

LM Studio empaqueta múltiples runtimes de inferencia y expone la gestión de runtimes a través del comando lms. Su documentación de runtime soporta listar, descargar, seleccionar, actualizar y eliminar runtimes, lo que hace que los experimentos de ROCm contra Vulkan sean accesibles sin mantener árboles de fuente separados.

lms runtime ls
lms runtime get
lms runtime select

Ejecuta el mismo GGUF con la misma longitud de contexto, offload de GPU, configuración de flash-attention y prompt. Compara el tiempo hasta el primer token, la tasa de generación, el tiempo de carga y la memoria pico en lugar de juzgar un backend por una respuesta de chat corta.

El empaquetado de runtimes no elimina los fallos específicos del backend. Por ejemplo, un problema de LM Studio en R9700 en 2026 informó de un gran modelo colgando cerca del final de una carga ROCm mientras el runtime Vulkan lo cargaba, mientras que un problema separado de margen de memoria Vulkan describió el resultado opuesto cerca de la VRAM completa. Estos son informes individuales, pero juntos hacen el punto operativo correcto: mantén un runtime de retroceso y deja margen de memoria.

LocalAI: elige la imagen así como el backend

LocalAI proporciona variantes de contenedor separadas ROCm o hipblas y Vulkan. Su guía de aceleración de GPU documenta las imágenes gpu-hipblas para el cálculo AMD y las imágenes gpu-vulkan para la ruta portable, por lo que una etiqueta de contenedor copiada de una guía CUDA no descubrirá el backend correcto por magia. El arranque rápido de LocalAI cubre la configuración general; la elección de contenedor específica del backend es lo que esta sección añade.

El contenedor ROCm necesita /dev/kfd y /dev/dri, mientras que Vulkan normalmente necesita el dispositivo de render adecuado bajo /dev/dri. Fija una etiqueta de lanzamiento para un servicio real; latest y master son útiles para el diagnóstico, pero hacen que la reversión y la comparación de rendimiento sean innecesariamente vagas.

# Imagen ROCm o HIP
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Imagen Vulkan
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

Los ejemplos de etiquetas reflejan la documentación disponible en el momento de la publicación; confirma los nombres actuales del registro antes de automatizar un pull. Más importante aún, no infieras la aceleración solo por el nombre del contenedor — inspecciona el registro de depuración de LocalAI y observa la utilización de GPU durante una solicitud.

Qué cambió en el empaquetado de ROCm 10

ROCm 10 no es solo otra actualización menor de paquetes. La guía de transición de TheRock de AMD dice que los paquetes del SDK Core de ROCm ahora usan el prefijo amdrocm-, la raíz de instalación versionada es /opt/rocm/core-10.0, y varios paquetes legados han sido consolidados.

Esta es la razón por la que un comando de un artículo antiguo de ROCm puede devolver “paquete no encontrado” incluso en un repositorio correctamente configurado. Por ejemplo, HIPCC ahora proviene de amdrocm-llvm, los componentes BLAS se combinan en amdrocm-blas, y una instalación de sistema completa puede usar un metapaquete del SDK Core para todas las arquitecturas o específico de la familia de GPU — las tarjetas RDNA 4 usan la etiqueta de familia gfx120X-all (sufijo de paquete -gfx1200-gfx1201), lo cual es valioso saber antes de buscar un nombre de paquete solo gfx1201 que no existe.

El metapaquete amdrocm configura alternativas y enlaces de compatibilidad bajo /opt/rocm. Una instalación mínima o personalizada puede no proporcionar las mismas rutas, por lo que los guiones de compilación que codifican /opt/rocm/bin/hipcc deben usar hipconfig o establecer ROCM_PATH explícitamente.

Dos cambios de diagnóstico son fáciles de pasar por alto. ROCm SMI ha sido eliminado en favor de AMD SMI, y ROCm Bandwidth Test llegó a fin de vida; los guiones que llaman a rocm-smi o rocm-bandwidth-test necesitan migrar a amd-smi y las herramientas de reemplazo de AMD en lugar de reinstalar paquetes legados arbitrarios.

Los contenedores aún dependen del host

Un contenedor ROCm lleva librerías de espacio de usuario, no un controlador de kernel de reemplazo. El host debe exponer /dev/kfd y /dev/dri, su controlador debe ser compatible con el stack del contenedor, y el usuario del servicio necesita permiso para abrir esos dispositivos.

Los contenedores Vulkan tienen un límite similar alrededor del controlador Vulkan y el nodo de render del host. El empaquetado es más ligero, pero una ICD incorrecta, la falta de pertenencia al grupo de render, o una iGPU seleccionada accidentalmente aún pueden convertir una imagen de contenedor funcional en un servicio dependiente de CPU o inestable.

GPUs discretas, APUs y tarjetas Radeon antiguas

GPUs discretas RDNA 3 y RDNA 4

Los modelos actuales Radeon RX 7000, RX 9000 y Radeon AI Pro tienen el caso más fuerte para probar ambos backends de llama.cpp. El soporte ROCm ahora es explícito para muchos objetivos gfx110x y gfx120x, mientras que Vulkan a través de un Mesa RADV actual o un controlador de proveedor en Windows es lo suficientemente maduro para ser una ruta primaria en lugar de un retroceso desesperado. Para el lado de hardware de esa decisión — VRAM, ancho de banda, potencia y precios entre proveedores — consulta nuestra comparación de GPUs para cargas de trabajo de IA en 2026.

No conviertas una referencia cruzada de 7B en una regla para un modelo denso de 27B o un modelo de mezcla de expertos. Las formas de matriz, los parámetros activos, los kernels cuantizados, la longitud del prompt y la presión de memoria pueden cambiar el orden, y el rendimiento del backend ha cambiado sustancialmente entre revisiones de llama.cpp — la regresión de tamaño oculto gfx1201 anotada anteriormente es un caso concreto de exactamente este tipo de cambio.

APUs Ryzen y memoria compartida

Los sistemas Ryzen AI Max de gran memoria son inusualmente interesantes porque la GPU puede acceder a un pool de memoria compartida mucho mayor que el que ofrece una tarjeta discreta de consumo normal. ROCm 10 lista las familias Ryzen AI actuales, mientras que los runtimes de llama.cpp compatibles con Vulkan también pueden usar la iGPU sin construir un entorno PyTorch.

La capacidad no es el ancho de banda. Que un modelo quepa en 64 GB o 96 GB de memoria compartida asignada no significa que decodificará como una tarjeta discreta de 32 GB, y una asignación agresiva de contexto puede privar al sistema operativo incluso cuando una aplicación informa de memoria GPU abundante. La misma disciplina de presupuesto de VRAM que se aplica a las tarjetas discretas NVIDIA y AMD se aplica también aquí — consulta KV Cache en GPUs de 16 GB para las matemáticas subyacentes de presupuesto, que son independientes del backend.

Las máquinas con iGPU y dGPU mixtos necesitan una selección de dispositivo explícita. Un informe reciente de llama.cpp describió una reserva excesiva de memoria del sistema cuando una iGPU no utilizada permanecía visible junto a una R9700; es un problema no confirmado, pero es una buena razón para exponer solo el dispositivo que el servicio está destinado a usar.

Hardware Radeon antiguo y no soportado

Vulkan suele ser la primera ruta para una Radeon antigua porque la cobertura del controlador de gráficos es más amplia que el conjunto de objetivos de cálculo soportados de ROCm. Los proyectos basados en ROCm también notan que las versiones nuevas de rocBLAS eliminaron kernels para algunos objetivos antiguos, por lo que forzar un valor gfx cercano no puede restaurar el código que ya no se entrega.

Una superposición es aceptable para un experimento de laboratorio con expectativas de fallo claras. Es una base pobre para una API sin atención, porque la próxima actualización de ROCm o de la aplicación puede reemplazar un desajuste tolerado con un fallo de inicio o un resultado incorrecto.

Linux vs Windows para backends LLM de AMD

Linux es el host ROCm natural para la inferencia de producción. Ofrece el soporte más amplio de motores, el mapeo de dispositivos de contenedor establecido, los controladores Vulkan Mesa actuales y las herramientas operativas esperadas por los despliegues de vLLM y SGLang.

Windows tiene un soporte ROCm genuino para hardware listado, pero el ecosistema de aplicaciones permanece más estrecho. Para la inferencia GGUF de escritorio a través de llama.cpp, Ollama o LM Studio, Vulkan suele ser el punto de partida más tranquilo; usa ROCm cuando la aplicación proporciona una ruta Windows soportada y una función o referencia cruzada concreta lo justifica.

WSL2 debe tratarse como una tercera plataforma, no como un sinónimo de Linux nativo. Coincide el controlador de Windows documentado por AMD, la distribución WSL, la liberación ROCm y el paquete del framework como una combinación soportada.

Lista de verificación de verificación antes de servir tráfico

Comienza por debajo de la aplicación. Si el controlador no puede enumerar el dispositivo correcto, cambiar los flags del modelo solo está reorganizando el síntoma.

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# Ruta ROCm
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Ruta Vulkan
vulkaninfo --summary

Luego verifica el motor. La salida de inicio debe nombrar ROCm o Vulkan, nombrar la GPU prevista e informar que las capas o tensores del modelo se colocaron en ella; finalmente, la memoria y la utilización de GPU deben aumentar mientras una solicitud se esté ejecutando.

# Observa una GPU AMD mientras otro terminal envía solicitudes
watch -n1 amd-smi monitor

# Verificación básica de API compatible con OpenAI para llama-server
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Registra el controlador, el runtime, el commit o digest de imagen del motor, la suma de verificación del archivo del modelo, el contexto, los ajustes de lote y la línea de comando con cada referencia cruzada. Sin esos metadatos, un número de tokens por segundo es una anécdota que no puede sobrevivir a la próxima actualización — y como tanto el retroceso de vLLM en gfx1201 como la regresión de tamaño oculto de Vulkan anteriores muestran, un número con apariencia plausible puede ocultar una ruta de código no optimizada silenciosamente.

Modos de fallo que parecen rendimiento del backend

Retroceso a CPU silencioso

El servidor se inicia y responde correctamente, pero la generación es inesperadamente lenta y la utilización de GPU permanece plana. Revisa los registros de descubrimiento, los permisos del dispositivo, el offload del modelo y los dispositivos del contenedor antes de ajustar hilos o parámetros de muestreo.

Retroceso de precisión silencioso (nuevo hardware, nuevos kernels)

El servidor se inicia, la utilización de GPU parece razonable y no hay error — pero el framework retrocedió silenciosamente a una ruta numérica no optimizada porque la capacidad de cálculo de la GPU o la cadena de arquitectura aún no era reconocida. Esto es exactamente lo que sucedió con los kernels FP8 de vLLM en gfx1201; la corrección es revisar el código de detección de plataforma del propio framework o su rastreador de problemas para tu cadena exacta de GPU antes de confiar en un número de throughput único en una generación de GPU lanzada en el último ciclo de lanzamiento o dos.

Se selecciona la GPU incorrecta

Un escritorio Ryzen puede exponer una iGPU como dispositivo Vulkan 0 y una Radeon discreta como dispositivo 1. Restringe los dispositivos visibles y confirma el nombre completo del dispositivo en el registro; no asumas que la numeración es estable después de un cambio de controlador o BIOS.

Desajuste de objetivo ROCm

rocminfo informa un objetivo gfx mientras la imagen de la aplicación contiene kernels para otro conjunto. Usa una imagen coincidente o recompila para el objetivo exacto; reserva HSA_OVERRIDE_GFX_VERSION para experimentos explícitamente no soportados.

Desajuste entre controlador y espacio de usuario

El contenedor tiene librerías ROCm actuales, pero el controlador del host pertenece a un flujo de lanzamiento antiguo. Los timeouts durante el descubrimiento, los errores de lanzamiento de kernel o el retroceso a la CPU son más probables que un mensaje limpio que explique el límite de versión.

Confusión de ICD Vulkan

Se instala más de una implementación Vulkan y el cargador selecciona una ICD inesperada. Inspecciona vulkaninfo, elimina duplicados accidentales o selecciona explícitamente la ICD y el dispositivo previstos en lugar de apilar otro SDK sobre el problema.

Las estimaciones de VRAM no dejan margen operativo

El modelo parece caber pero falla durante el calentamiento, la configuración de flash-attention o el primer prompt largo. Deja varios gigabytes de margen en un modelo grande, luego reduce el contexto o el tamaño de lote antes de concluir que el backend no puede ejecutar la cuantización.

Un procedimiento práctico de selección de backend

Paso 1: elige el comportamiento de servicio

Si el objetivo es uno o dos usuarios locales, archivos GGUF y un extremo compatible con OpenAI simple, comienza con llama-server, Ollama o LM Studio. Si el objetivo es el loteo continuo, la alta concurrencia, los modelos nativos del framework o la paralelización de tensores, comienza con vLLM o SGLang y acepta ROCm como parte del diseño.

Paso 2: verifica el soporte oficial de hardware

Coincide el objetivo exacto de GPU, la versión del sistema operativo, el kernel y el controlador en la matriz ROCm actual. Para Vulkan, confirma la GPU prevista a través de vulkaninfo y usa un controlador actual en lugar de asumir que la presencia de libvulkan.so prueba el soporte de cálculo útil. Si la GPU es de la generación de arquitectura más nueva, también revisa el código de detección de plataforma del framework específico o los problemas abiertos para ese objetivo exacto gfx — el soporte oficial y el soporte de kernels optimizados no siempre se lanzan juntos.

Paso 3: establece la línea base de trabajo más simple

Para GGUF, Vulkan normalmente es esa línea base porque cambia menos componentes del sistema. Para un motor PyTorch, usa el contenedor ROCm fijado de AMD en lugar de ensamblar torch, Triton, AITER y vLLM de las últimas versiones no relacionadas.

Paso 4: haz referencia cruzada de prompts con forma de producción

Mide el procesamiento de prompts, el tiempo hasta el primer token, la tasa de decodificación, la memoria pico y el comportamiento de solicitudes concurrentes. Incluye el patrón de contexto y de llamado de herramientas que el servicio real usará; una microreferencia de 128 tokens no predice una sesión de agente de 100.000 tokens.

Paso 5: mantén el retroceso desplegable

Dos directorios de compilación de llama.cpp cuestan poco en comparación con un día perdido por una regresión de controlador. Mantén el digest de contenedor o el runtime conocido como bueno instalado, y avanza solo después de que el candidato pase el mismo conjunto de pruebas.

El mismo procedimiento como un flujo de decisión:

Veredicto final: ¿ROCm o Vulkan para el alojamiento de LLM en AMD?

Vulkan es el valor predeterminado mejor para la inferencia local GGUF cuando la portabilidad, la velocidad de configuración, el soporte de Windows o la cobertura de Radeon antigua importan. Ya no es razonable describirlo como inherentemente lento; en algunas combinaciones recientes de Radeon y llama.cpp es el backend más rápido, y en otros está lo suficientemente cerca como para que la menor fricción operativa gane.

ROCm es la elección correcta cuando el motor está construido en torno a PyTorch, cuando AMD Instinct y el cálculo multi-GPU son centrales, o cuando una compilación HIP probada gana la carga de trabajo del modelo real. Su ecosistema es mucho más fuerte en 2026, pero el nuevo empaquetado y las capas estrictas de compatibilidad aún premian las versiones fijadas y la verificación disciplinada — y en la generación más nueva de RDNA específicamente, verificar que la ruta de kernel optimizado se ejecutó realmente no es opcional.

Para una estación de trabajo Radeon soportada, mi recomendación es deliberadamente no romántica: instala Vulkan primero, añade ROCm cuando un motor o una referencia cruzada merezca la complejidad, y mantén ambas compilaciones de llama.cpp si la máquina sirve regularmente formas de modelo diferentes. El mejor backend AMD no es una propiedad permanente de la tarjeta; es una propiedad de la tarjeta, el motor, el modelo, el controlador y la carga de trabajo juntos.

Referencias

• Notas de lanzamiento de ROCm 10.0.0
• Matriz de compatibilidad de ROCm
• Transición de TheRock y mapeo de paquetes de ROCm
• Instrucciones de compilación HIP y Vulkan de llama.cpp
• Soporte de hardware AMD y Vulkan de Ollama
• Guía de inferencia y servicio de vLLM de AMD
• Hugging Face TGI en GPUs AMD
• Gestión de runtime de LM Studio
• Aceleración de GPU de LocalAI
• Discusión de rendimiento de Vulkan de llama.cpp
• Discusión de rendimiento de ROCm de llama.cpp
• Angelov, I. “Inferencia local de LLM en AMD RX 9070 XT — Referencias cruzadas de Vulkan vs ROCm en RDNA4.” digtvbg.com, marzo de 2026. https://digtvbg.com/blog/llama-server-vulkan-rdna4-vllm-rocm-benchmark/
• “Referencias cruzadas de ROCm Vs. Vulkan Llama.cpp RDNA4 Radeon RX 9070 XT.” OpenBenchmarking.org. https://openbenchmarking.org/result/2509078-NE-ROCMVSVUL92
• "[Vulkan] Enlentecimiento patológico de generación de tokens en RX 9070 XT (gfx1201) para modelos con hidden_size >= 4096." Problema de GitHub de llama.cpp.