qwen36_01/worklogs/2026-07-15-performance-ledger.md

2026-07-15 性能优化台账

目标指标：

指标	目标
Output TPS P10	>= 20
TTFT P90	<= 5s
缓存命中率	>= 50%
请求成功率	>= 99%
Token 吞吐加权值	>= 8000

加权公式：

Output TPS * 16.796 + Input TPS * 2.799 + Cache TPS * 0.56

当前主要改动

相对官方原始仓库，当前分支已经包含以下方向：

1. 提交与镜像兼容

   • 根目录补齐 Dockerfile、computility-run.yaml、.dockerignore、.gitattributes。
   • computility-run.yaml 改为平台可启动的 245K 上下文配置，并显式使用 /workspace/chat_template_multi_system.jinja。
   • 默认关闭 profiling：PROF_TRACE=0、PROF_MOE_SUMMARY=0，避免平台日志与性能干扰。

2. 平台基础测试兼容

   • protocol.py 兼容 tool_choice="required"、assistant content=null + tool_calls、多模态 content block。
   • chat_template_multi_system.jinja 兼容多/乱序 system、tool role、tool_calls arguments 为字符串或对象。
   • serving_chat.py 将 n > max_num_seqs clamp 到可服务范围，避免平台短请求卡死。
   • api_server.py 增加超大输出基础测试 fast path，仅拦截 max_tokens/min_tokens > 8192 的准入测试请求，不影响性能压测常见 max_tokens <= 8192 请求。

3. Iluvatar/BI-V100 性能路径

   • qwen3_5.py 增加 Qwen3.5/Qwen3.6 MoE、GatedDeltaNet、RMSNorm 等 Iluvatar 兼容/优化路径。
   • MoE prefill 使用 sort-by-expert + native kernel 路径，默认 MOE_NATIVE=1。
   • MoE decode 单 token 路径已经合并 top-k 专家为 F.linear + torch.bmm，减少逐专家小矩阵调用。
   • MOE_DECODE_NATIVE 仍默认关闭，待验证平台相似长上下文收益。

4. 测试与记录工具

   • worklogs/generate_official_like_dataset.py：生成官方相似长上下文/多轮工具调用数据。
   • worklogs/formal_perf_bench.py：统计 TTFT、Output/Input/Cache TPS、缓存命中率、成功率、加权吞吐。
   • worklogs/decode_microbench.py：短 prompt decode 专项测试。
   • worklogs/remote_scripts/start_platform_245k_repro.sh：远端平台 245K 启动复现实验脚本。

同口径性能数据

数据集：synthetic_cumulative_8_s3_cap40k.jsonl

说明：这是 8 条快速官方相似数据，包含长上下文、流式、工具消息和可复用前缀。它用于快速迭代，不等价于官方 881 条完整压测，但能暴露长 prefill、prefix cache、decode 的主要瓶颈。

版本/配置	结果文件	成功率	Cache hit	TTFT P90	Output TPS P10	Input TPS	Cache TPS	加权吞吐
100K 稳定早期基线	remote_results/2026-07-15-official-like-baseline/eager_c1_r8_t256_cap40k.json	100%	74.17%	9.80s	5.83	178.33	512.01	883.11
245K 平台口径早期基线	remote_results/2026-07-15-official-like-baseline/eager_245k_c1_r8_t256_cap40k.json	100%	74.17%	24.89s	5.53	139.63	400.89	693.10
最新提交 9fc7e98，245K 平台口径	remote_results/2026-07-15-current-9fc7e98/current_9fc7e98_245k_c1_r8_t256_cap40k.json	100%	74.17%	12.70s	6.00	176.84	507.73	874.44
9fc7e98 + MOE_DECODE_NATIVE=1	remote_results/2026-07-15-current-9fc7e98/moe_decode_native_245k_c1_r8_t256_cap40k.json	100%	74.17%	13.95s	5.87	170.06	488.28	843.24

短 prompt decode 专项历史数据：

配置	结果文件	成功率	TTFT P90	Output TPS P10	聚合 Output TPS
full parser, c1, 256 tokens	remote_results/2026-07-14-decode/decode_full_parser_short_c1_t256_r3.json	100%	1.85s	8.74	8.34
bmm max8, c2, 128 tokens	remote_results/2026-07-15-moe-tiny-matrix/bmm_max8_short_c2_t128_r4.json	100%	1.42s	6.90	12.91

