基准测试与评测
实测数字，旁边附上日期、量化方式和测试设置，不佳的结果也一并列出。
基准测试的数字，只有在知道它是怎么得出的时候才有用。同一个模型，换一种量化方式、换一个运行时或换一个提示词，得分就可能不同，而大多数公开的表格都没有写明这些细节。
这对需要做选择的人很重要。排行榜可以说某个模型很强，但它可能做不好你手头的实际工作；厂商自己的测试，也很少正是你需要的那一种。速度也有同样的问题：模型读取长输入所用的时间（prefill）和写出内容所用的时间（decode）回答的是不同的问题，却常常被合并成一个数字。
我在自己的工作室里、用自己的硬件做测量。公布的数据只使用 llama.cpp，每个数字旁边都附上日期、量化方式和测试设置，prefill 和 decode 分开报告。测试集包括 LiveCodeBench（30 个编程任务）、来自 SWE-bench Verified 的真实软件问题、一个提取标准答案集，以及视频质量关卡。
不佳的结果同样公布。最好的本地编程模型解决了 LiveCodeBench 30 个任务中的 22 个；在 150 个 SWE-bench Verified 问题上，一个本地模型解决了 16 个。其中一个模型 Nemotron 3.5 Lightning 被移除：它解决了 30 个任务中的 15 个，而且在其中一个任务上，为得出答案所写的内容是一个更快的模型的十倍。
这套做法遵循一条规则：本地模型可以判定工作不合格，但绝不能批准工作通过。由一个简单的测试来裁定。
证据
- Qwen3.8-27B 使用 Q4_K_M 构建并搭配 MTP Q4_0 sidecar，解码速度为 38.9 token/秒（llama.cpp d454a20，本地工作站，三个提示词，temperature 0）。较早的 Q4_K_M 构建为 25.9，IQ3_S 为 26.2。
- 在 LiveCodeBench v6 上（30 个任务，llama.cpp，本地工作站），Qwen3.8-27B 的三个变体分别解出 17 个（IQ3_S）、16 个（MTP）和 15 个（较早的 Q4_K_M）任务，差异在噪声范围内，可视为持平。
- 在包含 24 份文档、120 个字段的标准答案集上，qwen3.8-flash-next-coder IQ1_M（29.6 GB）提取出 120 个字段中的 120 个，每份文档的中位耗时为 9.84 s，第 95 百分位为 11.27 s（llama.cpp 0.6.0，本地工作站）。
- 在 SWE-bench Verified 的 sympy 子集上，Qwen3-Coder-Next Q4_K_M 在本地硬件上通过 llama.cpp 解决了 63 个任务中的 24 个（原生回放测试框架）。
- 本地模型可以让工作不通过，但绝不能批准工作。
- 对 Qwen2.5-0.5B-Instruct Q8_0 做的 CUDA 解码冒烟测试，在 95 个 token 上达到 231.27 token/秒（llama.cpp b11429，CUDA 12.4，自有硬件）。
- 运行一个包含 24 份文档和 120 个字段的提取标准答案集。
- 在 30 个任务上运行 LiveCodeBench v6。
- 通过原生测试框架运行 SWE-bench Verified 的 sympy 子集，该框架验证了 67 个标准补丁中的 63 个。
- 对每个构建和量化版本，分别报告预填充速度和解码速度。
- 依据规则和人工判定来检查生成的视频。
- 用 llama.cpp 在本地运行开源模型，同时也使用云端模型；在 Nemotron 3.5 Lightning（30B）解出 30 个 LiveCodeBench 任务中的 15 个、而 gemma-4-26b-a4b 解出 18 个之后，将其移除，并且在一个 14k token 的任务上它用了 12,650 个 token，而对方为 1,236；按 Jared Palmer 的开源方案微调 Kev 检查点；是否通过由 shell 检查来判定；本地模型可以让工作不通过，但绝不能批准工作。
- 在 Modal 上由官方测试框架评分的 150 个 SWE-bench Verified 任务中，llama.cpp 下的 Qwen3-Coder-Next 解决了 16 个。Codex 解决了 58 个本地模型没有解决的任务。其余 76 个两者都没有解决。