IBM transforma o acelerador Spyre em um backend PyTorch de primeira classe

Em uma publicação no blog do IBM Research, divulgada em 26 de outubro de 2026, a IBM afirmou que as atualizações de software implementadas em todo o ecossistema PyTorch no segundo semestre de 2026 tornaram seu acelerador de fluxo de dados Spyre um backend PyTorch de primeira classe, concretizando um plano que a IBM e a PyTorch Foundation haviam delineado em outubro de 2025.

A IBM descreve o Spyre como seu acelerador de IA de fluxo de dados, otimizado para inferência e projetado para equipes corporativas que executam IA junto com seus aplicativos e dados em sistemas IBM Z, LinuxONE e Power. Seu processamento de precisão reduzida é voltado para as operações com matrizes, predominantes em modelos de geração de linguagem e de embeddings. Diferentemente de uma GPU convencional, que executa kernels como fluxos de instruções distribuídos por grupos de threads agendados, o Spyre inicia a computação à medida que os dados chegam aos seus mecanismos de processamento.

No segundo semestre de 2026, a IBM, a Red Hat e colaboradores da PyTorch Foundation, incluindo a Meta e a Hugging Face, disponibilizaram atualizações que abrangem a habilitação de modelos desde o primeiro dia, modelos independentes de hardware no vLLM, testes contínuos de regressão e de versões e integração como dispositivo nativo, afirma a publicação. Na PyTorch Conference 2025, em uma publicação do IBM Research datada de 21 de outubro de 2025, a IBM afirmou que planejava ampliar a habilitação do Spyre em 2026, com a participação do Spyre como backend de primeira classe em fluxos de trabalho de inferência de código aberto e foco em caminhos de compilação unificados, geração otimizada de kernels e agendamento transparente de múltiplos aceleradores. Até então, a IBM havia adotado o vLLM como ambiente de execução para inferência e o torch.compile como compilador de front-end para integrar aceleradores como o Spyre, além de ter contribuído com um plug-in do Spyre para o vLLM que habilita a atenção paginada para inferência de modelos de linguagem de grande porte.

Um compilador reconstruído sobre o Inductor

No centro da integração está o torch-spyre, um backend PyTorch que compila código PyTorch comum em um plano executável para o Spyre. A maior parte da lógica de um modelo passa pelo compilador PyTorch sem alterações; quando uma operação ainda não pode ser convertida de forma eficaz para o hardware, um adaptador pode substituí-la por uma forma matematicamente equivalente que o compilador consiga processar.

Em uma publicação da PyTorch Foundation divulgada em 13 de outubro de 2026, Dave Grove, Olivier Tardieu e a equipe IBM Spyre descreveram a migração do backend torch.compile do torch-spyre: do sendnn, uma pilha de compilação construída inteiramente do zero, para backend=inductor, um backend de código aberto criado com a extensão do próprio Inductor do PyTorch. De acordo com os autores, a análise com o analisador de código lizard contabilizou cerca de 273.000 linhas de C++ e Python distribuídas por 6.170 funções no sendnn, enquanto a extensão do Inductor tem cerca de 38.600 linhas de Python distribuídas por 1.878 funções — aproximadamente 7 vezes menos linhas e menor complexidade por função.

O Spyre é um acelerador de 75 watts conectado por PCIe, composto por 32 pequenos núcleos interligados em anel. Cada núcleo tem uma memória scratchpad própria de 2 MB, em vez de compartilhar um cache, e os dados são transferidos em blocos fixos de 128 bytes chamados sticks. Segundo a publicação, o trabalho no compilador concentrou-se na movimentação de dados em granularidade de stick, no planejamento da memória scratchpad e na atribuição de núcleos em tempo de compilação.

Entre as medições relatadas estão uma redução de 29–69% no tempo do kernel matmul com escolhas de divisão em blocos e de layout; uma queda no tempo mediano do kernel softmax, de 32,51 microssegundos para 23,67 microssegundos — redução de 27% — graças ao agendamento atento à memória scratchpad; e um kernel fundido no estilo MLP que elevou a utilização dos núcleos de cerca de dois terços para aproximadamente 80%, reduzindo o tempo do kernel em torno de 17%. Em um grafo sintético criado para testar essas decisões, uma nova reorganização de dados no chip substituiu uma ida e volta de 80 microssegundos à memória do dispositivo por uma troca de dados entre núcleos de 1,1 microssegundo. A publicação também observa que a necessidade do torch-spyre de registrar decomposições específicas do dispositivo ajudou a impulsionar melhorias no suporte a backends Inductor externos ao repositório, incorporadas ao PyTorch 2.12 por meio de duas solicitações de pull aceitas.

Integração como dispositivo nativo

O Spyre passa a ser um dispositivo PyTorch nativo por meio do registro PrivateUse1, que atribui ao tensor.to(“spyre”) uma identidade real de dispositivo: o armazenamento do alocador do PyTorch mantém os tensores residentes no dispositivo, os fluxos fornecem semântica de ordenação e os eventos do ambiente de execução conectam operações dependentes entre fluxos. A placa reúne 32 núcleos conectados por um anel de alta largura de banda, cada um com 2 MB de memória scratchpad local, e até 128 GB de LPDDR5 para tensores e programas. No ambiente de execução atual, os programas são ajustados no momento do lançamento, substituindo endereços simbólicos de tensores por endereços reais em três etapas ordenadas.

