私には個人的な評価用ハーネスがあります。LLMがエージェント的なセットアップ（私はOpenCodeを使用）でデバッグし、対応すべき意図的な不具合が37件ある、約3万行のコードを含むリポジトリです。
このハーネスの一部には、かなり大きめのPDF（40〜60ページ）からLLMが重要情報を抽出し、その内容を要約して評価するテストも含まれています。
要するに、このハーネスは次のLLM特性をテストしています： - エージェント的な能力 - コーディング - 画像からテキストへの統合 - 指示追従 - 推論
公正なベースラインとして、最適なサンプリングパラメータでUD-Q4_K_XLの両モデルを実行。Googleによる最新のchat-templateの修正後のGemma 4のGGUFに加え、DRAMの暴走（blowups）を抑えるための -cram、-ctkcp フラグを使用しています。
結果はこうです：
Qwen3.6 Gemma 4 ┌──────────────┐ ┌──────────────┐ Tests Fixed │ 32 / 37 │ │ 28 / 37 │ Regressions │ 0 │ │ 8 │ Net Score │ 32 │ │ 20 │ Post-Run Failures │ 5 │ │ 17 │ Duration │ 49 min │ │ 85 min │ └──────────────┘ └──────────────┘ WINNER ✓
1. テスト結果
| 指標 | Qwen3.6-35B-A3B | Gemma 4-26B-A4B |
|---|---|---|
| ベースラインの失敗 | 37 | 37 |
| 修正されたテスト | 32 (86.5%) | 28 (75.7%) |
| 回帰（新たな失敗） | 0 | 8 |
| ネットスコア（fixed − regressed） | 32 | 20 |
| まだ失敗（元の37件のうち） | 5 | 9 |
| 実行後の総失敗数 | 5 | 17 |
| ガードレール違反 | 0 | 0 |
Qwenは残った5件の失敗を実際に見つけましたが、スコープ外だと判断して意図的にスキップしました。Gemmaは複数回のリトライをしても諦めました。
2. トークン使用量
| 指標 | Qwen3.6 | Gemma 4 | 比 |
|---|---|---|---|
| 入力トークン | 634,965 | 1,005,964 | Gemma 1.6倍多い |
| 出力トークン | 39,476 | 89,750 | Gemma 2.3倍多い |
| 総計（I+O） | 674,441 | 1,095,714 | Gemma 1.6倍多い |
| キャッシュ読み取りトークン | 4,241,502 | 3,530,520 | Qwen 1.2倍多い |
| 出力/入力比 | 1:16 | 1:11 | Gemmaの方が冗長 |
| 修正1回あたりのトークン | 約21K | 約39K | Gemmaの方が1.9倍高くつく |
| ネットスコア1ポイントあたりのトークン | 約21K | 約55K | Gemmaの方が2.6倍高くつく |
3. ツール呼び出し
| ツール | Qwen3.6 | Gemma 4 |
|---|---|---|
| read | 46 | 39 |
| bash | 33 | 30 |
| edit | 14 | 13 |
| grep | 16 | 10 |
| todowrite | 4 | 3 |
| glob | 1 | 1 |
| write | 1 | 0 |
| 合計 | 115 | 96 |
| 成功 | 115 (100%) | 96 (100%) |
| 失敗 | 0 | 0 |
| 派生指標 | Qwen3.6 | Gemma 4 |
|---|---|---|
| ユニークな読み取りファイル数 | 18 | 27 |
| ユニークな編集ファイル数 | 7 | 13 |
| ユニークファイルあたりの読み取り回数 | 2.6 | 1.4 |
| 1分あたりのツール呼び出し回数 | 2.3 | 1.1 |
| 修正あたりの編集回数 | 0.44 | 0.46 |
| Bash（pytest）実行回数 | 33 | 30 |
4. タイミングと効率
| 指標 | Qwen3.6 | Gemma 4 | 比 |
|---|---|---|---|
| 実時間（wall clock） | 2,950s (49m) | 5,129s (85m) | Gemma 1.74倍遅い |
| 合計ステップ数 | 120 | 104 | — |
| 平均ステップ時間 | 10.0s | 21.7s | Gemma 2.2倍遅い/ステップ |
主な観察結果：
- 両モデルとも、エージェント的な能力に顕著な飛躍が見られます。95回以上のツール呼び出しで0件の失敗
- Qwenの方が優れたコーダーです（少なくとも、私のハーネスがベースにしているPythonにおいて）
- 両モデルは推論パフォーマンスで最初は同等のスタートを切っていますが、Gemma 4はコンテキストが大きくなるにつれてプリフィル速度が揺らぎます。Qwenはアーキテクチャによって、プリフィル速度を通じてほぼ同じ状態に保つのに役立っています。エージェント的なコーディングでこれは非常に大きいです！
- 私を含め多くの人が、推論が過剰に冗長でトークンを無駄にしているとQwenを批判していますが、意外にもエージェント環境でははるかに効率的で、この点ではGemma 4を大きく上回っています。より短い時間で、より少ないトークン数で、より多くの問題を修正できました
- 画像からテキストへの統合は別の話です。QwenはGemmaよりも8倍多いトークン（および時間）を出力しますが、より高い精度で結果を返します。Gemmaは数値抽出のような細部をいくつか誤解しましたが、Qwenはそれを誤りませんでした。とはいえ、Gemmaも全体としては概ね良好に処理できています。品質 vs 効率。どちらを取るかです。
- 指示に基づいて長いPDFを要約し評価する用途では、両モデルとも十分に良いです。結局は好みの問題です。Gemmaはこの領域でも素早く仕上げます。Qwenはより多く考えて、最終評価ではわずかに良い結果になります。
Qwen 3.6 35B A3Bは、Gemma 4 26Bを私のユースケースでは支配しています。そして、スピードとパフォーマンスの最良のバランスを見つけられたことで、私の新しいデイリードライバーになりました。
逆に、Gemmaを支持するいくつかのポイントも挙げると： - Qwen 3.5/3.6シリーズのモデルは量子化への耐性が非常に高いのですが、Gemmaもそうかは分かりません。重みフルの比較をすれば、結果は大きく異なる可能性があります - Gemmaのサポートは、Qwenに比べてずっと成熟していません - 単発実行のばらつきがGemmaに不利に働いた可能性があります。ただし、私はこのハーネスの多様なカテゴリにまたがる評価基準が、それをある程度きちんと緩和していると考えています。結局のところ、これはあくまで私個人のテスト結果に基づく判断です。
[link] [comments]
