MLPerf Storage 3.0: СХД для AI больше не сводится к пропускной способности на обучении

1 сентября 2026 года MLCommons опубликовал результаты MLPerf Storage v3.0. На первый взгляд это может выглядеть как очередное обновление известного бенчмарка СХД: новые GPU, несколько новых нагрузок, поддержка S3. Но после того, как я внимательно посмотрел на спецификацию, результаты и текущую реализацию набора тестов, я бы назвал v3.0 гораздо более серьезным изменением.

Для меня главное в MLPerf Storage 3.0 заключается в том, что бенчмарк наконец перестает отвечать только на один вопрос:

«Сколько GPU система хранения способна накормить данными во время обучения?»

Теперь вопрос существенно шире:

«Как система хранения ведет себя на разных стадиях жизненного цикла современной AI-системы: от загрузки обучающего датасета и записи чекпоинтов до RAG и LLM-инференса?»

В MLPerf Storage 3.0 появляются два совершенно новых класса нагрузки: векторная БД и KV-кэш. Обучение заметно меняется, чекпоинтинг развивается дальше, а S3 становится официальным путем доступа к данным наряду с POSIX. MLCommons сам формулирует новую структуру довольно четко: обучение и чекпоинтинг представляют сторону обучения, KV Cache и Vector Database представляют сторону инференса.

На мой взгляд, именно это превращает MLPerf Storage из специализированного бенчмарка СХД для обучения в гораздо более универсальный бенчмарк инфраструктуры данных для AI.

MLPerf Storage: история и принципы бенчмарка СХД для AI

Изначальная идея MLPerf Storage была правильной: не пытаться измерять производительность СХД для AI обычными fio, IOR или синтетическими тестами последовательного чтения и записи.

Проблема таких тестов очевидна. Можно построить СХД, которая показывает несколько терабайт в секунду последовательного чтения, и это все еще ничего не говорит о том, способна ли она поддерживать работу кластера обучения из сотен или тысяч GPU.

Поэтому MLPerf Storage эмулирует поведение реальных задач обучения.

GPU при этом физически не требуется. Бенчмарк читает реальные данные через реальный путь ML-фреймворка, например PyTorch, после чего вместо реального вычисления батча делает паузу на время, соответствующее измеренной производительности конкретного ускорителя. Вся цепочка от СХД до памяти клиента остается настоящей, исключаются только вычисления на GPU.

Главным показателем становится Accelerator Utilization, или AU.

Если СХД не успевает, эмулируемый ускоритель начинает ждать, AU падает, и результат перестает соответствовать требованиям бенчмарка.

Это ключевая философия MLPerf Storage: СХД измеряется не сама по себе, а по тому, насколько эффективно она способна обслуживать вычислительные ресурсы AI.

В v3.0 эта идея сохраняется и применяется к гораздо более широкому набору профилей ввода-вывода.

Четыре типа нагрузки на СХД для AI

После выхода v3.0 я мысленно делю MLPerf Storage на четыре независимых домена нагрузки.

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

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

Векторная БД: случайное чтение и чувствительный к задержкам доступ к ANN-индексу для RAG и семантического поиска.

KV-кэш: массовое хранение и повторное чтение контекста инференса для большого количества параллельных диалогов с LLM.

Это принципиально разные нагрузки. Чекпоинтинг хочет огромную пропускную способность последовательной записи. UNet3D хочет огромную пропускную способность последовательного чтения. RetinaNet начинает упираться в производительность на мелких файлах и в пространство имен. Векторная БД упирается в задержку случайного чтения и IOPS. KV-кэш одновременно требует пропускной способности, параллельности, предсказуемой задержки и эффективного многоуровневого хранения.

Впервые один релиз MLPerf Storage действительно проверяет СХД практически по всей плоскости характеристик, которые важны для инфраструктуры AI.

Главное нововведение №1: бенчмарк KV-кэш

На мой взгляд, KV Cache является самым интересным нововведением MLPerf Storage 3.0.

До последнего времени бенчмарк СХД для AI почти автоматически означал измерение СХД для обучения. Но в реальном AI компаний все больше инфраструктуры строится не вокруг обучения моделей, а вокруг инференса.

Именно здесь возникает KV-кэш.

Почему KV-кэш вообще становится нагрузкой на СХД

Во время авторегрессионного инференса трансформер хранит для уже обработанных токенов вычисленные attention Keys и Values.

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

