TransferEngine：可移植的RDMA通信庫

本文從一個實際的工程問題（供應(yīng)商鎖定的RDMA硬件）出發(fā)，通過深刻的抽象（TransferEngine及其IMMCOUNTER機制），提供了一個可移植的高性能P2P通信解決方案。它不僅解決了AWS EFA上部署萬億參數(shù)MoE模型的難題，更在NVIDIA ConnectX-7上實現(xiàn)了超越專有方案的SOTA性能，充分展示了其架構(gòu)的先進性和通用性。

核心邏輯：為了在云端（特別是AWS EFA）高效部署萬億參數(shù)的MoE模型，必須解決現(xiàn)代LLM架構(gòu)對靈活通信的需求與異構(gòu)RDMA硬件（如EFA和ConnectX）間“供應(yīng)商鎖定”的矛盾。    

本文的核心貢獻是TransferEngine：一個可移植的RDMA通信庫。它通過一個關(guān)鍵洞察——即抽象出不同硬件（EFA和ConnectX）的共同功能（可靠但無序的交付）——成功解決了這一挑戰(zhàn)。它不依賴消息排序，而是使用一個新穎的IMMCOUNTER原語來處理完成通知，從而在不同平臺上提供了統(tǒng)一的高性能接口。

1. 核心問題：現(xiàn)代LLM通信需求的“鎖”

LLM的架構(gòu)（如MoE路由、解耦推理）正變得日益復雜。這些新架構(gòu)嚴重依賴靈活、稀疏的點對點（P2P）通信。

然而，現(xiàn)有的LLM框架和通信庫（如NCCL）主要依賴集合通信（Collectives）。這種模式存在四大局限，無法滿足新興需求：

• 固定成員：阻礙動態(tài)擴展。
• 同步初始化：增加開銷。
• 操作排序：強加不必要的同步。
• 形狀統(tǒng)一：無法高效處理稀疏模式。

最大的障礙是硬件供應(yīng)商鎖定。不同的云平臺和硬件商使用不同的RDMA實現(xiàn)：

• NVIDIA ConnectX：使用傳統(tǒng)的可靠連接（RC）傳輸，并獨家支持GPU直接啟動RDMA（IBGDA）。
• AWS EFA（Elastic Fabric Adapter）：使用專有的SRD協(xié)議（可擴展的可靠數(shù)據(jù)報），提供可靠但無序的交付，且不支持IBGDA。

這導致現(xiàn)有的高性能MoE內(nèi)核（如DeepEP）無法在EFA上運行，而通用庫（如NVSHMEM）在EFA上則表現(xiàn)出嚴重的性能下降。

2. 核心洞察與抽象：TransferEngine

本文的突破點在于找到了跨越硬件鴻溝的共同基礎(chǔ)。

核心洞察：無論是ConnectX的RC（可以不依賴其排序）還是EFA的SRD（本質(zhì)上無序），它們的核心共同點是可靠但無序的交付。

解決方案 TransferEngine：一個可移植的RDMA通信庫，它抓住了這個共同點。

關(guān)鍵機制 IMMCOUNTER

該引擎不依賴網(wǎng)絡(luò)傳輸?shù)南⑴判騺磉M行完成通知，而是引入了一個新穎的 IMMCOUNTER 原語。

• WRITEIMM 操作在完成時會自動遞增接收方的計數(shù)器，從而實現(xiàn)高效、原子的完成通知，且無需假設(shè)排序。

統(tǒng)一接口與多NIC管理：TransferEngine 提供了統(tǒng)一的API（如SEND/RECV、WRITEIMM），并能透明地管理和聚合每個GPU的多個NIC（例如，在AWS p5en實例上聚合2個200Gbps的EFA NIC以達到400Gbps）。

3. 核心應(yīng)用（一）：MoE 路由（EFA上的萬億模型部署）

這是本文中展示的旗艦應(yīng)用，旨在解決EFA上部署MoE的獨特挑戰(zhàn)。

EFA的挑戰(zhàn)與優(yōu)化策略

EFA的挑戰(zhàn)：由于EFA缺乏GPUDirect Async (IBGDA)，數(shù)據(jù)傳輸必須由 CPU代理線程（Host Proxy） 啟動，而非GPU。這引入了額外的GPU-CPU-NIC通信，增加了PCIe事務(wù)和微秒級延遲。

