Мы продолжаем говорить про S3/RDMA и сегодня подробно разберем доклад на SDC’25. Вопрос у него очень приземленный: что делать в ситуации, когда S3 как API всех устраивает, а вот привычный путь данных через HTTP/TCP уже начинает отъедать CPU и мешать GPU-серверу работать на полной скорости.

Авторы не предлагают выбросить объектное хранилище и начать жизнь с нуля. Наоборот, подход тут довольно консервативный: сохранить привычную S3-семантику, не заставлять команды переписывать пайплайны, но вынести из data path все то, что особенно больно бьет по AI/ML-нагрузке. В первую очередь это лишняя работа CPU, bounce buffer в памяти хоста и копии по дороге из CPU в GPU.

PUT и GET никуда не пропадают, но данные перестают быть заложниками HTTP payload. HTTP остается для сигналов и метаданных: что запросили, куда положить данные, какой участок памяти использовать. Сами данные идут отдельным RDMA-путем. Для GPU-нагрузки это уже совсем другая механика.

Где этот подход реально нужен

Если убрать все общие слова про «ускорение storage», идея S3 over RDMA сводится к довольно простой задаче: быстро донести данные до GPU-памяти и не сжечь по дороге CPU на копированиях. В докладе это привязано к четырем сценариям, где storage напрямую начинает влиять на итоговую скорость пайплайна: data loading, indexing, checkpointing и inference с KV-cache.

По сути, это почти весь жизненный цикл AI-нагрузки. Сначала нужно быстро подать датасеты на обучение. Потом где-то хранить checkpoint, не растягивая шаги обучения. Затем приходят индексация, retrieval и inference. Если на каждом из этих этапов storage заставляет систему прокачивать данные через CPU, узкое место оказывается уже не в модели, а в транспорте.

И здесь важно, что докладчик не пытается натянуть S3 over RDMA на любой workload подряд. Разговор идет про плотные AI-серверы с большим числом GPU, быстрой сетью и не таким уж большим количеством потоков, зато с очень жесткими требованиями к пропускной способности и задержке. Классический S3 исторически затачивался не под такой профиль.

Почему же S3 исторически плохо подходил для AI/ML

Объектное хранилище S3 долгое время не слишком годилось на роль основного источника данных для AI-нагрузок по трем причинам:

• Задержка выше, чем хотелось бы: HTTP-передачи добавляют ощутимый накладной расход там, где системе нужен просто быстрый перенос больших блоков данных.
• CPU втянут в процесс сильнее, чем нужно: классический S3 опирается на CPU при приеме, буферизации и копировании.
• Под реальной нагрузкой все становится хуже: когда AI-сервер уже занят обучением или инференсом, пропускная способность S3 заметно проседает.

Как изменился профиль нагрузки

Обычный S3 особенно хорош там, где много потоков и много клиентов. Но у AI/ML-задач профиль нагрузки теперь другой:

Почему объектное хранилище все равно важно для AI

Даже с этими ограничениями у object storage есть вполне практичные плюсы по сравнению с файловыми системами:

• С большими наборами данных через него банально удобнее работать: управление и метаданные устроены проще и понятнее.
• Versioning и immutability уже встроены, а не собираются отдельными костылями поверх.
• Масштабирование до очень больших объемов данных для object storage давно привычная история.
• И по рынку видно, что object storage все чаще рассматривают не как архив, а как основное хранилище для AI.

Как на S3/RDMA  смотрели через тесты

Чтобы не спорить абстрактно, авторы разложили нагрузку на четыре понятных режима: object transfer и tensor load, каждый в idle и busy состоянии клиента.

Это важный момент. Для AI-сервера busy client — вообще не экзотика, а обычный рабочий режим. Поэтому сравнение пиковой скорости на полностью свободной системе мало о чем говорит. Намного интереснее посмотреть, что происходит, когда клиент уже занят вычислениями и параллельно тянет данные.

