Las restricciones de suministro de GPU no son algo abstracto para los equipos de infraestructura europeos en este momento. Las asignaciones de Nvidia son limitadas, los plazos de entrega son largos, y la pregunta de si es posible migrar cargas de trabajo de inferencia o entrenamiento a hardware de AMD o Intel sin reescribir todo ha pasado de ser académica a urgente. La respuesta honesta es: a veces sí, con frecuencia de forma parcial, y en ocasiones en absoluto. El resultado depende de la herramienta concreta, el framework concreto y hasta qué punto tu código accede a los componentes internos específicos de Nvidia.

Este artículo mapea el panorama de portabilidad tal como está a mediados de 2026, cubriendo AMD ROCm, Intel oneAPI, Spectral Compute SCALE y ZLUDA. Seremos directos sobre dónde funciona cada enfoque, dónde falla y qué significa eso para los equipos que ejecutan inferencia en GPU sin Nvidia en un contexto cloud europeo.

Los cuatro enfoques de portabilidad y qué hacen realmente

Estas herramientas resuelven el mismo problema desde cuatro ángulos distintos, y confundirlas lleva a decisiones arquitectónicas erróneas.

AMD ROCm y HIP

ROCm es la plataforma de cómputo GPU open source completa de AMD. HIP es la capa de compatibilidad con CUDA que incluye: una API de traducción que mapea las llamadas CUDA al backend de AMD para que el código pueda compilarse para cualquiera de los dos fabricantes. Las herramientas HIPIFY de AMD automatizan gran parte de esta traducción. hipify-clang analiza la sintaxis CUDA y la convierte a HIP a nivel de código fuente; hipify-perl gestiona sustituciones más sencillas pero detecta menos errores.

HIPIFY cubre un amplio conjunto de llamadas a la API de tiempo de ejecución de CUDA, sintaxis de lanzamiento de kernels y funciones de la biblioteca estándar donde existe un equivalente en HIP. Lo que no puede gestionar es todo aquello que no tiene contrapartida en AMD: bibliotecas CUDA sin equivalente en HIP y características específicas de arquitectura como el PTX en línea (el lenguaje ensamblador virtual de Nvidia), que siguen requiriendo portabilidad manual. Para uso en producción, la propia documentación de AMD dirige a los equipos a ROCm 7.2.4; la versión 7.13.0 es únicamente una vista previa tecnológica.

El beneficio práctico es real para las cargas de trabajo de inferencia. PyTorch, vLLM y SGLang cuentan con soporte oficial de ROCm en 2026. Los resultados de MLPerf Inference 6.0 de abril de 2026 muestran que la MI355X de AMD obtiene puntuaciones de inferencia en servidor a pocos puntos porcentuales de la B200 de Nvidia para inferencia LLM estándar. TensorRT-LLM y FlashAttention 3 aún no tienen soporte ROCm, lo que importa si tu stack depende de ellos.

Intel oneAPI y SYCLomatic

El enfoque de Intel es arquitectónicamente diferente. En lugar de traducir CUDA a un backend específico de un fabricante, oneAPI está construido sobre SYCL, un modelo de programación basado en C++ regido por estándares abiertos de la industria. La premisa es que el código basado en estándares puede sobrevivir a cualquier generación de hardware.

SYCLomatic, la herramienta de migración open source disponible en GitHub, convierte código CUDA existente a SYCL. La propia documentación de Intel afirma que entre el 90 y el 95 por ciento de una base de código CUDA se porta correctamente de forma automática. Hay una advertencia que vale la pena mencionar: el Intel DPC++ Compatibility Tool, la distribución binaria de esta funcionalidad, quedó obsoleto en la versión 2025.3 y será eliminado en una versión futura. El trabajo futuro se dirige a la comunidad open source de SYCLomatic. Los equipos que construyan sobre esta ruta deben planificarlo en consecuencia.

Usar oneAPI con hardware de AMD o Nvidia requiere instalar plugins específicos del fabricante desde Codeplay. El modelo SYCL es el más puro en términos de estándares de todas las opciones aquí descritas, pero requiere el mayor trabajo de integración para llegar a objetivos que no sean Intel.

Spectral Compute SCALE

SCALE apuesta por algo diferente. En lugar de traducir tu código fuera de CUDA, funciona como un reemplazo directo de NVCC, el compilador CUDA de Nvidia, usando Clang y LLVM por debajo. Mantienes tu base de código CUDA; SCALE lo compila para hardware AMD de forma transparente a través de un entorno virtual llamado scalenv que reemplaza a nvcc.

En lugar de migrar los programas fuera de CUDA, SCALE ofrece una plataforma neutral al fabricante que permite a los usuarios conservar sus bases de código existentes.

