ИИтог

UCCL-EP: параллельные вычисления на любом сетевом адаптере без инициативы GPU

инфраструктураРедакция ИИтогHacker News🔥50Рейтинг ИИтог50
UCCL-EP: параллельные вычисления на любом сетевом адаптере без инициативы GPU

Когда гигантские модели обучаются на кластерах из разных чипов, слабое звено часто оказывается в сети. UCCL-EP это сетевой слой, который позволяет использовать паттерн параллельных коммуникаций DeepEP (изначально разработанный DeepSeek) на любом оборудовании. Ключевая идея: если GPU не может напрямую управлять сетевой картой, пусть GPU пишет команды в обычную оперативную память хоста, а специальный поток на CPU их исполняет.

Ключевые факты

  • UCCL-EP воспроизводит контракт NVSHMEM (три примитива: одностороннюю запись, атомарный сигнал и синхронизацию) на любой паре GPU и NIC, а не только на NVIDIA-NVIDIA.
  • Вместо того чтобы GPU писал прямо в очереди NIC, GPU пакует 16-байтовые команды в кольцевой буфер в оперативной памяти хоста, а CPU-прокси их обрабатывает.
  • Стоимость отправки одного токена: одна команда и одна запись через PCIe, что только немного медленнее IBGDA.
  • Уже работают бэкенды для AWS EFA, AMD Pollara, Broadcom Thor и NVIDIA ConnectX; портирование требует только реализации интерфейса для конкретного NIC.
  • Компания Doubleword использует это на Isambard-AI (HPE Slingshot), где нет GPU-инициированных коммуникаций, и это критично для экономики инференса.

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

Облачная инфраструктура давит конкуренцию. Если вашим чипам не повезло оказаться не у NVIDIA, а у AMD, AWS, HPE или Broadcom, вы платите штраф за производительность сети. DeepEP из DeepSeek показал, что тонкая координация между GPU и NIC во время инференса может дать кратное ускорение (техники вроде Two-Batch Overlap). До UCCL-EP это было доступно только на NVIDIA.

Кому это важно

Прежде всего облачным провайдерам, которые закупают чипы у разных производителей: AWS (Trainium, Inferentia, EC2), Google (TPU), Broadcom, AMD, а также государственным программам типа UK Sovereign AI. Внутри компании будут интересны инженеры, кто работает с множественными паттернами параллелизма в LLM: распределённый инференс, обслуживание многих малых партий одновременно (batch overlap).

Как это применить

Если вы уже используете PyTorch с процессными группами и всё работает, ничего менять не нужно. UCCL-EP это слой ниже. Но если вы хотите использовать продвинутые техники параллелизма (Two-Batch Overlap, WideEP) на нестандартном оборудовании, нужно либо ждать, пока UCCL добавится в вашу фреймворк (PyTorch, MXNet), либо вносить патч самостоятельно. Для новых NIC нужно написать небольшой бэкенд (реализовать кодирование команд и управление очередями). Главное требование от аппаратуры: NIC должен уметь DMA-читать и DMA-писать в GPU-память.

Можно ли доверять

Дизайн предельно скучный, ровно такой, какой нужен. Вместо магии берутся хорошо известные примитивы: кольцевые буферы, RDMA-команды, синхронизация через completion queue. Авторы подробно разбирают контракт NVSHMEM и показывают, как он преобразуется. Компания Doubleword уже использует это в боевом деплое на реальном суперкомпьютере Isambard-AI. Код похоже готов к выпуску (на момент поста бэкенды существуют для главных NIC).

Риски и подводные камни

Перфоманс CPU-прокси должен быть идеален: если поток зависнет или получит большую задержку, весь трафик встанет. На системе с перегруженным CPU могут быть скрытые задержки (пейджинг, прерывания, контекстные переключения). GPU теперь пишет в оперативную память хоста, что может быть медленнее некоторых шин и требует pinned memory. Сложность отладки: когда GPU через CPU управляет NIC, точка отказа становится невидимой стандартными профайлерами. Также нужно, чтобы NIC поддерживал DMA-доступ к GPU-памяти, это не гарантировано везде.

«Nothing in the DeepEP dispatch and combine kernels depends on how the contract is implemented. The queues, the layouts, the formula addressing all live above it.»

— Fergus Finn, Doubleword