「RTX3060」タグアーカイブ

コンピュータ

RTX 3060 12GB の自宅サーバで 125B の Qwen3.8-Flash-Next を動かす ― メモリ80GBに増設と Strata 導入記

コメントする

はじめに

ローカル AI 用に専用機（DGX Spark や Mac Studio など）を買うかどうか、しばらく迷っていました。 そこへ出てきたのが Strata。総 125B パラメータの MoE モデル Qwen3.8-Flash-Next を、12GB の GPU と 64GB 程度の RAM というゲーミング PC 級の構成で動かせる推論エンジンです。

うちの常時稼働サーバは RTX 3060 12GB を積んでいて、GPU の条件は満たしています。足りないのは RAM だけ。 そこで「専用機は買わず、RAM を足して Flash-Next を動かす」方針に決め、実際にやってみました。

結論から書くと:

  • RAM は 32GB×2 を足して 80GB（DDR4-3000）。種類の違うメモリを混ぜた4枚挿しで少しハマった
  • Strata の IQ3_XXS（3bit 級）で約 62 tok/s
  • 自作の6問テストで、クラウド版 Flash-Next とほぼ同じ品質。手元の Qwen3.6-35B-A3B より明確に上

環境

項目 内容
CPU Ryzen 5 5600X
マザーボード ASRock B550M Steel Legend（DDR4・4スロット・上限 128GB）
GPU RTX 3060 12GB（ドライバ 580）
RAM（前） 8GB×4（32GB）→ Strata には全然足りない
RAM（後） 32GB×2（新規）＋ 8GB×2（既存）＝ 80GB
ストレージ NVMe SSD（モデル置き場に約80GB使用）
OS Ubuntu 24.04

このサーバでは他にも Windows VM（約8GB）や各種常駐サービスが動いているため、「Strata 35〜43GB＋VM＋OS」で 64GB だとギリギリ、という見立てでした。

なぜ Qwen3.8-Flash-Next なのか

Qwen3.8-Flash-Next は Alibaba Qwen チームのオープンウェイト MoE モデルです。

  • 総 125B／1トークンあたり動くのは 6B（512 エキスパート中 10 個）
  • n-gram 埋め込み 51B と MTP（複数トークン予測）を持つ
  • コンテキスト 262K

アクティブが 6B と小さいので計算は軽い一方、エキスパート全体を置いておく場所（RAM）が大量に要る、というタイプのモデルです。

買う前に、クラウド（API 経由）で手元の候補と比べました。題材は手元の小さな Web アプリ（PHP＋素の JS）のコードで、わざと入れたバグの特定3問・実コードのレビュー2問・実装1問（隠しテスト22件）の計6問です。

お題 Flash-Next（クラウド） Qwen3.6-35B-A3B FP8 Qwen3.6-35B-A3B q4（ローカル）
残高を超えて申請できる（abs 抜け） 正解 不正解 不正解
ロック外の読み込みで更新が消える 正解 正解 正解
10〜12月が空になる（substr 位置ずれ） 正解＋追加指摘 正解 正解
ポイント処理のレビュー 良 中 弱
保存クラスのレビュー 良 中 弱
実装（隠しテスト22件） 22/22 2/22（タイポ） 22/22

Qwen3.6 は FP8 でも q4 でも同じ誤診をしていて、差は量子化ではなくモデルの地力でした。これで「Flash-Next を手元で動かす価値はある」と判断しました。

補足: 既定設定の Flash-Next は、自由記述のレビューで思考だけに 24,000 トークンを使い切って本文が空になることがありました。reasoning_effort: medium にすると 30〜50 秒で良い回答が返ります。

メモリ増設 ― 混在4枚挿しの落とし穴

買ったもの

DDR4-3200 の 32GB×2（JEDEC 3200 CL22、XMP なし）。もともと 8GB×4 で4スロットが埋まっていたので、8GB を2枚抜いて 32GB×2 を挿し、残した 8GB×2（Corsair Vengeance RGB Pro、XMP 3200 16-18-18-36 1.35V）と合わせて 80GB にしました。

