IBM sprawia, że akcelerator Spyre staje się pełnoprawnym backendem PyTorch

IBM poinformował w wpisie na blogu IBM Research opublikowanym 26 października 2026 r., że aktualizacje oprogramowania udostępnione w ekosystemie PyTorch w drugiej połowie 2026 r. sprawiły, iż akcelerator przepływu danych Spyre stał się pełnoprawnym backendem PyTorch, realizując plan nakreślony przez IBM i PyTorch Foundation w październiku 2025 r.

IBM opisuje Spyre jako swój akcelerator AI oparty na przepływie danych, zoptymalizowany pod kątem wnioskowania i zaprojektowany z myślą o zespołach przedsiębiorstw, które uruchamiają AI obok aplikacji i danych w systemach IBM Z, LinuxONE i Power. Obliczenia o obniżonej precyzji służą do realizacji zadań wymagających intensywnych operacji macierzowych, charakterystycznych dla generowania języka i modeli osadzających. W przeciwieństwie do konwencjonalnego GPU, który wykonuje jądra jako strumienie instrukcji w zaplanowanych grupach wątków, Spyre rozpoczyna obliczenia w miarę napływu danych do jednostek obliczeniowych.

Jak podano we wpisie, w drugiej połowie 2026 r. IBM, Red Hat i współpracownicy z PyTorch Foundation, w tym Meta i Hugging Face, wprowadzili aktualizacje obejmujące obsługę modeli od pierwszego dnia, niezależne od sprzętu modele w vLLM, ciągłe testy regresji i wydań oraz integrację z urządzeniem natywnym. Podczas PyTorch Conference 2025 IBM poinformował w wpisie IBM Research z 21 października 2025 r., że planuje rozszerzyć obsługę Spyre w 2026 r. Spyre miał działać jako pełnoprawny backend w otwartoźródłowych procesach wnioskowania, a prace miały koncentrować się na ujednoliconych ścieżkach kompilacji, optymalizowanym generowaniu jąder i przejrzystym planowaniu zadań dla wielu akceleratorów. Do tego czasu IBM przyjął vLLM jako środowisko uruchomieniowe wnioskowania, a torch.compile jako kompilator front-endowy służący do integracji akceleratorów, takich jak Spyre. Firma udostępniła też wtyczkę Spyre dla vLLM, która umożliwia stosowanie uwagi stronicowanej podczas wnioskowania w dużych modelach językowych.

Kompilator przebudowany na bazie Inductor

Centralnym elementem integracji jest torch-spyre — backend PyTorch, który kompiluje zwykły kod PyTorch do planu wykonywalnego przez Spyre. Większość logiki modelu przechodzi przez kompilator PyTorch bez zmian; jeśli danej operacji nie da się jeszcze skutecznie obniżyć do kodu niższego poziomu, adapter może zastąpić ją matematycznie równoważną postacią, którą kompilator potrafi obsłużyć.

We wpisie PyTorch Foundation opublikowanym 13 października 2026 r. Dave Grove, Olivier Tardieu i IBM Spyre Team opisali przeniesienie backendu torch.compile w torch-spyre z sendnn — stosu kompilacyjnego zbudowanego całkowicie od podstaw — na backend=inductor, otwartoźródłowy backend rozwijany przez rozszerzanie własnego Inductor w PyTorch. Według autorów pomiar za pomocą analizatora kodu lizard wykazał, że sendnn obejmuje łącznie około 273 000 wierszy kodu C++ i Python w 6170 funkcjach, podczas gdy rozszerzenie Inductor liczy około 38 600 wierszy kodu Python w 1878 funkcjach — to około 7 razy mniej wierszy i niższa złożoność poszczególnych funkcji.

Spyre to akcelerator o mocy 75 W, podłączany przez PCIe, zbudowany z 32 niewielkich rdzeni połączonych pierścieniem. Każdy z nich ma własny bufor scratchpad o pojemności 2 MB zamiast współdzielonej pamięci podręcznej, a dane są przesyłane w stałych porcjach po 128 bajtów, nazywanych pałeczkami. Jak podano we wpisie, prace nad kompilatorem koncentrowały się na przesyłaniu danych w porcjach wielkości pałeczki, planowaniu wykorzystania bufora scratchpad i przypisywaniu rdzeni podczas kompilacji.