Пока пользователей немного, KV-кэш можно держать в VRAM GPU.

Этот подход очень быстро перестает масштабироваться. Количество одновременных диалогов растет. Контекстное окно растет. Модели становятся больше. Пользователь может уйти на несколько секунд или минут, а потом вернуться к своему диалогу. Хранить KV-кэш тысяч неактивных сессий в дорогой HBM бессмысленно.

Поэтому современная архитектура инференса постепенно становится многоуровневой:

VRAM GPU → DRAM CPU → локальные или дезагрегированные NVMe/СХД.

KV-кэш начинает мигрировать между уровнями в зависимости от активности диалога. И в этот момент СХД становится частью критичного к задержкам пути инференса.

Именно это теперь пытается моделировать MLPerf Storage.

MLCommons описывает нагрузку KV Cache как модель большого числа одновременно работающих пользователей: сессии чат-ботов, ассистенты для написания кода и сессии анализа документов с различной длиной контекста, длиной ответов и временем на обдумывание. Полученный KV-трафик отправляется на реальную СХД.

MLPerf Storage 3.0: как тестируется KV-кэшВ CLOSED v3.0 используются три сценария.

Первый: Llama 3.1 8B Storage Only. Уровень памяти отсутствует, поэтому обращения к кэшу доходят непосредственно до СХД. Это режим максимальной нагрузки на СХД при сравнительно большом количестве параллельных диалогов.

Второй: Llama 3.1 8B Storage + Memory. Перед СХД появляется кэш в DRAM объемом 4 GiB. Горячие записи KV могут обслуживаться из памяти, холодные данные уходят на СХД.

Мне кажется, что именно этот режим концептуально ближе всего к будущим продуктивным архитектурам инференса: нам уже интересно не только то, насколько быстро работает SSD или файловая система, а насколько хорошо работает иерархия памяти и хранения в целом.

Третий сценарий: Llama 3.1 70B Storage Only. Здесь объекты KV значительно крупнее. MLCommons указывает примерно 2,5-кратную разницу по объему данных на токен относительно конфигурации 8B.

Каждый сценарий CLOSED выполняется несколькими прогонами, причем один прогон длится 300 секунд. Это уже не микробенчмарк одиночного чтения или записи, а достаточно продолжительная параллельная нагрузка.

Размер KV-кэша: требования к емкости СХД

Здесь начинается самое интересное.

В эталонной модели для 8B состояние KV соответствует примерно 128 KiB на токен контекста, а для 70B примерно 320 KiB на токен.

Контекст может быть как сравнительно маленьким, так и достигать десятков тысяч токенов.

В результате объект KV-кэша оказывается вовсе не маленьким объектом «ключ-значение» размером в несколько килобайт. Это могут быть десятки MiB, сотни MiB, а в некоторых случаях и несколько GiB на один диалог. MLCommons указывает длину контекста вплоть до примерно 25 000 токенов для крупных сессий написания кода.

Это важно для понимания нагрузки. Бенчмарк KV Cache не является классической нагрузкой случайного доступа блоками по 4K. Это множество пользователей, которые параллельно читают и записывают довольно крупные объекты.

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

LLM-инференс: как prefill и decode нагружают СХД

Мне нравится рассматривать эту нагрузку через две фазы LLM-инференса.

Во время prefill создается состояние KV. С точки зрения СХД это потенциальная запись.

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

То есть СХД становится частью механизма сохранения результата вычислений. Мы фактически обмениваем емкость и пропускную способность СХД на вычисления GPU и емкость HBM.

Это серьезное изменение роли СХД в архитектуре AI. Раньше СХД была преимущественно местом, откуда модель забирает датасет. Теперь СХД становится частью иерархии памяти самой модели.

Метрики KV-кэша: пропускная способность и задержка СХД

Здесь MLPerf сделал правильную вещь: бенчмарк не сводит результат к одной цифре GiB/s.

Для KV Cache публикуются одновременно несколько характеристик.

Главная метрика уровня приложения: производительность в токенах в секунду. То есть бенчмарк спрашивает не просто «сколько гигабайт способна прочитать СХД», а фактически «какой объем работы LLM-инференса способна поддержать эта СХД».

Дополнительно публикуются пропускная способность чтения, пропускная способность записи и задержка чтения P95.

