LLM推論卡在網路，通常不是因為「網路太慢」這一個原因，而是模型平行方式決定每個Token需要交換什麼資料、交換幾次，以及同步是否位於Critical Path。Tensor Parallel需要頻繁Collective，Pipeline Parallel需要Stage間傳輸，Expert Parallel需要All-to-all，Prefill／Decode分離則要搬移KV Cache。
增加GPU只有在運算時間大於通訊與等待時才會有效。當GPU完成Kernel後持續等待All-Reduce、Remote Expert或KV Transfer，新增卡數可能提高理論算力，卻降低Scaling Efficiency。部署前應先畫出Parallelism與資料路徑，再查看TTFT、TPOT、Collective Timeline和Network Utilization。
重點快讀
- Tensor Parallel常使用All-Reduce或Reduce-Scatter／All-Gather。
- Pipeline Parallel使用Stage間Send／Recv，會產生Bubble。
- Expert Parallel把Token Dispatch到不同GPU，核心是All-to-all。
- Data Parallel主要複製模型並分散Request，跨Replica同步較少。
- P／D Disaggregation會跨Worker傳輸Prompt KV Cache。
- TTFT主要受Queue、Prefill與KV Transfer影響。
- TPOT主要受Decode、HBM、Collective與Batch影響。
- 真正瓶頸要從Trace判斷，不用GPU Utilization單一數字推測。
四種Parallelism交換什麼？
| 平行方式 | 切分單位 | 主要通訊 | 延遲特性 |
|---|---|---|---|
| Tensor Parallel | 同一Layer的矩陣 | All-Reduce、All-Gather、Reduce-Scatter | 每Layer或每Token頻繁同步 |
| Pipeline Parallel | 不同Layer Stage | Activation Send／Recv | Stage Bubble與最慢Stage |
| Expert Parallel | MoE Experts | All-to-all Dispatch／Combine | 路由不均與跨節點敏感 |
| Data Parallel | 完整Model Replica | 推論時多為Router分流 | 獨立Request，擴展較直接 |
大型服務常混合多種方式，例如節點內Tensor Parallel、節點間Data Parallel，或節點內TP加跨節點Expert Parallel。每增加一個維度，都要確認Collective Group與實體Topology是否對齊。
Tensor Parallel為何影響每個Token？
Tensor Parallel把同一個Linear或Attention計算拆到多張GPU。每張卡只得到局部結果，後續Layer前需要合併或重新分布。Decode每輪只有少量Token，Collective啟動延遲和同步等待會更明顯。
- TP Degree提高可放入更大模型。
- 每張卡的Weight和Compute下降。
- Collective次數和參與Rank增加。
- 跨節點TP通常比節點內昂貴。
- 小Batch Decode可能無法攤平通訊。
若模型能放進單節點，通常優先讓高頻TP Collective留在NVLink／NVSwitch域內，再用Data Parallel增加Replica。
All-Reduce、All-Gather與Reduce-Scatter
| Collective | 結果 | 常見用途 |
|---|---|---|
| All-Reduce | 聚合後每個Rank都有完整結果 | TP輸出、訓練梯度 |
| All-Gather | 每個Rank收集所有Rank片段 | Sharded Tensor重建 |
| Reduce-Scatter | 聚合後每Rank保留一段 | 避免先完整All-Reduce |
| Broadcast | 單一Rank送到全部Rank | 模型狀態或控制資訊 |
NCCL會依Topology、Message Size與硬體自動選擇Ring、Tree、CollNet、NVLS、NVLSTree或PAT等演算法。手動固定演算法可能改善特定Case，也可能破壞其他Message Size和Collective。
Pipeline Parallel與Bubble
Pipeline Parallel把Layer分到不同Stage，Activation依序在Stage間移動。Stage數越多，模型越容易跨節點；若Microbatch不足或Stage計算不均，部分GPU會等待上游或下游。
- Stage Boundary的Activation大小。
- 每個Stage的Compute Balance。
- Microbatch和In-flight Request。
- 跨節點Latency與Bandwidth。
- Decode Streaming和Token順序。
- Failure後整條Pipeline重建。
Pipeline可以降低高頻All-Reduce，代價是Bubble和更複雜排程。它適合模型無法在單節點放下或Rack-scale系統，不是小型服務的預設。
Expert Parallel與All-to-all
MoE Router為每個Token選擇Top-k Experts，Token Representation要Dispatch到Expert所在GPU，運算後再Combine回原順序。每個Rank同時向多個Rank送資料，因此流量型態接近All-to-all。
- Expert Load是否平衡。
- Token Dispatch和Combine資料量。
- 節點內NVLink與跨節點RDMA比例。
- Top-k、Hidden Size與資料型別。
- Remote Expert的尾端延遲。
- Buffer、Queue Pair與SM占用。
DeepEP的專家通訊實作可閱讀DeepEP是什麼？。
KV Cache跨節點傳輸
Prefill／Decode分離時，Prompt所有Layer的KV要從Prefill Worker交給Decode Worker。這不是Collective，也可能是Point-to-point、RDMA、Connector或Storage Backend。
KV transfer time ≈
KV bytes / effective bandwidth
+ queue + setup + synchronization長Prompt與MHA增加資料量；GQA、MLA與KV量化降低傳輸。完整P／D架構可閱讀Prefill和Decode為什麼要拆？。
NVLink、PCIe與RDMA的分工
| 路徑 | 範圍 | 適合 |
|---|---|---|
| HBM | 單一GPU | 權重、Activation與KV本地讀寫 |
| NVLink／NVSwitch | 節點內或Rack-scale NVLink域 | 高頻TP Collective |
| PCIe | GPU、CPU與NIC | 較通用P2P與Host Transfer |
| RDMA／InfiniBand／RoCE | 跨伺服器 | Collective、EP與KV Transfer |
| Ethernet TCP | 通用網路 | 控制面與低規模資料流 |
標稱Bandwidth不是實際Collective Bandwidth。NIC數量、PCIe Root、NUMA、GPU Direct、Switch Oversubscription、Message Size與Concurrent Flow都會降低有效值。
TTFT與TPOT如何對應網路？
| 指標 | 主要網路來源 |
|---|---|
| TTFT | Queue、Prefill TP、P／D KV Transfer、Model Router |
| TPOT／ITL | Decode TP Collective、EP All-to-all與Batch等待 |
| End-to-end | 兩階段、Streaming、Tool與Application Network |
| P99 | 壅塞、慢Rank、重試與拓撲不均 |
平均TPOT正常、P99突然變差，常見原因包括某個NIC壅塞、慢Rank、Collective演算法切換或同一Fabric上其他Job競爭。
如何診斷？
- 建立單GPU或單節點Compute基線。
- 逐步增加TP、PP或EP Degree。
- 記錄Kernel、Collective和Idle Timeline。
- 查看每個Rank的開始、結束與慢Rank。
- 量測NVLink、PCIe和NIC實際Throughput。
- 比較Message Size與算法選擇。
- 觀察TTFT、TPOT和Goodput是否改善。
- 測高峰、長Context與混合Request。
GPU Utilization高不代表有效工作；Collective Kernel與Busy Wait也可能占用GPU。需要使用Profiler區分Compute、Communication與Idle。
常見錯誤
- 把TP跨過低頻寬節點。
- 只看NIC平均流量，忽略P99與單Rank。
- 手動固定Ring或Tree後不測其他Shape。
- 忽略PCIe、NUMA和GPU／NIC Affinity。
- 用更多Replica掩蓋單Request Collective問題。
- KV Transfer沒有Timeout、Checksum和Cleanup。
- 不同Model／Tokenizer版本交換不相容KV。
實體拓撲、NCCL演算法和NIC映射可閱讀GPU拓撲感知通訊怎麼做？；運算與通訊時間線可閱讀運算與通訊如何重疊？。
常見問題
GPU越多，推論一定越快嗎？
不一定。單Request需要更多Collective時，通訊可能抵消算力；增加Data Parallel Replica通常較容易提高總Throughput。
All-Reduce只用在訓練嗎？
不是。Tensor Parallel推論也可能在每層或每Token使用Collective整合局部結果。
KV Cache傳輸是All-to-all嗎？
通常不是固定形式。它可能是Prefill到Decode的Point-to-point、RDMA、Connector或Storage傳輸，依Placement決定。
官方資料
LLM網路瓶頸來自Parallelism和資料路徑。TP、PP、EP與KV Transfer交換不同資料，也影響不同延遲；先定位哪一段位於Critical Path，才能決定該加GPU、換拓撲、改Parallelism或調整Scheduler。
發表迴響