本文的優(yōu)化策略：

• CPU-GPU混合架構(gòu)：采用了GPU內(nèi)核（與模型交互）和主機CPU代理線程（處理NIC交互）的混合架構(gòu)。
• 最小化交互：整個設(shè)計的核心是最小化GPU內(nèi)核與主機代理之間的交互開銷。
• 兩階段批量傳輸：為克服代理延遲，內(nèi)核避免了逐個Token傳輸。

階段一（元數(shù)據(jù)交換）：dispatch（調(diào)度）內(nèi)核首先在GPU上聚合路由信息，然后將其復制到主機內(nèi)存，通知代理開始交換這些小塊的路由信息。

階段二（批量數(shù)據(jù)傳輸）：一旦所有Rank交換了路由信息，所有Token被打包并通過單個（或少量）RDMA寫入操作批量發(fā)送。

• 隱藏延遲：在交換路由元數(shù)據(jù)（高延遲）的同時，內(nèi)核會并行地將一小部分Token寫入遠程的私有緩沖區(qū)。這確保了在等待路由計算完成時，網(wǎng)絡(luò)帶寬已被充分利用。
• NVLink優(yōu)化：在節(jié)點內(nèi)部，內(nèi)核利用NVLink進行Token交換，這卸載了相當一部分網(wǎng)絡(luò)流量。

結(jié)果

• EFA：實現(xiàn)了首個在EFA上具有可行延遲的MoE部署。其性能顯著優(yōu)于其他基于EFA的內(nèi)核（如UCCL-EP）。
• ConnectX-7：這種為EFA優(yōu)化的內(nèi)核，在ConnectX-7上（同樣使用主機代理）的解碼延遲超越了依賴IBGDA（GPU啟動）的DeepEP。這證明了其批量傳輸架構(gòu)的優(yōu)越性足以彌補主機代理的開銷。

4. 核心應(yīng)用（二）&（三）：驗證TransferEngine的通用性

TransferEngine的價值不僅限于MoE，論文還展示了其在另外兩個生產(chǎn)系統(tǒng)中的應(yīng)用：

• KvCache傳輸（解耦推理）：用于分離的prefill和decode集群。TransferEngine 提供了動態(tài)、彈性的KV Cache頁傳輸，支持層級傳輸（layer-by-layer transfers）并兼容CUDA Graph。
• RL權(quán)重更新：用于異步強化學習微調(diào)（RLHF）。通過P2P RDMA WRITE，訓練GPU可直接將權(quán)重寫入推理GPU內(nèi)存，實現(xiàn)了萬億參數(shù)模型 1.3秒 的極速權(quán)重更新（比現(xiàn)有框架快100倍以上）。

在AWS EFA上實現(xiàn)萬億參數(shù)模型的部署

賦于萬億參數(shù)模型云平臺可移植性

在Perplexity，我們?yōu)楫a(chǎn)品、API和研究團隊采用最優(yōu)模型。大型開源混合專家模型（Mixture-of-Experts，MoE），如Kimi-K2，帶來了特殊的挑戰(zhàn)，因為最大的推理節(jié)點配備8x NVIDIA H200 GPU無法高效承載，因此需要多節(jié)點部署。我們提出了一套專家并行內(nèi)核，在ConnectX-7上實現(xiàn)了領(lǐng)先的延遲表現(xiàn)，超越了DeepEP的性能。相同的內(nèi)核也是首批在AWS EFA（Elastic Fabric Adapter）上實現(xiàn)可接受延遲的內(nèi)核，從而實現(xiàn)了萬億參數(shù)模型的部署。

引言

混合專家（Mixture-of-Experts，MoE）已成為將模型擴展至數(shù)千億乃至萬億參數(shù)規(guī)模的標準架構(gòu)，同時在推理過程中仍能保持合理的延遲。MoE模型用一組專家和一個小型線性路由層取代了Transformer中的密集層，該路由層用于決定將Token路由至哪個或哪些專家進行乘法運算。通過將與同一專家關(guān)聯(lián)的Token分組，計算變得稀疏且易于并行化，因為不同的專家可以分布并托管在跨多個節(jié)點的GPU上。

