llm-d 1.0 debiutuje na konferencji PyTorch Conference z produkcyjnym stosem do obsługi wnioskowania

Współtwórcy projektu llm-d ogłosili wersję llm-d 1.0 — natywny dla Kubernetes rozproszony stos do obsługi wnioskowania — 20 października 2026 r. podczas konferencji PyTorch Conference North America, jak wynika z ogłoszenia IBM Research. IBM poinformował, że wydanie to wykracza poza demonstrowanie poszczególnych technik zwiększania wydajności llm-d i ma pomóc organizacjom we wdrażaniu modeli we własnym zakresie, w miarę wzrostu kosztów wnioskowania.

llm-d powstał z myślą o wdrażaniu stosów do obsługi wnioskowania dla dowolnych modeli, na dowolnych akceleratorach i w dowolnej chmurze. Red Hat, IBM i Google są głównymi opiekunami projektu i współzałożyli llm-d wraz z CoreWeave i NVIDIA; do grona współtwórców dołączyły AMD, Cisco, Hugging Face, Intel, Lambda i Mistral AI. Cloud Native Computing Foundation (CNCF) udostępnia llm-d jako projekt w fazie sandbox. IBM przedstawia to rozwiązanie jako niezależną od dostawcy alternatywę dla organizacji, które chcą uzyskać wydajność wnioskowania na poziomie modeli czołówki rynku — jak określa ją IBM — bez całkowitego uzależniania się od jednego dostawcy zastrzeżonych modeli, jednej chmury lub jednej platformy sprzętowej.

Carlos Costa, Distinguished Engineer w IBM Research, a zarazem współzałożyciel i główny opiekun llm-d, powiedział, że wersja 1.0 zapewnia projektowi dojrzałość niezbędną do działania jak każda inna usługa o krytycznym znaczeniu. Wskazał na stabilne API, możliwość współdzielenia tej samej infrastruktury przez wielu dzierżawców o sprzecznych priorytetach oraz aktualizacje, które nie przerywają działania.

Co wnosi wersja 1.0

Opublikowane 20 października 2026 r. w serwisie GitHub informacje o wydaniu v1.0.0, opatrzone podpisanymi i zweryfikowanymi tagami, na pierwszym miejscu wymieniają jakość usług w środowisku wielodzierżawnym: sterowanie przepływem uwzględniające priorytety i sprawiedliwy podział zasobów, z kontrolowanym ograniczaniem obciążenia, w tym probabilistycznym mechanizmem dopuszczania żądań, sprawiedliwym podziałem uwzględniającym program oraz punktacją priorytetów tur. Dzięki temu żądania wrażliwe na opóźnienia i skokowo obciążające system zadania agentów mogą korzystać z tej samej puli zasobów bez wzajemnego zagładzania się w warunkach przeciążenia. Konfigurację sterowania przepływem zebrano w jednym polu flowControl.

Aby zapewnić działanie bez przestojów, router zyskuje wysoką dostępność dzięki gorącej rezerwie i bezpiecznym aktualizacjom kroczącym, a kontroler DisaggregatedSet zarządza replikami etapów prefill i decode jako jedną logiczną całością, koordynując wdrożenia, przeprowadzając aktualizacje w ścisłej synchronizacji, uzależniając gotowość od migawki Poda i zapewniając natywne kierowanie na podstawie wersji. API konfiguracji routera osiąga wersję v1, Responses API obsługuje previous_response_id, a ścieżkę obsługi żądań selektora punktów końcowych wzmocniono pod kątem niezawodności, wydajności i skalowalności. Wydanie obejmuje również przewodnik po akceleratorach uwzględniający topologię, dotyczący DRA i DRANET.

Obsługa uwzględniająca agentów obejmuje wtyczkę session-state-producer oraz dynamicznie dostosowywane powinowactwo sesji, które pozwalają utrzymywać wieloturowe rozmowy blisko buforowanego kontekstu. Harmonogramowanie uwzględniające priorytety tur oraz stan Responses API pomagają agentom ponownie wykorzystywać kontekst w kolejnych turach. Wydanie ujednolica komponenty projektu w wersji v1.0.0, dodaje elementy ekosystemu, w tym integrację z ai-dynamo/modelexpress umożliwiającą równorzędne ładowanie wag modeli, pakiet llm-d-api-extensions oraz narzędzia diagnostyczne llm-d-pd-utils, a także oznacza własne kompilacje obrazów kontenerów llm-d-rocm jako przestarzałe. Obrazy serwerów modeli obejmują kompilacje vLLM i SGLang dla różnych akceleratorów, a przewodnik po rozdzieleniu etapów prefill i decode wymaga teraz LeaderWorkerSet w wersji v0.11.1 lub nowszej z włączonym API DisaggregatedSet.

Kluczowe techniki i sterowanie przepływem

