Почему корпоративные GPU простаивают и когда общий пул помогает

Корпоративный пул GPU не создаёт новые вычислительные мощности. Он объединяет ускорители разных команд в общую очередь, перераспределяет временно свободные ресурсы и при необходимости делит одну карту между несколькими задачами. Это может повысить загрузку уже купленного оборудования, но результат зависит от характера нагрузки, совместимости ускорителей, сети и хранилища.

11 ноября 2026 года российский разработчик «Базис» представил Basis Air — платформу для управления GPU-кластерами на разных площадках. Как сообщил CNews, разработчик оценивает возможный рост эффективности использования ускорителей с 30% до 80%. Это заявление поставщика, а не результат независимого испытания, поэтому его нужно рассматривать вместе с ограничениями общего пула.

Что происходит с корпоративными GPU

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

Есть и менее очевидная причина простоя. NVIDIA пишет, что инженеры часто запрашивают целый GPU, чтобы избежать конкуренции за ресурсы, хотя модель использует лишь 30–50% его памяти и вычислительных блоков. Для Kubernetes такая карта считается занятой независимо от фактической нагрузки.

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

Поэтому общий пул начинается с наблюдения за инфраструктурой. NVIDIA собрала для этой задачи открытый GPU Usage Monitor, объединяющий аппаратные показатели, сведения Kubernetes, Prometheus и Grafana. Система показывает, какие нагрузки удерживают ускорители, сколько памяти фактически занято и какие задачи стоят в очереди.

Как планировщик собирает общий пул

После инвентаризации ускорители перестают быть безусловной собственностью отдельных отделов. Администратор задаёт квоты, приоритеты и правила доступа, а команды указывают требования задачи: тип и число GPU, объём памяти и допустимое время ожидания.

Если подразделение не использует гарантированную квоту, планировщик временно передаёт её другой команде. Когда появляется приоритетная задача владельца, заимствованные ресурсы нужно вернуть. Простого правила «первым пришёл — первым получил» недостаточно: оно может загрузить кластер, но оставить критическую задачу без обещанной мощности.

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

Basis Air следует той же общей логике централизованного распределения. По описанию CNews, платформа управляет кластерами в разных подсетях и на разных площадках, учитывает квоты и приоритеты, сохраняет историю использования и предоставляет ресурсы через веб-интерфейс, API или командную строку. Её можно установить в центре обработки данных заказчика, включая изолированный контур без доступа к интернету.

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

Как делят один GPU и что показывают цифры

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

Альтернатива — NVIDIA Multi-Instance GPU, или MIG. На совместимых ускорителях технология создаёт аппаратно изолированные экземпляры с выделенными вычислительными блоками и памятью. По описанию AWS, один GPU можно разделить максимум на семь частей, хотя число и размеры доступных профилей зависят от модели карты.

MIG обеспечивает более предсказуемую производительность и изоляцию, но менее гибок. Конфигурацию нельзя менять, пока разделы заняты, а модели, которой требуется несколько GPU, всё равно нужны целые устройства. Объём памяти каждого раздела также фиксирован.

Испытание Lenovo подчёркивает разницу подходов: программное дробление быстро перенастраивается и подходит для лёгких или импульсных нагрузок, тогда как MIG полезнее там, где важны изоляция и стабильная производительность. Но тест использовал синтетическое умножение матриц, а не полный цикл обучения или инференса, поэтому его результаты нельзя считать универсальными.

«Базис» оценивает возможный рост эффективности использования GPU с 30% до 80%, а подготовку рабочей среды обещает сократить с месяца до одного-двух часов. Эти значения описывают ожидаемый эффект продукта и требуют проверки на инфраструктуре реальных заказчиков.

Более независимый ориентир даёт DeepShare. В экспериментах на 23 859 заданиях Venus и 3200 внутренних заданиях средняя загрузка достигла 70,58%. Это на 29,5% выше результата сильнейшего из сравнивавшихся неинтрузивных способов совместного использования. Средняя задержка в очереди сократилась на 46%, а на тестовом кластере из 16 GPU среднее время выполнения задания уменьшилось на 34%.

Но и эти цифры нельзя автоматически переносить на любую компанию. Пул помогает, когда пики команд происходят в разное время или задачи используют только часть карты. Если все подразделения одновременно обучают крупные модели, свободных ресурсов для перераспределения не останется.

Кто экономит и кто оплачивает сложность

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

Цена этой экономии — дополнительный инфраструктурный слой. Нужно поддерживать Kubernetes, драйверы и плагины устройств, мониторинг, роли доступа, квоты и профили разделения. Для MIG придётся заранее подобрать размеры экземпляров, а при программном совместном использовании — контролировать взаимное влияние нагрузок.

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

Альтернатива собственному пулу — облачная аренда. Она снимает необходимость покупать оборудование под редкие пики, но гибкость может стоить дороже. TechCrunch сообщал, что CoreWeave повысила цены примерно на 25% в июле и ещё на 10% позднее в квартале. Компания оценивает краткосрочные сделки более чем в $40 млн в год на мегаватт мощности, а новые контракты на четыре-пять лет — в $20–25 млн.

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

Что это меняет для российских компаний

Basis Air показывает появление на российском рынке отдельного класса систем управления ИИ-инфраструктурой, а не только облачной аренды и поставки серверов. Развёртывание в собственном центре обработки данных и работа без интернета важны для организаций, которые не могут передавать данные во внешний контур.

По опубликованному описанию, платформа поддерживает обучение, инференс, среды Jupyter и VS Code, Kubeflow и MLflow, а также существующие S3-совместимые и NFS-хранилища. Разработчик утверждает, что при синхронизации площадок центральному компоненту передаются служебные метаданные и показатели состояния, но не пользовательские наборы данных и артефакты моделей.

При этом показатели эффективности Basis Air приводит разработчик. Не опубликованы подробные результаты на разных поколениях ускорителей, при смешении обучения с инференсом и при объединении удалённых площадок. Поэтому заявление о росте эффективности до 80% следует считать целевым сценарием поставщика, а не гарантией.

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