Когда использование графического процессора обманчиво: проблема скрытых систем, замедляющая развитие современного ИИ.

Почему показатель «средней загрузки» не отражает реальную степень заполнения ваших видеокарт.

Делиться

В 2:00 ночи команда разработчиков инфраструктуры получает уведомление о внезапном увеличении задержки при выполнении инференции на 60%. Панели мониторинга отображаются некорректно. Использование графических процессоров по-прежнему выглядит удовлетворительно:

• 79%,
• 82%,
• 84%.

Кажется, ничего катастрофически не происходит. Включается автоматическое масштабирование. Добавляются новые узлы. Счет за облачные услуги растет. Задержка практически не улучшается.

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

Подобные сбои становятся все более распространенными в современной инфраструктуре ИИ. И они обнажают более глубокую иллюзию, скрывающуюся под многими системами генерации искусственного интеллекта:

Графические процессоры могут быть заняты, но при этом не приносить пользы.

Это различие кажется незначительным. В финансовом плане это может означать миллионы долларов.

Современные системы искусственного интеллекта со стороны выглядят безупречно. Пользователь отправляет запрос в ChatGPT от OpenAI, Claude от Anthropic или Gemini от Google и через несколько секунд получает отточенный ответ. Но за этим скрывается огромная проблема координации.

Графические процессоры выполняют тензорные операции. Центральные процессоры обрабатывают запросы и перемещают данные. HBM хранит активации и кэш ключ-значение. SSD-накопители передают потоковые эмбеддинги и контекст извлечения. Сети распределяют градиенты и трафик вывода между узлами. Системы хранения обрабатывают перестроения, повторные попытки и фоновую работу.

Где-то посередине всего этого планировщик решает, где должны выполняться рабочие нагрузки. Этот планировщик незаметно определяет, будет ли кластер вести себя как целостная вычислительная система или как дорогостоящая пробка.

В этой статье рассматривается геометрическая упаковка с учетом остаточных значений (RAGP), представленная в работе Каарата и др., и исследуется, почему современным планировщикам ИИ все чаще необходимо учитывать пропускную способность хранилища, нагрузку на ввод-вывод и динамическое поведение ресурсов, а не рассматривать графические процессоры как изолированные вычислительные устройства.

Суть проблемы гораздо шире, чем просто один алгоритм планирования. Это системная проблема. И все чаще она становится и экономической проблемой.

Иллюзия использования

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

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

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

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

Фрагментация: невидимый режим отказа

Рассмотрим три узла после всплеска смешанных нагрузок GenAI:

Теперь предположим, что поступила новая задача по выводу данных, требующая:

• умеренный графический процессор,
• умеренный HBM,
• достаточная пропускная способность хранилища,
• и достаточная пропускная способность ввода-вывода.

В рамках всего кластера по-прежнему имеется достаточное количество общих ресурсов.

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

Это фрагментация ресурсов. Кластер не пуст. Он фрагментирован на неиспользуемые ресурсы, которые трудно эффективно применять.

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

Кластер может иметь резервные графические процессоры и растущие очереди.

Это самая нелогичная часть всей проблемы. Кластер может одновременно обладать следующими свойствами:

• запасные видеокарты,
• увеличение времени ожидания в очереди,
• ухудшение латентного периода,
• и снижение пропускной способности.

На первый взгляд, это звучит противоречиво. Но это не так.

Если единственные «свободные» графические процессоры находятся на узлах, пропускная способность хранилища которых уже перегружена, глубина очереди SSD-накопителей резко возрастает или ресурсы ЦП ввода-вывода заняты фоновой работой, то эти графические процессоры становятся практически недоступны для следующей полезной рабочей нагрузки.

Жадный планировщик все равно может размещать там задания. Эти задания затем

• беги медленнее,
• усилить конкуренцию,
• увеличить время ожидания в очереди.
• и оставить после себя еще большую фрагментацию.

