MetaRoCE — это transport layer для AI инфраструктуры, где сеть становится частью critical path. Для распределённого обучения и inference это важно, потому что даже небольшая потеря или задержка в сети напрямую бьют по throughput и tail latency.
Слабое место здесь не в одном конкретном линке, а в поведении системы под нагрузкой. В кластерах из сотен тысяч GPU сеть находится в критическом пути, потому что коллективные операции вроде all-reduce и all-to-all синхронизируют тысячи ускорителей. В inference ситуация похожая: низкая latency между шардированными частями модели влияет на отклик для сотен миллионов пользователей. Если сеть начинает давать трение, compute capacity простаивает.
Meta выбрала MetaRoCE как протокол, который изначально проектировался для Ethernet и масштабов до million-GPU. Базовая идея меняет место, где живёт интеллект: fabric видит пакеты, а NIC видит intent. Это компромиссный, но прагматичный сдвиг. Вместо того чтобы заставлять сеть быть lossless и держать порядок кадров, протокол принимает lossy Ethernet как норму и переносит ответственность за маршрутизацию, восстановление и балансировку на endpoint.
Реализация строится вокруг нескольких решений. MetaRoCE размечает сеть на множество fine-grained logical paths и ведёт для каждого свою телеметрию: per-path RTT, ECN state и utilization. Пакеты spray-ятся по разным путям и могут приходить out of order по дизайну. Это убирает reorder buffer и head-of-line blocking, а данные пишутся сразу в финальную память по destination, указанному в каждом пакете. Для потерь используется selective acknowledgment: если в 256-bit SACK bitvector появляется gap, это трактуется как loss, и недостающий пакет ретранслируется по тому же пути.
Отдельно важно, что MetaRoCE разделяет transport semantics и поведение очередей. Writes несут адрес назначения в каждом пакете, а Sends используют posted receive buffer, поэтому сообщение может быть доставлено корректно без round trip для уточнения места записи. Для congestion control протокол сочетает ECN-based sender-driven AIMD и receiver-driven fair-share rate hints. При этом window ведётся и на уровне path, и на уровне connection, чтобы congested или broken link замедлял только один маршрут, а не весь поток.
С точки зрения эксплуатации это заметное упрощение. MetaRoCE не требует PFC, pause frames, packet trimming, in-network telemetry, credit-based flow control или switch-side spraying. Он опирается на то, что уже есть в Ethernet: ECN и ECMP. Это делает протокол совместимым с fat-tree, multiplane, deep-buffer и shallow-buffer fabric, а также с vendor clouds, где конфигурация сети не принадлежит одной команде. Такой подход снижает зависимость от специализированной аппаратной логики и сохраняет свободу оптимизации на стороне fabric.
Есть и важный архитектурный эффект для QP model. В традиционном RDMA масштабирование часто упирается в количество queue pairs, потому что каждое дополнительное соединение приносит собственное состояние и отдельную congestion window. MetaRoCE отделяет ordered stream сверху от bandwidth below. Один connection может нести много независимых ordered streams, а путьов ниже становится много. Это сохраняет состояние NIC от разрастания вместе с параллелизмом workload.
На практике протокол уже проверяли на AMD Pensando programmable NICs. На 64-node AMD GPU cluster с RCCL collectives MetaRoCE сравнивали с RoCEv2 на all-reduce и all-to-all. По исходным данным он стабильно показывал higher throughput и lower flow completion times. При 1% packet loss он сохранял около 86% throughput, а при 10% loss продолжал давать полезную bandwidth вместо резкого collapse. На multiplane topology с 4 и 8 плоскостями throughput масштабировался линейно с числом planes, а при simulated plane failures traffic перераспределялся без участия приложения и оператора.
Итог у этой конструкции довольно ясный. MetaRoCE не пытается сделать Ethernet идеальным. Он делает сеть предсказуемой в условиях потерь, неравномерной загрузки и частичных отказов. Для AI infrastructure это практичное улучшение, потому что оно сохраняет производительность в норме и даёт системе достойное поведение, когда ситуация ухудшается. Отдельно важно, что Meta открывает specification, compliance suite и software reference implementation через OCP, а это уже влияет не только на одну реализацию, но и на возможность межвендорной совместимости.