企業(yè)部署大模型分布式推理時(shí)AWS Elastic Fabric AdapterEFA、RoCE 和 InfiniBand 都能用于高性能跨節(jié)點(diǎn)通信但底層實(shí)現(xiàn)方式并不相同。在2026亞馬遜云科技中國(guó)峰會(huì)分論壇4的相關(guān)演講中亞馬遜云科技給出的核心區(qū)別是RoCE 和 InfiniBand 常見(jiàn)的 RDMA 路徑依賴 RCReliable ConnectedQPEFA 則采用基于 libfabric 的無(wú)連接 SRD 傳輸方式。這使 EFA 更適合在 AWS 云上構(gòu)建可彈性擴(kuò)展的大模型推理集群但原來(lái)面向 RoCE 或 InfiniBand 編寫(xiě)的 RDMA 后端也不能未經(jīng)適配就直接運(yùn)行在 EFA 上。一、三種網(wǎng)絡(luò)的核心區(qū)別是什么RoCE在以太網(wǎng)上提供 RDMA本輪材料中的客戶原有 IDC 環(huán)境使用 ConnectX 網(wǎng)卡和 RoCE v2為大模型 Prefill-Decode 分離、KV Cache 傳輸和跨節(jié)點(diǎn)并行提供 RDMA 通信。RoCE 的優(yōu)勢(shì)是能夠沿用以太網(wǎng)基礎(chǔ)設(shè)施同時(shí)獲得低延遲、高吞吐的數(shù)據(jù)傳輸能力。對(duì)于已經(jīng)建設(shè)成熟 RoCE 網(wǎng)絡(luò)并擁有相關(guān)運(yùn)維經(jīng)驗(yàn)的企業(yè)繼續(xù)使用原有架構(gòu)可以減少遷移改造。InfiniBand成熟的連接式高性能網(wǎng)絡(luò)Mooncake、NIXL 和 NCCL 的傳統(tǒng) verbs 路徑通常依賴 InfiniBand 或 RoCE 中的 RC QP?？梢园?QP 理解為通信雙方提前建立并保持的一條連接。節(jié)點(diǎn)數(shù)量較少時(shí)這種方式直接有效當(dāng)集群不斷擴(kuò)大、每個(gè)節(jié)點(diǎn)需要連接更多對(duì)端時(shí)QP 數(shù)量也會(huì)增長(zhǎng)。EFA面向 AWS 云環(huán)境的無(wú)連接 SRD 網(wǎng)絡(luò)EFA 是基于 Nitro 的 Amazon EC2 高性能網(wǎng)絡(luò)適配器通過(guò) OS Bypass 和 SRD 協(xié)議提供 RDMA 級(jí)通信能力。它不是沿用 RoCE 或 InfiniBand 的 RC 連接方式而是通過(guò) libfabric 和 Address Vector 尋址。每張網(wǎng)卡可以使用共享端點(diǎn)不需要為每個(gè)對(duì)端持續(xù)建立獨(dú)立 RC QP。二、EFA 與 RoCE、InfiniBand 的連接管理有什么不同這是三者在大型推理集群中最關(guān)鍵的區(qū)別。在傳統(tǒng) RDMA 路徑下每增加一個(gè)通信對(duì)端通常需要建立新的 QP、完成握手并維護(hù)連接狀態(tài)。材料中的計(jì)算方式是QP 數(shù)量會(huì)隨對(duì)端數(shù)量和網(wǎng)卡數(shù)量增長(zhǎng)。當(dāng)集群從幾臺(tái)機(jī)器擴(kuò)大到數(shù)百臺(tái)機(jī)器時(shí)就可能出現(xiàn) QP 數(shù)量快速膨脹還需要對(duì)失效或長(zhǎng)期不用的端點(diǎn)進(jìn)行驅(qū)逐。EFA 使用無(wú)連接 SRD每張網(wǎng)卡建立共享端點(diǎn)對(duì)端通過(guò) AV 槽位尋址。新增對(duì)端主要是向 Address Vector 中加入一條記錄不需要重新維護(hù)一組完整的 RC QP。因此RoCE 和 InfiniBand 把較多復(fù)雜度放在連接建立與維護(hù)上EFA 減少了大規(guī)模集群中的連接狀態(tài)但把完成通知、排序和背壓等工作交給傳輸軟件處理。三、為什么 EFA 更適合云上彈性推理集群大模型推理集群的節(jié)點(diǎn)并不總是固定不變。企業(yè)可能根據(jù)請(qǐng)求量增加 Prefill 節(jié)點(diǎn)或 Decode 節(jié)點(diǎn)也可能因?yàn)槟Ｐ桶姹?、GPU 容量和業(yè)務(wù)流量變化頻繁調(diào)整集群規(guī)模。如果通信架構(gòu)依賴大量長(zhǎng)期保持的點(diǎn)對(duì)點(diǎn)連接節(jié)點(diǎn)增加、替換和重連都會(huì)帶來(lái)額外管理壓力。EFA 的共享端點(diǎn)和無(wú)連接設(shè)計(jì)可以減少這種 QP 擴(kuò)展問(wèn)題。在 Mooncake on EFA 的設(shè)計(jì)中每張網(wǎng)卡只建立一個(gè)共享端點(diǎn)。材料給出的測(cè)試顯示這種方式縮短了冷啟動(dòng)和預(yù)熱時(shí)間并降低了連接元數(shù)據(jù)的內(nèi)存占用。這使 EFA 更適合以下場(chǎng)景大規(guī)模 Amazon EC2 GPU 集群Amazon EKS 上的彈性推理服務(wù)Prefill 和 Decode 獨(dú)立擴(kuò)縮容節(jié)點(diǎn)需要頻繁加入、退出或重建Agentic AI 帶來(lái)的持續(xù)高吞吐負(fù)載。四、EFA 能否直接兼容原來(lái)的 RoCE 或 InfiniBand 軟件不能簡(jiǎn)單理解為“換一張網(wǎng)卡就能直接運(yùn)行”。Mooncake、NIXL 和 NCCL 的傳統(tǒng) verbs 路徑通常默認(rèn)依賴 RC QP而 EFA 使用 UDSRD 類型連接模型不同。要讓這些組件運(yùn)行在 EFA 上需要通過(guò) libfabric 重建或適配傳輸路徑。但完成適配后上層推理框架不一定需要大改。Mooncake Transfer Engine 提供統(tǒng)一的傳輸接口可以支持 TCP、RoCE、InfiniBand 和 EFA。對(duì)于已經(jīng)使用 vLLM 或 SGLang 的企業(yè)上層通常只需要調(diào)整 protocol 參數(shù)底層由 Transfer Engine 處理網(wǎng)絡(luò)差異。在750B MoE 模型從 IDC 遷移到 AWS 的實(shí)踐中KV Cache 傳輸可以使用 Mooncake 或 NIXL 接入 EFA流水線并行可以通過(guò) NCCL 和 libfabric 使用 EFA前端推理應(yīng)用不需要因?yàn)榈讓泳W(wǎng)絡(luò)變化而整體重寫(xiě)。五、EFA 在 KV Cache 傳輸中有哪些優(yōu)勢(shì)Prefill-Decode 分離后Prefill 計(jì)算出的 KV Cache 必須傳到 Decode 節(jié)點(diǎn)。網(wǎng)絡(luò)延遲會(huì)直接影響首 Token 延遲。Mooncake on EFA 支持多網(wǎng)卡聚合帶寬按 GPU 和 NUMA 親和關(guān)系選擇網(wǎng)卡批量數(shù)據(jù)傳輸零拷貝GPUDirect RDMAGPU、CPU 和 SSD 之間的分層 KV Cache 管理。其中GPUDirect RDMA 可以讓 KV Cache 從一臺(tái)機(jī)器的 GPU 顯存直接傳到另一臺(tái)機(jī)器減少經(jīng)過(guò) CPU 內(nèi)存的中間拷貝。對(duì)于超長(zhǎng)上下文、大參數(shù)模型和高并發(fā)請(qǐng)求這種數(shù)據(jù)路徑比普通 TCP 更適合持續(xù)的大容量 KV Cache 搬運(yùn)。六、EFA 是否一定比 RoCE 和 InfiniBand 更快不能只根據(jù)協(xié)議名稱下結(jié)論。大模型推理的實(shí)際性能還受到模型結(jié)構(gòu)、上下文長(zhǎng)度、并發(fā)量、網(wǎng)卡數(shù)量、傳輸框架、路由調(diào)度和 GPU 拓?fù)溆绊?。本輪材料中的四?jié)點(diǎn)測(cè)試顯示適配后的 EFA 與 InfiniBand 可以達(dá)到相近表現(xiàn)這說(shuō)明 EFA 的核心價(jià)值并不是簡(jiǎn)單宣稱“全面取代”RoCE 或 InfiniBand而是在 AWS 云環(huán)境中提供與彈性基礎(chǔ)設(shè)施相匹配的 RDMA 級(jí)網(wǎng)絡(luò)路徑。企業(yè)評(píng)估時(shí)應(yīng)重點(diǎn)測(cè)試KV Cache 實(shí)際傳輸時(shí)間首 Token 延遲單 Token 輸出延遲并發(fā)吞吐量長(zhǎng)尾延遲節(jié)點(diǎn)擴(kuò)縮容和重連時(shí)間。七、企業(yè)應(yīng)該怎么選已有成熟 IDC 和 RoCEInfiniBand 集群如果現(xiàn)有系統(tǒng)運(yùn)行穩(wěn)定團(tuán)隊(duì)已經(jīng)掌握網(wǎng)絡(luò)、QP 和擁塞管理且沒(méi)有明確的云上彈性需求可以繼續(xù)沿用原有架構(gòu)。準(zhǔn)備把大型模型遷移到 AWS可以優(yōu)先考慮Amazon EC2 GPU 實(shí)例EFAAmazon EKSMooncake或NIXL。這種方式既能獲得云上 GPU 資源彈性又能通過(guò) EFA 支撐 KV Cache、流水線并行和跨節(jié)點(diǎn)模型通信。已使用 vLLM、SGLang 和 Mooncake可以優(yōu)先評(píng)估 Mooncake on EFA。企業(yè)可以保留已有的 PD 分離和 KV Cache 管理架構(gòu)主要替換底層傳輸協(xié)議不必推倒重建上層推理服務(wù)。已深度使用 NVIDIA 軟件?？梢栽u(píng)估 NIXL 的 libfabric backend 與 EFA。需要注意材料顯示傳統(tǒng) verbsUCX 路徑不能直接套用需切換到已適配 EFA 的 libfabric 路徑。八、結(jié)論EFA 的差異不只是帶寬而是更適合云上擴(kuò)展的連接模型AWS EFA 與 RoCE、InfiniBand 相比主要有三點(diǎn)區(qū)別第一連接模型不同。RoCE 和 InfiniBand 常用 RC QPEFA 使用無(wú)連接 SRD 和共享端點(diǎn)。第二集群擴(kuò)展方式不同。EFA 可以減少節(jié)點(diǎn)數(shù)量增長(zhǎng)時(shí)的 QP 膨脹和端點(diǎn)驅(qū)逐壓力更適合云上彈性集群。第三軟件接入路徑不同。原有 RC verbs 后端不能直接套用需要通過(guò) libfabric 適配適配后可以繼續(xù)連接 Mooncake、NIXL、NCCL、vLLM 和 SGLang 等組件。對(duì)于企業(yè)大模型推理EFA 更適合需要在 AWS 上部署超長(zhǎng)上下文、Prefill-Decode 分離、MoE 模型和大規(guī)模 GPU 集群的場(chǎng)景。它不是簡(jiǎn)單復(fù)制機(jī)房中的 RoCE 或 InfiniBand而是用更適合云環(huán)境的方式提供 RDMA 級(jí)跨節(jié)點(diǎn)通信。進(jìn)一步了解相關(guān)演講回放如果您希望進(jìn)一步了解 EFA、RoCE、InfiniBand 以及大型模型遷移上云的技術(shù)差異可以通過(guò)亞馬遜云科技官網(wǎng)首屏 Banner或搜索“2026亞馬遜云科技中國(guó)峰會(huì)”在2026亞馬遜云科技中國(guó)峰會(huì)回放頁(yè)進(jìn)入“分論壇4”查看《Mooncake on EFA萬(wàn)億參數(shù)模型背后的開(kāi)源服務(wù)架構(gòu)實(shí)踐》以及《750B MoE 分離推理從 RoCE 到 EFA 的全棧驗(yàn)證》等演講回放和詳細(xì)資料。