record max batched tokens 8192 experiment

worklogs/decode_analysis_report_2026-07-14.md

@@ -1146,3 +1146,51 @@ _PROF_TRACE = os.environ.get("PROF_TRACE", "0") == "1"
 ### 结论
 
 32768 可以启动，但没有带来总体收益；Output TPS P10 略升，TTFT 继续变差，综合吞吐仍低于原 100K 基线。单纯扩大 chunk 不是主优化方向。下一步尝试 8192，验证更小 chunk 是否能改善 TTFT。
+
+## 2026-07-15：max_num_batched_tokens=8192 实验
+
+### 流程改进
+
+新增可复用远端实验脚本：
+
+- `worklogs/remote_scripts/run_batched_tokens_experiment.sh`
+
+脚本负责：
+
+- 停止旧 `api_server`；
+- 检查启动前 GPU 显存；
+- 按指定 `max_num_batched_tokens` 启动 100K/no-prof 服务；
+- 等待 `/health`；
+- 运行 8 请求官方相似压测；
+- 写入 `driver.log`、`server.log` 和结果 JSON。
+
+这能减少超长 SSH 命令导致的本地 PowerShell/SSH 子进程异常，也让后续实验日志格式统一。
+
+### 结果
+
+本地归档：
+
+- `worklogs/remote_results/2026-07-15-official-like-baseline/eager_100k_b8192_c1_r8_t256_cap40k.json`
+- `worklogs/remote_results/2026-07-15-official-like-baseline/driver_b8192.log`
+
+| 指标 | 100K 基线 | no-prof 8192 | no-prof 16384 | no-prof 32768 | 目标 |
+| --- | ---: | ---: | ---: | ---: | ---: |
+| Success Rate | 100.00% | 100.00% | 100.00% | 100.00% | >= 99% |
+| Cache Hit Rate | 74.17% | 74.17% | 74.17% | 74.17% | >= 50% |
+| TTFT P90 | 9.803s | 13.996s | 12.739s | 13.005s | <= 5s |
+| Output TPS P10 | 5.825 | 5.840 | 5.851 | 5.895 | >= 20 |
+| Aggregate Output TPS | 5.789 | 5.513 | 5.674 | 5.556 | - |
+| Uncached Input TPS | 178.330 | 168.408 | 169.148 | 173.430 | - |
+| Cache TPS | 512.015 | 483.527 | 485.652 | 497.947 | - |
+| Weighted Throughput | 883.109 | 834.751 | 840.712 | 857.595 | >= 8000 |
+
+### 结论
+
+8192 没有改善 TTFT，反而是本轮 chunk 参数中最弱。8192/16384/32768 三组的 Output TPS P10 都约 5.8-5.9，差别很小，说明当前目标瓶颈不是 chunk 大小，而是 decode 每 token 的层内计算/通信周期，以及长上下文 prefill/cache 路径的底层吞吐。
+
+下一轮方向：
+
+1. 对 decode 稳态做低开销 profiling，只记录少量聚合计时，避免 `PROF_TRACE` 每层每 token 打日志。
+2. 拆分 `MLP` 时间中 routed expert、shared expert、TP all-reduce 的占比。
+3. 若 all-reduce 占比高，测试 `--disable-custom-all-reduce` 保持关闭/打开的差异和 TP 通信路径。
+4. 若 routed expert 占比高，继续优化 `_native_experts_sorted` 中逐 expert 循环和 `index_add_`。