Architecture-Aware LLM Inference Optimization on AMD Instinct GPUs: A Comprehensive Benchmark and Deployment Study

Este estudio presenta una evaluación exhaustiva de la inferencia de LLMs en GPUs AMD Instinct MI325X, demostrando que la optimización consciente de la arquitectura es crucial para maximizar el rendimiento, revelando que modelos con diferentes diseños (como MoE+MLA frente a Dense+GQA) requieren configuraciones específicas de vLLM y AITER para alcanzar un alto rendimiento y fiabilidad en cargas de trabajo de texto y visión.

Lo esencial

¡Claro que sí! Imagina que este informe técnico es como una guía de viaje para un camión de mudanzas de última generación, pero en lugar de muebles, estamos moviendo "cerebros digitales" gigantes (modelos de Inteligencia Artificial) a través de un nuevo tipo de carretera (los chips de AMD).

Aquí tienes la explicación de lo que descubrieron, contada como una historia:

🚚 El Escenario: Un Camión Gigante (AMD MI325X)

Los investigadores probaron sus modelos de IA en un nuevo camión eléctrico muy potente llamado AMD Instinct MI325X.

• La analogía: Imagina que este camión tiene un baúl de almacenamiento inmenso (2 Terabytes de memoria) y una autopista de 8 carriles (8 tarjetas gráficas) que permite mover cosas a una velocidad increíble.
• El objetivo: Querían ver qué tan rápido podían entregar "paquetes de pensamiento" (tokens) a miles de clientes al mismo tiempo.

🧠 Los Pasajeros: Cuatro Tipos de Cerebros

No todos los modelos de IA son iguales. Probaron cuatro "pasajeros" muy diferentes, cada uno con una personalidad distinta:

1. Llama-3.1-405B (El Gigante Duro): Un cerebro denso y pesado. Piensa en un elefante que usa todos sus músculos para cada paso. Es muy fuerte, pero lento porque tiene que mover todo su peso.
2. DeepSeek V3.2 y Kimi-K2.5 (Los Expertos Selectivos): Son modelos "MoE" (Mezcla de Expertos). Imagina un equipo de cirujanos donde, para cada problema, solo se despiertan 3 o 4 expertos y el resto descansa. Son muy eficientes porque no mueven todo el peso, solo lo necesario.
   • Nota: Kimi-K2.5 es el más grande de todos (1 billón de parámetros), ¡como un cerebro del tamaño de un planeta!
3. Qwen3-VL-235B (El Polímata Visual): Un cerebro que puede ver imágenes y leer texto al mismo tiempo. Es como un detective que tiene lupa y libro de notas.

🔧 El Problema: "No sirve una llave para todas las cerraduras"

Lo más importante que descubrieron es que no puedes usar la misma configuración para todos. Es como intentar ponerle ruedas de bicicleta a un camión de mudanzas; no funcionará.

• El problema de los "Expertos Selectivos" (MLA): Modelos como DeepSeek y Kimi tienen una forma especial de pensar (llamada MLA). En el sistema actual de AMD, estos modelos son muy caprichosos:

  • Necesitan que el camión cargue los paquetes uno por uno (bloque de tamaño 1), lo cual es lento.
  • No pueden usar un "trastero externo" (offloading de memoria) si se les llena el baúl.
  • La solución mágica (AITER): Para que estos modelos vayan rápido, necesitan un turbo especial llamado AITER. Sin este turbo, van a paso de tortuga. Pero ojo: si el modelo es demasiado grande (como Kimi), el turbo no le cabe y hay que apagarlo, o el motor explota.

• El problema de los "Gigantes Densos" (GQA): Modelos como Llama funcionan mejor con la configuración estándar. Pueden usar el trastero externo y van más rápido con la configuración normal.

📊 Los Resultados: ¿Quién gana la carrera?

1. La velocidad depende de lo que realmente usas:

   • Aunque Kimi es 10 veces más grande que DeepSeek, van a casi la misma velocidad. ¿Por qué? Porque en cada paso, Kimi solo usa una pequeña parte de su cerebro (32 mil millones de "neuronas activas"), igual que DeepSeek (37 mil millones).
   • La moraleja: No importa cuán grande sea el camión, importa cuánta carga mueves realmente en cada viaje.

2. El cuello de botella no es el motor, es la carretera:

   • Descubrieron que, sin importar qué modelo usen, todos se frenan al mismo tiempo cuando hay demasiados clientes (alrededor de 500 personas pidiendo cosas a la vez).
   • La analogía: El motor del camión (la potencia de cálculo) es tan potente que nunca se cansa. El problema es que la autopista de entrada (ancho de banda de memoria) se satura. Es como tener un grifo de agua gigante, pero solo una manguera fina para sacarlo. Llegan 500 personas, la manguera se llena y nadie puede beber más rápido, aunque el grifo tenga agua de sobra.

3. El Rey de la Velocidad (Qwen3-VL):

   • El modelo que vio imágenes (Qwen) fue el más rápido de todos (casi 48,000 paquetes por segundo). ¿Por qué? Porque su arquitectura es muy eficiente y aprovecha bien la "autopista" de AMD.