不同于張量并行（Tensor Parallelism，TP）和數(shù)據(jù)并行（Data Parallelism，DP）等其他并行形式，這些形式可通過torch.distributed和NCCL等集體通信庫輕松實現(xiàn)，MoE路由則涉及稀疏的點對點通信。調(diào)度內(nèi)核（dispatch kernel）必須將輸入的Token集合進行拆分，并將其調(diào)度到托管專家的計算秩（ranks）上，而其對偶操作——合并內(nèi)核（combine kernel）——則必須接收經(jīng)過處理的結(jié)果，并計算其加權(quán)平均值。由于這些傳輸無法直接映射到集體通信操作，因此需要定制化的內(nèi)核來確保實現(xiàn)低延遲。

在Perplexity，我們持續(xù)開發(fā)可移植的節(jié)點間內(nèi)核和優(yōu)化的節(jié)點內(nèi)內(nèi)核，我們已在先前關(guān)于MoE通信的文章中詳細介紹了此項工作（https://research.perplexity.ai/articles/efficient-and-portable-mixture-of-experts-communication）。我們還在另一篇博客文章中展示了多節(jié)點部署可以為大型MoE模型帶來更低的延遲和更高的吞吐量（https://research.perplexity.ai/articles/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment）。

在本文中，我們深入探討了新型節(jié)點間內(nèi)核的實現(xiàn)細節(jié)，該內(nèi)核極大地提升了我們先前基于NVSHMEM方案的性能。除了展示在ConnectX-7適配器上的領(lǐng)先結(jié)果外，這些內(nèi)核在我們的推理運行時環(huán)境中，能夠高效地支持最大的開源模型服務(wù)。

在InfiniBand上的推理

張量并行和專家并行可以在單個節(jié)點內(nèi)高效擴展，因為NVLink可提供900GB/s的吞吐量和微秒級的延遲。雖然NVIDIA GB200和GB300系統(tǒng)配備了充足的內(nèi)存以容納萬億參數(shù)模型的權(quán)重和KV Cache，然而，AWS p5en實例（配備最多8個H200 GPU）的部署僅限于1120GB的HBM，這部分內(nèi)存必須在模型權(quán)重和KV Cache之間進行劃分。因此，部分模型需要依賴InfiniBand進行跨節(jié)點部署。

盡管InfiniBand的速率雖然依然很高，但它僅提供400Gbps（50GB/s）的吞吐量，這為MoE路由增加了數(shù)十到數(shù)百微秒的延遲開銷。幸運的是，通過使用共享專家、微批處理（micro-batching）和計算-通信重疊，這些額外的延遲可以被有效隱藏，從而以具備競爭力的成本實現(xiàn)可接受的吞吐量。DeepSeek憑借其DeepSeek-R1模型率先采用了這些技術(shù)，該模型部署在H800 GPU集群和NVIDIA ConnectX-7 InfiniBand適配器上。

在AWS集群上，情況則有所不同，因為采用了定制化的EFA。盡管這些適配器在訓練工作負載通常使用的集體操作上提供峰值400Gbps吞吐量，但在MoE調(diào)度和合并過程中涉及的消息大小方面，其表現(xiàn)略遜于ConnectX-7。此外，EFA不支持GPUDirect Async，因此需要通過CPU代理線程在GPU與NIC之間進行橋接來啟動數(shù)據(jù)傳輸。除了由此帶來的復雜性增加外，額外的PCIe事務(wù)還會為所有傳輸操作增加微秒級的開銷。NVSHMEM等框架使內(nèi)核編寫者能夠提供設(shè)備無關(guān)的實現(xiàn)，然而，通用的API調(diào)用會引入額外的開銷，導致在成本和延遲方面部署效率低下。

基于NVSHMEM的pplx-kernels

我們之前的內(nèi)核對底層傳輸實現(xiàn)進行了抽象。它們依賴nvshmemx_putmem_signal_nbi_warp逐個傳輸Token，并使用原子計數(shù)器實現(xiàn)對等方之間的同步。雖然這在配備IBGDA的ConnectX-7 NIC上提供了合理的性能，但基于代理的ConnectX-7 IBRC實現(xiàn)性能顯著較慢，同時EFA實現(xiàn)也未能提供低于一毫秒的延遲。

