В этом материале
InferencePool и выбор воркеров LLM: совместимость, устаревшие метрики и граница маршрутизации относительно фактического исполнения модели.
Обычный балансировщик распределяет запросы по здоровым endpoint, не обязательно понимая длину входа и уже знакомый воркеру контекст. Inference-aware gateway добавляет сведения, значимые для исполнения модели. Kubernetes Gateway API Inference Extension предоставляет API и точки интеграции для этой задачи, но сам языковую модель не исполняет. Появление ресурса маршрутизации не означает появление готового вычислительного сервиса.
Определите невидимое балансировщику
Перечислите доступные сейчас сведения: соединения, число запросов, готовность и специальные метрики backend. Длинная генерация и короткий запрос имеют существенно разный остаток работы, хотя оба могут учитываться как одно соединение или одно обращение.
Введение Inference Extension объясняет специализацию проекта. До установки определите недостающее решение. Если простой набор реплик уже выполняет цель нагрузки, усложнённый выбор воркера остаётся гипотезой для проверки, а не автоматическим увеличением полезной ёмкости сервиса.
Разберитесь в InferencePool и picker
Документация InferencePool описывает группу исполняющих endpoint и её связь с выбором назначения. Ресурс объявляет участников и сведения интеграции. Он не является чекпойнтом модели, выделением GPU или самим движком исполнения, поэтому эти части развёртывания нужно проектировать отдельно.
Нарисуйте gateway, picker и воркеры модели раздельно. Отметьте обычную HTTP-обработку и решение по состоянию инференса. Внешний маршрутизатор моделей и провайдеров — ещё одна граница. Ясное владение предотвращает предположение, что установка gateway одновременно устанавливает поддерживаемый runtime для любой LLM.
Согласуйте реальные версии
Используйте справочник API выбранной версии ресурса и сопоставьте его с реализацией gateway и образом picker. Принятие ресурса Kubernetes не доказывает интерпретацию всех полей контроллером и наличие каждой необязательной функции оценки кандидатов.
Запишите метрики, аутентификацию и обнаружение воркеров. Проверьте объявление правильной модели и точности, а не только успешную проверку здоровья. Здоровый, но неподходящий воркер не должен получать запросы модели, которую он не способен обслужить, даже при свободной памяти и пустой очереди.
Проверьте устаревшее и отсутствующее состояние
Используйте трассу коротких чатов, длинных входов, популярных префиксов и уникальных запросов. Сравните новую политику с прежней на том же пуле и расписании. Сопоставьте предсказанную нагрузку с фактической очередью и задержкой первого токена на конкретном назначении.
Затем прервите доставку метрик, перезапустите воркер и добавьте ёмкость. Наблюдайте скорость обновления решений и резервную политику без телеметрии. Локальность не должна продолжать отправку на перегруженный или исчезнувший endpoint только потому, что раньше там находился полезный префикс.
Измерьте результат сервиса
Запишите полезные завершения, хвост задержки, дисбаланс воркеров и расходы маршрутизации. Сохраните правило успеха между политиками. Ровное число обращений не обязательно лучше, когда запросам нужны разные вычисления и доступны разные возможности повторения контекста.
Зафиксируйте совместно проверенные gateway, extension, picker и движок. Для провайдера это внутренняя маршрутизация, дополняющая выбор провайдера внешней платформой. Расширение не следует представлять конкурирующей площадкой токенов или доказательством возможности исполнять одну тесно связанную модель на любом наборе GPU распределённой сети.
Материалы по теме
Prefix caching: когда повторяющийся контекст помогает GPU-пулу, Очередь vLLM: как ограничить backlog запросов и prefill-токенов.