From d2a585c5cbe067cb232528893ba5bf2d7b5f0952 Mon Sep 17 00:00:00 2001 From: Gahow Wang Date: Mon, 15 Jun 2026 23:20:26 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20KI-1=20re-diagnosed=20in=20v3=20?= =?UTF-8?q?=E2=80=94=20larger=20batch=20does=20NOT=20fix=20DDP=20weak=20sc?= =?UTF-8?q?aling?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit v3 tested the documented mitigation (raise global_batch to amortize the per-step all-reduce). Isolated back-to-back A/B on 4× RTX 5090, dim384/12L, seq256: global_batch 32 (8/rank) → 3163 tok/s global_batch 256 (64/rank)→ 3200 tok/s (8× batch, +1.2%, within noise) 8× larger batch = 1/8 the all-reduces per token, yet no speedup → all-reduce is NOT the bottleneck. GPU util 0–15%, mem ~2–3 GB/32 GB → the workload is launch-bound: the single-sequence model design (each sequence its own tiny forward/backward, per-op kernel launches) starves the GPU, and batching only adds proportionally more serial launches. Real fix is batched (multi-sequence) forward so GEMMs fill the GPU — a T4/T5 autograd/model change, not a batch knob. Bucketed/overlapped all-reduce stays deferred (no value until launch-bound is fixed). KI-1 kept Open with the corrected root cause. Co-Authored-By: Claude Opus 4.8 --- docs/known-issues.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/docs/known-issues.md b/docs/known-issues.md index 0a35853..b64c7c1 100644 --- a/docs/known-issues.md +++ b/docs/known-issues.md @@ -7,14 +7,20 @@ ## Open -### KI-1 · DDP 弱扩展性（small global batch）— `P1` · 由 v2 暴露 -- **现象**：4 卡 DDP 仅 ~3593 tok/s，几乎不快于 v1 单卡 ~3310 tok/s（≈1.08×，远低于近线性；T8 在 tiny 规模为 3.0×@4）。 -- **复现**：v2 训练 `dim384/12L, world=4, global_batch=32（每卡 8）, seq 256`。 -- **根因**：每个 step 对**全部参数梯度**做一次 NCCL all-reduce 是固定开销；`global_batch` 太小 → 每卡 compute 太少 → 通信/同步开销占比过高，吃掉扩展性。 -- **拟修复**： - 1. 显著加大 `global_batch`（每卡 batch ↑：摊薄 all-reduce、喂饱 GPU）—— v3 先用此缓解； - 2. 梯度 all-reduce **分桶 + 与 backward 重叠**（bucketed / overlapped all-reduce）； - 3. 减少 per-step 同步点（与 KI-2/KI 性能项协同）。 +### KI-1 · DDP 弱扩展性（吞吐受单序列 launch-bound 限制）— `P1` · 由 v2 暴露，v3 重新诊断 +- **现象**：4 卡 DDP 仅 ~3.2K tok/s，几乎不快于单卡（≈2× over 单卡，远低于近线性；T8 在 tiny micro-bench 为 3.0×@4）。 +- **复现**：`dim384/12L, world=4, seq 256`。 +- **v3 实测（dash5, 4× RTX 5090, dim384, 隔离 back-to-back A/B）**： + | global_batch | 每卡 | tok/s（4卡）| GPU util | 显存 | + |---|---|---|---|---| + | 32 | 8 | **3163** | 5–69%（spiky）| ~2–3 GB / 32 GB | + | 256 | 64 | **3200** | 0–15% | ~2–3 GB / 32 GB | + → **加大 8× batch 仅 +1.2% 吞吐（噪声内）**。1 卡 dim384 ≈ 1653 tok/s，4 卡 3163 ≈ 2.1×。 +- **原"拟修复"（加大 global batch）经 v3 实测 falsified**：gbatch256 时每 token 的 all-reduce 次数只有 gbatch32 的 1/8，若瓶颈是 all-reduce 应大幅提速——实际没有 → **all-reduce / 通信不是瓶颈**。 +- **重新诊断的根因**：瓶颈是**单序列模型设计**（T5：每个 sequence 各跑一次独立 forward/backward，逐 op kernel-launch 开销，见 docs/06 延迟瓶颈）。GPU util 仅 0–15%、显存仅占 ~8% → 严重 **launch-bound / under-utilized**；GEMM 太小喂不饱 GPU。加大 batch 只是按比例增加串行 launch 次数，无法摊薄。4 卡相对单卡 ~2× 的固定天花板来自跨 rank 同步税，但**不是**靠调 batch 能修的。 +- **真正的修复（需实作，非调参）**： + 1. **batched（多序列）forward**——把一个 step 的多条序列在 batch 维一次性过模型，让 GEMM 大到能填满 GPU（这是 launch-bound 的根本解，但要改 T4/T5 的 single-sequence autograd/model，工作量大、有正确性风险）； + 2. 在 (1) 之后，梯度 all-reduce **分桶 + 与 backward 重叠**（bucketed / overlapped all-reduce）才会有意义（当前 all-reduce 已非瓶颈，做了也无收益）。 - **参考**：[docs/07-distributed.md](07-distributed.md)、[docs/06-performance.md](06-performance.md)。 ---