Загрузка GPU становится главным ограничением корпоративного ИИ

Автор проводит аналогию между авиацией и корпоративным ИИ. У самолёта расходы (лизинг, амортизация, страховка, обслуживание, экипаж) идут по календарному часу, а выручка, только по часу полёта; поэтому выживаемость авиакомпании исторически определял не размер флота, а доля времени, когда самолёты в воздухе. С GPU та же структура: расходы (финансирование, амортизация, электричество, охлаждение) идут по календарному часу независимо от загрузки, а отдача, только по часу полезных вычислений. Больше GPU, как больше самолётов: реальное преимущество, но не гарантия результата; при сопоставимых бюджетах на GPU компании расходятся именно по загрузке оборудования, а не по числу купленных чипов.

Автор описывает, как узкое место сместилось от моделей к вычислениям. В 2020 году Microsoft построила для OpenAI суперкомпьютер из более чем 10 000 GPU и 285 000 процессорных ядер, тогда одну из пяти крупнейших систем в мире, для обучения GPT-3. К 2026 году это выглядит уже не потолком, а стартовой точкой: Anthropic одновременно вела мультигигаваттные обязательства сразу на четырёх аппаратных платформах, Amazon, Google, Microsoft и AMD, а Meta подписала сопоставимую по масштабу сделку. Параллельные контракты с четырьмя поставщиками сразу, это то, как выглядит дефицит вычислений, когда у покупателя практически неограниченный капитал, но купить впрок всё равно не получается.

Для компаний, потребляющих модели через API, проблема не столько аппаратная, сколько ценовая: стоимость растёт линейно с числом токенов, и это резко отличает экономику пилотного проекта от экономики продакшена, то, что было доступно на нескольких тысячах запросов в месяц, на продуктовых объёмах превращается в неподъёмную статью расходов. Альтернатива, покупать собственные GPU и запускать модели локально, меняя переменные, растущие вместе с использованием, издержки на фиксированные капитальные; после точки безубыточности выгоднее свои GPU.

Но покупка оборудования не закрывает проблему, а открывает новую: кластер сажают под пиковую нагрузку, а значит бóльшую часть времени часть мощности простаивает. Дальше вскрывается более глубокое несоответствие: если раньше задачей GPU было в основном инференс, то сегодня то же оборудование обслуживает обучение, дообучение, квантование, инференс в реальном времени, пакетный (batch) инференс, генерацию эмбеддингов и оценку моделей, часто для одной и той же организации и даже одной модели на одном кластере. У каждой из этих задач разные требования: инференсу в реальном времени критична низкая задержка, пакетным задачам важна пропускная способность и они терпимы к отсрочке, обучение может занимать GPU непрерывно часами или сутками, квантование требует много мощности, но ненадолго. Планировщик, настроенный под одну из этих задач, почти неизбежно плохо распределяет остальные три, и это не всегда видно на дашборде загрузки: кластер может показывать высокую среднюю занятость, пока задачи в очереди ждут GPU конкретной конфигурации, которая занята чем-то другим.

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

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

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

Ключевые факты

• Аналогия с авиацией: расходы на GPU идут по календарному часу (финансирование, амортизация, электричество, охлаждение) независимо от использования, а отдача, только по часу полезных вычислений; больше GPU не гарантирует результата, если они простаивают
• Масштаб дефицита вычислений вырос кратно: в 2020 году суперкомпьютер Microsoft для OpenAI (10 000+ GPU, 285 000 ядер CPU) был одной из пяти крупнейших систем в мире; к 2026 году Anthropic одновременно вела мультигигаваттные обязательства на четырёх платформах (Amazon, Google, Microsoft, AMD), Meta подписала сопоставимую сделку
• Одно и то же оборудование сегодня обслуживает разнородные задачи, обучение, дообучение, квантование, инференс в реальном времени, пакетный инференс, эмбеддинги, оценку моделей, и планировщик под одну задачу плохо распределяет остальные
• В отличие от самолёта, который можно перебросить почти на любой маршрут, простаивающий GPU может забрать только нагрузку, подходящую по памяти, задержке и длительности, это делает оркестрацию сложнее, чем диспетчеризацию авиапарка
• Формируется новая дисциплина GPU Management, слой непрерывной автоматической оркестрации нагрузок; специализация моделей высвобождает мощность GPU, но она конвертируется в отдачу только при активном перераспределении, иначе становится новой формой простоя

Почему это важно

Материал фиксирует структурный сдвиг: первая волна корпоративного ИИ выигрывалась за счёт качества моделей, но по мере роста доступных вычислительных бюджетов конкурентное преимущество всё сильнее определяется не количеством купленных GPU, а тем, насколько эффективно они используются каждый час. Это меняет то, на что компаниям стоит смотреть при оценке своей ИИ-инфраструктуры, не только на объём закупленного железа, но и на дисциплину его загрузки.

Кому это важно

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

Как это применить

Автор советует не ограничиваться метрикой формальной занятости GPU («busy»), а отслеживать, действительно ли выполняемая работа приоритетна и полезна в моменте. Практический шаг, вводить слой оркестрации, который непрерывно распределяет нагрузки (обучение, инференс, дообучение, квантование и другие) по GPU с учётом их профиля задержки, памяти и длительности, а не полагаться на разовое планирование при закупке. Специализированные модели меньшего размера стоит использовать для высвобождения мощности, но обязательно сопровождать это активным перераспределением освободившихся ресурсов, иначе выигрыш не реализуется.

Можно ли доверять

Это авторский аналитический материал (эссе) в блоге на платформе Hugging Face, опубликованный от аккаунта Dharma-AI; имя автора и его должность в тексте не указаны. Изложенные фактические данные, про суперкомпьютер Microsoft для OpenAI 2020 года и про мультигигаваттные обязательства Anthropic и Meta в 2026 году, приводятся как общеизвестные отраслевые события без ссылок на первоисточники внутри текста, поэтому их стоит воспринимать как контекст авторской аргументации, а не как самостоятельно подтверждённые здесь цифры. Основной тезис материала, рассуждение и аналогия, а не результат эмпирического исследования или опроса.

Риски и подводные камни

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

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

— блог Dharma-AI на Hugging Face

Компания Meta Platforms признана экстремистской организацией, её деятельность на территории РФ запрещена.