Phase 1：DeepSeek-V4-Pro 双机 Pro6000D SGLang 快速性能地图

阶段状态：已完成。 正式 Run dsv4pro-phase1-full-20260730-220916 在双 Rail NET/IB + GDRDMA 下完成 9 个固定点和 3 个混合 A/B 结果， 共 12/12 成功，用时 28 分 36 秒；服务、容器与 16 张 GPU 已清理。

1. 目标与边界

用数小时以内、可重复的小矩阵替代约一天以上的全量扫描，先回答 Prefill、Decode、长上下文和混合干扰各自是否存在明显异常，再决定后续 Timeline 和 Kernel Profiling 的捕获对象。该阶段不要求为了“跑满表格” 而浪费算力；一旦出现稳定、可复现且足以改变调查方向的异常，就可以提前结束。

• 只测试 SGLang，不测试 vLLM。
• 使用双机 16 卡完整实例，不做 PD 分离。
• 不启用 MTP、EAGLE、DSpark 或其他投机解码。
• 本轮不启用 Profiler；正文只记录最终有效 Run，失败尝试仅在末尾总结经验。
• 不修改或调用旧的全天全量 Benchmark 脚本。

2. 精简实现

实验代码位于：

/data/hzy/sskj/experiments/pro6000/
dsv4pro_pro6000d_2node_sglang_tp16_quick_map/

单入口的操作面：

bash run_quick_map.sh all

# 仅排障时使用同一个入口
bash run_quick_map.sh start
bash run_quick_map.sh fixed
bash run_quick_map.sh mixed
bash run_quick_map.sh stop

3. 服务配置

4. 固定快速矩阵

快速 Run 使用一次重复和一波测量请求，即 num_prompts=C。 32K/128K Prefill 不做昂贵的同形状 Warm-up；短 Prefill 与 Decode 使用一个 Warm-up，并在正式计时前清空 Prefix Cache。固定矩阵不做 SLO 截断或自适应并发搜索。

5. SGLang Benchmark 与 Prefix Cache

5.1 random 如何生成 ISL

当前镜像的实现位于 /sgl-workspace/sglang/python/sglang/benchmark/datasets/random.py。 dataset-name=random 会读取 ShareGPT，打乱样本后取每条会话的首轮用户文本： 文本过长就截断，过短就重复其 token，直到达到目标 ISL。 random-range-ratio=1.0 使每条请求都使用精确的目标长度。 本机数据集共有 94,145 行，其中 92,886 行可用、71,904 个不同首轮文本， 因此不存在此前“两条数据只能形成两个并发请求”的问题。

random-ids 则直接构造随机整数 token id，不读取 ShareGPT。 当前源码同时警告这种方式可能触发 NaN，因此本阶段继续使用 random + 大规模 ShareGPT，并通过清缓存隔离不同测试点。

5.2 OSL 为什么能达到指定长度

SGLang 原生请求函数位于 /sgl-workspace/sglang/python/sglang/benchmark/serving.py。 它将目标 OSL 写入 max_new_tokens，并默认设置 ignore_eos=True。因此模型即使提前生成 EOS，也会继续生成到指定 OSL； 只有请求失败、超时或触及上下文限制时，实际输出才可能不足。

sampling_params = {
    "max_new_tokens": request_func_input.output_len,
    "ignore_eos": not args.disable_ignore_eos,
}

5.3 为什么 Warm-up 会污染 Prefix Cache

SGLang benchmark 的 Warm-up 直接复用 input_requests[0]， 而正式测量随后仍会遍历包含该请求的完整列表。因此，只要服务启用了 Prefix Cache， 第一条正式请求就可能命中刚刚 Warm-up 的前缀。第一次 Run 的服务日志实际出现 #cached-token: 768，证明该污染在当前环境真实发生。

修复方式是在每个隔离测试点传入 --flush-cache。benchmark 会先完成 Warm-up，再调用服务端 /flush_cache，最后才启动计时。这样保留 Kernel 和执行路径预热，同时不把 Warm-up 的 KV 前缀带入测量。混合干扰中的长 Prefill 注入不会清缓存，避免在 Decode 背景运行时改变其服务状态；背景与注入使用不同随机种子。

5.4 如何单独测试 Prefix Caching

1. 调用 /flush_cache，发送固定长 Prompt P，记录 Cold TTFT 和 #cached-token。
2. 不清缓存，原样重发 P，记录 Warm TTFT；预期 cached token 明显增加、TTFT 降低。
3. 再次清缓存，发送同长度但内容不同的 Prompt Q，排除长度、JIT 和偶然波动造成的假提升。

