El proyecto de código abierto ZLUDA permite que las apps CUDA se ejecuten en GPUs AMD

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

Un proyecto de código abierto llamado ZLUDA aspira a permitir que las aplicaciones CUDA se ejecuten en GPUs AMD, reavivando las esperanzas de romper el dominio de Nvidia en la computación acelerada por GPU. Los comentaristas evalúan los obstáculos técnicos y legales, desde las restricciones del EULA de Nvidia y la dependencia de bibliotecas propietarias como cuDNN hasta los desafíos de la reimplementación limpia y la paridad de rendimiento. Gran parte del debate se centra en el ecosistema de software de AMD, muy criticado durante años, y en sus decisiones estratégicas, incluido por qué dejó de financiar ZLUDA y si alternativas como ROCm, HIP o los estándares abiertos podrán algún día rivalizar con la madurez y el bloqueo de CUDA.

Alcance de ZLUDA y restricciones legales

  • ZLUDA es una implementación limpia y de sustitución directa de CUDA, orientada a GPUs que no son de Nvidia (primero Intel, ahora AMD).
  • El EULA de CUDA de Nvidia lleva, al menos desde 2022, prohibiendo usar las salidas del SDK para apuntar a plataformas que no sean de Nvidia y ejecutar bibliotecas clave (p. ej., cuDNN, cuBLAS) en otro hardware.
  • Debate sobre su aplicabilidad:
    • Una postura: la emulación y la reimplementación de API son, por lo general, legales; si nunca aceptaste el EULA de Nvidia, no estás obligado por él, y esto podría ser anticompetitivo.
    • Otra postura: si las aplicaciones incluyen binarios de Nvidia, sus licencias pueden prohibir ejecutarlos en runtimes de terceros; la DMCA y casos previos de sistemas operativos en hardware ajeno al proveedor sugieren un riesgo legal alto para uso comercial.
  • La ingeniería inversa limpia es posible, pero cara y difícil de mantener al día; hacerlo para todas las bibliotecas de Nvidia es un gran obstáculo.

Estrategia de AMD y ecosistema de software

  • Muchos sostienen que la mayor debilidad de AMD es el software: stacks de OpenCL/ROCm/HIP con errores, drivers inestables y ventanas de soporte cortas, pese a un hardware decente.
  • AMD financió ZLUDA durante unos 2 años y luego lo detuvo, alegando “no business case”; el código pasó a ser de código abierto por contrato.
  • Algunos ven eso como una oportunidad perdida y “absurda”, porque beneficia de inmediato a los usuarios de AMD.
  • Otros argumentan que es racional: una capa robusta de CUDA sobre AMD podría afianzar aún más CUDA, al permitir que los desarrolladores sigan centrados en Nvidia mientras usan AMD solo como hardware de ejecución más barato.

Limitaciones técnicas y prácticas

  • La dificultad clave no es la traducción básica de kernels, sino las equivalentes mantenidas y de alto rendimiento para las bibliotecas de Nvidia (cuDNN, cuBLAS, etc.).
  • Nvidia tiene PTX como IR estable; AMD a menudo compila por arquitectura, lo que complica el soporte a largo plazo y la optimización comunitaria.
  • Hay informes de que ZLUDA + llama.cpp funciona, pero más lento que ROCm nativo; los APUs de AMD suelen estar limitados por el ancho de banda de memoria y por una “VRAM” efectiva pequeña.
  • Algunos aficionados reportan buenas experiencias con LLMs pequeños en GPUs AMD de consumo; otros cuentan caídas persistentes, segfaults y errores de drivers.

Alternativas y estándares

  • Alternativas mencionadas: HIP/HIPIFY (traducción de código fuente, no de runtime), ROCm, OpenCL, Vulkan compute, SYCL, offload de GPU con OpenMP.
  • Varios comentaristas sostienen que AMD e Intel deberían impulsar conjuntamente estándares abiertos como SYCL; otros señalan que la fragmentación y las implementaciones deficientes han limitado su adopción.

Perspectiva general del mercado

  • Varios comentarios describen a Nvidia, AMD e Intel como si actuaran como aspirantes a monopolios una vez que ganan poder.
  • Se especula con que los reguladores, especialmente en la UE, podrían acabar viendo las restricciones de Nvidia como anticompetitivas, pero el resultado no está claro.