6000D 双机 DeepSeek-V4-Pro 推理优化计划

适用环境：174.1.51.5 + 174.1.51.7，每台 8 张 RTX PRO 6000 Blackwell Server Edition
当前部署：DeepSeek-V4-Pro，16 张 GPU 组成一个完整实例
当前约束：模型暂时只能使用全部 16 张 GPU，无法额外复制一套模型进行 PD 分离
计划版本：2026-07-30 15:52 CST

当前执行状态与阶段档案

1. 目标与原则

1.1 最终目标

在不做 PD 分离的前提下，定位 DeepSeek-V4-Pro 在双机 6000D 上的端到端瓶颈，并提高：

• 满足 TTFT、TPOT 等 SLO 时的最大吞吐。
• 长上下文 Prefill 性能。
• Decode 输出吞吐和单请求 TPOT。
• 混合流量下的稳定性与 P95/P99 时延。
• 16 张 GPU、PCIe 和双 Rail 计算网的有效利用率。

1.2 核心原则

1. 先找关键路径，再调参数。
2. 先用端到端指标确认问题，再用 Timeline 找到阶段，最后才用 Kernel Profiler。
3. Prefill、Decode 和混合干扰必须分别测试。
4. 一次只改变一个变量，每项优化都要保留可复现的 A/B 结果。
5. 单算子更快不代表服务吞吐更高，最终结论必须回到真实请求和 SLO。
6. Profiling Run 只用于定位，不能与无 Profiler 的正式性能结果直接比较。

2. 当前最值得验证的瓶颈假设

3. Profiling 总体流程

端到端性能地图
    ↓
服务内部指标与硬件计数器
    ↓
Nsight Systems 时间线
    ↓
确定 1-3 个主要瓶颈
    ↓
Nsight Compute 或专项 Microbenchmark
    ↓
提出优化并做单变量 A/B
    ↓
回到完整 Benchmark 和 SLO 验证

不要直接对完整服务运行长时间 Nsight Compute。它的开销很高，也会生成巨大的报告。应先用 Nsight Systems 找到占关键路径的 Kernel，再构造小型复现。

4. Phase 0：冻结可复现环境

正式测试前，每个 Run 必须保存以下信息：

• 两台机器的 GPU、Driver、CUDA、NCCL 版本。
• vLLM 或 SGLang 的镜像名、镜像 ID、Git Commit 和 Python 包版本。
• 模型目录、权重文件校验信息和模型配置。
• 完整 Docker Run 与服务启动命令。
• 完整 Benchmark 命令。
• TP、DP、PP、EP 拓扑。
• Attention、NSA、Indexer、MoE、GEMM 和通信 Backend。
• NCCL_SOCKET_IFNAME、NCCL_IB_HCA、NCCL_CROSS_NIC 等通信变量。
• GPU Memory Fraction、Context Limit、Active Request Limit、KV Cache Dtype。
• CUDA Graph、Chunked Prefill、Prefix Cache 和投机解码状态。
• 运行前后的 nvidia-smi、容器列表和网络状态。

建议每次运行生成：

results/<RUN_ID>/
  run_manifest.json
  run.log
  summary.csv
  summary.jsonl
  aggregate.csv
  report.md
  cases/
  server/

基线约束

• 初始基线不启用 MTP、EAGLE、DSpark 等投机解码。
• 初始基线使用唯一随机 Prompt，避免 Prefix Cache 影响。
• 短 Prefill 与 Decode 点执行一个 Warm-up；昂贵的 32K/128K Prefill 不做同形状 Warm-up。
• 隔离测试点在 Warm-up 后、正式计时前清空 Prefix Cache，避免首条测量请求复用 Warm-up 前缀。
• 快速定位 Run 先执行 1 次；只有进入里程碑基线后才执行 3 次并计算变异系数。
• 正式结果使用无 Profiler 运行。
• Profiling 只捕获预热后的少量 Engine Step。

5. Phase 1：建立阶段化性能地图

本阶段当前实现与结果维护在 Phase 1：双机 SGLang TP16 快速性能地图实施记录。 代码采用单一 Shell 入口 run_quick_map.sh，不修改或调用旧的全天全量脚本。