三组请求保持 OSL、采样参数和并发一致，各重复至少 3 次。Prefix Cache 是生产优化能力， 不是“坏东西”；这里只是在无缓存性能基线中隔离它，后续会把缓存命中场景作为单独 A/B。

6. 混合干扰实现

这里的“背景”不是 SGLang 后台线程，而是先启动并持续运行的一批 Decode 基准流量。它既在实验期间占用 GPU，也是我们希望观察是否 变慢的对象。混合 A/B 的问题非常具体：同样一批 Decode 请求，在没有长 Prefill 干扰和有长 Prefill 干扰时，性能会相差多少？

1. 先完成 A 组，仅运行 Decode，保存对照指标。
2. 启动 B 组的 Decode 基准流量，并从日志确认它已进入正式测量，而不只是完成客户端初始化。
3. 正式测量开始 10 秒后，并行提交一个 128K → 1 长 Prefill。
4. 等待两类请求都结束，分别保存 Decode 流量和长 Prefill 请求的结果。
5. 用 A、B 两组 Decode 的 Output TPS、TTFT P95、TPOT P95 与 E2E P95 计算变化率；长 Prefill 自身的 TTFT 单独报告。

A：Decode ───────────────────────────────→ 结束

B：Decode ───────────────────────────────→ 结束
             正式测量 + 10 秒
                        └─ 128K Prefill ─→ 结束
                           共同占用同一服务

(
  run_bench_case ... 1024 1024 32 64
) &
background_pid=$!

# 实际代码先从 bench.log 确认正式测量已经开始。
sleep 10
run_bench_case ... 131072 1 1 1
wait "${background_pid}"

& 让 Decode benchmark 与后续 Prefill 并行； $! 取得该 Decode benchmark 的进程号； wait 等待它完成。总请求数 64、并发 32，表示最多同时有 32 条请求在途，通常形成约两波请求。如果 Decode 流量在注入前已经结束， 两类请求没有发生重叠，结果会被明确改写为 BACKGROUND_FINISHED_BEFORE_INJECTION，避免生成虚假的“混合成功”。

7. 结果与可追溯性

results/<RUN_ID>/
  run_manifest.json
  run.log
  summary.csv
  summary.jsonl
  aggregate.csv
  report.md
  cases/<case_id>/rep1/
    bench_cmd.txt
    bench.jsonl
    bench.log
    meta.json
  server/
    head_server_cmd.txt
    worker_server_cmd.txt
    head_server.log
    worker_server.log

汇总保留 Request/Input/Output/Total TPS，以及 E2E、TTFT、TPOT、ITL 的 Mean、P50、P95、P99。断点续跑前会重新解析原始 Bench JSON，不能只凭文件存在就跳过。

8. 已完成验证

9. 最终真机结果

本节只使用正式成功 Run。Profiler 与投机解码均关闭，每个 Case 只做一次快速测量， 所以它适合决定下一步 Profile 对象，不作为需要统计置信度的最终容量认证。

9.1 执行摘要

9.2 Prefill

9.3 Decode

Decode 吞吐到 C=64 仍在上升，但增益递减且 TPOT 明显变差。综合场景 32K → 1K，C=8 的 Input/Output TPS 为 2,038.00 / 63.69，TTFT P95 为 82.084 s， 说明 Prefill 与 Decode 同时存在时干扰很强。

9.4 混合 Prefill/Decode A/B

Phase 2 优先采集三类代表负载：128K → 1，C=1 的纯长 Prefill、 32K → 1，C=16 的并发 Prefill，以及 1K → 1K，C=32 在有无 128K 注入时的混合 A/B。 目标是区分计算、显存带宽、调度排队、跨机通信和节点不均衡。

完整产物： 报告、 逐点汇总、 聚合表、 运行清单。

10. 经验教训

• 启动参数不等于实际传输路径；开始性能测试前必须由 NCCL 日志证明 NET/IB。
• Warm-up、固定随机种子和跨 Case Prefix Cache 会改变 TTFT，冷缓存与热缓存必须分开报告。
• 先跑四点 Sanity 再启动完整矩阵，可以在几分钟内验证环境、口径和数量级。

历史排查细节保存在 TTFT 脚本口径审计报告 与 TP16 网络路径审计报告， 不作为本阶段最终结果。

11. 运行命令

cd /data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map

tmux new-session -d -s dsv4pro-phase1-full \
  "RUN_ID=dsv4pro-phase1-full-20260730-220916 bash run_quick_map.sh all \
   2>&1 | tee /data/hzy/dsv4pro_phase1_full_20260730-220916.log"

tmux attach -t dsv4pro-phase1-full

下一阶段： Phase 2：Prefill 硬件指标归因

返回推理优化主计划