GPU-менеджмент: почему простаивающие ускорители стали «новыми самолетами на приколе»

Авиационная индустрия усвоила этот урок через жесткий опыт. На протяжении большей части истории отрасли числом, которое лучше всего предсказывало выживаемость авиакомпании, было время, проводимое каждым самолетом на земле. Причина этого носит фундаментально структурный характер. Расходы авиакомпании начисляются по календарному времени: лизинг, амортизация, страховка корпуса, плановое техническое обслуживание и контракты экипажей продолжают тикать вне зависимости от активности. Доход же авиакомпании начисляется исключительно за летный час. Каждый час, проведенный на земле, сокращает доходную часть уравнения, в то время как расходная остается неизменной. Уровень утилизации парка — это показатель, который стоит «ниже по потоку» практически всего, что делает авиакомпания. Дисциплина разворота в аэропорту, проектирование маршрутной сети, планирование техобслуживания, графики экипажей и доступность запчастей — всё это в конечном итоге отражается в одной цифре, потому что поломка в любом звене операционной цепочки удерживает самолеты на земле, несмотря на все остальные успехи. Разумеется, наличие большего флота помогает. Больше самолетов означает больше доступной емкости, это очевидно. Но две авиакомпании, летающие на сопоставимых флотах по схожим маршрутам, могут прийти к совершенно разным экономическим результатам, и большая часть этого разрыва прослеживается в одном показателе, а не в размере флота.

Корпоративный ИИ сегодня сталкивается с точно такой же структурной проблемой, но на другом типе оборудования. GPU также накапливает издержки по календарному времени через финансирование, амортизацию, затраты на электроэнергию и охлаждение — независимо от того, выполняет ли карта полезную работу в данный конкретный момент. Выходная мощность GPU также исчисляется только часами вычислений. Увеличение парка GPU помогает так же, как и у авиакомпаний: это дает реальную емкость, дает преимущество, но не гарантирует победу. Две компании с сопоставимыми бюджетами на GPU всё чаще расходятся по результативности, основываясь на том, какая часть их оборудования делает что-то полезное в любой момент времени, а не на том, сколько «железа» находится на балансе. Тот же самый показатель утилизации, как и в авиации, находится ниже по потоку почти любого инфраструктурного решения компании. На текущий момент интеллект продвинул отрасль достаточно далеко, но утилизация — это тот рубеж, где формируется следующее реальное ограничение. Дефицит не исчез по мере масштабирования ИИ, он переместился вверх по цепочке, сосредоточившись на совершенно ином ресурсе.

Эволюция ограничений: от качества моделей к утилизации мощностей

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

Масштабирование инфраструктуры как стратегический вызов

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

Переход от модели API к собственным вычислительным мощностям

Тот же паттерн проявляется и ниже по потоку от исследовательских лабораторий, но в другой форме. Предприятия, потребляющие модели через API, сталкиваются скорее с проблемой ценообразования, чем с нехваткой железа. Стоимость масштабируется линейно вместе с количеством используемых токенов, и этот факт полностью отделяет экономику экспериментального проекта (PoC) от экономики реального производства. Проект, обрабатывающий несколько тысяч запросов в месяц, выглядит доступным. Та же нагрузка в производственном масштабе может превратиться в статью расходов, которую невозможно покрыть. Набирающая популярность альтернатива проста: предприятия приобретают собственные GPU и запускают модели локально, обменивая переменные, линейно растущие затраты на фиксированные капитальные вложения. Стоимость API растет вместе с использованием, в то время как собственная инфраструктура остается почти фиксированной. После прохождения точки безубыточности торговля меняется в обратную сторону. Этот сдвиг превращает GPU в инфраструктуру, а не в линейную статью расходов, размеры которой теперь зависят от роста и пиковых нагрузок — а значит, она всегда немного превышает то, что действительно нужно в любую конкретную неделю. Это означает, что покупка оборудования не закрывает проблему, а открывает новую. В день, когда кластер начинает работу, вопрос перестает звучать как «можем ли мы получить ускорители?» и переходит в «можем ли мы занять их работой?», при том, что только на первый вопрос был назначен ответственный отдел закупок. Подписание контракта на оборудование имеет дедлайн и владельца. А недопущение простоя — это та часть, которая в конечном итоге тихо решает, стоило ли вообще совершать сделку.

Сложность оркестрации в мире гетерогенных нагрузок

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

Проблема многозадачности в едином кластере

Несоответствие начинается на слой глубже. В первом поколении корпоративного ИИ работа GPU была в значительной степени уникальной: выполнять инференс (вывод). Сегодня одно и то же оборудование поддерживает обучение, дообучение, квантование, вывод в реальном времени, пакетный вывод, создание эмбеддингов и оценку моделей — часто для одной и той же организации, иногда для одной и той же модели, на одном и том же кластере. Каждая из этих нагрузок требует от железа чего-то своего, и различия здесь глубоки. Вывод в реальном времени требует низких задержек выше всего остального, потому что медленный ответ считается неудачным. Пакетная работа заботится о пропускной способности и допускает задержки, иногда часами. Обучение может занимать GPU непрерывно на промежуток времени, измеряемый часами или днями. Квантование требует большого объема емкости, но лишь на короткий миг. Планировщик, настроенный на один из этих типов, будет неправильно распределять ресурсы для трех остальных по умолчанию. Неудача не всегда отображается на панели мониторинга утилизации: кластер может показывать высокую среднюю занятость, в то время как несколько заданий в очереди ждут GPU определенной конфигурации, которая в данный момент занята выполнением совершенно другой задачи. Состав рабочих нагрузок варьируется от организации к организации, но форма самой проблемы — нет.

