Kinference zkrátilo čekání na první token o 95 %, má to ale podmínku

Kinference řeší provoz, ne samotný model

Kinference není nový jazykový model ani náhrada za vLLM. Funguje o vrstvu výš. vLLM se stará o samotné generování tokenů na GPU, zatímco Kinference rozhoduje, kam konkrétní požadavek poslat, kdy ho odmítnout a jak zohlednit stav celého clusteru. Buoyant tento rozdíl popisuje jednoduše. vLLM je datová rovina a Kinference řídicí rovina. Prakticky to připomíná rozdíl mezi jednotlivými servery v datacentru a systémem, který rozhoduje, který server dostane další práci. To je důležité hlavně ve chvíli, kdy firma provozuje více open-weight modelů, několik GPU workerů a desítky interních aplikací. Běžná Kubernetes Service v takovém prostředí požadavky rozděluje bez hlubší znalosti toho, co se právě děje uvnitř inference serverů. Kinference sleduje metriky vLLM i obsah KV-cache a podle nich vybírá vhodnější endpoint. Projekt je dostupný jako open source pod licencí Apache 2.0. Aktuální vydání má označení v0.1.0-alpha.7, je napsané v Rustu a jeho zdrojový kód je na GitHubu. Samotný software nemá poplatek za tokeny ani předplatné. Náklady vznikají až za Kubernetes cluster, GPU, úložiště a provoz modelů.

KV-cache rozhoduje, kam požadavek půjde

Jedním z hlavních prvků Kinference je směrování podle KV-cache. Ta uchovává mezivýsledky výpočtu během zpracování promptu. Pokud další požadavek obsahuje stejný nebo podobný začátek, worker může část výpočtu znovu použít. Typickým příkladem je několik kol jedné konverzace nebo opakované dotazy nad stejným systémovým promptem. Když každý požadavek skončí náhodně na jiném GPU workeru, cache se využije méně. Kinference se pokouší najít worker, který už relevantní část kontextu má uloženou. Rozhodování vychází z odhadované hodnoty TTFT, tedy doby do prvního tokenu. Nejde o celkovou délku odpovědi. Uživatel ale obvykle vnímá právě první token jako okamžik, kdy systém začíná reagovat. Řídicí rovina využívá knihovnu dynamo-kv-router od NVIDIA. Vedle obsahu cache pracuje také s délkou fronty a stavem GPU poolu. Podle dokumentace může pravidlo vybrat endpoint s nejnižším očekávaným TTFT.

Konfigurace probíhá přes Kubernetes

Kinference se nenastavuje pouze ručně v aplikaci. Pravidla se zapisují deklarativně do Kubernetes, takže mohou být verzována společně s další konfigurací infrastruktury. Systém používá pět vlastních typů zdrojů, takzvaných CRD:

• GatewayBackend popisuje externí backend a způsob autentizace,
• InferenceProvider označuje vzdáleného poskytovatele inference,
• InferenceWorkerSet definuje skupinu lokálních workerů pro jeden model,
• InferencePool sdružuje možné lokální i vzdálené cíle,
• InferencePolicy určuje, jak se mají požadavky směrovat nebo odmítat.

Pravidla mohou rozlišovat tenanty, požadovaný model, stav GPU poolu nebo sémantické štítky. V praxi lze například nastavit, aby méně náročné požadavky mířily na menší model. Pokud je však na větším modelu připravený relevantní prefix v cache, pravidlo může zohlednit očekávanou rychlost. Další scénář počítá s přesměrováním špiček do cloudového poskytovatele. Jiná pravidla mohou požadavky označené jako osobní údaje ponechat pouze na lokálních workerech a při jejich nedostupnosti požadavek odmítnout. Dokumentace uvádí také modelové aliasy. Aplikace tak může používat stabilní název modelu, zatímco provozovatel pod ním vymění konkrétní backend. To je užitečné při řízení více verzí modelů bez úprav klientského kódu.

Benchmark ukázal rozdíl hlavně u sdílených promptů

