Авиационная индустрия узнала этот урок на собственном горьком опыте. На протяжении большей части своей истории ключевым показателем, предсказывающим выживаемость авиакомпании, была не скорость самолетов и не их комфорт, а то, сколько времени каждый воздушный судно проводило в воздухе, а не на земле. Причина кроется в самой структуре экономики отрасли. Затраты на самолет накапливаются с каждым календарным часом: финансирование, амортизация, страховка корпуса, плановое техническое обслуживание, контракты с экипажем. Доход же генерируется исключительно в часы полета. Каждый час, проведенный на земле, сокращает сторону «выход» в этом уравнении, в то время как сторона «затраты» продолжает работать с той же интенсивностью. Более того, коэффициент использования (utilization) находится в прямой зависимости от почти всех остальных решений, принимаемых авиакомпанией. Дисциплина оборота, проектирование сети маршрутов, планирование обслуживания, расписание экипажей и наличие запасных частей — все это в конечном итоге отражается на одном единственном числе: сколько времени самолет находится в воздухе. Если внутренняя операция сломана, самолеты будут оставаться на земле, несмотря ни на что.
Корпоративный искусственный интеллект сегодня сталкивается с той же структурной проблемой, но на другом типе оборудования. Графический процессор (GPU) также накапливает стоимость по календарному часу. Это финансирование, амортизация, электроэнергия и охлаждение — все это происходит независимо от того, выполняет ли чип какую-либо полезную работу в данный момент. Его выход (output) генерируется только в часы вычислений. Наличие большего количества GPU помогает так же, как увеличение флота помогает авиакомпании: это реальная мощность и настоящее преимущество. Однако это не гарантирует результата, который определяет победителя. Две компании с сопоставимыми бюджетами на GPU все чаще расходятся в эффективности не из-за того, сколько оборудования они владеют, а из-за того, какая часть этого оборудования выполняет полезную работу в любой данный момент. Этот показатель, подобно коэффициенту использования в авиации, находится «после» почти всех других инфраструктурных решений. Интеллект моделей довел индустрию до этого момента. Именно использование (utilization) становится следующим реальным ограничением.
01Узкое место сместилось от моделей к вычислениям
Дефицит не исчез по мере масштабирования AI. Он просто переместился вверх по цепочке, осев на совершенно другом ресурсе. Первая волна корпоративного AI была выиграна за счет качества моделей. Большие модели, обученные на большем объеме вычислений, оценивались по более сложным бенчмаркам: количество параметров и позиция в рейтингах доминировали в разговорах. Гонка привела к созданию моделей, которые стали достаточно хорошими для запуска реальных корпоративных рабочих нагрузок. Однако эта способность приходит с зависимостью. Корпоративный AI работает на специализированном оборудовании, и сегодня это оборудование — почти исключительно GPU.
GPU дороги, их предложение ограничено, а спрос превышает доступные мощности, и это верно даже для самого верхнего сегмента рынка. В 2020 году Microsoft построила для OpenAI выделенный суперкомпьютер: более 10 000 GPU и 285 000 ядер CPU. На тот момент это сообщалось как одна из пяти крупнейших систем в мире, собранная для обучения того, что стало GPT-3. Тогда это выглядело как почти невообразимая концентрация оборудования, число, которое заставляло вычислительные мощности казаться решенной проблемой для тех, кто мог получить к ним доступ. Шесть лет спустя это число читается скорее как стартовая точка, чем как потолок. К 2026 году даже самые капиталоемкие лаборатории рассматривали доступ к вычислениям как живую стратегическую проблему, а не как урегулированный вопрос. Anthropic, например, выполняла одновременные многогигаваттные обязательства перед четырьмя различными аппаратными платформами: Amazon, Google, Microsoft и AMD, накладывая их друг на друга в течение нескольких месяцев, в то время как Meta подписала аналогичную многогигаваттную сделку. Распределение обязательств между четырьмя поставщиками одновременно — это то, как выглядит дефицит вычислений, когда покупатель имеет практически неограниченный капитал, но все равно не может получить достаточно от любого единственного источника.
Шесть лет разницы между этими событиями отмечают границу того, что нужно лаборатории, чтобы оставаться конкурентоспособной. То, что изменилось за это время, имеет меньше общего с ростом возможностей AI и больше — с тем, что способность больше не является связующим ограничением. Та же картина наблюдается и за пределами лабораторий, в другой форме. Предприятия, потребляющие эти модели через API, сталкиваются с проблемой ценообразования, а не аппаратного обеспечения. Стоимость масштабируется линейно с количеством использованных токенов, и этот единственный факт полностью отделяет экономику концепта (PoC) от экономики производства. PoC, обрабатывающий несколько тысяч запросов в месяц, выглядит доступным. Та же рабочая нагрузка в производственном объеме может превратиться в строку затрат, которая никогда не исчезает. Альтернатива, набирающая популярность, достаточно проста: предприятия приобретают свои собственные GPU и запускают модели локально, обменивая переменную, линейно масштабируемую стоимость на фиксированную капитальную.
02Почему занятые кластеры все равно тратят ресурсы впустую
Кластер, полный занятых GPU, все еще может тратить большую часть своего потенциала, и причина почти всегда одна. GPU работают непрерывно, день и ночь, в то время как спрос на них не является постоянным. Инфраструктура должна быть рассчитана на пиковые нагрузки — момент, когда задачи обучения, пакетные задания и трафик реального времени накладываются друг на друга. Это оставляет значительную долю мощности, зарезервированную и неиспользуемую вне пиковых периодов. Лучшее прогнозирование могло бы решить эту проблему само по себе, если бы каждый GPU мог одинаково хорошо поглощать любой вид работы. Но немногие могут, и это оказывается более сложной половиной проблемы.
Несоответствие начинается на один уровень глубже. В первом поколении корпоративного AI задача GPU была в основном единой: запуск инференса. Сегодня то же самое оборудование поддерживает обучение, тонкую настройку (fine-tuning), квантование, инференс в реальном времени, пакетный инференс, генерацию эмбеддингов и оценку моделей, часто для одной и той же организации, иногда для одной и той же модели, на одном и том же кластере. Каждая из этих рабочих нагрузок хочет от оборудования чего-то разного, и различия глубоки. Инференс в реальном времени нуждается в низкой задержке выше всего остального, потому что медленный ответ считается неудачным. Пакетная работа заботится о пропускной способности и терпит задержки, иногда в течение часов. Обучение может занимать GPU непрерывно в течение периода, измеряемого часами или днями. Квантование требует большого объема мощности, но только на короткое время. Планировщик, настроенный на один из этих видов, по умолчанию будет неправильно распределять остальные три. Проблема не всегда проявляется на панели мониторинга использования. Кластер может сообщать о высокой средней занятости, в то время как несколько задач в очереди ждут GPU определенной формы, который занят выполнением чего-то другого.
Точный состав рабочих нагрузок варьируется в зависимости от организации. Форма проблемы не меняется. Здесь аналогия с самолетом достигает своего предела, и этот предел учит чему-то важному, а не просто уточняет сравнение. Простаивающий самолет обычно можно перенаправить на любой маршрут во флоте: Boeing 737, стоящий в Чикаго, может полететь в Денвер вместо Далласа без больших потерь. Простаивающий GPU может поглощать только ту рабочую нагрузку, профиль памяти, задержки и длительности которой он может фактически обслужить. Это различие делает оркестровку сложнее, чем планирование флота, и именно поэтому вопрос перестает быть «заняты ли GPU», а превращается в «какая рабочая нагрузка должна работать на каком GPU, в какое время, с каким приоритетом». Покупка еще одной стойки GPU добавляет мощность и стоимость, но не исправляет несоответствие, и эта новая мощность может оказаться в неправильной форме в неподходящий момент так же легко, как и уже установленная мощность.
03Интеллект перемещается в инфраструктуру
Максимизация возврата инвестиций (ROI) от GPU требует не однократного решения о выделении ресурсов. Это требует непрерывного, активного управления самой инфраструктурой, работающего каждый час, а не только во время закупки. В ответ на это формируется новая дисциплина — Управление GPU (GPU Management), слой оркестровки, расположенный между рабочими нагрузками, моделями и оборудованием. Его задача — непрерывно решать, какая рабочая нагрузка запускается, когда она запускается, как она запускается и на каком конкретном GPU в кластере. Ничего из этого не является экзотикой в концепции. Это ближе к тому, что хорошая операционная команда уже делает инстинктивно, просто формализовано и работает непрерывно, а не зависит от того, заметит ли кто-то проблему.
Интеллект больше не останавливается на границе модели. Слой оркестровки принимает решения о распределении в реальном времени, в которые сама модель не имеет видимости. Интеллект раньше находился почти исключительно в модели: больше, лучше обучена, более способна, и это было большей частью игры. Теперь он также должен находиться в инфраструктуре, в слое, решающем, момент за моментом, какая из нескольких конкурирующих рабочих нагрузок получает только что освободившийся GPU и с каким приоритетом относительно всего остального, ожидающего в очереди. Поддержание занятости GPU перестает быть целью само по себе, поскольку «занятость» легко симулировать за счет запуска низкоприоритетных работ, которые могли бы подождать. Максимизация возврата, генерируемого каждым установленным GPU, становится реальной целью, и это оказывается гораздо более непрерывной проблемой, чем вопрос выделения ресурсов, который был до нее.
Хорошее выделение ресурсов не устраняет эту проблему, а лишь меняет ее форму. Решение о выделении принимается один раз, в момент покупки. Решение о распределении принимается постоянно: каждый раз, когда задача завершается, каждый новый запрос поступает, каждый сдвиг в приоритете между сервисом, ориентированным на клиента, и внутренним запуском обучения. Эта частота объясняет, почему решение перешло от того, что человек обрабатывает случай за случаем, к тому, что должно работать автоматически. Ни один инженер не смотрит на панель мониторинга в три часа утра, чтобы решить, должна ли завершенная задача обучения передать свой GPU пакетной задаче в очереди или удержать его для входящего всплеска клиентского трафика. Что-то другое должно принимать это решение, непрерывно, и принимать его правильно достаточно часто, чтобы никто не нуждался в проверке.
04Специализация освобождает мощность; Оркестровка тратит её
Специализация и оркестровка решают разные половины одной и той же проблемы. Специализированные, более мелкие модели могут выполнять конкретные задачи за долю ресурсных затрат, которые потребовались бы большой универсальной модели для той же работы, не теряя качества, необходимого для задачи. Это оказывает прямое влияние на использование. Рабочие нагрузки, которые ранее требовали одной большой модели, занимающей большую часть мощности кластера на протяжении всей работы, теперь могут запускаться на меньших, специализированных моделях, занимающих лишь часть этого пространства. Мощность, которая раньше была полностью занята, внезапно становится свободной.
Однако сколько бы мощности ни освободила специализация, эта свободная мощность все равно должна куда-то деться, иначе она просто останется там. Меньшая специализированная модель превращается в ROI от GPU только в том случае, если кто-то активно решает, что делать дальше с освободившимся пространством, перераспределяя его другой рабочей нагрузке, другой модели, другой очереди, ожидающей позади нее. Если этим не управлять, освободившаяся мощность становится другой разновидностью простоя, невидимой по-другому, но не более продуктивной. Специализация без оркестровки освобождает мощность, которую никто не возвращает. Оркестровка без специализации имеет меньше мощности, которую стоит возвращать, потому что модели все еще большие, а пространство, которое они оставляют после себя, мало. Ни один из этих рычагов не делает всю работу в одиночку; каждый из них повышает потолок того, что может достичь другой рычаг. Ни один не является необязательным, если цель — действительно закрыть разрыв между установленной мощностью и полезным выходом, а не просто переместить место, где происходит расточительство.
05Практические шаги к эффективному управлению
Внедрение практики управления GPU не происходит в одночасье. Это требует сдвига мышления от «покупки железа» к «управлению состоянием». Во-первых, необходимо внедрить инструменты мониторинга, которые показывают не просто загрузку процессора, а загрузку памяти, пропускную способность шины и время ожидания в очереди. Во-вторых, архитектура должна позволять динамическое перераспределение ресурсов. Если задача обучения завершается, система должна автоматически проверять наличие задач инференса в реальном времени с высоким приоритетом, прежде чем передавать ресурсы пакетным заданиям. В-третьих, необходимо внедрить политики приоритизации, которые учитывают бизнес-ценность каждой задачи. Запрос от клиента всегда должен иметь приоритет над фоновым обучением, если только не настроены изолированные кластеры.
Кроме того, важно учитывать разнообразие аппаратного обеспечения. Как упоминалось выше, современные лаборатории работают с GPU от разных производителей (NVIDIA, AMD, Intel). Оркестровка должна быть абстрагирована от конкретного железа, чтобы позволять переносить задачи между разными типами ускорителей, если это экономически целесообразно и технически возможно. Это требует использования универсальных фреймворков, таких как PyTorch или TensorFlow, которые поддерживают кросс-платформенную компиляцию, и управления драйверами на уровне контейнеризации (например, через Docker или Kubernetes).
06Вызовы локального запуска в России
Для российских компаний, которые активно развивают собственные AI-инфраструктуры, вопрос управления GPU стоит особенно остро. В условиях ограничений на импорт новейших чипов NVIDIA H100/H200, многие компании转向 к использованию доступных альтернатив или к оптимизации существующих ресурсов. В этом контексте простои становятся еще более критичными. Если у вас есть ограниченный парк GPU, каждый час их простоя — это упущенная возможность для обучения моделей или обслуживания клиентов.
Локальный запуск моделей требует тщательного планирования. Важно использовать техники квантования (например, INT8 или INT4) для снижения требований к памяти и увеличения пропускной способности. Это позволяет запускать более крупные модели на меньшем количестве GPU. Однако, как мы выяснили, квантование само по себе не решает проблему, если нет системы, которая будет динамически распределять освободившиеся ресурсы. Российским компаниям стоит обратить внимание на open-source решения для оркестровки, такие как Kubernetes с плагинами для GPU, или специализированные платформы, которые могут работать в условиях ограниченных ресурсов.
07Будущее AI-инфраструктуры
Мы стоим на пороге новой эры, где «умные» модели становятся commodity, а «умная» инфраструктура становится конкурентным преимуществом. Компании, которые смогут эффективно управлять своими GPU, будут иметь возможность запускать больше экспериментов, быстрее выводить продукты на рынок и обслуживать больше клиентов при тех же затратах. Это не просто техническая оптимизация; это стратегическое решение. Как и в авиации, победителем станет не тот, у кого больше самолетов, а тот, кто лучше использует свои.
Дисциплина управления GPU все еще формируется. Нет единого playbook, который бы работал для всех. Однако принципы ясны: непрерывный мониторинг, динамическое распределение, специализация моделей и интеграция бизнес-логики в технические решения. Компании, которые овладеют обоими рычагами — специализацией моделей и управлением инфраструктурой, — зададут темп AI-конкуренции на следующее десятилетие.
08Что это значит на практике
Для руководителей и технических специалистов это означает необходимость пересмотра подходов к закупке и эксплуатации AI-инфраструктуры. Вот ключевые выводы:
- Оценка ROI по-новому: Не смотрите только на стоимость GPU. Смотрите на стоимость часа простоя. Инвестируйте в инструменты оркестровки, которые повышают коэффициент использования.
- Гибкая архитектура: Проектируйте системы так, чтобы они могли легко переключаться между задачами обучения, инференса и пакетной обработки. Изолируйте критичные к задержкам задачи, но позволяйте остальным делить ресурсы.
- Специализация: Не используйте большие модели для простых задач. Обучайте или настраивайте маленькие модели для конкретных задач, чтобы освободить ресурсы для более сложных работ.
- Автоматизация: Доверьте управление приоритетами и распределением ресурсов автоматизированным системам. Человеческий фактор слишком медленен для реагирования на изменения в реальном времени.
В конечном итоге, управление GPU — это не просто техническая задача. Это бизнес-стратегия. В мире, где вычислительные ресурсы ограничены, а спрос растет экспоненциально, эффективность использования этих ресурсов станет главным фактором успеха. Те, кто поймет это раньше, получат значительное преимущество.
Источник: Hugging Face ↗