GPU scheduling: как планировать загрузку GPU между inference, training и batch-задачами

GPU легко превращается в самый дорогой и самый нервный ресурс в инфраструктуре. Сегодня он отвечает на запросы пользователей, ночью обучает модель, а где-то сбоку еще крутится batch-обработка датасета, которую “надо было сделать еще вчера”. Если пустить все это самотеком, ускоритель быстро станет похож на перегруженный аэропорт: самолеты есть, взлетная полоса одна, а диспетчерская молчит.

Правильный GPU scheduling решает именно эту проблему. Он помогает заранее понять, какие задачи должны получить видеокарту прямо сейчас, какие могут подождать, какие стоит запускать ночью, а какие лучше изолировать на отдельном сервере. В итоге GPU работает не “когда получится”, а по понятным правилам: с приоритетами, лимитами, очередями и нормальной наблюдаемостью.

Что такое GPU scheduling простыми словами

GPU scheduling - это планирование доступа к графическим ускорителям между разными задачами. Не просто “кому досталась видеокарта, тот и работает”, а управляемая система распределения: кто стартует первым, сколько памяти может занять, можно ли делить один GPU, что делать при перегрузке и как не уронить production-инференс ради ночного эксперимента.

Представьте общую кухню в офисе. Inference - это люди, которым нужно быстро разогреть обед и вернуться к работе. Training - повар, который занял всю плиту на несколько часов. Batch-задача - курьер с коробками полуфабрикатов, которому надо все разложить, но не обязательно прямо в 12:00. Если расписания нет, кухня встает. Если есть понятные правила, все успевают.

С GPU происходит то же самое. Разные типы нагрузки конкурируют за одни и те же ресурсы: видеопамять, вычислительные блоки, PCIe/NVLink, CPU, RAM, диск и сеть. Ошибка в планировании часто выглядит не как красивый алерт, а как “почему модель внезапно отвечает 9 секунд?” или “почему обучение упало с CUDA out of memory?”.

Три типа GPU-нагрузки: почему их нельзя планировать одинаково

Главная ошибка - считать все GPU-задачи одинаковыми. На практике inference, training и batch-нагрузки ведут себя по-разному. У них разные требования к задержке, стабильности, памяти и предсказуемости.

Inference: важна задержка и стабильность

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

Для inference критична не только средняя скорость, но и “хвосты” задержки. Если 95 запросов из 100 отвечают за 300 мс, а 5 запросов зависают на 8 секунд, бизнес все равно почувствует боль. Пользователь не смотрит на красивый график среднего latency, он видит конкретную задержку в интерфейсе.

Мини-пример: интернет-магазин использует ML-модель для персональных рекомендаций. Во время распродажи запросов становится больше, и модель начинает делить GPU с экспериментальным training job. Средняя загрузка GPU выглядит нормальной, но latency рекомендаций растет. Формально сервер не “упал”, но конверсия уже просела.

Поэтому inference обычно получает высокий приоритет, отдельные лимиты и более аккуратный режим совместного использования GPU.

Training: важны длительность, память и повторяемость

Training - это обучение или дообучение модели. Такая задача может занимать часы, дни, иногда недели. Она часто потребляет почти всю доступную GPU-память и любит стабильную среду: один и тот же набор GPU, предсказуемую пропускную способность, минимум внезапных соседей.

Если inference похож на кассу в магазине, где очередь должна двигаться быстро, то training - это ремонт склада. Его можно запланировать, но нежелательно прерывать каждые десять минут.

Мини-пример: команда обучает модель компьютерного зрения на нескольких GPU. Посреди эпохи на тот же узел попадает batch-задача, активно читающая данные с диска. GPU вроде бы свободен по метрикам, но input pipeline начинает тормозить, обучение растягивается, а стоимость эксперимента растет без видимой причины.

Для training важны резервации ресурсов, checkpointing, прогноз времени выполнения и ограничение конкуренции с другими тяжелыми задачами.

Batch-задачи: важна пропускная способность и дешевое окно выполнения

Batch-задачи - это офлайн-обработка: массовая генерация эмбеддингов, пересчет признаков, обработка видео, прогон датасета через модель, рендеринг, аналитика. Обычно они не требуют ответа “прямо сейчас”, зато могут съесть много GPU-часов.

