IBM transformă acceleratorul Spyre într-un backend PyTorch de prim rang

IBM a declarat într-o postare pe blogul IBM Research, publicată la 26 octombrie 2026, că actualizările software lansate în ecosistemul PyTorch în a doua jumătate a anului 2026 au transformat acceleratorul său de tip flux de date Spyre într-un backend PyTorch de prim rang, îndeplinind planul prezentat de IBM și PyTorch Foundation în octombrie 2025.

IBM descrie Spyre drept acceleratorul său de inteligență artificială de tip flux de date, optimizat pentru inferență și conceput pentru echipele de întreprindere care rulează aplicații de inteligență artificială alături de aplicațiile și datele lor pe sisteme IBM Z, LinuxONE și Power. Capacitatea sa de calcul cu precizie redusă vizează operațiile intensive în matrici din generarea de limbaj și modelele de încorporare, iar, spre deosebire de un GPU convențional, care execută nuclee de calcul sub formă de fluxuri de instrucțiuni în grupuri de fire de execuție programate, Spyre declanșează calculele pe măsură ce datele ajung la motoarele sale de calcul.

În a doua jumătate a anului 2026, IBM, Red Hat și colaboratorii din PyTorch Foundation, inclusiv Meta și Hugging Face, au lansat actualizări care acoperă activarea modelelor încă din prima zi, modele independente de hardware în vLLM, testarea continuă a regresiilor și a versiunilor, precum și integrarea ca dispozitiv nativ, se arată în postare. La PyTorch Conference 2025, într-o postare IBM Research din 21 octombrie 2025, IBM a declarat că plănuia să aprofundeze integrarea Spyre în 2026, astfel încât Spyre să participe ca backend de prim rang în fluxurile de lucru open-source pentru inferență, cu accent pe căi unificate pentru compilator, generarea optimizată a nucleelor de calcul și programarea transparentă a mai multor acceleratoare. Până atunci, IBM adoptase vLLM ca mediu de execuție pentru inferență și torch.compile ca compilator de front-end pentru integrarea acceleratoarelor precum Spyre și contribuise la un plug-in Spyre pentru vLLM, care permite mecanismul de atenție paginată pentru inferența modelelor lingvistice mari.

Un compilator reconstruit pe baza Inductor

În centrul integrării se află torch-spyre, un backend PyTorch care compilează codul PyTorch obișnuit într-un plan executabil pentru Spyre. Cea mai mare parte a logicii unui model trece neschimbată prin compilatorul PyTorch; atunci când o operație nu poate fi încă transpusă eficient în cod de nivel inferior, un adaptor o poate înlocui cu o formă echivalentă din punct de vedere matematic, pe care compilatorul o poate procesa.

Într-o postare a PyTorch Foundation, publicată la 13 octombrie 2026, Dave Grove, Olivier Tardieu și echipa IBM Spyre au descris trecerea backendului torch.compile din torch-spyre de la sendnn, o stivă de compilare construită integral de la zero, la backend=inductor, un backend open-source creat prin extinderea propriului Inductor al PyTorch. Potrivit autorilor, analiza efectuată cu analizorul de cod lizard arată că sendnn cuprinde aproximativ 273.000 de linii de cod C++ și Python în 6.170 de funcții, în timp ce extensia Inductor are aproximativ 38.600 de linii de cod Python în 1.878 de funcții — de circa 7 ori mai puține linii, cu o complexitate mai redusă pentru fiecare funcție.

Spyre este un accelerator de 75 de wați, conectat prin PCIe, alcătuit din 32 de nuclee mici interconectate printr-o topologie în inel; fiecare are o memorie scratchpad proprie de 2 MB, în locul unei memorii cache partajate. Dispozitivul transferă date în blocuri fixe de 128 de octeți, numite stick-uri. Activitatea de compilare s-a concentrat pe transferul datelor la nivel de stick, planificarea memoriei scratchpad și alocarea nucleelor în timpul compilării, se arată în postare.

Măsurătorile raportate includ o reducere cu 29–69% a timpului de execuție al nucleelor de înmulțire matricială, obținută prin alegeri privind împărțirea în blocuri și organizarea datelor; scăderea timpului median de execuție al nucleului softmax de la 32,51 microsecunde la 23,67 microsecunde — o reducere de 27% — datorită planificării care ține cont de memoria scratchpad; și un nucleu de calcul de tip MLP, cu operații combinate, care a crescut gradul de utilizare a nucleelor de la aproximativ două treimi la circa 80%, reducând totodată timpul de execuție al nucleului cu aproximativ 17%. Într-un graf sintetic conceput pentru a testa aceste decizii, o nouă rearanjare a datelor pe cip a înlocuit un transfer dus-întors de 80 de microsecunde prin memoria dispozitivului cu un transfer de 1,1 microsecunde între nuclee. Postarea mai menționează că nevoia torch-spyre de a înregistra descompuneri specifice dispozitivului a contribuit la îmbunătățirea suportului pentru backendurile Inductor externe arborelui principal, îmbunătățiri incluse în PyTorch 2.12 prin două cereri de integrare acceptate.

Integrarea ca dispozitiv nativ

Spyre devine un dispozitiv PyTorch nativ prin înregistrarea PrivateUse1, care conferă lui tensor.to(“spyre”) o identitate reală de dispozitiv: mecanismul de alocare a memoriei din PyTorch păstrează tensorii în memoria dispozitivului, fluxurile asigură ordonarea operațiilor, iar evenimentele de execuție conectează lucrările dependente din fluxuri diferite. Placa are 32 de nuclee conectate printr-un inel cu lățime mare de bandă, fiecare cu o memorie scratchpad locală de 2 MB, și până la 128 GB de LPDDR5 pentru tensorii și programele executate; mediul de execuție actual modifică programele la lansare, înlocuind adresele simbolice ale tensorilor cu adrese reale în trei pași ordonați.

