El programa JumpStart de Supermicro se ha consolidado como una de las herramientas más útiles en el conjunto de herramientas de evaluación previa a la compra para infraestructura de IA. En lugar de una demostración guionizada en un entorno compartido, JumpStart ofrece a los usuarios cualificados acceso gratuito, limitado en el tiempo y sin infraestructura física a servidores de producción reales a través de SSH, IPMI y VNC, lo que les permite ejecutar cargas de trabajo en hardware real. Cubrimos el programa en profundidad el pasado noviembre utilizando un Sistema X14 con una NVIDIA HGX B200y se llevó una idea clara de lo que una semana de acceso intensivo puede y no puede revelar. En esta ocasión, Supermicro brindó acceso a un sistema H14 8U con una historia de acelerador muy diferente.
Probamos el AS-8126GS-TNMR te, una plataforma 8U refrigerada por aire construida alrededor de dos procesadores AMD EPYC 9575F y ocho GPU AMD Instinct MI350X. La MI350X es el acelerador de centro de datos insignia actual de AMD, construido sobre la arquitectura CDNA de cuarta generación en el nodo de 3 nm de TSMC y cuenta con 288 GB de HBM3e por GPU. A través de ocho GPU interconectadas mediante AMD Infinity Fabric, el servidor ofrece 2.3 TB de memoria GPU total en un solo nodo, con un ancho de banda agregado de 1,024 GB/s. El sistema completo utiliza seis fuentes de alimentación de nivel Titanium de 5,250 W en una configuración redundante 3+3, y Supermicro ha provisto una red dedicada de 400 Gbps por GPU para implementaciones de escalabilidad horizontal.
La posición de AMD en el mercado de GPU para centros de datos ha cambiado significativamente en los últimos dos años, y la generación MI350X representa un desafío competitivo más serio para NVIDIA que cualquier producto Instinct anterior. ROCm 7, lanzado en septiembre de 2025 y ahora en la versión 7.2, incorporó soporte nativo para MI350X junto con un rendimiento de inferencia notablemente mejorado, actualizaciones de la API HIP que cierran la brecha de compatibilidad con CUDA y un soporte de marcos de trabajo ampliado, incluyendo PyTorch, JAX, TensorFlow, ONNX Runtime, vLLM y SGLang.
El proyecto vLLM añadió una canalización de CI dedicada para AMD ROCm a finales de diciembre de 2025, convirtiendo el hardware de AMD en una plataforma de primera clase en esa pila de inferencia en lugar de una simple adaptación. La adopción del ecosistema también es difícil de ignorar: AMD y Meta anunciaron Un acuerdo plurianual y multigeneracional para el despliegue de GPU de 6 gigavatios en febrero de 2026, que se basa en los despliegues de producción existentes de Meta con hardware de las series MI300 y MI350. Este nivel de compromiso por parte de uno de los mayores operadores de infraestructura de IA del mundo no es una simple estrategia de marketing.
Para las organizaciones que actualmente evalúan la infraestructura de aceleración de IA, el tiempo de entrega del hardware de NVIDIA sigue siendo una preocupación. La pregunta es si AMD es una alternativa viable en lugar de una opción de último recurso. Tras una semana de pruebas con ROCm 7.2.0 y la versión actual de vLLM, la respuesta es significativamente diferente a la de hace 18 meses.
Nuestras pruebas abarcaron una selección de modelos populares; los 2.3 TB de HBM3e en un solo nodo permitieron la inferencia en un único servidor para modelos con muchos parámetros, incluidos Kimi K2.5 y MiniMax M2.5 de Moonshot.
AMD Instinct MI350X: Arquitectura y mejoras generacionales
El MI350X representa el salto generacional más ambicioso en términos de arquitectura que AMD ha dado hasta la fecha en la línea de productos Instinct. Comprender las decisiones de ingeniería que lo respaldan proporciona un contexto importante para interpretar los resultados de rendimiento posteriores.
Arquitectura CDNA 4 y transición de nodos de proceso
El cambio fundamental de la serie MI300 a la serie MI350 se centra en la adopción del nodo de proceso N3P de TSMC para los chiplets de computación aceleradora (XCD), dejando atrás la fabricación de 5 nm utilizada en la generación anterior. El número total de transistores alcanza aproximadamente 185 mil millones, un aumento de alrededor del 21 % con respecto a la generación MI300, logrado sin un aumento correspondiente en el consumo de energía.
El MI350X conserva la estrategia de empaquetado multichiplet de eficacia probada de AMD. En su núcleo, el paquete de GPU cuenta con ocho chiplets de cómputo acelerador (XCD) como motores de cálculo principales. Cada XCD alberga cuatro motores de sombreado, cada uno con ocho unidades de cómputo CDNA 4 activas, lo que da como resultado 32 CU por XCD y un total de 256 CU para el acelerador completo.
La capa de chips de E/S también se consolidó, pasando de cuatro a dos módulos en el diseño del paquete CDNA 4. Esta reorganización permitió a AMD duplicar el ancho del bus Infinity Fabric, mejorando el ancho de banda biseccional y reduciendo la frecuencia y el voltaje de funcionamiento del bus para disminuir el consumo de energía.
Unidades de cómputo rediseñadas y soporte de precisión ampliado
Gracias a las capacidades de cálculo matricial de la unidad de cómputo CDNA 4, se produce una mejora sustancial: las unidades de cómputo MI350 ofrecen un aumento del doble en el rendimiento por unidad de cómputo para operaciones de 16 bits (BF16, FP16) y de 8 bits (FP8, INT8) en comparación con sus homólogas MI300.
Más allá de las mejoras en el rendimiento bruto, CDNA 4 introduce soporte de hardware para tipos de datos de menor precisión ausentes en la serie MI300, específicamente FP6 y FP4, junto con el soporte FP8 existente heredado de la generación anterior.
Además de estos formatos estándar, el MI350X incorpora soporte de hardware nativo para las variantes de microescalado OCP: MXFP4, MXFP6 y MXFP8. Los formatos de microescalado están diseñados para ofrecer las ventajas de rendimiento de la computación de menor precisión, manteniendo una calidad de salida más cercana a la de las bases de mayor precisión que la que suele permitir la cuantización estándar. Este no es un desarrollo específico de AMD. El formato NVFP4 de NVIDIA funciona con los mismos principios de microescalado y ha tenido una amplia adopción en implementaciones de modelos de vanguardia, siendo la familia GPT-OSS de OpenAI uno de los ejemplos más destacados basados en estos formatos. El soporte nativo MXFP4 del MI350X le permite dar servicio a estas y otras familias de modelos cuantizados similares sin recurrir a la emulación por software ni a la promoción de precisión.
El MI350X ofrece 9.2 PFLOPs en MXFP4 y MXFP6, en comparación con 4.6 PFLOPs en OCP-FP8, con FP16 a 2.3 PFLOPs y una frecuencia máxima del motor de 2,200 MHz. Para implementaciones optimizadas para inferencia donde la cuantización por microescalado es viable, el margen de cómputo se duplica efectivamente en relación con las cargas de trabajo FP8. También se ha añadido una nueva ALU vectorial a la unidad de cómputo CDNA 4, que admite operaciones de 2 bits y es capaz de acumular resultados BF16 en FP32, lo que proporciona flexibilidad adicional para cargas de trabajo vectoriales de baja precisión fuera de la ruta de cómputo de matriz principal.
Subsistema de memoria: HBM3e, caché infinita y eficiencia de ancho de banda.
La serie MI350 cuenta con un subsistema de memoria sustancialmente mejorado con ocho pilas de memoria HBM3e, que proporcionan una capacidad total de 288 GB por GPU. Cada pila de 36 GB, compuesta por 12 dispositivos de 24 Gbit/s de alto, opera a la velocidad máxima de pines HBM3e de 8 Gbps por pin. La arquitectura conserva la Infinity Cache de AMD, una caché del lado de la memoria ubicada entre la HBM y las cachés Infinity Fabric/L2. Consta de 128 canales, cada uno respaldado por 2 MB de caché, para un total de 256 MB por GPU. AMD ha ampliado los buses de red en el chip dentro de los IOD y los opera a un voltaje reducido, lo que permite un ancho de banda de memoria por vatio aproximadamente 1.3 veces mayor en comparación con la serie MI300.
El aumento de la capacidad de memoria, de 192 GB a 288 GB en la MI300X, amplía la ventaja de AMD en cuanto a la capacidad de memoria por GPU, con implicaciones directas para la inferencia de modelos de gran tamaño. Cada GPU MI350X puede alojar de forma independiente modelos con más de 500 mil millones de parámetros. En un servidor de ocho GPU, los 2.3 TB de HBM3e en conjunto eliminan los requisitos de distribución multinodo que complican las implementaciones con billones de parámetros, como demuestran los resultados de Kimi K2.5 y MiniMax M2.5 en este análisis.
Arquitectura de particionamiento y despliegue flexible
La serie MI350 admite la partición flexible de GPU por socket, con la memoria dividida en dos clústeres separados. Esta flexibilidad también se aplica a los XCD, donde el clúster cuádruple XCD se puede dividir en bloques dobles o simples, lo que permite que el chip admita configuraciones como 8 instancias de modelos 70B en CPX+NPS2. Para las organizaciones que ejecutan cargas de trabajo de inferencia heterogéneas en infraestructura compartida, esta capacidad de partición reduce la necesidad de hardware dedicado por nivel de modelo y mejora la rentabilidad en entornos de implementación mixtos.
La serie MI350 también mantiene la compatibilidad directa con la infraestructura UBB (Universal Base Board) utilizada en los sistemas de la serie MI300. El chasis del servidor, el suministro de energía y la infraestructura de refrigeración existentes se conservan sin modificaciones, lo que reduce las dificultades de actualización para las organizaciones con implementaciones activas de MI300.
MI355X: El hermano con refrigeración líquida
La serie MI350 se comercializa en dos variantes basadas en el mismo chip y optimizadas para diferentes rangos de temperatura de funcionamiento. El MI350X que se prueba aquí es la variante refrigerada por aire, mientras que el MI355X es su equivalente refrigerado por líquido, diseñado para implementaciones de mayor densidad donde se dispone de infraestructura de refrigeración líquida directa.
Si bien ambas variantes se basan en el mismo hardware fundamental, el mayor consumo de energía del MI355X permite frecuencias de reloj sostenidas más altas, lo que se traduce en una ventaja de rendimiento aproximada del 20 % en cargas de trabajo reales de extremo a extremo en comparación con el MI350X. El MI355X tiene un límite de TBP de 1,400 W frente a los 1,000 W del MI350X, con una velocidad de reloj máxima de 2.4 GHz en comparación con los 2.2 GHz de la variante refrigerada por aire.
En términos generacionales, la plataforma MI355X ofrece una mejora teórica de rendimiento máximo de hasta 4 veces con respecto a la MI300X, con ganancias de inferencia reales de aproximadamente 4.2 veces en cargas de trabajo de agentes y chatbots, y alrededor de 3 veces en escenarios de generación de contenido. Para las organizaciones que evalúan implementaciones de MI350X, la diferencia de rendimiento del 20 % entre las dos variantes representa un límite claro. Las instalaciones con infraestructura DLC deberían evaluar la MI355X para determinar si la inversión térmica proporciona un aumento de rendimiento suficiente para su perfil de carga de trabajo específico antes de comprometerse con configuraciones refrigeradas por aire a gran escala.
Acceso al AMD Instinct MI350X a través del programa Supermicro JumpStart.
Para empezar a usar JumpStart, es necesario registrarse en el portal de Supermicro, donde los usuarios cualificados pueden consultar los sistemas disponibles y programar una reserva. Una vez aprobada la solicitud, el portal proporciona credenciales SSH, acceso a IPMI y una consola remota web durante el periodo de reserva. El sistema llega con Ubuntu preinstalado y listo para usar. No hay demoras en el aprovisionamiento ni se requiere asistencia técnica para empezar. Nuestra reserva se extendió del 23 al 27 de marzo de 2026, lo que nos permitió disponer de la plataforma durante una semana completa, al igual que en nuestra experiencia anterior con JumpStart en el HGX B200.
La captura de pantalla que aparece a continuación muestra la salida de nuestra terminal de jumpstart para el sistema H14, donde la herramienta AMD-SMI muestra las ocho GPU AMD Instinct MI350X y sus versiones de software en ejecución.
Resultados de las pruebas de rendimiento del AMD Instinct MI350X
Configuración del Sistema
- Chasis: Supermicro H14
- UPC: Doble procesador AMD EPYC 9575F
- Memoria: DDR3 de 5 TB
- GPU: ocho AMD Instinct MI350X
- Almacenamiento: 2x SSD M.2 NVMe PCIe 4.0 de 3.8 TB y 1 x M.2 NVMe de 1.92 TB
Resumen de Resultados
| Modelo | Precisión | Igual (256/256) | Relleno previo intensivo (8k/1k) | Decodificación intensiva (1k/8k) |
|---|---|---|---|---|
| GPT-OSS 20B | NVFP4 | 62,247 | 123,714 | 32,468 |
| GPT-OSS 120B | NVFP4 | 33,538 | 84,018 | 20,602 |
| Llama 3.1 8B Instrucción | BF16 | 51,467 | 77,658* | 19,326 |
| Mistral Pequeño 3.1 24B | FP8 | 40,742 | 56,093 | 14,557 |
| Mistral Pequeño 3.1 24B | BF16 | 30,530 | 53,740 | 13,559 |
| Codificador Qwen3 30B A3B | BF16 | 34,980 | 51,550 | 11,782 |
| Codificador Qwen3 30B A3B | FP8 | 25,928 | 47,179 | 11,014 |
| MiniMax M2.5 | FP8 a escala de bloques | 14,391 | 23,689 | 6,068 |
| Kimi K2.5 | INT4 QAT + BF16 | 6,527 | 11,256 | 2,513 |
| Todos los valores en tok/s, rendimiento máximo en BS=256. *Llama 3.1 8B prefill-heavy alcanzó su máximo en BS=128 (77,658 tok/s); BS=256 fue de 76,893 tok/s. | ||||
Servidor de código Claude – MiniMax M2.5
Más allá de las pruebas de inferencia LLM tradicionales, queríamos evaluar el rendimiento de este hardware en un flujo de trabajo de codificación con agentes, específicamente al servir múltiples sesiones concurrentes de Claude Code con un modelo alojado localmente. Este caso de uso se relaciona directamente con la productividad del equipo de desarrollo: ¿cuántos ingenieros pueden usar simultáneamente un asistente de codificación de IA alojado en un solo nodo antes de que la experiencia se degrade?
Para probar esto, creamos un entorno de evaluación comparativa que genera un conjunto de datos de problemas de codificación de dificultad moderada (tareas como implementar una caché LRU, crear una aplicación de lista de tareas de línea de comandos, escribir un convertidor de Markdown y construir una API REST) y ejecuta cada sesión de Claude Code en su propio contenedor Docker contra el servidor vLLM local. Un proxy transparente se sitúa entre las sesiones y el punto final de inferencia, capturando métricas por solicitud para cada instancia de Claude Code. El modelo utilizado fue MiniMax M2.5, servido a través de vLLM en las ocho GPU MI350X. Si bien no es el modelo de codificación mejor clasificado en las tablas de clasificación públicas, M2.5 es un modelo capaz que muchos usuarios ejecutan localmente, incluidos muchos de nuestros amigos desarrolladores.
Como punto de referencia, utilizamos el rendimiento promedio de salida de Claude Opus 4.6 de Anthropic a través de OpenRouter.ai, uno de los servicios de enrutamiento más populares para el acceso a API en entornos de producción. Este rendimiento de referencia se sitúa en aproximadamente 37 tokens por segundo por solicitud de API.
Medimos dos métricas clave: el promedio de tokens de salida por segundo por sesión de Claude Code (lo que experimenta cada desarrollador) y el total de tokens de salida por segundo en todas las sesiones (el trabajo total que produce el servidor).
Observando los resultados, una sola sesión concurrente ofrece 38.8 tok/s por usuario y 38 tok/s agregados, ligeramente por encima de la línea base de la nube de OpenRouter. Con dos sesiones, el sistema aumenta a 39.5 tok/s por usuario a medida que el procesamiento por lotes de vLLM comienza a amortizar la sobrecarga, con un rendimiento agregado que sube a 63 tok/s. Cuatro sesiones concurrentes se mantienen a 37.3 tok/s por usuario, igualando la línea base de la nube mientras se atiende a cuatro desarrolladores simultáneamente, con un rendimiento agregado que alcanza los 128 tok/s. A partir de ocho sesiones, el rendimiento por instancia comienza a disminuir: 34.6 tok/s por usuario en ocho sesiones, 31.4 tok/s en dieciséis con un agregado de 190 tok/s, y se estabiliza alrededor de 23 tok/s por usuario en 32 y 64 sesiones, mientras que el rendimiento agregado sube a 578 tok/s y 986 tok/s, respectivamente. Este es el clásico dilema entre rendimiento y interactividad en el procesamiento por lotes: el sistema puede lograr un rendimiento total significativamente mayor al agrupar más solicitudes, pero cada usuario experimenta tiempos de respuesta más lentos. Incluso con 64 usuarios concurrentes, cada desarrollador sigue disfrutando de una experiencia interactiva utilizable, aunque notablemente más lenta que la configuración base en la nube.
Para las organizaciones que sopesan el coste de docenas de suscripciones simultáneas a API comerciales frente a una infraestructura autogestionada, la disyuntiva es clara: un único nodo MI350X puede dar servicio a un equipo de desarrollo de entre 16 y 32 ingenieros, manteniendo velocidades de respuesta por usuario entre el 60 % y el 85 % de la base de la nube, al tiempo que ofrece una producción agregada de entre 600 y 1,000 tokens/s, con las ventajas adicionales de la localización de datos, la ausencia de cargos por API por token y el control total sobre la selección del modelo.
Servicio en línea de vLLM – Rendimiento de inferencia de LLM
vLLM es uno de los motores de inferencia y servicio de alto rendimiento más populares para LLM. La prueba de rendimiento en línea de vLLM evalúa el desempeño real de este motor de inferencia bajo solicitudes concurrentes. Simula cargas de trabajo de producción enviando solicitudes a un servidor vLLM en ejecución, con parámetros configurables como la tasa de solicitudes, la longitud de entrada/salida y el número de clientes concurrentes. La prueba mide métricas clave, incluyendo el rendimiento (tokens por segundo), el tiempo hasta el primer token y el tiempo por token de salida (TPOT), lo que ayuda a los usuarios a comprender el desempeño de vLLM bajo diferentes condiciones de carga.
Probamos el rendimiento de la inferencia en un conjunto integral de modelos que abarcan varias arquitecturas, escalas de parámetros y estrategias de cuantificación para evaluar el rendimiento en diferentes perfiles de concurrencia.
GPT-OSS 120B y 20B
La familia de modelos GPT-OSS se probó en configuraciones de 120 bits y 20 bits en el Supermicro H14.
GPT-OSS 120B
El modelo 120B bajo una carga de trabajo igual (256/256) entrega 313.42 tok/s en BS=1, alcanza 11,261.72 tok/s en BS=64 y llega a un máximo de 33,538.23 tok/s en BS=256. El prellenado pesado (8k/1k) comienza en 1,724.84 tok/s, sube a 36,156.80 tok/s en BS=32 y 79,247.76 tok/s en BS=128, llegando a un máximo de 84,018.79 tok/s en BS=256. La decodificación intensiva (1k/8k) aumenta de 288.90 tok/s en BS=1 a 20,602.52 tok/s en BS=256, y la latencia se mantiene bien controlada en niveles de concurrencia más bajos.
GPT-OSS 20B
El modelo 20B ofrece 485.17 tok/s en BS=1 bajo la misma carga de trabajo, alcanzando 17,986.36 tok/s en BS=64 y un pico de 62,247.52 tok/s en BS=256. El prefill-heavy comienza en 3,120.72 tok/s, sube a 48,132.52 tok/s en BS=32 y 83,968.71 tok/s en BS=64, alcanzando un pico de 123,714.50 tok/s en BS=256, el mayor rendimiento absoluto de prefill registrado en ambos tamaños de modelo. La decodificación intensiva aumenta de 378.20 tok/s en BS=1 a 32,468.67 tok/s en BS=256, ofreciendo aproximadamente 1.6 veces el rendimiento de decodificación del 120B en la concurrencia máxima, al tiempo que mantiene características de latencia más ajustadas en todo momento.
Instrucciones para Qwen3 Coder 30B A3B e instrucciones para FP8
El programa Qwen3-Coder-30B-A3B-Instruct del Supermicro H14 se probó con precisiones estándar (BF16) y FP8.
Qwen3-Coder-30B-A3B-Instruct (BF16)
En BF16, la carga de trabajo igual (256/256) ofrece 240.53 tok/s en BS=1, alcanzando 13,312.70 tok/s en BS=64 y 21,333.79 tok/s en BS=128, con un rendimiento máximo de 34,980.97 tok/s en BS=256. El prellenado pesado (8k/1k) comienza en 1,276.76 tok/s, sube a 25,069.32 tok/s en BS=32 y 50,198.94 tok/s en BS=128, alcanzando un máximo de 51,550.66 tok/s en BS=256. La decodificación intensiva (1k/8k) aumenta de forma constante desde aproximadamente 188 tok/s en BS=1 hasta 11,782 tok/s en BS=256, manteniendo el perfil de latencia más ajustado de los tres escenarios.
Qwen3-Coder-30B-A3B-Instruct (FP8)
La variante FP8 ofrece 188.92 tok/s en BS=1 bajo la misma carga de trabajo, alcanzando 10,866.27 tok/s en BS=64 y 17,617.60 tok/s en BS=128, con un pico de 25,928.77 tok/s en BS=256, ligeramente por debajo de los resultados de BF16 en todo el rango. El prefill-heavy comienza en 860.07 tok/s, sube a 20,513.77 tok/s en BS=32 y 44,205.46 tok/s en BS=128, con un pico de 47,179.15 tok/s en BS=256. La decodificación intensiva aumenta de 133.79 tok/s en BS=1 a 11,014.95 tok/s en BS=256, escalando de manera consistente y manteniéndose cerca de BF16 en todo momento.
Mistral Pequeño 3.1 24B Instrucción 2503
La instrucción Mistral-Small-3.1-24B-Instruct-2503 en el H14 se probó con precisión estándar y FP8-dinámica, mostrando una escalabilidad consistente en los tres perfiles de carga de trabajo.
Mistral-Pequeño-3.1-24B-Instrucciones-2503 (BF16)
Con precisión BF16, la carga de trabajo igual (256/256) ofrece 236.15 tok/s en BS=1, alcanzando 15,494.56 tok/s en BS=64, 24,216.52 tok/s en BS=128 y un pico de 30,530.54 tok/s en BS=256. El prellenado pesado (8k/1k) comienza en 1,429.41 tok/s, sube a 29,631.68 tok/s en BS=32 y 54,871.74 tok/s en BS=128, alcanzando un pico de 53,740.04 tok/s en BS=256. La decodificación intensiva (1k/8k) aumenta de 242.66 tok/s en BS=1 a 13,559.19 tok/s en BS=256, escalando de manera constante en todo el rango.
Mistral-Small-3.1-24B-Instruct-2503 (FP8-dinámico)
La variante FP8-dynamic ofrece 184.25 tok/s en BS=1 bajo la misma carga de trabajo, alcanzando 16,113.95 tok/s en BS=64 y 26,409.01 tok/s en BS=128, con un pico de 40,742.04 tok/s en BS=256. La variante Prefill-heavy comienza en 1,210.06 tok/s, sube a 28,773.52 tok/s en BS=32 y 57,765.02 tok/s en BS=128, con un pico de 56,093.09 tok/s en BS=256, superando el resultado de precisión estándar desde BS=64 en adelante. La decodificación intensiva aumenta de 183.94 tok/s en BS=1 a 14,557.94 tok/s en BS=256, manteniéndose cerca en el rango medio antes de adelantarse ligeramente en BS=128 y BS=256.
Llama 3.1 8B Instrucción
Para Llama-3.1-8B-Instruct, vimos que la carga de trabajo igual (256/256) entrega 373.26 tok/s en BS=1, alcanzando 19,363.33 tok/s en BS=64, 34,155.70 tok/s en BS=128, y un pico de 51,467.30 tok/s en BS=256. Prefill-heavy (8k/1k) comienza en 1,959.04 tok/s, sube a 37,227.63 tok/s en BS=32 y 60,062.40 tok/s en BS=64, alcanzando un pico de 77,658.50 tok/s en BS=128 antes de disminuir ligeramente a 76,893.77 tok/s en BS=256. El modelo Decode-heavy (1k/8k) comienza en 326.48 tok/s, alcanzando 17,877.52 tok/s en BS=128 y 19,326.35 tok/s en BS=256, manteniendo una latencia por token más baja en el rango de concurrencia que cualquiera de los modelos más grandes probados.
MiniMax M2.5
El MiniMax-M2.5 en el H14 completa la gama de modelos, situándose entre el Kimi K2.5 y los modelos de tamaño medio en términos de rendimiento, con características que reflejan su arquitectura de mezcla de expertos. La misma carga de trabajo (256/256) ofrece 79.31 tok/s con BS=1, alcanzando 5,029.76 tok/s con BS=64, 7,801.10 tok/s con BS=128 y 14,391.98 tok/s con BS=256. El escenario con precarga intensiva (8k/1k) muestra la mayor escalabilidad de los tres, comenzando en 424.41 tok/s y subiendo a 10,376.75 tok/s en BS=32 y 20,658.57 tok/s en BS=128, alcanzando un máximo de 23,689.18 tok/s en BS=256. El escenario con decodificación intensiva (1k/8k) escala de manera constante a 4,257.68 tok/s en BS=128 y 6,068.70 tok/s en BS=256, ofreciendo el crecimiento de latencia más consistente en todo el rango de concurrencia.
Kimi K2.5
El modelo Kimi K2.5 de 1 billón de parámetros en el H14 es el modelo más grande e inteligente probado en esta revisión, y su rendimiento refleja esa importancia.
La carga de trabajo igual (256/256) ofrece 72.06 tok/s en BS=1, alcanzando 2,693.07 tok/s en BS=64, 4,244.27 tok/s en BS=128 y un pico de 6,527.62 tok/s en BS=256. La carga de prellenado pesada (8k/1k) escala de forma más agresiva, comenzando en 185.29 tok/s y alcanzando 3,798.85 tok/s en BS=32 y 9,153.12 tok/s en BS=128, con un rendimiento máximo de 11,256.69 tok/s en BS=256. El aumento escalonado de BS=128 a BS=256 conlleva un coste de latencia significativo, lo que indica que el sistema se está acercando a sus límites de memoria y cómputo con la profundidad de lote completa para este tamaño de modelo. La decodificación intensiva (1k/8k) aumenta de 29.88 tok/s en BS=1 a 2,513.85 tok/s en BS=256, lo que proporciona la curva de escala más ajustada de los tres escenarios, al tiempo que demuestra ganancias de rendimiento consistentes en todo el rango.
Conclusión
El AMD Instinct MI350X ofrece un rendimiento de inferencia muy competitivo en todos los perfiles de carga de trabajo probados, y el Supermicro AS-8126GS-TNMR proporciona una plataforma bien diseñada para aprovecharlo al máximo. Con 288 GB de HBM3e por acelerador y ocho GPU interconectadas mediante Infinity Fabric, los 2.3 TB de memoria GPU agregada disponibles en un solo nodo son suficientes para ejecutar modelos con billones de parámetros, como Kimi K2.5 y MiniMax M2.5, sin necesidad de distribución en múltiples nodos ni soluciones alternativas de particionamiento de modelos. Esta capacidad simplifica considerablemente la arquitectura de implementación para la inferencia a gran escala.
Los modelos más pequeños también arrojaron resultados excelentes. Llama 3.1 8B superó los 77 000 tok/s bajo cargas de trabajo con gran cantidad de precarga, y las arquitecturas de gama media, como Mistral Small 3.1 24B y Qwen3 Coder 30B, mantuvieron un alto rendimiento con una latencia bien controlada en todo el rango de concurrencia. En general, los resultados indican una plataforma de hardware que escala de forma predecible bajo carga, en lugar de sufrir una caída drástica con lotes de mayor profundidad.
ROCm 7.2 aporta mejoras significativas al conjunto de software de inferencia de AMD, especialmente al combinarse con vLLM 0.18. Esta combinación ofrece una experiencia de servicio notablemente más estable y de mayor rendimiento que las generaciones anteriores de ROCm, con una compatibilidad de marco más amplia y menos problemas que caracterizaban las implementaciones anteriores de Instinct. También cabe destacar el impulso del ecosistema en torno al hardware de AMD: vLLM ahora mantiene una canalización de CI dedicada para AMD ROCm, y el compromiso de Meta con la implementación multigeneracional a escala de 6 gigavatios refuerza que la validación en producción va mucho más allá de los entornos de evaluación comparativa controlados.
La evaluación del servicio Claude Code aporta una perspectiva práctica a las cifras de rendimiento bruto. Un único nodo MI350X mantuvo velocidades de respuesta cercanas a las de la nube para hasta 16 sesiones de codificación concurrentes y se mantuvo interactivo con hasta 64 usuarios simultáneos, generando casi 1,000 tokens por segundo de salida agregada. Para las organizaciones que sopesan el coste de las suscripciones a API comerciales frente a la infraestructura autogestionada, la rentabilidad se simplifica con esta densidad, con ventajas adicionales en la localización de datos, la eliminación de costes por token y la selección de modelos sin restricciones.
El programa JumpStart de Supermicro sigue demostrando su valía en el proceso de evaluación de infraestructuras. El acceso directo al hardware de producción, sin necesidad de configuración adicional, nos permitió ejecutar cargas de trabajo reales en condiciones reales durante todo el periodo de prueba. Para los equipos que realizan evaluaciones de adquisición de aceleradores, este nivel de acceso práctico resulta mucho más informativo que las comparaciones de especificaciones técnicas o las demostraciones predefinidas de los proveedores.
Amazon