Хорошая новость: batch-нагрузки гибкие. Их можно ставить в очередь, запускать ночью, дробить на части, переносить между серверами и останавливать с сохранением прогресса.

Мини-пример: медиа-сервис должен каждую ночь обработать 2 млн изображений и пересчитать теги. Если дать batch-задаче такой же приоритет, как inference, утром пользователи могут получить медленный сервис. Если отправить ее в ночное окно с лимитом по GPU, задача выполнится без конфликта с production.

Batch - лучший кандидат на очереди, квоты, backfill и запуск в периоды низкой нагрузки.

С чего начинается грамотное планирование GPU

Планирование GPU начинается не с Kubernetes, Slurm или красивой панели мониторинга. Оно начинается с простой инвентаризации: какие задачи у вас есть и чего они боятся.

У каждой нагрузки стоит описать профиль:

сколько GPU нужно;

сколько GPU-памяти она обычно занимает;

насколько чувствительна к latency;

можно ли ее прерывать;

есть ли checkpointing;

сколько длится типичный запуск;

нужна ли изоляция от соседних процессов;

какие данные читает и куда пишет результат.

Это выглядит скучно, зато экономит деньги. Без такого профиля команда часто покупает “еще одну мощную видеокарту”, хотя проблема была не в нехватке GPU, а в том, что длинные задачи запускались в самое неподходящее время.

Хороший вопрос для старта: “Что сломается первым, если эта задача получит GPU на 30 минут позже?” Для inference ответ может быть “SLA”. Для training - “ничего, но эксперимент закончится утром”. Для batch - “почти ничего, главное уложиться до 06:00”. Вот вам уже три разных приоритета.

Базовая модель приоритетов

В реальной инфраструктуре удобно разделить GPU-нагрузки на несколько классов. Не обязательно усложнять с первого дня. Даже простая схема уже дает порядок.

Класс 1: production inference

Это сервисы, которые напрямую влияют на пользователей или бизнес-процессы. Они получают самый высокий приоритет.

Для них обычно задают:

гарантированную долю GPU или отдельные GPU;

лимиты по памяти;

autoscaling по очереди запросов, latency или custom-метрикам;

запрет на соседство с экспериментальными задачами;

отдельные алерты по p95/p99 latency.

Пример: LLM-чат, API для распознавания документов, recommendation service, антифрод-модель в checkout.

Класс 2: важный training

Это обучение моделей, которое важно для продукта или клиента, но не требует миллисекундной реакции.

Для него полезны:

очереди с приоритетом ниже inference;

выделенные временные окна;

checkpointing;

квоты по командам;

лимиты на одновременное количество экспериментов.

Пример: еженедельное дообучение модели рекомендаций или fine-tuning LLM под новую предметную область.

Класс 3: batch и фоновые задачи

Это все, что может подождать: массовая обработка, пересчет, рендеринг, тестовые прогоны, one-off jobs.

Для них хорошо работают:

FIFO-очереди;

запуск по расписанию;

backfill в свободные GPU-окна;

ограничение максимальной длительности;

preemption, если пришла более важная задача.

Пример: ночная генерация эмбеддингов для каталога товаров.

Класс 4: эксперименты и sandbox

Здесь живут исследовательские ноутбуки, ad-hoc тесты и “я только на пять минут”. Именно этот класс часто незаметно съедает дорогие ресурсы.

Для sandbox стоит задавать жесткие лимиты:

максимум 1 GPU на пользователя или проект;

автоостановка простаивающих сред;

запрет на запуск в production-очередях;

отдельные дешевые GPU или временные окна.

Иначе “пять минут” легко превращаются в процесс, который занимает GPU все выходные.

Как делить GPU: отдельный ускоритель, MIG, MPS и time-slicing

Когда задач становится больше, возникает соблазн делить один GPU между несколькими процессами. Это возможно, но важно понимать цену каждого подхода.

Отдельный GPU на задачу

Самый простой и предсказуемый вариант - одна задача получает один или несколько GPU целиком. Это удобно для production inference с жесткими SLA, крупного training и любых задач, где важна стабильность.

Плюсы понятны: меньше сюрпризов, проще диагностика, лучше изоляция. Минус тоже очевиден: если задача использует только 20-30% GPU, остальная мощность простаивает.

Пример: модель занимает 70 ГБ видеопамяти на GPU с 80 ГБ. Делить такой ускоритель почти бессмысленно. Любой сосед может привести к нехватке памяти или скачкам latency.

