主機與網路

RoCEv2 還是 InfiniBand？AI 叢集 400/800G 網路怎麼選，參數基線怎麼定？

RoCEv2 還是 InfiniBand？AI 叢集 400/800G 網路怎麼選，參數基線怎麼定？關於AI 訓練是典型的東西向（east-west）洪流，All-Reduce／All-to-All 容易在高密度叢集中互相「打架」。RoCEv2（乙太）與 InfiniBand（IB）各有勝場，關鍵在Lossless 條件、擁塞控制、可觀測性能否到位。本文以「拓樸選型 → 參數基線 → 驗收方法 → 常見地雷」為主線，給出可落地的工程順序與驗收清單。

為什麼是這一題？因為當你把單櫃 40–100kW 的 AI 算力疊到數百、數千張 GPU，東西向流量（特別是 All-Reduce）會把網路「榨乾」。要跑得穩，不是只有升級到 400/800G 介面，而是整套「拓樸 × 參數 × 驗收 × 監控」都到位。

1. 先釐清問題（工作負載與瓶頸）

  • 工作負載：NCCL All-Reduce／Mixture-of-Experts（MoE）會產生大量同步流，對延遲抖動與丟包極敏感。
  • 目標：在無丟包或可控丟包下，壅塞快速收斂，維持高 GPU 利用率與穩定的 samples/s。
  • 錯誤直覺：只換 800G 介面，不調拓樸、PFC/ECN/DCQCN 與 Buffer Profile，結果 p99.9 RTT 飆高、PFC storm 亂竄、GPU 降速。

2. 拓樸與速率：先把路修好，再談車多快

  • 拓樸建議：
    • Fat-Tree／Rail-optimized：多埠 GPU 節點（如每節點 2–4 埠）將不同 NIC 綁不同Leaf交換器，降低單點壅塞與跳數。
    • Over-subscription：訓練區域建議 1:1 或接近 1:1，必要時把儲存/備份流量與訓練流量分層（VRF／實體平面）。
  • 速率與光纖：
    • 400/800G（OSFP／QSFP-DD），依距離選 DR4/DR8／2×FR4 等型號；短距離可考慮 MMF AOC，機櫃間骨幹建議 SMF。
    • 混合速率（800↔400G）要注意 FEC 與分裂（breakout）規劃，避免介面不對稱造成誤碼或退降。
  • Leaf/Spine比例：由端口密度 × GPU 佈線回推，先定「每節點上行埠數 × 葉交換器數量」，再估脊層背板需求。

3. 選型框架：RoCEv2 還是 InfiniBand？

  • RoCEv2（以太）
    • 優點：延用既有乙太域與運維能力、與雲／儲存／安全設備整合容易、採購與備件彈性高。
    • 關鍵：端到端 Lossless 條件（PFC/ECN/DCQCN/Buffer/Scheduler）要「一致且正確」。
    • 適配：≤ ~2k GPU 且乙太運維成熟的團隊；或需與既有乙太服務大規模整合。
  • InfiniBand
    • 優點：低延遲、Lossless 先天、工具鍊成熟（verbs、perf、UFM 等）、Adaptive Routing。
    • 代價：採購與維運門檻較高、與乙太域整合需多一層規劃。
    • 適配：極致延遲敏感、既有 HPC/IB 經驗的團隊，或超大規模平面。
  • 混合策略：以 RoCE 為主、關鍵小區 IB，或按工作負載拆平面（training plane vs. storage/ingress）。

快速判斷：你的團隊若已有成熟的 DCN（資料中心網路）乙太運維能力與自動化，且規模 <~2k GPU，RoCEv2 先行；對延遲極端敏感、已有 IB 經驗與工具，IB 可一線到位。

4. RoCEv2「三把鑰匙」：沒有之一

  1. PFC（Priority Flow Control）
    • 僅對訓練流量 CoS 開啟（例如單一優先權），禁用全域 Pause。
    • 端到端一致：Host NIC ↔ ToR ↔ Spine ↔ ToR ↔ Host NIC；PFC watchdog 務必開啟以抑制 storm。
  2. ECN + DCQCN（壅塞回饋）
    • ECN 標記門檻依裝置 Buffer Profile 設於安全水位，確保在溢位前觸發回饋。
    • DCQCN 參數採廠商建議基線起步，再以疊代實測收斂（觀察 RTT p99/p99.9、重傳率、ECN 標記率）。
  3. Buffer 與排程（Scheduler）
    • 設定隊列隔離，把訓練流量與背景服務分離；排程採 Strict + WRR 混合，避免儲存/備份流量影響訓練。
    • 針對 PFC 優先權配置headroom，減輕微爆（microburst）時的瞬時壓力。

RoCEv2 範例基線（需依品牌/韌體調整）

  • MTU：9000（叢集一致）；RDMA 介面關閉 LRO/GRO。
  • PFC：僅啟用訓練 CoS；全域 Pause 關閉；PFC watchdog 開啟。
  • ECN：在訓練 CoS 上啟用；門檻採廠商建議的中位值起跑，依實測微調。
  • DCQCN：以 NIC/交換器相容版本的預設建議檔落地，觀測後再細修。
  • Scheduler：訓練隊列 Strict，背景服務 WRR；Buffer Profile 鎖版且隨變更受控。