Wśród zgłoszonych wyników pomiarów znalazło się skrócenie czasu działania jądra matmul o 29–69% dzięki doborowi podziału na kafelki i układu danych, spadek mediany czasu działania jądra softmax z 32,51 do 23,67 mikrosekundy — czyli o 27% — dzięki planowaniu uwzględniającemu bufor scratchpad oraz zespolone jądro w stylu MLP, które zwiększyło wykorzystanie rdzeni z około dwóch trzecich do około 80%, jednocześnie skracając czas działania jądra o około 17%. W syntetycznym grafie zaprojektowanym tak, by uwypuklić wpływ tych decyzji, nowy układ danych w układzie scalonym zastąpił 80-mikrosekundową operację przesłania danych z pamięci urządzenia i z powrotem tasowaniem między rdzeniami trwającym 1,1 mikrosekundy. We wpisie zaznaczono również, że konieczność rejestrowania przez torch-spyre dekompozycji specyficznych dla urządzenia przyczyniła się do ulepszenia obsługi zewnętrznych backendów Inductor. Zmiany te trafiły do głównej gałęzi PyTorch 2.12 w ramach dwóch scalonych pull requestów.

Integracja z natywnym urządzeniem

Spyre staje się natywnym urządzeniem PyTorch dzięki rejestracji PrivateUse1, która nadaje tensor.to(“spyre”) rzeczywistą tożsamość urządzenia: pamięć przydzielana przez alokator PyTorch pozwala przechowywać tensory na urządzeniu, strumienie zapewniają semantykę porządkowania, a zdarzenia środowiska uruchomieniowego łączą zależne zadania wykonywane w różnych strumieniach. Karta zawiera 32 rdzenie połączone pierścieniem o dużej przepustowości, każdy z lokalnym buforem scratchpad o pojemności 2 MB, oraz do 128 GB pamięci LPDDR5 na tensory i programy. Obecne środowisko uruchomieniowe modyfikuje programy podczas ich uruchamiania, zastępując symboliczne adresy tensorów rzeczywistymi w trzech uporządkowanych krokach.

Zespół poinformował, że w demonstracji z modelem Granite 3.3 8B, przy rozmiarze partii 1 i długości sekwencji 1024, przeniesienie budowania grafu poza ścieżkę przesyłania danych przyspieszyło fazę prefill o 9,9%, a fazę dekodowania o 13,6%. Po usunięciu tych operacji również ze ścieżki wysyłania zadań do obliczeń łączne przyspieszenie wyniosło 1,7x dla fazy prefill i 2,4x dla fazy dekodowania, przy czym około trzy czwarte poprawy wynikało ze ścieżki obliczeniowej.

„Zaletą jest to, że ani Spyre, ani PyTorch nie muszą udawać czegoś, czym nie są” — napisali autorzy w artykule Budowanie Spyre jako natywnego urządzenia PyTorch, opublikowanym 8 października 2026 r. Dodali, że Spyre zachowuje swój model wykonywania oparty na przepływie danych, a użytkownicy otrzymują natywne urządzenie PyTorch z dobrze znanymi sposobami rozmieszczania tensorów, strumieniami i kompilacją.

Przenośność vLLM i połączenie z Llm-D

Spyre jest akceleratorem spoza głównego drzewa, a nie jedną z platform GPU najczęściej obsługiwanych przez oprogramowanie AI. Do śledzenia grafu modelu wykorzystuje TorchDynamo, a do przekształcania go na potrzeby docelowego sprzętu — TorchInductor. W vLLM mechanizmy rozszerzeń, takie jak CustomOp i PluggableLayer, pozwalają wtyczce sprzętowej dostosować działanie bez konieczności ponownego implementowania dużej części stosu oprogramowania.