自動設定だと 2133 に落ちる

構成 速度 帯域（memtest 表示） 結果
32GB×2 のみ（自動） DDR4-3200 CL22 43 GB/s 正常
4枚（自動） DDR4-2133 CL15 28.4 GB/s 種類が混ざると JEDEC 標準の 2133 に落ちる
4枚・手動 3200 ― ― メモリトレーニングに失敗し 2133 に戻される
4枚・手動 3000 DDR4-3000 CL22 38 GB/s 合格
  • 4枚挿し（1チャネル2枚＝2DPC）で、しかも XMP を持つものと持たないものが混在すると、自動では 2133 まで下がります
  • XMP をオンにすると 8GB 用の CL16 が 32GB 側にも掛かって不安定になるので、XMP はオフ
  • 手動で 3200 を指定してもトレーニングで弾かれたので、一段落とした 3000 に

最終的な BIOS 設定

ASRock の OC Tweaker → DRAM Configuration で手動設定:

  • DRAM Frequency: DDR4-3000（FCLK 1500MHz で 1:1）
  • タイミング: 22-22-22-52
  • DRAM Voltage: 1.35V
  • XMP: 無効
  • その他: Auto

CMOS クリアや BIOS 更新をすると消えるので、手で入れ直す必要があります（メモしておくのが大事）。

memtest86+ で確認

memtest86+ v7.00 を約5時間。1パス完走＋2パス目 94% まで Errors 0 で合格としました。 80GB・3000 は 64GB・3200 に比べて帯域が約12%落ちますが、容量優先です。memtest の所要時間も容量÷帯域に比例してだいたい 1.4 倍になります。

3200 に再挑戦するなら、VDDCR SOC 1.10V → DRAM 1.40V → ProcODT 調整 → Gear Down 有効 … の順に詰めていく予定です（今は 3000 で安定運用優先）。

起動後は 78GiB と認識され、4枚とも 3000MT/s で動作。VM や常駐サービスも問題なく立ち上がりました。

Strata の導入

Strata は GitHub で公開されているオープンソースの推論エンジンです。モデルを GPU・RAM・SSD の3層に分けて置くのが特徴で、

  • GPU: よく使う部分と、アクセス頻度の高いエキスパート
  • RAM: 全エキスパート（CPU も並列で計算）
  • SSD: 大きなルックアップテーブル（n-gram 埋め込み）

という分担になっています。さらに MTP による投機的デコードで 1.6〜1.8 倍速くしています。

事前チェック

git clone https://github.com/Niko1221/Strata
cd Strata
./setup.sh --check

RTX 3060 12GB・RAM 78GB・AVX2・PCIe 4.0 x16 を認識し、IQ3_XXS は「約60GB 必要・収まる」判定でした。

インストール

./setup.sh --yes --family qwen --model IQ3_XXS --port 8081 --no-start
  • 量子化は IQ3_XXS（Q2_0 / IQ2_XS より遅いが品質重視）
  • うちでは 8080 を別サービス（Open WebUI）が使っているので 8081 に変更
  • ダウンロードは本体 47GB＋29GB、MTP 約5GB
  • この環境向けの配布済みエンジンが無く、CUDA 13.0 で自動コンパイル（約15分） が走りました

起動と実測

cd Strata && ./run-iq3_xxs.sh

OpenAI 互換 API が http://127.0.0.1:8081/v1 に立ちます（127.0.0.1 のみで待ち受け）。

項目 値
読み込み時間 約1分（エキスパート 40GiB を RAM、約5GiB を GPU キャッシュ）
生成速度 約 62 tok/s（手元の Qwen3.6 q4 は約45）
RAM 使用 56〜57GB（残り約21GB）
GPU 使用 11.4GB / 12GB

64GB だと他の常駐分と合わせてかなり厳しかったはずで、80GB にしておいてよかったところです。

