IBM convierte el acelerador Spyre en un backend de PyTorch de primera clase

IBM afirmó en una entrada del blog de IBM Research publicada el 26 de octubre de 2026 que las actualizaciones de software implementadas en todo el ecosistema de PyTorch durante la segunda mitad de 2026 han convertido su acelerador de flujo de datos Spyre en un backend de PyTorch de primera clase, cumpliendo así el plan que IBM y la PyTorch Foundation expusieron en octubre de 2025.

IBM describe Spyre como su acelerador de IA de flujo de datos, optimizado para la inferencia y diseñado para equipos empresariales que ejecutan aplicaciones de IA junto con sus aplicaciones y datos en sistemas IBM Z, LinuxONE y Power. Su capacidad de cálculo de precisión reducida está orientada a las operaciones intensivas en matrices propias de la generación de lenguaje y los modelos de incrustaciones. A diferencia de una GPU convencional, que ejecuta núcleos como flujos de instrucciones en grupos de subprocesos programados, Spyre activa los cálculos a medida que los datos llegan a sus motores de cálculo.

Durante la segunda mitad de 2026, IBM, Red Hat y colaboradores de la PyTorch Foundation, entre ellos Meta y Hugging Face, publicaron actualizaciones que abarcan la habilitación de modelos desde el primer día, modelos independientes del hardware en vLLM, pruebas continuas de regresión y lanzamiento, e integración como dispositivo nativo, señala la entrada. En la PyTorch Conference 2025, en una publicación de IBM Research fechada el 21 de octubre de 2025, IBM dijo que planeaba ampliar la compatibilidad con Spyre en 2026, con el objetivo de que Spyre participara como backend de primera clase en flujos de trabajo de inferencia de código abierto y centrando sus esfuerzos en vías de compilación unificadas, generación optimizada de núcleos y programación transparente de varios aceleradores. Para entonces, IBM había adoptado vLLM como entorno de ejecución de inferencia y torch.compile como compilador de frontend para integrar aceleradores como Spyre, y había contribuido un complemento de Spyre para vLLM que habilita la atención paginada para la inferencia de modelos de lenguaje grandes.

Un compilador reconstruido sobre Inductor

En el centro de la integración está torch-spyre, un backend de PyTorch que compila código PyTorch convencional en un plan ejecutable para Spyre. La mayor parte de la lógica de un modelo pasa sin cambios por el compilador de PyTorch; cuando una operación todavía no se puede traducir de forma eficaz, un adaptador puede sustituirla por una forma matemáticamente equivalente que el compilador pueda procesar.

En una publicación de PyTorch Foundation publicada el 13 de octubre de 2026, Dave Grove, Olivier Tardieu y el equipo de IBM Spyre describieron cómo trasladaron el backend torch.compile de torch-spyre de sendnn —una pila de compilación creada íntegramente desde cero— a backend=inductor, un backend de código abierto desarrollado mediante la ampliación del propio Inductor de PyTorch. Según los autores, las mediciones realizadas con el analizador de código lizard indican que sendnn suma aproximadamente 273.000 líneas de C++ y Python distribuidas en 6.170 funciones, mientras que la extensión de Inductor comprende unas 38.600 líneas de Python distribuidas en 1.878 funciones: alrededor de 7 veces menos líneas y una complejidad menor por función.

Spyre es un acelerador de 75 vatios conectado mediante PCIe, compuesto por 32 núcleos pequeños conectados en anillo. Cada uno tiene una memoria scratchpad de 2 MB propia, en lugar de una caché compartida, y los datos se transfieren en bloques fijos de 128 bytes llamados «sticks». Según la publicación, el trabajo en el compilador se centró en el movimiento de datos en unidades del tamaño de un stick, la planificación de la memoria scratchpad y la asignación de núcleos durante la compilación.

Entre las mediciones comunicadas figuran una reducción del 29–69 % del tiempo de ejecución de los núcleos de multiplicación de matrices gracias a las decisiones sobre el particionado en bloques y la disposición de los datos; una disminución del tiempo mediano de ejecución de los núcleos de softmax, de 32,51 microsegundos a 23,67 microsegundos —una reducción del 27 %—, gracias a una planificación que tiene en cuenta la memoria scratchpad; y un núcleo fusionado de tipo MLP que elevó la utilización de los núcleos de aproximadamente dos tercios a cerca del 80 %, a la vez que redujo el tiempo de ejecución de los núcleos alrededor de un 17 %. En un grafo sintético diseñado para poner a prueba esas decisiones, una nueva reorganización de datos en el chip sustituyó un viaje de ida y vuelta de 80 microsegundos a la memoria del dispositivo por una redistribución entre núcleos de 1,1 microsegundos. La publicación también señala que la necesidad de torch-spyre de registrar descomposiciones específicas del dispositivo contribuyó a impulsar mejoras en la compatibilidad con backends de Inductor externos al árbol de código, que se incorporaron a PyTorch 2.12 mediante dos solicitudes de incorporación de cambios fusionadas.

Integración como dispositivo nativo

Spyre se convierte en un dispositivo nativo de PyTorch mediante el registro PrivateUse1, que asigna una identidad de dispositivo real a tensor.to(“spyre”): el almacenamiento del asignador de PyTorch mantiene los tensores en el dispositivo, los flujos proporcionan semántica de ordenación y los eventos del entorno de ejecución conectan el trabajo dependiente entre flujos. La tarjeta cuenta con 32 núcleos conectados mediante un anillo de gran ancho de banda, cada uno con 2 MB de memoria scratchpad local, y hasta 128 GB de LPDDR5 para tensores y programas. El entorno de ejecución actual aplica parches a los programas al iniciarlos y sustituye las direcciones simbólicas de los tensores por direcciones reales en tres pasos ordenados.

