Dev 品質・言語ベンチマーク

スループットは品質ではない。モデルは高速に decode できても、エージェント・コーディングには使い物にならないことがある — ツールコールの引数を切り詰めたり、エラーでループしたり、ファインチューンが別の言語をひそかに壊していたりする。このページは実際の asiai bench --code と asiai bench --language の結果を報告する: 決定的なシグナル（コアには LLM ジャッジ不要）であり、モデルがどれだけ速くトークンを出すかではなく、実際に動くかどうかを計測する。

継続更新ドキュメント。 これらの数値は、モデルのリビジョン、エンジン、テンプレートの変更に応じて更新される。各ブロックは正確なモデルファイルと配信構成を明記しているため、結果は再現可能である。

何を計測するか

asiai bench --code（決定的、ジャッジ不要）:

tool-call — 蓄積するコンテキスト下での 8 ターンのエージェント・ファイル編集セッション。ツールコールの発行、JSON の妥当性、非切り詰め、正しいツール、スキーマ準拠、そして 空オブジェクトのバグ を採点する: |items テンプレートの切り詰めが edit_file.edits 配列を {} / [] に潰してしまうもの。
tool-call-stress — 同じだがより難しい: より深いコンテキスト、8〜10 要素の編集配列、JSON エスケープの圧力（改行、引用符、バックスラッシュ、unicode）。ベースラインで満点を取るモデル同士を見分けるために用いる。
recovery — セッション途中で合成的なツールエラーを注入し、是正アクション（失敗したコールを再発行して詰まるループに対して）を採点する。
thinking — thinking モードの規律: <think> が content に漏れない、短い予算でも非空の出力、enable_thinking=false が尊重される。
coding / coding-hard (任意のジャッジ) — マルチターンのコーディングタスクを、--judge-url（任意の OpenAI 互換エンドポイント）の LLM ジャッジが 1〜5 で採点する。

asiai bench --instruct（決定的な指示追従）:

verifiable — プログラムで検証可能な指示（語数／文数／セクション数、キーワード、JSON のみ、大文字小文字、カンマなし、末尾フレーズ、<<>> 内のタイトル、言語…）を伴う IFEval スタイルの単一ターンのプロンプト。プロンプトレベルと指示レベルでの strict/loose 精度として報告される — これは公開リーダーボードの形式である。IFEval パラダイム（Zhou et al. 2023）の asiai ネイティブな再実装であり、IFEval のコードやデータはベンダリングしていない。
research-brief — エージェント・タスク: ツールを使って複数のトピックを調査し、続いて複数セクションのブリーフィングを書き、最後に副次的なツールアクション（保存）を最後に行う。モデルは主要なブリーフィングを生成するのか、それともツール作業をして副次ステップの確認だけを返すのか? モデルはツールコールの信頼性で満点を取りつつ、それでも主要な成果物をスキップしてしまうことがある — 必要なセクションがツールターンの後に現れるかをチェックして決定的に採点する。order-control は順序を入れ替え（副次を先に）、診断として用いる。
loop-search — 曖昧な検索のトラップ: 明快なトピックにわたる深いウォームアップに続いて、web_search が決して確認できないターゲットの事実（クエリの意味的な言い換えが 1 つの答えに収束する）。モデルが曖昧さを受け入れて（冷静に）成果物を提供するのか、それとも no-progress の上限が停止させるまで等価なクエリを再発行し続けるのか（完璧主義）を採点し、加えて出力トークン崩壊のシグナルも採る。2 つのモード（short の 1KB 未満の結果 / unconfirmable のもっともらしいが欠けている事実）。これは単一ターンの IFEval や research-brief が表面化させない失敗モードである。

asiai bench --language <code>（決定的、8 言語）:

adherence — モデルはターゲット言語にとどまるか?（Latin スクリプトについてはターゲット対英語の機能語比; ja/ko/zh についてはターゲットスクリプトの文字比）。
diacritics — 正解が特定のアクセント付きトークン（café、préféré）を含まなければならないトラッププロンプト; ASCII 化された回答は不合格となる。

3 つのモードはすべて JSON のみであり、出力を diff することでモデル間を比較する。

実例 — Qwen3.6-35B-A3B vs Qwopus3.6-35B-A3B vs Qwen3.6-27B dense