P95 берется консервативно: учитывается худший клиентский узел, а измеряется время получения целого объекта KV, а не задержка отдельной блочной операции 4 KiB.

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

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

KV-кэш меняет требования к СХД для AI

На уровне архитектуры я вижу несколько последствий.

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

Во-вторых, появляется очевидная потребность в интеллектуальном кэшировании и многоуровневом хранении.

В-третьих, становятся интересными локальные NVMe на узлах инференса. Если сервер уже содержит десятки терабайт локальных SSD, использовать их как второй или третий уровень KV-кэша становится очень привлекательной идеей.

В-четвертых, появляется пространство для дезагрегированных NVMe, общих пулов NVMe и storage fabric.

И наконец, программному обеспечению СХД теперь потенциально нужно понимать не только блоки, файлы и объекты, но и жизненный цикл контекста: горячий, теплый, холодный, неактивный, вытесненный.

Иными словами, KV-кэш сближает архитектуру СХД и архитектуру управления памятью.

Главное нововведение №2: бенчмарк Vector Database

Вторая новая нагрузка v3.0, векторная БД, интересна по совершенно другой причине.

Если KV Cache вырастает из обслуживания инференса, то нагрузка Vector Database моделирует путь, который становится фундаментальной частью RAG и семантического поиска.

Почему векторная БД вообще является проблемой для СХД

Эмбеддинг обычно представляет собой вектор высокой размерности. Например, нагрузка CLOSED в MLPerf v3.0 использует векторы размерности 1536 элементов float32. Один такой вектор занимает примерно 6 KiB.

При небольшом объеме данных все векторы и индекс можно держать в RAM. Но продуктивная БД может содержать десятки или сотни миллионов векторов. Индекс становится слишком большим, и часть ANN-индекса неизбежно оказывается на СХД.

В этот момент задержка запроса начинает зависеть уже не только от CPU и алгоритма поиска, но и от задержки СХД.

Как устроена нагрузка Vector Database в MLPerf

В конфигурации CLOSED v3.0 используется Milvus.

Датасет содержит 10 миллионов векторов, каждый размерностью 1536 float32. Только сырые векторы дают примерно 61 GB данных еще до учета ANN-индекса и других структур.

Для поиска используется индекс приближенного поиска ближайших соседей (ANN). Правила CLOSED допускают DiskANN, HNSW и AISAQ, хотя в опубликованных заявках v3.0 использовался DiskANN.

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

Поэтому это действительно нагрузка на СХД, а не бенчмарк базы данных, который случайно запускается поверх файловой системы.

Что происходит при запросе

ANN-поиск идет по графу. Алгоритм переходит от одного узла к другому, постепенно приближаясь к векторам, наиболее похожим на вектор запроса.

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

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

Это почти противоположность нагрузки чекпоинтинга. Чекпоинтинг: крупный, последовательный, параллельный, ориентированный на пропускную способность. Векторная БД: мелкий, случайный, с преобладанием чтения, ориентированный на задержку.

Теперь обе крайности находятся внутри одного набора MLPerf Storage.

У векторной БД нельзя смотреть только на QPS

Ключевая метрика для этой нагрузки: количество запросов в секунду (QPS).

Но сравнивать СХД исключительно по QPS здесь было бы ошибкой.

ANN-поиск почти всегда содержит компромисс между скоростью и качеством поиска. Можно пройти меньше узлов графа, сделать меньше чтений с СХД и получить очень высокий QPS. Но recall упадет.

Поэтому MLPerf публикует QPS, задержку запроса P99 и recall вместе. Recall проверяется относительно точного эталона, полученного полным перебором.

Я бы вообще не рассматривал QPS отдельно от recall. Если одна система показывает 50 000 QPS при заметно худшем recall, а другая 40 000 QPS при существенно более качественном поиске, это не доказательство того, что первая СХД быстрее. Она могла просто обслуживать более простую конфигурацию поиска.

Поэтому для бенчмарка векторной БД правильным объектом сравнения становится условно:

QPS @ Recall @ P99.

Это уже намного ближе к тому, как стоит анализировать реальную инфраструктуру RAG.

Почему векторная БД особенно интересна для NVMe

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

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

В DiskANN такой роскоши гораздо меньше. Случайный обход графа намного сильнее чувствует задержку носителя, задержку программного стека, сетевой round-trip, накладные расходы файловой системы, долю попаданий в кэш, эффективность очередей NVMe, размещение по NUMA и поведение СХД при большом количестве параллельных мелких чтений.

