- Mientras la demanda de inferencia supera a la oferta y suben los costos de las GPU NVIDIA y de los tokens, AMD MI355X emerge como una alternativa de inferencia de bajo costo, con un precio promedio por GPU aproximadamente 2.75 veces menor que B300
- La serie AMD Instinct MI350 compite con Blackwell a nivel de silicio, pero la ventaja de software de NVIDIA y su soporte day-0 determinan la velocidad real de serving y la dificultad de adopción
- Wafer optimizó GLM-5.2 en MI355X y logró 2626 tok/s/node y 2.4 rps en una carga de trabajo de 20k tokens de entrada/1k de salida y 60% de tasa de acierto de caché, equivalente al 80% del rendimiento medido en B200
- En un solo stream registró 213 tok/s con 10k tokens de entrada/1.5k tokens de salida; aunque no encabeza el leaderboard, considera que tiene ventaja en costo por rendimiento
- Estos resultados se lograron sin kernels personalizados, mediante correcciones de bugs del framework, cuantización, speculative decode y ajuste de selección de kernels MoE, por lo que el desafío de AMD se parece cada vez más a un problema de soporte que de software en sí
Costos de inferencia de AMD y brecha de software con NVIDIA
- La demanda de inferencia crece rápidamente y supera a la oferta; a medida que modelos de frontera como Claude Fable, GLM-5.2 y Minimax M3 aparecen casi cada dos semanas, también aumenta la demanda de tokens
- La oferta de Blackwell no es suficiente, lo que empuja al alza tanto los precios de las GPU NVIDIA como los costos de los tokens
- AMD MI355X cuesta en promedio aproximadamente 2.75 veces menos por GPU que B300, y sus especificaciones de hardware son comparables
- La serie AMD Instinct MI350 compite con Blackwell a nivel de silicio, pero gracias al soporte day-0 y a su ecosistema de software, NVIDIA puede servir inferencia de los modelos más recientes con mayor rapidez y menos fricción
- En MI355X y el stack ROCm, muchas veces el rendimiento SOTA de los modelos de frontera más recientes no aparece por defecto, e incluso puede ser difícil encontrar una imagen ejecutable
- Sin soporte day-0, construir y optimizar los modelos más recientes requiere semanas de ingeniería y cómputo; mientras tanto aparecen modelos aún más nuevos, dejando a AMD en una dinámica constante de ponerse al día
Rendimiento de GLM-5.2 en MI355X
- Wafer considera que, a medida que los agentes mejoran en la optimización de kernels y modelos, la brecha práctica entre AMD y NVIDIA se está reduciendo
- Logró 2626 tok/s/node en una carga de trabajo de 20k de entrada/1k de salida y 60% de tasa de acierto de caché
- RPS sostenido: 2.4 rps
- El knee definido es TTFT menor o igual a 5 segundos
- Equivale al 80% del rendimiento medido en B200
- MI355X cuesta más de 2 veces menos
| RPS sostenido | tok/s/node agregado | TTFT p50 / p95 | Tasa de éxito |
|---|---|---|---|
| 0.5 | 449 | 0.59s / 0.60s | 100% |
| 1.0 | 974 | 0.60s / 0.81s | 100% |
| 1.5 | 1913 | 0.62s / 1.03s | 100% |
| 2.0 | 1944 | 0.62s / 1.05s | 100% |
| 2.25 | 2089 | 0.63s / 1.23s | 100% |
| 2.4 saturado | 2626 | 0.81s / 2.22s | 100% |
- Según el criterio de Artificial Analysis, logró 213 tok/s en GLM-5.2 de un solo stream con 10k tokens de entrada/1.5k tokens de salida
- Aunque esta cifra no está en la cima del leaderboard de Artificial Analysis, considera que tiene ventaja en costo por rendimiento
- La prueba se sirvió sobre capacidad AMD MI355X de TensorWave
Cuantización y elección del framework de inferencia
- El primer paso fue la cuantización y la elección del framework; Wafer cuantizó GLM-5.2 basado en bf16 a MXFP4 con AMD Quark
- En comparación con la cuantización FP8 oficial de z-ai, MXFP4 se evaluó como prácticamente sin pérdida en GPQA-Diamond, tau2 y GSM8K
| Evaluación | Referencia FP8 | MXFP4 | Δ |
|---|---|---|---|
| GSM8K, 200 preguntas, 5-shot, greedy | 0.965 ± 0.013 | 0.955 ± 0.014 | −0.010 |
| GPQA-Diamond, 198 preguntas × 2 seeds, temp 1.0 | 0.9217 ± 0.027 | 0.9026 ± 0.029 | −0.019 |
| tau2 macro | 0.819 | 0.834 | +0.015 |
- Los candidatos a framework de inferencia fueron vLLM, ATOM y sglang
- vLLM no pudo aprovechar los beneficios de los pesos MXFP4 porque la ruta MXFP4 + GlmMoeDsa no funcionaba
- ATOM degradaba la calidad de salida en contextos largos
- sglang tenía la menor fricción hasta el soporte nativo y mantenía salidas consistentes mientras aprovechaba la cuantización
Dos problemas que bloqueaban speculative decode
- Para mejorar el throughput, se intentó activar speculative decode en sglang, pero la imagen ROCm de sglang no lo soportaba por defecto
- Para que MTP funcionara correctamente, hacían falta dos correcciones
- El primer problema era que el shared expert del MTP head se guardaba en bf16, pero la búsqueda de cuantización de sglang intentaba construirlo como MXFP4 debido a una discrepancia en el prefix del módulo
- Quark nombra el shared expert bf16 como
model.layers.78.mlp.shared_experts.* - El prefix real de la capa MTP es
model.decoder.* - Por esta discrepancia, al cargar se intentaban leer pesos bf16 de ancho completo en slots de 4 bits de medio ancho, provocando un shape mismatch y fallando la inicialización
- Wafer copió una vez más la entrada de layer 78 al nombre decoder que sglang realmente usa, habilitó speculative decode y el throughput de un solo stream aumentó casi 3 veces
- Quark nombra el shared expert bf16 como
- El segundo problema era que quedaba bloqueado el speculative decode profundo, como la configuración 5/1/6 propuesta por z-ai
- El kernel de fused multi-step metadata requerido para draft depth 4 o superior escribía
#include <cuda_runtime.h>sin guard ROCm - Se corrigió con un único guard
#ifdef USE_ROCM
- El kernel de fused multi-step metadata requerido para draft depth 4 o superior escribía
- Una vez que speculative decode funcionó correctamente, al añadir optimizaciones de configuración como
--kv-cache-dtype fp8_e4m3y--enable-aiter-allreduce-fusion, se llegó a 213 tok/s de decodificación en un solo stream
Cuello de botella de throughput agregado y ajuste de MoE
- En la carga de trabajo definida, optimizar solo el decode no era suficiente; con 20k de entrada y 60% de caché, el principal cuello de botella era el prefill
- En la configuración TP8 ajustada para decode de un solo stream, MI355X ejecutó GLM-5.2-MXFP4 a 1461 tok/s/node
- Al cambiar a TP4×DP2, logró 1944 tok/s/node y 2.0 RPS en la misma carga de trabajo
- Sin embargo, el rendimiento de Blackwell medido por Wafer fue de 3192 tok/s/node a 3.0 RPS, y el rendimiento de prefill de MI355X era relativamente más lento
- Una razón importante fue que el MoE fp4 de GLM-5.2 en la imagen de sglang caía silenciosamente en un fallback heurístico lento de FlyDSL
- aiter solo ofrece configuraciones ajustadas para la ruta a8w8/fp8
- Wafer ajustó directamente la selección del kernel MoE para las shapes fp4 de GLM
- Las shapes objetivo son
model_dim 6144,moe_inter 2048,E=256,topk=8
- Con este ajuste, el throughput agregado llegó a 2626 tok/s/node y 2.4 RPS
Qué se necesita para lograr rendimiento SOTA en AMD
- El proceso para alcanzar el mejor costo por rendimiento en MI355X tuvo cierta fricción, pero se evaluó como no especialmente difícil
- A diferencia del trabajo con Qwen3.5 397B, esta vez no se escribieron kernels personalizados
- Este estudio no consideró rendimiento multinodo, pero los despliegues de un solo nodo siguen siendo muy usados en entornos reales
- Lograr rendimiento SOTA en AMD se está convirtiendo cada vez más en un problema de soporte más que de software en sí
- La conclusión es que el moat de CUDA se está debilitando en tiempo real
1 comentarios
Opiniones de Hacker News
Me gustaría que en comparaciones como esta también incluyeran rendimiento por watt como métrica. Quiero saber dónde queda AMD en costo frente al rendimiento real.
Al hablar con empresas que quieren construir centros de datos fuera de EE. UU., dicen que es difícil conseguir volúmenes suficientes de Nvidia.
Si AMD es competitiva en rendimiento por watt y su soporte de software es en general confiable, eso importa bastante fuera de EE. UU., donde la electricidad suele ser relativamente cara.
Si permite montar centros de datos pequeños a un precio razonable, parece que AMD podría convertirse en parte del stack en regiones donde el suministro de Nvidia es limitado.
Dicho eso, no sé bien cómo es en la práctica la adquisición de GPUs AMD, y salvo Wafer en EE. UU. y algunas empresas, casi no he visto compañías que usen AMD, así que quizá estoy atrapado dentro de la burbuja de Nvidia.
Si suponemos que funciona al 100% durante 8 años, eso es cerca de 1 GWh; incluso en un lugar con electricidad cara como Alemania, serían unos 100.000 euros, así que comparado con el costo inicial del equipo de 500.000 dólares, no es un gasto enorme a lo largo de 8 años.
El verdadero problema del alto consumo no es la factura eléctrica, sino el límite de suministro eléctrico que se puede llevar al centro de datos. Una configuración más eficiente significa que puedes meter más equipos dentro de una acometida eléctrica limitada.
El mercado realmente necesita un competidor efectivo para Nvidia, y en especial importa el rendimiento/watt.
OpenAI también: https://www.amd.com/en/newsroom/press-releases/2025-10-6-amd...
Está genial, pero en uso real la cuantización FP4 casi nunca es prácticamente sin pérdidas. Muchos proveedores anuncian altas tasas de tokens por segundo con Kimi y GLM, pero el modelo queda funcionalmente recortado y ya no está cerca de la calidad de frontera.
Ojalá esto no fuera cierto.
Eso es distinto de GLM, donde la precisión de 16 bits es la base y 8 bits también se usa con frecuencia.
Así que la gente debería crear una cuantización MXFP6, que sea casi sin pérdidas y esté mucho más cerca del rendimiento de FP4 que de FP8.
No he probado lo suficiente los modelos convertidos por Nvidia a NVFP4, salvo GLM 5.2, pero me parecieron bien.
Mis resultados al usarlos directamente fueron irregulares según el modelo.
Pensé que iban a hablar de un camino para mejorar haciéndolo más rápido y barato, pero en este artículo parece que ofrecen la versión cuantizada al mismo precio que la versión completa, y venden la versión rápida mucho más cara.
¿No es esto casi obvio? El rendimiento por dólar debería mejorar en una sola dirección, como un trinquete. ¿Cómo podría algo más caro reemplazar a algo más barato?
Creo que debería ser ilegal que títulos como este no especifiquen el método de cuantización.
.ai. Si ves eso, hay una probabilidad muy alta de que sea un texto de bajo esfuerzo, clickbait, superficial, inútil o engañoso.La computación en memoria y los paradigmas neuromórficos probablemente impulsen mucho más esta tendencia durante la próxima década.
A medida que salgan del laboratorio mejoras más radicales, eventualmente entrarán nuevos materiales y nanodispositivos, y la eficiencia podría mejorar en varios órdenes de magnitud.
Incluso escalar tecnologías existentes como MRAM deja margen.
Al pasar de fp8 a mxfp4 aparece una pérdida de precisión notable.
Aun así, presume de haber reducido más los costos con cuantización, aunque la implementación claramente se queda corta.
[1] https://www.ycombinator.com/launches/Q9i-wafer-pass-flat-rat...
No es un fenómeno nuevo. El rendimiento por dólar viene mejorando de forma exponencial bastante constante desde alrededor de 1900.
1900~2010: https://www.thekurzweillibrary.com/exponential-growth-of-com...
1939~2023: https://medium.com/@timventura/kurzweils-law-for-the-ai-age-...
No sorprende que compita con Blackwell. Rubin es 5 veces más rápido que Blackwell en inferencia, y Blackwell es la última generación de Nvidia que no fue optimizada específicamente para inferencia.
Si me estoy perdiendo algo, me gustaría que me lo dijeran.
Se ve una configuración desagregada que separa los nodos de prefill y decodificación, pero no sé qué más hay.
Especialmente cuando varias monedas se están debilitando.