最终 Run 完成 1K、32K、128K 三个单请求 Prefill 点，输入吞吐分别为 64.44、64.96、65.20 token/s。第 4 个 32K, C=16 点在稳定复现 单序列 Chunk 推进后被主动中止；Manifest 状态为 ABORTED_EARLY_FOR_PHASE2。Decode、Balanced 和混合 A/B 未执行。

旧脚本 TTFT 较短的问题已完成复核。新旧服务端关键运行参数相同；旧脚本固定 warmup_requests=16、不清 Prefix Cache、按固定 Seed 递增长度， 且正式 Run 前已有一次失败 Run 预热同一批请求。最小复现中，两次清 Cache 的 1K 冷 TTFT 分别为 16.04 秒和 15.90 秒，OSL=128 时为 15.79 秒；旧产物的 0.455 秒无法在冷缓存口径复现。因此当前 65 token/s 明确解释为完整冷 Prompt 路径，Warm Prefix 性能后续单独做 A/B。

5.1 当前固定快速矩阵

长度应以当前已验证的服务容量为上限。如果 128K 不可用，先降到 64K，但必须在 Manifest 中记录原因。

5.2 混合干扰 A/B

1. 先运行有限的 1K → 1K, C=32 Decode 对照流量。
2. 再次运行相同 Decode 基准流量，并等待 Benchmark 确认进入正式测量。
3. 正式测量开始 10 秒后注入一个 128K → 1, C=1 长 Prefill；不额外执行 128K Warm-up。
4. 比较 Output TPS、P95 TTFT、P95 TPOT 与 P95 E2E 的变化。

该 A/B 在 Phase 1 中未执行，待 Prefill 异常完成归因后再决定是否重放。这是聚合级干扰探针，不声称具备逐请求时间线归因能力；后者在 Scheduler 与 Timeline 阶段实现。

5.3 本轮运行与停止策略

• 固定矩阵不做 Add-16 搜索，也不按 SLO 提前终止。
• 快速 Run 每个 Case 只执行一波请求，即 num_prompts=C，默认重复 1 次。
• 单个 Case 失败会记录错误并继续；服务失去健康状态则中止，避免连锁无效结果。
• 断点续跑只有在 meta.json 为成功且原始 Benchmark JSON 可重新解析时才跳过。
• 进入里程碑基线后使用 3 次重复；自适应并发搜索仍由后续完整容量实验负责。
• 如果少量 Case 已稳定暴露足以改变调查方向的异常，可由用户决定提前结束并进入归因阶段；必须在 Manifest 和报告中记录未执行项。

不能把“最大成功并发”“最高 TPS 并发”和“满足 SLO 的最大并发”混为同一个值。

5.4 当前采集范围

本轮已实现的请求层指标

• 实际成功、失败和超时请求数。
• 实际输入、输出和总 token 数。
• Request Throughput。
• Input、Output 和 Total TPS。
• P50/P95/P99 TTFT。
• P50/P95/P99 TPOT。
• P50/P95/P99 ITL。
• P50/P95/P99 E2E。

本轮明确不采集

Scheduler Step、逐请求 Queue Time、显存分解、GPU/CPU/网络时间序列和 Kernel Timeline 不伪装成当前已有能力；它们分别由后续硬件指标与 Profiling 阶段补齐。

6. Phase 2：同步采集轻量硬件指标

本阶段的设计、代码改动与结果同步维护在 Phase 2：Prefill 硬件指标归因档案。第一轮只重放 32K → 1, C=1，目标是在约 20 分钟内区分 GPU、CPU、双 Rail、 频率节流和节点不均衡。该请求在测量前清 Prefix Cache；旧脚本中的热缓存 TTFT 不作为本阶段参照值。

6.1 GPU

测试期间持续记录：

nvidia-smi dmon -s pucvmt -d 1

重点观察：

• SM Utilization。
• HBM Utilization。
• 显存占用。
• GPU Clock、Memory Clock。
• Power 与温度降频。
• PCIe RX/TX。

如果有 DCGM，增加：

