Очередь задач для AI-инференса может расти даже в кластере с незанятыми GPU — проблема не в дефиците железа, а в том, как оно распределяется между нагрузками. Планирование GPU в Kubernetes становится отдельной инженерной задачей: оно определяет, получит ли сервис ускоритель вовремя или будет ждать, пока подходящий узел формально освободится. Об этом сообщает The New Stack, рассматривая новые подходы cloud-native сообщества к агентным AI-нагрузкам.
На первый взгляд ситуация выглядит странно: дорогие ускорители есть, заявки на вычисления есть, а полезной работы меньше, чем могла бы быть. На практике Kubernetes по умолчанию хорошо умеет размещать контейнеры по ресурсным запросам, но AI-инференс добавляет слишком много условий. Нужны определённый тип GPU, объём памяти, совместимый драйвер, модель в кеше, подходящая топология сети и иногда — соседство с конкретным набором сервисов. Свободная карта на другом узле не всегда помогает задаче, которая ждёт здесь и сейчас.
Для команд это уже не академический спор о качестве scheduler-а. GPU-инфраструктура стоит дорого, а задержка в очереди напрямую влияет на разработчиков, внутренних пользователей AI-сервисов и клиентов продукта. Если кластер занят мелкими или плохо упакованными задачами, новая важная нагрузка может не стартовать даже при видимом запасе мощности. Если же размещать задачи слишком агрессивно, растут риски конкуренции за память и непредсказуемых задержек в ответах моделей.
Агентные системы усиливают эту проблему. В отличие от одного предсказуемого API-вызова, агент может запускать цепочку обращений к моделям, инструментам и базам данных. Пики нагрузки возникают неровно, а время исполнения отдельных шагов заранее известно плохо. Для обычного автоскейлинга это неудобный сценарий: он привык реагировать на метрики после того, как нагрузка уже появилась. Инфраструктуре для AI нужно не только добавлять реплики, но и решать, какой работе отдать дефицитный ускоритель и когда разумнее подождать.
В центре обсуждения оказывается не просто доступ контейнера к GPU, а политика распределения. Одним задачам нужен быстрый старт — например, интерактивному пользовательскому запросу. Другие могут потерпеть в очереди: пакетная обработка документов, тесты моделей или ночные прогоны. Без явных приоритетов они легко конкурируют за один и тот же пул как равноправные, хотя цена задержки у них совершенно разная. Поэтому планирование GPU в Kubernetes всё чаще связывают с очередями, приоритетами, квотами и более точным учётом реального состояния ускорителей.
Есть и вторая ловушка: формально выделенный ресурс не всегда означает полезную загрузку. Модель может ждать данных, сеть — отвечать медленно, а процесс — держать GPU в резерве с минимальной фактической работой. С точки зрения кластера карта занята; с точки зрения бизнеса она почти не производит результат. Значит, наблюдаемость должна показывать не только число выделенных устройств, но и очередь запросов, занятость памяти, время ожидания, длительность инференса и долю простаивающих ресурсов. Иначе команда будет масштабировать кластер, не понимая, что упирается в правила размещения или архитектуру приложения.
Для российских команд вывод вполне прикладной. Прежде чем расширять GPU-пул, стоит проверить, какие нагрузки действительно требуют ускорителя, как настроены requests и limits, есть ли отдельные очереди для онлайнового и пакетного инференса и можно ли высвободить ресурсы за счёт более короткоживущих воркеров. Не менее важно договориться о владельцах квот: без этого общий кластер быстро превращается в систему, где каждый резервирует мощность «на всякий случай», а общий счёт за инфраструктуру растёт вполне конкретно.
Новый этап развития Kubernetes для AI, вероятно, будет измеряться не числом подключённых GPU, а тем, насколько хорошо платформа принимает решения между конкурирующими задачами. Планирование GPU в Kubernetes перестаёт быть деталью эксплуатации: для продуктов с моделями оно становится частью управления стоимостью, скоростью ответа и надёжностью сервиса. Главный вопрос теперь не «сколько ускорителей купить», а «кто и по каким правилам получит следующий свободный».