品質は落ちたのか ― 同じ6問で比較

3bit 級まで量子化しているので劣化が心配でしたが、同じ6問（reasoning_effort: medium）を解かせた結果がこちら。

# お題 Flash-Next クラウド Flash-Next ローカル IQ3_XXS Qwen3.6 FP8 Qwen3.6 q4
1 abs 抜け 正解 正解（68秒） 不正解 不正解
2 ロック外の読み込み 正解 正解（40秒） 正解 正解
3 10〜12月が空 正解＋追加指摘 正解（54秒） 正解 正解
4 ポイント処理レビュー 良 良（123秒） 中 弱
5 保存クラスレビュー 良 良（117秒） 中 弱
6 実装 22件 22/22 22/22（27秒） 2/22 22/22
  • クラウド版との差は見当たりませんでした。Qwen3.6 に対する優位（原因の見極め・レビューの正確さ）もそのまま
  • レビューでは的外れな指摘も少し混ざりましたが、「問題ではない点」をきちんと切り分けるなど、全体としては良い内容
  • 1問あたり 30秒〜2分

ついでに、普段使っているクラウドモデルとも比べました。

# お題 Flash-Next ローカル DeepSeek-V4.1-Flash（クラウド） Gemma-4-31B（クラウド）
1 abs 抜け 正解 正解 △（説明が誤り）
2 ロック外の読み込み 正解 正解 正解
3 10〜12月が空 正解 正解 不正解
4 ポイント処理レビュー 良 良 弱
5 保存クラスレビュー 良 時間切れ（504） 時間切れ（504）
6 実装 22件 22/22 22/22 22/22
1問の時間 27〜123秒 72〜300秒 90〜300秒

質では ローカル Flash-Next ≧ DeepSeek-V4.1-Flash > Gemma-4-31B。DeepSeek との差は小さく、効いてくるのは「速さ（2〜3倍）」と「長い回答でもタイムアウトしない」点でした。

常駐させるための工夫 ― GPU の譲り合い

このサーバでは Strata 以外にも GPU を使うもの（画像生成の ComfyUI、Ollama のローカルモデル）が動きます。Strata はモデルを載せると GPU を 11.4GB 占有するので、そのままだと取り合いになり、最悪 OOM killer が走ります。

そこで「先に使っている方が優先」というルールにしました。

  • strata.service（systemd user）は受付だけ常駐（RSS 約210MB、GPU ほぼ 0）。リクエストが来たらモデルを読み込み（lazy load）、10分使われなければ下ろす
  • 読み込み前に小さなチェックスクリプト（strata-gpu-guard）を実行
    • ComfyUI が実際に生成中、または Ollama がモデルを載せている → 読み込まず 503（Retry-After 15）
    • ComfyUI が起動しているだけ（キューが空・GPU 使用 1GB 以下）→ ComfyUI を止めてから読み込む
    • GPU の空きが 11000MiB 未満 → 503
  • ComfyUI 側には drop-in で、起動前に Strata へ POST /unload?wait=300 を投げる設定を追加（回答中なら終わるまで待ってから下ろす）
    • 待ち時間が systemd 既定の 90 秒を超えるので TimeoutStartSec=360 も必要でした

最初は systemd の Conflicts= で「後から呼ばれた方が勝つ」排他にしていましたが、生成途中で相手を落としてしまうので、上の形に作り直しました。

つまずいたところ

エージェントから使ったら 32K では足りなかった

AI エージェント（Hermes Agent）から Strata を使おうとしたら「Something went wrong」で停止。 原因は、エージェント側が文脈長 64K 未満のモデルを受け付けない仕様だったこと。Strata は VRAM 12GB だと既定で 32K でした。

設定ファイルの --max-context を 65536 にして解決。GPU 上のエキスパートキャッシュが 5.36→4.88GiB に減りますが、速度への影響は体感ではほぼありません。