Într-o demonstrație cu Granite 3.3 8B, la dimensiunea lotului 1 și o lungime a secvenței de 1024, mutarea construirii grafului în afara traseului de transfer al datelor a îmbunătățit etapa de preumplere cu 9,9% și decodarea cu 13,6%, a raportat echipa. Eliminarea acestei operații și din distribuirea calculelor a dus la îmbunătățiri totale de 1,7x pentru etapa de preumplere și 2,4x pentru decodare, aproximativ trei sferturi din câștig provenind din traseul de calcul.

„Avantajul este că nici Spyre, nici PyTorch nu trebuie să pretindă că sunt altceva”, au scris autorii în Construirea Spyre ca dispozitiv PyTorch nativ, publicată la 8 octombrie 2026. Ei au adăugat că Spyre își păstrează modelul de execuție de tip flux de date, iar utilizatorii beneficiază de un dispozitiv PyTorch nativ, cu plasarea familiară a tensorilor, fluxuri și compilare.

Portabilitatea vLLM și legătura cu Llm-D

Spyre este un accelerator extern arborelui sursă, nu una dintre platformele GPU cel mai des acceptate de software-ul pentru IA. Acesta se bazează pe TorchDynamo pentru a urmări graful unui model și pe TorchInductor pentru a-l adapta la hardware-ul țintă. În vLLM, mecanismele de extensie precum CustomOp și PluggableLayer permit unui plugin hardware să personalizeze comportamentul fără să reimplementeze porțiuni mari din stiva software.

În Modele independente de hardware în vLLM, publicat la 22 septembrie 2026 de autori de la IBM, Meta și Hugging Face, echipa a descris orientarea vLLM către definiții de modele „plate”, specifice hardware-ului, și a prezentat straturi independente de hardware, construite pe baza a patru principii de proiectare: să poată fi compilate, să poată fi extinse, să fie izolate de căile specifice hardware-ului și să fie portabile. Suportul inițial a fost integrat în ramura principală a vLLM și poate fi activat cu USE_HW_AGNOSTIC=1 în backendul transformers. Această abordare a fost validată cu pluginul Spyre extern arborelui sursă, pe modele precum Gemma 4, Qwen3 și Granite 4.2; pe GPU-urile NVIDIA H100, straturile independente de hardware au asigurat un debit total de tokenuri cu cel mult 3,4% mai mic decât cel al implementării native, potrivit autorilor, măsurat ca medie geometrică pentru trei modele recente.

Integrarea Spyre cu PyTorch este și modul în care acesta se conectează la llm-d, explică articolul IBM: llm-d execută inferența distribuită folosind vLLM pe mai multe tipuri de acceleratoare, vLLM comunică cu fiecare accelerator prin PyTorch, iar, odată ce un dispozitiv are un backend PyTorch funcțional, un plugin hardware pentru vLLM îl poate expune, astfel încât llm-d să poată programa lucrări pe acesta.

Activare din prima zi și testare continuă

O postare din 20 august 2026 a echipei IBM Spyre prezintă HF-adapters, un proiect care folosește agenți de programare pentru a redacta patch-uri la execuție, permițând modelelor standard Hugging Face Transformers să ruleze pe Spyre. În perioada de la jumătatea lunii aprilie până la sfârșitul lunii iunie 2026, 13 adaptoare distincte au ajuns să acopere 7.960 dintre cele 10.000 de modele de embedding Hugging Face descărcate cel mai frecvent; dintre acestea, 6.804 trec testul complet, de la un capăt la altul, pe Spyre, potrivit postării. Un exemplu înlocuiește torch.pow(x, 3.0) din activarea gelu_new cu expresia matematic echivalentă x x x, pe care stiva torch-spyre o poate transpila; oamenii continuă să se ocupe de diagnosticare, identificând defecțiunile care apar doar pe dispozitiv, cauzate de operațiile fuzionate, și verificând concluziile fiecărui agent prin raportare la rezultatele testelor complete.

Într-o postare din 30 septembrie 2026, ingineri de la IBM și Red Hat au descris integrarea L2 a torch-spyre cu Cross-Repository CI Relay din PyTorch, care declanșează testarea în aval la modificările din PyTorch și transmite rezultatele înapoi către tabloul de bord CI al PyTorch. Integrarea combină o conductă de selecție a testelor în patru etape, bazată pe agenți, cu un cadru declarativ de reutilizare a testelor în YAML; la actualizarea de la PyTorch 2.13 la 2.14, a fost necesară evaluarea a aproximativ 4.000 de teste modificate, în loc de zeci de mii, au scris autorii. Aceștia au adăugat că intenționează să colaboreze cu echipa PyTorch pentru a integra în proiectul principal componentele reutilizabile, folosind PyTorch OpenReg drept punct de referință.

Pentru utilizatorii IBM Z, LinuxONE și Power11, experiența dorită presupune obținerea modelelor din ecosisteme precum Hugging Face și folosirea unor fluxuri de lucru bazate pe PyTorch, în mare parte identice cu cele utilizate cu GPU-urile Nvidia; punctele de extensie comune din PyTorch ascund o mare parte din diferențele arhitecturale, se arată în articolul IBM. Autorii articolului despre vLLM au spus că intenționează să înceapă includerea modelelor independente de hardware în CI și să treacă treptat la această abordare ca opțiune implicită pentru servirea modelelor pe Spyre.