IBM Spyre sustituye sendnn, su compilador propio, por el Inductor de código abierto en torch.compile

IBM Spyre tiene 32 núcleos aceleradores y hasta 128 GB de memoria LPDDR5 en una sola tarjeta PCIe, y ahora usa otro compilador en PyTorch. El stack de software de Spyre ha pasado de sendnn, un sistema de compilación independiente escrito desde cero, a backend=inductor. Se trata del backend abierto de torch.compile que PyTorch utiliza por defecto. Lo ha informado el blog de PyTorch. En la parte disponible del anuncio solo aparece la tesis del cambio de backend, sin benchmarks, así que lo único que se puede valorar es el sentido arquitectónico de la decisión.

Qué ha cambiado exactamente

Hasta ahora, el recorrido de un modelo en Spyre era este: el usuario llamaba a torch.compile, el grafo pasaba a sendnn y, a partir de ahí, decidía todo el compilador de IBM, desligado del resto del ecosistema de PyTorch. Ahora el grafo pasa por Inductor, que se encarga de la captura del grafo, la descomposición de operadores, la planificación y la fusión de kernels. De lo específico de Spyre solo se ocupa una extensión conectada a Inductor.

Este esquema es el habitual en Inductor. Genera código Triton para GPU y C++ para CPU, y sus puntos de extensión permiten conectar dispositivos de terceros sin hacer un fork de todo el compilador. Spyre pasa a ser un dispositivo más de este tipo.

Por qué no un compilador propio

Un stack propio ofrece control total, pero sale caro. Cada novedad de PyTorch, desde nuevos operadores hasta formas dinámicas y cambios en AOTAutograd, hay que alcanzarla a mano. Los modelos recientes rompen la cobertura de operadores, y el equipo tiene que actualizar el compilador para cada arquitectura por separado.

Al usar Inductor, IBM obtiene parte de ese trabajo sin coste:

• decomposiciones de operadores que mantiene la comunidad de PyTorch;
• optimizaciones generales del grafo y fusión de operaciones;
• una vía unificada de depuración y profiling, familiar para los desarrolladores que ya han trabajado con GPU;
• menos código que IBM tiene que mantener por su cuenta.

También hay un precio. Inductor se diseñó en torno a GPU y CPU, con sus modelos de memoria y paralelismo. Spyre es distinto: es un acelerador con su propia organización del cálculo y de los datos. Parte de las optimizaciones que sendnn hacía directamente para el hardware ahora deben expresarse mediante extensiones de Inductor, y eso puede resultar más complicado de lo que suena.

Qué se sabe de Spyre

Spyre nació del chip de investigación IBM AIU y está orientado a la inferencia en sistemas corporativos, sobre todo en mainframes IBM Z y servidores Power. Estos son sus parámetros clave según los datos públicos de IBM:

• 32 núcleos aceleradores;
• unos 25,6 mil millones de transistores, proceso de fabricación de 5 nm;
• hasta 128 GB de memoria LPDDR5 por tarjeta;
• formato PCIe, en torno a 75 W por tarjeta;
• escenario objetivo: inferencia de modelos generativos y clásicos dentro del perímetro corporativo.

Detrás del acelerador hay una lógica clara. Bancos y aseguradoras quieren ejecutar modelos cerca de los datos, sin sacarlos a la nube, y para eso necesitan un stack que los desarrolladores ya conozcan. El paso a Inductor acerca a Spyre justamente a ese objetivo.

En la práctica

Mientras no haya tablas públicas de velocidad ni de cobertura de operadores, conviene evaluar la migración con varios criterios:

1. Si su modelo funciona con backend=inductor en Spyre sin modificaciones, y cuántas roturas de grafo quedan tras la compilación. 2. Cómo ha cambiado el tiempo de compilación respecto a sendnn, sobre todo en LLM grandes con formas dinámicas. 3. Si el rendimiento en sus modelos es comparable al del backend anterior. Si no lo es, hay que revisar dónde la extensión de Inductor no aprovecha las capacidades del hardware. 4. Con qué rapidez aparecen en el stack las nuevas versiones de PyTorch. Es la principal ventaja práctica del cambio de arquitectura: cuanto menos código propio, menor es el retraso.

A los equipos que planeen hacer inferencia en IBM Z o Power les conviene reunir desde ya un conjunto de pruebas con sus modelos y ejecutarlo en ambos backends mientras sendnn siga disponible para comparar. Si Inductor se las arregla sin perder velocidad, Spyre tendrá un motivo menos para diferenciarse del resto de aceleradores en PyTorch.