Ограничения оркестрации в сравнении с авиацией

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

Синтез специализации и менеджмента

Максимизация ROI от GPU требует большего, чем разовое решение о закупке. Это требует постоянного активного управления самой инфраструктурой, выполняемого ежечасно, а не только в момент приобретения. В ответ на это формируется новая дисциплина — GPU Management, слой оркестрации, находящийся между рабочими нагрузками, моделями и оборудованием. Его задача — постоянно решать, какая задача выполняется, когда, как и на каком конкретном GPU в кластере. Ничего экзотического в концепции нет. Это ближе к тому, что хорошая операционная команда делает инстинктивно, просто это формализовано и работает непрерывно, вместо того чтобы зависеть от того, заметил ли кто-то проблему. Интеллект не останавливается на границе модели. Слой оркестрации принимает решения о распределении в реальном времени, о которых сама модель не имеет представления. Раньше интеллект почти полностью находился внутри модели: больше, лучше обучена, способнее — вот и вся игра. Теперь он должен присутствовать и в инфраструктуре, в слое, решающем «на лету», какая из нескольких конкурирующих задач получит освободившийся GPU и с каким приоритетом относительно всего остального в очереди.

Автоматизация как ключ к эффективности

Поддержание занятости GPU перестает быть целью самой по себе, поскольку занятость легко подделать, запуская низкоприоритетные задачи, которые могли бы подождать. Максимизация отдачи от каждого установленного GPU становится реальной целью, и это гораздо более непрерывная проблема, чем вопрос закупки, который был до этого. Качественное планирование не делает эту проблему исчезающей — оно меняет её форму. Решение о закупке принимается один раз. Решение о распределении принимается постоянно: каждый раз, когда работа завершается, когда приходит новый запрос, при каждом изменении приоритета между клиентским сервисом и внутренней тренировкой. Эта частота объясняет, почему решение перешло из области «человек рассматривает каждый случай отдельно» в «автоматизированный процесс». Ни один инженер не сидит перед панелью мониторинга в три часа ночи, чтобы решить, должен ли завершенный тренировочный запуск передать свой GPU задаче в очереди или придержать его для всплеска клиентского трафика. Кто-то другой должен делать этот выбор постоянно и делать его правильно достаточно часто, чтобы никто не нуждался в проверке. Дисциплина GPU-менеджмента настолько новая, что её инструментарий и конвенции всё еще формируются, и ни одного общего сценария пока не возникло.

Специализация и оркестрация как взаимодополняющие стратегии

Что стало понятно, так это то, куда сместилось ограничение. Специализация и оркестрация решают разные половины одной и той же проблемы. Специализированные, меньшие модели могут выполнять специфические задачи за долю ресурса, который потребовался бы большой универсальной модели, без потери качества. Это имеет прямой эффект на утилизацию. Рабочие нагрузки, которые когда-то требовали единую большую модель, занимающую большую часть кластера в течение всего времени работы, могут вместо этого выполняться на меньших, узкоспециализированных моделях, занимающих долю от прежнего следа. Емкость, которая была полностью расписана, внезапно освобождается. Количество емкости, которую высвобождает специализация, зависит от нагрузки, но освобожденная мощность должна куда-то деться, иначе она просто будет простаивать. Меньшая модель конвертируется в ROI GPU только если что-то активно решает, что произойдет дальше с освободившимся пространством, перераспределяя его на другую задачу или очередь. Оставленная без управления, высвобожденная мощность становится «другим вкусом» простоя, невидимым, но не менее продуктивным. Специализация без оркестрации высвобождает мощности, которые никто не востребует. Оркестрация без специализации имеет меньше мощностей, которые стоит востребовать в принципе. Ни один из рычагов не выполняет всю работу в одиночку. Каждый из них поднимает потолок того, чего может достичь другой рычаг. Ни то, ни другое не является опциональным, если цель состоит в том, чтобы действительно закрыть разрыв между установленной мощностью и полезным выходом, а не просто сместить место, где скапливаются отходы. Это причина, по которой архитектура модели и управление GPU — это два способа решения одной и той же проблемы, к которым подходят с двух сторон, опирающихся друг на друга. Одно сжимает то, что нужно каждой нагрузке. Другое постоянно решает, куда девается разница. Большой флот всегда был реальным преимуществом. Среди авиакомпаний с сопоставимыми флотами, иногда даже меньшая, сталкивающаяся с крупным соперником, побеждала, потому что летала более полно. Корпоративный ИИ приходит к той же дисциплине с другого направления. GPU уже установлены, уже амортизируются, уже куплены. Специализированные модели и GPU-менеджмент — это параллельные решения. Предприятия, которые освоят оба, будут задавать темп конкуренции в ИИ на ближайшее десятилетие.

Источник: huggingface.co