# GPU в Kubernetes: как планировать CPU, RAM и ускорители вместе

Что проверить при размещении моделей в Kubernetes: запросы ресурсов, доступные GPU, ограничения хоста, готовность модели и влияние соседних задач.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-gpu-scheduling/
Language: ru

В кластере может отображаться свободный GPU, а модельный процесс всё равно не запускаться. Причина бывает в системной памяти, CPU, ограничениях узла или ещё неготовом окружении. Для владельца оборудования важно описать весь сервер, а финансовому партнёру — не считать кластерную ёмкость простой суммой карт.

## Разделите виды ресурсов

[Kubernetes документирует планирование GPU](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) через поддерживаемые механизмы устройств. [CPU и память контейнеров](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) имеют собственные requests и limits.

Это разные ресурсы одного задания. Системная RAM не является VRAM, а число виртуальных CPU не должно автоматически трактоваться как число физических ядер хоста.

До запуска запишите модель GPU, нужную память хоста, CPU, хранение и ограничения размещения. Утверждение «требуется одна карта» не описывает достаточную конфигурацию задания.

## Проверьте условный конфликт

Предположим, GPU доступен, но другие процессы заняли нужную RAM. Добавление ещё одной карты в такой узел может не увеличить число запускаемых моделей. Сначала нужно понять, какой совместный набор ресурсов требуется каждой реплике.

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

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

## Различайте запуск контейнера и готовность модели

Созданный процесс может ещё получать файлы, подготавливать память или прогреваться. Передавать ему пользовательский поток нужно по согласованному признаку готовности, а не только факту существования контейнера.

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

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

## Учтите неоднородность узлов

Разные GPU, архитектуры CPU и размеры памяти могут требовать разных условий размещения. Не направляйте одну конфигурацию на любой узел только потому, что общее число ускорителей достаточно.

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

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

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

## Критерии готовности к размещению

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

Для подготовки полезны [RAM и VRAM](/ru/journal/ram-vs-vram/), [разделение GPU](/ru/journal/gpu-mig-vs-time-slicing/) и [контейнеры против VM](/ru/journal/gpu-containers-vs-vms/).