Это создает порочный круг: больше фрагментации → больше задержек → увеличение времени выполнения → еще больше фрагментации. На панели управления кластер по-прежнему выглядит загруженным. В операционном плане система постепенно начинает задыхаться.

Почему GenAI изменил ландшафт узких мест

Традиционные планировщики были разработаны для сред, где решения о размещении ресурсов в значительной степени принимались на основе ЦП, памяти, графического процессора и сети. Современные системы GenAI изменили характер нагрузки на инфраструктуру:

• Процессы, требующие интенсивного извлечения данных, могут привести к перегрузке пропускной способности SSD-накопителей.
• В процессе выполнения задач вывода данных кэш ключ-значение накапливается с течением времени.
• Загрузка контрольных точек может сильно нагрузить хранилище объектов.
• Многомодальные рабочие нагрузки приводят к прерывистому перемещению данных.
• Фоновые задачи обслуживания незаметно отнимают ресурсы ЦП, которые в противном случае были бы задействованы для работы с графическими процессорами.
• Снижение производительности хранилища на уровне узла может привести к уменьшению эффективной пропускной способности задолго до того, как узел технически выйдет из строя.

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

Даже при недостаточном объеме вычислительных ресурсов видеокарта остается дорогой видеокартой.

Вот тут-то и начинаются серьезные экономические вопросы. Современная инфраструктура для ИИ обходится дорого. Цены на доступ к NVIDIA H100 в 2026 году обычно варьируются от нескольких долларов за час работы графического процессора до значительно более 10 долларов в час, в зависимости от провайдера и модели обязательств.

Теперь масштабируйте это на большой флот.

Кластер H100, состоящий из 1000 графических процессоров и работающий со средней себестоимостью примерно 3 доллара США в час на один графический процессор, обходится приблизительно в:

• 3000 долларов в час.
• 72 000 долларов в день.
• и около 26 миллионов долларов в год.

до учета затрат на сетевое взаимодействие, хранение данных, оркестрацию и проектирование.

Теперь представьте, что фрагментация и задержки ввода-вывода незаметно тратят всего 10% продуктивного времени работы графического процессора.

В итоге это выглядит примерно так:

• 300 долларов в час.
• 7200 долларов в день.
• и около 2,6 миллиона долларов в год.

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

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

Планирование с учетом остаточных значений

Большинство планировщиков задают обманчиво простой вопрос:

«Поместится ли эта рабочая нагрузка на данном узле?»

Планирование с учетом остаточных значений задает более важный вопрос:

«Какой вид остаточного кластера образуется в результате такого размещения?»

Эта идея лежит в основе геометрической упаковки с учетом остаточных значений (Residual-Aware Geometric Packing, RAGP), предложенной в работе Каарата и др. Вместо того чтобы сводить узел к нескольким скалярным счетчикам, RAGP рассматривает остаточную емкость как многомерную форму.

В общих чертах:

1. Неподходящие узлы исключаются.
2. Планировщик имитирует оставшиеся ресурсы после их размещения.
3. Предпочтение отдается размещению ресурсов, оставшиеся в наличии которых могут быть использованы для будущих рабочих нагрузок.

Этот последний шаг имеет огромное значение.

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

Один конкретный пример

Предположим, что поступающая рабочая нагрузка требует:

• сбалансированный графический процессор,
• сбалансированная HBM,
• умеренная пропускная способность хранилища,
• и наличие достаточного количества процессорных ресурсов.

После предварительного распределения рабочей нагрузки:

Скалярный планировщик может считать оба варианта размещения приемлемыми, потому что:

• Графический процессор по-прежнему доступен.
• память остается доступной,
• и объем работы технически соответствует требованиям.

При планировании с учетом остаточных значений предпочтение отдается узлу А.

Почему?

Потому что узел B оставляет после себя практически непригодную для использования емкость хранилища.

