86 lines
3.7 KiB
Markdown
86 lines
3.7 KiB
Markdown
# Kimi-K3 DP2 无投机：TP32 与 PP8 对比
|
||
|
||
## 测试目的
|
||
|
||
在 8 台 RTX 6000D 上部署两个独立四节点 SGLang 副本，通过 SGLang Router `round_robin` 组成 DP2，比较两种单副本并行策略：
|
||
|
||
- TP32：`TP32/PP1/EP4`
|
||
- PP8：`TP4/PP8/EP4`
|
||
|
||
本轮不启用投机解码，重点观察长输入场景下 TTFT 与长 Decode 的取舍。
|
||
|
||
## 固定口径
|
||
|
||
| 项目 | 配置 |
|
||
|---|---|
|
||
| 数据集 | SPEED-Bench `/data/speedbench16k_complete.jsonl` |
|
||
| 请求 | 40 条，16K 输入，512 输出 |
|
||
| 客户端并发 | C=8 |
|
||
| Chunked Prefill | 8K |
|
||
| MoE | EP4，FlashInfer MXFP4，A2A=none |
|
||
| KV Cache | BF16 |
|
||
| Prefix Cache | 关闭 |
|
||
| Router | 两副本 `round_robin` |
|
||
| GPU | 601-608，共 64 卡 |
|
||
|
||
两种配置均在正式计时前分别预热两个副本，并由 benchmark 再执行一条标准 warmup。`Peak concurrent requests=12` 是 SGLang 报告的服务端峰值，可因排队高于客户端 `max_concurrency=8`，不表示客户端发出了 12 路并发。
|
||
|
||
## 结果
|
||
|
||
| 指标 | DP2 TP32/PP1/EP4 | DP2 TP4/PP8/EP4 | PP8 相对 TP32 |
|
||
|---|---:|---:|---:|
|
||
| 成功请求 | 40/40 | 40/40 | 相同 |
|
||
| Benchmark duration | 238.18s | 370.30s | +55.47% |
|
||
| Input TPS | 2797.64 | 1799.46 | -35.68% |
|
||
| Output TPS | 85.99 | 55.31 | -35.68% |
|
||
| Total TPS | 2883.63 | 1854.76 | -35.68% |
|
||
| TTFT mean | 8.35s | 7.84s | -6.15% |
|
||
| TTFT median | 5.30s | 7.03s | +32.62% |
|
||
| TTFT p95 | 20.79s | 11.68s | -43.82% |
|
||
| TPOT mean | 75.93ms | 126.86ms | +67.07% |
|
||
| TPOT median | 79.95ms | 136.09ms | +70.22% |
|
||
| TPOT p95 | 88.06ms | 145.13ms | +64.80% |
|
||
| E2E mean | 47.15s | 72.66s | +54.10% |
|
||
| E2E p95 | 59.24s | 82.83s | +39.82% |
|
||
|
||
## 初步结论
|
||
|
||
PP8 继续体现了 Prefill 优势：平均 TTFT 小幅下降 6.15%，TTFT p95 降低 43.82%，长尾更稳定。这来自 TP 通信域从 32 缩到 4，并由流水线分摊模型层。
|
||
|
||
但 512-token Decode 暴露了 PP8 的代价。每个 token 都要依次通过 8 个 Pipeline Stage，TPOT 增加 67.07%，最终使 Output TPS 降低 35.68%、E2E 平均时延增加 54.10%。因此：
|
||
|
||
- 以 P 节点 TTFT 为目标时，PP8 有价值，尤其能改善 TTFT 长尾。
|
||
- 作为不做 PD 分离的完整 16K→512 服务，TP32 综合表现更好。
|
||
- PP8 更适合作为 PD 分离中的 P 侧配置，由独立 D 侧承担长 Decode；不能用本轮 PP8 的 E2E/TPOT 直接否定其 P 侧价值。
|
||
|
||
TP32 的 TTFT median 更低但 p95 明显更高，说明该配置在 DP2 排队与长 Prefill 交错时波动更大。后续如继续优化单实例，应分别报告 median 与 p95，不能只看 mean。
|
||
|
||
## 数据质量与日志说明
|
||
|
||
两轮 Router 初始命令没有挂载模型目录，因此 worker tokenizer 注册出现错误。Router 使用固定 `round_robin`，不依赖 tokenizer 做 cache-aware 路由；40/40 请求成功，两副本 Prefill 数量接近均分，未发现请求级失败或重试，所以不影响本轮 A/B 结论。脚本已补上 Router 模型只读挂载，后续运行不会再产生该注册错误。
|
||
|
||
满负载期间 Router 偶有 `/health` 超时，这是模型服务忙于长 Prefill/Decode 时健康响应延迟；两轮均未出现 OOM、NCCL collective failure、Traceback 或 EngineDeadError。
|
||
|
||
## 原始结果
|
||
|
||
TP32：
|
||
|
||
```text
|
||
/data/hzy/sskj/experiments/pro6000/kimi3_pro6000_dp2_nospec_ab/results/dp2-tp32-final-20260902-123051/
|
||
```
|
||
|
||
PP8：
|
||
|
||
```text
|
||
/data/hzy/sskj/experiments/pro6000/kimi3_pro6000_dp2_nospec_ab/results/dp2-pp8-final-20260902-130711/
|
||
```
|
||
|
||
核心 benchmark 日志分别位于：
|
||
|
||
```text
|
||
bench/tp32_speedbench16k_c8_o512.log
|
||
bench/pp8_speedbench16k_c8_o512.log
|
||
```
|
||
|
||
每个结果目录同时保存完整启动命令、环境 manifest、输入校验值、Router 日志和八节点服务日志。
|