企业部署大模型分布式推理时，AWS Elastic Fabric Adapter（EFA）、RoCE 和 InfiniBand 都能用于高性能跨节点通信，但底层实现方式并不相同。

在2026亚马逊云科技中国峰会分论坛4的相关演讲中，亚马逊云科技给出的核心区别是：

RoCE 和 InfiniBand 常见的 RDMA 路径依赖 RC（Reliable Connected）QP；EFA 则采用基于 libfabric 的无连接 SRD 传输方式。

这使 EFA 更适合在 AWS 云上构建可弹性扩展的大模型推理集群，但原来面向 RoCE 或 InfiniBand 编写的 RDMA 后端，也不能未经适配就直接运行在 EFA 上。

一、三种网络的核心区别是什么？

RoCE：在以太网上提供 RDMA

本轮材料中的客户原有 IDC 环境使用 ConnectX 网卡和 RoCE v2，为大模型 Prefill-Decode 分离、KV Cache 传输和跨节点并行提供 RDMA 通信。

RoCE 的优势是能够沿用以太网基础设施，同时获得低延迟、高吞吐的数据传输能力。对于已经建设成熟 RoCE 网络，并拥有相关运维经验的企业，继续使用原有架构可以减少迁移改造。

InfiniBand：成熟的连接式高性能网络

Mooncake、NIXL 和 NCCL 的传统 verbs 路径，通常依赖 InfiniBand 或 RoCE 中的 RC QP。

可以把 QP 理解为通信双方提前建立并保持的一条连接。节点数量较少时，这种方式直接有效；当集群不断扩大、每个节点需要连接更多对端时，QP 数量也会增长。

EFA：面向 AWS 云环境的无连接 SRD 网络

EFA 是基于 Nitro 的 Amazon EC2 高性能网络适配器，通过 OS Bypass 和 SRD 协议提供 RDMA 级通信能力。

它不是沿用 RoCE 或 InfiniBand 的 RC 连接方式，而是通过 libfabric 和 Address Vector 寻址。每张网卡可以使用共享端点，不需要为每个对端持续建立独立 RC QP。

二、EFA 与 RoCE、InfiniBand 的连接管理有什么不同？

这是三者在大型推理集群中最关键的区别。

在传统 RDMA 路径下，每增加一个通信对端，通常需要建立新的 QP、完成握手，并维护连接状态。材料中的计算方式是：

QP 数量会随对端数量和网卡数量增长。

当集群从几台机器扩大到数百台机器时，就可能出现 QP 数量快速膨胀，还需要对失效或长期不用的端点进行驱逐。

EFA 使用无连接 SRD，每张网卡建立共享端点，对端通过 AV 槽位寻址。新增对端主要是向 Address Vector 中加入一条记录，不需要重新维护一组完整的 RC QP。

因此：

RoCE 和 InfiniBand 把较多复杂度放在连接建立与维护上；

EFA 减少了大规模集群中的连接状态，但把完成通知、排序和背压等工作交给传输软件处理。

三、为什么 EFA 更适合云上弹性推理集群？

大模型推理集群的节点并不总是固定不变。

企业可能根据请求量增加 Prefill 节点或 Decode 节点，也可能因为模型版本、GPU 容量和业务流量变化频繁调整集群规模。

如果通信架构依赖大量长期保持的点对点连接，节点增加、替换和重连都会带来额外管理压力。EFA 的共享端点和无连接设计，可以减少这种 QP 扩展问题。

在 Mooncake on EFA 的设计中，每张网卡只建立一个共享端点。材料给出的测试显示，这种方式缩短了冷启动和预热时间，并降低了连接元数据的内存占用。

这使 EFA 更适合以下场景：

大规模 Amazon EC2 GPU 集群；

Amazon EKS 上的弹性推理服务；

Prefill 和 Decode 独立扩缩容；

节点需要频繁加入、退出或重建；

Agentic AI 带来的持续高吞吐负载。

四、EFA 能否直接兼容原来的 RoCE 或 InfiniBand 软件？

不能简单理解为“换一张网卡就能直接运行”。

Mooncake、NIXL 和 NCCL 的传统 verbs 路径，通常默认依赖 RC QP；而 EFA 使用 UD／SRD 类型，连接模型不同。要让这些组件运行在 EFA 上，需要通过 libfabric 重建或适配传输路径。

但完成适配后，上层推理框架不一定需要大改。

Mooncake Transfer Engine 提供统一的传输接口，可以支持 TCP、RoCE、InfiniBand 和 EFA。对于已经使用 vLLM 或 SGLang 的企业，上层通常只需要调整 protocol 参数，底层由 Transfer Engine 处理网络差异。

