В эпоху, когда развертывание больших языковых моделей (LLM) перешло из стадии экспериментов в стадию промышленной эксплуатации, инфраструктурные вызовы становятся все более сложными. Развернуть модель на одной видеокарте — это лишь начало. Настоящая боль возникает, когда нужно обслуживать десятки моделей, сотни клиентов и гарантировать низкие задержки при переменчивой нагрузке. Именно на этот разрыв между «просто запустить» и «надежно масштабировать» отвечает новый проект Kinference от компании Buoyant, известной своим сервис-мешем Linkerd.
Kinference позиционируется не как еще один движок для запуска моделей, а как контрольная плоскость (control plane) для инференса. Если представить архитектуру LLM-сервиса как транспортную систему, то vLLM — это сами грузовики, везущие данные, а Kinference — это диспетчерский центр, который решает, куда именно поедет каждый груз, чтобы избежать пробок и оптимизировать время доставки. Это решение написано на Rust, лицензировано под Apache 2.0 и доступно в альфа-версии v0.1.0-alpha.7.
В этой статье мы подробно разберем, как работает Kinference, почему маршрутизация, aware к KV-кэша, критически важна для современных LLM, и какие реальные преимущества это дает командам, использующим Kubernetes для AI-инфраструктуры.
01Что такое Kinference и зачем она нужна?
Ключевая проблема при масштабировании LLM-серверов в Kubernetes заключается в том, что стандартные механизмы балансировки нагрузки (например, kube-proxy с алгоритмом round-robin или random) не понимают специфику работы с большими моделями. Они видят только TCP-соединения и пакеты, игнорируя семантику запросов. В результате, запросы могут направляться на узлы, где уже есть частичное совпадение в кэше (KV-cache), что позволяет заметно ускорить генерацию, или, наоборот, на узлы с пустым кэшем, заставляя модель выполнять полную, ресурсоемкую операцию префиллинга (prefill).
Kinference решает эту проблему, выступая в роли интеллектуального шлюза перед пулом воркеров vLLM. Она анализирует входящие запросы, состояние кластера и, что самое важное, состояние KV-кэша каждого воркера. Это позволяет системе принимать решения на основе данных, а не случайности.
Проект нацелен на команды, которые обслуживают множество open-weight моделей для внутренних клиентов. Вместо того чтобы писать кастомные прокси-серверы или полагаться на базовые возможности Kubernetes, разработчики получают готовый слой абстракции, который интегрируется с существующей инфраструктурой через 5 пользовательских ресурсов Kubernetes (CRDs).
02Архитектура: Как это работает под капотом
Архитектура Kinference состоит из двух основных компонентов: шлюза трафика (traffic gateway) и обработчика инференса (inference handler). Обработчик предоставляет gRPC-интерфейс, который принимает запрос, определяет целевой endpoint и, при необходимости, модифицирует тело запроса. Этот компонент тесно интегрируется с прокси, таким как Buoyant Gateway, который обрабатывает входящий HTTP/gRPC трафик.
Сердцем системы является способность Kinference отслеживать события KV-кэша и метрики движка vLLM в реальном времени. Для этого проект использует библиотеку dynamo-kv-router от NVIDIA, что обеспечивает глубокую интеграцию с внутренним состоянием vLLM. Это позволяет системе «видеть», какие токены уже кэшированы на каждом узле, и принимать решения на основе этого знания.
Конфигурация системы декларативна и управляется через пять CRDs:
- GatewayBackend: Определяет бэкенды, к которым может направляться трафик.
- InferencePolicy: Основной объект для определения правил маршрутизации и обработки.
- InferencePool: Группирует воркеры в пулы для управления ресурсами.
- InferenceProvider: Позволяет подключать внешние провайдеры (например, облачные API) для burst-нагрузок.
- InferenceWorkerSet: Описывает набор воркеров vLLM, управляемых Kinference.
Такой подход позволяет командам хранить конфигурацию в Git (GitOps), проводить код-ревью изменений политик и откатывать их в случае ошибок, что является стандартом для надежной CI/CD практики в DevOps.
03Политики инференса: Гибкость и контроль
Одной из самых сильных сторон Kinference является система декларативных политик (InferencePolicy). Эти правила позволяют инженерам задавать сложную логику маршрутизации без написания кода. Политики могут учитывать множество факторов: идентификатор клиента (tenant), запрашиваемую модель, состояние GPU-пула и семантические теги (например, наличие персональных данных).
Рассмотрим пять ключевых паттернов, которые поддерживаются в текущей версии:
- Маршрутизация к более дешевым моделям (Simple to cheaper): Если запрос простой, система может направить его на меньшую модель, если только перекрытие кэша не делает большую модель быстрее. Это экономит вычислительные ресурсы без ущерба для качества.
- Burst в облако (Burst to cloud): Если локальные воркеры перегружены (более 2 запросов в очереди), трафик автоматически перенаправляется на внешние провайдеры, такие как AWS Bedrock. Это обеспечивает отказоустойчивость и масштабируемость.
- Конфиденциальность данных (PII stays local): Если запрос помечен тегом PII (Personally Identifiable Information), система исключает внешние провайдеры
Источник: MarkTechPost ↗