TransferEngine от Perplexity: как запускать триллионные LLM на смешанных GPU-кластерах

Команда Perplexity Research открыла TransferEngine и набор pplx garden, чтобы команды могли запускать триллионные языковые модели на существующих смешанных GPU-кластерах без покупки нового GB200-оборудования и без привязки к одному облачному провайдеру.

Почему узким местом стала сеть, а не FLOPs

Большие MoE-модели, такие как DeepSeek V3 (671B) и Kimi K2 (1T), уже не помещаются на одном 8-GPU сервере и вынуждены работать на нескольких узлах. Тогда основным ограничением становится сетевой интерфейс между GPU. Аппаратный ландшафт разнороден: NVIDIA ConnectX 7 обычно дает надежную транспортную связь с упорядоченной доставкой, тогда как AWS EFA обеспечивает надежность без гарантии порядка доставки. Чтобы достичь 400 Gbps, на одном GPU может потребоваться несколько сетевых адаптеров (например, 4×100 Gbps или 2×200 Gbps). Существующие библиотеки часто оптимизированы под одного вендора и плохо работают на другом, поэтому до появления TransferEngine не было универсального решения для кросс-провайдерного инференса LLM.

Что такое TransferEngine

TransferEngine предоставляет переносимый уровень RDMA, который опирается только на общий набор гарантий разных NIC. Он предполагает надежность транспорта, но не требует упорядочивания сообщений. На этой основе реализованы односторонние операции WriteImm и примитив ImmCounter для уведомлений о завершении.

Ключевые аспекты API и архитектуры

• Минимальный Rust API: двухсторонние Send и Recv для управляющих сообщений и три односторонние операции: submit_single_write, submit_paged_writes и submit_scatter. Примитив submit_barrier синхронизирует группу пиров. Структуры NetAddr и MrDesc описывают пиров и зарегистрированные области памяти; alloc_uvm_watcher создает наблюдатель на стороне устройства для синхронизации CPU–GPU.
• Рабочие потоки и DomainGroup: библиотека создаёт по одному рабочему потоку на GPU и DomainGroup на GPU, который координирует от 1 до 4 RDMA NIC. Логика шардирования знает про все NIC и может распределять передачу между ними для агрегации пропускной способности.

Производительность и переносимость

Команда Perplexity сообщает о пиковой пропускной способности 400 Gbps как на NVIDIA ConnectX 7, так и на AWS EFA (путём агрегации адаптеров). Это подтверждает, что абстракция сопоставима по производительности с решениями одного вендора, оставаясь переносимой.

pplx garden и требования к системе

TransferEngine входит в репозиторий pplx garden под лицензией MIT. Структура репозитория включает fabric-lib для RDMA-библиотеки, p2p-all-to-all для MoE all-to-all ядра, python-ext для Python-расширения на Rust и python/pplx_garden для Python-пакета.

Рекомендуемые требования:

• Linux kernel 5.12+ (DMA-BUF)
• CUDA 12.8+
• libfabric, libibverbs, GDRCopy
• RDMA-фабрика с поддержкой GPUDirect RDMA
• Каждому GPU как минимум один выделенный RDMA NIC

Производственные кейсы

Дисагрегированный prefill и decode

Prefill и decode могут выполняться на отдельных кластерах; требуется быстрая передача KvCache с prefill GPU на decode GPU. TransferEngine использует alloc_uvm_watcher для отслеживания прогресса модели. При prefill наблюдатель увеличивается после проекции внимания каждого слоя; когда рабочий поток видит изменение, он отправляет paged writes для страниц KvCache этого слоя и один write для оставшегося контекста. Это позволяет потоковую передачу страниц кеша по слоям без фиксированного состава участников и без строгих требований по упорядочиванию.

Быстрая передача весов для RL

Для асинхронной дообучаемости RL, когда обучение и инференс на отдельных пулах GPU, вместо сбора обновлений на одном ранге и широковещательной рассылки (ограничивающей пропускную способность одним NIC), TransferEngine выполняет точечно-точечные односторонние записи: каждая обучающая GPU записывает свою шард-параметров прямо в соответствующие inference GPU. Пайплайн делит тензор на стадии: host→device копия (при оффлоуде весов FSDP), реконструкция и опциональная квантизация, RDMA-передача, барьер через scatter и ImmCounter. В продакшне такой подход обеспечивает обновления весов для моделей вроде Kimi K2 (1T) и DeepSeek V3 (671B) примерно за 1.3 секунды от 256 training GPU к 128 inference GPU.

Маршрутизация MoE на ConnectX и EFA

В pplx garden есть point-to-point ядро dispatch/combine для MoE. Оно использует NVLink для внутриядерного трафика и RDMA для межузлового. Dispatch и combine разделены на фазы отправки и получения, чтобы декодер мог микробатчить и перекрывать коммуникацию с групповой GEMM. Хост-прокси опрашивает состояние GPU и вызывает TransferEngine, когда буферы отправки готовы. Сначала обмениваются маршрутами, затем каждый ранг вычисляет смещения для приёма по каждому эксперту и записывает токены в приватные буферы, которые можно переиспользовать между dispatch и combine. Это снижает потребление памяти и удерживает записи достаточно большими для полной загрузки канала.

На ConnectX 7 MoE-ядра pplx garden показывают лидирующую латентность и превосходят DeepEP на том же оборудовании. На AWS EFA они дают первые практичные MoE латентности для триллионных моделей. Многоузловые тесты на AWS H200 показывают, что распределение модели по узлам снижает латентность при средних размерах батча — характерном рабочем режиме для продакшена.

Главные выводы для команд инфры

• TransferEngine предоставляет единый RDMA point-to-point слой, работающий и на ConnectX 7, и на EFA, управляя несколькими NIC на GPU прозрачно.
• Библиотека поддерживает односторонние WriteImm с ImmCounter и достигает 400 Gbps на обеих семействе NIC, сопоставимую с решениями одного вендора при переносимости.
• Perplexity использует TransferEngine для потоковой передачи KvCache, быстрой передачи весов в RL и маршрутизации MoE, что делает триллионные модели практичными для реальных систем.

Поскольку TransferEngine и pplx garden открыты под MIT, инженерные команды могут запускать очень большие MoE и плотные модели на смешанных кластерах H100/H200 у разных провайдеров без переписывания под каждую сетевую стек-вендора. Для деталей смотрите статью на arXiv: https://arxiv.org/pdf/2510.27656 и репозиторий pplx garden на GitHub.