AWS представила Inference Gateway для SageMaker HyperPod: GPU-осознанная маршрутизация вместо round-robin

Что объявила AWS

AWS представила Amazon SageMaker HyperPod Inference Gateway — Kubernetes-нативный, GPU-осознанный слой маршрутизации инференса, который разворачивается как один управляемый EKS add-on на уже существующей инфраструктуре HyperPod. Компания формулирует цель прямо: убрать простаивающие GPU и снизить задержку первого токена, не меняя при этом модельные серверы и клиентские приложения.

Проблема, ради которой сделан gateway, — в неосведомлённости штатных балансировщиков Kubernetes. Round-robin и least-connections не видят, что происходит внутри GPU: у каких подов переполнен KV-кэш, какие находятся в середине длинной генерации с большим контекстом и у каких уже загружен в память нужный LoRA-адаптер.

Результат AWS описывает так: round-robin заставляет запросы скапливаться за занятыми подами, пока свободная ёмкость остаётся неиспользованной; во время всплесков трафика задержка первого токена подскакивает до 4 секунд и более, утилизация GPU становится неравномерной и непредсказуемой, а чтобы это компенсировать, приходится закупать лишние ускорители.

Два уровня архитектуры

Tier 1 — это gateway на уровне кластера, который устанавливается как управляемый EKS add-on и состоит из трёх компонентов. Envoy Gateway работает как высокопроизводительный L7-прокси, терминирует входящий HTTPS-трафик и выставляет единственный частный endpoint на кластер. Body-Based Router (BBR) разбирает тело OpenAI-совместимого запроса, извлекает поле `model` и направляет запрос в нужный пул моделей — так один gateway обслуживает несколько моделей. Endpoint Picker (EPP) — слой принятия решений: он читает метрики Prometheus от каждого пода в реальном времени и взвешенным скорингом выбирает лучший бэкенд.

В скоринге EPP учитываются утилизация KV-кэша, глубина очереди запросов, резидентность LoRA-адаптера, доля попаданий в префикс-кэш и количество активных запросов; каждый параметр имеет настраиваемый вес, поэтому поведение маршрутизации можно подгонять под профиль нагрузки — от чувствительного к задержке чата до оптимизированного по пропускной способности батча.

Документация AWS уточняет детали конвейера: BBR читает поле `model` из тела запроса, разворачивает имя LoRA-адаптера в его базовую модель и проставляет заголовки `X-Gateway-Model-Name` и `X-Gateway-Base-Model-Name`, после чего gateway сопоставляет их с HTTPRoute и отправляет запрос в `InferencePool` нужной модели. Уже внутри пула Endpoint Picker выбирает под, оценивая кандидатов по метрикам модельного сервера — глубине очереди и утилизации KV-кэша — вместе с префикс-кэшем и резидентностью LoRA-адаптера. Каждая запись в `spec.schedulers` запускает собственный Endpoint Picker.

Tier 2 — Global Inference Router (GIR) — пока анонсирован как «coming soon»: он добавит координацию на уровне всего парка между кластерами и регионами, межкластерный failover, глобальное ограничение частоты запросов и маршрутизацию с учётом стоимости. Второй уровень строится поверх первого: локальная интеллектуальная маршрутизация в каждом кластере продолжает работать.

Что показывают бенчмарки AWS

AWS протестировала четыре модели от 8B до 235B параметров на инстансах p5.48xlarge (H100) и g5 (A10G), направив весь трафик через внутренние Application Load Balancer — то есть по тому же пути, которым идёт продакшн-запрос. Нагрузку генерировала отдельная клиентская группа узлов, а модельные серверы работали изолированно на своей группе узлов, чтобы исключить конкуренцию за ресурсы при высокой параллельности.

Все результаты получены на конфигурации маршрутизации по умолчанию, без ручной настройки, и сравниваются с Kubernetes round-robin на тех же репликах моделей. В сценарии со смешанными поколениями GPU на Llama-3.1-8B показатели TTFT P95 и P99 снизились на 97%, пропускная способность выросла на 8%; на Qwen3-32B — минус 98% и 97% по задержке первого токена и плюс 50% по пропускной способности.

