Amazon SageMaker HyperPod Inference Gateway превращает балансировщик из сетевой формальности в инструмент управления стоимостью инференса. AWS заявляет снижение задержки до первого токена с 4,4 секунды до менее 800 мс. Если результат подтвердится на рабочей нагрузке, следующий заказ GPU разумно отложить до проверки новой маршрутизации.
Обычные алгоритмы Kubernetes, round-robin и least-connections, видят соединения, но не понимают, что происходит внутри модельного сервера. Запрос может попасть на pod с переполненным KV-кэшем, длинной очередью или незаконченной генерацией, пока соседний GPU простаивает. Команда компенсирует скачки задержки запасом мощностей и в итоге платит за оборудование, которое используется неравномерно.
Новый шлюз устанавливается как EKS managed addon в существующий кластер HyperPod. Он анализирует OpenAI-совместимый запрос, определяет модель и выбирает pod по метрикам из Prometheus. В расчёт входят загрузка KV-кэша, глубина очереди, число активных запросов, вероятность попадания в prefix cache и наличие нужного LoRA-адаптера в памяти GPU.
Последние два сигнала особенно важны для многомодельного инференса. Prefix cache позволяет повторно использовать уже обработанное начало промпта. А запрос к LoRA-адаптеру выгоднее отправить туда, где адаптер уже загружен, вместо дополнительной смены содержимого памяти. Вес каждого сигнала можно настроить: чат оптимизировать под задержку, пакетную обработку под пропускную способность.
AWS подчёркивает, что менять клиентский код и модельные серверы не нужно. Шлюз предоставляет стандартный HTTP endpoint с OpenAI-совместимой схемой. Однако совсем без настройки не обойдётся: deployments модельных серверов надо разметить, а модели и правила маршрутизации описать в InferenceGatewayConfig.
Практический вывод здесь не в обещанных 82%, а в смене порядка решений. Пользователю HyperPod стоит сначала включить addon и на своём профиле трафика сравнить загрузку GPU, очереди и задержку до первого токена. Только после этого пересчитывать необходимый запас мощности. Цифра AWS взята из её собственного блога и не гарантирует такой же эффект на любом кластере.
Есть и ограничение: сейчас шлюз принимает решения внутри отдельного HyperPod/EKS-кластера. Глобальная маршрутизация между кластерами и регионами, включая cost-aware распределение трафика и failover, у AWS пока обозначена как coming soon. Поэтому сегодня это рычаг локальной утилизации, а не готовая система управления всей GPU-инфраструктурой.