先排除服务与配置问题#

/props 与 /slots 显示：n_ctx = 262144、is_processing = false、state 空闲，服务健康。 命令行参数与预期完全一致（-c 262144 -np 1、KV q8_0、--alias qwen36）。

→ 配置和内存分配都没问题，且 /props 的 n_ctx 证明 256K 窗口确实生效了。

从 DSH 会话日志里取真实数据#

会话日志是 append-only 的多帧 zstd：

~\.dsh\sessions\--D-sites-bigfoxme--\session-7a02256b-...\session.v4.jsonl.zstd

踩了一个坑：zstdDecompressSync 和流式 API 都只解出第一个 frame（80811 B 里只得到 199 B）。 解法是按 zstd 魔数 28 B5 2F FD 切帧后逐帧解压 → 79 帧 → 149 条记录。

日志里拿到了三个关键事实：

另外两点值得记录：

• 18 条助手消息全部带 reasoning，而日志里 enable_thinking 出现 0 次。 说明 pi-ai 适配器没有传递该参数的能力（它的采样字段只有 temperature/maxTokens/stop）， DSH 里思考始终是开着的。不过该会话的推理都很短（42~480 字符），不是速度主因。
• 第 1 步撞上 503 Loading model 并重试 3 次——模型还在加载就开始提问。

第一次算速率算错了#

我先用 输出token ÷ 整步耗时 算，得到 2.26~11.42 tok/s。但这个指标是错的，因为记录顺序是：

step/start → assistant/message → tool/call → tool/result → step/end

step/end 出现在 工具执行之后，所以整步耗时里混进了读文件、跑命令的时间。必须先剔除。

意外发现：会话里已经存了逐 token 的时间戳#

DSH 的流记录里保存了 token 级到达间隔：

{"type":"text-chunks","time0":1791517980564,"index":1,
 "dt":[60,62,63,64,61,66,62,62,61],
 "texts":["好的","，","让我","先","了解","项目","整体","结构","。","\n\n"]}

dt 就是每个 token 的毫秒间隔（首个 407 ms 是首字延迟）。稳态约 60~63 ms/token = 16.4 tok/s—— 这是最直接的证据，不需要任何推算。

同时按时间线把每步拆成三段：

于是得到三个层次的数字，对应不同的问法：

→ 用户看到的 13 落在”模型期整体”这一档，是真实的、可解释的。

活体服务上的受控深度扫描#

为把”深度”从其他因素里分离出来，在正在运行的服务上做扫描（不加载模型、不重启）， 读服务端自己返回的 timings.predicted_per_second（权威解码速率）：

• 请求体写入 JSON 文件后用 curl --data-binary @file 发送（避免 PowerShell 吃掉引号）
• 填充文本由同一句话重复构成，深度递增 → 后续请求能复用 KV 前缀缓存
• 每点生成 62~221 token，样本量足够

深度曲线（同一服务、连续测量）#

拟合出的经验关系（量级参考，非精确公式）：

解码速率 ≈ 21.0 − 0.00039 × 上下文token数        （每 1K 深度约 −0.39 tok/s，−1.9%）

关键对照：预填完全不受深度影响#

同一个 21K 深度的请求里，两项指标对比：

整个扫描区间内预填稳定在 297~331 tok/s。这一条是整个调查里最有价值的证据， 因为它一次性排除了两个竞争解释：

• 排除换页：权重被换出页面会同时拖垮预填与解码，而预填纹丝不动。
• 排除配置/量化问题：两者用的是同一套参数、同一块 KV。

排除”机器变热/变慢”#

我做了重活（21K 预填 + 多次长生成）之后立刻复测浅深度：

浅深度稳定回到 23~24，所以不是热降频、也不是”跑久了变慢”。

顺带发现：前缀”形状”变化要付一次重预填#

bench_running_server.py 的第一次请求首字延迟 17.29 s，第二次只有 0.23 s。 原因是从上一个 21K 填充前缀切换到新提示时，KV 缓存前缀不匹配、需要重新预填。

这解释了真实会话里 平均 6.8 s 的预填耗时：agent 每一步的提示都在变化， 一旦工具结果插在历史中段或发生压缩，前缀就分叉，重预填代价立刻出现。

交叉验证：另一个模型的独立测量#

同一台机器上，dense 27B（Qwen3.8-27B）由另一次实验测得：

两个不同架构的模型、两次独立测量，16~17K 深度处的衰减量级一致（−28% vs −32%）， 说明这是通用现象而非某个模型的怪癖。

两个数字都对，只是测的不是同一件事#

机制：代价定位在”逐 token 的注意力”，具体成因未确立#

已经确定的（实测）：代价只出现在解码阶段，预填几乎不受影响。 这一条排除了所有”与阶段无关”的解释——如果是权重被换出页面，预填会同步变慢，而它没有。

一个反直觉的算账（说明不能用”KV 搬运量”解释）：

KV 字节搬运只解释了额外耗时的约 1%。所以不能说”解码是内存带宽瓶颈”—— 同理，它也不是”上下文越长、要读的数据越多”这种简单模型。

因此更可能的机制（推断，未单独验证）：长上下文下注意力算子本身的效率问题。 本模型的注意力配置是 2 个 KV 头、head_dim 256、且只有 10/40 层有注意力， 长序列下算术密度低、访存模式分散（KV 工作集远超 iGPU 末级缓存）， 实际表现可能远低于算力上界。另外该服务的启动参数未显式指定 -fa （flash attention 走 auto），是否影响长序列注意力效率也未验证。

这些只是候选解释，我没有单独验证。 本报告确证的是现象与其量级，不是内核层面的成因—— 这也意味着”换个后端/打开 flash attention 能不能改善”是一个尚未验证的可行方向，值得单独实验。

排除的解释#

该期待多少#

换算系数来自那个会话的实测分解：纯解码 16.4 → 模型期 11.93（×0.73）→ 输出÷整步 7.13（×0.43）。 三个数字都对，问的是不同的东西——讨论速度时务必先说明用哪个口径。

一处诚实的不一致#

曲线外推 26K 应得约 11 tok/s，而真实会话在 26K 处实测 16.4 tok/s（高约 1.5 倍）。 两者方向一致但绝对值有差距，原因未查明。可能因素：填充文本高度重复、 两次测量的机器状态不同、真实提示含工具 schema 结构不同。

→ 因此上面的曲线应作为量级参考，而不是精确公式。