llm-d 1.0 představen na konferenci PyTorch Conference s produkčním inferenčním stackem

Přispěvatelé projektu llm-d oznámili 20. října 2026 na konferenci PyTorch Conference North America vydání llm-d 1.0, distribuovaného stacku pro obsluhu inference nativního pro Kubernetes, jak uvádí oznámení IBM Research. IBM uvedla, že toto vydání posouvá llm-d za hranice předvádění jednotlivých technik zvyšování výkonu a má organizacím pomoci přesunout nasazování modelů do vlastní infrastruktury v době, kdy náklady na inferenci rostou.

llm-d je navržen tak, aby umožňoval nasazovat inferenční stacky pro jakýkoli model, na jakémkoli akcelerátoru a v jakémkoli cloudu. Red Hat, IBM a Google jsou hlavními správci projektu a llm-d založily společně s CoreWeave a NVIDIA; k přispěvatelům se přidaly AMD, Cisco, Hugging Face, Intel, Lambda a Mistral AI. Cloud Native Computing Foundation (CNCF) zastřešuje llm-d jako sandboxový projekt. IBM výsledek popisuje jako alternativu nezávislou na dodavatelích pro organizace, které chtějí dosáhnout toho, co označuje za inferenční výkon na špičkové úrovni, aniž by byly zcela závislé na jediném proprietárním poskytovateli modelu, cloudu nebo hardwarové platformě.

Carlos Costa, význačný inženýr ve společnosti IBM Research a spoluzakladatel a hlavní správce llm-d, uvedl, že verze 1.0 přináší dostatečnou vyspělost k tomu, aby bylo možné provozovat llm-d jako jakoukoli jinou kritickou službu. Poukázal přitom na stabilní API, možnost sdílení stejné infrastruktury více nájemci s protichůdnými prioritami a aktualizace, které nenarušují provoz.

Co přináší verze 1.0

Poznámky k vydání v1.0.0 projektu, zveřejněné na GitHubu 20. října 2026 spolu s podepsanými a ověřenými tagy, kladou důraz na kvalitu služeb pro více nájemců: řízení toku zohledňující priority a spravedlivé přidělování prostředků, doplněné řízeným omezováním zátěže, včetně pravděpodobnostního mechanismu přijímání požadavků, spravedlivého přidělování zohledňujícího program a bodování priority jednotlivých tahů. Díky tomu mohou požadavky citlivé na latenci a nárazově zatěžující úlohy agentů sdílet stejnou infrastrukturu, aniž by se při přetížení navzájem připravovaly o prostředky. Konfigurace řízení toku je sjednocena pod jediným polem flowControl.

Pro provoz bez výpadků získává směrovač vysokou dostupnost s teplou zálohou a bezpečnými průběžnými aktualizacemi. Řadič DisaggregatedSet spravuje repliky předvyplňování a dekódování jako jednu logickou jednotku, zajišťuje koordinované zavádění změn a synchronizované aktualizace, podmiňuje připravenost snímkem Podu a podporuje nativní směrování podle revizí. Konfigurační API směrovače přechází na verzi v1, Responses API podporuje previous_response_id a cesta požadavků výběru koncového bodu je posílena z hlediska spolehlivosti, výkonu a škálovatelnosti. Součástí je také průvodce akcelerátory zohledňující topologii pro DRA a DRANET.

Obsluha zohledňující agenty přidává zásuvný modul pro produkci stavu relace a průběžně se přizpůsobující afinitu relací, aby vícetahové konverzace zůstávaly blízko svého kontextu uloženého v mezipaměti. Plánování podle priority jednotlivých tahů a stav v Responses API pomáhají agentům opakovaně využívat kontext napříč tahy. Vydání sjednocuje komponenty projektu na verzi v1.0.0 a přidává součásti ekosystému, mimo jiné integraci s ai-dynamo/modelexpress pro načítání vah modelů mezi uzly metodou peer-to-peer, balíček llm-d-api-extensions a diagnostické nástroje llm-d-pd-utils. Zároveň označuje vlastní sestavení kontejnerových obrazů llm-d-rocm projektu za zastaralá. Obrazy serverů modelů zahrnují sestavení vLLM a SGLang pro různé cílové akcelerátory a průvodce oddělením předvyplňování a dekódování nyní vyžaduje LeaderWorkerSet verze v0.11.1 nebo novější se zapnutým API DisaggregatedSet.

Klíčové techniky a řízení toku

