AMD financió una implementación drop-in de CUDA construida sobre ROCm: ahora es de código abierto

Artículo original ↗ Discusión en Hacker News ↗

AMD financió discretamente ZLUDA, una implementación drop‑in de CUDA sobre su stack ROCm que puede ejecutar muchas cargas de trabajo dirigidas a NVIDIA en GPUs Radeon y, en algunos casos, incluso superar al backend HIP nativo de AMD. El proyecto se ha liberado ahora como código abierto después de que AMD terminara su contrato, lo que ha reavivado el debate sobre si abandonar una capa de compatibilidad con CUDA casi lista es un error estratégico en un momento en que NVIDIA domina la IA y el cómputo en GPU. Los comentaristas contraponen el sólido y ampliamente soportado ecosistema de software de NVIDIA con el soporte fragmentado de ROCm de AMD y discuten si AMD debería perseguir la compatibilidad con CUDA, apostar más por su propia pila o centrarse en despliegues de centro de datos de alta gama en lugar de GPUs de consumo.

Proyecto y lanzamiento

  • ZLUDA es una implementación “drop‑in” de CUDA sobre el stack ROCm/HIP de AMD, financiada originalmente por AMD mediante un contrato privado.
  • AMD canceló la financiación tras ~2 años, afirmando que no había “caso de negocio” para ejecutar CUDA en GPUs de AMD; el contrato permitía al autor liberar el código como código abierto, lo que dio lugar a un gran commit único.

Rendimiento y capacidades

  • Los benchmarks citados en el hilo muestran que el backend CUDA de Blender a través de ZLUDA a veces supera al backend HIP nativo de Blender en hardware Radeon.
  • La cobertura actual de cuDNN es mínima (suficiente para ejecutar ResNet‑50); el soporte de PyTorch se describe como muy limitado.
  • ZLUDA reimplementa grandes partes de la “dark API” de CUDA mediante ingeniería inversa, lo cual es complejo y, por su naturaleza, frágil.

Reacciones al fin de la financiación por parte de AMD

  • Muchos comentaristas creen que abandonar el proyecto es estratégicamente irracional dado el auge de la IA de NVIDIA y el bloqueo de CUDA.
  • Otros sostienen que AMD no quiere perseguir permanentemente una API propietaria que no controla y prefiere impulsar directamente ROCm/HIP.
  • Algunos sospechan de política interna, restricciones de recursos o aversión al riesgo legal; otros señalan que tanto Intel como AMD han concluido antes que no había “caso de negocio” para la compatibilidad con CUDA.

Estado de ROCm y la estrategia de GPU de AMD

  • Hay una crítica fuerte a que ROCm solo admita oficialmente muy pocas GPUs de consumo, sea difícil de instalar y presente problemas de estabilidad; esto disuade a desarrolladores y aficionados.
  • Quienes lo defienden señalan que ROCm funciona de forma no oficial en muchas más tarjetas, y que AMD está priorizando el centro de datos/HPC (MI300, sistemas Top500) por encima del cómputo para gaming/entusiastas.
  • Varias anécdotas muestran laboratorios y particulares eligiendo tarjetas NVIDIA solo por CUDA y sus herramientas, a pesar de que les gusta el hardware de AMD.

La ventaja competitiva de CUDA y alternativas

  • Hay un consenso amplio en que el dominio de CUDA proviene de años de inversión en compiladores, bibliotecas (cuDNN, cuBLAS), herramientas y compatibilidad hacia atrás.
  • Se debate si una capa de compatibilidad fortalece la posición de CUDA (como OS/2 ejecutando aplicaciones de Windows) o si es un puente necesario que más tarde podría habilitar “embrace/extend”.
  • Se mencionan alternativas: ROCm/HIP, SYCL, Vulkan compute, WebGPU, OneAPI; OpenCL es visto ampliamente como un intento fallido.

Perspectivas de código abierto y puntos poco claros

  • Hay optimismo de que abrir el código de ZLUDA permita que la comunidad continúe el desarrollo y presione a NVIDIA sobre la estabilidad de la API.
  • Existe escepticismo sobre la sostenibilidad a largo plazo: una enorme carga de mantenimiento, una CUDA en constante cambio y un compromiso limitado de AMD.
  • Se debate el estatus legal de reimplementar APIs/ABIs de CUDA; las implicaciones siguen sin estar claras.