一、测试环境与口径

本版实测服务规格（读容器启动参数与引擎日志，不是抄配置文档）：

与上一版相比 KV 池从 12,715,913 → 11,434,628 tokens（15.89 → 14.23 GiB），1M 单请求并发余量 12.13 → 10.90 路。新镜像的显存切分略有变化，权重本身大小一致。

测量口径（与上一版一致，便于逐格对照）：

• 每档输出 128 tokens；填充文本带唯一 nonce + 递增编号，不命中 prefix 缓存；温度 0.6
• 单流 pp/tg = 各请求均值；聚合 pp = Σprompt / max(TTFT)；聚合 tg = Σcompletion / (max 总时长 − max TTFT)
• 并发 1 / 2 / 4 / 8（8 = max-num-seqs 上限），上下文档位 1K → 512K
• 本版改进了采样方式：≤64K 各档每点跑 3 次取中位，因为发现每轮第一笔请求有约 2.2 秒冷启开销（稳态仅 0.98 秒，8 次连测标准差 0.01）；≥128K 各档单次采样，该区间冷启占比 <1%。上一版全部为单次采样。

二、栈自检（功能与能力，全部本机环上实跑）

能力边界说明：图文混合输入正常；音频输入不支持（服务端明确报 At most 0 audio(s) may be provided in one prompt）。思考链落在非标准字段 reasoning，不是 OpenAI 惯例的 reasoning_content——对接客户端时要注意这个字段名。

三、长上下文阶梯压测（并发 1）

单流解码在 16K–64K 区间冲到 83.7 / 92.7 / 102.6 tok/s，是这版最突出的地方；512K 单请求 TTFT 181.4s、prefill 2.77k tok/s，全程无 OOM。

四、高并发 × 上下文 二维扫描

并发 2

并发 4

并发 8（满并发，= max-num-seqs）

五、汇总对照

聚合解码吞吐（tokens/s）

单流解码吞吐（tokens/s）

聚合 prefill 吞吐（tokens/s）

几条结论：

• Decode 随并发放大更明显：满并发 8 路聚合解码从 1K 的 358.0 涨到 8K–64K 的 398.3–463.7 tok/s，512K 达到 672.8。
• 单流解码不再被并发拖死：并发 8 下 8K / 16K 仍有 48.5 / 50.6 tok/s（上一版同档为 16.9 / 12.6）。
• Prefill 与并发无关：1K→128K 区间聚合 prefill 稳定在 3.5k–4.1k tok/s，四档并发几乎重合，512K 降到 2,860.1——瓶颈仍是单请求长序列 attention，不是环带宽。
• 128 tokens 的短输出会低估真实吞吐：单流 tg 含首几步调度开销，实际长任务会更好。

六、与上一版（旧 checkpoint）的性能对比小结

① 聚合解码吞吐 —— 并发 ≥2 时明显胜出；并发 1 与 128K 以上退步

② 单流解码吞吐 —— 并发 ≥2 时大幅提升，并发 1 的中小上下文退步

③ 首字延迟 TTFT —— 长上下文明显更快，短上下文更慢

④ 聚合 prefill 吞吐 —— 本版唯一整体退步项

对比要点

• 并发能力是这版的核心提升：并发 8 下 8K–32K 区间聚合解码提升 +38% ~ +50%，并发 4 下 4K–32K 提升 +27% ~ +51%。上一版满并发时单流被压到 9.7–16.9 tok/s（8K–64K），本版同档有 21.0–48.5 tok/s。
• 超长上下文 prefill 更快：512K 并发 8 的 TTFT 从 1,396.56s 降到 815.73s（-42%），128K/256K 分别 -32% / -38%。
• 短 prompt、低并发是明确退步：并发 1 的 1K/4K/8K 单流解码 91.0→55.3、96.5→71.5、89.4→73.0 tok/s；TTFT 1K 档 0.47s→1.22s。聚合 prefill 因此在小上下文掉 65% 左右。
• 墙钟基本持平：同规格任务的总耗时两版差异在 −3% ~ +3% 之间，最大差异出现在并发 8 × 512K（1,398s → 1,405s）。

七、两个反直觉的测量发现（供同好参考）

1. 每轮第一笔请求有约 2.2 秒冷启开销，稳态只要 0.98 秒。 同一个 1000-token 请求连测 8 次，首字延迟稳定在 0.96–0.99 秒（标准差 0.01）；而每次重新开跑的第一个 cell 会达到 2.2–2.5 秒。如果只做单次采样，就会把这个冷启算进表里——上一版的 1K 档 0.47s 和本版单采样的 2.2s 都不代表稳态。
2. TTFT 可以拟合成一条直线：阶梯实验（160 / 997 / 3,719 / 7,365 / 14,640 prompt tokens）得到 TTFT ≈ 0.8s 固定 + prompt_tokens / 4,700 (t/s)。也就是说这版有约 0.8 秒的固定首字成本，短 prompt 时被放大成几倍差距，长 prompt 时完全被淹没——这也解释了为什么 prefill 吞吐在小上下文退步、在 128K 以上反而变好。

八、结论

1. 1017 版是「高并发 / 长上下文」取向的版本。 并发 8 路时聚合解码比上一版高 +38% ~ +50%（8K–32K），单流也不再被并发压死；超长上下文（128K–512K）并发 8 的 TTFT 快 32%–42%。
2. 代价是短 prompt / 低并发的首字延迟：约 0.8 秒固定开销让 1K–8K 的 prefill 吞吐掉 40%+，单流解码在并发 1 时也从 ~90 掉到 ~55–73 tok/s。
3. 实际选型建议：如果负载是「多轮 agent、工具调用、批量并发」（典型如 Hermes 这类前端），1017 更合适，尤其是并发 ≥2 之后；如果是「单用户、短问短答、极在意首字延迟」，旧版在同硬件上反而更顺手。
4. 环拓扑本身没有任何变化：四机 4 根 DAC、无交换机、SIRCL 传输，512K 满并发 1,405 秒跑完、全程无 OOM。换 checkpoint 不影响这套拓扑的可用性。