Поэтому векторная БД, вероятно, окажется одной из наиболее интересных нагрузок MLPerf для сравнения локальных NVMe, распределенных СХД на NVMe и традиционных общих файловых систем.

Обучение тоже серьезно изменилось

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

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

Что было в v2.0

В предыдущем поколении набор тестов обучения использовал три хорошо знакомые нагрузки: 3D U-Net, ResNet-50 и CosmoFlow.

Они давали разные профили ввода-вывода: от крупных сэмплов медицинских изображений у UNet3D до сравнительно небольших объектов и научных датасетов.

Профили ускорителей соответствовали предыдущим поколениям GPU, включая A100 и H100. В частности, UNet3D для H100 требовал уже более 3 GB/s пропускной способности на один ускоритель при 100% AU.

Что стало в финальном v3.0

В опубликованной матрице CLOSED/OPEN v3.0 канонические нагрузки обучения: UNet3D и RetinaNet.

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

Для v3.0 используются профили ускорителей NVIDIA B200 и AMD MI355X. UNet3D в официальной матрице используется с B200, а RetinaNet доступен и для B200, и для MI355.

RetinaNet: теперь проверяется не только пропускная способность

RetinaNet работает с OpenImages и большим количеством файлов JPEG.

Средний сэмпл около 315 KiB, один сэмпл на файл, сэмплы читаются в случайном порядке.

Пропускная способность на ускоритель не выглядит особенно большой: для B200 порядка 155 MiB/s. Но каждый ускоритель должен открывать и читать примерно 500 файлов в секунду.

Если система масштабируется до сотен эмулируемых ускорителей, речь уже идет о десятках или сотнях тысяч открытий и чтений файлов в секунду на пространстве имен, содержащем миллионы объектов.

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

На мой взгляд, это очень полезное изменение бенчмарка. Для датасетов AI проблема мелких файлов абсолютно реальна, а многие высокопроизводительные СХД выглядят гораздо лучше на последовательном вводе-выводе блоками 1 MiB, чем на миллионах файлов размером в несколько сотен KiB.

UNet3D никуда не исчез

MLPerf не отказался от классической нагрузки на пропускную способность. UNet3D остается, сэмплы там порядка 140 MiB.

То есть одна и та же категория обучения v3.0 позволяет посмотреть на два почти ортогональных профиля:

UNet3D → устойчивая пропускная способность чтения крупных файлов.

RetinaNet → мелкие файлы, метаданные, IOPS, задержка.

Мне это кажется значительно полезнее, чем пытаться вывести единственную условную «пропускную способность СХД для AI». Такой характеристики в реальной жизни просто не существует.

А где DLRMv2 и FLUX?

Здесь есть интересная деталь.

В материалах Storage Working Group, опубликованных во время разработки MLPerf Storage 3.0, в качестве новых нагрузок обучения показывались сразу три модели: DLRMv2 для рекомендательных систем, FLUX для генерации изображений и RetinaNet для детекции объектов. Одновременно появлялись новые загрузчики данных, включая Parquet и JPEG.

В финальном опубликованном наборе CLOSED/OPEN v3.0 картина другая.

Текущий mlpstorage явно помечает UNet3D/B200, RetinaNet/B200 и RetinaNet/MI355 как v3.0. А DLRM и FLUX с B200/MI355 находятся в категории WHATIF.

Это означает, что их можно использовать для планирования емкости и экспериментов, но нельзя подать как официальный результат CLOSED/OPEN v3.0.

Поэтому я бы аккуратно формулировал изменения так: DLRMv2 и FLUX появились в инструментарии бенчмарка поколения v3, но официальными соревновательными нагрузками обучения финального раунда v3.0 стали UNet3D и RetinaNet.

Это небольшая, но важная деталь, особенно если кто-то пытается строить сравнение производителей СХД именно по официальным результатам MLPerf.

Новые профили GPU: B200 и MI355

Еще одно изменение, которое нельзя игнорировать: новое поколение эмулируемых ускорителей.

В финальном бенчмарке обучения v3.0 используется измеренное время вычислений современных NVIDIA B200 и AMD MI355X.

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

Поэтому фраза:

«эта система обслуживала N ускорителей в MLPerf Storage v2.0, а теперь обслуживает M ускорителей в v3.0»

сама по себе практически ничего не говорит об ухудшении или улучшении СХД. Изменился знаменатель. Один эмулируемый B200 представляет собой другую точку нагрузки ввода-вывода, чем эмулируемый H100 или A100.

Поэтому v2.0 и v3.0 нельзя напрямую сравнивать по количеству ускорителей. Я бы сравнивал системы только внутри одной версии, одной нагрузки и одного профиля ускорителя.

Accelerator Utilization остался ключевым ограничителем

Методология обучения при этом остается очень разумной.

Чтобы результат считался валидным, СХД должна обеспечить минимальный Accelerator Utilization: 90% для UNet3D и 85% для RetinaNet.

Кроме того, бенчмарк пытается не позволить участнику случайно протестировать кэш в DRAM вместо СХД. Датасет должен быть не меньше чем 5× суммарного объема DRAM всех клиентских узлов, а каждый прогон должен обработать как минимум 500 батчей на ускоритель.

При большом количестве ускорителей это очень быстро превращается в датасет объемом в несколько терабайт.

Мне нравится этот принцип: бенчмарк пытается заставить систему проявить именно установившееся поведение СХД.

Чекпоинтинг: нагрузка сохранилась, но продолжает развиваться

Чекпоинтинг появился еще в MLPerf Storage 2.0 и в v3.0 остается одной из центральных частей набора.

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

Четыре масштаба чекпоинта

В v3.0 представлены четыре масштаба в стиле Llama 3.

8B: порядка 105 GiB на чекпоинт.

70B: порядка 911 GiB.

405B: порядка 5,29 TiB.

Самый большой профиль: примерно 18 TiB на чекпоинт.

Здесь есть небольшая терминологическая особенность. В инструментарии модель называется llama3-1t, а на странице опубликованных результатов старшая нагрузка обозначена как Checkpoint 1250B. Поэтому в документации можно встретить и «1T», и «1250B». Для архитектуры СХД важнее сама величина состояния: примерно 18 TiB.

Что именно делает бенчмарк чекпоинтинга

Бенчмарк выполняет 10 записей чекпоинта, затем 10 чтений тех же данных.

Это не один гигантский файл. Чекпоинт распределен между множеством процессов: 8 процессов для 8B, 64 для 70B, 512 для 405B и 1024 для старшего профиля. Каждый процесс потоково пишет свою часть состояния.

При записи требуется fsync: бенчмарк не позволяет СХД показать красивую цифру только благодаря энергозависимому кэшу отложенной записи. Данные должны реально стать долговечными.

После этого тот же объем читается обратно, моделируется восстановление.

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

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

На бумаге можно сказать: «ну это же просто большая последовательная запись».

Но именно параллельность делает нагрузку сложной.

Тысяча писателей одновременно приходит в СХД. Файловая система должна распределить аллокации. Слой метаданных должен выдерживать операции с пространством имен. Бэкенд должен масштабировать потоки записи. RAID, erasure coding или другая защита данных должны работать параллельно. Сеть должна выдерживать fan-in. А fsync не дает бесконечно прятать задержку носителя.

После этого нагрузка разворачивается обратно и превращается в массово-параллельное чтение.

Для распределенных СХД это намного интереснее простого fio --rw=write.

Direct I/O в чекпоинтинге

В ходе разработки v3 путь чекпоинтинга получил поддержку direct I/O.

Кроме этого, была переработана генерация данных: уменьшено время генерации тензоров, которое само по себе могло ограничивать скорость бенчмарка. Рабочая группа отдельно отмечала рост производительности даже без direct_io.

Это кажется технической мелочью, но для бенчмарка СХД такие изменения принципиальны. Генератор нагрузки не должен становиться узким местом раньше СХД. Если CPU занят созданием буферов данных и способен генерировать только 20 GB/s, мы никогда не узнаем, умеет ли тестируемая СХД записывать 50 или 100 GB/s.

S3 становится полноправным участником

Это, пожалуй, второе по фундаментальности изменение после нагрузок инференса.

До v3.0 MLPerf Storage был сильно ориентирован на файловые системы. В v3.0 официально появляется слой доступа к S3-совместимому объектному хранилищу как альтернатива POSIX.