我們將這些內(nèi)核用作底層硬件的測試平臺，并確定了面向模型暴露的最合適的接口。我們推測內(nèi)核與NIC或代理線程之間過于頻繁的傳輸和交互是性能瓶頸所在。此外，我們的實現(xiàn)除了可靠性之外，不依賴于硬件的任何其他保證，這表明我們可以通過減少同步原語（synchronization primitives）的開銷來實現(xiàn)加速。

基于這些觀察結(jié)果，我們設(shè)計了新型的基于EFA的內(nèi)核，該內(nèi)核暴露了相同的接口，但在底層針對設(shè)備內(nèi)核與主機代理之間的交互進行了優(yōu)化，從而實現(xiàn)峰值性能。

在EFA上的MoE all-to-all

新型內(nèi)核采用了CPU-GPU混合架構(gòu)，其中GPU內(nèi)核在設(shè)備側(cè)與模型進行交互，而運行在主機CPU上的代理線程則負責處理與NIC的交互。新型內(nèi)核重用了我們先前為KV Cache傳輸而構(gòu)建的TransferEngine。

MoE路由由調(diào)度內(nèi)核執(zhí)行，該內(nèi)核從模型接收Token及其對應(yīng)的專家路由信息，并將它們通過網(wǎng)絡(luò)發(fā)送至托管專家的計算秩。在分組GEMM內(nèi)核完成Token與專家權(quán)重相乘的運算后，合并內(nèi)核負責將Token傳輸回其源計算秩，計算加權(quán)平均值，然后將結(jié)果返回給模型。

調(diào)度和合并內(nèi)核均被拆分為發(fā)送方和接收方兩部分，以利于計算重疊和微批處理的實現(xiàn)。發(fā)送方將Token重新排序（洗牌）并放置到發(fā)送緩沖區(qū)中，從而能夠通過單個RDMA寫入操作發(fā)送給對等方。執(zhí)行發(fā)送方后，GPU可以執(zhí)行其他工作（例如共享專家乘法），而網(wǎng)絡(luò)上的傳輸在后臺懸掛進行。接收方內(nèi)核將保持阻塞狀態(tài)，直至所有傳輸接收操作完成。在后臺，主機側(cè)工作線程負責處理數(shù)據(jù)傳輸：當發(fā)送緩沖區(qū)填充完成后，由GPU發(fā)出通知，隨后調(diào)度RDMA寫入操作。一旦NIC完成信號通知，它將解除接收方的阻塞狀態(tài)，后者將Token返回給模型。

內(nèi)核與主機系統(tǒng)緊密耦合，并通過統(tǒng)一內(nèi)存和GDRCopy機制進行通信。CUDA統(tǒng)一內(nèi)存機制使得設(shè)備內(nèi)存或主機內(nèi)存能夠被映射到兩者（GPU和CPU）的地址空間，并由PCIe透明地處理通信過程。

雖然統(tǒng)一內(nèi)存適用于批量傳輸，但低延遲的輪詢操作是通過GDRCopy完成的。GDRCopy利用GPUDirect RDMA實現(xiàn)從GPU內(nèi)存的微秒級延遲讀寫操作。

除了RDMA傳輸之外，內(nèi)核在節(jié)點內(nèi)部還利用NVLink進行Token交換。這可以卸載相當比例的網(wǎng)絡(luò)流量，例如，對于EP32配置可卸載高達四分之一，對于EP64配置可卸載高達八分之一，最終實現(xiàn)整體延遲的降低。

發(fā)送和接收緩沖區(qū)

調(diào)度內(nèi)核的發(fā)送緩沖區(qū)設(shè)計對于實現(xiàn)涉及主機代理的可接受延遲至關(guān)重要。假設(shè)有N個秩，每個秩調(diào)度T個Token，且每個Token路由至E個專家中的R個，在最壞情況下，如果所有Token都路由到同一個秩，該秩可能接收高達N * T * max(R, E / N)個Token。此外，只有當發(fā)送方能夠連續(xù)布局其寫入數(shù)據(jù)時，才能達到此最小界限，因為私有接收緩沖區(qū)會消耗過多的內(nèi)存資源。為了使發(fā)送方能夠連續(xù)且無沖突地布局寫入數(shù)據(jù)，必須將完整的路由信息分發(fā)至每個計算秩。因此，我們的調(diào)度內(nèi)核首先交換每個專家的Token計數(shù)，隨后每個秩便能確定其寫入位置以及從其他秩接收Token的偏移量。

