ROCm desafía a CUDA: “avanzar paso a paso”
(eetimes.com)- AMD está reforzando su estrategia de GPU para centros de datos en torno a ROCm, su stack de software de IA, para competir con el ecosistema CUDA de Nvidia
- ROCm evolucionó desde un simple conjunto de firmware inicial hasta convertirse en una plataforma de software completa, y está adoptando un esquema de lanzamientos cada 6 semanas para asegurar una usabilidad estable
- Con OneROCm, impulsa la integración y portabilidad del stack de IA entre CPU, GPU y FPGA, y está mejorando la eficiencia de desarrollo mediante la reutilización de código basada en Triton y MLIR
- ROCm ha abierto como software de código abierto todos sus componentes excepto el firmware, absorbiendo así la velocidad de innovación de la comunidad, y también cuenta con soporte nativo en laptops Strix Halo y en la versión para Windows
- AMD pone énfasis en responder al feedback de los desarrolladores y recuperar la confianza de la comunidad, con el objetivo de convertir ROCm en una plataforma sostenible y centrada en desarrolladores para la próxima década
La evolución de AMD ROCm y su estrategia para competir con CUDA
- AMD está impulsando ROCm, su stack de software de IA, como estrategia central para enfrentar al ecosistema CUDA de Nvidia en el mercado de GPU para centros de datos
- Anush Elangovan, vicepresidente del área de software de IA, describió el desarrollo de ROCm como “el proceso de subir una montaña, avanzando paso a paso”, destacando la mejora continua y la integración
- Se unió a AMD tras la adquisición de la startup Nod.ai, y el equipo de Nod tiene experiencia contribuyendo a importantes proyectos open source como Shark, Torch.MLIR e IREE
- A través de ROCm, AMD impulsa la integración del stack de IA entre CPU, GPU y FPGA (OneROCm), y busca acortar el ciclo de desarrollo de software a intervalos de 6 semanas, con la meta de llegar a un nivel en el que “el usuario ni siquiera tenga que pensar en la versión”
- Actualmente, ROCm se está preparando para una transición hacia la ingeniería asistida por IA, al tiempo que acelera su expansión apoyándose en el ecosistema open source y en la comunidad de desarrolladores
El avance de ROCm y la estrategia de software
- En sus inicios, ROCm era una agrupación de varios fragmentos de firmware, pero tras dos años y medio de inversión evolucionó hacia una plataforma de software completa
- Elangovan tomó como referencia la cultura de desarrollo del equipo de Google Chrome para apuntar a ciclos de lanzamiento regulares y una experiencia de usuario estable
- ROCm ya se posicionó como un software que “simplemente funciona”, y planea pasar a un modelo de lanzamientos cada 6 semanas
- AMD está transformándose de una empresa centrada en hardware a una centrada en software, y ve en la ingeniería asistida por IA (AI-assisted engineering) el próximo punto clave de inflexión
Integración y portabilidad del stack de IA
- AMD hace realidad la integración del stack de IA entre distintos tipos de hardware como CPU, GPU y FPGA mediante OneROCm
- Aunque algunos componentes siguen dependiendo del hardware, toda la aceleración se realiza a través del stack ROCm, lo que asegura la portabilidad (portability)
- La expansión del framework Triton ha reducido los problemas de compatibilidad entre GPU
- Antes se convertían kernels CUDA a kernels HIP, pero ahora es posible escribir kernels Triton que pueden ejecutarse tanto en AMD como en Nvidia
- AMD está invirtiendo activamente en Triton y en la infraestructura de compiladores MLIR, y mediante el mantenimiento de Torch.MLIR permite redirigir código hacia distintos tipos de hardware
- La mayoría de los clientes de inferencia usan frameworks de LLM como vLLM y SGLang, y las solicitudes para convertir código CUDA han disminuido
- Cuando aparece un nuevo algoritmo de atención, es posible optimizar kernels basados en Triton en uno o dos días
- HIPify sigue ofreciéndose para clientes de HPC, y para escribir nuevos kernels se utiliza Claude AI para validación y generación de código
Estrategia open source
- ROCm publica como 100% open source todos sus componentes excepto el firmware
- Al abrir el código, no solo recibe validación de la comunidad de desarrolladores, sino que también puede aprovechar la velocidad de innovación de la comunidad, superior a la de AMD
- Cualquiera puede participar en el punto que quiera, ya sea el compilador, el runtime u otra capa, sin quedar limitado por la velocidad de colaboración de AMD
- AMD está impulsando activamente la expansión de la comunidad de desarrolladores, y ROCm tiene soporte nativo en laptops con Strix Halo
- También distribuye las actualizaciones de ROCm para Windows el mismo día que en el hardware de centro de datos Instinct
Comunidad de desarrolladores y cultura de feedback
- Elangovan da gran importancia a la comunicación directa con desarrolladores y recopila feedback en tiempo real a través de X (Twitter)
- Monitorea palabras clave como “ROCm”, “ROCm sucks” y “AMD software not working”, y responde personalmente a todas las publicaciones
- La mayoría de los problemas se originan por falta de formación y soporte, y ofrece orientación directa incluso a desarrolladores anónimos
- AMD investigó en GitHub más de 1,000 quejas relacionadas con ROCm y las resolvió todas en el plazo de un año
- Hubo muchas solicitudes de soporte para hardware antiguo, que actualmente AMD o la comunidad mantienen
- Gracias a esta respuesta, se recuperó la confianza de los desarrolladores y se extendió la percepción de que “AMD resuelve los problemas”
- Elangovan expresó expectativas positivas sobre la GPU MI450, cuyo lanzamiento está previsto para la segunda mitad de 2026, y subrayó que ROCm se desarrollará como una plataforma sostenible para la próxima década
- El objetivo es construir un ecosistema estable en el que los desarrolladores no tengan que preocuparse incluso cuando llegue nuevo hardware
Dirección futura y filosofía
- Basándose en su experiencia en Nod.ai, Elangovan mencionó casos en los que tecnología de compiladores terminó siendo adoptada por casi todas las empresas de aceleradores
- Señaló que “hay que avanzar paso a paso con convicción”, definiendo el progreso de ROCm como el resultado de una ejecución continua
- AMD no busca simplemente copiar CUDA, sino que está desarrollando funciones diferenciadas para ROCm, con el objetivo de posicionarlo a largo plazo como una plataforma centrada en desarrolladores
2 comentarios
Empezando por el driver...
Opiniones de Hacker News
Durante la última semana estuve porteando TheRock a stagex e intentando compilar ROCm con una toolchain basada en musl/mimalloc
porque no se puede confiar en binarios construidos con un solo compilador para cargas de trabajo donde la seguridad y la privacidad son críticas
Fue una pesadilla empaquetar más de 30 dependencias y un LLVM personalizado, pero finalmente esta mañana logré compilar el runtime
El hecho de que el hardware de AMD funcione en un entorno completamente abierto da esperanza para cargas de trabajo de alta seguridad
Logré avanzar con el fork personalizado de LLVM y varios paquetes, pero al final lo abandoné porque era una pérdida de tiempo
Ahora uso llama.cpp con soporte para Vulkan y estoy bastante satisfecho
Si pudieras compartir la receta de compilación, creo que ayudaría a superar la etapa final del port a Alpine
El año pasado detuve una campaña de accionistas porque confié en las promesas de AMD, pero ahora siento que de verdad hace falta actuar
unlockgpu.com/action-plan
No debería ser así; este trabajo claramente debería ser utilizable
Nvidia también prometió mejorar sus drivers open source
En lo personal, me atrae más que Intel ofrezca 32GB de VRAM por alrededor de 1000 dólares
¿Se refiere a mezclar y enlazar archivos .o compilados con distintos compiladores?
Me pregunto si realmente se trata de una carga de trabajo que busca evitar el problema de Reflections on Trusting Trust
Desde febrero estoy pidiéndole a AMD que incluya kernels de Tensile ajustados para gfx1201 en rcom-libs, pero nadie sabe quién está a cargo
Es frustrante que tampoco haya respuesta en el Discord de desarrolladores. Parece un caso que muestra no solo problemas técnicos, sino también un cuello de botella organizacional dentro de AMD
zichguan-amd o harkgill-amd podrían ser las personas responsables
AMD todavía tiene que cerrar una brecha de varios años en ROCm
Ni siquiera soporta todas sus propias GPU capaces de hacer cómputo de IA, y aun cuando las soporta hay muchos bugs
El driver AMDGPU para Linux sigue siendo inestable desde 6.6
No haber visto que la IA se iba a volver importante fue claramente un error
Si AMD se volviera competitiva, sería bueno para toda la industria, pero esto se lo buscaron solos
Desde la época de ATI ya tenían mala fama por sus drivers llenos de bugs, y parece que esa cultura no cambió después de la adquisición por AMD
El año pasado AMD recopiló quejas sobre ROCm en GitHub y anunció que había resuelto las 1000
Pero en la práctica casi no aumentó el soporte para hardware antiguo
Cuando llegue el día en que ROCm tenga soporte desde el día del lanzamiento para todas las tarjetas AMD, recién ahí sentiré que se puede creer en el marketing
Haber abandonado antes incluso tarjetas relativamente nuevas como la serie 400 fue un gran error
Ojalá la dirección invierta más en el stack de software
ROCm no tiene soporte para GPU de consumo comunes, por ejemplo tarjetas como la RX 580
En cambio, el backend de Vulkan funciona bien
Me parece normal que la arquitectura GCN ya haya quedado fuera de soporte, pero en la generación RDNA el problema sigue siendo la falta de soporte
Actualmente solo funcionan RDNA3 y RDNA4, mientras que CUDA todavía soporta Turing
Ver la documentación oficial
El backend de Vulkan funciona bien, pero el soporte oficial tardó entre 1 y 2 años en llegar
Ojalá hicieran un clean-up del stack de ROCm
Que se pudiera compilar simplemente con
git clone --recurse-submodules rocmseguido de configure/make, y que mostrara claramente qué dependencias faltanEn este momento parece más bien una colección de componentes arrojados sin estructura, y no se ve una arquitectura consistente
Yo estoy en el equipo que busca enfrentar a CUDA con OpenVINO y SYCL
Las iGPU y dGPU de Intel últimamente tienen precios razonables y el soporte de software ha mejorado bastante
Para cargas de visión por computador o ciencia de datos, más que gaming, escala bastante bien
Este es el feedback sobre ROCm que me gustaría hacerle llegar a la dirección de AMD
(1) Haber soportado solo GPU de servidor e ignorado GPU/APU de consumo fue un error estratégico
La mayoría de los desarrolladores experimenta en laptops personales y después escala a servidores
Como CUDA, debería funcionar en GPU de consumo aunque el rendimiento sea menor
(2) La política de soportar solo dos generaciones es irracional desde la perspectiva del cliente
Ver la documentación oficial
CUDA mantiene una fuerte compatibilidad hacia atrás
(3) Enfocarse solo en Triton y tratar HIP como algo de segunda categoría va en la dirección equivocada
Sigue habiendo mucho código HPC, simulación y ciencia basado en C/C++
Las GPU de AMD tienen como fortaleza el rendimiento FP64, y así están desperdiciándolo ellas mismas
(4) Por último, hay que mejorar la calidad del empaquetado
Colaborar con los empaquetadores de distribuciones no cuesta tanto y podría darles una ventaja competitiva frente a Nvidia
Puedes escribir kernels directamente desde Python, Julia y varios otros lenguajes, y la integración con IDE, depuradores y bibliotecas es excelente
Si miras el ecosistema GPGPU completo, AMD e Intel todavía no alcanzan el nivel de madurez del ecosistema de CUDA
La mayoría de las empresas opta por instalaciones del proveedor como
/opt/foo/Así después también es más fácil para la distribución empaquetarlo por su cuenta
Pero para entender esto se necesita gente con experiencia en el ecosistema open source
Está retrasando el lanzamiento de GPU de consumo con mucha VRAM mientras se enfoca en el mercado de servidores
Si AMD aprovecha bien ese hueco, podría ser una oportunidad
Por ejemplo, también corre bien en una 7900 XT
Lo único es que AMD no invierte recursos de pruebas para etiquetarlo como “soporte oficial”
Por mi experiencia previa trabajando con compute shaders, CUDA, ROCm y OpenCV son demasiado engorrosos de instalar
Las dependencias también son enormes, y CUDA pesa 11GB
Creo que es mejor usar Vulkan. No depende de una plataforma específica y “simplemente funciona”
Solo la compilación de shaders y la configuración de recursos ya requieren cientos de líneas, y para manejar direcciones de GPU hacen falta extensiones
No parece algo que deba tomar horas
Antes incluso había un bug(?) en NVIDIA donde cambiar al modo gráfico mejoraba el rendimiento un 20%