Причем это не экспериментальное приложение к спецификации. MLCommons поддерживает путь S3 для обучения, чекпоинтинга и части тестов векторной БД. Примерно одна шестая всех заявок v3.0 уже использовала слой доступа S3.

Почему S3 в MLPerf Storage действительно важен

Для обычных корпоративных СХД разговор «файловая система против объектного хранилища» идет много лет.

AI меняет экономику этого выбора. Датасет огромный. Данные часто неизменяемые. Обучение преимущественно читает объекты. Вычисления и хранение все чаще дезагрегированы. Cloud-native стеки AI уже умеют работать непосредственно с объектным хранилищем. Датасет может жить в одном пространстве имен для десятков кластеров. У объектного хранилища намного проще независимое масштабирование емкости.

Поэтому предположение о том, что СХД для обучения обязана быть параллельной POSIX-файловой системой, становится все менее очевидным.

MLCommons прямо говорит: по мере роста контекста AI и масштаба датасетов объектное хранилище может стать не просто допустимой, а в некоторых архитектурах предпочтительной альтернативой хранилищу на базе файловой системы.

Но S3 не сводится к замене open на GET

При чтении результатов MLPerf по S3 я бы был осторожен.

POSIX и S3 различаются гораздо глубже, чем синтаксис протокола. Меняются размеры объектов, параллелизм запросов, управление соединениями, накладные расходы HTTP/TCP, поведение multipart, семантика метаданных, буферизация на стороне клиента, поведение при повторах, модель согласованности, возможности кэширования, число конечных точек и распределение объектов между узлами бэкенда.

Поэтому две СХД с одинаковыми физическими носителями могут показать совершенно разное поведение через POSIX и S3. И наоборот: хорошо оптимизированный клиент S3 может очень эффективно конвейеризовать запросы и в некоторых нагрузках прекрасно масштабироваться.

Для меня появление S3 в MLPerf особенно полезно именно потому, что теперь эти архитектурные различия можно исследовать не через синтетические warp или s3bench, а через нагрузку AI, повторяющую форму реального приложения.

MLPerf Storage теперь фактически тестирует разные плоскости данных

Еще одна важная архитектурная особенность v3.0: не все нагрузки используют один и тот же генератор.

Обучение и чекпоинтинг используют DLIO. Vector Database и KV Cache имеют собственные реализации нагрузки.

Это логично. Попытка описать запрос DiskANN через универсальный генератор последовательного или случайного ввода-вывода потеряла бы саму сущность нагрузки. То же самое относится к KV Cache.

Бенчмарк СХД становится менее синтетическим и больше похож на набор миниатюрных конвейеров приложений. Мне кажется, это правильное направление.

MLPerf Storage 3.0 теперь проверяет задержку, а не только пропускную способность

Если посмотреть на эволюцию набора сверху, можно увидеть еще одну фундаментальную перемену.

Раньше обсуждения MLPerf Storage практически неизбежно сводились к GB/s, количеству эмулируемых GPU и пропускной способности записи чекпоинтов.

Теперь появляются полноценные метрики задержки. Vector Database публикует задержку запроса P99. KV Cache публикует задержку чтения P95.

Это важнейшее изменение, потому что инфраструктура AI становится все более интерактивной. Пропускную способность обучения можно оценивать минутами или часами. Инференс должен отвечать пользователю за миллисекунды и секунды. СХД теперь попадает непосредственно в видимый пользователю путь задержки.

Хвостовая задержка P95 и P99: влияние на производительность AI

Представим две СХД. Первая стабильно возвращает объект KV за 150 мс. Вторая обычно возвращает его за 100 мс, но периодически зависает на 2 секунды.

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

То же самое с DiskANN. Если один обход графа вызывает несколько последовательных чтений с СХД, один случайный запрос из хвоста распределения способен существенно увеличить задержку запроса.

Поэтому появление P95/P99 в MLPerf Storage я считаю очень правильным сигналом для рынка.

Эффективность СХД для AI: производительность, емкость и энергопотребление

В опубликованных результатах v3.0 MLCommons значительно внимательнее показывает не только абсолютную производительность, но и эффективность.

Например, результаты можно нормализовать на полезную емкость, юниты в стойке и выделенную мощность. Для векторной БД MLCommons прямо рекомендует анализировать QPS относительно плотности в стойке и емкости, а для KV Cache производительность и пропускную способность относительно емкости и юнита стойки и, при наличии данных, относительно мощности.