Od chwili uruchomienia projektu jego prace koncentrują się na pięciu sposobach usprawniania wnioskowania: kierowaniu uwzględniającym bufor prefiksów, które kieruje żądanie do infrastruktury mogącej już przechowywać współdzielony kontekst; przenoszeniu bufora KV, czyli przesyłaniu buforowanych informacji między zasobami GPU, CPU i pamięcią masową; optymalizacji wnioskowania wsadowego; rozdzieleniu etapów prefill i decode, które oddziela odczytywanie promptu od generowania odpowiedzi; oraz szerokim równolegleniu ekspertów, które rozdziela duże modele typu mixture of experts na wiele akceleratorów. Techniki te istniały przed wersją 1.0. Według IBM nowością jest ich integracja i dojrzałość operacyjna, a także dyscyplina operacji Day 2, polegająca na utrzymywaniu wydajności mimo zmian natężenia ruchu, awarii sprzętu, aktualizacji oprogramowania czy rywalizacji różnych użytkowników o te same zasoby.

W wersji 1.0 sterowanie przepływem, sprawiedliwy podział zasobów i ustalanie priorytetów mają zapobiegać przeciążaniu usług wrażliwych na opóźnienia przez skokowo obciążające system zadania — niezależnie od tego, czy korzystają one z tego samego sprzętu, czy z różnych akceleratorów. Żądania mogą też pozostawać przypisane do odpowiedniej infrastruktury przez wiele tur, aby bufory prefiksów zachowywały przydatną zawartość. llm-d współpracuje z silnikami wnioskowania, takimi jak vLLM i SGLang, zapewniając dodatkowo rozproszone kierowanie ruchem i funkcje operacyjne. Stephen Watt, wiceprezes w biurze dyrektora ds. technologii Red Hat, powiedział, że llm-d łączy ekosystemy PyTorch i CNCF, wprowadzając natywną dla Kubernetes orkiestrację bezpośrednio do vLLM i nowoczesnych silników wnioskowania.

Wyniki demonstracji i podane koszty

We wpisie z wynikami testu opublikowanym 22 lipca 2026 r. projekt zmierzył obsługę wnioskowania dla agentów w przypadku GLM-5.2, opisanego w nim jako model typu mixture-of-experts z 744 mld parametrów, 39 mld aktywnych parametrów i 78 warstwami. Analiza obciążenia opierała się na 219 sesjach produkcyjnych Claude Code, w których mediana liczby tokenów wejściowych w żądaniu głównego agenta wynosiła 195 tys., a liczby zwracanych tokenów wyjściowych — 317; w 96% tur głównego agenta ponownie wykorzystywano co najmniej 90% danych wejściowych. Wpis podaje, że routing uwzględniający prefiksy pozwolił wykorzystać 96–97% ponownego użycia pamięci podręcznej dostępnego w ramach tego obciążenia. Przy założonej stawce wynajmu H200 wynoszącej 2,71 USD za godzinę pracy GPU autorzy szacują, że samodzielnie hostowane wnioskowanie na dwóch konfiguracjach po 64 GPU kosztuje od 0,05 do 0,08 USD za milion tokenów wejściowych oraz od 1,92 do 3,55 USD za milion tokenów wyjściowych. Jak zaznaczają autorzy, kwoty te obejmują wyłącznie wynajem GPU i zakładają stałe obciążenie.

W osobnej demonstracji IBM i Red Hat wdrożyły GLM-5.2, opisany w relacji IBM Research jako model z otwartymi wagami, liczący około 753 mld parametrów, z czego około 39 mld to parametry aktywne, na 544 procesorach graficznych NVIDIA H100. IBM podaje, że wdrożenie w szczytowym momencie generowało ponad 6,6 mln tokenów wyjściowych na minutę, obsługując jednocześnie do 3000 agentów kodujących, bez żadnych wywłaszczeń; przy obciążeniu 2500 agentów utrzymywano tempo 7612 żądań na minutę. IBM informuje, że przy obecnych stawkach wynajmu w chmurze samodzielne hostowanie GLM-5.2 na procesorach graficznych H100 z użyciem llm-d kosztuje od 5 do 10 razy mniej za token niż równoważne usługi komercyjnych interfejsów API. „Obsługa tysięcy agentów jednocześnie bez wywłaszczeń daje operatorom wiarygodną możliwość przejścia od wyników testów porównawczych do wdrożenia produkcyjnego” — powiedział Maroon Ayoub, starszy główny inżynier uczenia maszynowego w zespole inżynierii wnioskowania Red Hat.

Według tej samej relacji u podstaw tych wyników leżała zdezagregowana płaszczyzna danych, która zrealizowała 6,2 mln transferów pamięci podręcznej KV o średniej wielkości 2,71 GiB każdy, bez żadnych błędów transferu; wszystkie testy porównawcze zakończyły się bez błędów obsługi.