Technologia

llm-d 1.0: Red Hat, IBM, Google i Nvidia stawiają, że prawdziwy rachunek za AI to inferencja

Zarządzany przez CNCF stos do serwowania modeli dojrzewa do produkcji, a agenci AI czynią kontekst najdroższą częścią
Adrian Kessler
Dodaj nas w Google

Przez trzy lata rozmowa o AI kręciła się wokół tego, kto zbuduje największy model. Mniej efektowne pytanie — ile kosztuje utrzymanie tego modelu w gotowości do odpowiedzi, miliony razy dziennie, bez awarii — to dziś miejsce, którędy uciekają pieniądze. llm-d, otwartoźródłowy projekt inferencji zapoczątkowany przez Red Hat, IBM, Google Cloud, CoreWeave i Nvidię, osiągnął wersję 1.0, a jego oferta celuje dokładnie w ten wyciek.

Mechanizm warto opisać wprost. Agent AI nie zadaje jednego pytania i nie znika. Utrzymuje długie sesje, wielokrotnie czyta te same dokumenty i uruchamia równoległych pomocników, którzy obciążają sprzęt nieprzewidywalnymi falami. W takim układzie obsługa kontekstu może kosztować więcej niż wygenerowanie odpowiedzi. Każdy zespół serwujący modele na dużą skalę, mówi Shadi Saba, wiceprezes ds. inżynierii AI/ML w CoreWeave, trafia na „kontekst, którego obsługa często kosztuje więcej niż sam wynik”. Odpowiedzią llm-d jest routing: każde zapytanie trafia do serwera, który ma już jego kontekst w pamięci podręcznej, zamiast liczyć go od nowa.

Fisheye view of a server rack in the Datarmor high-performance computing and AI centre in Brest
Image: Gregory Rocher, Ifremer / Wikimedia Commons (CC BY 4.0)

Wersja 1.0 przynosi mniej nowych sztuczek, a więcej pewności, że istniejące da się utrzymać przez miesiące. Projekt oferował już routing uwzględniający pamięć podręczną, odciążanie pamięci KV cache i rozdzielenie faz prefill i decode między maszyny, na bazie serwerów modeli takich jak vLLM i SGLang. Nowe wydanie dodaje kontrolę priorytetów i sprawiedliwego podziału, aby zapytania wrażliwe na opóźnienia i agenci działający zrywami mogli dzielić jedną flotę GPU, nie dusząc się nawzajem, router o wysokiej dostępności pozwalający na aktualizacje bez przestojów, stabilne API konfiguracji v1 oraz routing świadomy sesji, który trzyma wieloturowe rozmowy blisko ich zapisanego stanu.

Dane o wydajności z komunikatu pochodzą z pokazów samych współtwórców, więc należy je traktować jako deklaracje, a nie audyty. W jednym z nich badacze serwowali GLM 5.2, model z otwartymi wagami liczący około 753 miliardów parametrów, na powszechnie używanych GPU Nvidii, osiągając szczytowo ponad 6,6 mln tokenów wyjściowych na minutę i do 3000 równoczesnych agentów programistycznych; według obecnych stawek wynajmu w chmurze koszt za token był od pięciu do dziesięciu razy niższy niż w porównywalnym komercyjnym API. IBM Research podaje 11,5 razy niższy koszt inferencji niż w konfiguracji w pełni zamkniętej przy projekcie układów do korekcji błędów kwantowych, przy trafności pamięci podręcznej około 98%.

Bardziej wymowne jest to, kto już na nim polega. JetBrains twierdzi, że llm-d obsługuje znaczną część ruchu w Junie Lite, darmowym planie jego agenta programistycznego; DigitalOcean uruchamia na nim swoją inferencję serverless, a Mistral i Roblox opisują swoje warstwy serwowania zbudowane na projekcie. Google Cloud integruje wersję 1.0 z Google Kubernetes Engine w całej ofercie TPU i GPU Nvidii, a AMD przenosi ją na akceleratory Instinct.

Założony w 2025 roku i zarządzany dziś przez Cloud Native Computing Foundation, llm-d ma ponad 500 współtwórców z ponad 25 organizacji. Wersję 1.0 ogłoszono 20 października 2026 roku w San José; jest już dostępna jako oprogramowanie open source.

Konsekwencją jest przesunięcie układu sił. Jeśli drogie w AI jest serwowanie, a nie trenowanie, to kto kontroluje warstwę serwowania, ten kontroluje rachunek. llm-d to próba zadbania o to, by ta warstwa pozostała wspólna i otwarta, a nie zamknięta w API jednego dostawcy.

Tagi: , , , , ,

Dodaj nas w Google

Dyskusja

Jest 0 komentarzy.