設定を変えても古い会話は前のモデルのまま

エージェントの既定モデルを Strata に変えても、既存の会話は会話ごとに保存されたモデル設定で動き続けます。新しい会話を始めると切り替わります。 さらに、要約などの裏方処理が自動で Ollama に流れていて、Ollama がモデルを載せる → 上のチェックで Strata が 503 → 自分で自分を締め出す、という状態になっていました。裏方処理の接続先も Strata に揃えて解消しました。

まとめ

  • 専用機を買わなくても、RAM を足すだけで 125B MoE が実用速度で動く時代になった。RTX 3060 12GB＋DDR4 80GB で約62 tok/s
  • 3bit 級（IQ3_XXS）でも、6問のテストではクラウド版とほぼ同等の品質
  • ボトルネックは GPU ではなく RAM 容量。DDR4 の混在4枚挿しは自動だと 2133 まで落ちるので、手動設定と memtest は必須
  • 常時稼働機で使うなら、GPU を使う他のサービスとの「譲り合い」の設計が要る

運用としては、定期ジョブ中心のメインエージェントは安定性重視でクラウド API のまま、速さが欲しい対話やコード作業は Strata、という使い分けにしています。 RTX 5060 Ti の追加は、速度が足りなくなったときか画像生成を本格化するときに改めて考えるつもりです。

参考

コンピュータ

Gemma4-E4Bだとコンテクストメモリを確保できなかった。。。

コメントする

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

前回の記事でGemma4-E4BをOpenClawのメインモデルとして採用した、と書いたんだけど——

すぐ問題が出た。

コンテキストが足りなくなるんだよね😅

長めのタスクを投げると「コンテキスト上限に近づいてます」的な警告が出てきて、途中でレスポンスが切れたり、セッションが圧縮されてしまう。

E4BはVRAMを9.6GBも使うから、KVキャッシュ（会話履歴を保持するメモリ）に割ける余裕が少ない。 contextTokensを16384（約16K）に制限せざるを得なかったのが原因だった。

「もっとコンテキスト長を伸ばしたい…でもVRAMが足りない…」

というジレンマを解決するために 量子化を落とすという選択をした話です。

E4B vs E2B：量子化の違い

ここで少し技術的な話。

Gemma4には複数の量子化バリアントがある：

バリアント VRAM 量子化 精度
E4B 9.6 GB 4-bit 高め
E2B 7.2 GB 2-bit 低め

量子化（quantization）というのは、モデルの重みを圧縮する技術。 4-bit → 2-bit にすると精度は落ちるが、モデルサイズが約2.4GB削減される。

その削減分をKVキャッシュ（コンテキスト）に回せるのがポイント。

結果として：

  • E4B: contextTokens = 16,384（16K）
  • E2B: contextTokens = 131,072（131K）

コンテキストが8倍になった。エージェント用途ではこれが大きい。

ベンチマーク結果：E2BはE4Bより速い

量子化を落とすと精度が下がる、という一般論があるけど、速度はどうかも気になったのでベンチマークを回してみた。

条件は前回と同じく /api/chat + ツール定義 + think: false。

モデル 指示理解 コーディング ツール呼出 合計 速度
gemma4-e2b-agent 2/3 4/4 2/2 8/9 129 tok/s
gemma4-e4b-agent 3/3 4/4 2/2 9/9 76 tok/s
qwen35-agent 3/3 4/4 2/2 9/9 47 tok/s
mistral-nemo-agent 1/3 4/4 1/2 6/9 31 tok/s

E2Bは 129 tok/s、E4Bは 76 tok/s。

約1.7倍速い。

モデルが軽くなる分、推論が速くなるのは理屈どおりだけど、 ここまで差が出るとは思わなかった（笑）

トレードオフ：精度 vs コンテキスト vs 速度

結果をまとめるとこんな感じ：