MIG: аппаратное разделение GPU

MIG, или Multi-Instance GPU, позволяет разделить поддерживаемый NVIDIA GPU на несколько изолированных инстансов. Каждый такой инстанс выглядит для приложения как отдельный “мини-GPU” с выделенной частью памяти и вычислительных ресурсов.

Это хороший вариант для multi-tenant inference, небольших моделей и ситуаций, где нужна предсказуемость. Например, один большой GPU можно разделить между несколькими сервисами, каждый из которых не требует всей мощности ускорителя.

Аналогия простая: вместо большого open space вы нарезаете офис на отдельные кабинеты. Да, каждый кабинет меньше, зато соседи не сидят у вас на столе.

Минусы тоже есть. MIG доступен не на всех GPU, требует аккуратной конфигурации и не всегда удобен для динамически меняющихся нагрузок. Если утром нужно 7 маленьких инстансов, а вечером 1 большой, придется продумать процесс переключения.

MPS: совместное выполнение CUDA-процессов

CUDA MPS помогает нескольким процессам эффективнее использовать один GPU. Это может быть полезно, когда задачи небольшие и по отдельности не загружают ускоритель полностью.

MPS подходит для controlled environment: например, несколько похожих inference-процессов с понятным профилем потребления. Но его не стоит воспринимать как магическую кнопку “делить GPU без риска”. Память, конкуренция за compute и поведение приложений все равно нужно тестировать.

Пример: у вас есть несколько легких моделей, каждая использует 10-15% GPU. На отдельном ускорителе они будут простаивать. Через MPS можно повысить utilization, но сначала стоит проверить latency под нагрузкой.

Time-slicing: делим время, но не изолируем память

Time-slicing позволяет нескольким workload получать “виртуальные” доли одного GPU по времени. Это удобно для разработки, sandbox-сред, легких batch-задач и ситуаций, где лучше хоть как-то поделить ресурс, чем держать его пустым.

Но time-slicing не дает такой же изоляции, как MIG. Если один процесс забрал слишком много видеопамяти, соседям станет плохо. Для production inference такой режим нужно использовать осторожно.

Хорошая бытовая аналогия - общий переговорный кабинет по расписанию. Пока все приходят вовремя и не оставляют вещи на столе, система работает. Но если кто-то занял комнату на весь день, расписание уже не спасает.

Как планировать inference

Inference нужно проектировать вокруг latency, очередей и предсказуемости. Высокий GPU utilization сам по себе не является победой. Если ускоритель загружен на 95%, но p99 latency улетает в космос, система работает плохо.

Держите production inference отдельно от хаоса

Самый надежный подход - выделить production inference отдельный пул GPU-узлов или отдельные MIG-инстансы. Тогда training и batch не смогут случайно повлиять на пользовательские запросы.

Мини-кейс: команда держала inference и offline processing на одном GPU-сервере. В спокойные часы все работало отлично. Но раз в день batch-процесс запускал тяжелую обработку, и API начинал отвечать медленнее. Решение оказалось не в покупке нового железа, а в разделении очередей и запрете batch-задач на inference-пуле.

Используйте batching, но не превращайте его в пробку

Batching помогает объединять несколько запросов в один пакет и эффективнее загружать GPU. Это особенно полезно для нейросетевых моделей, где обработка пачки запросов может быть выгоднее, чем одиночные вызовы.

Но batching - это баланс. Чем дольше система ждет, чтобы собрать пачку, тем выше задержка первого запроса. Для real-time API обычно задают небольшой max queue delay, а для offline inference можно позволить более крупные batch.

Пример: сервис распознавания изображений может собирать batch 8-16 запросов в течение нескольких миллисекунд. А ночной прогон 10 млн изображений может работать batch size 128 или 256, если хватает памяти.

Следите за p95 и p99, а не только за средним latency

Среднее значение часто успокаивает. p95 и p99 говорят правду. Именно они показывают, как чувствуют себя пользователи на пиках.

Для inference полезно мониторить:

request rate;

queue length;

p50/p95/p99 latency;

GPU utilization;

GPU memory used;

batch size;

ошибки CUDA OOM;

время холодного старта модели;

количество активных реплик.

