测试对象：NINFER v2 容器制品
1） ternary-bonsai-3080-sm86-ninfer（代号 M_TER，identity qwen3.8-27b）
2）ornith_1_5_35b_a3b（代号M_ORN，identity qwen3.6-35b-a3b）

硬件：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（65536）	100K（102400）	128K（131072）
填充 token（引擎自报实测）	64,345	100,800	129,153
解码 tok/s（引擎自报）	18.8	17.0	16.1（另一次 15.0；中位 15.6）
解码 tok/s（客户端口径）	19.6（serve SSE 扣首 token）	基准缺失（未测 serve）	15.0（step-07 serve A 请求，扣首 token 15.04 / 含首 token 15.39）
样本数 / 中位	4 次 / 18.8（4 次全 18.8）	1 次 / 17.0	2 次 / 15.6
prefill tok/s	118.1	108.8	104.4
prefill 墙钟	544.8 s（9m04.8s）	926.6 s（15m26.6s）	1237.5 s（20m37.5s）
TTFT	554.87 s	未实测（【推算】931.4 s = prefill 926.6 s + 起引擎 4.8 s）	1237.28 s（serve A 请求）
生成 token	49	60	53
MTP 接受率	50.0%	45.2%	50.0%
峰值显存（1 s 采样）	10,007 MiB	11,319 MiB	12,271 MiB
引擎自报 planned device total	9.70 GiB	10.9 GiB	11.9 GiB

三句话答案

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 三条省钱手段叠加后，失败原文与数字零变化。