CUDA sigue siendo un enorme foso para Nvidia

El foso de CUDA y el lock-in

• Muchos sostienen que CUDA tiene menos que ver con el lenguaje y más con el ecosistema que lo rodea: bibliotecas, herramientas e integración profunda con marcos como PyTorch, TensorFlow, JAX y servidores de inferencia.
• Las restricciones de la EULA de CUDA (por ejemplo, sobre la ingeniería inversa para objetivos que no sean de NVIDIA) se citan como un factor que refuerza el lock-in.
• Algunos ven esto como un monopolio de software perjudicial, similar al dominio pasado de los navegadores o las tiendas de aplicaciones; otros creen que los monopolios son transitorios y que la sociedad acaba beneficiándose de la innovación aunque una sola empresa se enriquezca.

Papel del software y del ecosistema

• Tema recurrente: los competidores de hardware subestimaron lo crítico que es el software.
• NVIDIA se trató a sí misma como una empresa de stack completo y muy centrada en software durante unos 20 años, construyendo bibliotecas (cuBLAS, cuDNN, etc.), compiladores, depuradores, perfiladores e integración estrecha con la investigación y la industria.
• El verdadero foso se describe como “base instalada + integraciones”, no solo la sintaxis de CUDA.

Críticas a AMD/Intel/ROCm

• Se critica ampliamente a AMD e Intel por:
  • Invertir poco en equipos de software, herramientas y documentación.
  • Mala estabilidad de controladores, soporte de dispositivos limitado y regresiones (por ejemplo, ROCm solo admite un conjunto reducido de GPUs, problemas en APU y en piezas de cloud).
  • Abandonar o infrafinanciar proyectos de compatibilidad con CUDA y capas de traducción.
• Algunos argumentan que deberían aumentar masivamente la contratación de software, financiar la integración directa en todos los principales proyectos OSS y lanzar tarjetas de consumo con mucha VRAM para tentar a quienes se cambien.

Dificultad de programar GPU

• Escribir CUDA de alto rendimiento se describe como algo extremadamente especializado:
  • Requiere un conocimiento profundo de algoritmos, hardware, jerarquías de memoria, concurrencia y múltiples generaciones de GPU.
  • Incluso muchos “programadores CUDA” solo logran un rendimiento básico; cerrar la brecha con las propias bibliotecas de NVIDIA se considera trabajo de nivel olímpico.
• Otros señalan que ciertas cargas de trabajo de nicho aún pueden superar a las bibliotecas de NVIDIA con kernels personalizados, especialmente fuera de la ruta principal de optimización.

Frameworks de alto nivel vs CUDA de bajo nivel

• La mayoría de los usuarios de ML escriben PyTorch, etc., no CUDA, pero esos propios frameworks y muchos métodos de vanguardia (por ejemplo, variantes personalizadas de atención, álgebra lineal especializada) dependen de kernels CUDA afinados a mano.
• CUDA sigue siendo central para HPC no orientado a ML, procesamiento de señales y computación científica.

Competencia, China y alternativas

• Algunos creen que LLVM/OpenMP, ONNX, TVM, Metal o nuevos lenguajes (por ejemplo, Mojo) podrían erosionar CUDA con el tiempo.
• Otros argumentan que, sin una cultura sostenida, bien financiada y prioritaria en software (ya sea en AMD, Intel o en China), esas alternativas seguirán siendo incompletas y de segunda categoría.