AMD no fue honesta con el rendimiento de la RX 7900 XTX en DeepSeek y tanto NVIDIA como Dylan Patel contestan con datos

Hace menos de una semana vimos cómo AMD daba una especie de guía para sus usuarios donde explicaba cómo usar sus gráficas con DeepSeek de forma nativa, es decir, una IA para cada PC con su hardware. En ella, mostraba el rendimiento de la RX 7900 XTX, donde esta se alzaba con la victoria frente a NVIDIA y su RTX 4090, algo que sorprendió bastante. Hoy, tanto NVIDIA como Dylan Patel ponen todo en su sitio y muestran cómo AMD no fue honesta, o cometió un error (nunca lo sabremos) con los datos, puesto que la RTX 4090 es bastante más rápida con esta IA de DeepSeek.

No han querido hacer daño, eso está claro, y lo sabemos porque los datos no han sido publicados a bombo y platillo, pero sí que se realizó apenas un día después de que AMD pusiese online los suyos. NVIDIA saca músculo y demuestra, junto con la explicación de Dylan Patel, qué ocurrió con los rojos y cómo todo ha quedado en un tremendo bochorno.

Tanto la RTX 4090 como la RTX 5090 son bastante más rápidas que la RX 7900 XTX en DeepSeek

La temática no cambia, los datos sí. Partimos de aquel artículo que tanto gustó a los usuarios de los rojos para exponer los datos correctos por parte de los verdes y Patel, luego llegarán las explicaciones de lo ocurrido. Seguimos, por tanto, con la técnica Distill, donde DeepSeek creó una familia de seis modelos de IA más pequeños desde el modelo grande R1 con 671.000 millones de parámetros.

Esto es importante de comprender, porque NVIDIA prueba estos modelos más pequeños como son Qwen 7b, Llama 8b y Qwen 32b, siendo los más usados. Entrando en faena, lo que podemos ver es que en Qwen 7b la RTX 5090 es hasta un 103% más rápida que la opción de AMD, y la RTX 4090 es un claro +46% superior. En Llama 8b los datos son casi clavados, con +106% y +47%, mientras que en Qwen 32b tenemos un espectacular +124% y +47%.

En otras palabras y simplificando mucho, los datos de AMD eran totalmente incorrectos, y por una distancia sideral además, de ahí el bochorno, pero, ¿qué pasó realmente para que lanzasen unos datos incorrectos? ¿Cómo sabemos que NVIDIA no se equivoca y AMD sí? Ahí entra Dylan Patel a escena.

AMD usó el código de SemiAnalysis, pero cometió "un error"

AMD reused our code + modified for the benchmarks that show they're faster than Nvidia for training
Few major caveats
They didn't use pytorch native attention backend
They used out of tree attention for MI300, but didn't give NV the same benefit or even the main tree version
1/2 https://t.co/NOEJltkFpq

— Dylan Patel (@dylan522p) February 3, 2025

Como decíamos arriba, nunca sabremos a ciencia cierta si fue un error, un despiste, o un intento de posicionarse por encima de los verdes pensando que no reaccionarían a algo como la guía de DeepSeek.

Sea como fuere, Dylan Patel analizó los datos de AMD porque le extrañaron muchísimo, y dio la casualidad de que los rojos usaron su código modificado, tras lo cual aludió a uno de los ingenieros que realizaron las pruebas: Anush Elangovan, para que viese en X dónde se había equivocado. La conversación es de lo más entretenida:

AMD reutilizó nuestro código y lo modificó para los puntos de referencia que muestran que son más rápidos que NVIDIA para el entrenamiento. Algunas advertencias importantes No utilizaron el backend de atención nativo de PyTorch. Usaron atención fuera del árbol para MI300, pero no le dieron a NV el mismo beneficio o incluso la versión del árbol principal.

Podrían haber utilizado el árbol principal o FA3 y haber logrado un rendimiento mucho mejor. Utilizaron una atención GQA fuera del árbol, pero no habilitaron la GQA nativa de PyTorch para NVIDIA. Es probable que NVIDIA vuelva a realizar pruebas con varios perfiles Megatron y Vboost para mostrar un rendimiento aún mayor

A este mensaje y tras ser citado por el propio Patel, Elangovan respondió lo siguiente:

Utilizamos el último contenedor (docker) de entrenamiento recomendado por AMD y el último contenedor PyTorch de NGC. El contenedor AMD incluye nuestro último kernel FAv3, que se espera que se fusione con el master cuando esté listo. Para NVIDIA comenzamos con el último contenedor PyTorch de Nvidia NGC “ http://nvcr.io/nvidia/pytorch:24.12-py3… ”

Ejecutamos todas las combinaciones de árbol principal/SDPA `enable_qga` y `SDPBackend con CUDNN_ATTENTION y FLASH_ATTENTION` para H200 y H100 con muy poca mejora, dentro del ~1 %. Ver adjunto.

Intentamos agregar FAv3 desde el repositorio de Tri Dao mientras comparábamos H200 con MI325 y encontramos problemas (recientemente presentamos https://github.com/Dao-AILab/flash-attention/issues/1472… ). Estamos depurando esto y actualizaremos una vez que se solucione.

Lógicamente esto no explica los buenos datos para AMD y los malos datos para NVIDIA, pero Patel tenía la solución a este entuerto que dejó muy mal a los rojos:

Creo que hay dos problemas que explican por qué estás obteniendo TFLOPS mucho peores que los que obtengo en cada uno de los servidores H100 que estamos probando. Obtenemos 560 TFLOP/s. Es posible que tengas un servidor defectuoso, o bien, es posible que no estés usando vboost sudo nvidia-smi boost-slider --vboost 1

AMD confiesa no conocer cómo funciona vboost de NVIDIA para los LLM de menor tamaño

I had no idea what vboost is until today. I understand the H100 shifts power to the tensorcores ? I'm not sure what you tradeoff by doing so since it isn't default in h100 for some reason.

Anyway I'm going to now find out how to "vboost" my MI300x and hot rod it Leer Más