sskj/bench_results/dspark_grid_20260707-132641/evaluation.md

vllm-dspark Benchmark 结果评估

对应结果：/data/user1/yy/bench_results/dspark_grid_20260707-132641
运行时间：2026-07-07
硬件：8× NVIDIA H200 143GB
模型：/data/models/DeepSeek-V4-Flash-DSpark
服务配置：TP=8，FP8 KV cache，--spec-method dspark --spec-tokens 5，block-size=256，max-num-seqs=256
压测工具：sglang.bench_serving --backend vllm

---

1. 总体结论

本次 grid 测试覆盖了从轻量 chat 到超长上下文、从重 decode 到高并发压测的多种场景。整体上看：

• DSpark 在短输入、中高并发场景下表现优秀，chat_short 在并发 64 时达到约 9580 tok/s，stress_standard 在并发 128 时达到约 17465 tok/s。
• 低并发下 DSpark 的 draft 开销明显，部分场景单并发延迟和吞吐都不如预期。
• 超长上下文场景存在明显的吞吐拐点，long_rag（32K 输入）在并发 4 达到峰值后，并发 8 吞吐腰斩。
• 延迟长尾（P95/P99）普遍较重，提示调度、内存或投机解码验证阶段存在抖动。

---

2. 异常点分析

2.1 低并发（c=1）下 DSpark 收益被开销吃掉

以 chat_standard（input=1000, output=256）为例：

并发	req/s	mean E2E(ms)	P99 E2E(ms)	mean TTFT(ms)	P99 TTFT(ms)
1	0.49	2040.65	10715.53	1412.48	8430.71
8	4.35	1819.35	15165.63	327.62	4404.92
16	8.32	1885.15	10491.31	443.50	8567.07
32	10.00	3156.73	12936.08	560.77	7129.66

• 单并发吞吐仅 0.49 req/s，远低于无投机基线可预期的水平。
• P99 TTFT 高达 8.4s，说明单请求首次预填充极不稳定，可能是 draft 验证/编译缓存未命中或 warmup 不充分导致。
• 并发提升到 8 后，TTFT 均值下降到 327ms，说明 DSpark 的 draft 计算需要 batch 才能摊薄。

判断：这是 DSpark 的典型特征——低并发下 draft 固定开销无法被摊薄，导致延迟尾和单请求吞吐都较差。

2.2 超长上下文出现吞吐断崖

long_rag（input=32000, output=512）：

并发	Total tok/s	mean TTFT(ms)	P99 TTFT(ms)
1	16104.98	549.72	1163.96
2	43215.62	192.57	409.32
4	70040.54	191.57	427.69
8	34141.70（↓51%）	930.98	2742.48

long_context_probe（input=16000, output=512）也有类似模式：

并发	Total tok/s	mean TTFT(ms)
1	11051.09	316.59
2	26862.06	110.65
4	43042.77	127.38
8	29255.46（↓32%）	453.93
16	43292.68	444.14

判断：

• 32K/16K 长 prefill 在并发 4 时达到最佳，继续加并发反而下降，可能与 KV cache 显存带宽瓶颈、prefill 阶段 scheduling 阻塞 或 hybrid KV cache manager 的换入换出 有关。
• long_rag 在 c=8 时 P99 TTFT 暴涨到 2.7s，进一步印证内存/调度压力。

2.3 延迟长尾普遍偏重

几乎所有场景的 P99 E2E 都是 mean E2E 的 2~4 倍：

场景	并发	mean E2E	P99 E2E	倍数
chat_standard	32	3156.73	12936.08	4.1×
generation_standard	32	2908.89	6938.03	2.4×
summarization	32	5587.21	14541.75	2.6×
decode_heavy	32	5562.57	12822.35	2.3×
stress_standard	128	4417.43	14850.43	3.4×

判断：投机解码的 draft 验证失败会导致 fall back 到逐个 target 前向，造成明显的延迟毛刺；另外 vLLM v1 引擎的 scheduling 在高并发下也可能产生队列等待。

2.4 高并发下 TPOT/ITL 增长较快

stress_standard（input=1000, output=256）：

并发	mean TPOT	P95 TPOT	P99 TPOT	mean ITL
96	29.46	67.30	123.42	113.64
128	35.20	76.85	141.17	136.57

TPOT 从 29ms 升到 35ms，P99 超过 140ms，说明 decode 阶段在极限并发下已经接近饱和。

