Meta 推出 MetaRoCE：以「網卡看得懂意圖」取代封包順序保證的新一代 RDMA 傳輸
engineering.fb.com · 2026-08-24
Meta 於 2026 年 8 月 24 日在工程部落格發表 MetaRoCE，一套專為橫跨數十萬顆 GPU 的乙太網路叢集設計的新 RDMA 傳輸協定。這套協定的目標是取代現行 RoCEv2 在 AI 訓練與推論流量下暴露的延遲與壅塞問題。Meta 同時宣布將透過 Open Compute Project（OCP）釋出完整規格與參考實作。
捨棄「循序送達」這個包袱
傳統 RDMA 傳輸把封包順序視為必要條件，接收端得靠重排緩衝區（reorder buffer）把亂序抵達的封包排好才能寫入記憶體，一旦某個封包卡住就會造成隊頭阻塞（head-of-line blocking）。MetaRoCE 的核心設計是讓亂序抵達成為常態：每個封包自帶目的位址資訊，網卡收到就能直接寫入記憶體，完全不需要重排。Meta 把這個原則總結為「fabric 看到的是封包，網卡看到的是意圖」。
逐封包灑向多條路徑
MetaRoCE 把同一筆訊息拆成封包後，逐封包（packet-by-packet）灑向多條路徑，每條路徑各自帶不同的 UDP 來源埠號以取得 ECMP 的路徑多樣性。網卡會動態把流量從壅塞或故障的路徑移開，不需要應用層介入。過去一組節點對節點連線得靠開幾十條 QP（queue pair）分攤流量，MetaRoCE 改成單一 QP 內同時維護多條獨立排序的訊息串流，並統一做壅塞控制。
用選擇性 ACK 取代 PFC
MetaRoCE 可以直接跑在有損（lossy）乙太網路上，不需要 PFC（Priority Flow Control）或 pause frame 這類反而會擴散壅塞的機制。每條路徑各自維護一個 256-bit 的選擇性 ACK 點陣圖，用來分辨封包究竟是遺失還是只是抵達順序被打亂；一旦偵測到缺口，就立刻在原本遺失的那條路徑上重傳缺的那個封包。壅塞控制結合傳送端依 ECN 標記做的 AIMD（加法增、乘法減）與接收端算出的公平分享速率提示，視窗以「每路徑、每連線」為單位維護，讓 ECN 標記只會削減單一路徑而不是整條連線。文章指出，這樣的設計能讓 incast 在一到兩個 RTT 內就收斂。
64 節點叢集實測與跨拓樸相容性
Meta 在一個 64 節點的 AMD GPU 叢集上跑 RCCL 集合通訊測試，MetaRoCE 在各種封包遺失率下的吞吐量與流完成時間都優於 RoCEv2，在 1% 封包遺失率時仍能維持約 86% 的吞吐量，即使遺失率拉高到 10% 也只是效能逐步下滑而非崩潰。在 4-plane 與 8-plane 的多平面拓樸驗證中，吞吐量隨平面數量線性成長；即使模擬整個平面故障，流量也能自動重新分配而不需應用層介入。這套協定只要求交換器提供 ECN 標記與 ECMP，兩者都是現有商用交換器已具備的能力，因此能同時相容 fat-tree、多平面、深緩衝與淺緩衝等不同結構的網路。
釋出時程與後續挑戰
Meta 目前已與 AMD Pensando 的可程式化網卡合作實作，並規劃在 2026 年 10 月的 OCP Global Summit 上，透過 Open Compute Project 釋出：
- 完整的協定規格文件
- 可跑在一般 Linux、標準 UDP 之上的參考實作
libsoftmetaroce - 正式的合規測試套件
- 針對 DPDK 最佳化的軟體實作
文章也點出三個尚未解決的方向：機櫃內 scale-up 場景要進一步消除重排緩衝與 PFC 帶來的奈秒級延遲；跨資料中心的 scale-across 場景要應付毫秒級 RTT；以及儲存與 KV-cache 場景中「一次讀取扇出給上千台伺服器」的 incast 問題。
MTIA 300 曝光：Meta 首款把網卡與通訊卸載引擎直接做進訓練晶片的設計
engineering.fb.com · 2026-08-24
Meta 工程團隊於 2026 年 8 月 24 日發表 MTIA 300，這是 Meta 第一款訓練用的自研晶片，把 RDMA 網卡與集合通訊卸載引擎直接整合進晶片內部。相關細節同時發表於 ISCA '26 論文〈MTIA 300: Meta's First Training Chip Featuring Built-in NICs and Collective Offloading Engines〉，以及 SC26 會議上介紹配套通訊函式庫 HCCL 的論文。文章作者為 Rajiv Krishnamurthy 與 Wes Bland。
把網卡做進晶片裡的架構
MTIA 300 的運算核心是一個 12×6 排列的運算單元（Processing Element）網格，搭配 216 GB 的 HBM3E 記憶體。晶片內建兩個網路晶粒（network chiplet），各自整合六個 800 Gbps 的自研 RDMA 網卡，總計提供 1.2 TB/s 的 I/O 頻寬且不吃 PCIe 頻寬額度。這些網卡可以依需求彈性切割，動態在 scale-up（機櫃內）與 scale-out（跨機櫃）流量之間調整配置，不需更動硬體。
訊息引擎：讓集合通訊不再搶 GPU 算力
晶片另外配置 16 個訊息引擎（Message Engine，簡稱 ME），每個 ME 內含一顆負責調度的 RISC-V 核心、網卡介面路由邏輯，以及一個能以每週期 128 bytes 速度做加總運算的近記憶體運算（Near-Memory Compute）區塊。16 個 ME 加總後的簡化運算吞吐量超過 2.8 TB/s，比晶片的 I/O 頻寬還高兩倍以上，代表通訊卸載不會反過來成為瓶頸。這些 ME 支援 AllReduce、AllGather、AllToAll、ReduceScatter 等主要集合通訊操作。
HCCL：編譯式通訊模型
MTIA 300 搭配的通訊函式庫 HCCL 採用「編譯式通訊」模型，把集合通訊操作編譯成子圖後直接派送給各個 ME 執行；主機端只需要把指令複製進 HBM，之後整個過程「host 完全不用介入」。HCCL 對接 PyTorch 的 torch.compile 以及 c10d／torchcomms 介面，在單一機櫃內可達到 940 GB/s 的頻寬。
生產環境數據對比
Meta 在一個 1500 億參數的推薦系統模型、40 顆加速器的生產環境中做了對比測試。下表整理了幾個關鍵數字：
| 項目 | 數值 |
|---|---|
| 運算網格 | 12×6 Processing Element |
| 記憶體 | 216 GB HBM3E |
| 晶片內建網卡 | 2 個網路晶粒 × 6 個 800 Gbps RDMA 網卡 |
| Scale-up 頻寬 | 最高 1 TB/s（12 個乙太網路網卡） |
| Scale-out 頻寬 | 200 GB/s |
| ME 簡化運算吞吐量 | >2.8 TB/s |
| 與運算並行時的效能損失 | <0.5% |
| 通訊總時間對比同等 GPU 叢集 | 快 3.9 倍 |
Meta 指出，GPU 叢集常見的做法是讓 NCCL 這類函式庫把集合通訊當成 GPU kernel 執行，會佔用原本要拿來做訓練運算的串流多處理器（SM），實測中造成超過 20% 的效能損失；MTIA 300 因為通訊完全卸載到獨立的 ME 上，同樣情境下的損失壓在 0.5% 以下，讓使用者可以放心拉大 local batch size 或改用精度更高的資料型別。
Cloudflare 把自家部落格搬上自研 CMS「EmDash」：用 k6 壓測與灰度切流上線
blog.cloudflare.com · 2026-08-24
Cloudflare 於 2026 年 8 月 24 日發表文章，說明工程團隊如何把自家工程部落格搬遷到內部開發的內容管理系統 EmDash 上。這次遷移由 Diogo Carneiro 與 Amy Dutton 主筆，完整記錄了壓力測試、灰度切流與前端改版的過程。EmDash 是一套設計給 Astro 搭配 Cloudflare 生態系使用的 CMS，專案原始碼公開在 GitHub。
原本的問題
Cloudflare 奉行「Customer Zero」原則，凡是自家產品都要先在內部場景驗證。既有 CMS 供應商在功能上碰到限制，團隊因此決定改用還在 1.0 之前開發階段的 EmDash，順便用部落格這個真實流量場景把平台的問題挖出來。部落格平時流量約每秒 75 次請求，尖峰可以衝到超過 5000 RPS，這代表新平台得先通過等量級的壓力測試才能上線。
採用的方法
EmDash 部署在 Cloudflare Workers 上，前面掛 Workers Cache，團隊形容這是第一個用這種方式上線的大型網站；物件快取建立在 Workers KV 之上，資料庫連線則透過 Hyperdrive 接到 PlanetScale。上線前用 k6 做了三組壓力測試：
- Ramp：緩步加壓到正常流量的 3 倍
- Breakpoint：從 0 RPS 漸進加壓到系統撐不住為止
- Burst：直接打進 7000 RPS 並持續一分鐘
三組測試的失敗門檻設定為 5xx 錯誤率低於 0.01%、P95 延遲低於 500ms、P99 延遲低於 1000ms。正式切流靠一個 proxy Worker 依版本 cookie 決定路由，流量先從 1% 開始，同一天內依序拉到 5%、15%，最後全量切到 100%；一旦偵測到 500 錯誤就自動退回舊版部落格，Worker 之間則用 service binding 溝通以壓低延遲。
實際效果
切換後量到的快取命中率是靜態檔案 99.5%、整體請求 70%。延遲曲線從原本會週期性飆高，變成平坦穩定，正式環境內測到尖峰 850 RPS 都沒有出現錯誤。文章提到今年的 Agents Week 活動期間，9 天內部落格衝出 300 萬次瀏覽，尖峰達到 450 RPS，同時還扛住了一波 28000 RPS 的 DDoS 攻擊而沒有受影響。
前端同步用 Kumo 設計系統改版，加入依系統偏好切換的深色模式，把訂閱信箱框從頁首移到文章結尾（因為讀者常把頁首那個輸入框誤認成搜尋欄），並新增頁內目錄與「Discuss Online」討論區塊。團隊也在 EmDash 上串了 MCP server，開放 search_posts、list_posts、get_post、list_tags 等工具給外部 agent 讀取部落格內容，程式碼在 cloudflare/mcp-server-cloudflare 倉庫。過程中也暴露了一些還沒解決的問題，包括媒體縮放、內容搜尋、SEO metadata 與 CSP 設定，其中排程發文的功能已在 EmDash 0.19.0 版本修復。
原始來源：Cloudflare Blog: Brought to you by EmDash、EmDash on GitHub