119 lines
7.6 KiB
Markdown
119 lines
7.6 KiB
Markdown
# 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` 可以健康启动，可作为下一步平台仍卡启动时的保底方案。
|