Если очередь растет быстрее, чем GPU успевает обрабатывать запросы, нужно масштабироваться, уменьшать batch delay, переносить часть трафика или включать деградационный режим.

Не запускайте большие training jobs рядом с latency-critical API

Даже если GPU-памяти хватает, training может создавать шум: конкурировать за compute, CPU, RAM, диск и сеть. Иногда проблема не в GPU, а в том, что training активно читает датасет с того же NVMe, откуда inference подгружает артефакты.

Для production API правило простое: соседство должно быть осознанным, протестированным и обратимым. “Вроде работает” - слабая стратегия для сервиса, который видят клиенты.

Как планировать training

Training любит длинные непрерывные окна. Чем крупнее модель, тем дороже случайные остановки и тем важнее дисциплина планирования.

Запускайте training через очередь

Очередь лучше ручного подхода “кто первый успел подключиться к серверу”. Она делает инфраструктуру честнее: команды видят, кто и сколько ресурсов занимает, какие задачи ждут и почему.

В Kubernetes для batch/ML-нагрузок часто используют Kueue, Volcano, Kubeflow Training Operator и похожие инструменты. В HPC-средах сильную позицию сохраняет Slurm: он умеет управлять GPU как generic resources, задавать очереди, лимиты, приоритеты и правила распределения.

Мини-пример: у data science команды 8 GPU и 20 экспериментов. Без очереди люди договариваются в чате, забывают остановить процессы и спорят, чей запуск важнее. С очередью видно, какие jobs ждут, какие выполняются, кто превысил квоту и где есть свободное окно.

Делайте checkpointing обязательным

Checkpointing - это сохранение промежуточного состояния обучения. Он превращает сбой из катастрофы в неприятную паузу.

Для GPU scheduling это особенно важно. Если training можно безопасно прервать и продолжить, планировщик получает свободу: например, уступить GPU срочному inference-пику или перенести задачу на другой узел.

Простой ориентир: чем дороже эпоха обучения, тем чаще нужны checkpoint. Но слишком частые сохранения тоже могут тормозить процесс, особенно при медленном хранилище. Здесь нужен практический баланс.

Разделяйте dev, staging и production training

Не все training jobs одинаково важны. Одно дело - официальный retraining модели для production. Другое - эксперимент “проверим новую архитектуру на маленьком датасете”.

Хорошая схема:

production retraining - высокая очередь, резервируемые ресурсы, строгий мониторинг;

research training - обычная очередь, квоты по командам;

exploratory jobs - низкий приоритет, ограничение по времени, возможность preemption.

Так вы не запрещаете эксперименты, но и не позволяете им вытеснять важные задачи.

Учитывайте не только GPU, но и всю трубу данных

GPU может простаивать, если данные не успевают поступать. Training часто зависит от скорости диска, сети, CPU preprocessing и формата датасета.

Выглядит обидно: дорогой GPU загружен на 35%, команда думает о покупке второго ускорителя, а реальная проблема - датасет лежит на медленном сетевом хранилище или DataLoader работает в один поток.

Перед масштабированием training проверьте:

скорость чтения данных;

загрузку CPU;

RAM и page cache;

throughput сети;

размер batch;

использование mixed precision;

время на preprocessing;

баланс между GPU.

GPU scheduling без наблюдения за остальной системой похож на управление автомобилем только по тахометру.

Как планировать batch-задачи

Batch-задачи - самый благодарный тип нагрузки для оптимизации. Они редко требуют мгновенного ответа и хорошо переносят очереди, дробление и запуск по расписанию.

Дробите большие jobs на части

Одна огромная batch-задача неудобна для планировщика. Ее сложно переместить, долго перезапускать и трудно оценивать. Гораздо практичнее разбить работу на небольшие независимые chunks.

Пример: нужно обработать 50 млн изображений. Не запускайте один монолитный job на неделю. Разбейте датасет на партиции, сохраняйте прогресс, повторяйте только неудачные куски. Тогда свободные GPU-окна будут использоваться эффективнее.

Используйте ночные окна и backfill

Если днем GPU нужен inference, batch можно отправить в ночное окно. Если есть свободные промежутки между training jobs, batch может заполнять их через backfill.

Backfill - это как посадить пассажира на свободное место, пока основной рейс еще не готов к вылету. Главное, чтобы пассажир успел выйти до посадки приоритетной задачи.

Для этого batch-задачи должны быть:

