Простаивающий GPU: где утекает бюджет ИИ-инфраструктуры

AWS выпустила надстройку Inference Gateway для Kubernetes-кластеров SageMaker HyperPod: без единой правки в коде приложений она режет задержку первого токена LLM-ответа до 82%.

Повод локальный - релиз одного облачного вендора, - но цифра обнажает вещь, которую редко считают: большая часть денег, потраченных на GPU для ИИ, уходит не на вычисления, а на простой дорогого железа в очереди.

Кластер GPU для LLM стоит десятки тысяч долларов в месяц, и почти вся сумма списывается по часам аренды, а не по числу обработанных токенов.

Стандартный Kubernetes-балансировщик распределяет запросы round-robin или по числу открытых соединений - метрикам, которые ничего не знают о состоянии самой модели.

Он не видит, у какого пода забит KV-кеш, какой под ещё дожёвывает long-context генерацию на десятки тысяч токенов, а у какого уже загружен в память нужный LoRA-адаптер.

Запрос улетает на занятый под и встаёт в очередь внутри GPU, пока счётчик аренды тикает на простаивающем соседнем.

Обе истории требуют одного класса решений - управляемого слоя между приложением и моделью.

На стороне маршрутизации GPU это шедулер с видимостью внутреннего состояния, как у HyperPod Inference Gateway.

На стороне доступа и аудита - LLM & Security Gateway, который логирует каждый вызов модели, разграничивает права по агентам и считает стоимость по отделам, а не одной строкой в счёте облака.

Для связи агентов с внутренними системами без десятка кастомных коннекторов годится MCP - единый протокол вместо связки самописных интеграций под каждый инструмент.

Для событийной маршрутизации между источниками данных и агентами - Apache Kafka, чтобы не гонять запросы синхронно и не класть цепочку сервисов при пиковой нагрузке.

Это и есть AI-native integration: инфраструктуру проектируют под агентов и модели с первого дня, до того как эти системы попадут в прод.