ファインチューン（Qwopus3.6、Qwen3.6-35B-A3B MoE の Opus 蒸留ファインチューン）対そのベース、対その半分のサイズの dense モデル。同じ llama.cpp、同じチャットテンプレートを固定（モデルファイルのみ差し替え）、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 を空オブジェクトのバグに 3/3 で潰す — Q4 と Q5 の両 quant で（つまり量子化ではなく生成の挙動である）。単純なコールでの |items バグを修正するコミュニティの froggeric テンプレートは、コンテキストの深いところにいるベース MoE を救えない。
Opus 蒸留ファインチューンはそれを完全に修復する — 0 バグ、100% clean — しかもより低い quant（Q4 vs Q5）で、これによって勝ちはさらに強固になる。
ストレス下では、ファインチューンは dense 27B よりも堅牢なエージェントである: 27B は崩れる（より難しいスイートで空オブジェクトのバグ 3 件）が、ファインチューンは 0 にとどまる。両者はベースラインでは並ぶ; ストレススイートが両者を切り分ける。

コードの正しさ（LLM ジャッジによる難タスク）

2 つのよりトリッキーなマルチターン・コーディングタスクでは両者は分かれる: スライディングウィンドウのレートリミッタでは双方が境界／追い出しのエッジケースを処理する; 式評価器では dense 27B が演算子優先順位を正しく処理する（-2**2 == -4、単項マイナスを適切な演算子として）一方で、ファインチューンはそうしない（単項マイナスを数値に畳み込んでしまう → 4.0）。ツールコールの堅牢性とアルゴリズムの正しさは異なる軸である — 両方を計測すること。

言語保持

ファインチューンとそのベースに対し、同じ quant で --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、diacritics、ASCII 化なし） — タスク固有のファインチューンが別の言語を犠牲にしなかったということであり、これは想定するのではなく検証する価値がある。

完璧主義の調査ループ（loop-search）

research-brief はここのすべてのモデルで 100% に飽和するため、実際のエージェントを壊す完璧主義のループを識別しない。loop-search シナリオはそれを行う。dense 27B と MoE 35B-A3B の構成のスイープ全体（M5、llama.cpp b9430、thinking on/off、両方の曖昧さモード）にわたって:

35B-A3B MoE はループする — 確認不能な事実に対して意味的に等価な検索を再発行し続け、no-progress のガードレールが停止させるまで止まり、不確実性を受け入れて成果物を提供しない。これはベースと Opus 蒸留ファインチューンのいずれについても、Q4 と Q8 の両方で起こる（量子化の作為ではなくアーキテクチャ由来）。
dense 27B は決してループしない（Q4 / Q5 / Q8）: 曖昧な結果を受け入れてブリーフィングを書く。

NousResearch の Hermes Agent のようなエージェント・ハーネスにとっては、これが決め手となるシグナルである: より速い MoE が存在する場合でも、ループ耐性のある dense モデルのほうが安全なメインである — エージェントが 1 つの曖昧なステップでスパイラルに陥るなら、スループットは何も買わない。これは上記のツールコールの結果（MoE ファインチューンがより堅牢なエージェントだった）とは逆の教訓でもある: 適性は失敗モードごとであり、したがって複数を計測すること。

これをどう読むか

判定優先、速度優先ではない。 これらは正しさ／信頼性のシグナルである。スループットについてはエージェント・ベンチマークを参照。
決定的なコア、任意のジャッジ。 tool-call / recovery / thinking / adherence / diacritics に LLM ジャッジは不要 — これらは再現可能である。coding/fluency の採点は LLM ジャッジによる（主観的、任意）。
制御された変更の内側で比較する。 この例はテンプレートを固定しモデルのみを変えるため、差はモデルのものであり、ハーネスのものではない。

手法と注意点

asiai bench --code / --language、thinking 無効化（chat_template_kwargs.enable_thinking=false）、一度に常駐するエンジンは 1 つ。
この例では quant が異なる（ファインチューンは Q4、Qwen モデルは Q5）: 見出しの空オブジェクトのバグはテンプレート／生成によるものであり、ベースについては両方の quant で確認されたため、quant では差を説明できない — そしてファインチューンはより低い quant から勝っている。
コード品質のジャッジは厳密にはブラインドではない ここでは（フロンティアモデルがトランスクリプトを内容に基づいて読んだ）; 決定的な tool-call/stress の数値は客観的である。
recovery は重みに敏感であり、クリーンなクロスモデルのシグナルではない — 見出しは tool-call/空オブジェクトの信頼性であり、これは反復をまたいで安定している。

参照: エージェント・ベンチマーク · ベンチマーク手法 · メトリクス仕様。