簡單地交換路由信息會帶來不必要的高延遲，因為每個秩必須等待寫入到達后才能開始調(diào)度自身的寫入操作。相反，我們在每個接收方秩上預留了少量私有的“每發(fā)送方”空間，并將一部分Token與路由信息的寫入操作一同調(diào)度。這確保了在調(diào)度過程的大部分時間內(nèi)都能夠?qū)崿F(xiàn)全帶寬利用。在交換路由后，剩余的Token則通過針對每個遠程對等方的單個寫入操作進行傳輸。路由信息交換、固定大小緩沖區(qū)以及填充這些緩沖區(qū)的傳輸過程，均在下圖中有所說明。

合并內(nèi)核在本質(zhì)上更為簡單，因為路由信息在調(diào)度階段已準備就緒。它們可以在接收到每個對等方的單個寫入操作后復制Token，然后從接收緩沖區(qū)讀取數(shù)據(jù)，以計算Token的加權(quán)平均值并寫入輸出張量。

對于NVLink，節(jié)點內(nèi)部的發(fā)送和接收緩沖區(qū)被映射至對等方，從而使它們能夠直接從相鄰的計算秩推送或拉取Token。

調(diào)度和合并

下圖詳細說明了GPU、CPU和NIC之間的時序關(guān)系和交互過程，展示了交織模型內(nèi)核的調(diào)度與合并迭代過程。

整個過程從調(diào)度發(fā)送階段開始，內(nèi)核在單個塊的共享內(nèi)存中，通過原子累加操作聚合路由信息，并計算每個專家的Token計數(shù)。一旦Token計數(shù)準備就緒，它們將被復制到主機內(nèi)存，并立即通知代理開始將路由信息調(diào)度到所有其他對等計算秩。同時，調(diào)度器繼續(xù)計算Token計數(shù)的累積和，以確定將Token打包到連續(xù)的“每對等”發(fā)送緩沖區(qū)所需的偏移量。一旦偏移量確定，所有將通過EFA發(fā)送的Token即被打包至發(fā)送緩沖區(qū)。隨后通知代理將寫入操作發(fā)布到節(jié)點間對等方的發(fā)送緩沖區(qū)。在節(jié)點內(nèi)部，內(nèi)核還立即通過NVLink將Token推送到同一節(jié)點內(nèi)的私有緩沖區(qū)。

一旦任一計算秩從所有對等方接收到路由信息，它將進行集中化處理，并計算識別調(diào)度和合并Token所需的各種偏移量。由于此時數(shù)據(jù)傳輸已處于懸掛（pending）狀態(tài)，因此該計算對延遲而言并非關(guān)鍵路徑。隨后，一旦所有偏移量都已知，將發(fā)布超過私有緩沖區(qū)大小的剩余Token的寫入操作，調(diào)度發(fā)送階段即告完成。

在接收階段，內(nèi)核首先通過NVLink從同一節(jié)點內(nèi)部拉取超出私有緩沖區(qū)容量的Token。隨后，它會保持阻塞狀態(tài)，直至主機代理發(fā)出所有傳輸完成的信號。一旦接收到完成信號，Token將從接收緩沖區(qū)重新排序（洗牌）并轉(zhuǎn)移到傳遞給分組GEMM的輸出張量。由于緩沖區(qū)在調(diào)度和合并之間重用，NVLink和RDMA屏障機制確保接收緩沖區(qū)已被完全讀取，隨后才允許下一個內(nèi)核覆蓋其內(nèi)容。

合并內(nèi)核遵循大致相似的執(zhí)行模式，包括重新排序Token、通知代理并等待傳輸完成。然而，由于用于發(fā)布其寫入操作的元數(shù)據(jù)已準備就緒，且所有遠程偏移量都已知，因此所有節(jié)點內(nèi)部傳輸?shù)腡oken都通過NVLink被推送到接收方，而節(jié)點間Token則通過單個寫入操作完成傳輸。在返回結(jié)果之前，內(nèi)核將從接收緩沖區(qū)累加Token，并將其寫入最終的輸出張量。