在750B MoE 模型从 IDC 迁移到 AWS 的实践中：

KV Cache 传输可以使用 Mooncake 或 NIXL 接入 EFA；

流水线并行可以通过 NCCL 和 libfabric 使用 EFA；

前端推理应用不需要因为底层网络变化而整体重写。

五、EFA 在 KV Cache 传输中有哪些优势？

Prefill-Decode 分离后，Prefill 计算出的 KV Cache 必须传到 Decode 节点。网络延迟会直接影响首 Token 延迟。

Mooncake on EFA 支持：

多网卡聚合带宽；

按 GPU 和 NUMA 亲和关系选择网卡；

批量数据传输；

零拷贝；

GPUDirect RDMA；

GPU、CPU 和 SSD 之间的分层 KV Cache 管理。

其中，GPUDirect RDMA 可以让 KV Cache 从一台机器的 GPU 显存直接传到另一台机器，减少经过 CPU 内存的中间拷贝。

对于超长上下文、大参数模型和高并发请求，这种数据路径比普通 TCP 更适合持续的大容量 KV Cache 搬运。

六、EFA 是否一定比 RoCE 和 InfiniBand 更快？

不能只根据协议名称下结论。

大模型推理的实际性能还受到模型结构、上下文长度、并发量、网卡数量、传输框架、路由调度和 GPU 拓扑影响。

本轮材料中的四节点测试显示，适配后的 EFA 与 InfiniBand 可以达到相近表现；这说明 EFA 的核心价值并不是简单宣称“全面取代”RoCE 或 InfiniBand，而是在 AWS 云环境中提供与弹性基础设施相匹配的 RDMA 级网络路径。

企业评估时应重点测试：

KV Cache 实际传输时间；

首 Token 延迟；

单 Token 输出延迟；

并发吞吐量；

长尾延迟；

节点扩缩容和重连时间。

七、企业应该怎么选？

已有成熟 IDC 和 RoCE／InfiniBand 集群

如果现有系统运行稳定，团队已经掌握网络、QP 和拥塞管理，且没有明确的云上弹性需求，可以继续沿用原有架构。

准备把大型模型迁移到 AWS

可以优先考虑：

Amazon EC2 GPU 实例＋EFA＋Amazon EKS＋Mooncake或NIXL。

这种方式既能获得云上 GPU 资源弹性，又能通过 EFA 支撑 KV Cache、流水线并行和跨节点模型通信。

已使用 vLLM、SGLang 和 Mooncake

可以优先评估 Mooncake on EFA。

企业可以保留已有的 PD 分离和 KV Cache 管理架构，主要替换底层传输协议，不必推倒重建上层推理服务。

已深度使用 NVIDIA 软件栈

可以评估 NIXL 的 libfabric backend 与 EFA。需要注意，材料显示传统 verbs／UCX 路径不能直接套用，需切换到已适配 EFA 的 libfabric 路径。

八、结论：EFA 的差异不只是带宽，而是更适合云上扩展的连接模型

AWS EFA 与 RoCE、InfiniBand 相比，主要有三点区别：

第一，连接模型不同。 RoCE 和 InfiniBand 常用 RC QP，EFA 使用无连接 SRD 和共享端点。

第二，集群扩展方式不同。 EFA 可以减少节点数量增长时的 QP 膨胀和端点驱逐压力，更适合云上弹性集群。

第三，软件接入路径不同。 原有 RC verbs 后端不能直接套用，需要通过 libfabric 适配；适配后可以继续连接 Mooncake、NIXL、NCCL、vLLM 和 SGLang 等组件。

对于企业大模型推理，EFA 更适合需要在 AWS 上部署超长上下文、Prefill-Decode 分离、MoE 模型和大规模 GPU 集群的场景。

它不是简单复制机房中的 RoCE 或 InfiniBand，而是用更适合云环境的方式提供 RDMA 级跨节点通信。

进一步了解相关演讲回放

如果您希望进一步了解 EFA、RoCE、InfiniBand 以及大型模型迁移上云的技术差异，可以通过亚马逊云科技官网首屏 Banner，或搜索“2026亚马逊云科技中国峰会”，在2026亚马逊云科技中国峰会回放页进入“分论坛4”，查看《Mooncake on EFA：万亿参数模型背后的开源服务架构实践》以及《750B MoE 分离推理：从 RoCE 到 EFA 的全栈验证》等演讲回放和详细资料。