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, пул, кластер та флот: використання KV‑кешу, глибина черги, активні запити та резидентність адаптера через Prometheus на рівні pod; сумарна кількість запитів, гістограми тривалості та кількість токенів через Prometheus і Grafana на рівні пулу; середнє використання KV‑кешу, рівень помилок та затримка P99 через Amazon CloudWatch на рівні кластера; а також рішення про маршрутизацію, події відмовостійкості та кількість спрацьовувань обмежень швидкості через CloudWatch на рівні флоту.

Результати бенчмарків, повідомлених AWS

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

У повідомлених результатах змішаний парк GPU різних поколінь скоротив час до першого токена (latency) P95 і P99 на 97 % для Llama-3.1-8B, збільшивши пропускну здатність на 8 %, і на 98 % та 97 % для Qwen3-32B, підвищивши пропускну здатність на 50 %. При сплесковому навантаженні Llama-3.1-70B продемонстрував скорочення P95 і P99 на 94 % і 98 % при збільшенні пропускної здатності на 12 %, тоді як Qwen3-235B показав порівнянну затримку P95 і на 89 % нижчу P99. При спільних префіксах підказок затримка 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 з контролем доступу в межах кожної смуги.