- 日期：2026-10-19
- 硬件：2 × Tesla V100-SXM2-16GB（TCC，NVLink，TP2）
- 执行文件：
build-win\apps\ninfer-serve.exe
- serve sha256：
FFD20B9DE0AA3E91F4E3DC2595051FE07172284E275BDC3B58DF62BF8DBAE7B5
- repo HEAD：
b0c7ffc05e854acdbf3d88377d2393c5fd01785d
- 目的：在
--prefill-chunk 2048、--max-context 196608 下，用 coding 场景对比本机三个 Qwen3.8-27B artifact，并追加 C 的 DFlash2 K=7 对照。
1. TL;DR
- A（官方 NVFP4）与 C（Coder390 V3）基本打平：主实验 decode 112.77 vs 112.43 tok/s，差约 0.3%。
- B（Coder390 V2）慢约 4.7%：107.48 tok/s。B/C 是同一 Coder390 微调的两个 artifact 构建，不是两个独立基础模型。
- 三者长上下文 prefill 几乎相同：48,056-token prompt 为 958.1 / 956.8 / 955.9 tok/s。
- 主实验总消耗 211,064 tokens（149,370 prompt + 61,694 completion），墙钟约 899.1–899.2 s。
- DFlash2 K=7 不可用于 196608：显存差 893 MiB，最大只能到 155648。
- 同 155648 context 下，DFlash2 K=7 仍比 MTP3 K=3 慢 3.2%（108.71 vs 112.33 tok/s），且少 41K 可用 context。coding 继续选 MTP3 K=3。
- 主实验 13/15 个请求达到
max_tokens，其中 5 个正文为空。速率结论不受截断影响，但 token 总数是“固定预算下的截断值”，不是完整答案长度。
2. 固定配置
主实验与对照实验的核心配置：
--prefill-chunk 2048
--max-context 196608
--kv-capacity 196608
--kv-dtype int8
--max-concurrency 1
--tp 2 --devices 0,1
--no-prefix-reuse
--greedy
--spec mtp --draft-tokens 3
说明：
--kv-dtype int8 是 196608 在 16GB 卡上可行的前提；BF16 KV 放不下。--no-prefix-reuse 保证每个请求都是冷 prefill。- thinking 固定
reasoning_effort=medium。
- A/C 使用 optimized proposal head（
--lm-head-draft）；B 使用 full proposal head（不加 --lm-head-draft）。
- DFlash2 对照实验实际使用 155648 context；196608 下无法启动。
3. 被测 artifact
| 代号 |
路径 |
大小 (B) |
说明 |
| A |
F:\models\ninfer\qwen3_8_27b_nvfp4.ninfer |
23,719,715,844 |
官方 NVFP4，MTP3 + optimized head |
| B |
models\Qwen3.8-27B-Coder390-W4A4-MTP-DFlash2-NInferV2-NOT-FOR-V3.ninfer |
23,477,696,516 |
Coder390 V2（文本），MTP3 + full head |
| C |
F:\models\ninfer\Qwen3.8-27B-Coder390-EfficientThink-W4A4-MTP-DFlash2.ninfer |
23,773,675,264 |
Coder390 V3（含 Vision 权重，未启用），MTP3 + optimized head |
| D |
同 C |
— |
C + DFlash2 K=7，155648 context |
补充：
F:\models\ninfer\模型-中文路径.ninfer 与官方 NVFP4 是同一文件的硬链接，未算作独立模型。- B/C 是同一 Coder390 微调的两个 artifact 构建：B 为 V2 文本版 / full proposal head；C 为 V3 带 Vision / optimized proposal head。
4. 场景与输出预算
| id |
内容 |
prompt token |
max_tokens |
| s1_geometry |
平面四边形 / 二面角余弦最小值，完整推导 |
131 |
6144 |
| s2_impl |
C++20 有界阻塞队列 + GoogleTest |
235 |
4096 |
| s3_debug |
并发 LRU 的 use-after-free 根因与最小修复 |
759 |
4096 |
| s4_refactor |
热点 build_report 字节级等价重构 |
609 |
4096 |
| s5_long_context |
约 18.9 万字符真实仓库源码，跨文件定位实现 |
48,056 |
2560 |
每个模型单独启动一次 server，顺序执行 5 个非流式请求；请求之间关闭 prefix reuse，因此每个请求都是冷 prefill。
5. 主实验（run-20261019-190343）
5.1 总览
| 模型 |
Prompt tok |
生成 tok |
总 tok |
加载 s |
请求 s |
进程 s |
decode tok/s |
端到端 tok/s |
截断/空回答 |
| A-official-nvfp4 |
49,790 |
20,992 |
70,782 |
71.9 |
239.0 |
313.3 |
112.77 |
87.84 |
5/2 |
| B-coder390-v2 |
49,790 |
20,992 |
70,782 |
31.2 |
248.2 |
281.8 |
107.48 |
84.57 |
5/1 |
| C-coder390-v3 |
49,790 |
19,710 |
69,500 |
73.5 |
228.2 |
304.0 |
112.43 |
86.35 |
3/2 |
| 合计 |
149,370 |
61,694 |
211,064 |
176.6 |
715.4 |
899.1 |
110.81 |
86.23 |
13/5 |
统计口径：
请求 s：5 个请求的 Engine timings.total 之和。进程 s：每个模型从进程启动到退出的墙钟，含加载与请求。decode tok/s：(completion-1) / decode_seconds。端到端 tok/s：completion / 请求 s。- 总墙钟约 899.2 s（14m59s），其中启动 176.6 s、Engine 请求 715.4 s。
5.2 逐场景 decode (tok/s)
| 场景 |
A |
B |
C |
最快 |
| s1 几何 |
112.20 |
108.70 |
114.32 |
C (+1.9%) |
| s2 队列实现 |
118.88 |
112.42 |
117.19 |
A (+1.4%) |
| s3 并发调试 |
110.01 |
102.57 |
107.15 |
A (+2.7%) |
| s4 重构 |
115.39 |
108.00 |
113.41 |
A (+1.7%) |
| s5 48K 长上下文 |
105.75 |
104.48 |
107.46 |
C (+1.6%) |
5.3 长上下文 prefill
| 指标 |
A |
B |
C |
| prompt tokens |
48,056 |
48,056 |
48,056 |
| prefill 秒 |
50.16 |
50.23 |
50.27 |
| prefill tok/s |
958.1 |
956.8 |
955.9 |
| TTFT 秒 |
50.37 |
50.44 |
50.50 |
短 prompt 的 prefill 速率（360–915 tok/s）主要受固定请求开销影响，不适合单独比较。
5.4 显存与截断
| 模型 |
启动后 free |
planned slack |
截断请求 |
正文为空 |
| A |
~200 MiB |
~156 MiB |
5/5 |
2（s1/s4） |
| B |
~370 MiB |
~325 MiB |
5/5 |
1（s1） |
| C |
~200 MiB |
~156 MiB |
3/5 |
2（s1/s4） |
- 13/15 达到
max_tokens（output_limit）。
- C 的 s2/s3 分别 3,588 / 3,322 token 自然停止。
- 5 个正文为空（预算全用于 reasoning）：A s1/s4、B s1、C s1/s4。
- 最大占用为 48,056 prompt + 2,560 output = 50,616 token，约为 196,608 的 25.7%。
- 最大 prompt 为 48,056 token，占 196,608 容量的 24.4%；本次没有填满 196K 上下文。
6. DFlash2 对照
6.1 196608 不可行
DFlash2 companion 额外常驻约 1.0 GiB/卡：
- 196608 的最低 Engine reservation：5,323,270,656 B
- DFlash2 权重加载后可用：4,386,459,648 B
- 缺口：936,811,008 B ≈ 893 MiB
--kv-capacity auto 不能绕过，因为 196608 的最低 reservation 本身已超可用值。
逐档探测（chunk 2048）：
| max-context |
结果 |
| 188416 |
差 712 MiB |
| 180224 |
差 531 MiB |
| 172032 |
差 350 MiB |
| 163840 |
差 169 MiB |
| 155648 |
启动成功，slack 5.1 MiB |
6.2 同 context（155648）对比
- MTP3@155648：
run-20261019-214025
- DFlash2 K=7@155648：
run-20261019-212816
| 场景 |
MTP3 decode |
DFlash2 decode |
DFlash2 相对 |
对照 MTP3@196608 |
| s1 几何 |
114.19 |
119.60 |
+4.7% |
114.32 |
| s2 队列实现 |
117.01 |
116.93 |
-0.1% |
117.19 |
| s3 并发调试 |
107.02 |
92.13 |
-13.9% |
107.15 |
| s4 重构 |
113.35 |
108.33 |
-4.4% |
113.41 |
| s5 48K 长上下文 |
107.47 |
102.22 |
-4.9% |
107.46 |
| 指标 |
MTP3@155648 |
DFlash2@155648 |
MTP3@196608 |
| completion tokens |
19,710 |
19,198 |
19,710 |
| total tokens |
69,500 |
68,988 |
69,500 |
| decode 秒 |
175.4 |
176.6 |
175.3 |
| decode tok/s |
112.33 |
108.71 |
112.43 |
| 请求秒 |
228.4 |
230.2 |
228.2 |
| 接受率 |
70.3% |
43.9% |
70.3% |
| 启动后 slack |
1,101.8 MiB |
5.1 MiB |
155.6 MiB |
结论：
- 同 context 下 DFlash2 K=7 仍慢 3.2%；跨 context 的旧对比是 3.3%，一致。
- MTP3 196608 → 155648 只差 +0.1%，且 5 个场景的生成 token 数完全相同，证明 context ceiling 对这些请求没有影响。
- DFlash2 接受率只有 43.9%（MTP3 70.3%）。唯一胜出的 s1 也只有 +4.7%，而调试题 s3 直接 -13.9%。
- DFlash2 的代价：可用 context 少 41K（196608 → 155648）、slack 仅 5.1 MiB，不适合作为日常 profile。
7. 结论与选型建议
- A 与 C 基本持平：A 汇总 decode 112.77 tok/s，C 112.43 tok/s；A 赢 3/5 场景，C 赢 2/5，差距都 <3%。
- B 慢约 4.7%：接受率反而最高（71.3%），说明 full proposal head 的每轮验证成本更高。
- prefill 无实质差异：48K prompt 三者都在 956–958 tok/s。
- coding 选 A 或 C；B 没有速度优势。
- DFlash2 K=7 不值得：同 context 慢 3.2%，还牺牲 41K context，slack 仅 5.1 MiB。
- 若目标是完整答案/质量对比，而不是吞吐：建议把 s1/s4 的
max_tokens 提到 8192+（几何题 8192 可能仍不够），或降低 reasoning_effort；预计总时间增加 2–5 分钟，decode 速率因上下文变长下降约 1–3%，排名不变。
8. 注意事项
- 截断：主实验 13/15 个请求达到
max_tokens，其中 5 个回答 content 为空、预算全部用于 reasoning。completion token 是固定预算下的截断值，不是完整答案长度；decode tok/s 不受截断影响，但总 token/总时间会受各模型停止位置影响。
- 加载时间：B 的 artifact 在测试前已被读取，加载 29.8 s；A/C 约 71 s。启动时间受 OS page cache 影响，不应据此判断冷启动性能。
- 统计口径：每个场景只跑 1 次；decode 差异小于约 3% 时不足以视为稳定优势。
- 文本编码：响应 JSON 的文本曾被 Windows PowerShell 5.1 按 Latin-1 解码 UTF-8 而乱码，已用无损的 Latin-1→UTF-8 反转修复；token/时间指标来自 server JSONL，未受影响。
- 模型关系：B 与 C 是同一 Coder390 微调的两个 artifact 构建（V2 文本版 / V3 带 Vision），B 使用 full proposal head，C 使用 optimized proposal head；A 是官方 NVFP4。
- 对照实验 context：DFlash2 K=7 与 MTP3@155648 对照实验实际使用 155648 context；主实验 A/B/C 使用 196608 context。