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

阶段状态：提前结束，已进入硬件归因。 第一次真机 Run dsv4pro-pro6000d-2node-sglang-quick-20260730-140026 已验证双机服务可用，但因发现请求量和 Prefix Cache 口径问题而主动停止。 精简后的第二次 Run dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625 完成 3 个 Prefill 固定点后，发现输入吞吐稳定锁定在约 65 token/s。继续扫描 Decode 和混合流量不能解释该异常， 因此用户决定中止第 4 个 Case，直接进入 Phase 2。 Manifest 终态为 ABORTED_EARLY_FOR_PHASE2； 两节点容器和 16 张 GPU 已清理。

1. 目标与边界

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

• 只测试 SGLang，不测试 vLLM。
• 使用双机 16 卡完整实例，不做 PD 分离。
• 不启用 MTP、EAGLE、DSpark 或其他投机解码。
• 本轮不启用 Profiler；三个已完成 Case 可作为对应 Shape 的端到端基线。
• 不修改或调用旧的全天全量 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 dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625。 以下三条均为一条请求、C=1、OSL=1，且正式测量前 Prefix Cache 已清空。

9.1 可以下的结论

• 三个长度的输入吞吐只相差约 1.2%，稳定在 64.44–65.20 token/s。
• 32K TTFT 约为 1K 的 31.76 倍；128K TTFT 约为 32K 的 3.99 倍，几乎按 token 数线性增长。
• 这不是偶发卡顿：服务端每约 125 秒完成一个 8192-token Chunk，GPU 在该期间持续忙碌。
• 32K, C=16 的观察窗口内，日志持续显示 #new-seq: 1，队列从 15 降到 14；至少当前路径没有立即把 16 条 Prefill 合成大批次。
• 没有出现 OOM、NCCL、CUDA、EngineDead 或请求失败，所以“服务崩溃”不能解释低吞吐。

9.2 现在还不能下的结论

• 仅凭 GPU Utilization=100% 不能判断是算力、显存带宽还是通信瓶颈。
• 尚不能断言是 SGLang Bug、DSV4/NSA Kernel、TP16 NCCL、MoE Backend 或 Scheduler 中的哪一项。
• Decode、Balanced 和混合 A/B 未执行，Phase 1 不提供这些场景的基线。
• 每个 Shape 只有一次重复，不能用于稳定性或 CV 结论。

9.3 为什么提前结束

Phase 1 的目标是发现值得归因的关键异常，而不是机械完成九个格子。 三个独立长度已经给出同一个稳定信号；第 4 个并发 Prefill 在 922 秒后仍表现为 单序列 Chunk 推进。继续执行剩余矩阵预计还需数小时，却不能回答 “这 65 token/s 到底卡在哪里”。因此第 4 个 Case 被写入 EARLY_STOP_FOR_PHASE2，其余固定点和混合 A/B 保留为未执行。

9.4 为什么旧脚本的 TTFT 短很多

2026-07-30 对旧目录 /data/qqt/sskj/experiments/pro6000/dsv4_pro6000_sglang_tp16 做了逐项审计。结论是：旧结果与本轮冷 Prefill 不是同一缓存口径， 不是 quick-map 把相同请求跑慢了。

旧时间线还有一条直接证据：17:40 的失败 Run 已完整执行过 1K / 128 / C=1，18:01 的正式 Run 没有重启服务便再次执行同一批 Seed=42 请求。因此旧文件中的 1K TTFT 约 0.455 秒，本身就是热缓存结果。

旧 32K 文件的第一条请求约 0.67 秒，其余 9 条平均约 35.51 秒； 旧 128K 文件的第一条约 0.96 秒，其余 9 条平均约 144.83 秒。 后 9 条也已经分别继承上一档 16K、64K 前缀。旧报告仍按完整 ISL 统计 Input TPS，因此会把只计算新增后缀的耗时除进完整 token 数，进一步放大吞吐。

审计结论：Phase 1 的约 65 token/s 是冷 Prefix Cache 的完整 Prompt 路径， 旧结果是热缓存/递增前缀路径。两者都可以测，但必须分成 Cold 与 Warm 两套实验， 不能放在同一列直接比较。审计原始产物保存在：

/data/hzy/dsv4_script_audit_20260730/

本地归档： TTFT 脚本口径审计报告 及同目录原始 JSON/log。

10. 结果位置

服务器原始结果：

/data/hzy/sskj/experiments/pro6000/
dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/
dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/

本地已归档 report.md、 aggregate.csv 和同目录下的 Manifest、Summary、主日志。

11. 运行命令

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

tmux new-session -d -s dsv4pro-pro6000d-2node-sglang-quick-map -c "$PWD"
tmux send-keys -t dsv4pro-pro6000d-2node-sglang-quick-map \
  'RUN_ID=dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625 bash run_quick_map.sh all' Enter

tmux attach -t dsv4pro-pro6000d-2node-sglang-quick-map

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

返回推理优化主计划