IBM Spyre troca o sendnn, compilador próprio, pelo Inductor aberto no torch.compile

O IBM Spyre tem 32 núcleos de aceleração e até 128 GB de memória LPDDR5 em uma única placa PCIe, e agora ganhou outro compilador no PyTorch. O stack de software do Spyre migrou do sendnn, um sistema de compilação separado, escrito do zero, para o backend=inductor. Trata-se do backend aberto do torch.compile, usado por padrão no PyTorch. A mudança foi divulgada pelo PyTorch Blog. Na parte disponível do anúncio, há apenas a afirmação sobre a troca de backend, sem benchmarks; por isso, só dá para avaliar o sentido arquitetural da mudança.

O que mudou, exatamente

Até agora, o caminho de um modelo no Spyre era este: o usuário chamava o torch.compile, o grafo seguia para o sendnn e, dali em diante, tudo ficava a cargo de um compilador da IBM, desconectado do restante do ecossistema PyTorch. Agora o grafo passa pelo Inductor, que cuida da captura do grafo, da decomposição de operadores, do agendamento e da fusão de kernels. Só a extensão conectada ao Inductor cuida das especificidades do Spyre.

Esse é um esquema previsto no Inductor. Ele gera código Triton para GPU e C++ para CPU, e seus pontos de extensão permitem plugar dispositivos de terceiros sem fazer um fork de todo o compilador. O Spyre passa a ser mais um desses dispositivos.

Por que não manter um compilador próprio

Um stack próprio dá controle total, mas sai caro. Cada novidade do PyTorch, de novos operadores a formas dinâmicas e mudanças no AOTAutograd, precisa ser acompanhada manualmente. Modelos recentes quebram a cobertura de operadores, e a equipe atualiza o compilador separadamente para cada arquitetura.

Ao usar o Inductor, a IBM recebe parte desse trabalho de graça:

• decomposições de operadores mantidas pela comunidade PyTorch;
• otimizações gerais de grafo e fusão de operações;
• um caminho único de depuração e profiling, familiar a quem já trabalhou com GPU;
• menos código que a IBM precisa manter por conta própria.

Há também um custo. O Inductor foi projetado em torno de GPUs e CPUs, com seus modelos de memória e paralelismo. O Spyre é diferente: é um acelerador com organização própria de computação e de dados. Parte das otimizações que o sendnn aplicava diretamente ao hardware agora precisa ser expressa por meio das extensões do Inductor, e isso pode ser mais difícil do que parece.

O que se sabe sobre o Spyre

O Spyre nasceu do chip de pesquisa IBM AIU e é voltado para inferência em sistemas corporativos, principalmente mainframes IBM Z e servidores Power. Principais parâmetros, segundo dados públicos da IBM:

• 32 núcleos de aceleração;
• cerca de 25,6 bilhões de transistores, processo de 5 nm;
• até 128 GB de memória LPDDR5 por placa;
• formato PCIe, em torno de 75 W por placa;
• cenário-alvo: inferência de modelos generativos e clássicos dentro do perímetro corporativo.

Há uma lógica clara por trás do acelerador. Bancos e seguradoras querem executar modelos perto dos dados, sem levá-los para a nuvem, e para isso precisam de um stack familiar aos desenvolvedores. A migração para o Inductor aproxima o Spyre justamente desse objetivo.

Na prática

Enquanto não há tabelas públicas de velocidade e de cobertura de operadores, vale avaliar a migração por alguns critérios.

1. Se o seu modelo funciona com backend=inductor no Spyre sem ajustes, e quantas quebras de grafo (graph breaks) restam após a compilação. 2. Como mudou o tempo de compilação em relação ao sendnn, especialmente para LLMs grandes com formas dinâmicas. 3. Se o desempenho nos seus modelos é comparável ao do backend anterior. Se não for, é preciso investigar onde a extensão do Inductor não aproveita os recursos do hardware. 4. Com que rapidez novas versões do PyTorch chegam ao stack. Esse é o principal ganho prático da mudança de arquitetura: quanto menos código próprio, menor o atraso.

Para equipes que planejam inferência em IBM Z ou Power, faz sentido montar logo um conjunto de testes com seus modelos e rodá-lo nos dois backends enquanto o sendnn ainda está disponível para comparação. Se o Inductor der conta do recado sem perda de velocidade, o Spyre terá um motivo a menos para ser diferente dos demais aceleradores no PyTorch.