В самом докладе это разобрано на примере single-GPU client system, который делает большие GET-операции из Dell ObjectScale. Сначала система простаивает. Потом ей начинают урезать доступные вычислительные ресурсы. И тут проявляется главный контраст: классический inline S3 еще может показать приличную скорость, пока у него много свободных ядер и есть чем заливать трубу. Но как только система становится занятой, цена этого подхода резко становится видна.

Таблица с режимами испытаний хорошо показывает замысел эксперимента. Авторам было важно проверить не только базовый transfer path, но и сценарий, где данные сразу попадают в среду, похожую на реальный AI-use case, то есть в тензорный pipeline, а не просто в память ради красивого бенчмарка.

Что показали измерения

Если собрать результаты в одну картину, она получается довольно жесткой. Классический S3 сам по себе не «медленный». На idle-системе он вполне может выглядеть конкурентно. Проблема в другом: для этого ему нужно больше CPU, больше потоков и просто больше свободы по ресурсам. А вот этого у AI-сервера обычно нет.

По цифрам картина такая:

• По CPU S3 over RDMA дает примерно ту же пропускную способность, но требует в 20-30 раз меньше ресурсов.
• Inline-путь добавляет около 40% лишней загрузки GPU только из-за копирования данных.
• На busy client inline-передача теряет примерно половину throughput, тогда как RDMA такой просадки не показывает.
• Самый ценный выигрыш тут не в красивом peak throughput, а в том, что система не разваливается, когда нагрузка становится похожей на реальную.

Почему это вообще важно

Если сжать смысл доклада до одной фразы, получится примерно так: S3 over RDMA нужен не ради лабораторного рекорда, а ради того, чтобы AI-сервер не сжигал CPU и GPU на транспортную рутину. Вся практическая ценность ровно в этом.

Докладчик несколько раз возвращается к одной простой мысли: GPU должен считать, а не ждать, пока CPU освободится, примет очередной кусок данных и передаст его дальше. Как только storage-path заставляет тратить дорогие GPU-циклы на движение данных, проблема уже не в модели и не во фреймворке. Проблема в том, как мы вообще организовали transport.

Что именно меняется в архитектуре

Если нужен один слайд, который быстро объясняет всю идею, то это прямое сравнение классического S3 и S3 over RDMA.

В верхней части схемы показан привычный inline-path. PUT кладет данные в HTTP payload, сервер принимает их как часть S3-запроса, а CPU и GPU все время участвуют в копировании. GET устроен симметрично: данные приходят обратно в payload, потом попадают в память хоста, и только после этого двигаются к GPU. На такой схеме сразу видно, откуда берутся CPU overhead, дополнительная работа для GPU и просадка на busy system.

В нижней части уже S3 over RDMA. HTTP никуда не исчезает, но становится control plane. Он несет сигнал и метаданные: какой объект нужен, куда его класть, какой адрес памяти использовать. Сам data plane переезжает в RDMA. Вот это и есть главный архитектурный поворот во всей истории.

Выводы

S3 over RDMA выглядит как вполне взрослый шаг вперед для хранилищ под AI/ML. За счет разделения HTTP для control plane и RDMA для data plane, а также благодаря GPUDirect и zero-copy-передаче, Dell и NVIDIA получили:

• Снижение загрузки CPU при передаче данных в 20-30 раз.
• Снижение накладных расходов на GPU для data movement примерно на 40%.
• Стабильный throughput даже на загруженных клиентах.
• Совместимость с S3 API без обнуления текущих инвестиций в приложения.

Самое интересное тут даже не в самой цифре throughput. Намного важнее, что object storage перестает выглядеть как удобный, но компромиссный вариант для on-prem AI-нагрузок. В Dell ObjectScale v4.1 эта история уже доведена до вполне практического состояния.

Дополнительные технические иллюстрации

Ниже собраны схемы, которые и делают этот доклад по-настоящему полезным. Без них разговор легко скатился бы в банальное «RDMA быстрее TCP». А с ними уже видно, где именно теряются ресурсы, что меняется в стеке и какие вещи инженеру придется настраивать руками.