Это становится опасным, как только появляется следующая нагрузка, требующая интенсивного извлечения данных или увеличения размера кэша. Это скрытая ошибка, характерная для многих современных кластеров GenAI: размещение может быть локально осуществимым, но при этом глобально вредным.

Расширение функциональности RAGP до RAGP-I/O

Первоначальная формулировка RAGP основывалась главным образом на следующих соображениях:

• ПРОЦЕССОР,
• БАРАН,
• Вычисления на графическом процессоре,
• ХБМ,
• и налаживание связей.

Это неплохо работало в средах, где преобладали вычислительные мощности.

Внедрение рабочих нагрузок GenAI изменило ситуацию с узкими местами в системе.

В реальных системах:

• Конфликт на SSD-накопителе,
• глубина очереди хранения,
• ухудшенное состояние RAID,
• давление извлечения,
• и насыщение ЦП при вводе/выводе

может влиять на пропускную способность так же сильно, как и само использование графического процессора.

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

RAGP-I/O расширяет пространство планирования за счет явного включения следующих элементов:

• пропускная способность хранилища,
• и процессор ввода/вывода

В логику планирования заложены как вопросы осуществимости, так и вопросы размещения. Вместо пяти измерений, планировщик использует семь: ЦП, ОЗУ, GPU SM, HBM, сеть, пропускная способность хранилища и ЦП ввода-вывода.

Концептуально это звучит как небольшое расширение. Однако на практике это существенно меняет поведение планировщика, как только объем памяти становится активным ограничением.

Симулятор, воплощенный в бетоне

Производственные кластеры ИИ представляют собой сложную среду для безопасного тестирования экспериментальных планировщиков. Для оценки поведения планировщика в контролируемых условиях в работе используется синтетический дискретно-событийный симулятор.

В состав симулятора входят:

Наиболее показательными являются сценарии с высокой нагрузкой на хранилище данных.

• Сценарий C : примерно 10–20% узлов в любой момент времени остаются в состоянии восстановления RAID, что снижает эффективную пропускную способность хранилища.
• Сценарий D : добавляется «дышащая» обработка заданий, использование HBM и потребность в хранилище которых постепенно возрастают со временем, имитируя расширение KV-кэша, поэтому размещение, которое кажется безопасным на начальном этапе, может стать проблематичным позже.

Это на удивление хорошо отражает реальные системы искусственного интеллекта.

Самый важный результат

Самый важный результат заключается не просто в том, что «RAGP-I/O обеспечивает меньшую фрагментацию». Более глубокий вывод состоит в следующем:

Как только объем памяти и ввод-вывод становятся доминирующими ограничениями, разумные планировщики систематически вводятся в заблуждение, если эти параметры игнорируются.

Это более широкое понимание системы в целом.

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

Что показывают эксперименты

В сбалансированных, импульсных и ресурсоемких сценариях RAGP-I/O неизменно демонстрировал следующие результаты:

• более низкая степень фрагментации,
• снижение моделируемой задержки GPU,
• более здоровая остаточная емкость
• и более стабильное поведение пропускной способности

по сравнению со скалярной балансировкой, упаковкой в стиле Тетриса и вариантом RAGP-5D, нечувствительным к вводу/выводу.

Наибольший прирост производительности наблюдался при нагрузке на хранилище. В экспериментах с нагрузкой на хранилище средняя фрагментация для RAGP-I/O оставалась примерно в диапазоне 0,04–0,06, в то время как базовые показатели были ближе к 0,09–0,12. Моделируемое замедление работы графического процессора резко снизилось, в некоторых случаях приближаясь к нулю для RAGP-I/O, оставаясь при этом значительным для других планировщиков.

В сценарии D наблюдается та же закономерность в более жестких условиях: RAGP-I/O поддерживает низкий уровень фрагментации, значительно сокращает общее количество задержек на графическом процессоре и сохраняет пропускную способность в том же диапазоне, что и более простые планировщики.

