一页版。数据权威仍是 profiles/bench/SUMMARY.md；本笔记是给人看的摘要，不重复全部明细。
测量条件：2× Tesla V100-SXM2-16GB (TCC) / NVLink，artifact qwen3_8_27b_nvfp4.ninfer
（weights 20.92 GiB），--tp 2 --devices 0,1 --kv-dtype int8 --spec mtp --lm-head-draft --no-prefix-reuse，窗口 184,320（180k 那一点 192,512）。
所有速率来自 request_done.timings_seconds，不含任何采样窗口。
1. 一句话结论
prefill 有明确峰值，decode 没有。 prefill 峰值 1115 t/s @ P≈4k / chunk 4096；
decode 只能在「接受率」这个前提下标定，落在 74~146 t/s，150~187 只属于 100% 接受的合成负载。
2. 对外上报口径
| 负载 |
接受率 |
单请求 decode |
建议 draft window |
| 自由散文 / 创作 / 闲聊 |
~35% |
74~80 |
2 |
| 结构化 JSON / 代码 / 抽取 |
90100% |
142~146 |
3~5 |
| 重复枚举（合成/校验） |
100% |
150~187 |
5 |
- prefill：1115 t/s @ 4k / chunk 4096；报数必须带 P 和 chunk，否则 1115 与 694 会被当成同一指标。
- 并发 2：512 档 249.9、8k 档 238.5、32k 档 209.1（合计口径），只有 1.56~1.66×。
- 上下文上限：显式
--kv-capacity 时 192,512；193,536 起加载静默 fail-fast。
3. prefill（单调衰减，无第二峰）
| 实际 prompt |
chunk 1024 |
chunk 2048 |
chunk 4096 |
| ~2,048 |
999.3 |
1077.6 |
— |
| ~4,096 |
1002.6 |
1080.2 |
1115.0 |
| ~8,192 |
1000.1 |
1074.2 |
1108.6 |
| ~32,768 |
939.4 |
998.5 |
1027.3 |
| 65,536 |
— |
912.1 |
— |
| 131,131 |
— |
771.3 |
— |
| 180,252 |
— |
693.7 |
— |
- chunk 4096 比 2048 高约 3%（4k/8k/32k 三点一致）；2048 比 1024 高约 8%。
- 相对 4k 峰值：32k −7.6%、65k −15.6%、131k −28.6%、180k −35.8%。
--draft-tokens 不影响 prefill（65k 处 k=5 与 k=3 差 0.6%，在重复测量噪声内）。- 只有一条 prefill lane，并发不影响 prefill。
4. decode（先看接受率）
| draft |
负载 |
接受率 |
ctx 512 |
ctx 8k |
| k=0 |
枚举 |
— |
41.0 |
37.0 |
| k=2 |
枚举 |
100% |
118.3 |
114.6 |
| k=3 |
枚举 |
100% |
150.6 |
145.5 |
| k=5 |
枚举 |
100% |
187.1 |
169.5 |
| k=2 |
散文 T0.7 |
52% |
80.5 |
77.4 |
| k=3 |
散文 T0.7 |
36% |
74.3 |
74.9 |
| k=5 |
散文 T0.7 |
23% |
69.9 |
— |
| k=3 |
JSON T0.7 |
94% |
145.8 |
141.8 |
逐位置接受率（speculative.accepted_per_position / 轮数）是解释一切的抓手：
- 散文：
67% / 30% / 12%（k=3）、67% / 37%（k=2）→ 第 3 位起基本白付 verify，k=2 最快。
- JSON：
100% / 94% / 89%（k=3）→ 到第 3 位仍高，k=3~5 都有收益。
每轮耗时反推：k=0 24.4 ms/token、k=2 25.4、k=3 26.6、k=5 32.1 ms/轮 ⇒ 每多一档 draft 约 +2.5~2.9 ms。
默认保持 --draft-tokens 3：散文端只损失 8%，结构化端比 k=2 高 23%；换自适应 k 的收益抵不上参数复杂度。
5. 并发 2
| prompt |
每路 |
合计 |
相对 2× |
| ~512 |
125.4 |
249.9 |
0.83× |
| ~8,192 |
119.2 |
238.5 |
0.80× |
| ~32,768 |
102.5 |
209.1 |
0.78× |
32k 那一点必须用长输出（6000 token）：prefill 串行，输出只有 512 时两路 decode 根本不重叠，
且第二路在 FIFO 里等 ~32 s 会撞默认 --pending-timeout-ms 直接 503。
6. 被推翻的旧结论（不要再引用）
| 旧说法 |
真因 |
| 带 draft 的上下文上限 155,648 |
--kv-capacity auto 按卡铺满 KV 池；显式 kv 时是 192,512 |
| decode 峰值 113.7 |
那批 prompt 写死 "Reply briefly"，4~7 token 就 EOS，测的是单轮 |
| 面板 peak prefill ≈2048 |
1 s 窗口下 chunk/1s 的量化假峰 |
| 真实文本 60~70% 接受 → 110~120 t/s |
外推。实测散文 36% 接受 → 74.3 |
| decode 峰值 150.6 |
那是 k=3 + 100% 接受的合成上限；散文 74.3、JSON 145.8、k=5 枚举 187.1 |
7. 为什么这次的数字可信
- 口径：
prefill = computed_prefill_tokens / timings.prefill、
decode = (completion_tokens−1) / timings.decode，分母是相位自己的墙钟，不掺采样窗口。
- 工具：
tools/bench/run_peak_sweep.py，每个 chunk 一个 server（执行图与显存计划启动固定），
每请求换 nonce 关掉前缀缓存，取重复测量的最大值（peak 而非 sustain）。
- 面板口径已修并验证：重链后的
/metrics 与 request_done 逐项对齐 ——
peak_prefill_tok_s 1081.27 vs 1081.27、peak_tok_s 150.76 vs 150.76、TTFT 到微秒一致；
history.prefill_tokens 记录的是原始计数 [2048, 0, 2001, 0]（4049 token 的 prompt），无 hold-over。
- 性能未变：新 exe 上 prefill 1081.3 / decode 150.76，与旧 exe 的 1080.2 / 150.6 一致
⇒ 上面的数字与 /metrics 改造无关。
8. 代码与坑
两个 commit：
ee8922b8 serve: report exact per-request rates and session peaks（20 文件）6fa85af4 bench: add the peak prefill and decode sweep（新增工具 + README）
/metrics 契约变化：history.prefill_tokens / decode_tokens / interval_seconds / cache_hit_tokens
取代 prefill_tok_s / tok_s / cpu_temp；last 增加 peak_prefill_tok_s / peak_tok_s；
新增 performance 段；hardware.gpus 移除。usage 增加 prompt_tokens_details.cached_tokens。
工程坑：
--kv-capacity auto 会按显存铺满池子，叠加 MTP 提案头后长上下文静默 fail-fast
（日志停在 loading model...，退出码 0xC0000409，无错误行）。/v1/responses 的 max_output_tokens 最小 16。- 测 decode 必须让模型持续输出，否则 EOS 后只剩一个 MTP round。
- 本沙箱跑不了
scripts\windows\build.cmd（vcvars 调 reg.exe，在黑名单里）；
绕法是 _scratch/ninja-env.sh 手工设 INCLUDE/LIB/PATH 后直接调 VS 自带 ninja。
build.ninja 被重新生成后第一次 ninja 是全量重编；构建与模型加载不能同时跑，
nvcc 吃内存会触发上面的静默 fail-fast。
9. 没做 / 不建议做
- 不做自适应 k：散文端 8% 的收益，不值得引入一个要解释的参数。
- 端到端（含前端、网络、tokenizer）吞吐未测；上面的数字是引擎相位速率。
- dflash2 当前 artifact 不支持（加载即 fail-fast）；换
Coder390-...-DFlash2.ninfer
是另一套权重，与全表不可比。