1. Почему классический путь через CPU становится проблемой

На этой схеме показано место, где традиционный data path начинает стоить слишком дорого: bounce buffer в памяти хоста. Даже если конечная точка — GPU memory, данные все равно сначала заезжают в CPU memory. На картинке это выглядит почти безобидно: storage -> CPU memory -> GPU memory. На практике за этой простотой прячется довольно неприятная цена.

Цена состоит сразу из нескольких вещей. Данные копируются не один раз, а два. CPU втягивается почти в каждый transfer. PCIe-шина используется дважды. GPU ждет, пока кто-то подготовит ему данные. Именно отсюда потом и вылезают цифры из benchmark-блока: 20-30x higher CPU utilization, до 40% лишней GPU-нагрузки только на копирование, просадка throughput под нагрузкой и более длинное обучение.

2. Как выглядит zero-copy path

Следующая схема показывает уже желаемый путь: remote storage -> RDMA NIC -> GPU memory. CPU здесь не исчезает совсем, но его роль резко уменьшается. Он нужен для setup-фазы: поднять соединение, зарегистрировать память, передать служебную информацию. В самом transfer CPU уже не обязан быть промежуточной остановкой.

Поэтому внизу слайда так заметно выделены четыре числа: `0` CPU copies, `1x` PCIe traversal, около `~2 мкс` latency и до `400 Gbps` line rate. Это, конечно, не магические свойства системы при любых условиях, но как объяснение замысла архитектуры работает отлично.

3. Из чего вообще состоит software stack

Здесь сразу видно, что S3 over RDMA не живет в изоляции. Он опирается на несколько слоев сразу: CUDA-память, GPUDirect RDMA, RDMA connection management, драйвер сетевой карты и PCIe P2P. То есть это не один волшебный флаг в конфиге, а аккуратная сцепка библиотек, драйверов и аппаратных возможностей.

4. Memory registration

На этом слайде хорошо видно, почему доступ к GPU memory через RDMA — это не история формата «дали NIC адрес и поехали». Перед этим память нужно выделить, pinned-сделать, получить memory handle и зарегистрировать регион в RDMA-подсистеме. Только после этого удаленная сторона вообще может безопасно читать или писать по нужному адресу.

5. Как данные реально попадают в GPU

Схема показывает две важные операции: RDMA WRITE to GPU для `S3 GET object` и RDMA READ from GPU для `S3 PUT object`. Для GET объект приходит с object storage на server NIC, дальше идет по RDMA на client NIC и через PCIe P2P оказывается в GPU memory. Для PUT путь разворачивается в обратную сторону.

Это очень хороший слайд, чтобы наконец понять, почему во всей этой теме столько разговоров про PCIe topology. Если устройства не стоят в правильной PCIe-конфигурации, прямой peer-to-peer путь до GPU либо не заработает, либо потеряет смысл. А вместе с ним уйдет и большая часть выигрыша.

6. Как выглядит S3 GET flow шаг за шагом

Этот слайд раскладывает GET-object flow по шагам, а не просто рисует стрелки. Сначала клиент выделяет и регистрирует GPU buffer. Потом отправляет S3 GET request, где payload пустой, а в metadata лежат `rkey`, `gpu_addr` и размер. Затем сервер читает объект из storage, делает RDMA WRITE прямо в GPU memory клиента и только после этого возвращает обычный S3 response без полезной нагрузки.

S3 semantics никуда не делись. GET остается GET, ответ остается ответом, но payload больше не служит контейнером для самих данных. По сути, это и есть самое точное объяснение того, что такое S3 over RDMA на практике.

Q&A-сессия после выступления

Вопрос 1. Сложности реализации

Вопрос: С какими основными трудностями вы столкнулись при реализации S3 RDMA?

Ответ: Таких моментов было несколько:

