В эпоху больших языковых моделей (LLM) каждый байт, перемещаемый по кластеру, имеет свою цену. Когда чекпоинты моделей достигают сотен гигабайт или даже терабайт, эта цена складывается в значительные задержки. Представьте себе типичный сценарий: холодный старт сервиса, автоскейлинг при всплеске трафика или непрерывное обучение с подкреплением (RL), где веса постоянно обновляются. Во всех этих случаях возникает один и тот же «налог» — время, потраченное на перемещение весов, прежде чем модель сможет приступить к полезной работе. Традиционные подходы, полагающиеся на объектные хранилища и оперативную память хоста, часто становятся узким горлышком, ограничивающим масштабируемость и экономическую эффективность развертывания ИИ-инфраструктуры.
На смену этим методам приходит NVIDIA ModelExpress (MX) — инновационная платформа, разработанная для ускорения жизненного цикла артефактов моделей. MX предлагает радикально новый подход: вместо того чтобы каждый раз загружать веса из удаленного хранилища, система сначала проверяет, нет ли уже совместимой копии весов в памяти GPU другого узла. Если такая копия найдена, MX использует прямое взаимодействие GPU с GPU (P2P) через RDMA, минуя лишние этапы копирования через оперативную память и локальные диски. Это позволяет заметно сократить время холодного старта и значительно повысить пропускную способность кластера.
В этой статье мы подробно разберем, как работает ModelExpress, какие технологии лежат в основе его высокой производительности, и как он интегрируется с популярными фреймворками, такими как vLLM, SGLang и Dynamo. Мы также рассмотрим практические примеры оптимизации, включая передачу кэшей JIT-компиляции и поддержку рабочих процессов RL-дообучения.
01Архитектура ModelExpress: От хранилища к GPU
Основная идея ModelExpress проста, но эффективна: перед загрузкой модели спросите, где уже находится совместимая копия ее весов. MX не рассматривает каждую реплику как независимый холодный старт. Вместо этого он выбирает самый быстрый доступный источник и путь передачи. Когда обслуживающий узел (peer) уже содержит совместимые веса в GPU, MX передает их напрямую от GPU к GPU через P2P RDMA с использованием NVIDIA Inference Xfer Library (NIXL). Это позволяет избежать избыточного доступа к объектным хранилищам, локальным дискам и оперативной памяти хоста.
Если же ни один узел-партнер недоступен, MX инициирует загрузку из самого быстрого поддерживаемого пути, потоково передавая данные из объектного хранилища без сохранения их на диск или чтения локальных файлов напрямую в память GPU. Такая гибкость обеспечивает оптимальную производительность в различных сценариях развертывания, от облачных сред до локальных дата-центров.
Первый узел: Загрузка из хранилища
Для первого узла в кластере, который начинает обслуживание модели, путь загрузки отличается. В этом случае нет узла-партнера, поэтому загрузка должна осуществляться из удаленного хранилища. MX предлагает несколько оптимизированных путей для этого этапа:
Объектное хранилище в GPU: Избегание локального диска
Когда чекпоинт находится в облачном бакете (например, S3 или Hugging Face Hub), и вы не хотите provision и управлять кэш-уровнем на диске, MX использует Model Streamer. Этот инструмент извлекает файлы safetensors через многотредовый читатель тензоров, который одновременно запрашивает диапазоны тензоров из различных шардов чекпоинта. По мере поступления тензоров они конвейерно передаются в GPU, позволяя inference-движку начинать обработку, пока остальные данные все еще загружаются. Это держит пути хранения, сети и копирования GPU занятыми, повторно используя ограниченное количество памяти хоста.
В развертываниях с тензорной параллельностью (Tensor Parallelism, TP) участвующие ранги делят удаленные чтения и обмениваются результатами, обычно через NCCL, вместо того чтобы каждый ранг скачивал полный чекпоинт независимо. MX подключает этот распределенный поток напрямую к загрузчику весов inference-движка, подготавливая первый узел стать источником P2P для всех совместимых реплик.
Кластерный ingress: Скачивание один раз, а не N раз
Если кластер поддерживает общий кэш-уровень на диске (например, постоянные тома в Kubernetes), MX обеспечивает его заполнение только один раз. Представьте, что множество реплик одновременно хотят загрузить модель DeepSeek-V4 Pro. Без оптимизации они скачают огромный объем идентичных данных, конкурируя за пропускную способность ingress. Сервис кэширования MX (Model Cache Service) сводит эти запросы к одному скоординированному скачиванию: атомарная заявка в хранилище метаданных выбирает один «скачиватель», а остальные реплики отслеживают его прогресс и используют кэшированную копию. Кластер платит за внешнее скачивание один раз, после чего каждая реплика может начать с того же кэшированного чекпоинта.
Локальное хранилище в GPU: Обход стадирования через память хоста
Когда в системе поддерживается GPUDirect Storage (GDS), MX читает файлы чекпоинта напрямую из локального хранилища в память GPU через многотредовый бэкенд GDS NIXL. NIXL выполняет пакетные тензорные чтения параллельно напрямую в память GPU, обходя оперативную память и стадирование, необходимое для обычного загрузчика. Пользователям не нужно явно включать GDS: MX автоматически обнаруживает эту возможность и использует ее, если она доступна.
Если GDS недоступен, MX может загрузить локальные чекпоинты через Model Streamer. Несколько потоков ОС читают safetensors одновременно в настраиваемый буфер CPU, пока завершенные тензоры перемещаются в GPU, а последующие чтения продолжаются параллельно. Хотя этот путь все еще использует память хоста как промежуточное звено, он перекрывает дисковый ввод-вывод с размещением в GPU, выигрывает от кэша страниц ОС и обеспечивает портативный быстрый путь, когда прямой доступ к хранилищу-GPU недоступен.
М
Источник: NVIDIA Developer ↗