Este podría ser el momento que AMD ha estado esperando durante mucho tiempo.
Recientemente, Wafer AI implementó en AMD MI355X Kimi K3. Como resultado, el modelo que anteriormente requería 16 NVIDIA B200 distribuidos en dos servidores ahora se puede implementar en un solo servidor AMD con 8 MI355X.
Más importante aún, no solo incorporó el modelo.
En la prueba con 1024 tokens de entrada y 400 tokens de salida, el MI355X logró un throughput total de 952 tokens/s, con una velocidad de generación por usuario de 118 tokens/s.
Calculado por nodo único, su rendimiento es aproximadamente 3.8 veces mayor que la solución de 16 tarjetas B200, y también supera la relación calidad-precio de las B200 y B300.
Y lo más sorprendente es que ROCm esta vez no se complicó en absoluto.
El modelo es demasiado grande; la memoria gráfica empieza a ser más importante que el poder de cómputo
Kimi K3 tiene 2.8 billones de parámetros, y solo los pesos del modelo requieren más de 1.5 TB de memoria GPU, sin contar el KV Cache necesario para el contexto de millones de tokens.
Un servidor con 8 tarjetas B200, cada una con 192 GB de memoria VRAM, tiene una capacidad total de aproximadamente 1.5 TB. Esto significa que es difícil alojar por completo los pesos del modelo, sin mencionar dejar espacio para el KV Cache. Por lo tanto, el B200 debe utilizar dos servidores con 16 GPU.
Cada tarjeta B300 tiene 288 GB de memoria VRAM, lo que permite alojar el modelo dentro de un solo nodo. Curiosamente, la AMD MI355X también tiene 288 GB de memoria VRAM; ocho MI355X suman aproximadamente 2.3 TB, suficiente con un solo servidor.
No se trata solo de usar una máquina menos. Después de que el modelo se ejecute entre nodos, cada token generado puede requerir la sincronización de datos a través de la red. Incluso con una red RoCE v2 de aproximadamente 195 Gb/s, la comunicación entre nodos aún ralentiza la decodificación.
MI355X, con más memoria de video, mantuvo todo el modelo en un solo nodo.
Según los resultados finales, el throughput pico total de las 8 MI355X alcanzó 952 Token/s, con una velocidad de generación por ruta de 118 Token/s.
Para comparación, el rendimiento total de una implementación de doble nodo con 16 B200 es de 498 tokens/s, lo que equivale a aproximadamente 249 tokens/s por nodo.
Es decir, el rendimiento por nodo único del MI355X es aproximadamente 3.8 veces mayor que el rendimiento promedio por nodo único de la implementación dual nodo del B200. En cuanto a la velocidad de generación por usuario, el MI355X con 118 Token/s también supera al B200 con 90 Token/s.
B300 sigue siendo la solución con el rendimiento absoluto más alto. El nodo con 8 B300 alcanza un rendimiento total de 1568 Token/s, con una velocidad de generación por ruta de 172 Token/s, lo que representa aproximadamente 1.65 veces el rendimiento total del MI355X.
Pero el precio cambió la conclusión. Wafer se calcula a $2.50 por tarjeta por hora para MI355X, $4.25 para B200 y $6 para B300.
Bajo este supuesto de precio, MI355X puede proporcionar aproximadamente 48 Token/s de capacidad máxima por dólar; B200, alrededor de 7 Token/s; B300, alrededor de 33 Token/s.
B300 es más rápido, pero la MI355X ofrece una mayor eficiencia de costo por unidad. Para centros de datos que necesitan ejecutar modelos abiertos a gran escala, esto puede ser más importante que simplemente competir por el título de rendimiento máximo.
Lo más sorprendente es que ROCm se puede usar directamente.
Durante mucho tiempo, el mayor problema de las GPU de centro de datos de AMD no ha sido el hardware, sino el software.
El mismo modelo puede ejecutarse directamente en CUDA, pero en ROCm puede requerir cambiar el marco, agregar operadores o incluso reescribir los núcleos subyacentes.
pero Kimi La situación de K3 es diferente.
AMD proporciona soporte casi sincronizado desde el lanzamiento. Wafer indicó que los modelos pueden ejecutarse directamente en el MI355X, y los trabajos posteriores se centran principalmente en algunas cuestiones de compatibilidad y optimización de rendimiento.
Uno de los problemas surgió en la etapa de decodificación por inferencia. Kimi K3 no proporciona por sí mismo los parámetros del modelo de borrador necesarios para MTP o EAGLE, por lo que Wafer utilizó un modelo de borrador de difusión externo.
Este方案 puede ejecutarse directamente en CUDA, pero en el entorno ROCm, la primera solicitud real provoca un error en el programador. La causa es que en la rama ROCm falta la definición de una función llamada top_k_renorm_prob.
Lo que hace esta función no es complicado: seleccionar los k valores más altos de una distribución de probabilidad, establecer en cero las demás probabilidades y volver a normalizar las probabilidades conservadas.
Wafer completó finalmente esta lógica utilizando una función común de PyTorch, sin necesidad de escribir kernels de GPU ni de rediseñar el sistema de decodificación por especulación.
Tras la corrección, se estima que la decodificación mejoró el rendimiento en una sola vía en aproximadamente 2.2 veces, el rendimiento de un solo flujo bajo carga media en aproximadamente 1.7 veces y el rendimiento total máximo en aproximadamente un 18%.
Más importante aún, el sistema puede alcanzar su capacidad máxima de procesamiento bajo una mayor concurrencia.
El primer carácter es demasiado lento, al final solo se agregaron cuatro ceros
Of course, throughput is not the whole story for inference services. For real users, another metric that directly impacts the experience is TTFT, the wait time from sending a request to seeing the first token.
En esta tarea, el MI355X tuvo un desempeño inicial deficiente. Frente a una tarea de prellenado de arranque en frío de aproximadamente 172.000 tokens, el MI355X requirió unos 51 segundos, mientras que el B300 solo necesitó unos 23 segundos.
En modelos que admiten contextos de hasta un millón de tokens, la tarea de prellenado puede ser extremadamente grande. Si los usuarios deben esperar decenas de segundos o más cada vez que se procesa un contexto largo, incluso la velocidad de decodificación más alta difícilmente podrá compensar el problema de experiencia.
Wafer finalmente descubrió que la brecha de rendimiento proviene casi por completo de un núcleo de atención. Kimi K3 en una configuración de paralelismo de tensor de 8 rutas asigna 12 cabezas de atención a cada GPU. El kernel de prellenado MLA más rápido de AMD AITER solo admite formas que sean múltiplos de 4, 8 o 16.
12 encabezados no coincidieron, por lo que el sistema volvió a la implementación general de Triton más lenta.
La solución es sencilla: rellena con ceros los 12 cabezales de atención hasta llegar a 16, llama al núcleo de alta velocidad existente y, una vez completado el cálculo, recupera solo los 12 cabezales realmente necesarios. No se modificó la estructura del modelo ni se escribió ningún nuevo núcleo en ensamblador; simplemente se añadieron cuatro ceros.
Tras la optimización, la velocidad estable de prellenado del núcleo AITER MLA alcanza aproximadamente 13.000 tokens/s, mientras que la ruta de respaldo original de Triton solo alcanzaba alrededor de 4.000 a 7.000 tokens/s, reduciendo así el tiempo de prellenado en frío en aproximadamente dos a tres veces.
Esta optimización no altera el rendimiento final de decodificación, pero reduce significativamente el tiempo que los usuarios esperan para que aparezca el primer carácter.
Esto también indica que la aparente gran brecha de software entre AMD y NVIDIA a veces no se debe a una falta de capacidad subyacente, sino a que los núcleos de alta velocidad actuales aún no cubren ciertos nuevos formatos de modelos.
El foso de CUDA aún existe, pero ya se han abierto grietas
Una sola prueba, por supuesto, no demuestra que AMD haya alcanzado por completo a NVIDIA.
B200 se ve obligado a ejecutarse entre nodos debido a la falta de memoria de vídeo; el rendimiento absoluto del B300 sigue liderando; la cadena de herramientas, el soporte de marcos y el ecosistema de desarrolladores de ROCm aún son inferiores a CUDA.
Pero los modelos abiertos están entrando rápidamente en la era de los billones de parámetros. Cuando los modelos son tan grandes que no caben en un solo servidor, la capacidad de memoria de GPU ya no es solo un número en una tabla de parámetros, sino que afecta directamente el costo de comunicación, la complejidad de implementación y el rendimiento final.
La estrategia de AMD de asignar más HBM a configuraciones de una sola tarjeta está convirtiéndose en una ventaja sistémica real.
Si AMD puede continuar mejorando la estabilidad de ROCm, ampliar el soporte para formas de núcleos de alta velocidad y ofrecer compatibilidad oportuna el mismo día para nuevos modelos, entonces los centros de datos deben considerar seriamente estas GPU. Son más baratas, tienen más memoria VRAM, suficiente rendimiento y ya no requieren meses de ajustes de software.
¿Qué piensas al respecto?
Enlace de referencia:
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151
Este artículo proviene del número de WeChat "Machine Heart" (ID: almosthuman2014), autor: interesado en LLM