Quien ejecuta modelos de IA en una CPU x86 ha tenido durante años una decisión incómoda al principio de cada proyecto: comprobar qué compilación o qué complemento rendía mejor en su procesador concreto, porque cada fabricante optimizaba por su cuenta. Ese reparto empezó a desmontarse el 20 de octubre de 2026. Intel y AMD anunciaron ese día que unifican su trabajo de optimización para PyTorch dentro de oneDNN, y que AMD entra como miembro del comité directivo de la Fundación UXL, según los comunicados de Intel y de AMD.
La pieza no es menor. oneDNN ejecuta las operaciones matemáticas pesadas que hay debajo de PyTorch, TensorFlow, ONNX Runtime y OpenVINO, y desde 2023 vive bajo el paraguas de la UXL Foundation, la fundación que heredó buena parte de los proyectos oneAPI de Intel. Hasta el anuncio, Intel publicaba sus mejoras en esa librería compartida mientras AMD mantenía ZenDNN, compatible con la misma interfaz y afinada para sus procesadores Zen.
El resultado para quien programa es una sola ruta en lugar de dos, con menos comprobaciones antes de cambiar de procesador. Para el mercado es otra cosa, porque dos rivales pasan a decidir juntos el rumbo de una pieza de la que dependen varios frameworks de uso masivo.
¿Qué se llevan a oneDNN y qué se queda fuera?
Los comunicados eligen el verbo planificar y no el de entregar. Las dos empresas han acordado alinear oneDNN como la librería de código abierto por defecto para acelerar PyTorch en CPU x86, y AMD integrará en ella las optimizaciones que hasta ahora vivían en ZenDNN. La nota de AMD añade que seguirá optimizando para sus propios procesadores, y el acuerdo llega por recomendación del x86 Ecosystem Advisory Group, el foro que ambas presentaron en octubre de 2024 y cuyas notas pública, x86ecosystem.org.
| Pieza |
Qué cambia con el anuncio |
| oneDNN |
Pasa a ser la librería común de aceleración x86 dentro de PyTorch |
| ZenDNN |
AMD integra sus optimizaciones en oneDNN y conserva el ajuste para sus chips |
| ROCm y las GPU |
Fuera del acuerdo, AMD sigue desarrollando su propia pila gráfica |
| ACE |
Extensión de instrucciones prevista, sin fecha de llegada |
La tabla deja dos huecos que conviene nombrar. El primero es la parte gráfica: el anuncio habla de CPU x86 y no toca ROCm, la pila de software de AMD para GPU, que la compañía sigue empujando por su cuenta incluso fuera de Linux, como contamos en FreeBSD porta el software ROCm de AMD para HPC e IA en GPU. El segundo es ACE (AI Compute Extensions), una ampliación del repertorio de instrucciones x86 pensada para multiplicar matrices, la operación que domina el cálculo de una red neuronal; Intel la describe como integración futura mediante actualizaciones de oneDNN.
Ninguno de esos dos huecos tiene fecha. Quien planifica una renovación de servidores a doce meses vista se queda, por ahora, con una promesa de dirección y sin calendario al que agarrarse.
Jeff McVeigh, vicepresidente y director general de programas estratégicos de centro de datos en Intel, resumió el objetivo con una frase que también funciona como diagnóstico del problema anterior: «Los desarrolladores no deberían tener que pensar en rutas de software separadas para sacar lo mejor de una CPU x86». Robert Hormuth, vicepresidente corporativo de arquitectura y estrategia en AMD, puso el acento en la libertad de elección: «AMD impulsa un ecosistema de software abierto que da a los desarrolladores más opciones y facilita crear aplicaciones de IA de alto rendimiento».
ZenDNN deja de ser una bifurcación y pasa a código compartido
ZenDNN es la bifurcación de AMD de oneDNN, compatible con su interfaz y adaptada a los procesadores Zen. La realidad es algo más enrevesada, y el propio repositorio de AMD lo aclara: ZenDNN se reescribió y hoy puede delegar en oneDNN las operaciones que allí están mejor resueltas, así que las dos bibliotecas ya se hablaban antes del anuncio. Para PyTorch, AMD publica además zentorch, un complemento que enchufa ZenDNN al framework y que se instala aparte.
Ahí estaba la factura invisible para cualquier equipo con hardware mixto. Un mismo modelo podía necesitar dos instalaciones distintas, dos baterías de pruebas y dos explicaciones para el equipo de guardia cuando algo se ralentizaba tras una actualización. Unificar el código no elimina ese trabajo de validación, pero lo reduce a una sola ruta y evita que dos grupos de ingenieros arreglen por separado el mismo error en una multiplicación de matrices.
Merece la pena separar dos cosas que el anuncio mezcla. El código compartido ahorra mantenimiento desde el primer día, mientras que la ganancia de rendimiento depende de cuánto se afine cada ruta para un chip concreto. Lo primero es una certeza administrativa; lo segundo, una expectativa.
La palabra que más se repite en las notas es default. oneDNN no será la única opción, pero pasa a ser la que PyTorch elige cuando nadie configura nada, y eso pesa sobre todo en proyectos pequeños que no tocan variables de entorno.
La cuenta de quien paga el hardware
La inferencia en CPU no gana titulares frente a la GPU, pero aguanta la comparación en la factura. Un servidor con muchos núcleos y memoria rápida cuesta menos que un acelerador dedicado, y para modelos pequeños, cargas por lotes o aplicaciones donde la latencia manda, la CPU sigue siendo la opción sensata. Como contamos en nuestro repaso a la IA local en el PC, ese camino tampoco es barato: un equipo preparado para mover modelos en local se movía en torno a los 4.000 euros.
Ahí es donde un camino único cambia la conversación con el proveedor. Si el mismo binario rinde en dos marcas, el comprador recupera la palanca de cambiar de fabricante sin rehacer el despliegue, y los equipos dejan de pagar dos veces por el mismo trabajo. La rebaja no aparece como descuento inmediato en la tienda: aparece en menos horas de integración y en menos sorpresas al renovar el parque de servidores.
Ese ahorro no llega a todo el mundo por igual. Un equipo que sirve modelos con llama.cpp o con vLLM toca otras capas y notará el cambio de forma indirecta, mientras que otro que entrena o ajusta modelos en PyTorch sobre CPU vive de lleno en esta decisión.
Conviene matizar que la IA local no solo mueve librerías: también reordena el reparto de controladores y entornos con que Windows y Linux ejecutan los modelos, una capa que este acuerdo no toca.
Una librería, dos rivales y una fundación en medio
oneDNN no nació en una fundación. Creció dentro de Intel, y hoy vive bajo el paraguas de la UXL Foundation, creada en septiembre de 2023 y operada bajo la Joint Development Foundation dentro de la Linux Foundation, según Crypto Briefing. En el consejo se sientan Intel, Samsung, Qualcomm y Arm, entre otros, y la fundación lista seis librerías heredadas de oneAPI, con oneDNN como la que toca a este artículo según su propio catálogo de proyectos.
La gobernanza es la parte que el anuncio no resuelve del todo. AMD pasa de contribuidor general a miembro del comité directivo, y eso le da voz en la hoja de ruta de una librería que antes mandaba su competidor. El riesgo tiene nombre propio: cuatro frameworks de peso consumen la misma implementación, así que una prioridad mal puesta en oneDNN se propaga a toda la cadena y no hay una segunda opción lista para sustituirla. Stephen Watt, de Red Hat, defendió el acuerdo precisamente por ese lado, como un paso importante para eliminar la fragmentación del ecosistema.
Que dos rivales compartan código no significa que compartan intereses. Cada uno seguirá afinando sus propios núcleos y su propio silicio, y la parte común cubrirá solo lo que ambos consideren rentable, que no siempre coincide con lo que necesita el cliente.
Los usuarios de Arm o RISC-V, que también aparecen en el ámbito de oneDNN, miran desde fuera un pacto entre dos fabricantes x86. La diferencia es importante: el acuerdo baja el coste de entrada y no garantiza que la ruta común sea la más rápida para cada chip en todos los casos.
Lo que el anuncio todavía no firma
Falta lo que un ingeniero mira primero, que es versión y fecha. Los comunicados no dicen qué versión de PyTorch estrenará la ruta común, ni cuándo dejará ZenDNN de tener sentido, ni en qué entrega de oneDNN aparecerá el soporte de ACE. Tampoco aclaran si zentorch seguirá publicándose durante la transición, un detalle que decide si un equipo en producción toca algo este trimestre.
Habrá que esperar a las notas de versión de oneDNN y al repositorio de AMD para saber si el plan se convierte en código que alguien pueda instalar. Mientras tanto, la recomendación práctica es no desmontar la compilación que funciona. El anuncio describe una dirección, y en software la dirección solo cuenta cuando llega a un paquete con número de versión y fecha de descarga.