• Tensor Core Active。
• DRAM Active。
• SM Active。
• PCIe Throughput。
• GPU Stall 与 XID。

6.2 CPU

记录服务主进程与 Worker 线程：

pidstat -t -p <PID> 1
mpstat -P ALL 1
numastat -p <PID>

需要发现：

• 单个 Scheduler Thread 是否满核。
• Tokenizer、HTTP Frontend 或 Python 线程是否阻塞。
• Worker 是否跨 NUMA 访问。
• CPU 空洞是否对应 GPU 空洞。

6.3 网络

当前拓扑中需要分别观察两条 Compute Rail，确认：

• 两条 Rail 是否同时有流量。
• 带宽是否均衡。
• 是否有丢包、重传、PFC Pause 或错误计数。
• 慢 Rank 是否固定绑定某个 NIC 或 NUMA 节点。

基础监控可以使用：

sar -n DEV 1
ethtool -S eth0
ethtool -S eth3

通信调试 Run 可以临时开启：

NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,GRAPH,TUNING

该日志开销较高，不应在正式性能结果中长期启用。

6.4 NCCL_CROSS_NIC 快速 A/B

Phase 1 固定使用 NCCL_CROSS_NIC=1。完成首轮 Prefill 硬件归因后， 固定其余环境，快速比较 0/1/2，不能仅凭双 Rail 拓扑判断最优值。

1. 分别执行相同消息范围的 all_reduce_perf，每个值至少重复 3 次，检查错误、algbw 和 busbw。
2. 通过 NCCL 调试日志及两端 NIC 计数器确认实际 mlx5_0/mlx5_3 映射、双 Rail 使用率和流量均衡。
3. 每个值重启同配置 SGLang 服务，仅重放一个 Decode 高并发代表点，比较 Output TPS、TPOT P95 与稳定性。
4. 先排除不正确或不稳定的值，再比较 NCCL 中位带宽，最终以 SGLang 端到端结果决定生产值。

6.5 与其他阶段的组合边界

• Phase 1 保留一份不启用 Profiler 的端到端基线，避免 TPS 和时延被诊断工具污染。
• GPU、CPU 和网络的轻量采样可以伴随后续基线运行，但必须从 Case 开始前启动，并使用统一时间戳与 Case ID 对齐。
• Phase 1 已提前结束，不把中途人工观察到的 GPU 数值伪装成完整硬件时间序列。
• Phase 2 首轮独立重放 32K Prefill 并完整采集轻量指标；得到瓶颈方向后，再决定是否把 Phase 2 指标与 Phase 3 的短时间线放在同一诊断 Run。
• 联合诊断 Run 的吞吐和时延只用于解释时间线；正式性能变化仍与 Phase 1 的无 Profiler 结果比较。

7. Phase 3：时间线 Profiling（Nsight Systems 为主）

Nsight Systems、PyTorch Profiler 和 NVTX 是三件不同的东西：Nsight Systems 记录系统级 CUDA/NCCL/CPU 时间线；PyTorch Profiler 由框架接口触发； NVTX 只是在时间线上添加可读标记。启用 NVTX 不等于已经启动 Nsight。

7.1 捕获策略

• 只捕获预热后的 5 到 10 个 Engine Step。
• Prefill、Decode 和混合干扰分别生成报告。
• 两台机器分别保存原始报告。
• 优先保留所有 Rank；文件过大时至少保留代表 Rank 和跨机通信相关 Rank。
• 报告必须和对应 Benchmark Case ID 绑定。

7.2 vLLM

当前版本支持时，使用 CUDA Profiler 动态 Capture：

export VLLM_WORKER_MULTIPROC_METHOD=spawn

nsys profile \
  --trace=cuda,nvtx,nccl \
  --trace-fork-before-exec=true \
  --cuda-graph-trace=node \
  --capture-range=cudaProfilerApi \
  --capture-range-end=repeat \
  -o /data/profile/dsv4_tp16 \
  vllm serve ... \
  --profiler-config.profiler cuda

压测端使用支持 Profile Trigger 的 Bench：

vllm bench serve ... --profile

7.3 SGLang