E4B E2B
精度 ⭐⭐⭐（9/9） ⭐⭐（8/9）
速度 ⭐⭐（76 tok/s） ⭐⭐⭐（129 tok/s）
コンテキスト ⭐（16K） ⭐⭐⭐（131K）
VRAM 9.6 GB 7.2 GB

E2Bで失点したのは「指示理解」の1問のみ。 具体的には「疑問文の末尾に？をつけてください」という条件を守りきれなかったケース。 コーディングとツール呼び出しは満点。

実用上どちらを選ぶか、というのは用途次第だけど：

  • 短いチャット・精度重視 → E4B
  • 長文コンテキスト・速度重視のエージェント → E2B

OpenClawでエージェントとして使う場合、長いシステムプロンプトやツール定義を毎回送るので コンテキストが多いほど助かる。今の使い方だとE2Bの方が合っている。

openclaw.jsonの設定

参考まで、現在のE2B設定はこんな感じ：

{
  "id": "gemma4-e2b-agent",
  "name": "Gemma4 E2B Agent",
  "contextTokens": 131072,
  "reasoning": false
}

reasoning: false は前回の記事で解説したthinkingモード対策。contextTokens: 131072 でKVキャッシュをフル活用する設定。

ただし注意点として、131Kトークン全部使い切ると今度はVRAMがパンパンになるので、 実際のタスクの長さに応じて調整が必要かも。

まとめ

ポイント 内容
E4Bの問題 VRAM 9.6GB消費でコンテキスト16Kに制限される
E2Bへ切り替え 7.2GBに削減 → コンテキスト131Kに拡大
精度の変化 9/9 → 8/9（指示理解1問失点）
速度の変化 76 tok/s → 129 tok/s（1.7倍速く）
結論 エージェント用途ならE2Bがベストバランス

VRAMが12GBしかない環境でも、量子化を工夫することで長いコンテキストと高速推論を両立できた。

精度的にはE4Bを使いたいところだけど、ないメモリは振れないですね :-)

コンピュータ

自宅RTX 3060でローカルLLMを比べてみたら、エージェントとして使ったら全然違う結果になった話

2件のコメント

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

前回、RTX 3060（12GB VRAM）で5つのローカルLLMをベンチマークしてみた記事を書いた。 結果としては coder14b が満点で圧倒的！という内容だったんだけど…

実際にAIエージェント（OpenClaw）として動かしてみたら、全然違う結果になった😅

「あれ？ベンチマークで高得点だったのに、なんでまともに動かないの？」

という沼にはまった話です。

前回のベンチマーク（/api/generate）の結果おさらい

前回は Ollama の /api/generate エンドポイントでシンプルにテキスト生成させてスコアを出した。

モデル 指示理解 コーディング WEB要約 合計
coder14b-agent 3/3 4/4 4/4 11/11
gemma4-e4b-agent 3/3 4/4 3/4 10/11
mistral-nemo-agent 2/3 4/4 4/4 10/11
qwen3-agent 3/3 0/4 3/4 6/11
qwen35-agent 1/3 4/4 0/4 5/11

この結果を見て「よし、coder14b をメインにしよう！」と思ったんだけど、 実際にエージェントに組み込んだらすぐ問題が出てきた。

問題① thinkingモードで content が空になる

OpenClaw（AIエージェントフレームワーク）は内部で Ollama の /api/chat エンドポイントを使う。 そしてツール定義（function calling の仕様）を一緒に渡す。

ここで Gemma4・Qwen3・Qwen35 が 盛大にこけた。

Ollama のログを見ると：

500 | 59.996s | POST /api/chat

60秒でタイムアウト。毎回。

原因を調べてみると、これらのモデルは「thinkingモード」を持っていて、 ツール定義を受け取ると思考プロセスを <think>...</think> トークンに費やしてしまう。 その結果、実際の content フィールドが 空文字列 になってしまうのだ。

{
  "content": "",
  "thinking": "Let me analyze the tools available..."  // ← これが問題
}