Результат, дающий предостережение, не менее важен. RAGP-5D по-прежнему показывает лучшие результаты, чем более простые базовые модели, но как только объем памяти становится доминирующим ограничением, игнорирование ввода-вывода делает планировщик частично неинформированным. Геометрическая интуиция хороша. Однако видимость неполная.

Затор: Дорогостоящий невидимый налог

Сама по себе фрагментация не является оперативной проблемой. Более болезненным симптомом является застой.

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

В результате анализа рабочей нагрузки могут быть выявлены следующие признаки:

• высокая загрузка графического процессора,
• и здоровое использование памяти,

в то время как ядра тратят значительное время в ожидании:

• перемещение запасов
• извлечение,
• или перегруженные конвейеры обработки данных на стороне ЦП.

На практике команды, отвечающие за инфраструктуру, часто замечают проблему на уровне поведения еще до того, как определят ее на уровне метрик.

Некоторые узлы просто:

• «Чувствую себя проклятым»
• создают более шумную задержку,
• или неожиданно ухудшить работу соседних рабочих нагрузок.

Иногда команды начинают вручную отключать эти узлы задолго до того, как на панелях мониторинга становится ясно, почему это происходит.

Обычно это признак скрытой конкуренции где-то на пути передачи данных.

Компромиссы действительно существуют.

Планировщик, учитывающий операции ввода-вывода, не бесплатен. Добавление новых параметров приводит к следующим изменениям:

• дополнительные требования к телеметрии,
• более сложная система планирования,
• повышенная чувствительность к устаревшей информации о состоянии узлов.
• а также потенциальная нестабильность размещения, если показатели ресурсов быстро меняются.

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

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

Урок по более масштабным системам

В конечном итоге, эта статья посвящена не только планировщикам. Она о поведении систем. Здоровые системы определяются не только уровнем использования ресурсов. Они определяются скоординированным потоком данных. Эта закономерность встречается повсюду:

• транспортные системы,
• цепочки поставок,
• распределенные базы данных,
• облачная инфраструктура,
• и финансовых рынков.

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

За чем командам, отвечающим за инфраструктуру, следует следить более внимательно.

Одного лишь использования графического процессора уже недостаточно. Для серьезного мониторинга инфраструктуры GenAI все чаще требуется прозрачность в отношении:

• Давление HBM,
• потребление пропускной способности хранилища,
• глубина очереди SSD,
• Увеличение времени выполнения по сравнению с ожидаемой продолжительностью,
• Использование ЦП для ввода-вывода,
• деградировавшие состояния хранения,
• а также замедление работы на уровне узлов относительно ожидаемого времени завершения.

Если на определенных узлах выполнение задач постоянно замедляется на 20%, 30% или 40%, несмотря на, казалось бы, нормальные показатели загрузки, планировщик должен обрабатывать эти узлы по-другому. Именно здесь часто кроется скрытая неэффективность.

Для мониторинга инфраструктуры GenAI в серьезных условиях все чаще требуется прозрачность в отношении:

• Давление HBM,
• потребление пропускной способности хранилища,
• глубина очереди SSD,
• Инфляция во время выполнения
• Использование ЦП для ввода-вывода,
• деградировавшие состояния хранения,
• а также замедление работы на уровне узлов относительно ожидаемого времени завершения.

Заключительная мысль

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

Это различие сейчас важно как никогда. Потому что в современных системах GenAI настоящий вопрос уже не в том, чтобы:

«Графические процессоры заняты?»

Это:

«Они заняты продуктивно?»

Отказ от ответственности

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

Ссылки

Каарат, А., Баттула, В. Дж. Р., и Сегалл, Р. «Укладка в пустоту: геометрическая упаковка с учетом остатков для рабочих нагрузок GenAI». IEEE, 2025.

Если вас интересует концепция геометрической упаковки с учетом остаточных значений, модель моделирования или код, использованный в этой статье, обращайтесь по адресу [email protected]

Арджун Каарат Посмотреть все от Арджун Каарат

Источник: towardsdatascience.com