В официальном релизе MLCommons отдельно привел показатели энергоэффективности: для on-premises заявок на запись чекпоинтов медианное значение составило 14 GB/s на ватт, а максимальное 201; для чтения UNet3D соответственно 34 и 277.

Сам по себе абсолютный GB/s больше не дает полной картины. Если одна система достигает результата четырьмя юнитами и 30 кВт, а другая двадцатью юнитами и 100 кВт, архитектурно это совершенно разные результаты.

Для больших кластеров AI это критично: мощность и место в ЦОД все чаще оказываются таким же ограниченным ресурсом, как GPU.

Как сравнивать результаты MLPerf Storage 3.0

После v3.0 я бы вообще перестал искать в результатах одного «победителя MLPerf Storage». Такого победителя практически не может быть.

Нужно сначала понять свою нагрузку.

Если я проектирую крупный кластер обучения, для меня в первую очередь интересны UNet3D/RetinaNet и способность СХД удерживать AU. Если у меня обучение на тысячах GPU, меня особенно волнует чекпоинтинг. Если строится платформа RAG, то векторная БД. Если кластер инференса с LLM с длинным контекстом и переиспользованием префиксов и KV, то KV Cache.

И даже внутри нагрузки заглавную цифру нельзя отрывать от контекста. Для векторной БД я смотрю QPS вместе с recall и P99. Для KV Cache токены в секунду вместе с P95 и пропускной способностью чтения и записи. Для обучения количество ускорителей вместе с типом ускорителя и AU. Для чекпоинтинга длительность и пропускную способность в рамках одного и того же размера модели.

Как правильно сравнивать производительность чекпоинтинга

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

70B это порядка 911 GiB и значительно меньше писателей. Старшая нагрузка это около 18 TiB и более тысячи процессов.

Это разные режимы параллельности и совершенно разные рабочие точки СХД. MLCommons прямо предупреждает: сравнивать результаты чекпоинтинга имеет смысл только внутри одного профиля модели.

Что MLPerf Storage 3.0 говорит о будущем СХД для AI

Самый интересный для меня вывод из v3.0 вообще не связан с конкретными результатами производителей.

Посмотрите, насколько разными стали нагрузки. UNet3D требует пропускной способности последовательного чтения крупных файлов. RetinaNet требует высокой частоты доступа к мелким файлам. Чекпоинтинг требует массово-параллельной записи с гарантией сохранности. Векторная БД требует случайного чтения с низкой задержкой. KV-кэш требует параллельного чтения и записи крупных объектов, предсказуемой хвостовой задержки и эффективной иерархии памяти и хранения. S3 добавляет объектную семантику.

Термин «СХД для AI» окончательно перестает означать «быстрая параллельная файловая система». Современной платформе AI нужна СХД, которая одновременно умеет хорошо работать как минимум в нескольких совершенно различных режимах.

Универсальные СХД для AI: ограничения и компромиссы архитектуры

Архитектура СХД, идеально оптимизированная под чекпоинтинг, может быть посредственной для DiskANN.

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

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

Поэтому я ожидаю, что СХД для AI будет двигаться не к одному универсальному пулу носителей, а к многоуровневым архитектурам: HBM, DDR, локальные NVMe, общие или дезагрегированные NVMe, емкостной flash, HDD, объектное хранилище и, возможно, дальше ленты.

Задача программного слоя будет состоять в том, чтобы правильно перемещать данные между этими уровнями в зависимости от нагрузки и температуры данных. Бенчмарк KV Cache особенно хорошо показывает, почему такой подход становится необходимым.

Дезагрегированные NVMe для AI: производительность и задержки

Мне кажется, v3.0 дает очень хорошую основу для бенчмарков именно нового класса дезагрегированных СХД.

В обучении у них есть возможность показать суммарный масштаб. В чекпоинтинге массовый fan-in записи. В векторной БД задержку сети плюс случайного доступа к NVMe. В KV Cache возможность проверить, насколько близко удаленные NVMe могут подойти к локальным в чувствительной к задержкам нагрузке инференса.

То есть теперь можно гораздо содержательнее отвечать на вопрос:

Насколько дорого с точки зрения производительности приложения нам обходится дезагрегация?

Раньше этот вопрос часто пытались решить через синтетические цифры задержки. Теперь его можно измерять через QPS, recall, токены в секунду и Accelerator Utilization.

