Buoyant випустила Kinference v0.1.0-alpha.7: open source control plane для vLLM на Kubernetes. У власному тесті Buoyant на спільних префіксах медіанний TTFT упав з 6,88 до 0,31 с, за даними MarkTechPost.
Kinference, проєкт компанії Buoyant (автора Linkerd) з ліцензією Apache 2.0, стоїть перед парком vLLM-воркерів і вирішує, куди йде кожен запит. Якщо ви обслуговуєте кілька open-weight моделей для кількох внутрішніх клієнтів, це шар над model server. Цифри нижче самозвітні, тому читайте їх разом із застереженнями.
Звідки береться виграш у 95%?
Виграш дає роутинг з урахуванням кешу: Kinference стежить за подіями KV-кешу vLLM і метриками рушія, прогнозує TTFT для кожного кандидатного endpoint і в більшості правил мінімізує його. За даними Buoyant, для обробки подій кешу він використовує crate dynamo-kv-router від NVIDIA.
Тест ішов на трьох подах vLLM 0.31.0, кожен на одній L40S, з моделлю Qwen3.8-27B-FP8. Навантаження давав GuideLLM 0.8.1. Базою був ClusterIP Service, де kube-proxy випадково обирає под на кожне зʼєднання.
- Медіанний TTFT на shared-prefix: 6,88 с проти 0,31 с, тобто приблизно у 22 рази швидше (6,88 / 0,31 ≈ 22).
- Піковий goodput на shared-prefix: 103,0 проти 14,0 запитів на хвилину (приблизно 7,4x).
- Піковий goodput на multiturn: 82,7 проти 23,8 (приблизно 3,5x).
Де Kinference не дає виграшу?
На промптах без спільних префіксів медіанний TTFT майже не змінився: 6,92 с проти 6,83 с. Лише на контрольному трафіку p95 TTFT упав з 21,46 до 12,33 с, і Buoyant пояснює це балансуванням з урахуванням черг.
Є ще два застереження. MarkTechPost зазначає, що порівняння велося з випадковим роутингом, а не з cache-aware рішеннями на кшталт llm-d чи Dynamo. А Buoyant сама визнає, що SLO в тесті (8 с і 4 с) підходять для офлайн-агентів, але не для чату.
Чи готовий він до продакшну?
Ні, і це видно з репозиторію: Buoyant прямо пише, що це alpha-софт без тривалої експлуатації в продакшні. Не реалізовано підтримку /v1/messages (виклики в стилі Anthropic), rate limiting, семантичні класифікатори та кілька реплік самого Kinference.
Тут є розбіжність у MarkTechPost: в описі серед можливостей названо token rate limits, але в підсумку той самий текст пише, що rate limiting ще не випущений. Це збігається з README, тож спирайтеся на нього.
Окрема цінність проєкту: політики. InferencePolicy описує, що робити із запитом: відправити легкий промпт на меншу модель, пропускати воркери з чергою понад 2 промпти й переходити на провайдерів на кшталт Bedrock, або прибрати зовнішніх провайдерів і відхилити запит, коли спрацьовує PII-тег. Конфігурація живе в 5 CRD, а kinfctl дозволяє перевіряти політики офлайн. Директор Buoyant Вільям Морган розповів Cloud Native Now, що завантаження GPU зазвичай вимірюється одиницями відсотків, а Kinference має допомогти використовувати їх краще.
Що робити зараз
- Порахуйте частку запитів зі спільним префіксом (системний промпт, історія діалогу). Якщо вона мала, результат, імовірно, буде ближчим до 6,92 с проти 6,83 с, ніж до 0,31 с.
- Якщо вам потрібен rate limiting або більше однієї репліки control plane, зачекайте: цього в alpha.7 немає.
- Для проби підготуйте Gateway API v1.5.1 CRDs, Helm-чарт Buoyant gateway і чарт Kinference, а політики перевіряйте через kinfctl до застосування.