---

3. 可重点优化的方向

3.1 按并发动态调整 --spec-tokens

参考历史对比数据（dsv4_inference_comparison_report.md）：

spec-tokens	低并发（c=1）	高并发（c=64）
3	1.03 req/s, 254 tok/s	14.53 req/s, 3507 tok/s
5	1.07 req/s, 257 tok/s	9.36 req/s, 2210 tok/s
7	1.03 req/s, 251 tok/s	9.13 req/s, 2218 tok/s

当前部署固定使用 --spec-tokens 5：

• 对低并发（c=1~16）相对友好；
• 对高并发（c≥64）不是最优，st=3 在高并发下接受率更高、验证开销更小。

建议：

• 高并发服务场景：改用 --spec-tokens 3。
• 若负载混合，可考虑不同 endpoint/队列按并发分桶，或测试 st=3/st=5 在本 grid 下的完整表现。

3.2 长上下文场景优化

针对 long_rag（32K）和 long_context_probe（16K）的吞吐断崖：

1. KV cache dtype 对比测试：当前是 FP8，可测试 BF16 是否改善长上下文稳定性和吞吐。
2. block-size 调整：当前 256，可尝试 128 或 64 看是否减少内存碎片。
3. hybrid KV cache manager：当前 --no-disable-hybrid-kv-cache-manager，可对比关闭后的表现。
4. 限制长上下文并发：若业务允许，对 32K 输入设置更低的 max-num-seqs 或独立队列，避免 c=8 后的内存带宽瓶颈。
5. attention backend：可测试 FLASHINFER_MLA_SPARSE_DSV4（脚本 start_dsv4_dspark_8card_flashinfer.sh）在长上下文下的表现。

3.3 降低延迟长尾

1. 增加 warmup：当前仅 10 条 warmup。DSpark 的 JIT 编译/算子 warmup 在首次运行时较重，建议增加到 50~100 条或先跑一轮 discard。
2. compilation cache 持久化：确认 TORCH_EXTENSIONS_DIR、VLLM_CACHE_ROOT 等环境变量已设置并复用，避免每次重启重新编译 deep_gemm/tilelang。
3. 调度参数：尝试调整 --max-num-batched-tokens、--max-num-seqs、chunked prefill 相关参数，减少队列等待。
4. P99 TTFT 抖动：高并发下 P99 TTFT 高通常与 prefill batching 有关，可尝试限制 prefill 阶段 batch 大小或启用 prompt chunked prefill。

3.4 低并发场景是否需要 DSpark

对于 chat_standard c=1：

• 当前 0.49 req/s、P99 E2E 10.7s 的服务质量较差。
• 若业务存在大量单用户/低并发请求，可考虑：
  • 部署无投机基线 vLLM 专门服务低并发流量；
  • 或设置最小 batch 阈值，累积少量请求后再用 DSpark 处理。

3.5 对比 baseline 与 SGLang

本次测试只有 DSpark 单一配置，建议补充：

1. vLLM-dspark 无投机基线：用同样的 sglang.bench_serving --backend vllm 测一遍相同 grid，计算真实加速比。
2. SGLang EAGLE：在相同 grid 下复测，验证 DSpark 在不同场景下的相对优势。
3. 不同 --spec-tokens 的完整 grid：st=3 和 st=5 各跑一遍，绘制并发-吞吐曲线。

---

4. 推荐下一步实验

优先级	实验	预期收益
P0	高并发改用 --spec-tokens 3	提升 c≥64 场景吞吐 20~50%
P0	长上下文（16K/32K）对比 BF16 KV cache	改善吞吐断崖和 P99 TTFT
P1	增加 warmup / 预热缓存	降低 P99 TTFT 和首请求延迟
P1	测试 FLASHINFER_MLA_SPARSE_DSV4 backend	可能提升长上下文吞吐
P2	跑无投机基线 grid	获得真实加速比
P2	对比 st=3/st=5 完整曲线	找到最佳投机长度配置

---

5. 结论

当前 DSpark 部署在 短输入、中高并发 场景下已经展现出明显优势，但在 低并发 和 超长上下文 场景下存在明显短板。最优先的优化是：

1. 高并发服务改用 --spec-tokens 3；
2. 针对 16K/32K 长上下文做 KV cache dtype 和 attention backend 的调优；
3. 补充 baseline 测试，量化 DSpark 的真实收益。