AWS запускает SageMaker HyperPod Inference Gateway для маршрутизации с учётом GPU

Amazon Web Services объявила Amazon SageMaker HyperPod Inference Gateway 18 сентября 2026 г., нативную для Kubernetes, учитывающую GPU систему маршрутизации вывода больших языковых моделей, которая разворачивается как единый управляемый аддон для Amazon EKS на существующей инфраструктуре HyperPod. AWS заявила, что шлюз может сократить задержку первого токена до 82 %.

Проблема маршрутизации, стоящая за шлюзом

По словам AWS, стандартные алгоритмы балансировки нагрузки Kubernetes, такие как round-robin и least-connections, не имеют видимости состояния GPU: какие pod‑ы заполнили KV‑кеши, какие находятся в процессе генерации длинного контекста, и какие уже имеют загруженный в память LoRA‑адаптер, необходимый запросу. Компания заявила, что запросы накапливаются за занятыми pod‑ами, в то время как простаивающие ресурсы остаются неиспользованными, задержка первого токена скачет выше четырёх секунд при всплесках трафика, использование становится неравномерным и непредсказуемым, а операторы переоснащают системы для компенсации. AWS описала сценарий, в котором пользователь чат‑бота, ожидающий 4,4 секунды для первого токена, вместо этого получает его менее чем за 800 миллисекунд.

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

Шлюз использует двухуровневый дизайн, построенный на нативных примитивах Kubernetes. AWS заявила, что использует сигналы GPU в реальном времени, чтобы направлять каждый запрос вывода к наиболее подходящему pod‑у. Уровень 1 устанавливается непосредственно на каждый HyperPod или кластер EKS в виде аддона amazon-sagemaker-hyperpod-inference и состоит из трёх компонентов, все построены на открытом проекте Gateway API Inference Extension. Envoy Gateway, прокси уровня 7, завершает входящий HTTPS‑трафик и предоставляет единую приватную точку доступа на кластер. Body-Based Router анализирует тело каждого входящего запроса, совместимого с OpenAI, извлекает поле model и направляет запрос в соответствующий пул моделей, позволяя одному шлюзу обслуживать несколько моделей.

Endpoint Picker потребляет метрики Prometheus в реальном времени от каждого pod‑а, обслуживающего модели, и применяет взвешенный алгоритм оценки по оценщикам, охватывающим использование KV‑кеша, глубину очереди, наличие LoRA‑адаптера, коэффициент попаданий префикс‑кеша и количество активных запросов. Каждый оценщик имеет настраиваемый вес, позволяющий адаптировать поведение маршрутизации под конкретную нагрузку, например чат с чувствительностью к задержке против пакетной обработки, оптимизированной по пропускной способности.

Уровень 2, Global Inference Router, объявлен как ожидаемый в ближайшее время. AWS заявила, что добавит координацию всего флота между несколькими кластерами и регионами, с отказоустойчивостью между кластерами, глобальным ограничением скорости и формированием трафика с учётом стоимости. Уровень 2 построен поверх Уровня 1, при этом шлюз каждого кластера продолжает выполнять локальную маршрутизацию.

Развёртывание, обработка сбоев и наблюдаемость

Развёртывание состоит из единственной команды aws eks create-addon и одного декларативного пользовательского ресурса InferenceGatewayConfig, определяющего модели и поведение маршрутизации, при этом существующие развертывания серверов моделей обнаруживаются по меткам pod‑ов. AWS заявила, что установка не требует sidecar‑ов, сервис‑меша и изменений в коде приложений. Шлюз предоставляет стандартную точку доступа, совместимую с OpenAI, по протоколу HTTP; согласно AWS, существующий клиентский код работает без изменений, без изменения SDK и без подписи SigV4 для трафика вывода.

Для нагрузок, обслуживающих доработанные LoRA‑адаптеры на общей базовой модели, LoRA Affinity Scorer в Endpoint Picker направляет запросы адаптеров к pod‑ам, у которых запрошенный адаптер уже находится в памяти GPU; если ни один pod не имеет его загруженным, запрос направляется к pod‑у с наибольшей доступной ёмкостью. AWS заявила, что это устраняет задержку переключения адаптеров.

Документированные сценарии сбоев охватывают отказ pod‑ов, исчерпание пула, отказ кластера и региональный отказ. При отказе pod‑а Endpoint Picker исключает pod‑ы со старыми метриками и перенаправляет запросы к здоровым pod‑ам, автоматически восстанавливаясь, когда метрики возобновятся. При исчерпании пула шлюз возвращает HTTP 429 с заголовком Retry-After, пока автоскейлинг добавляет ёмкость. При отказе кластера Global Inference Router обнаруживает устаревший heartbeat и перенаправляет трафик в течение 35 секунд, постепенно увеличивая нагрузку при повторном вводе кластера в работу. При региональном отказе автоматически активируется маршрутизация между регионами, что, по словам AWS, приводит к более высокой задержке, но не влияет на доступность.

Шлюз генерирует метрики на уровнях pod, pool, cluster и fleet: использование KV‑кеша, глубина очереди, активные запросы и наличие адаптеров через Prometheus на уровне pod; суммарное количество запросов, гистограммы длительности и количество токенов через Prometheus и Grafana на уровне pool; среднее значение KV‑кеша, уровень ошибок и задержка P99 через Amazon CloudWatch на уровне кластера; а также решения о маршрутизации, события отказа и срабатывания ограничений скорости через CloudWatch на уровне флота.

Результаты тестов, опубликованные AWS

AWS заявила, что провела бенчмарки четырёх моделей с количеством параметров от 8 млрд до 235 млрд на инстансах p5.48xlarge с GPU H100 и инстансах g5 с GPU A10G. Весь трафик маршрутизировался через внутренние Application Load Balancers, соответствуя пути, по которому проходит запрос в продакшн, с выделенной группой клиентских узлов, генерирующей контролируемую нагрузку, и серверами моделей, изолированными в отдельной группе серверных узлов. Каждый результат получен с использованием конфигурации маршрутизации шлюза по умолчанию без настройки и измеряется относительно базового Kubernetes round-robin на тех же репликах моделей, согласно AWS.

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

AWS заявила, что при полностью однородном парке и стабильном трафике шлюз работает на уровне round-robin, а сопоставимые результаты определяются как различия, укладывающиеся в разброс между запусками. Компания отметила, что наибольшие улучшения наблюдаются там, где round-robin показывает наихудшие показатели: при смешанном оборудовании, всплесках нагрузки и общих префиксах запросов.

Доступность и дорожная карта

AWS описывает шлюз как соответствующий Kubernetes Gateway API и его расширению Inference Extension, настраиваемому через единственное пользовательское определение ресурса и совместимому с любым сервером моделей, совместимым с OpenAI, включая vLLM, SGLang и TGI. Управление осуществляется через kubectl, GitOps, Helm и ArgoCD, а установка, обновления и откат выполняются в рамках жизненного цикла дополнения EKS.

Маршрутизация уровня Tier 1 на уровне кластера доступна с 18 сентября 2026 года в регионах, где доступно дополнение Inference. Помимо Global Inference Router, в дорожной карте AWS указаны такие пункты, как канареечное разделение трафика, которое будет направлять часть запросов к новым версиям моделей с помощью пользовательских ресурсов InferenceModelRewrite, и управление потоком, классифицирующее запросы как Critical, Standard или Sheddable с контролем допуска по каждому диапазону.