5. InfiniBand 的典型優勢與考量

  • 低延遲／Lossless 先天，對 All-Reduce 抖動非常友善；Adaptive Routing 對不均勻流量有幫助。
  • 原生工具鍊成熟（perf、UFM、分區 PKey、SL），端到端一致性高。
  • 考量：採購與維運技能門檻、跨域（以太）整合；升級與異廠互通需專案級驗證。

6. 可觀測性與驗收（能量、延遲、無損三層聯動）

**你無法改善你看不到的東西。**建議把下列指標納入 DCIM/NOC 或 NetOps 看板：

  • 網路端：丟包/重傳、p99/p99.9 RTT、ECN 標記率、PFC pause 次數與時長、微爆偵測、Queue 深度。
  • 主機/NIC：RDMA 連線錯誤、重傳、DCQCN 事件、NIC 韌體/驅動版本一致性。
  • 訓練層：NCCL All-Reduce 佔比、step time、samples/s、GPU 利用率。

驗收手法（建議完整演練）：

  1. 階梯負載：25%→50%→75%→100%，觀察 RTT 抖動與 ECN/PFC 事件曲線。
  2. No-drop 測試：在訓練 CoS 以線速壓測，確認零丟包或丟包於可控範圍。
  3. 失效演練：鏈路 flap、Leaf/Spine 切換、單點維護；觀察收斂時間、GPU 下降幅度。
  4. 灰度升級：韌體/驅動 鎖版；小批量釋出→觀測→擴大；出問題可快速回滾。

7. 常見地雷（實務歸納）

  • 只開 PFC、沒開 watchdog → 一次微爆引發長時間 PFC storm。
  • ECN 門檻與 Buffer Profile 不匹配 → 標記太晚，先丟包再回饋。
  • DCBX 自動協商造成端到端不一致 → 強制策略、落盤與稽核缺一不可。
  • RDMA 介面沒關 LRO/GRO、MTU 不一致 → 神祕抖動與重傳。
  • 同平面混跑備份/掃毒/大檔案傳輸 → 訓練隊列被背景流量「擠掉」。
  • 800/400G 混接沒檢核 FEC/分裂規格 → 隱性錯誤與降速。
  • 只看網路指標、不看 NCCL log 與 samples/s → 以為通了，其實效能沒上來。

8. Cloudmax 的做法（從設計到營運）

  • AI-Net 健檢：拓樸/佈線/速率、PFC/ECN/DCQCN、Buffer/Scheduler、韌體/驅動盤點。
  • 參數基線模板：依 RoCEv2 常見品牌提供可直接套用的起跑檔（PFC/ECN/DCQCN/MTU/Queue/Headroom），並標註可調參。
  • 端到端 Lossless 調校：Host ↔ ToR ↔ Spine 一致化；測試-觀測-疊代至目標 p99/p99.9。
  • 叢集可觀測性看板：整合網路 Telemetry（INT/IFA/sFlow/gNMI）與 NCCL/DCGM 指標。
  • 變更管理：韌體/驅動鎖版、灰度升級、回滾腳本；維持穩定輸出。

參數上限與行為會依裝置品牌/韌體而異，Cloudmax 以現場封包統計與 NCCL 實測曲線做最後校核。

FAQ 延伸問答

Q1：規模多大建議用 IB？
A：沒有硬性門檻。經驗法則是極致延遲敏感、需要最均一的 Lossless、或團隊原生 HPC/IB 背景者，IB 成本效益更好；否則 RoCEv2 憑乙太運維優勢，<~2k GPU 常能達標。

Q2：RoCEv2 一定要 Lossless 嗎？
A：All-Reduce 對丟包超敏感。RoCEv2 務必建立近 Lossless 條件（正確 PFC＋ECN＋DCQCN＋Buffer/Scheduler），否則 p99.9 抖動與重傳會拖垮 GPU。

Q3：MTU 要不要 9000？
A：建議叢集一致 MTU 9000，降低封包數與中斷成本；注意端到端一致，並於 RDMA 介面關 LRO/GRO。

Q4：NCCL 調校要看什麼？
A：觀察 All-Reduce 佔比、step time、samples/s 與 NCCL DEBUG 訊息；多埠節點確認 rail 綁定與路徑對稱，避免單軌飽和。

Q5：PFC storm 怎麼避？
A：僅對訓練 CoS 啟用 PFC、開 watchdog、預留 headroom、Queue 隔離，並在看板上長期監控 pause 次數與時長。

Q6：混用 800G 與 400G 有什麼要注意？
A：檢核 FEC 模式、breakout 規格、光模/線材相容；跨速率處理時要驗證誤碼率/降速行為，必要時把關鍵層維持同速率域。

Q7：Cloudmax 的 RoCEv2 基線包含什麼？
A：MTU 9000、單一訓練 CoS 的 PFC（watchdog on）、該 CoS 的 ECN＋建議 DCQCN 檔、Queue/Headroom Profile、Scheduler（Strict+WRR）、端到端一致性檢核與灰度升級流程。

總結：
RoCEv2 ≠ 會通就好，IB ≠ 自動最強。AI 叢集的網路關鍵在「拓樸正確、參數一致、驗收嚴謹、可觀測性常態化」。把這四件事一次做對，才是讓 All-Reduce 不打架、GPU 不空轉的根本之道。每個專案會因為預算、規模、條件要求、關鍵因素的值，給出不同的意見及見解。Cloudmax 以基線模板＋端到端調校＋灰度變更，協助團隊在 400/800G 時代把吞吐與穩定度拉滿。

歡迎轉載！請見：轉載原則。

Image by AI-generated via ChatGPT