Buoyant, компания за проектом Linkerd, выпустила Kinference — открытый проект для построения платформ инференса на Kubernetes. Это control plane, который ставится перед парком воркеров vLLM и решает, куда уйдёт каждый запрос: применяет политики маршрутизации, лимиты по токенам, балансировку с учётом KV-кэша и метрики по арендаторам в одном слое. Лицензия — Apache 2.0, текущий релиз — v0.1.0-alpha.7, код написан на Rust и лежит на GitHub.
Формулировка из FAQ проекта простая: vLLM — это data plane, а Kinference — control plane. Целевая аудитория — команды, которые отдают много открытых моделей многим внутренним клиентам и которым нужен слой выше сервера моделей.
Из чего состоит Kinference
В системе две части: шлюз трафика и обработчик инференса. Обработчик, согласно README на GitHub, выставляет gRPC-интерфейс: принимает запрос и возвращает выбранный endpoint плюс, возможно, изменённое тело запроса. Работает он в паре с прокси вроде Buoyant Gateway.
Kinference следит за событиями KV-кэша vLLM и метриками движка. Для обработки событий кэша сейчас используется крейт NVIDIA dynamo-kv-router. Конфигурация живёт в пяти CRD Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider и InferenceWorkerSet.
Политики маршрутизации вместо ручных правил
InferencePolicy — декларативные правила, по которым запрос маршрутизируется или отклоняется. Условия могут опираться на арендатора, запрошенную модель, состояние пула GPU и семантические теги. В примерах на сайте проекта разобрано пять шаблонов:
- простое — на дешёвое: низкокомплексные промпты уходят на меньшую модель, если только перекрытие кэша не делает большую модель быстрее;
- всплеск — в облако: воркеры с очередью больше двух промптов пропускаются, дальше идёт откат на внешних провайдеров вроде Bedrock;
- PII остаётся локально: при срабатывании тега PII внешние провайдеры убираются, а
onEmpty: Rejectзакрывает отказом; - батчи — на простаивающие GPU: пакетные запросы идут только на воркеры с загрузкой KV-кэша ниже 70%;
- алиасы моделей: публикуется одно стабильное имя, например
standard-model, за которым стоит несколько моделей.
Большинство правил заканчивается minimize: PredictedTTFT. Kinference предсказывает время до первого токена для каждого кандидата, учитывая перекрытие кэша и длину очереди. Политики хранятся в git и проверяются офлайн через CLI kinfctl.
Что показал бенчмарк
Buoyant опубликовала сравнение с обычной балансировкой Kubernetes. В каждом плече было по 3 пода vLLM 0.31.0, каждому — по одной GPU L40S. Модель — Qwen3.8-27B-FP8, нагрузку генерировал GuideLLM 0.8.1. Базой служил ClusterIP Service, где kube-proxy выбирает случайный под на соединение.
Медианный TTFT без нагрузки:
| Нагрузка | Kubernetes Service | Kinference | Изменение |
|---|---|---|---|
| Контроль (без общего префикса) | 6,92 с | 6,83 с | без значимой разницы |
| Общий префикс | 6,88 с | 0,31 с | около −95% |
| Мультитёрн | 1,70 с | 0,59 с | около −65% |
Медианная сквозная задержка упала на 45% на общем префиксе и на 32% на мультитёрне. На контрольном трафике p95 TTFT всё равно снизился с 21,46 с до 12,33 с — Buoyant объясняет это балансировкой с учётом очереди.
Тест ёмкости измерял goodput: запросы в минуту, укладывающиеся в SLO по TTFT. Пиковый goodput — 103,0 против 14,0 запроса в минуту на общем префиксе, примерно в 7,4 раза. На мультитёрне — 82,7 против 23,8, примерно в 3,5 раза. База на Service не уложилась в SLO ни при одной из проверенных конкурентностей.
Цифры заявлены самим вендором. База — случайная маршрутизация, а не другой кэш-осведомлённый роутер вроде llm-d или Dynamo. Buoyant также оговаривает, что её SLO (8 с и 4 с) подходят офлайн-агентам, а не чату.
Чем это отличается от llm-d, Dynamo и Production Stack
Все четыре проекта — Apache 2.0, но решают разные задачи. llm-d развивается как sandbox-проект CNCF при участии Red Hat, Google Cloud, IBM, CoreWeave и NVIDIA, версия v0.7 (май 2026). NVIDIA Dynamo — 1.x, контейнеры 1.5.1. vLLM Production Stack — проект самого vLLM.
Kinference поддерживает vLLM, а SGLang и TensorRT-LLM заявлены в планах. llm-d и Dynamo уже работают с vLLM, SGLang и TensorRT-LLM. Кэш-осведомлённая маршрутизация есть у всех, но по-разному: у Kinference — через предсказание TTFT, у llm-d — по префикс-кэшу и предсказанной задержке, у Dynamo — через KV-aware router, у Production Stack — сессионная, а префикс-осведомлённость указана как незавершённая работа.
Декларативные CRD маршрутизации, откат на внешних провайдеров и управление арендаторами в README остальных трёх проектов не описаны. Разделение prefill и decode у Kinference не раскрыто, у llm-d и Dynamo оно есть, у Production Stack — в планах. По сырой производительности обслуживания, разделению prefill/decode и охвату движков впереди llm-d и Dynamo; отличительный угол Kinference — governance: политики, алиасы, откат на провайдеров и учёт по арендаторам.
Установка и что ещё не готово
По гайду getting started установка занимает пять шагов: ставятся CRD Gateway API v1.5.1, Helm-чарт шлюза Buoyant, затем чарт Kinference. Проект отдаёт метрики Prometheus и дашборды Grafana: TTFT, ITL, сквозная задержка, токены промпта из кэша и вне его — в основном в разрезе арендаторов.
Релиз альфа-уровня: лимиты по токенам, классификаторы и поддержка Anthropic API ещё не выпущены. Для продакшена это значит, что проект стоит рассматривать как слой управления поверх уже работающего vLLM, а не как готовую замену отлаженному стеку.
Если вы уже строите распределённый инференс на Kubernetes, полезно сравнить подход Kinference с тем, что предлагает стек llm-d 1.0, а по управлению GPU-ресурсами кластера — с открытым Run:ai от NVIDIA. Для маршрутизации запросов между разными вычислителями пригодится и опыт NVIDIA PAIR.
Частые вопросы
Что такое control plane инференса и зачем он нужен?
Это слой, который стоит между клиентами и серверами моделей и решает, куда направить каждый запрос. vLLM обслуживает запросы, Kinference выбирает воркер, применяет политики и собирает метрики.
Кого касается новость?
Команды, которые держат несколько открытых моделей на Kubernetes и отдают их многим внутренним клиентам. Если у вас один под vLLM и один клиент, выгода от отдельного control plane невелика.
Насколько вырастет скорость на моём трафике?
Зависит от доли запросов с общим префиксом. На общем префиксе Buoyant заявила падение медианного TTFT на 95%, на мультитёрне — на 65%, а на промптах без общего префикса разницы не было вовсе.
Можно ли верить цифрам бенчмарка?
Это самоотчёт вендора. База — случайная маршрутизация kube-proxy, а не другой кэш-осведомлённый роутер, и SLO в тесте (8 с и 4 с) рассчитаны на офлайн-агентов, а не на чат.
Какие версии нужны для установки?
В бенчмарке использовались vLLM 0.31.0 и Gateway API v1.5.1 CRD. Кластер должен быть с GPU, а установка идёт Helm-чартами: сначала шлюз Buoyant, затем Kinference.
Что делать, если обновиться нельзя?
Kinference — не замена vLLM и не патч, а дополнительный слой. Без него остаётся штатная балансировка Kubernetes, но на трафике с общим префиксом она, по данным Buoyant, не укладывается в SLO по TTFT.
Есть ли лимиты по токенам прямо сейчас?
Нет. Лимиты по токенам и классификаторы заявлены, но в текущем релизе v0.1.0-alpha.7 ещё не выпущены. Из управления арендаторами доступны метрики в разрезе арендаторов.
Поддерживаются ли другие движки, кроме vLLM?
Пока нет. SGLang и TensorRT-LLM указаны в планах, а сейчас проект рассчитан на vLLM на любом GPU-кластере Kubernetes.
Чем Kinference отличается от llm-d и Dynamo?
Политиками и governance: декларативные InferencePolicy, алиасы моделей, откат на внешних провайдеров и учёт по арендаторам. llm-d и Dynamo сильнее в сырой производительности обслуживания и разделении prefill/decode.
Источник: marktechpost.com