Spectral Compute fue fundada en 2018 y lanzó la primera beta pública de SCALE en julio de 2024. La versión 1.4.2, publicada en octubre de 2025, admite GPUs AMD; Nvidia y otros aceleradores están en la hoja de ruta. Un artículo revisado por pares en ACM indica que SCALE cubre la mayoría de la API de CUDA, lo que refleja aproximadamente un 60 por ciento de cobertura en cuatro microarquitecturas de GPU AMD y trece frameworks populares. Los propios benchmarks de Spectral Compute afirman una ejecución 5,94 veces más rápida que HIP en hardware AMD, aunque se trata de cifras publicadas por el fabricante y no de resultados verificados de forma independiente. La limitación actual importante: SCALE aún no cubre suficiente de la API de CUDA para portar frameworks grandes como PyTorch. La empresa cerró una ronda semilla de 6 millones de dólares en noviembre de 2025.

ZLUDA

ZLUDA es la opción más inusual. Opera sobre el binario compilado en lugar del código fuente, lo que significa que no necesitas el código fuente y heredas todas las optimizaciones de nvcc. Comenzó en Intel en 2020, pasó a AMD y ahora lo mantienen dos desarrolladores independientes. La versión 5, publicada en octubre de 2025, puede ejecutar llama.cpp pero está lejos de una cobertura general. También existe una cuestión legal: la licencia de CUDA parece prohibir traducir la salida generada por el SDK de CUDA para apuntar a plataformas que no sean Nvidia. Los equipos que consideren ZLUDA para producción deben obtener revisión legal antes de proceder.

Dónde falla realmente la portabilidad de CUDA

Los modos de fallo se agrupan en torno a unos pocos patrones que vale la pena nombrar explícitamente.

  • PTX e intrínsecos de bajo nivel. El PTX en línea es el lenguaje ensamblador virtual de Nvidia. Ningún kernel que lo utilice puede ser traducido automáticamente por ninguna de estas herramientas. Se requiere reescritura manual.
  • Bibliotecas sin equivalentes en AMD o Intel. Si tu pipeline depende de una biblioteca CUDA que no tiene contrapartida en ROCm o SYCL, HIPIFY y SYCLomatic no pueden ayudar. Necesitas una biblioteca de reemplazo o una reescritura.
  • Dependencias de frameworks grandes. La cobertura del 60 por ciento de la API de CUDA de SCALE es significativa para cargas de trabajo específicas, pero aún no es suficiente para PyTorch o frameworks similares de stack completo. ROCm es la ruta más madura para esos casos.
  • Kernels CUDA personalizados optimizados para la microarquitectura de Nvidia. Los kernels escritos para aprovechar el comportamiento específico del hardware de Nvidia (tamaños de warp, detalles de la jerarquía de memoria) pueden compilarse en AMD pero rendir mal o producir resultados incorrectos sin ajuste previo.

Qué significa esto para la inferencia en GPU sin Nvidia en Europa

El panorama realista para las empresas europeas en 2026 es el siguiente: si tu carga de trabajo de inferencia corre sobre PyTorch con arquitecturas transformer estándar y no dependes de TensorRT-LLM ni de FlashAttention 3, el hardware AMD Instinct con ROCm es una ruta de producción viable. Los números de MLPerf lo respaldan. Si tu stack es más personalizado, necesitas auditar tus dependencias CUDA con cuidado antes de asumir portabilidad.

La capa de conectividad importa más de lo que podría parecer cuando se mezcla hardware entre proveedores. Operamos 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en todos los sitios. Para los equipos que ejecutan pipelines de inferencia híbridos donde algunas cargas permanecen en capacidad Nvidia de un hyperscaler y otras se mueven a infraestructura GPU alternativa, ese tejido de peering mantiene los caminos de datos cortos y la latencia predecible, algo que importa cuando se orquesta sobre pools de aceleradores heterogéneos.

La pregunta de aprovisionamiento detrás de la técnica

La portabilidad de GPU es en última instancia una cuestión de gestión de riesgos. El vendor lock-in de CUDA es real: la profundidad del ecosistema, la cobertura de bibliotecas y la madurez de las herramientas siguen favoreciendo significativamente a Nvidia. Pero la situación de suministro y la trayectoria de costes significan que tratar a Nvidia como la única ruta viable es en sí mismo un riesgo.

El enfoque pragmático consiste en auditar tus cargas de trabajo frente a la matriz de compatibilidad de ROCm, identificar qué componentes tienen dependencias CUDA duras (kernels PTX, bibliotecas no soportadas, TensorRT-LLM) y separar las cargas que pueden migrarse de las que no. Ejecuta las cargas portables en hardware AMD donde el suministro y el coste lo justifiquen. Mantén las no portables en Nvidia. Construye tu capa de orquestación para tratar los dos pools como intercambiables donde las cargas de trabajo subyacentes realmente lo sean.

Ninguna de las herramientas de portabilidad es mágica. HIPIFY automatiza mucho y aun así requiere revisión manual. SCALE es prometedor pero incompleto. ZLUDA conlleva riesgo legal. Los equipos que naveguen bien esta situación serán los que comiencen con un inventario honesto de sus dependencias CUDA en lugar de asumir portabilidad y descubrir las brechas en producción.