硬件：ThinkPad P1 Gen4 RTX 3080 Laptop 16 GiB / sm_86 /驱动596.47 /80 W 功耗墙（上限100 W 不可调）/ 32 GB 单通道 DDR4-3200
测试窗口：2026-10-09 21:47 → 2026-10-10 08:53（Asia/hanghai），全程GPU 独占

结论先行：CTX 64K / 100K / 128K 各自每秒生成多少 token
被测组合：M_TER（ternary-bonsai-3080-sm86-ninfer，7.736 GiB 文件 / 设备常驻 7.12 GiB）+ 社区 sm_86 引擎 E_TER（engine\ninfer.exe，构建日期 2026-10-06）。
统一口径：--kv-dtype int8、--spec mtp --draft-tokens 2、--greedy（温度 0）、--no-thinking、--prefill-chunk 1024、--max-new 256、--max-context = --kv-capacity = 档位、CUDA graph 开启、填充 = 档位 − 512 token。

1.1 主表（全部【实测】）

1.1 主表（全部【实测】）— 转置

三句话答案

64K：约 18.8 token/s（引擎自报；客户端 19.6 t/s；四条独立测量全部 18.8）。
100K：约 17.0 token/s（仅 1 次样本，且没有任何 serve 侧数据）。
128K：约 15.0–16.1 token/s（中位 15.6）（2 次样本：CLI 16.1 + step-07 serve A 请求 15.0；客户端口径 15.0）。

随上下文加长，解码只掉 14%（64K→128K：18.8 → 16.1 t/s，−14.4%；100K 居中 17.0）。这与 KVMem/llama.cpp 路线在同类硬件上"每条 token 都要重读预算内权重"的陡降不同 —— 本引擎的 KV 是 paged KV + 显存常驻，因此长上下文代价主要落在 prefill 墙钟和 MTP 接受率上，而不是解码吞吐的崩塌。

三个必须与数字同读的口径事实

这是"满载上下文"的数字：64,345 / 100,800 / 129,153 token 已把上下文填满（档位 −512），不可用来预测短对话的体验 —— 同一台 64K 服务器上，48-token 短提示词的解码是 53.3 t/s【实测，c2-results.jsonl C1a/C1b】，比满载低 64.7%。差别来自 MTP 接受率（短上下文 98.3% vs 长上下文 41.7–50.0%）与注意力开销。

解码样本很短：--max-new 256 未跑满，命中 stop-token 提前结束，生成长度 44–60 token，解码窗口仅 2.4–3.5 s。这是本报告 decode 数字最大的方法学弱点（见 §8.2）。
prefill 是真正的瓶颈：64K/100K/128K 的首字等待分别是 9 分 15 秒 / 15 分 27 秒 / 20 分 37 秒；同批次没有"额外暖机"——CLI 单进程墙钟 ≈ 起引擎 4–5 s + 整篇 prefill + decode（step-03 曾把 prefill 重复计成"暖机 ≈8.5 ms × ctx"，已被 step-06 用原文推翻）。

1.2 M_ORN（ornith_1_5_35b_a3b）：本机不可跑

一句话结论：本机 16 GiB（可用 14.91 GiB）在任何上下文长度下都不可跑，因为权重本身需要 19.59 GiB / 制品文件 21.22 GiB，已超出整卡 15.996 GiB；KV 压到 2048、KV dtype 换 int8、打开 --wddm-evictable-budget 三条省钱手段叠加后，失败原文与数字零变化。