W publikacji Modele vLLM niezależne od sprzętu, opublikowanej 22 września 2026 r. przez autorów z IBM, Meta i Hugging Face, zespół opisał przejście vLLM w kierunku specyficznych dla sprzętu „płaskich” definicji modeli oraz przedstawił warstwy niezależne od sprzętu, oparte na czterech zasadach projektowych: możliwości kompilacji, rozszerzalności, odseparowaniu od ścieżek specyficznych dla sprzętu i przenośności. Wstępna obsługa jest już dostępna w głównej gałęzi vLLM i można ją włączyć za pomocą USE_HW_AGNOSTIC=1 w zapleczu transformers. Ścieżkę tę zweryfikowano przy użyciu wtyczki Spyre spoza głównego drzewa na modelach takich jak Gemma 4, Qwen3 i Granite 4.2. Jak podali autorzy, na procesorach graficznych NVIDIA H100 warstwy niezależne od sprzętu zapewniły całkowitą przepustowość tokenów mieszczącą się w granicach 3,4% wyniku natywnej implementacji; pomiar ten stanowił średnią geometryczną dla trzech niedawnych modeli.

Jak wyjaśniono w publikacji IBM, integracja Spyre z PyTorch umożliwia również połączenie z llm-d: llm-d prowadzi rozproszone wnioskowanie w oparciu o vLLM na wielu typach akceleratorów, vLLM komunikuje się z każdym akceleratorem za pośrednictwem PyTorch, a gdy urządzenie ma już działające zaplecze PyTorch, wtyczka sprzętowa vLLM może je udostępnić, dzięki czemu llm-d może kierować na nie zadania.

Obsługa od pierwszego dnia i ciągłe testowanie

W wpisie z 20 sierpnia 2026 r. zespół IBM Spyre opisuje HF-adapters — projekt, w którym agenty programistyczne tworzą szkice poprawek środowiska uruchomieniowego, umożliwiających uruchamianie na Spyre standardowych modeli Hugging Face Transformers. Jak podano we wpisie, od połowy kwietnia do końca czerwca 2026 r. 13 różnych adapterów objęło 7960 z 10 000 najczęściej pobieranych modeli embeddingowych Hugging Face, z których 6804 przeszły na Spyre test kompleksowy. W jednym z przykładów funkcję aktywacji gelu_new zastąpiono wyrażeniem torch.pow(x, 3.0) przez matematycznie równoważne x x x, które stos technologiczny torch-spyre potrafi skompilować; ludzie nadal zajmują się diagnozowaniem problemów, lokalizując awarie występujące wyłącznie na urządzeniu, spowodowane operacjami łączonymi, oraz weryfikując wnioski każdego agenta na podstawie wyników testów kompleksowych.

We wpisie z 30 września 2026 r. inżynierowie IBM i Red Hat opisali integrację L2 środowiska torch-spyre z Cross-Repository CI Relay PyTorch. Integracja ta uruchamia testy w dalszych projektach po zmianach w nadrzędnym repozytorium PyTorch i przesyła wyniki z powrotem do panelu CI PyTorch. Łączy ona czteroetapowy, oparty na agentach potok doboru testów z deklaratywnym mechanizmem ponownego wykorzystywania testów opartym na YAML. Jak napisali autorzy, aktualizacja z PyTorch 2.13 do 2.14 oznaczała konieczność oceny około 4000 zmienionych testów zamiast dziesiątek tysięcy; dodali, że zamierzają współpracować z zespołem PyTorch nad przeniesieniem do głównego projektu elementów wielokrotnego użytku, wykorzystując PyTorch OpenReg jako punkt odniesienia.

Jak napisano w publikacji IBM, użytkownicy IBM Z, LinuxONE i Power11 mają móc pobierać modele z ekosystemów takich jak Hugging Face i korzystać z praktycznie tych samych przepływów pracy opartych na PyTorch, co w przypadku procesorów graficznych Nvidia. Wspólne punkty rozszerzeń PyTorch mają ukrywać znaczną część różnic architektonicznych. Autorzy wpisu o vLLM poinformowali, że planują zacząć uwzględniać modele niezależne od sprzętu w CI i stopniowo przechodzić na tę ścieżkę jako domyślną metodę obsługi modeli na Spyre.