En una demostración con Granite 3.3 8B, un tamaño de lote de 1 y una longitud de secuencia de 1024, trasladar la construcción del grafo fuera de la ruta de transferencia de datos mejoró el prellenado un 9,9 % y la decodificación un 13,6 %, informó el equipo. Al retirar también ese trabajo del envío de cálculos, las mejoras totales llegaron a 1,7 veces más velocidad en el prellenado y 2,4 veces más velocidad en la decodificación; aproximadamente tres cuartas partes de la mejora procedieron de la ruta de cálculo.

«La ventaja es que ni Spyre ni PyTorch tienen que fingir ser otra cosa», escribieron los autores en Crear Spyre como dispositivo nativo de PyTorch, publicado el 8 de octubre de 2026. Añadieron que Spyre conserva su modelo de ejecución de flujo de datos, mientras que los usuarios disponen de un dispositivo nativo de PyTorch con una gestión familiar de la ubicación de los tensores, los flujos y la compilación.

Portabilidad de vLLM y conexión con Llm-D

Spyre es un acelerador externo al árbol de código, en lugar de una de las plataformas de GPU más compatibles con el software de IA. Se apoya en TorchDynamo para trazar el grafo del modelo y en TorchInductor para generar código de nivel inferior a partir de ese grafo para el hardware de destino. En vLLM, mecanismos de extensión como CustomOp y PluggableLayer permiten que un complemento de hardware personalice el comportamiento sin tener que volver a implementar grandes partes de la pila de software.

En Modelos independientes del hardware en vLLM, publicado el 22 de septiembre de 2026 por autores de IBM, Meta y Hugging Face, el equipo describió el giro de vLLM hacia definiciones de modelos «planas» específicas para cada hardware y presentó capas independientes del hardware basadas en cuatro principios de diseño: compilables, extensibles, aisladas de las rutas específicas del hardware y portátiles. Ya hay compatibilidad inicial en la rama principal de vLLM, que puede habilitarse con USE_HW_AGNOSTIC=1 en el backend de Transformers. La ruta se validó con el complemento externo de Spyre en modelos como Gemma 4, Qwen3 y Granite 4.2; según informaron los autores, en las GPU NVIDIA H100 las capas independientes del hardware alcanzaron un rendimiento total de generación de tokens que quedó dentro de un margen del 3,4 % respecto de la implementación nativa, medido como la media geométrica de tres modelos recientes.

La integración de Spyre con PyTorch también es la forma en que se conecta con llm-d, explica la publicación de IBM: llm-d ejecuta inferencias distribuidas sobre vLLM en varios tipos de aceleradores; vLLM accede a cada acelerador a través de PyTorch; y, una vez que un dispositivo cuenta con un backend funcional de PyTorch, un complemento de hardware de vLLM puede exponerlo para que llm-d programe tareas en él.

Habilitación desde el primer día y pruebas continuas

Una publicación del 20 de agosto de 2026 del equipo IBM Spyre describe HF-adapters, un proyecto que utiliza agentes de programación para redactar parches en tiempo de ejecución que permiten ejecutar en Spyre modelos estándar de Hugging Face Transformers. Entre mediados de abril y finales de junio de 2026, 13 adaptadores distintos llegaron a cubrir 7.960 de los 10.000 modelos de incrustaciones de Hugging Face con más descargas; de estos, 6.804 superaron su prueba integral en Spyre, según la publicación. Un ejemplo reemplaza torch.pow(x, 3.0) de la función de activación gelu_new por la expresión matemáticamente idéntica x x x, que la pila torch-spyre puede compilar a código de nivel inferior; las personas siguen encargándose del diagnóstico, localizan los fallos que se producen únicamente en el dispositivo debido a operaciones fusionadas y contrastan las conclusiones de cada agente con los resultados integrales.

En una publicación del 30 de septiembre de 2026, ingenieros de IBM y Red Hat describieron la integración L2 de torch-spyre con Cross-Repository CI Relay de PyTorch, que activa pruebas posteriores ante cambios en PyTorch y comunica los resultados al panel de CI de PyTorch. La integración combina una canalización de selección de pruebas de cuatro etapas basada en agentes con un marco declarativo de reutilización de pruebas en YAML. Los autores escribieron que, al actualizar de PyTorch 2.13 a 2.14, fue necesario evaluar aproximadamente 4.000 pruebas modificadas, en lugar de decenas de miles; añadieron que tienen previsto colaborar con el equipo de PyTorch para incorporar al proyecto las partes reutilizables, tomando PyTorch OpenReg como referencia.

Para los usuarios de IBM Z, LinuxONE y Power11, la experiencia prevista consiste en obtener modelos de ecosistemas como Hugging Face y utilizar flujos de trabajo basados en PyTorch prácticamente iguales a los que usarían con GPU Nvidia; las extensiones compartidas de PyTorch ocultan buena parte de las diferencias arquitectónicas, señala la publicación de IBM. Los autores de la publicación sobre vLLM dijeron que planean empezar a incluir modelos independientes del hardware en CI y pasar gradualmente a esa ruta como opción predeterminada para servir modelos en Spyre.