AMD vs. NVIDIA en inferencia de IA: el rendimiento por dólar está mejorando, pero no es gratis
Hace un tiempo que el mercado de GPUs para IA es un monopolio de facto de NVIDIA. Si quieres correr modelos grandes sin dolores de cabeza, compras NVIDIA y listo. Pero esa comodidad tiene un precio, y últimamente ese precio se está yendo a las nubes. Es por eso que me llamó la atención lo que hizo Wafer: desplegar GLM-5.2 en GPUs AMD MI355X y demostrar que el rendimiento por dólar puede ser mucho mejor, siempre y cuando estés dispuesto a meter las manos al código.
Según sus números, una MI355X cuesta alrededor de 2,75 veces menos que una NVIDIA B300 con especificaciones similares. En throughput sostenido, lograron unos 2.626 tokens por segundo por nodo antes de saturarse, con un TTFT que se mantiene razonable. Eso equivale a aproximadamente el 80% del rendimiento de una B200, pero por más de la mitad del precio. En otras palabras, si tu presupuesto es apretado y tienes ingenieros que cachan del tema, AMD empieza a tener sentido.
El problema es el software, no el silicio
Aquí viene el pero. AMD tiene hardware decente, pero ROCm sigue siendo el dolor de cabeza principal. NVIDIA gana porque CUDA lleva años de ventaja y todo funciona de inmediato. Con AMD, si quieres correr un modelo de punta como GLM-5.2, no basta con instalar el driver y darle play. Wafer tuvo que pasar semanas debuggeando para lograr que el modelo corriera bien.
El primer obstáculo fue la cuantización. Pasaron de BF16 a MXFP4 usando AMD Quark, lo que en teoría reduce el uso de memoria sin perder calidad. Y funcionó: la diferencia en benchmarks como GSM8K fue mínima, casi imperceptible. Pero el framework de inferencia sglang, que soporta MXFP4, no estaba preparado para las particularidades del modelo en ROCm.
Bug tras bug: lo que nadie te cuenta
Uno de los problemas más molestos fue el speculative decode, o MTP (Multi-Token Prediction). Este truco puede acelerar la inferencia hasta 3x, pero en la imagen ROCm de sglang simplemente no andaba. La razón: el prefijo del módulo MTP head no coincidía con lo que esperaba el sistema de cuantización. Un experto se llamaba de una forma en Quark, pero sglang lo buscaba con otro nombre. Eso hacía que el sistema intentara leer pesos BF16 en slots de 4 bits, y obvio que crasheaba.
La solución fue un hack manual: copiar las entradas de capa 78 a la lista de capas que no debían cuantizarse, pero usando el nombre que sglang efectivamente usaba. Con ese parche, el speculative decode empezó a funcionar y el throughput se disparó.
Y eso no fue todo. Para activar el deep speculative decode con configuración 5/1/6, el kernel de metadata en sglang tenía un include directo a cuda_runtime.h sin ningún guard de ROCm. Un simple #ifdef USE_ROCM fue suficiente para desbloquear otra optimización.
Opinión: la pega de infraestructura está más viva que nunca
Esto me deja una reflexión clara. En los últimos meses hemos visto una explosión de modelos de IA — Claude Fable, GLM-5.2, Minimax M3 — pero la infraestructura para correrlos no se ha democratizado al mismo ritmo. Todo el mundo habla de los modelos, pero pocos hablan de lo que cuesta mantenerlos corriendo.
Si eres una startup o un equipo pequeño, el hecho de que AMD ofrezca un rendimiento comparable por la mitad del precio es una excelente noticia. Pero ojo: no es para cualquiera. Necesitas gente que sepa leer logs de kernels, parchear frameworks y debuggear shape mismatches en pesos cuantizados. Es decir, la pega de ingeniería de sistemas no desapareció con la IA; al contrario, se volvió más compleja.
Personalmente, me gusta que existan alternativas a NVIDIA. La concentración de todo el ecosistema de IA en un solo proveedor es un riesgo para la industria. Pero AMD tiene que ponerse las pilas con ROCm. No puede ser que cada modelo nuevo requiera semanas de ingeniería manual para funcionar en sus GPUs. El hardware ya está; falta que el software alcance.
¿Tú qué crees? ¿Le darías una oportunidad a AMD en tu stack de IA, o sigues con NVIDIA por comodidad?
Fuente de inspiración: Performance per dollar is getting faster and cheaper | Wafer
