开发质量与语言基准测试
吞吐不等于质量。一个模型可以 decode 飞快，却依然无法用于 agentic 编码 ——
它会截断工具调用参数、在错误上陷入循环，或者它的微调悄悄破坏了另一门语言。
本页报告真实的 asiai bench --code 与 asiai bench --language 结果：
确定性信号（核心部分无需 LLM 评判器），衡量的是模型是否真的能用，
而非它喷出 token 的速度。
持续更新文档。 随着模型修订、引擎和模板的变化，这些数字会被刷新。每一个 区块都标注了确切的模型文件和服务配置，因此结果始终可复现。
测量内容
asiai bench --code（确定性，无评判器）：
- tool-call —— 一段 8 轮、上下文不断累积的 agentic 文件编辑会话。对工具调用
的发出、JSON 有效性、不截断、正确的工具、schema 一致性，以及空对象 bug
进行评分：即
|items模板截断把edit_file.edits数组塌缩成{}/[]。 - tool-call-stress —— 同样的任务，但更难：更深的上下文、8–10 个元素的编辑 数组、JSON 转义压力（换行、引号、反斜杠、unicode）。用于区分那些在基线上 满分的模型。
- recovery —— 在会话中途注入一个合成的工具错误；对纠正性动作 vs 卡死循环 （重新发出失败的调用）进行评分。
- thinking —— thinking 模式纪律：不把
<think>泄漏进正文、在短预算下输出 非空，以及遵守enable_thinking=false。 - coding / coding-hard （可选评判器） —— 多轮编码任务，由位于
--judge-url的 LLM 评判器（任意 OpenAI 兼容端点）按 1–5 分评分。
asiai bench --instruct（确定性指令遵循）：
- verifiable —— IFEval 风格的单轮提示词，带有可通过程序检查的指令
（字数/句数/段落数、关键词、仅 JSON、大小写、无逗号、结尾短语、用
<<>>括起的标题、语言……）。以严格/宽松准确率在提示词层级和指令层级上报告 —— 即公开排行榜的格式。这是对 IFEval 范式（Zhou et al. 2023）的 asiai 原生 重新实现；未内置任何 IFEval 代码或数据。 - research-brief —— 一项 agentic 任务：通过工具研究若干主题，然后撰写一份 多章节简报，最后再执行一个次要工具动作（保存）。模型究竟会产出主体简报， 还是只做工具工作并仅返回次要步骤的确认？一个模型可以在工具调用可靠性上拿 满分，却依然跳过主要交付物 —— 通过检查必需的章节是否出现在工具轮次之后来 进行确定性评分。order-control 调换顺序（次要在前）作为诊断。
asiai bench --language <code>（确定性，8 种语言）：
- adherence —— 模型是否保持在目标语言？（拉丁字母文字看目标 vs 英语的 功能词比例；ja/ko/zh 看目标文字的字符比例）。
- diacritics —— 陷阱提示词，其正确答案必须包含特定的带重音 token
（
café、préféré）；被剥去 ASCII 的答案算失败。
这三种模式都仅输出 JSON，并通过对输出做差异比较来跨模型对比。
实例分析 —— Qwen3.6-35B-A3B vs Qwopus3.6-35B-A3B vs Qwen3.6-27B 稠密模型
一个微调版（Qwopus3.6，对 Qwen3.6-35B-A3B MoE 进行 Opus 蒸馏的微调）
vs 它的基座模型，vs 一个只有其一半大小的稠密模型。相同的 llama.cpp、
chat 模板保持恒定不变（只替换模型文件）、关闭 thinking、3 次重复。
Apple Silicon M5 Max，High Power Mode。
工具调用可靠性
| model · quant | tool-call clean | empty-object bug | under stress |
|---|---|---|---|
| Qwen3.6-35B-A3B base · Q4 / Q5 | 87.5% | 3 | 87.5% · 3 bugs |
| Qwopus3.6-35B-A3B · Q4 | 100% | 0 | 100% · 0 |
| Qwen3.6-27B dense · Q5 | 100% | 0 | 88.9% · 3 bugs |
- 基座 35B MoE 存在一个模板修复无法完全闭合的残余工具调用缺陷。
在深上下文的某一轮中，它会把
edit_file.edits塌缩成空对象 bug，3/3 —— 在 Q4 和 Q5 两种量化下都如此（所以这是一种生成行为，而非量化所致）。 社区的froggeric模板能修复简单调用上的|itemsbug，却救不了深陷上下文 中的基座 MoE。 - Opus 蒸馏微调版将其完全修复 —— 0 个 bug、100% clean —— 而且是在更低的 量化下（Q4 vs Q5），这让胜势更加有力。
- 在压力之下，该微调版是比稠密 27B 更稳健的 agent：27B 出现裂缝 （在更难的测试集上有 3 个空对象 bug），而微调版保持在 0。它们在基线上打平； 压力测试集才把它们区分开来。
代码正确性（LLM 评判的高难度任务）
在两项更刁钻的多轮编码任务上它们分道扬镳：在一个滑动窗口限流器上两者都能
处理边界/淘汰的边缘情况；在一个表达式求值器上，稠密 27B 把运算符优先级处理
对了（-2**2 == -4，一元负号作为一个真正的运算符），而微调版没有
（它把一元负号折叠进了数字 → 4.0）。工具调用稳健性与算法正确性是不同的
维度 —— 两者都要测。
语言保持
对微调版及其基座以相同量化运行 --language fr：
| model | adherence | diacritic traps | ASCII-stripped |
|---|---|---|---|
| Qwen3.6-35B-A3B base | 100% | 4/4 | 0 |
| Qwopus3.6-35B-A3B | 100% | 4/4 | 0 |
法语零退化。 这个面向编码的微调版完好地保留了基座模型的法语能力 （adherence、变音符号、无 ASCII 剥离）—— 一个任务专精的微调并未以牺牲另一门 语言为代价，这一点值得验证，而非想当然。
如何阅读本页
- 结论优先，而非速度优先。 这些是正确性/可靠性信号。关于吞吐， 请见 Agentic 基准测试结果。
- 确定性核心，可选评判器。 tool-call / recovery / thinking / adherence /
diacritics 无需 LLM 评判器 —— 它们可复现。
coding/fluency评分由 LLM 评判 （主观，可选）。 - 在受控变更内比较。 该实例保持模板恒定、只变动模型，因此差异归于模型， 而非测试框架。
方法与注意事项
asiai bench --code/--language，关闭 thinking （chat_template_kwargs.enable_thinking=false），同一时刻仅常驻一个引擎。- 量化在该实例中各异（微调版用 Q4，而 Qwen 系列模型用 Q5）：作为重头戏的 空对象 bug 是由模板/生成驱动的，并已在基座的 两种 量化下得到确认， 因此量化并不能解释这一差距 —— 而且微调版还是从更低的量化中胜出的。
- 此处的代码质量评判器并非严格盲测（一个前沿模型基于实质内容阅读了 对话记录）；确定性的 tool-call/stress 数字是客观的。
- Recovery 对权重敏感，并非干净的跨模型信号 —— 重头戏是 tool-call/空对象 可靠性，它在多次重复之间保持稳定。
另见：Agentic 基准测试结果 · 基准测试方法 · 指标规范。