Buoyant, firma rozwijająca Linkerd, opublikowała Kinference, otwartoźródłowy projekt mający służyć do budowy platform inferencyjnych na Kubernetes. Umieszczony przed zestawem serwerów vLLM, decyduje dla każdego żądania, do którego serwera zostanie ono wysłane. Projekt jest dystrybuowany na licencji Apache 2.0 na GitHub, w wersji v0.1.0-alpha.7.
- Buoyant publie Kinference, un plan de contrôle open source pour l’inférence sur Kubernetes et vLLM, sous licence Apache 2.0.
- Kinference décide pour chaque requête vers quel serveur vLLM l’envoyer, selon des politiques déclaratives stockées dans git.
- Selon Buoyant, le TTFT médian passe de 6,88 s à 0,31 s avec préfixe partagé, soit environ 95 % de gain.
- Le projet reste en alpha, et la limitation de débit, les classificateurs et l’API Anthropic ne sont pas encore disponibles.
Warstwa kontroli nad vLLM
Kinference łączy Kubernetes, platformę orkiestracji kontenerów, oraz vLLM, silnik uruchamiający modele językowe. Według FAQ Buoyant, vLLM stanowi płaszczyznę danych, podczas gdy Kinference pełni rolę płaszczyzny kontroli. W tej samej warstwie stosuje on polityki routingu, limity przepustowości w tokenach, równoważenie obciążenia uwzględniające cache KV, czyli pamięć przechowującą już wykonane obliczenia, oraz metryki per tenant.
System składa się z dwóch elementów: bramy ruchu i menedżera inferencji. Ten ostatni udostępnia interfejs gRPC, odbiera żądanie i zwraca wybrany punkt końcowy oraz ewentualnie zmodyfikowaną treść żądania. Działa z proxy, takim jak Buoyant Gateway. Kinference monitoruje zdarzenia cache KV i metryki silnika, korzystając z crate dynamo-kv-router od NVIDIA do ich przetwarzania. Jego konfiguracja opiera się na pięciu zasobach Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider i InferenceWorkerSet.
Polityki inferencji to deklaratywne reguły określające, jak każde żądanie jest kierowane lub odrzucane. Mogą opierać się na tenantcie, żądanym modelu, stanie pul GPU lub semantycznych etykietach. Strona projektu przedstawia kilka przykładów, takich jak kierowanie prostych żądań do mniejszego modelu lub korzystanie z dostawcy chmurowego jak Bedrock, gdy serwer ma więcej niż 2 żądania oczekujące. Polityki są przechowywane w git i mogą być walidowane offline za pomocą narzędzia CLI kinfctl.
Wyniki zmierzone przez Buoyant
Buoyant porównał Kinference z prostym równoważeniem obciążenia Kubernetes. Każda konfiguracja używała trzech podów vLLM 0.31.0, każdy na GPU L40S, z modelem Qwen3.8-27B-FP8. Przy ruchu współdzielącym wspólny prefiks, mediana opóźnienia do pierwszego tokena (TTFT) spadła, według Buoyant, z 6,88 s do 0,31 s, czyli o około 95%. Bez współdzielonego prefiksu wartości wyniosły 6,92 s wobec 6,83 s, bez znaczącej różnicy według wydawcy.
W teście wydajności, efektywna przepustowość, mierzona w żądaniach na minutę spełniających cel TTFT, osiągnęła 103,0 wobec 14,0 req/min dla ruchu ze współdzielonym prefiksem, czyli około 7,4 razy więcej. Dane te są samodeklarowane. Odniesieniem był routing losowy, a nie inny router uwzględniający cache, jak llm-d czy Dynamo. Buoyant dodaje, że jego progi 8 s i 4 s są bardziej odpowiednie dla agentów offline niż chatbotów. Tabela porównawcza opublikowana z artykułem przedstawia wyróżnik Kinference jako zarządzanie (governance), czyli polityki, aliasy modeli, fallback do dostawców i rozliczenia per tenant, podczas gdy llm-d i Dynamo są opisane jako lepsze w surowej wydajności.
Projekt pozostaje w fazie alfa. Ograniczanie przepustowości, klasyfikatory i obsługa API Anthropic nie są jeszcze dostarczone.
