В мире искусственного интеллекта и машинного обучения видеокарты NVIDIA стали золотым стандартом вычислений. Однако для многих платформ, управляющих кластерами Kubernetes, остается одной из самых болезненных проблем — неэффективное использование этих мощных ресурсов. Часто бывает так, что workload (рабочая нагрузка) требует лишь малой доли вычислительной мощности или памяти GPU, но для запуска ему выделяется целая карта. Это приводит к тому, что значительная часть дорогостоящего оборудования простаивает, а инфраструктурные команды не могут масштабировать свои AI-инициативы без покупки нового железа.
Решение, которое многие уже используют, — это шаринг GPU. Но традиционные методы, такие как MIG (Multi-Instance GPU) или простое time-slicing, часто не обеспечивают достаточной гибкости или безопасности. NVIDIA CUDA 13.4 и новый открытый оператор GPU Fractioning Operator, интегрированный с KAI Scheduler, предлагают революционный подход: Memory-Enforced GPU Sharing. Это технология, которая позволяет точно ограничивать потребление памяти на уровне каждого контейнера, делая шаринг не только возможным, но и безопасным, предсказуемым и эффективным.
01Почему существующие методы шаринга GPU недостаточны?
Прежде чем погружаться в технические детали CUDA 13.4, важно понять, какие проблемы решают новые инструменты. NVIDIA уже давно предлагает несколько способов разделения GPU:
- Multi-Instance GPU (MIG): Разделяет GPU на изолированные аппаратные экземпляры. Это отлично подходит для крупных, стабильных нагрузок, но негибко. Вы не можете легко изменить размер инстанса «на лету», и если workload меньше размера инстанса, ресурсы все равно тратятся впустую.
- Time-Slicing (по умолчанию в MPS): Позволяет нескольким процессам делить время работы GPU. Однако без жесткого контроля памяти один «прожорливый» контейнер может занять всю доступную память, вызывая крах других процессов или всей системы.
- Multi-Process Service (MPS): Позволяет процессам работать параллельно в разных адресных пространствах. Это повышает производительность, но исторически требовало сложной настройки и не всегда гарантировало изоляцию памяти на уровне Kubernetes.
Проблема заключалась в том, что Kubernetes сам по себе не имел встроенного механизма для принудительного применения этих ограничений на уровне драйвера. Планировщик мог решить, куда отправить под, но не мог гарантировать, что внутри ноды ресурсы будут использованы корректно. CUDA 13.4 закрывает этот пробел, добавляя enforcement (принудительное соблюдение) границ памяти, прозрачный для приложений.
02Что нового в CUDA 13.4: Точный контроль памяти
Выход CUDA 13.4 знаменует собой сдвиг парадигмы. Теперь разработчики и администраторы могут задавать не просто «запрос» памяти, а строгие границы. Вот ключевые возможности, которые предоставляет новая версия:
1. Точное количество памяти (Exact Memory Amount)
Workload запрашивает конкретный объем памяти. CUDA гарантирует, что этот объем будет зарезервирован. Если приложение попытается выделить больше, операция выделения памяти завершится ошибкой, точно так же, как если бы вы пытались выделить больше памяти, чем есть на физической карте меньшего размера. Это создает предсказуемую среду, критически важную для стабильности production-инференса.
2. Диапазон памяти (Guaranteed Minimum + Burstable Maximum)
Это, пожалуй, самая полезная функция для оптимизации затрат. Вы можете задать гарантированный минимум (request) и максимальный предел (limit). Например, workload может гарантированно получить определенный объем памяти, но если на GPU есть свободная память от соседей, он может «вырасти» до большего значения. Это позволяет эффективно использовать пиковые возможности оборудования без риска переполнения.
3. Выбор режима вычислений (Compute Mode)
Пользователи теперь могут явно выбирать между двумя режимами работы:
- Time-Slicing (по умолчанию): Рабочие нагрузки работают последовательно, деля время. Каждая нагрузка находится в своей «области ошибок» (error domain), что означает полную изоляцию. Если один процесс падает, это не влияет на другие.
- SM-Sharing (Parallel): Стриминговые мультипроцессоры (SM) делятся между нагрузками, и они работают параллельно. Это повышает пропускную способность, но все нагрузки делят одну область ошибок. Используется для доверенных workload, которые могут безопасно работать вместе.
03GPU Fractioning Operator: Мост между Kubernetes и CUDA
Сама по себе CUDA 13.4 предоставляет возможности, но Kubernetes не умеет ими управлять «из коробки». Нужен посредник, который будет читать инструкции от планировщика и применять их на уровне ноды. Здесь на сцену выходит GPU Fractioning Operator — новый open-source проект, размещенный в организации KAI Scheduler на GitHub.
Этот оператор работает в паре с NVIDIA GPU Operator. Его задачи:
- Настройка и поддержка службы Multi-Process Service (MPS) на каждой GPU-ноде.
- Применение ограничений памяти и режимов вычислений к каждому контейнеру перед запуском процесса.
- Мониторинг использования памяти и вычислительных ресурсов не для всей GPU, а для каждой ее «доли» (fraction).
Оператор не принимает решений о том, где запускать workload. Этим занимается планировщик. Оператор отвечает за то, чтобы как этот workload будет использовать ресурсы на выбранной ноде.
04Интеграция с KAI Scheduler: Режим NvFractions
Первым планировщиком, получившим полную поддержку GPU Fractioning, стал KAI Scheduler (версия 0.18.0 и выше). В нем добавлен режим NvFractions. Этот режим позволяет планировщику писать специфические аннотации в YAML-манифесты подов, которые GPU Fractioning Operator затем читает
Источник: NVIDIA Developer ↗