💡 Lecciones para el Mundo Real (Consejos Prácticos)

Si quieres usar estos chips de AMD para tu negocio de IA, aquí tienes las reglas de oro que aprendieron:

1. Conoce a tu pasajero: Antes de configurar el camión, averigua si tu modelo es "Dense" (Gigante duro) o "MoE" (Experto selectivo). Si usas la configuración equivocada, tu modelo irá lento o fallará.
2. El Turbo (AITER) es vital, pero con cuidado: Para los modelos "Expertos", el turbo es obligatorio para ir rápido. Pero para el modelo gigante Kimi, el turbo no le sirve de nada y hay que quitarlo.
3. No te obsesiones con el tamaño total: Un modelo de 1 billón de parámetros no es necesariamente más lento que uno de 100 mil millones si el primero es "experto selectivo". Lo que importa es cuánta energía consume realmente en cada paso.
4. Hay un límite de pasajeros: Si tienes 8 tarjetas gráficas, no intentes atender a 1,000 personas a la vez esperando que sea más rápido. Llegarás a un punto (alrededor de 500) donde añadir más gente solo hará que todos esperen más tiempo, pero no procesarán más rápido. Es mejor gestionar la cola.

En resumen

Este estudio nos dice que AMD MI325X es un camión increíblemente potente capaz de mover los cerebros de IA más grandes del mundo (¡incluso los de 1 billón de parámetros!). Pero, para que funcione, no puedes tratar a todos los cerebros igual. Necesitas un mecánico experto que sepa qué configuración ponerle a cada uno, porque lo que funciona para un elefante puede ser un desastre para un equipo de cirujanos.

¡Y lo mejor de todo es que, con la configuración correcta, ¡funciona perfectamente y no falla ni una sola vez!

Resumen técnico

Aquí tienes un resumen técnico detallado del informe técnico presentado, traducido y adaptado al español:

Resumen Técnico: Optimización de Inferencia de LLMs Consciente de la Arquitectura en GPUs AMD Instinct

1. Problema y Contexto

La inferencia de Modelos de Lenguaje Grande (LLM) a escala fronteriza (cientos de miles de millones a billones de parámetros) requiere una co-optimización cuidadosa entre la arquitectura del modelo, las capacidades del hardware y la configuración del sistema de servicio. Sin embargo, existen estudios de referencia sistemáticos escasos sobre aceleradores AMD. Además, la diversificación rápida de las arquitecturas de modelos (Dense, MoE, MLA, GQA) impone demandas fundamentalmente diferentes en la jerarquía de memoria y la optimización de kernels. Una configuración de despliegue que funciona óptimamente para un modelo denso con Atención de Consulta Agrupada (GQA) puede ser subóptima o incluso errónea para un modelo de Expertos Mezclados (MoE) con Atención Latente Multicabezal (MLA).

El objetivo de este trabajo es llenar esta brecha evaluando sistemáticamente la inferencia de LLMs de producción en las nuevas GPUs AMD Instinct MI325X (arquitectura CDNA 3), cubriendo modelos de 235 mil millones a 1 billón de parámetros.

2. Metodología

El estudio se realizó en un clúster de 8 GPUs MI325X con un total de 2 TB de memoria HBM3e (256 GB por GPU, 6.0 TB/s de ancho de banda). Se utilizó el framework de servicio vLLM v0.14.1 con el stack de software ROCm 6.4.2.

Modelos Evaluados (4 modelos, 3 familias arquitectónicas):

1. DeepSeek V3.2: 685B parámetros totales, 37B activos. Arquitectura: MoE + MLA.
2. Llama-3.1-405B: 405B parámetros totales (Dense). Arquitectura: Dense + GQA.
3. Qwen3-VL-235B: 235B parámetros totales, 22B activos. Arquitectura: MoE + GQA (Multimodal).
4. Kimi-K2.5: 1T parámetros totales, 32B activos. Arquitectura: MoE + MLA.

Diseño de Experimentos:

• Carga de trabajo: Desde solicitudes individuales hasta 1,000 usuarios concurrentes.
• Métricas: Throughput (tokens/segundo), latencia (p99), tasa de éxito (HTTP 200) y variabilidad de medición.
• Pruebas: Escalado de concurrencia, generación de salida larga, prefill de contexto largo y cargas de trabajo de visión.
• Reproducibilidad: Se realizaron múltiples ejecuciones independientes (n=5) para calcular intervalos de confianza y coeficientes de variación.

3. Contribuciones Clave

1. Estudio de referencia transversal en MI325X: Primera evaluación académica de modelos fronterizos en hardware MI325X, caracterizando restricciones específicas de arquitectura (tamaño de bloque, compatibilidad con AITER, offloading de KV).
2. Optimización consciente de la arquitectura: Demostración de que no existe una configuración "única para todos".
   • Los modelos MLA requieren block-size 1 y son incompatibles con el offloading de KV cache en el stack ROCm actual.
   • Los modelos GQA se benefician del offloading y tamaños de bloque estándar.
   • AITER (AMD AI Tensor Engine): Es obligatorio para un throughput competitivo en modelos MLA. Para modelos GQA, ofrece beneficios modestos (3-5%) pero aumenta significativamente la variabilidad de las mediciones.