1. Подбор размера объекта. Нужно понять, с какого размера объекта S3 RDMA начинает реально выигрывать у inline-передачи. Для совсем маленьких объектов проще и разумнее оставить данные в HTTP payload.
2. Выбор операций S3. PUT и GET объекта выглядят очевидным стартом. Multi-part upload тоже рассматривали, но польза тут спорная: S3 RDMA может запускать большие передачи одним сигналом, так что параллелизм, ради которого multi-part когда-то и придумывали, уже не так нужен.
3. Интеграция с SDK. Пришлось разбираться с AWS SDK, особенно с AWS CRT S3 SDK, где уже есть встроенные оптимизации под параллелизм. Часть из них пришлось ограничивать или отключать, потому что для S3 RDMA выгоднее меньше сигналов, но крупнее передачи.
4. Целостность данных. У S3 есть встроенные checksums для проверки payload. Но если payload пустой, то что именно мы тогда проверяем? Пока остается открытым вопрос, считать ли checksum по данным, ушедшим через RDMA, или по HTTP-пакету.

Вопрос 2. Пределы масштабирования RDMA

Вопрос: Не упрется ли RDMA сама по себе в ограничения по масштабу? И как это соотносится с работой над Ultra Ethernet?

Ответ: Да, со временем мы упремся в ограничения fabric и в лимиты по соединениям и queue pair. Возможно, здесь понадобятся другие протоколы. Текущая работа нацелена прежде всего на on-prem-среды с небольшим числом, но очень плотных систем. В долгосрочной перспективе решение, вероятно, должно быть менее завязано на конкретно RDMA и более расширяемым по транспортам.

Вопрос 3. С какого размера объекта RDMA начинает выигрывать

Вопрос: У RDMA есть заметные издержки на подготовку — установка соединения, создание queue pair и так далее. Где находится граница, после которой объект уже достаточно большой, чтобы RDMA дала выигрыш, а не добавила задержку?

Ответ: Точного порога пока нет. По наблюдениям Kieran из NVIDIA, выгода появляется примерно от 1 МБ и выше, но это зависит от конкретного endpoint. В Dell ObjectScale пользу замечали и начиная примерно с 64 КБ.

Вопрос 4. Стандартизация протокола

Вопрос: Это проприетарное расширение Dell? Как вообще выглядит протокол и куда вы с ним идете?

Ответ: Нет, это не проприетарное решение Dell. Работа идет вместе с NVIDIA и другими участниками, поэтому цель здесь — совместимость и интероперабельность.

Самая красивая часть решения в том, что SDK уже умеет добавлять и читать метаданные из запросов. Для GET и PUT этого оказалось достаточно: инструкции для передачи едут в метаданных, а сами данные параллельно уходят по RDMA, минуя HTTP payload.

Вопрос 5. Требуется ли специальный клиент

Вопрос: Нужен ли кастомный клиент? И нужно ли при этом работать с библиотеками NVIDIA?

Ответ: Да, нужен кастомный клиент или набор библиотек. Готового S3 RDMA-клиента, который можно просто скачать, сейчас нет. В Dell интеграцию клиента S3 с AWS CRT сделали у себя в лаборатории. Если передача идет прямо в память GPU, в цепочке также участвуют библиотеки NVIDIA и CUDA.

Вопрос 6. Что с испытаниями под сетевой нагрузкой

Вопрос: Проводились ли тесты под нагрузкой на сеть? У TCP и RDMA, где управление опирается на UDP-сообщения, довольно разный профиль поведения.

Ответ: Нет, тестов под сетевой нагрузкой не проводили. Это как раз одно из направлений, которое было бы интересно проверить дальше.

Вопрос 7. Как выделять память, если размер объекта заранее неизвестен

Вопрос: При GET объекта его размер заранее неизвестен. Как понять, сколько памяти нужно выделить на GPU и зарезервировать под RDMA еще до выполнения GET?