При всплесковом трафике на Llama-3.1-70B задержка первого токена упала на 94% (P95) и 98% (P99) при росте пропускной способности на 12%; на Qwen3-235B P99 улучшился на 89%, а P95 и throughput AWS называет сопоставимыми. На общей префиксной части промпта у Llama-3.1-8B улучшение составило 26% по P95 и 43% по P99 при сопоставимой пропускной способности, а на однородном парке под ровной нагрузкой Qwen3-235B различия оказались в пределах разброса между прогонами.

Важная оговорка по цифрам из заголовка анонса: «снижение задержки первого токена до 82%» AWS иллюстрирует примером, где пользователь чат-бота, ждавший первый токен 4,4 секунды, получает его менее чем за 800 мс. То есть 82% относится к этому примеру, а не к средней или гарантированной величине; в собственной таблице AWS приводит и куда большие значения — до 97–98% по P95 и P99 в отдельных сценариях.

Отказы и наблюдаемость

Поведение при сбоях описано по уровням. Если падает под, EPP исключает из выбора поды с устаревшими метриками и направляет трафик на здоровые, возвращаясь к ним автоматически, когда метрики снова идут. При исчерпании пула gateway отвечает HTTP 429 с заголовком Retry-After, а ёмкость добавляет автомасштабирование. При отказе кластера GIR замечает устаревший heartbeat и перенаправляет трафик в течение 35 секунд, после чего постепенно возвращает нагрузку на восстановленный кластер; при отказе региона межрегиональная маршрутизация включается автоматически — растёт задержка, но доступность не страдает.

Наблюдаемость покрывает четыре уровня: поды отдают утилизацию KV-кэша, глубину очереди, число активных запросов и резидентность адаптеров в Prometheus; пулы — суммарные запросы, гистограммы длительности и число токенов в Prometheus и Grafana; кластер и весь парк — среднюю утилизацию KV-кэша, долю ошибок, P99-задержку, решения маршрутизации, события failover и срабатывания лимитов в Amazon CloudWatch.

Как разворачивается и на чём построено

Установка описана как один add-on плюс декларативный ресурс `InferenceGatewayConfig`: сайдкары, service mesh и правки кода приложения не нужны. Gateway выставляет стандартный OpenAI-совместимый endpoint, поэтому существующий клиентский код работает без изменений, а трафику инференса не требуется подпись SigV4 — достаточно обычного HTTP. В документации тот же ресурс назван единственной точкой описания gateway: в нём задаются общий Body-Based Router, TLS и прочие параметры.

Ключевая деталь позиционирования: Inference Gateway не заменяет HyperPod Inference Operator, а строится поверх него. Оператор продолжает управлять развёртыванием моделей, а gateway добавляет перед подами LLM-осознанный слой маршрутизации; при этом сам gateway не зависит ни от конкретного модельного сервера, ни от оркестратора и поставляется через тот же EKS add-on для HyperPod Inference.

Технологическую основу AWS описывает как открытый проект Kubernetes: gateway построен на Gateway API Inference Extension и сохраняет совместимость с официальным Gateway API и его Inference Extension. Сам проект Inference Extension — официальный проект Kubernetes, который оптимизирует самостоятельный хостинг генеративных моделей и расширяет шлюзы вроде Envoy Gateway до inference gateway. До этого релиза у HyperPod уже были свои политики маршрутизации — prefix-aware, kv-aware и session, — так что новый gateway не первая попытка решить задачу распределения запросов внутри кластера.

Отдельно AWS напоминает, почему установка стала проще: раньше клиентам приходилось вручную создавать IAM-роли и политики, S3-бакеты и VPC-эндпоинты и ставить несколько Kubernetes-операторов, а теперь все эти требования закрывает одно действие.

Что дальше и что осталось за рамками

В планах AWS перечисляет Tier 2 Global Inference Router, canary-сплит трафика через ресурсы `InferenceModelRewrite` и управление потоком с приоритетными полосами Critical, Standard и Sheddable вместе с admission control по полосам. Tier 1 доступен уже сегодня — но только «в регионах, где доступен inference add-on»; конкретного списка регионов в анонсе нет.

Публикация не приводит воспроизводимого набора бенчмарков: сценариев, конфигураций и сырых измерений в ней нет, а цифры получены AWS на её собственной инфраструктуре и на конфигурации по умолчанию. Значит, 97–98% и «до 82%» — заявления вендора, а не результат независимой проверки, и переносить их на свой парк без собственного замера нельзя.

Не раскрыты и детали второго уровня: сроки появления Global Inference Router, его цена и ограничения по регионам в анонсе не указаны — GIR описан только как будущая возможность.