エージェント側は空のレスポンスを受け取って「タイムアウトかな？」と判断 → フェールオーバー。 という流れで、何度やっても落ちていた。

問題② coder14b はネイティブ tool_calls に非対応

一方、coder14b はというと…こちらは別の問題。

ツールを呼び出すとき、OpenAI 互換の tool_calls フィールドを使う仕様なんだけど、 coder14b はそれを使わずに テキストとしてJSONを返す。

// 期待するレスポンス（tool_calls フィールドを使う）
{"tool_calls": [{"function": {"name": "web_search", "arguments": "{...}"}}]}

// coder14b が実際に返すもの
```json
{"name": "web_search", "arguments": {...}}


エージェントが「ツールを呼んだ」と認識できないので、正常に動作しない。

---

## 解決策：`reasoning: false` を設定する

調べてみると、OpenClaw の設定ファイル（openclaw.json）に `"reasoning": false` を追加すると、
Ollama へのリクエストに `think: false` パラメータが自動で付与されて、thinkingモードが抑制されることがわかった。

```json
{
  "models": [
    {
      "provider": "ollama",
      "modelId": "gemma4-e4b-agent",
      "reasoning": false
    }
  ]
}

これを設定してから再テストしたら、Gemma4もQwen系もちゃんと動くようになった🎉

改訂版ベンチマーク（/api/chat + think:false）

今度は実際のエージェント動作に近い条件でテスト。/api/chat エンドポイント + ツール定義 + think: false を使用。

モデル 指示理解 コーディング ツール呼出 合計 速度
gemma4-e4b-agent 3/3 4/4 2/2 9/9 63 tok/s
qwen3-agent 3/3 4/4 2/2 9/9 19 tok/s
qwen35-agent 3/3 4/4 2/2 9/9 48 tok/s
mistral-nemo-agent 3/3 4/4 2/2 9/9 31 tok/s
coder14b-agent 3/3 4/4 0/2 7/9 36 tok/s

結果が がらっと変わった。

前回のベンチマーク覇者だった coder14b は、ツール呼び出しで 0/2 という惨敗。 逆に Gemma4・Qwen3・Qwen35・mistral-nemo は全員満点🏆

前回の「Qwen3が低スコア」も、thinkingモードのせいだったということが判明。 あれ、全然 Qwen3 が弱かったわけじゃなかった（笑）

MVPは Gemma4-E4B

速度と精度のバランスを考えると Gemma4-E4B が最強という結論になった。

  • 全テスト満点（9/9）
  • 速度は 63 tok/s でトップクラス
  • RTX 3060 12GB に収まる（~9.6GB VRAM）

Qwen3.5 も満点で 48 tok/s と速く、サブモデルとして優秀。

というわけで、OpenClaw のメインモデルを gemma4-e4b-agent に切り替えた。

教訓：「ベンチマーク環境 ≠ 実際の使用環境」

今回の一番の学びはこれだった。

/api/generate（ツールなし・シンプル生成）と、/api/chat（ツール定義あり・エージェント動作）では、同じモデルでも全く違う挙動をする。

特に thinking モード搭載モデルは、ツールと組み合わせると無音になるという罠がある。 これ、知らなかったら永遠に「なんか不安定だな〜」で終わってた気がする。

ローカルLLMをエージェントとして使いたい人は、必ずエージェント条件でテストしてね！

まとめ

ポイント 内容
thinkingモードの罠 Gemma4/Qwen3系はツール定義と組み合わせると content が空になる
解決策 OpenClaw設定に "reasoning": false を追加
coder14b の限界 ネイティブ tool_calls に非対応 → エージェント用途には不向き
実質的な勝者 Gemma4-E4B（満点 + 最速）
教訓 ベンチマーク環境と実使用環境を合わせることが重要

自宅 GPU でローカル LLM を動かすの、なかなか沼ですが楽しいです😄 同じ環境で試してみたい人の参考になれば！

コンピュータ

自宅RTX 3060でローカルLLMを5モデル比べてみた結果が面白かった