以下 SGLANG_TORCH_PROFILER_DIR 与 /start_profile 属于 SGLang 的 PyTorch Profiler 路径，可用于框架级时间线，但不能把生成物 称为 Nsight Systems 报告。

服务启动前设置：

export SGLANG_TORCH_PROFILER_DIR=/data/profile/sglang

Profiling 专用 Run 可增加：

--enable-layerwise-nvtx-marker

捕获预热后的 10 个 Step：

curl -X POST http://127.0.0.1:30000/start_profile \
  -H 'Content-Type: application/json' \
  -d '{
    "output_dir": "/data/profile/sglang",
    "start_step": 5,
    "num_steps": 10,
    "activities": ["CPU", "GPU"]
  }'

多机 Trace 自动合并要求两台机器能访问同一个共享输出目录。没有共享目录时分别保存，再在本地汇总。

真正的 Nsight Systems Run 需要在两台节点分别由 nsys 捕获对应 SGLang 进程，并绑定相同 Case ID 和时间窗口。正式执行前先验证容器内外的 nsys 版本、子进程跟踪方式及动态 Capture 机制，再固化命令； 不直接对整轮 Benchmark 做长时间全量捕获。

7.4 时间线必须回答的问题

1. Prefill 和 Decode 各自的 Top Kernel 是什么？
2. NCCL 在关键路径上的暴露时间是多少？
3. 通信与计算重叠了多少？
4. 每层之间是否存在 CPU 或同步空洞？
5. CUDA Graph 是否覆盖常见 Decode Batch？
6. 16 个 Rank 是否同时结束？
7. 是否存在固定慢 Rank？
8. MoE Expert Token 是否严重不均衡？
9. NSA Indexer 的成本占 Sparse Attention 总成本多少？
10. 长 Prefill 到来时，Decode Kernel 为什么被延迟？

7.5 报告分析

nsys stats <REPORT>.nsys-rep

重点查看：

• CUDA GPU Kernel Summary。
• NCCL Summary。
• NCCL GPU Time Utilization。
• Communication/Compute Overlap。
• NCCL Straggler。
• CUDA API Summary。
• OS Runtime 和 CPU Thread Timeline。

8. 证据到优化方向的映射

9. Phase 4：优先级最高的拓扑实验

9.1 A：TP16 基线

当前方案用于建立所有后续实验的对照。

风险是每层 TP Collective 都可能跨越两台机器，Decode 小消息通信尤其容易被延迟支配。

9.2 B：TP8 + PP2

逻辑上：

Node 5: Pipeline Stage 0, TP8
Node 7: Pipeline Stage 1, TP8

理想情况下，每卡权重占用与 TP16 接近：

TP16:
  每卡权重约为 W / 16

TP8 + PP2:
  每个 Stage 保存 W / 2
  Stage 内由 8 卡切分
  每卡权重约为 (W / 2) / 8 = W / 16

潜在收益：

• 每层 TP Collective 留在单机。
• 跨机主要传输 Pipeline Stage 边界激活。
• 避免每层都进行跨机 AllReduce。

潜在代价：

• Pipeline Bubble。
• 低并发延迟可能变差。
• KV Cache、Hybrid Cache 和 DSV4-Pro 模型实现可能暂不支持 PP。
• 两个 Stage 的计算量可能不均衡。

测试顺序：

1. 先做加载与单请求 Smoke Test。
2. 对比 C=1 Decode 延迟。
3. 对比 C=16/32/64 吞吐。
4. 观察跨机网络流量是否显著下降。
5. 观察两个 Pipeline Stage 是否负载均衡。

9.3 C：Attention TP8/DP2 + MoE EP16

目标是：

• Attention 在节点内使用 TP8。
• 两个 Attention DP Group 并行处理请求。
• MoE Expert 在 16 张卡上分布。

这接近“Attention DP + MoE EP”的思路。Expert 权重通常占模型大头，因此即使 Attention 权重复制两份，也有机会放入显存。

必须先验证：

• 当前 vLLM/SGLang 版本是否支持 DSV4-Pro 的该拓扑。
• Expert 权重、非 Expert 权重和 KV Cache 的实际显存占用。
• All-to-All 是否比当前 TP16 AllReduce 更划算。
• Expert 负载是否均衡。