用于MoE路由的TransferEngine

為了對我們的實現(xiàn)進行原型設(shè)計，我們最初重用了為預填充和解碼階段分離而構(gòu)建的TransferEngine來發(fā)布和跟蹤RDMA寫入。然而，與分離解碼中每個節(jié)點向同一對等方發(fā)布大量寫入操作不同，MoE調(diào)度需要在一次操作中向所有對等方發(fā)布小規(guī)模傳輸。因此，在未經(jīng)優(yōu)化的“開箱即用”狀態(tài)下，其性能并非最優(yōu)，我們的實現(xiàn)落后于ConnectX-7上DeepEP約20微秒（us）。因此，我們將TransferEngine專門用于支持scatter和barrier這兩種操作，以優(yōu)化與大量對等方的交互性能。

scatter和barrier操作均暴露了可供預注冊的對等方組，從而預填充底層傳輸實現(xiàn)所需的數(shù)據(jù)結(jié)構(gòu)（WR模板）。Scatter操作將同一源緩沖區(qū)的不同數(shù)據(jù)切片復制到所有成員的不同偏移量處。Barrier操作則通過immediate機制向所有對等方發(fā)送信號。對這些操作進行批量入隊和處理，節(jié)省了關(guān)鍵路徑上的寶貴微秒時間。在EFA上，其中兩個200Gbps NIC聚合可提供400Gbps的帶寬，我們將對等方組分片到兩個NIC上進行處理，而非對每次傳輸?shù)淖止?jié)進行分片。

雖然最初我們僅使用libfabric在EFA上開發(fā)TransferEngine，但在增加了對使用libibverbs的ConnectX-7適配器的支持后，MoE內(nèi)核無需修改任何代碼即可在ConnectX-7上運行。與基于SRD的EFA相比，ConnectX-7需要額外的連接設(shè)置和對等方管理工作。我們利用Unreliable Datagram（UD）隊列對來引導建立Reliable Connection（RC）。我們?yōu)槊總€遠程對等方創(chuàng)建兩個隊列對，一個用于雙向SEND/RECV，一個用于單向WRITE_IMM，這是因為RECV和WRITE_IMM會按順序消耗RECV操作，且這兩種操作需要不同的緩沖區(qū)大小。此外，我們放寬了ConnectX-7與GPU內(nèi)存之間的PCIe事務(wù)排序限制。與EFA類似，我們實現(xiàn)了WR模板優(yōu)化。此外，當向同一對等方發(fā)送多個小消息時，我們采用了WR鏈機制來提高消息傳輸速率。

由于GPU側(cè)的工作在這兩種適配器上是相同的，我們將底層傳輸?shù)膶崿F(xiàn)推向極限，從而超越了DeepEP的性能，這凸顯了EFA和ConnectX-7之間在MoE路由方面的性能差距是由底層硬件能力所決定的。

評估

調(diào)度與合并延遲

我們在配備ConnectX-7和EFA適配器的H200系統(tǒng)上評估了在DeepSeek-V3和Kimi-K2標準配置下的調(diào)度與合并延遲，其中隱藏維度為7168，采用塊縮放的fp8調(diào)度和bf16合并。我們測試了調(diào)度批大小為128、合并批大小為4096的情況。在ConnectX-7上，我們與DeepEP和我們之前的基于NVSHMEM的pplx-kernels進行了比較，測試場景包括使用GPUDirect Async（IBGDA）和主機代理（IBRC）。我們在EP16、EP32和EP64上實現(xiàn)了459微秒（us）、582微秒（us）和692微秒（us）的合并延遲。我們的性能超越了依賴通用代理的其他基于EFA的內(nèi)核，如UCCL-EP，后者在相同配置下實現(xiàn)了519us、966us和1159us。

