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
当前执行状态与阶段档案
+| 工作项 | +状态 | +实现与结果档案 | +
|---|---|---|
| DeepSeek-V4-Pro / 双机 Pro6000D / SGLang TP16 快速性能地图 | +提前结束；3 个冷 Prefill 点完成，输入吞吐稳定约 65 token/s；旧脚本缓存口径审计已完成 | +打开实施记录 | +
| DeepSeek-V4-Pro / 双机 Pro6000D / SGLang Prefill 硬件指标归因 | +设计已固化；代码尚未开始 | +打开 Phase 2 档案 | +
1. 目标与原则
+1.1 最终目标
+在不做 PD 分离的前提下，定位 DeepSeek-V4-Pro 在双机 6000D 上的端到端瓶颈，并提高：
+-
+
- 满足 TTFT、TPOT 等 SLO 时的最大吞吐。 +
- 长上下文 Prefill 性能。 +
- Decode 输出吞吐和单请求 TPOT。 +
- 混合流量下的稳定性与 P95/P99 时延。 +
- 16 张 GPU、PCIe 和双 Rail 计算网的有效利用率。 +
1.2 核心原则
+-
+
- 先找关键路径，再调参数。 +
- 先用端到端指标确认问题，再用 Timeline 找到阶段，最后才用 Kernel Profiler。 +
- Prefill、Decode 和混合干扰必须分别测试。 +
- 一次只改变一个变量，每项优化都要保留可复现的 A/B 结果。 +
- 单算子更快不代表服务吞吐更高，最终结论必须回到真实请求和 SLO。 +
- Profiling Run 只用于定位，不能与无 Profiler 的正式性能结果直接比较。 +
2. 当前最值得验证的瓶颈假设
+| 编号 | +假设 | +为什么值得优先检查 | +
|---|---|---|
| H1 | +TP16 每层跨机通信暴露过多 | +两台机器没有跨机 NVLink，TP Collective 需要经过 RoCE | +
| H2 | +NSA Indexer 或 Sparse Attention Kernel 效率不足 | +DSV4-Pro 的稀疏注意力路径复杂，Indexer 可能抵消稀疏收益 | +
| H3 | +MoE Grouped GEMM 或路由负载不均 | +Decode 小 Batch 容易 Memory-bound，热门专家可能制造慢 Rank | +
| H4 | +长 Prefill 干扰在线 Decode | +统一实例中 Prefill 与 Decode 竞争计算、显存带宽和调度预算 | +
| H5 | +CPU Scheduler、Metadata 或 Kernel Launch 产生 GPU 空洞 | +小 Batch Decode 对 CPU 和 Launch 开销特别敏感 | +
| H6 | +KV Cache 容量、碎片或 Preemption 限制并发 | +大模型权重占用高，剩余 HBM 决定上下文与并发容量 | +
| H7 | +当前并行拓扑并非最优 | +使用 16 张卡不等于只能采用单一 TP16 拓扑 | +
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 当前固定快速矩阵
+| Case ID | +ISL | +OSL | +并发 | +主要目标 | +
|---|---|---|---|---|
short_prefill_latency_1k_c1 |
+1K | +1 | +1 | +固定开销与最小 TTFT | +
mid_prefill_latency_32k_c1 |
+32K | +1 | +1 | +NSA、Indexer、Attention | +
long_prefill_latency_128k_c1 |
+128K | +1 | +1 | +长上下文计算和显存压力 | +
mid_prefill_throughput_32k_c16 |
+32K | +1 | +16 | +Chunked Prefill 与输入 TPS | +
decode_latency_1k_to_1k_c1 |
+1K | +1K | +1 | +单请求 TPOT | +
decode_throughput_1k_to_1k_c16 |
+1K | +1K | +16 | +MoE、Batch 与通信 | +
decode_throughput_1k_to_1k_c32 |
+1K | +1K | +32 | +Decode 吞吐 | +
decode_throughput_1k_to_1k_c64 |
+1K | +1K | +64 | +Decode 高并发吞吐 | +
balanced_32k_to_1k_c8 |
+32K | +1K | +8 | +Prefill 与 Decode 综合压力 | +
长度应以当前已验证的服务容量为上限。如果 128K 不可用，先降到 64K，但必须在 Manifest 中记录原因。
+5.2 混合干扰 A/B
+-
+
- 先运行有限的
1K → 1K, C=32Decode 对照流量。
+ - 再次运行相同 Decode 基准流量，并等待 Benchmark 确认进入正式测量。 +
- 正式测量开始 10 秒后注入一个
128K → 1, C=1长 Prefill；不额外执行 128K Warm-up。
+ - 比较 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 拓扑判断最优值。
+
-
+
- 分别执行相同消息范围的
all_reduce_perf，每个值至少重复 3 次，检查错误、algbw 和 busbw。
+ - 通过 NCCL 调试日志及两端 NIC 计数器确认实际
mlx5_0/mlx5_3映射、双 Rail 使用率和流量均衡。
+ - 每个值重启同配置 SGLang 服务，仅重放一个 Decode 高并发代表点，比较 Output TPS、TPOT P95 与稳定性。 +
- 先排除不正确或不稳定的值，再比较 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 时间线必须回答的问题
+-
+
- Prefill 和 Decode 各自的 Top Kernel 是什么？ +
- NCCL 在关键路径上的暴露时间是多少？ +
- 通信与计算重叠了多少？ +
- 每层之间是否存在 CPU 或同步空洞？ +
- CUDA Graph 是否覆盖常见 Decode Batch？ +
- 16 个 Rank 是否同时结束？ +
- 是否存在固定慢 Rank？ +
- MoE Expert Token 是否严重不均衡？ +
- NSA Indexer 的成本占 Sparse Attention 总成本多少？ +
- 长 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. 证据到优化方向的映射
+| 观察到的证据 | +更可能的根因 | +下一项 A/B | +
|---|---|---|
| Decode 中 NCCL 占比高，且通信未被计算覆盖 | +TP16 通信受限 | +TP8+PP2、NCCL 拓扑与算法 | +
| C=1 很慢，并发增加后 TPS 明显改善 | +MoE/权重读取 Memory-bound | +Batch、MoE Backend、MTP | +
| GPU 利用率呈锯齿，Kernel 间有明显空洞 | +CPU Scheduler 或 Launch 开销 | +CUDA Graph、异步调度 | +
| 一个或少数 Rank 长期最慢 | +Expert、NIC 或 NUMA 不均衡 | +EPLB、Affinity、Rank Mapping | +
| NSA Indexer 时间接近或超过 Attention | +稀疏索引收益不足 | +Indexer Backend、Top-K、融合 | +
| 长 ISL 的 Attention 时间异常增长 | +Prefill Kernel 或 Chunking 问题 | +Prefill Backend、Chunk Size | +
| KV Cache 长期接近满并发生重算 | +HBM 容量不足 | +FP8 KV、并发和 Context 上限 | +
| 注入长 Prefill 后 Decode TPOT 暴涨 | +Prefill/Decode 相互干扰 | +Chunked Prefill 与 Scheduler | +
| GPU 利用率低但 CPU 单核满载 | +Host 端瓶颈 | +Frontend、Tokenizer、Scheduler | +
| 两条 Rail 流量明显不均 | +NIC Mapping 或 NCCL 拓扑 | +HCA、CROSS_NIC、NUMA Affinity | +
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 的计算量可能不均衡。 +
测试顺序：
+-
+
- 先做加载与单请求 Smoke Test。 +
- 对比 C=1 Decode 延迟。 +
- 对比 C=16/32/64 吞吐。 +
- 观察跨机网络流量是否显著下降。 +
- 观察两个 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 通信优化顺序
+-
+
- 确认两条 Rail 都在工作。 +
- 确认 Rank、GPU、NIC 和 NUMA Affinity。 +
- 对照实际模型消息大小。 +
- 查看 NCCL 自动选择的 Algorithm、Protocol 和 Channel。 +
- 只有自动选择明显不合理时，才 A/B
Ring/Tree、Simple/LL128等设置。
+ - 观察模型端到端结果，而不只看 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 次数。 +
优化优先顺序：
+-
+
- 切换已有高性能 Backend。 +
- 调整 Backend 的 Shape/Workspace/Tile 配置。 +
- 消除无用 Copy、Cast 和临时 Tensor。 +
- 融合相邻的 Memory-bound 小算子。 +
- 现有 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 是瓶颈，优先顺序：
+-
+
- 确认权重和 Workspace 的真实占用。 +
- 检查 Allocated/Reserved 差值与碎片。 +
- 使用 FP8 KV Cache，前提是当前 Kernel 支持且精度可接受。 +
- 根据业务上限设置 Context Length，不为不会出现的极端长度预留容量。 +
- 设置合理的 Active Request Limit，避免运行时 OOM。 +
- 再考虑 CPU/L3 KV Offload。 +
Prefix Cache 单独做第二阶段测试：
+| 命中率 | +用途 | +
|---|---|
| 0% | +纯计算基线 | +
| 20% | +低复用业务 | +
| 50% | +中等公共前缀 | +
| 80% | +Agent/Coding 高复用 | +
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. 实验纪律
+每次实验都必须回答：
+-
+
- 改了什么？ +
- 为什么认为它会影响当前瓶颈？ +
- 除该变量外，还有什么发生了变化？ +
- 端到端指标如何变化？ +
- Profile 证据如何变化？ +
- 是否引入精度、稳定性或显存风险？ +
- 是否值得保留？ +
禁止以下做法：
+-
+
- 同时修改多个参数后只报告最终 TPS。 +
- 用 Profiling Run 和普通 Run 直接比较性能。 +
- 只看平均值，不看 P95/P99。 +
- 用配置 ISL/OSL 估算 TPS，而不核对实际 token 数。 +
- 用 1 GiB NCCL 带宽代表 Decode 小消息性能。 +
- 因单个 Kernel 更快就宣称端到端优化成功。 +
- OOM 后不重启服务继续测试。 +
17. 首轮执行建议
+建议直接按以下顺序推进：
+-
+
- 固化当前 TP16 服务命令和 Manifest。 +
- 先跑九个固定快速地图点，再跑 Decode 背景中注入 128K Prefill 的混合干扰 A/B。 +
- 同步采集 GPU、CPU 和双 Rail 数据。 +
- 对 P3、D2、M1 各捕获 5 到 10 个 Engine Step。 +
- 输出 NCCL、NSA/Attention、MoE、CPU Gap 四项时间占比。 +
- 根据最大暴露时间选择第一个优化方向。 +
- 优先做 TP16 与 TP8+PP2 的可行性和性能对比。 +
- 回到完整 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 精读笔记 +