Ограничения MLPerf Storage 3.0: что не показывает бенчмарк

При всех улучшениях MLPerf Storage 3.0 я бы не воспринимал его как полноценную замену бенчмаркингу приложений.

Нагрузка обучения по-прежнему эмулирует вычисления ускорителя, а не запускает реальный кластер обучения на B200. Это сделано специально, чтобы изолировать СХД и сделать бенчмарк доступнее и воспроизводимее. Но сквозное взаимодействие CPU, GPU, сети и СХД в реальном кластере может отличаться.

Векторная БД использует конкретную архитектуру базы данных и конкретное поведение ANN. KV Cache использует конкретную модель симуляции диалогов.

Поэтому результат MLPerf отвечает на вопрос «как эта СХД ведет себя при стандартизированной нагрузке, репрезентативной для данного паттерна AI?». Но не на вопрос «как быстро именно мое приложение будет работать на этой СХД?».

Это принципиальная разница.

Кэширование в MLPerf Storage 3.0: как избежать искажения результатов

Любой бенчмарк СХД имеет проблему усиления за счет кэша. Если датасет или индекс помещается в DRAM, бенчмарк легко превращается в бенчмарк памяти.

Для обучения MLPerf борется с этим достаточно жестко через правило «датасет ≥ 5× суммарной DRAM клиентов». KV Cache Storage Only также специально старается заставить чтения действительно доходить до СХД, а не обслуживаться страничным кэшем ОС.

Но в реальной эксплуатации кэш не враг. Наоборот, правильное кэширование является частью архитектуры.

Поэтому мне особенно нравится наличие отдельного режима 8B Storage + Mem. Он позволяет посмотреть не на сырой носитель, а на многоуровневую систему.

MLPerf Storage 3.0: как изменилось тестирование СХД для AI

Если совсем коротко пересказать релиз, получится: «добавили KV Cache, Vector Database и S3».

Формально это правильно. Архитектурно изменение гораздо глубже.

MLPerf Storage теперь рассматривает СХД как компонент всего пути данных AI. До v3 основной нарратив был:

СХД → Обучение.

Теперь:

СХД → Обучение → Чекпоинт/Восстановление → Поиск/RAG → Контекст инференса.

И на каждом этапе СХД выполняет совершенно другую функцию. Во время обучения она кормит ускорители. Во время чекпоинтинга сохраняет достигнутый прогресс. В RAG она становится частью поискового движка. В инференсе частью иерархии памяти.

Для меня это и есть главное изменение MLPerf Storage 3.0.

MLPerf Storage 3.0: шесть главных технологических изменений

Если все-таки расставить изменения по значимости, я бы поставил их в таком порядке.

Первое: бенчмарк KV Cache. Он фактически признает постоянное хранилище частью современной архитектуры LLM-инференса.

Второе: бенчмарк Vector Database. В MLPerf Storage появляется настоящая нагрузка случайного чтения, чувствительная к задержкам и привязанная к RAG.

Третье: S3 как официальный путь доступа к данным. СХД для AI больше не предполагает обязательную POSIX-файловую систему.

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

Пятое: переход на профили ускорителей B200 и MI355. Бенчмарк СХД догоняет текущую производительность вычислений AI, а требования на один ускоритель становятся жестче.

Шестое: дальнейшее развитие чекпоинтинга, включая direct I/O и улучшенный генератор.

И наконец, существенно возрастает значение задержки, мощности и плотности, а не только суммарной пропускной способности.

Выводы: как MLPerf Storage 3.0 меняет требования к СХД для AI

После MLPerf Storage 3.0 я бы осторожнее использовал выражение «самая быстрая СХД для AI».

Больше нет одной универсальной нагрузки AI. СХД для обучения, СХД для чекпоинтинга, СХД для RAG и СХД для LLM-инференса могут требовать почти противоположных архитектурных свойств.

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

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

Это уже намного ближе к реальному вопросу, который приходится решать архитектору инфраструктуры AI.

Не «сколько гигабайт в секунду дает моя СХД?»

А «в каких частях конвейера AI моя СХД перестанет быть узким местом, и в каких станет им первой?»

На мой взгляд, ради ответа на этот вопрос MLPerf Storage 3.0 действительно стоит внимательно изучать.

Автор: Александр Иванов