Конференция GTC в Берлине внесла полную ясность в один вопрос: запуск ИИ-фабрики в работу становится всё более простой задачей.
Куда более интересными мне показались дискуссии о том, что происходит после этого. Как поддерживать высокую загрузку графических процессоров? Что происходит, когда несколько рабочих нагрузок начинают конкурировать за одну и ту же инфраструктуру? Как справляться со сбоями, ограничениями по питанию и всеми теми операционными проблемами, которые не проявляются на этапе пилотного тестирования?
Именно здесь начинается самое сложное. Инфраструктура, способная запустить модель, необязательно будет вести себя так же, когда сотни графических процессоров превратятся в тысячи, а одна рабочая нагрузка — в десятки.
Масштабирование — это не та же самая проблема, просто бóльшего масштаба
Всю свою карьеру я занимался созданием и эксплуатацией крупных распределенных систем. Больше всего меня до сих пор удивляет то, как внезапно наступает масштабирование. По своему поведению оно больше похоже не на множитель, а на фазовый переход.
У любой системы есть диапазон, в котором ее проектные допущения верны. Если выйти за его пределы, проблемы, которые казались краевыми эффектами, превращаются в главную инженерную задачу. Никто не проектировал систему плохо. Просто лежащие в ее основе допущения перестали быть актуальными.
Поставщик управляемых услуг STN убедился в этом на собственном опыте. Его предыдущая архитектура достигала пика примерно на 35 ГБ/с на высокооптимизированном наборе мелких файлов, в то время как FlashBlade//EXA™ теперь обеспечивает скорость до 100 ГБ/с.
Сабур Миан (Sabur Mian), генеральный директор и основатель STN, описал проблему масштабирования следующим образом: «В типичной системе хранения исследователи могут начать обучение модели на четырех узлах и получить хорошую производительность, но как только они начинают масштабироваться, эта производительность падает. С FlashBlade//EXA мы на данный момент масштабировались до 192 узлов, и пока не нашли предела».
Пилотный проект может пройти путь от одной команды до всей компании за два квартала, но лежащая в его основе платформа данных не перепроектируется за это время. От нее просто начинают требовать в 10 раз больше.
Что на самом деле меняется по мере роста
Четыре вещи ведут себя в масштабе иначе, чем в рамках проверки концепции (PoC).
Параллелизм перестает быть линейным.
Одна задача обучения, считывающая набор данных, представляет собой понятный паттерн ввода-вывода. Промышленная среда — это смесь предварительной обработки, обучения и дообучения, записи контрольных точек (чекпоинтов) и инференса, которые часто выполняются одновременно с одними и теми же данными. У каждого процесса свой паттерн доступа. В масштабе сложность заключается в том, как эти рабочие нагрузки взаимодействуют, когда борются за одну и ту же инфраструктуру.
Большинство систем упираются в «метаданные» раньше, чем в пропускную способность. Графики пропускной способности выглядят нормально, в то время как рабочие нагрузки замедляются, поэтому команды гонятся за производительностью, хотя реальное ограничение заключается в том, сколько запросов на поиск и создание в секунду может выдержать путь управления (control path).
Добавление узлов не решает проблему, потому что ограничение кроется не в том компоненте, который вы добавили.
Перемещение данных начинает диктовать расписание.
В пилотном проекте перемещение данных — это подготовительная работа. Вы один раз развертываете набор данных и переходите к обучению.
В продакшене перемещение не прекращается никогда. Чекпоинты для крупных моделей огромны, и их сохранение создает мощнейший всплеск одновременных записей. Путь записи должен выдерживать скачок, который почти не связан со средней нагрузкой на чтение, под которую вы рассчитывали систему.
Добавьте сюда обновление наборов данных, репликацию и копии, созданные из-за того, что одна команда не могла использовать данные другой команды на месте. Всё это увеличивает перемещение данных именно в тот момент, когда система и так находится под нагрузкой. Время, которое ваша инфраструктура тратит на перекладывание байтов вместо вычислений над ними, становится серьезной статьей в плане емкости.
Контекст перерастает место, где он должен был находиться.
При небольшом масштабе управление контекстом может выглядеть как задача инференса. В масштабе всего парка устройств оно становится и инфраструктурной проблемой.
При долгосрочных контекстных агентских нагрузках и тысячах одновременных сессий управление этим контекстом превращается как в проблему размещения данных, так и в проблему памяти GPU.
Когда вытесненный контекст приходится пересчитывать с нуля, вы платите по ценам GPU за повторное выполнение арифметических операций, которые уже делали. Эта трата ресурсов незаметна при паре сессий и огромна при тысячах.
Сбои перестают быть событием.
Для нескольких стоек аппаратный сбой — это то, что иногда случается. Для нескольких сотен стоек что-то постоянно ломается в том или ином месте.
Время безотказной работы (аптайм) перестает быть полезной метрикой. Значение имеет то, сколько производительности вы теряете во время восстановления системы и не замедляет ли пересборка другие рабочие нагрузки, разделяющие ресурсы системы. Две системы могут показывать одинаковые цифры на сравнительном тестировании и вести себя совершенно по-разному, как только одна из них начинает восстанавливаться под нагрузкой.
Экономика меняется на противоположную
Распределение бюджета — это то место, где я вижу самые дорогие ошибки.
При малом масштабе платформа данных — это затраты. Вы рассчитываете ее, покупаете, и в бюджете она отображается цифрой, которую хотелось бы видеть меньше.
В масштабе этот подход рушится. Когда ускорители составляют основную часть капиталовложений, уровень данных перестает быть статьей расходов и становится множителем утилизации. Каждая доля процента простоя GPU, вызванная задержкой, списывается на самый ценный актив, которым вы владеете.
Я яснее всего вижу это на примере провайдеров облачных GPU, где время простоя непосредственно подлежит оплате. Математика одинакова и для предприятия, управляющего собственным крупным парком оборудования. Просто счет не приходит в виде инвойса, из-за чего его легче игнорировать.
Что это значит для проектирования
Выбор, имеющий значение в масштабе, в основном невидим на уровне пилота.
Масштабируются ли метаданные независимо от пути передачи данных — не самый интересный вопрос при 200 GPU. Всё работает. При нескольких тысячах GPU, смешанных арендаторах и миллиардах мелких файлов операции с метаданными могут стать узким местом, даже когда пропускная способность все еще доступна. Это означает, что система может выглядеть исправной на графике пропускной способности, в то время как рабочие нагрузки уже начинают замедляться. Вот почему мы создали FlashBlade//EXA с дезагрегированным ядром метаданных, а не стали масштабировать метаданные и данные вместе.
То же самое относится и к тому, как приложения получают доступ к данным. Файловые и объектные рабочие нагрузки используют разные модели данных, семантику и протоколы доступа. Архитектуры СХД различаются: одни поддерживают раздельные пространства имен, другие предоставляют кросс-протокольный доступ к одним и тем же базовым данным. FlashBlade//EXA объединяет файловые и объектные рабочие нагрузки на единой высокопроизводительной платформе, сохраняя при этом их нативные пути доступа и семантику. Это позволяет организациям упростить инфраструктуру и операции без ущерба для семантики протоколов, критически важной для корректного выполнения ИИ-нагрузок.
Способность системы изолировать арендаторов определяет, испортит ли задача одной команды день другой команде.
Ничего из этого нельзя элегантно внедрить задним числом. Вы закладываете это до того, как в этом возникнет необходимость, и именно поэтому это так легко пропустить.
Прежде чем масштабироваться, найдите узкое место
Самое сложное — понять, какое допущение перестанет работать первым.
Что становится узким местом раньше — метаданные или пропускная способность? Замедляет ли трафик контрольных точек рабочие нагрузки обучения или инференса на той же инфраструктуре? Копируют ли команды данные, потому что система затрудняет их повторное использование? Восстанавливается ли инфраструктура при сбое без отключения работающих рядом задач?
Это не те вопросы, на которые можно ответить по результатам пилотного проекта.
Для этого требуется рассматривать систему как единый парк: как взаимодействуют рабочие нагрузки, как перемещаются данные, где возникает борьба за ресурсы и что происходит при работе среды под нагрузкой. В этом и заключается разница между доказательством того, что ИИ может работать, и пониманием того, что инфраструктура продолжит вести себя предсказуемо по мере роста внедрения.
Куда мы движемся дальше
Фактические данные — это более сложная часть, и именно их мы представим на SC26, 15–20 ноября 2026 года, в Чикаго.
Мы поместим эти нагрузки в контекст: как FlashBlade//EXA справляется с постоянной пропускной способностью и параллелизмом метаданных в крупных многоарендных средах, и о чем говорят результаты производительности S3 через RDMA и MLPerf Storage применительно к контрольным точкам и кэшу KV в условиях, приближенных к производственным.
Многие уже доказали, что ИИ может работать. Гораздо более сложный вопрос — что происходит, когда вы запускаете его на тысячах графических процессоров, для нескольких команд и с производственными нагрузками одновременно.
Чтобы узнать больше, ознакомьтесь с материалами:
- Блог-статья: Что промышленным ИИ-фабрикам требуется от уровня данных (21 октября)
- Блог-статья: Модели ИИ получают всю славу. Ваши данные определяют результат (15 октября)
- Результаты MLPerf Storage v3.0
