Общий GPU-пул: где заканчивается квота и начинается задержка ответа

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

Red Hat 20 октября описала priority-aware serving в Red Hat AI 3.5: порядок запросов при насыщении пула определяется через llm-d flow control. Kubernetes 14 октября показал расследование допуска Kueue через Headlamp; описанный плагин имеет alpha-статус и отдельные представления только для чтения. Ai2 9 октября объяснила переход к бюджетам GPU-времени и fair-share. NVIDIA 15 октября разобрала размещение Muse Spark Open на GB300 NVL72, включая разделение prefill и decode. Речь о разных слоях, а не готовом совместном стеке.

Три очереди под одним словом «ожидание»

Задача может ждать разрешения использовать квоту ещё до появления Pod. Затем допущенная задача может ждать подходящего узла. Уже запущенный модельный сервер может задерживать отдельный запрос из-за потока соседних клиентов. Добавление узла помогает далеко не во всех трёх ситуациях.

Полезная связь новостей состоит в разделении дефицита. Kueue делает видимой границу допуска. Подход Ai2 задаёт экономический смысл распределению времени между командами. Управление запросами в serving-слое распределяет уже доступную производительность между потребителями. Аппаратная архитектура и раскладка вычислений определяют, сколько этой производительности получится извлечь.

Когда эти уровни согласованы, общий пул может принимать ночные задачи на свободной мощности и отдавать приоритет дневному интерфейсу. Компании не нужно резервировать полный пик отдельно для каждого типа работы. Однако обещание срока пакетной обработки должно учитывать, что при длительной интерактивной нагрузке свободного окна может не оказаться.

Приоритет имеет цену для соседей

Высокий приоритет полезен только как ограниченный ресурс. Если каждая команда может объявить все запросы срочными, иерархия теряет смысл. Бюджет времени и согласованный класс обслуживания превращают спор о срочности в управляемый выбор: какой продукт получает мощность и чем за это платят остальные.

Выделенный пул остаётся разумным вариантом, когда нагрузка требует жёсткой изоляции, длительных непрерываемых вычислений или отдельной конфигурации модели. Его цена: запас мощности, который не всегда можно отдать другим. Общий пул уменьшает этот запас, но требует способности выдерживать очереди и управлять справедливостью.

Prefill и decode также нагружают систему по-разному. Обработка длинного входа и последовательная выдача токенов не обязаны иметь один аппаратный профиль. Разделение может повысить эффективность специализированных ресурсов, но добавляет передачу состояния, маршрутизацию и эксплуатационную сложность. Оно оправдано после измерения собственной смеси запросов, а не только по максимальной скорости на диаграмме производителя.

Условный проект: чат днём, документы ночью

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

Если чат стал медленным, а пакетные задания ещё не допущены, проблема не обязательно в конкуренции с ними. Если допущенные задачи не размещаются, нужно проверять ограничения узлов. Если очередь существует внутри работающего serving-пула, перестановка квот Kueue может не изменить ответ пользователю. Такое разделение позволяет вложить деньги в нужное узкое место.

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

Близкая прикладная основа описана в статье о фоновых задачах. Инфраструктурный кейс Debian в Google Cloud даёт контекст сопровождения приложения. При обсуждении инфраструктуры начните с типов нагрузки и сроков результата: аппаратный выбор следует из них.