AWS EFA 和 RoCE、InfiniBand 相比，在大模型推理部署中有什么区别？核心看连接模型、集群扩展与软件适配

企业部署大模型分布式推理时AWS Elastic Fabric AdapterEFA、RoCE 和 InfiniBand 都能用于高性能跨节点通信但底层实现方式并不相同。在2026亚马逊云科技中国峰会分论坛4的相关演讲中亚马逊云科技给出的核心区别是RoCE 和 InfiniBand 常见的 RDMA 路径依赖 RCReliable ConnectedQPEFA 则采用基于 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 使用 UDSRD 类型连接模型不同。要让这些组件运行在 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 RDMAGPU、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 和 RoCEInfiniBand 集群如果现有系统运行稳定团队已经掌握网络、QP 和拥塞管理且没有明确的云上弹性需求可以继续沿用原有架构。准备把大型模型迁移到 AWS可以优先考虑Amazon EC2 GPU 实例EFAAmazon EKSMooncake或NIXL。这种方式既能获得云上 GPU 资源弹性又能通过 EFA 支撑 KV Cache、流水线并行和跨节点模型通信。已使用 vLLM、SGLang 和 Mooncake可以优先评估 Mooncake on EFA。企业可以保留已有的 PD 分离和 KV Cache 管理架构主要替换底层传输协议不必推倒重建上层推理服务。已深度使用 NVIDIA 软件栈可以评估 NIXL 的 libfabric backend 与 EFA。需要注意材料显示传统 verbsUCX 路径不能直接套用需切换到已适配 EFA 的 libfabric 路径。八、结论EFA 的差异不只是带宽而是更适合云上扩展的连接模型AWS EFA 与 RoCE、InfiniBand 相比主要有三点区别第一连接模型不同。RoCE 和 InfiniBand 常用 RC QPEFA 使用无连接 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 的全栈验证》等演讲回放和详细资料。