10. Phase 5：通信专项

10.1 不只测 1 GiB 大消息

之前的 1 GiB all_reduce_perf 主要说明大消息带宽。Decode 中的 Collective 往往更小，可能由延迟主导。

需要覆盖真实消息尺度：

all_reduce_perf -b 8K -e 64M -f 2 -g 8
all_gather_perf -b 8K -e 64M -f 2 -g 8
reduce_scatter_perf -b 8K -e 64M -f 2 -g 8

若启用 EP，还要测试 All-to-All。

10.2 通信优化顺序

1. 确认两条 Rail 都在工作。
2. 确认 Rank、GPU、NIC 和 NUMA Affinity。
3. 对照实际模型消息大小。
4. 查看 NCCL 自动选择的 Algorithm、Protocol 和 Channel。
5. 只有自动选择明显不合理时，才 A/B Ring/Tree、Simple/LL128 等设置。
6. 观察模型端到端结果，而不只看 nccl-tests 峰值。

11. Phase 6：Kernel 专项

从 Nsight Systems 中选累计占关键路径最高的 1 到 3 个 Kernel，再使用 Nsight Compute。

DSV4-Pro 的优先怀疑对象：

• NSA Indexer/Top-K。
• Sparse MLA/Attention Prefill。
• Sparse MLA/Attention Decode。
• MoE Gate、Dispatch、Grouped GEMM、Combine。
• FP8 Quant/Dequant 与 Scale Packing。
• RMSNorm、Rope、KV Cache Store 等碎片化小算子。
• NCCL Collective Kernel。

需要分析：

• SM 和 Tensor Core 利用率。
• DRAM 吞吐与 L2 Hit Rate。
• Occupancy。
• Register 与 Shared Memory 压力。
• Warp Stall 原因。
• Kernel Shape 与 Batch/Token 数。
• 小 Kernel Launch 次数。

优化优先顺序：

1. 切换已有高性能 Backend。
2. 调整 Backend 的 Shape/Workspace/Tile 配置。
3. 消除无用 Copy、Cast 和临时 Tensor。
4. 融合相邻的 Memory-bound 小算子。
5. 现有 Backend 不覆盖关键 Shape 时，再开发新 Kernel 或提交 PR。

12. Phase 7：Scheduler 与统一实例干扰

12.1 混合干扰实验

先建立稳定 Decode 背景流量：

ISL=1K
OSL=1K
C=32

运行稳定后，周期性注入一个长 Prefill：

ISL=128K
OSL=1
C=1

比较注入前后：

• Decode P50/P95/P99 TPOT。
• Decode Output TPS。
• 长请求 TTFT。
• 每轮 Prefill Chunk。
• Scheduler Queue。
• GPU Timeline。

12.2 可调方向

• Chunked Prefill Size。
• Max Prefill Tokens。
• Max Batched Tokens。
• Max Running Requests/Max Num Seqs。
• Prefill 与 Decode 调度优先级。
• CUDA Graph Batch Coverage。
• 双 Batch Overlap 或框架已有的通算重叠能力。

调优目标不是单独最大化 Prefill TPS，而是减少长 Prefill 对 Decode SLO 的破坏。

13. Phase 8：显存与缓存

当前初始值应保持固定，只在发现明确证据后调整：

• GPU Memory Fraction。
• Max Context Length。
• Active Request Limit。
• KV Cache Dtype。
• Page/Block Size。
• CUDA Graph Capture Size。

若 KV Cache 是瓶颈，优先顺序：

1. 确认权重和 Workspace 的真实占用。
2. 检查 Allocated/Reserved 差值与碎片。
3. 使用 FP8 KV Cache，前提是当前 Kernel 支持且精度可接受。
4. 根据业务上限设置 Context Length，不为不会出现的极端长度预留容量。
5. 设置合理的 Active Request Limit，避免运行时 OOM。
6. 再考虑 CPU/L3 KV Offload。

Prefix Cache 单独做第二阶段测试：