1件のコメント

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

※この記事には間違いがありました。自宅RTX 3060でローカルLLMを比べてみたら、エージェントとして使ったら全然違う結果になった話で続編を書いているのでご参照ください。

最近、自宅のLLMサーバーに色々なモデルを詰め込んでいて、「結局どれが一番使えるの？」という疑問が積もってきたので、ちゃんとテストしてみました。

環境は以前書いた通り、Ollama + RTX 3060 (12GB VRAM) の構成です。

テストしたモデル

今回は「agentとして使う」という想定で、以下の5モデルを対象にしました。

モデル ベース サイズ
coder14b-agent Qwen2.5-Coder-14B 9.0GB
qwen3-agent Qwen3:14B 9.3GB
gemma4-e4b-agent Gemma4 E4B 9.6GB
qwen35-agent Qwen3.5:9B 6.6GB
mistral-nemo-agent Mistral Nemo 12B 7.1GB

モデルはすべてOllamaのカスタムエイリアスとして登録済みで、コンテキスト長を8192〜16384に制限して運用しています（VRAMが12GBしかないので）。

評価した3つの能力

AIエージェントとして使うことを想定して、以下の3カテゴリで評価しました。

① 指示理解力 複数の条件（出力形式・文字数・テーマ）を同時に守れるか。「全部読んでちゃんとやって」ができるかどうかですね。

② Pythonコーディング力 関数の実装 + unittestの作成をセットで依頼。正しいアルゴリズムを選べるかも見ました。

③ WEBサーチ＆要約力 ツール呼び出しの記述と、渡した検索結果を構造化してレポートにまとめる力を評価。エージェントとして一番重要なスキルかもしれません。

結果

モデル 指示理解 コーディング WEBサーチ 合計 速度
coder14b-agent 3/3 4/4 4/4 11/11 35 tok/s
gemma4-e4b-agent 3/3 4/4 4/4 11/11 66 tok/s
mistral-nemo-agent 3/3 4/4 4/4 11/11 30 tok/s
qwen3-agent 3/3 0/4 3/4 6/11 19 tok/s
qwen35-agent 1/3 4/4 0/4 5/11 47 tok/s

各モデルの感想

coder14b-agent（Qwen2.5-Coder-14B） 安定感が抜群です。コーディングテストでは seen = set() を使った素直な実装で、unittestも丁寧に書いてくれました。WEBサーチも手順を分けて記述してくれて、「指示通りに動く」という信頼感があります。

gemma4-e4b-agent（Gemma4 E4B）🏆 今回のMVPです。全項目満点で、しかも66 tok/sと断トツの速さ。コードには型アノテーションまで付いてきて、品質も高い。RTX 3060で66 tok/sは体感でもかなり快適です。これをメインに使います。

mistral-nemo-agent（Mistral Nemo 12B）dict.fromkeys(items) というPythonicな1行実装を使ってきたのがツボでした 🙂。出力が無駄なく簡潔で、サブタスクをこなすエージェントとして向いている気がします。

qwen3-agent / qwen35-agent 正直、期待を裏切られました。Qwen3系はいわゆる「思考モード（<think>タグ）」を持っていて、num_predictの上限まで思考トークンを消費し切った結果、実際の回答が空っぽになるケースが発生。qwen3-agentはPythonコーディングで0点、qwen35-agentはWEBサーチで0点でした。

思考モードを無効化するオプションを試せばまた変わるかもしれないので、別途チューニングしてみます。

まとめ

用途 おすすめ
普段使いのエージェント gemma4-e4b-agent（速くて賢い）
コーディング特化 coder14b-agent（丁寧・安定）
軽量サブタスク mistral-nemo-agent（簡潔）
Qwen3系 要チューニング

ローカルLLMは「ランキング上位のモデルが実用でも強いとは限らない」という教訓がありますが、今回はGemma4が思いのほか優秀でした。Googleのモデルを見直しています 笑。