Perplexity.ai 研究指出，用 DeepSeek-V3/R1 利用 MoE 與多節點部署，實現低延遲高吞吐，應能成為未來 LLM 部署關鍵方案。
瀏覽數：
以下是這篇關於 DeepSeek-V3/R1 多節點部署與效能優化 的完整繁體中文整理，
DeepSeek-V3/R1 多節點部署完整解析：如何同時降低延遲與提升吞吐量？
▍📌 前言：MoE 模型讓效能不再取捨
在傳統系統中，延遲（latency）與吞吐量（throughput）常常是衝突目標，但 DeepSeek-V3/R1 採用 Mixture of Experts（MoE）模型設計，透過多節點部署，能在多數情境中同時獲得更高吞吐與更低延遲。
▍🏗️ 架構設計：單節點 vs 多節點部署
- 單節點部署（8x H200）：延遲較低但在高負載下表現會迅速下降。
- 多節點部署（8x H100 x N）：可用更多 GPU 分散專家（experts），維持高速並增加容納量。
- 採用 Data Parallel + Expert Parallel 混合架構，並透過 自研 Request Scheduler 控管請求與 KV cache 重用。
▍🔁 並行技術解析：TP、EP、DP 怎麼搭配？
- Tensor Parallelism（TP）：對 Attention 和 MLP 的線性映射做 shard。
- Expert Parallelism（EP）：MoE Layer 分派給各 GPU 不同的 experts 處理。
- Data Parallelism（DP）：每組 DP group 單獨執行 MLA（Multi-Latent Attention）計算。
- 三者可以自由組合，如 EP128 = DP32 × TP4。
▍📊 效能比較：單節點與多節點的輸出差異
- 在高輸出速率下，單節點部署吞吐量極低，因為 batch size 無法放大。
- 使用 EP128 的多節點部署，在相同輸出速度下可達 5 倍吞吐量提升。
- 單節點會隨 batch size 增加造成大量 experts 同時啟用，導致記憶體頻寬瓶頸。
▍🧩 溝通與計算重疊：用微批處理省下延遲
- 實作 Dispatch Overlap：在等待通信完成時提前處理 shared expert。
- 微批處理（Microbatch） 可讓不同的 mini-batch 在不互相依賴下交錯處理，達到最大化重疊與平均資源使用。
▍⏱️ 延遲細節解析與對比
- 微批處理相比於純粹 Dispatch Overlap，可降低最多 29% 延遲。
- 然而在 batch size < 32 時可能反而造成效能下降，顯示微批處理需視情境使用。
▍📈 Roofline 模型分析：GEMM / GroupGEMM 效能瓶頸
- GroupGEMM：隨著 token 數上升，算術密度提高，提升效能。
- GEMM（線性投影）：多數情況下受限於記憶體頻寬，仍有最佳化空間。
- 微批處理將 m 改為 m/2，導致矩陣乘法效率下降。
▍🧠 MTP 與推理效率的關係
- 使用 Multi-Token Prediction（一次預測多個 token）可提升矩陣運算效率，是推理加速的重要手段。
▍🧪 其他優化與實作細節
- FP8 量化：使用 block-based quantization，降低效能損失。
- FlashInfer / CUDA Graph：使用高效 CUDA 核心與圖形加速器減少 kernel 啟動延遲。
- 自研 AllToAll Kernel：擺脫傳統 allreduce 與 padding 需求，實作更靈活。
▍🔭 未來方向
- Prefill Disaggregation：分離 prefill 與 decode 階段，避免相互干擾。
- AllToAll 優化：目前仍僅達 InfiniBand 頻寬 1/3，未來預計改善。
- EAGLE-style 推理：可用樹狀預測多 token。
- 新硬體 GB200 NVL72：將是 MoE 模型部署新挑戰與契機。
▍來源出處
▍常見問答（FAQ）
▍結論
DeepSeek-V3/R1 透過 MoE 架構與多節點部署實現傳統模型難以達成的效能平衡。透過混合並行策略與 kernel 最佳化，其在吞吐量、延遲與資源使用方面提供極具參考價值的解法，是未來 LLM 推理部署的重要參考範例。