Ответ: Это зависит от реализации. Многие AI-фреймворки заранее работают с буферами похожего размера и запрашивают объекты схожих объемов, так что часть логики уже есть на уровне самого фреймворка. Размер можно уточнить через HEAD object до GET. Все равно нужна координация: нужно понимать, что именно загружается и какой объем запрашивать. Плюс терабайтных GPU не бывает, так что при работе с большими моделями данные все равно приходится раскладывать по нескольким буферам.

Вопрос 8. Экономия энергии

Вопрос: Похоже, это еще и экономит энергию. Насколько сильно?

Ответ: Точной цифры пока нет. Но если мы экономим гигафлопсы на GPU и высвобождаем CPU-ядра, экономия энергии почти наверняка есть. Было бы полезно увидеть отдельные измерения — для клиентов это действительно важно.

Вопрос 9. Менялся ли layout данных в самом object storage

Вопрос: Вы меняли layout данных в объектном хранилище, например схему erasure coding или избыточность?

Ответ: Нет. Все сделали поверх уже существующих механизмов перемещения данных в ObjectScale. Scale-out-кластер поддерживает erasure coding. При GET object данные читаются из нескольких источников, после чего уже выполняется передача по RDMA.

Вопрос 10. Есть ли движение к стандартизации

Вопрос: Идет ли какая-то работа по стандартизации протокола? Несколько вендоров уже заявили, что занимаются похожими вещами.

Ответ: Запрос на стандартизацию явно есть: никому не хочется переписывать клиентов под каждый endpoint. Эту цель разделяют многие implementers и вендоры. Формального стандарта пока нет, но курс на интероперабельность уже хорошо виден.

Вопрос 11. Как управляется RDMA-соединение

Вопрос: Как вообще управляется RDMA-соединение? Оно создается под каждый запрос или живет заранее?

Ответ: Рассматривали несколько подходов:

• Dynamically Connected QPs: создавать queue pair под каждый запрос. Подход интересен тем, что инициализация происходит по требованию.
• Reliable Connections (RC): более долгоживущие point-to-point соединения. Кэширование таких соединений показало пользу.

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

Вопрос 12. Наборы тестов

Вопрос: Разрабатывали ли вы какой-то специальный test suite?

Ответ: Dell разрабатывает собственный инструмент тестирования. Его показывали позже в тот же день на BOF-сессии. Команда также ищет отклик сообщества по наборам тестов для fast object, high-performance object и S3 over RDMA.

Вопрос 13. Какие данные использовали в тестах

Вопрос: Какие именно данные вы использовали в тестах? Предобученные модели?

Ответ: И то и другое:

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

Вопрос 14. Безопасность

Вопрос: Рассматривали ли вы вопросы безопасности для RDMA? Ландшафт угроз тут заметно отличается от TCP.

Ответ: Этот вопрос поднимался, но докладчик сразу оговорился, что не он лучший человек, чтобы подробно отвечать именно за security.

Вопрос 15. Алгоритмы контрольных сумм

Вопрос: Какие checksums вы используете? AWS использует MD5. Считаете ли вы MD5 или поддерживаете другие варианты? Это ведь тоже влияет на производительность.

Ответ: Пока это открытая тема. AWS уже смещается в сторону SHA. Но главный вопрос другой: для чего именно считать целостность — для области памяти или для самого request/response? Четкого ответа пока нет; многое будет зависеть от того, что построят implementers на стороне клиента.

Том из аудитории добавил еще один хороший вопрос: кто вообще отвечает за integrity, если данные летят прямо в GPU? Возможно, классическая модель здесь уже не работает. Как решить это без лишнего вытаскивания данных из GPU — хорошая тема для дальнейшей работы.

Вопрос 16. Availability Zones

Вопрос: Не ломает ли этот подход привычную модель availability zones в object storage?

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

Источники:

• SNIA Developer Conference 2025: sniadeveloper.org
• Dell ObjectScale Documentation
• NVIDIA GPUDirect Storage
• SNIA SDC 2025 — Accelerating Object Storage for AI/ML with S3 RDMA. Докладчик: Jason Goldschmidt, Dell Technologies.