Od svého spuštění se projekt zaměřuje na pět přístupů ke zlepšení inference: směrování zohledňující prefixovou mezipaměť, které přesměrovává požadavek na infrastrukturu, jež už může obsahovat sdílený kontext; přesouvání mezipaměti KV, které přenáší uložené informace mezi prostředky GPU, CPU a úložiště; optimalizaci dávkové inference; oddělení předvyplňování a dekódování, při němž se čtení promptu odděluje od generování odpovědi; a širokou paralelizaci expertů, která rozděluje rozsáhlé modely typu mixture-of-experts mezi mnoho akcelerátorů. Tyto techniky existovaly již před verzí 1.0; podle IBM je novinkou jejich integrace a provozní vyspělost, tedy disciplína provozu druhého dne, která spočívá v udržení výkonu při změnách provozu, selhání hardwaru, aktualizacích softwaru nebo soupeření různých uživatelů o stejné prostředky.

V rámci verze 1.0 mají řízení toku, spravedlivé přidělování prostředků a určování priorit bránit tomu, aby nárazově zatěžující úlohy zahltily služby citlivé na latenci, ať už tyto úlohy sdílejí stejný hardware, nebo využívají kombinaci akcelerátorů. Požadavky lze navíc v průběhu více tahů připnout k odpovídající infrastruktuře, aby prefixové mezipaměti zůstávaly zahřáté. llm-d spolupracuje s inferenčními enginy, jako jsou vLLM a SGLang, a rozšiřuje je o distribuované směrování a provozní funkce. Stephen Watt, viceprezident v kanceláři technického ředitele společnosti Red Hat, uvedl, že llm-d sjednocuje ekosystémy PyTorch a CNCF tím, že přináší orchestraci nativní pro Kubernetes přímo do vLLM a moderních inferenčních enginů.

Předvedené výsledky a uváděné náklady

V benchmarkovém příspěvku zveřejněném 22. července 2026 projekt měřil agentní inferenční obsluhu modelu GLM-5.2, který je tam popsán jako model typu mixture of experts se 744B parametry, 39B aktivními parametry a 78 vrstvami. Analýza zátěže vycházela z 219 produkčních relací Claude Code, v nichž měl požadavek hlavního agenta mediánově 195K vstupních tokenů a vracel 317 výstupních tokenů; v 96 % tahů hlavního agenta se znovu použilo alespoň 90 % vstupních dat. Příspěvek uvádí, že směrování zohledňující prefixy zachytilo 96–97 % opětovného využití mezipaměti, které zátěž umožňovala. Při předpokládané ceně pronájmu H200 ve výši 2,71 $ za GPU-hodinu vychází podle něj samostatně hostovaná obsluha ve dvou konfiguracích se 64 GPU na 0,05 až 0,08 $ za milion vstupních tokenů a 1,92 až 3,55 $ za milion výstupních tokenů; autoři uvádějí, že tyto částky zahrnují pouze pronájem GPU a předpokládají trvalé zatížení.

V samostatné demonstraci nasadily IBM a Red Hat model GLM-5.2, který je v zprávě IBM Research charakterizován jako model s otevřenými váhami a přibližně 753 miliardami parametrů, z nichž je asi 39 miliard aktivních, na 544 GPU NVIDIA H100. IBM uvádí, že nasazení dosáhlo ve špičce výkonu přes 6,6 milionu výstupních tokenů za minutu při obsluze až 3 000 souběžně pracujících programovacích agentů bez jediného přerušení a že při provozním zatížení 2 500 agentů trvale zpracovávalo 7 612 požadavků za minutu. IBM uvádí, že při současných sazbách pronájmu cloudových služeb stojí samostatné hostování modelu GLM-5.2 na GPU H100 s llm-d 5 až 10krát méně za token než srovnatelné komerční ceny API. „Obsluha tisíců souběžně pracujících agentů bez přerušení dává provozovatelům reálnou možnost převést výsledky benchmarku do produkčního nasazení,“ řekl Maroon Ayoub, seniorní hlavní inženýr strojového učení v týmu inference engineering společnosti Red Hat.

Podle téže zprávy dokončila oddělená datová rovina při těchto výsledcích 6,2 milionu přenosů mezipaměti KV s průměrnou velikostí 2,71 GiB na přenos, aniž došlo k jedinému selhání přenosu; všechny benchmarky navíc proběhly bez jediné chyby při obsluze.