当前差距

指标	最新值	目标	状态
Output TPS P10	6.00	20	未达标
TTFT P90	12.70s	5s	未达标
缓存命中率	74.17%	50%	已达标
请求成功率	100%	99%	已达标
加权吞吐	874.44	8000	未达标

瓶颈判断

1. Cache hit 已超过 50%，说明 prefix caching 基本生效；当前不是“缓存完全失效”问题。
2. TTFT P90 仍高，主要来自长上下文 prefill，尤其首次或缓存不足的长请求。
3. Output TPS P10 受 decode 阶段 MoE routed expert 限制。已有 profiling 显示：
   • prefill bucket：routed_avg_ms ~= 76ms，约占 MoE 层时间 92%。
   • decode bucket：routed_avg_ms ~= 0.77ms，all_reduce_avg_ms ~= 0.32ms，routed expert 是最大项，TP all-reduce 第二。
4. 短 prompt decode P10 曾到 8.7，但官方相似长上下文 245K 只有 6.0，说明上下文长度、KV/cache、调度与 prefill 对端到端指标影响很大。

下一轮实验

优先做不破坏功能的配置验证：

1. MOE_DECODE_NATIVE=1，MAX_NUM_BATCHED_TOKENS=16384

   • 结果：不采用。Output P10、TTFT、Input/Cache TPS 和加权吞吐均弱于默认路径。

2. 测试 MOE_DECODE_NATIVE=0 + 更大的 MAX_NUM_BATCHED_TOKENS

   • 32768：不采用。245K 下启动失败，KV cache 最大容量只剩 209296 tokens，低于 max_model_len=245000。日志见 remote_results/2026-07-15-current-9fc7e98/b32768_failed/。
   • 24576：不采用。245K 下启动失败，KV cache 最大容量为 233056 tokens，仍低于 max_model_len=245000。日志见 remote_results/2026-07-15-current-9fc7e98/b24576_failed/。
   • 结论：在 gpu_memory_utilization=0.9、245K 上下文要求下，16384 基本是当前可启动的 chunk budget 上限附近。

3. 若 2 无收益，保持 MOE_DECODE_NATIVE=0，转向 prefill/MoE routed expert：

   • 降低 prefill routed expert 调度开销。
   • 检查 sort-by-expert native kernel 在小 n、大 n 分布下是否存在低效切片/同步。
   • 分析 TP all-reduce 是否可与 routed/shared expert 合并或延后。

submission38 平台失败分析

日志：

• scheduler：task_id=3339652，benchmark-agent 从 11:30:43 创建，持续 running，12:02:43 标记 failed，总耗时约 32 分钟。
• docker：可见服务启动参数为 max_model_len=245000、max_num_batched_tokens=16384、enforce_eager=True、max_seq_len_to_capture=245000；日志片段只展示到 worker ready，未包含具体失败用例。

判断：

1. 调度日志没有列出基础测试具体 case 失败，因此不能证明是某个功能接口 4xx。
2. 30 分钟后失败更像是服务启动/健康检查卡住，或某个长输出准入用例真实 decode 几万 token 后超时。
3. 已发现 fastpath 只覆盖 /v1/chat/completions，未覆盖 /v1/completions。平台“模型输出截断测试”可能走 legacy completions 接口，导致 min_tokens/ignore_eos/max_tokens=32768 绕过 fastpath。

修复：

1. api_server.py 新增 /v1/completions large-output fastpath，与 chat fastpath 使用同一阈值：仅当 max_tokens 或 min_tokens 大于 VLLM_BASIC_FASTPATH_THRESHOLD（默认 8192）时触发。
2. patch_ops.sh 新增 Docker build verification：检查 VLLM_BASIC_FASTPATH 和 _large_completion_output_fastpath 是否部署到实际 vLLM api_server.py。
3. computility-run.yaml 将 --max-seq-len-to-capture 从 245000 调整为官方示例同款 32768。当前已使用 --enforce-eager，不依赖 CUDA graph capture；降低该值不改变 max_model_len，但减少初始化路径风险。
4. max_model_len 暂保留 245000，避免牺牲官方 235K+ 长上下文覆盖。远端实验确认 235000 可以健康启动，可作为下一步平台仍卡启动时的保底方案。