Em uma demonstração com o Granite 3.3 8B, tamanho de lote 1 e comprimento de sequência 1024, transferir a construção do grafo para fora do caminho de transferência de dados melhorou o prefill em 9,9% e a decodificação em 13,6%, relatou a equipe. Ao remover essa tarefa também do despacho de computação, os ganhos totais chegaram a 1,7x mais velocidade no prefill e 2,4x na decodificação, com cerca de três quartos do ganho provenientes do caminho de computação.

“A vantagem é que nem o Spyre nem o PyTorch precisam fingir ser outra coisa”, escreveram os autores em Construindo o Spyre como um dispositivo PyTorch nativo, publicado em 8 de outubro de 2026. Eles acrescentaram que o Spyre mantém seu modelo de execução de fluxo de dados, enquanto os usuários dispõem de um dispositivo PyTorch nativo com posicionamento de tensores, fluxos e compilação familiares.

Portabilidade do vLLM e a conexão com o Llm-D

O Spyre é um acelerador externo à árvore principal, e não uma das plataformas de GPU mais comumente compatíveis com software de IA. Ele depende do TorchDynamo para rastrear o grafo de um modelo e do TorchInductor para compilar esse grafo para o hardware de destino. No vLLM, mecanismos de extensão como CustomOp e PluggableLayer permitem que um plug-in de hardware personalize o comportamento sem reimplementar grandes partes da pilha de software.

Em Modelos independentes de hardware no vLLM, publicado em 22 de setembro de 2026 por autores da IBM, da Meta e da Hugging Face, a equipe descreveu a mudança do vLLM em direção a definições de modelos «planas», específicas para cada hardware, e apresentou camadas independentes de hardware, baseadas em quatro princípios de projeto: capacidade de compilação, extensibilidade, isolamento de caminhos específicos de hardware e portabilidade. O suporte inicial já foi incorporado à ramificação principal do vLLM e pode ser ativado com USE_HW_AGNOSTIC=1 no back-end do Transformers. O caminho foi validado com o plug-in externo Spyre em modelos como Gemma 4, Qwen3 e Granite 4.2; nas GPUs NVIDIA H100, as camadas independentes de hardware alcançaram uma taxa de processamento total de tokens dentro de 3,4% da implementação nativa, medida pela média geométrica de três modelos recentes, informaram os autores.

A integração do Spyre com o PyTorch também é a forma como ele se conecta ao llm-d, explica a publicação da IBM: o llm-d executa inferência distribuída sobre o vLLM em vários tipos de aceleradores; o vLLM acessa cada acelerador por meio do PyTorch; e, quando um dispositivo dispõe de um back-end funcional para PyTorch, um plug-in de hardware do vLLM pode expô-lo para que o llm-d agende tarefas nesse dispositivo.

Ativação desde o primeiro dia e testes contínuos

Uma publicação de 20 de agosto de 2026 da equipe IBM Spyre descreve o HF-adapters, um projeto que usa agentes de programação para elaborar correções em tempo de execução que permitem executar no Spyre modelos padrão do Hugging Face Transformers. De meados de abril ao fim de junho de 2026, 13 adaptadores distintos passaram a abranger 7.960 dos 10.000 modelos de incorporação mais baixados do Hugging Face; desses, 6.804 são aprovados no teste de ponta a ponta no Spyre, informa a publicação. Um exemplo substitui torch.pow(x, 3.0), na ativação gelu_new, por x x x, expressão matematicamente equivalente que a pilha torch-spyre consegue compilar; as pessoas continuam responsáveis pelo diagnóstico, identificando falhas que ocorrem apenas no dispositivo e são causadas por operações fundidas, e conferindo as conclusões de cada agente com os resultados de ponta a ponta.

Em uma publicação de 30 de setembro de 2026, engenheiros da IBM e da Red Hat descreveram a integração L2 do torch-spyre com o Cross-Repository CI Relay do PyTorch, que aciona testes em projetos dependentes quando há alterações no PyTorch e envia os resultados de volta ao painel de CI do PyTorch. A integração combina um fluxo de seleção de testes em quatro etapas, baseado em agentes, com uma estrutura declarativa em YAML para reutilizar testes. Segundo os autores, a atualização do PyTorch 2.13 para o 2.14 exigiu avaliar cerca de 4.000 testes alterados, em vez de dezenas de milhares; eles acrescentaram que pretendem trabalhar com a equipe do PyTorch para incorporar ao projeto principal as partes reutilizáveis, usando o PyTorch OpenReg como referência.

Para quem usa IBM Z, LinuxONE e Power11, a experiência pretendida é obter modelos de ecossistemas como o Hugging Face e usar fluxos de trabalho baseados no PyTorch praticamente iguais aos que usariam com GPUs Nvidia. Os pontos de extensão compartilhados do PyTorch ocultam grande parte das diferenças arquitetônicas, afirma a publicação da IBM. Os autores da publicação sobre o vLLM disseram que planejam começar a incluir modelos independentes de hardware na CI e migrar gradualmente para esse caminho como padrão para disponibilizar modelos no Spyre.