прерываемыми;

короткими или разделенными на части;

с сохранением прогресса;

с понятной оценкой времени выполнения.

Давайте batch-задачам низкий приоритет по умолчанию

Batch легко захватывает инфраструктуру, потому что работы для него почти всегда много. Данные нужно пересчитать, видео перекодировать, эмбеддинги обновить, отчеты построить.

Поэтому низкий приоритет по умолчанию - здоровая практика. Срочный batch можно поднять вручную, но обычный фон не должен конкурировать с production inference.

Мини-кейс: команда запускала nightly batch без лимита. Иногда задача не успевала закончиться к утру и продолжала занимать GPU в рабочее время. После ввода дедлайна, лимита по параллельности и остановки при наступлении дневного окна влияние на API исчезло.

Kubernetes, Slurm или ручное управление: что выбрать

Выбор инструмента зависит от масштаба, команды и типа задач. Нет одного “правильного” варианта для всех.

Когда достаточно ручного подхода

Если у вас один GPU-сервер, пара моделей и небольшая команда, можно начать с простых правил:

systemd services или Docker Compose для inference;

cron для ночных batch-задач;

отдельные пользователи и лимиты;

nvidia-smi, DCGM Exporter и Grafana для мониторинга;

договоренность о расписании training.

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

Когда нужен Kubernetes

Kubernetes удобен, если GPU-нагрузки являются частью облачной платформы: микросервисы, API, autoscaling, CI/CD, много команд, разные окружения.

Для GPU в Kubernetes обычно используют:

NVIDIA GPU Operator;

NVIDIA device plugin;

node labels и taints;

resource requests/limits;

отдельные node pools;

MIG или time-slicing при необходимости;

Kueue или другие очереди для batch/ML jobs.

Пример: inference работает как сервис с несколькими репликами, batch-задачи запускаются как Kubernetes Jobs, а training - через отдельную очередь с квотами. Такой подход хорошо ложится на команды, которые уже живут в Kubernetes.

Когда нужен Slurm

Slurm силен в HPC, research и training-кластерах. Он хорошо подходит, когда пользователи запускают jobs через очередь, требуют несколько GPU/узлов, работают с длинными расчетами и привыкли к fair-share политике.

Slurm удобен для:

research-кластеров;

ML training;

batch processing;

multi-user окружений;

задач с четкими ресурсными заявками;

GPU как GRES/TRES ресурсов.

Пример: университетская лаборатория или ML-команда с большим количеством экспериментов. Пользователи отправляют jobs, планировщик распределяет GPU, учитывает приоритеты и квоты.

Когда лучше выделенные серверы

Иногда самый разумный scheduling - это физическое разделение. Production inference живет на одном выделенном GPU-сервере, training - на другом, batch - на третьем или запускается в свободные окна.

Такой подход особенно полезен, когда важны предсказуемость, простая диагностика и отсутствие “шумных соседей”. Выделенный GPU-сервер проще контролировать: весь ресурс принадлежит проекту, а планирование зависит от ваших правил, а не от чужих задач на общей платформе.

Для бизнеса это часто прагматичный вариант. Не нужно сразу строить сложный кластер. Можно начать с понятной архитектуры, а затем добавить Kubernetes, Slurm или систему очередей по мере роста.

Практическая схема распределения GPU

Ниже - рабочая схема, с которой можно стартовать без лишней теории.

Тип нагрузки

Приоритет

Где запускать

Можно ли прерывать

Как делить GPU

Production inference

Высокий

Отдельный pool или MIG

Обычно нет

Отдельный GPU, MIG, осторожный batching

Важный training

Средний/высокий

Training queue

Да, при checkpointing

Обычно целый GPU или несколько GPU

Research training

Средний

Shared training queue

Желательно да

Целый GPU, иногда time-slicing для маленьких тестов

Batch inference

Низкий/средний

Batch queue, ночные окна

Да

Целый GPU, MIG, time-slicing по ситуации

Sandbox/notebooks

Низкий

Dev pool

Да

Time-slicing, лимиты, автоостановка

Эта таблица не заменяет проектирование, но помогает быстро найти грубые ошибки. Если production inference оказался в одной очереди с sandbox notebook, стоит остановиться и пересмотреть правила.

Очереди, квоты и fair-share

Когда GPU-серверов становится несколько, простых договоренностей уже мало. Нужны очереди и квоты.