Mooncake 或三级缓存只有在 Prefix 可复用时才有明显价值。随机独立 Prompt 不适合评价它。

14. Phase 9：MTP 与模型级优化

当 TP16 Baseline、并行拓扑、通信、Backend 和 Scheduler 已稳定后，再测试：

• 原生 MTP。
• DSpark。
• EAGLE。
• KV Cache 量化。
• 更低比特权重量化。
• Sparse Attention 算法或 Indexer 优化。

投机解码至少记录：

• Accept Rate。
• Mean Accept Length。
• Target Forward TPS。
• Draft/MTP 开销。
• CPU 调度气泡。
• 不同并发下的净收益。

不能只看 Accept Length，也不能只看 C=1。

15. 里程碑与交付物

M1：可信 Baseline

完成条件：

• 九个固定快速地图点与混合干扰 A/B 均完成；里程碑版本各有 3 次重复。
• 同一 Case 的关键 TPS 变异系数尽量不超过 3%。
• 所有环境、命令和日志可追溯。

交付：

• Baseline Summary。
• SLO Frontier。
• GPU/CPU/Network Timeline。

M2：瓶颈报告

完成条件：

• Prefill、Decode、混合三类 Profile 完成。
• 找出累计贡献最高的 1 到 3 个瓶颈。
• 每个判断都有 Trace、计数器或日志证据。

交付：

• .nsys-rep 或 Torch Trace。
• Kernel/NCCL Summary。
• Bottleneck Evidence Table。

M3：并行拓扑 A/B

完成条件：

• TP16 保留基线。
• TP8+PP2 完成可行性与性能验证。
• Attention DP + MoE EP 完成支持性和显存评估。

交付：

• 每种拓扑的显存、通信、TTFT、TPOT 和 TPS 对比。
• 推荐拓扑与不推荐拓扑的证据。

M4：首轮优化闭环

完成条件：

• 至少一项优化通过完整 Benchmark。
• 结果在无 Profiler 环境下可复现。
• 正确性无回归。
• 满足 SLO 的吞吐有明确改善。

期望目标：

• 首轮争取获得至少 10% 的 SLO 内吞吐提升，或显著降低 P95/P99 长尾。
• 若无法提升，也必须形成排除结论，说明瓶颈为什么不在该方向。

16. 实验纪律

每次实验都必须回答：

1. 改了什么？
2. 为什么认为它会影响当前瓶颈？
3. 除该变量外，还有什么发生了变化？
4. 端到端指标如何变化？
5. Profile 证据如何变化？
6. 是否引入精度、稳定性或显存风险？
7. 是否值得保留？

禁止以下做法：

• 同时修改多个参数后只报告最终 TPS。
• 用 Profiling Run 和普通 Run 直接比较性能。
• 只看平均值，不看 P95/P99。
• 用配置 ISL/OSL 估算 TPS，而不核对实际 token 数。
• 用 1 GiB NCCL 带宽代表 Decode 小消息性能。
• 因单个 Kernel 更快就宣称端到端优化成功。
• OOM 后不重启服务继续测试。

17. 首轮执行建议

建议直接按以下顺序推进：

1. 固化当前 TP16 服务命令和 Manifest。
2. 先跑九个固定快速地图点，再跑 Decode 背景中注入 128K Prefill 的混合干扰 A/B。
3. 同步采集 GPU、CPU 和双 Rail 数据。
4. 对 P3、D2、M1 各捕获 5 到 10 个 Engine Step。
5. 输出 NCCL、NSA/Attention、MoE、CPU Gap 四项时间占比。
6. 根据最大暴露时间选择第一个优化方向。
7. 优先做 TP16 与 TP8+PP2 的可行性和性能对比。
8. 回到完整 Benchmark 验证 SLO 内吞吐。

最重要的判定标准是：

优化暴露在关键路径上的时间，而不是只优化看起来最慢的单个算子。

18. 参考资料

• vLLM Profiling
• SGLang Benchmark and Profiling
• SGLang Server Arguments
• NVIDIA Nsight Systems User Guide
• NVIDIA Nsight Systems Analysis Guide
• 腾讯混元 Hy3 Preview AI Infra 精读笔记