Buoyant porovnala Kinference s běžným Kubernetes Service routingem. Test využil dva stejné pooly vLLM. Každý měl tři pody, přičemž každý pod běžel na vlastní grafické kartě NVIDIA L40S. Model se jmenoval Qwen3.8-27B-FP8 a zátěž generoval nástroj GuideLLM 0.8.1. U workloadu se sdíleným prefixem klesl medián TTFT z 6,88 sekundy při běžném směrování na 0,31 sekundy s Kinference. Buoyant uvádí snížení o 95 procent. Medián celkové latence se u stejného testu snížil o 45 procent. U vícekrokových konverzací klesl medián TTFT z 1,70 na 0,59 sekundy, tedy přibližně o 65 procent. Celková latence byla nižší o 32 procent. Nejzajímavější číslo přinesl test kapacity. U sdíleného prefixu dosáhl Kinference goodputu 103 požadavků za minutu, zatímco běžný Kubernetes Service 14 požadavků za minutu. Goodput zde znamená počet požadavků za minutu, které splnily stanovený limit TTFT. Rozdíl vychází přibližně na 7,4násobek. Výsledek však není univerzální. U požadavků bez překrývajícího se prefixu se medián TTFT prakticky nezměnil. Běžné směrování dosáhlo 6,92 sekundy a Kinference 6,83 sekundy. Cache-aware routing tedy nemá co využít, pokud každý prompt přichází jako nový a nesdílí relevantní kontext s předchozími požadavky. Benchmark zveřejnila společnost Buoyant a srovnání probíhalo proti náhodnému výběru podu přes Kubernetes Service. Nešlo o přímý test proti jinému cache-aware routeru. Čísla proto ukazují přínos proti základnímu způsobu směrování, nikoli celkové pořadí všech dostupných řešení.

Kinference má jiný důraz než llm-d nebo NVIDIA Dynamo

Na trhu existují i další projekty pro distribuovanou inferenci. llm-d a NVIDIA Dynamo se také věnují směrování podle cache a výkonu. Zdrojové srovnání uvádí, že llm-d a Dynamo mají širší podporu inference enginů a řeší také disaggregated prefill/decode, tedy oddělení různých částí výpočtu generování. Kinference má odlišné těžiště. Staví na deklarativních pravidlech, tenantových metrikách, aliasování modelů a možnosti přesměrovat špičku k externímu poskytovateli. Pro tým, který provozuje interní AI platformu pro více oddělení, může být tento přístup praktičtější než samotné honění nejnižší latence. Srovnání výkonu je potřeba číst opatrně. Každý projekt používá jiný hardware, model, zátěž a definici SLO. Čísla proto nelze jednoduše postavit do jedné tabulky a vyhlásit vítěze. Infrastruktura pro AI má v tomto směru podobný problém jako auta. Spotřeba z jednoho testu neříká, jak si vůz povede s jiným nákladem a na jiné trase.

Dostupnost v Česku a stav projektu

Kinference je open-source software, takže není omezený na Spojené státy ani na konkrétní cloud. Česká nebo slovenská lokalizace se u tohoto nástroje neřeší, protože jde o infrastrukturu pro vývojáře a provozní týmy. Dokumentace, konfigurace i rozhraní jsou v angličtině. Nasazení je možné v evropském nebo českém Kubernetes clusteru s GPU, pokud v něm běží vLLM. Instalace podle oficiálního návodu probíhá v několika krocích. Nejprve se nasadí Gateway API CRD, potom gateway, CRD pro Kinference a samotný řídicí systém. K dispozici jsou také Prometheus metriky a Grafana dashboardy pro TTFT, dobu mezi tokeny, celkovou latenci a poměr cacheovaných a necachovaných tokenů. Důležitá je fáze vývoje. Verze v0.1.0-alpha.7 není hotový produkt pro každé nasazení. Podle zveřejněných informací v ní zatím chybí některé plánované funkce, například nativní endpoint /v1/messages ve stylu Anthropic, sémantické klasifikátory a plnohodnotný rate limiting. Dokumentace tyto oblasti uvádí jako součást směru projektu, nikoli jako důvod ignorovat označení alfa. Kinference proto dává největší smysl týmům, které už provozují vlastní modely v Kubernetes a potřebují řídit sdílené GPU zdroje. Pro jednotlivce s jedním modelem a jedním GPU by šlo o zbytečně velkou vrstvu. Pro více tenantů, různé modely a opakující se kontexty může být rozdíl mezi náhodným směrováním a rozhodováním podle cache dobře měřitelný. V testu Buoyantu byl největší u sdílených prefixů, nikoli u zcela nových promptů.

FAQ