Очередь отвечает на вопрос: “Кто следующий?”. Квота отвечает на вопрос: “Сколько ресурсов команда может занимать?”. Fair-share добавляет справедливость: если одна команда долго использовала много GPU, ее новые задачи могут получить меньший приоритет, пока другие догоняют.

Пример из жизни: команда A обучает модели каждый день и постоянно занимает 6 из 8 GPU. Команда B запускает эксперименты редко, но для важного релиза ей нужно 2 GPU на вечер. Без fair-share команда B будет вечно ждать. С fair-share система учитывает историю потребления и распределяет ресурсы честнее.

Для небольших команд можно начать с простых квот:

production inference: резерв 2 GPU;

training: до 4 GPU одновременно;

batch: до 2 GPU днем и до 6 GPU ночью;

sandbox: максимум 1 GPU на пользователя.

Затем правила можно уточнять по метрикам.

Preemption: когда можно отобрать GPU

Preemption - это принудительное вытеснение менее важной задачи ради более важной. Звучит жестко, но без этого дорогие ресурсы часто простаивают или используются не там, где нужно.

Preemption хорошо работает для:

batch-задач с сохранением прогресса;

research experiments;

dev notebooks;

задач, которые легко перезапустить.

Плохо работает для:

production inference;

training без checkpointing;

jobs с долгим стартом и большим объемом временных данных;

процессов, которые после остановки оставляют неконсистентный результат.

Золотое правило: вытеснять можно только то, что умеет безопасно падать. Иначе вы не планируете ресурсы, а играете в рулетку.

Autoscaling GPU: полезно, но не волшебно

Autoscaling для CPU-сервисов давно стал привычным. С GPU сложнее. Ускорители дорогие, модели могут долго загружаться в память, а холодный старт иногда занимает заметное время.

Для inference autoscaling обычно строят не только по GPU utilization. Лучше смотреть на:

длину очереди запросов;

p95/p99 latency;

tokens per second для LLM;

requests per second;

количество активных сессий;

GPU memory pressure;

время обработки batch.

Пример: GPU загружен всего на 45%, но очередь растет. Значит, bottleneck может быть в CPU preprocessing, postprocessing, сети или слишком маленьком batch. Просто добавить еще GPU - не всегда правильный ответ.

Для training autoscaling чаще означает не мгновенное добавление реплик, а умное выделение узлов под jobs: пришла большая задача - планировщик нашел подходящий GPU-пул, выделил ресурсы, после завершения освободил.

Наблюдаемость: без метрик scheduling слепой

GPU scheduling нельзя настроить один раз и забыть. Нагрузка меняется: модель стала больше, датасет вырос, клиенты пришли из другого часового пояса, batch перестал укладываться в ночь.

Минимальный набор метрик:

GPU utilization;

GPU memory used/free;

temperature and power usage;

SM occupancy, если доступно;

PCIe/NVLink throughput;

encoder/decoder utilization для видео;

queue length по типам задач;

job wait time;

job runtime;

failed jobs;

CUDA OOM;

inference latency p50/p95/p99;

throughput модели;

стоимость GPU-часа на проект или команду.

Особенно полезна метрика “время ожидания в очереди”. Она показывает не только техническую загрузку, но и реальную боль пользователей инфраструктуры. Если training jobs ждут по 18 часов, команда будет искать обходные пути. Если inference очередь растет каждую пятницу вечером, значит, расписание batch-задач стоит пересмотреть.

Частые ошибки в GPU scheduling

Ошибки обычно повторяются. Хорошая новость - большинство из них легко поймать заранее.

Ошибка 1: смотреть только на GPU utilization

Высокая загрузка GPU не всегда хорошо. Низкая загрузка не всегда плохо. Для inference важнее latency и стабильность, для training - throughput эпохи, для batch - выполнение в дедлайн.

GPU utilization - только один прибор на панели.

Ошибка 2: смешивать production и эксперименты

Эксперименты нужны, но они не должны жить рядом с критичным API без ограничений. Один notebook с неудачным batch size может занять всю память и испортить день всей команде.

Ошибка 3: не вводить лимиты на sandbox

Dev-среды и notebooks любят забывать. Пользователь закрыл ноутбук, процесс остался. Через два дня кто-то спрашивает: “А кто занял GPU?”.

