Уроки авиации: Почему время простоя GPU стало главной проблемой бизнеса

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

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

От борьбы за качество к борьбе за утилизацию

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

К 2026 году даже лучшие капитализированные лаборатории планеты рассматривают доступ к вычислениям как «живое» стратегическое ограничение, а не как что-то окончательно решенное. Одна только компания Anthropic одновременно выполняла обязательства по мощности в несколько гигаватт на четырех аппаратных платформах: Amazon, Google, Microsoft и AMD, причем соглашения заключались с разницей в несколько месяцев, а Meta подписала сопоставимую многогигаваттную сделку. Распределение обязательств между четырьмя поставщиками одновременно — именно так выглядит дефицит вычислительных мощностей, когда покупатель обладает практически неограниченным капиталом, но все равно не может получить достаточно ресурсов из одного источника. Шесть лет спустя оба этих события ознаменовали границы того, что необходимо лаборатории просто для сохранения конкурентоспособности. Изменилось не то, что ИИ стал мощнее, а то, что способность моделей перестала быть единственным связующим ограничением.

Экономика масштаба и ловушка капитальных затрат

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

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

Сложность оркестровки и лимиты аналогий

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

Специфика GPU как производственного ресурса

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

GPU Management как новая дисциплина

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

Автоматизация распределения ресурсов

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

Баланс между специализацией моделей и инфраструктурой

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

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