MetaRoCE — это попытка перенести интеллект из сети на край системы. Для AI-кластеров это важно, потому что именно сеть часто становится критическим путём для training и inference.
Meta упирается в одну и ту же границу, когда кластер растёт до сотен тысяч GPU и распределяется между дата-центрами и регионами. Для distributed AI training медленнее всего работает не вычисление, а синхронизация через all-reduce и all-to-all. Для inference проблема другая, но логика та же: низкая latency между shard’ами модели напрямую влияет на время ответа. Даже небольшое сетевое трение оставляет часть compute без работы.
Стандартный RoCE опирается на порядок доставки и lossless-поведение сети. Для этого традиционно используются PFC и ограничения на packet spraying, что плохо сочетается с multiplane и крупными Ethernet-топологиями. MetaRoCE выбирает другой компромисс: сеть признаётся потенциально lossy, а устойчивость переносится в transport и NIC. Это даёт высокий throughput, низкую tail latency и более простую эксплуатацию по мере роста числа ускорителей и расстояний между ними.
Ключевая идея MetaRoCE звучит просто: fabric видит packets, а NIC видит intent. Вместо того чтобы централизовать интеллект в switches, протокол дробит сеть на множество логических paths с собственной телеметрией. Для каждого пути отслеживаются RTT, ECN state и utilization. Это даёт endpoint’у возможность принимать решения локально и не ждать, пока fabric «сделает всё правильно» за него.
Практически это означает intentional out-of-order delivery. MetaRoCE sprays packets across many paths, и они приходят не по порядку. Но transport трактует это как норму, а не как исключение. Каждый packet несёт destination, поэтому данные пишутся сразу в конечное memory location без reorder buffer и без head-of-line blocking. Для Writes это особенно важно. Для Sends используется привязка к posted receive buffer, поэтому сообщение может быть доставлено корректно без round trip, который нужен для определения адресата.
Такой подход меняет и поведение congestion control. Каждый connection получает собственные first-class paths, а NIC может менять UDP source port, чтобы переносить трафик на другие ECMP-ветки. На multiplane fabric выбор plane тоже остаётся за NIC. Если один путь перегрет или сломан, страдает только этот path, а не весь connection. Это более точная реакция, чем остановка потока целиком. Для AI workloads, где большая доля трафика идёт через коллективные операции, это критично.
Отдельная инженерная деталь — работа с loss. MetaRoCE не требует PFC и не опирается на pause frames. У каждого пути есть свой ordered sequence и свой 256-bit selective acknowledgment bitvector. Если в битвекторе есть gap, это интерпретируется как loss, а не как reordering. Тогда retransmission запускается точечно: отправляется именно недостающий packet и именно по тому пути, где он потерялся. Это сдержанный, но важный сдвиг. Протокол перестаёт бороться с loss как с аномалией и начинает управлять им как с обычным системным состоянием.
Поверх этого MetaRoCE сочетает ECN-based sender-driven AIMD congestion control и receiver-driven fair-share rate hints. Windows ведутся и per path, и per connection. Поэтому congestion mark режет только тот path, который его получил, а receiver в каждом acknowledgment возвращает долю inbound bandwidth, выделенную этому sender. В результате senders приближаются к нужной скорости напрямую, без долгого поиска. Для incast это особенно полезно: нагрузка, по словам Meta, сходится за одну-две round trip и даёт лучшую fairness при меньшей tail latency.
Есть и архитектурный аргумент в пользу такого дизайна. MetaRoCE не требует packet trimming, in-network telemetry, credit-based flow control или switch-side spraying. Протокол использует только ECN и ECMP, которые уже есть в большинстве Ethernet fabrics. Это снижает зависимость от конкретной конфигурации сети и делает transport применимым на fat-tree, multiplane, deep-buffer и shallow-buffer fabrics, а также в vendor clouds, где настройки сети нельзя контролировать полностью. Trade-off здесь очевиден: сложность переносится на endpoint, но взамен система становится менее зависимой от поведения fabric.
На уровне API тоже выбран прагматичный путь. Один queue pair теперь несёт и ordered stream of messages, и bandwidth. В традиционном RDMA для увеличения parallelism часто открывают десятки QP на пару узлов, и каждое из них живёт со своей congestion state. MetaRoCE разделяет эти роли. Сверху остаются несколько ordered streams, снизу — много paths под одним congestion controller. При этом существующие RDMA Verbs APIs и стек software в основном остаются без изменений, а расширения нужны только для функций вроде multiplane.
Для валидации Meta работала с AMD и реализовала MetaRoCE на programmable Pensando NICs. На 64-node AMD GPU cluster с RCCL collectives протокол сравнивали с RoCEv2 на all-reduce и all-to-all. По описанию результата MetaRoCE показал более высокий throughput и более низкий flow completion time. При 1% packet loss он сохранял около 86% throughput, а при 10% loss продолжал выдавать полезную bandwidth вместо резкого collapse. На 4-plane и 8-plane topologies throughput масштабировался линейно с числом planes, а при имитации failure traffic перераспределялся без участия application или operator.
Пока это выглядит как эволюционное улучшение transport layer для AI-инфраструктуры на commodity Ethernet. Дальше Meta отдельно выделяет scale-up, scale-across и storage/Kv-cache сценарии, но конкретные результаты по ним в исходнике не приведены. Из фактов есть только то, что Meta планирует открыть спецификацию, software reference implementation и compliance framework через OCP, а также развивать поддержку разных NIC architectures. Для индустрии это важный сигнал: ставка сделана не только на производительность, но и на интероперабельность.