Автоостановка idle-сессий - маленькая мера с большим эффектом.

Ошибка 4: запускать batch “когда придется”

Batch-задачи должны знать свое окно. Если они могут подождать до ночи, пусть ждут. Если не могут, значит это уже не обычный batch, а задача с бизнес-приоритетом.

Ошибка 5: не считать стоимость ожидания

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

Пример архитектуры для небольшой AI-команды

Допустим, у компании есть несколько GPU-серверов и три типа задач:

API для inference, который работает 24/7;

обучение модели 2-3 раза в неделю;

ночной batch для пересчета эмбеддингов.

Практичная схема может выглядеть так:

Production inference получает отдельный GPU или MIG-инстансы.

Training запускается через очередь и не попадает на inference-пул.

Batch стартует ночью и останавливается утром, если не успел завершиться.

Все training jobs обязаны сохранять checkpoint.

Sandbox ограничен по времени и автоматически выключается при простое.

Метрики latency и queue length важнее красивого среднего GPU utilization.

Раз в неделю команда смотрит отчет: кто занимал GPU, сколько jobs ждало и где были провалы.

Это уже зрелая система. Не идеальная, не перегруженная, но управляемая. А управляемость в GPU-инфраструктуре часто ценнее, чем еще 10% теоретической производительности.

Пример архитектуры для роста

Когда нагрузка растет, можно двигаться к более формальной платформе:

Kubernetes для inference-сервисов и API;

отдельные GPU node pools по типам карт;

MIG для небольших production-моделей;

Kueue или похожий scheduler для batch jobs;

Slurm для исследовательского training-кластера, если команда работает в HPC-стиле;

централизованный мониторинг через Prometheus, DCGM Exporter и Grafana;

showback или chargeback по командам.

Showback - это отчет “кто сколько ресурсов использовал”. Chargeback - когда стоимость GPU-часов реально распределяется между командами или проектами. Даже если деньги внутри компании не переводятся, прозрачность быстро меняет поведение. Люди аккуратнее останавливают лишние jobs, когда видят цену простоя.

Как понять, что GPU scheduling работает хорошо

Хороший scheduling незаметен. Пользователи получают быстрый inference, training не стоит в очереди бесконечно, batch укладывается в окна, а инженеры не выясняют в чате, кто занял видеокарту.

Есть несколько признаков здоровой системы:

production latency стабилен даже во время batch-окон;

GPU простаивают меньше, но без ущерба для SLA;

пользователи понимают, почему их job ждет;

есть квоты и приоритеты;

training можно безопасно прерывать;

batch-задачи дробятся и перезапускаются;

стоимость GPU-часов видна по проектам;

новые workloads добавляются по правилам, а не “как-нибудь”.

Если эти пункты выполняются, инфраструктура уже живет не в режиме пожара, а в режиме плановой работы.

Практический чек-лист перед внедрением

Перед тем как менять инфраструктуру, полезно пройти короткий чек-лист.

На каждый вопрос лучше отвечать фактами, а не ощущениями. Если ответа нет, это не провал. Это точка, с которой начинается нормальная оптимизация.

Где здесь место GPU-серверам King Servers

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

На выделенном сервере проще разделить роли: один узел оставить под inference, второй использовать для training, третий подключать под batch или рендеринг. По мере роста можно добавить Kubernetes, Slurm, очереди, мониторинг и более тонкое разделение ресурсов.

Главное преимущество такого подхода - инфраструктура растет вместе с задачей. Не нужно сразу строить сложную платформу, если пока достаточно аккуратного расписания, лимитов и наблюдаемости. А когда нагрузка станет серьезнее, уже будет понятно, какие GPU нужны, где узкое место и какие правила scheduling действительно работают.

Итог

GPU scheduling - это не модная надстройка, а способ держать дорогой ресурс под контролем. Inference требует стабильности и низкой задержки. Training любит длинные окна, память и checkpointing. Batch-задачи лучше всего чувствуют себя в очередях, ночных расписаниях и прерываемых пайплайнах.

Хорошее планирование начинается с простых вопросов: что критично, что может подождать, что можно прервать и где нужна изоляция. Дальше появляются инструменты - Kubernetes, Slurm, MIG, MPS, time-slicing, очереди, квоты и мониторинг. Но основа остается человеческой: понятные правила, прозрачность и уважение к ресурсу.

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