3. Despliegue de modelo de 1 billón de parámetros: Primer benchmark publicado de inferencia de un modelo de 1T (Kimi-K2.5) en MI325X (CDNA 3), logrando 100% de fiabilidad.
4. Validación empírica de parámetros activos: Confirmación de que el número de parámetros activos por token (no el total) es el principal impulsor del throughput en modelos MoE a gran escala.
5. Saturación dependiente de la carga: Identificación de un punto de saturación común de throughput (~500 solicitudes concurrentes para secuencias cortas) que sugiere un cuello de botella en el ancho de banda de memoria, independiente de la arquitectura del modelo.

4. Resultados Principales

Rendimiento y Throughput

• Carga de Texto:
  • Llama-3.1-405B (Dense+GQA): 15,944 tok/s.
  • DeepSeek V3.2 (MoE+MLA): 15,343 tok/s.
  • Hallazgo: A pesar de que DeepSeek tiene solo el 9% de los parámetros activos de Llama (37B vs 405B), alcanzan un throughput casi idéntico. Esto indica que las restricciones de MLA en ROCm (tamaño de bloque 1, sin offloading) compensan la ventaja de eficiencia de MoE en este escenario específico.
• Carga de Visión:
  • Qwen3-VL-235B (MoE+GQA): 47,873 tok/s (incluyendo tokens de imagen).
  • Kimi-K2.5 (MoE+MLA): 7,327 tok/s.
  • Hallazgo: Qwen3-VL supera a Kimi-K2.5 en un 6.5x. Esto se debe a la menor cantidad de parámetros activos (22B vs 32B), el uso de GQA (que permite offloading y tamaños de bloque estándar), la activación de AITER y el uso de TP=8 (vs TP=4 forzado en Kimi).

Limitaciones y Restricciones de Configuración

• AITER: Es crítico para modelos MLA. Sin AITER, el rendimiento cae drásticamente (fallback a Triton). Sin embargo, para Kimi-K2.5, AITER debe desactivarse completamente debido a incompatibilidades de hardware (requisito MXFP4 solo disponible en CDNA 4/MI355X) y restricciones de número de cabezas de atención (64 cabezas no son compatibles con los soportes de 16/128 de AITER).
• Tensor Parallelism (TP):
  • La mayoría de modelos usó TP=8.
  • Kimi-K2.5 requirió TP=4 para cumplir con las restricciones de cabezas de atención, utilizando solo la mitad del ancho de banda del clúster.
• Offloading de KV Cache: Funciona en modelos GQA, pero no está soportado en modelos MLA en la versión actual de vLLM/ROCm.

Saturación y Cuello de Botella

• Todos los modelos alcanzaron su punto de saturación de throughput a aproximadamente 500 solicitudes concurrentes (para cargas de trabajo de secuencias cortas).
• Más allá de este punto, aumentar la concurrencia solo incrementa la latencia, no el throughput.
• La baja utilización de FLOPs (<15% incluso en el modelo más denso) confirma que la inferencia de LLMs en MI325X está limitada por el ancho de banda de memoria, no por la capacidad de cómputo.

Fiabilidad

• Se procesaron 18.9 millones de tokens en 17,406 solicitudes.
• Tasa de éxito del 100% (HTTP 200) en todos los niveles de concurrencia, incluyendo 1,000 usuarios simultáneos. El sistema gestionó la sobrecarga mediante colas en lugar de rechazar solicitudes.

5. Significado e Implicaciones

1. Necesidad de Configuración Dinámica: Los equipos de despliegue no pueden aplicar una configuración estándar de vLLM a todos los modelos. Se requiere lógica de detección de arquitectura para ajustar automáticamente el tamaño de bloque, la configuración de AITER, el offloading de KV y el grado de paralelismo tensorial.
2. Viabilidad de AMD MI325X: La plataforma demuestra ser una solución viable para modelos fronterizos, incluyendo modelos de 1 billón de parámetros, gracias a su gran capacidad de memoria (256 GB HBM3e) y alto ancho de banda (6.0 TB/s), que elimina la necesidad de offloading a CPU en muchos casos.
3. Eficiencia de MoE: La arquitectura MoE sigue siendo eficiente en términos de parámetros activos, pero su ventaja de throughput en ROCm actual puede verse mitigada por la falta de soporte de kernels optimizados (AITER) para ciertas configuraciones de atención (MLA) o restricciones de hardware (MXFP4).
4. Recomendaciones de Producción:
   • Desactivar AITER_ENABLE_VSKIP para evitar errores de memoria en modelos DeepSeek.
   • Desactivar AITER completamente para Kimi-K2.5 en MI325X.
   • Planificar la concurrencia alrededor del punto de saturación (~500 para secuencias cortas) para maximizar el throughput sin degradar la latencia innecesariamente.

En conclusión, este estudio establece que el rendimiento óptimo en hardware AMD para LLMs de próxima generación depende críticamente de adaptar la configuración del sistema a las sutilezas específicas de la arquitectura del modelo, más que simplemente escalar los recursos de hardware.