Meta 如何用拓撲感知平行化與混合精度訓練,把廣告基礎模型 GEM 的訓練效率翻倍
Engineering at Meta · 2026-08-03
Meta 在 2026 年 8 月 3 日發表文章,說明旗下廣告推薦基礎模型 GEM(Generative Ads Recommendation Model)在過去一年間如何把端到端訓練效率提升一倍。這個系統同時擁有數兆個稀疏 embedding 參數與數十億個稠密參數,是目前業界少數用 LLM 規模訓練技術打造的推薦系統。文章聚焦在訓練基礎設施層面的改動,而非模型架構本身的演進。
原本的問題
推薦系統的訓練負載跟語言模型有本質差異。輸入序列長度參差不齊(jagged)、attention pattern 不對稱、且大量運算是 memory-bound 而非 compute-bound,這些特性讓原本針對 LLM 訓練優化的標準 GPU 基礎設施效率低落。當 GEM 把訓練規模推向 LLM 等級,團隊發現既有的 kernel 與平行化策略沒辦法有效利用硬體算力。
這個落差直接反映在 Model FLOPs Utilization(MFU)上——如果不改動基礎設施,單純疊加算力只會讓 MFU 持續探底,訓練成本隨參數量增加而不成比例地墊高。
採用的方法
Meta 從運算效率與擴展效率兩個方向同時下手。在運算層面,團隊寫了三種自訂 kernel:Jagged Flash Attention(JFA)、Generalized Dot-Product Attention(GDPA)與 BlockAttention,專門處理推薦系統特有的參差序列與非對稱 attention。其中 JFA v4 比前一版本再拿下 40%–140% 的 TFLOPS 提升。訓練精度上則導入 MXFP8 做 attention 與 MLP 的混合超低精度訓練。
在擴展層面,團隊設計了「拓撲感知的 5D 平行化」:稠密參數用 2D FSDP 疊加 Expert Parallelism,稀疏參數則用 Fully Sharded 2D Model Parallelism 分片。通訊層改用 NCCLX 做 SM-free 通訊,帶來約 5% 的端到端 QPS 提升。此外還有:
- 自動化 activation checkpointing 並搭配量化,降低顯存壓力
- Base Batch Shuffling 做負載平衡,帶來 4% 的效率提升
- 硬體層每台主機 8 張 GPU 以 NVLink 互連,再疊上三層網路架構,配合數千張最新一代 GPU 做訓練
實際效果
疊加以上改動後,Meta 表示 GEM 訓練在 12 個月內把訓練 FLOPs 規模擴大 4 倍,同時把 MFU 維持在 20%–25% 區間,整體端到端訓練效率翻倍。這代表同樣的硬體預算下,團隊能訓練規模大 4 倍的模型,而不是效率隨規模擴大而衰退。文章沒有揭露具體的美元成本或 GPU-hour 數字,但明確指出這些改動是分開疊加、各自貢獻效率增量的獨立工程決策。
Cloudflare 用 FP8 KV Cache 與 INT4 權重壓縮,把 Kimi 與 GLM 的推論成本壓下來
Cloudflare Blog · 2026-08-03
Cloudflare 在自家資料中心的 GPU 上服務開源權重模型 Kimi K2.6 與 GLM 5.2,文章說的「更小、更快、更安全」不是行銷詞,而是具體的量化與服務架構決策。核心手法是把 KV cache 與模型權重分別用不同精度壓縮,再依 prefill、decode 兩階段各自的瓶頸配置不同精度。推論框架用的是開源的 SGLang。
原本的問題
大型開源模型正式服務時,decode 階段與 prefill 階段的瓶頸不一樣:decode 受限於 KV cache 佔用的顯存,直接壓縮可服務的上下文長度;prefill 則受限於權重本身佔用的顯存與頻寬。用單一精度(例如全程 BF16)服務,等於兩個階段都吃虧——上下文變短、單卡能塞的並發請求數變少、每張 GPU 的成本也墊高。
採用的方法
針對 KV cache,團隊把精度從 16-bit 的 BF16 降到 8-bit 浮點的 FP8(e4m3)。在 Kimi K2.6 上,這讓可定址的上下文長度從約 686,000 tokens 提升到約 137 萬 tokens。針對權重,GLM 5.2 則從 8-bit 浮點進一步壓到 4-bit 整數 INT4,checkpoint 從 705 GB 降到 421 GB,每張 GPU 的記憶體佔用從約 88 GB 降到 52 GB。
因為 INT4 與 FP8 各自在不同階段勝出,團隊採用拆分的 prefill/decode 資源池:decode 用 INT4,prefill 用 FP8,而不是整個 pipeline 套用單一精度。安全性上,系統在每次 decode 讀取 KV cache 前,會先檢查分頁對應(page mapping)是否有效,避免因分頁錯誤讀到其他 session 的殘留內容。
實際效果
下表整理文章提到的量測數字:
| 指標 | 改動前 | 改動後 |
|---|---|---|
| Kimi K2.6 可定址上下文 | BF16：約 686,000 tokens | FP8：約 137 萬 tokens |
| 64 併發時解碼吞吐 | BF16 峰值 | FP8：2,192 tokens/秒，高約 41% |
| GLM 5.2 checkpoint 大小 | FP8：705 GB | INT4：421 GB，減少約 40% |
| 單卡記憶體佔用 | 約 88 GB | 約 52 GB |
| 單一併發解碼速度 | FP8 基準 | INT4：+55% |
| KV cache 分頁檢查開銷(併發數 1) | 未檢查 | 吞吐 −0.53%、p95 延遲 +0.42% |
這些數字說明精度選擇是依實際瓶頸分開決策,而非整體套用同一種壓縮,分頁檢查的安全機制則以不到 1% 的效能代價換取 KV cache 讀取的正確性保證。
Google 揭露即時 AI Agent 的 Session-Aware 負載平衡:別再只看 QPS
Google Developers Blog · 2026-08-03
Google Developers Blog 在 2026 年 8 月 3 日的文章中,拆解了即時 AI agent(例如語音助理)在負載平衡上的一個根本盲點:用每秒請求數(QPS)或單純的 CPU 使用率判斷伺服器忙不忙,對長連線的 session 完全失準。文章沒有綁定特定的 Google Cloud 產品,而是提出一套可套用在 gRPC 或 WebSocket 雙向串流服務上的通用模式。
原本的問題
文章用一個對比例子說明 QPS 的失真:任務 A 處理 100 個各花 50 毫秒的短請求,任務 B 只接了 5 個請求,但每個都是長達 20 分鐘的 session。用 QPS 衡量,任務 A 看起來忙碌 20 倍,但任務 B 實際佔用的資源承諾遠高於 A。CPU 使用率同樣會騙人——一個掛著 20 個靜音語音 session 的 runtime,在使用者都不說話時 CPU 看起來很閒,一旦所有人同時開口,就會出現瞬間的 CPU 尖峰,負載平衡器在尖峰發生前完全看不出風險。
採用的方法
解法是在應用層直接追蹤活躍 session 數,而不是依賴基礎設施層的請求計數。文章給的 Kotlin 範例是在 session 開始時遞增計數器、結束時(含逾時)在 finally block 遞減:
suspend fun handleAudioSession(audioStream: Flow<AudioFrame>) {
activeSessions.incrementAndGet()
try {
withTimeout(20.minutes) {
audioStream.collect { frame ->
processAndRespond(frame)
}
}
} finally {
activeSessions.decrementAndGet()
}
}再把這個活躍 session 數,跟另外三個訊號合併成一個「有效容量」估算模型:
- 過去 10 秒平滑後的 CPU 使用率
- 目前活躍 session 數
- 動態計算出的「每 session 成本」
- 一個保守安全係數(文章舉例為 2.0),避免容量估算過於樂觀
實際效果
把這四個訊號合成單一容量指標後,負載平衡決策就能正確辨識出任務 B 這種「低 QPS、高負載」的伺服器,也能在 CPU 尖峰真正發生前,提前把新的語音 session 導向還有餘裕的節點。文章沒有提供導入前後的具體效能數字,呈現的是判斷負載的訊號模型,而非某個現成的 Google Cloud 負載平衡產品。這套模式的適用範圍鎖定在 gRPC 與 WebSocket 這類雙向串流協定,而非傳統的短連線 HTTP 請求。