在解碼階段，盡管我們的內(nèi)核比DeepEP慢幾微秒，但由于我們的合并內(nèi)核顯著更快，我們實現(xiàn)了整體更低的延遲表現(xiàn)。盡管我們使用了主機代理，但得益于我們采用的批量傳輸機制，我們的性能仍超越了所有基于IBGDA的無代理實現(xiàn)。這同時也證明了代理實現(xiàn)的重要性，因為我們高度優(yōu)化的專用代理比通用的NVSHMEM實現(xiàn)快了一個數(shù)量級。盡管EFA在傳輸256KB數(shù)據(jù)包時（該大小接近MoE路由交換的典型數(shù)據(jù)包規(guī)模）比ConnectX-7慢兩倍，但兩種適配器之間的整體性能差距并不顯著。

盡管我們?yōu)榻獯a優(yōu)化的內(nèi)核無需額外調(diào)整即可擴展支持預填充批大小，但其性能仍落后于DeepEP。這主要是因為在合并階段，我們在接收方側(cè)僅進行Token的累加，而DeepEP則在發(fā)送方進行累加，以減少傳輸?shù)臄?shù)據(jù)總量。然而，這種優(yōu)化可能會對模型的準確性造成影響。此外，由于內(nèi)核以一個寫入傳輸數(shù)據(jù)，我們?yōu)榘l(fā)送和接收緩沖區(qū)占用了更多的內(nèi)存。

Kimi-K2 / DeepSeek-V3 吞吐量

為驗證我們內(nèi)核的實際可行性，我們在配備EFA和H200 GPU的多個p5en實例上，對我們內(nèi)部推理引擎服務(wù)DeepSeek-V3（671B參數(shù)）和Kimi-K2（1T參數(shù)）的端到端性能進行了基準測試。我們采用了草稿驗證模式運行模型，并使用單個MTP層，報告在假設(shè)80%接受率下的延遲數(shù)據(jù)。

在DeepSeek-V3上，我們與運行高效NVLink專用調(diào)度與合并內(nèi)核的EP=8節(jié)點內(nèi)基線比較。節(jié)點間部署在整體上匹配甚至超越了單節(jié)點部署的性能，特別是在中等批大小上，這證明了跨節(jié)點擴展確實能夠帶來整體吞吐量的顯著提升。

在Kimi-K2上，我們的內(nèi)核實現(xiàn)了對該模型的服務(wù)支持。由于其龐大的模型規(guī)模，該模型無法僅使用H200節(jié)點上的數(shù)據(jù)并行（DP）技術(shù)在單個節(jié)點內(nèi)完整容納，因此需要通過跨節(jié)點部署來進行模型服務(wù)。由于模型具有較少的注意力頭，我們實現(xiàn)了優(yōu)于DeepSeek-V3的延遲表現(xiàn)，并能夠在EFA上以可接受的延遲提供模型服務(wù)。

我們還對微批處理進行了考量，盡管它僅在批大小非常高或使用多個草稿Token時才能帶來延遲改進。為了從將分組GEMM任務(wù)拆分為兩個子任務(wù)中獲益，Token的批處理大小必須足夠大（密集）。大部分時間仍消耗在MoE調(diào)度與合并操作上，這表明對內(nèi)核的任何進一步優(yōu)化都將相應(yīng)地降低延遲，并有利于微批處理的推廣應(yīng)用。

未來工作

我們正在與AWS工程師密切合作，以持續(xù)改進EFA上的性能表現(xiàn)。在我們后續(xù)的工作中，我們將密切關(guān)注libfabric的更新動態(tài)，從而減少數(shù)據(jù)平面的開銷。此外，我們將試驗采用efa-direct來進一步減少用戶空間開銷，并實現(xiàn)與硬件的直接接口。

參考文獻

• DeepSeek R1 Technical Report, https://arxiv.org/abs/2501.12948
• Kimi K2 Technical Report, https://arxiv.org/abs/2507.20534
• DeepEP, https://github.com/deepseek-ai/DeepEP
• UCCL-EP, https://uccl-project.github.io/posts/uccl-ep/
• Improving Network Performance of HPC Systems Using NVIDIA Magnum IO NVSHMEM and GPUDirect Async, https://developer.nvidia.com/blog/improving-network-performance-of-hpc-systems-using-nvidia-magnum-io-nvshmem-and-gpudirect-async/

本文轉(zhuǎn)載自??Andy730??，作者：常華