評判の最新ローカル LLM、ガチで動かしてみたら 3 連敗した話 — CodeRouter v1.8.1 で「実機 evidence first」に方針転換

ローカル LLM 界隈を眺めていると、新しいモデルがリリースされる度に X や r/LocalLLaMA で「Claude Code 代替として最高」「local champ」「Opus 級」みたいな絶賛が並びます。これを真に受けて自分の Mac で動かそうとすると、普通に動かないことが結構あります。

私は CodeRouter という Claude Code 用のローカル LLM ルーターを開発していて、つい昨日 v1.8.0 で 用途別 4 プロファイル（multi/coding/general/reasoning）+ note 推奨モデル群（Qwen3.6 / Gemma 4 / GLM）を一括登録する minor リリースを出しました。

そして実機検証の段階で、3 つのモデルで連敗した知見を v1.8.1 patch として反映したので、その記録です。

検証環境

• マシン: M3 Max 64GB unified memory

• Ollama: 0.21.2 （現時点で最新クラス）

• CodeRouter: v1.8.0 → v1.8.1

• Claude Code: ANTHROPIC_BASE_URL を CodeRouter (localhost:8088) に向ける構成

doctor コマンド (coderouter doctor --check-model X) は CodeRouter に組み込まれている、6 種類のプローブを実プロバイダに走らせて挙動を確認するツールです。auth+basic-chat / num_ctx / tool_calls / thinking / reasoning-leak / streaming の 6 観点で「宣言と実機の差」を出してくれます。

連敗 1: Qwen3.6:27b（note "local champ" の罠）

note の比較記事で「Claude Code 代替として最高」「local champ」と評されている Qwen3.6-35B-A3B（および軽量版の 27B）。Ollama 公式 tag (qwen3.6:27b / qwen3.6:35b) が並んでいて、すぐ pull できる。

意気揚々と pull して coderouter doctor --check-model ollama-qwen3-6-27b を回したら：

[1/6] auth+basic-chat …… [OK]
[2/6] num_ctx ………………… [NEEDS TUNING]
      canary 'ZEBRA-MOON-847' missing from reply — upstream truncated the prompt.
[3/6] tool_calls ………… [NEEDS TUNING]
      declaration says tools=true but model produced neither native `tool_calls` nor repairable tool JSON.
[6/6] streaming ………… [NEEDS TUNING]
      stream closed with `finish_reason='length'` after only 0 chars (expected ≥ 40).

3 つの probe が NEEDS_TUNING。doctor の --apply で patch（extra_body.options.num_ctx: 32768、num_predict: 4096）を当てると、しかし：

[2/6] num_ctx ………………… [NEEDS TUNING]
      canary missing even with num_ctx=32768 declared.
      The model's intrinsic context limit may be shorter than the declared value,
      or the upstream is silently capping it.

doctor の出力的には「32768 を declare しても実体側が縮めてる」状態。最初は「メモリ不足で Ollama が silent cap してるのでは」と疑ったんですが、M3 Max 64GB だと 27B GGUF (16GB 程度) を載せても余裕があるので、メモリ起因ではない。

切り分けで残るのは次のいずれか：

1. OpenAI 互換層で extra_body.options.num_ctx が Ollama 本体まで届いていない（/api/generate ではなく /v1/chat/completions 経由のときだけの fall-through）

2. GGUF 側の intrinsic context が declare より短い（変換時の rope/scaling パラメータの取りこぼし）

3. Ollama 0.21.2 の Qwen3.6 系 chat template / tool 仕様がまだ未成熟で、tool_calls が parse されず streaming も length で即終了

Qwen3 系の /no_think で thinking モード抑制を試したり、output_filters を空にして strip の影響を切り分けても streaming が 0 chars 打ち切りな点は変わらないので、CodeRouter 側の問題ではなさそう。Modelfile で PARAMETER num_ctx 32768 を焼き込む経路はまだ未検証で、これは TODO。

note 記事の評価が「嘘」だったわけではなくて、HF や vLLM 直叩きなら違う挙動かもしれないけど、Ollama 0.21.2 経由の Qwen3.6 系はまだフレームワーク側が追いついていない、というのが現時点の理解です。

ユーザー視点では「note で絶賛 → ollama pull → 動かない」がワンセットで降ってくる悲しさ。

連敗 2: Qwopus3.5-9B（Qwen3.5 + Opus 蒸留、HF 評価高い）

「Qwen3 系の Opus 蒸留モデル試したい」と思って HF 検索すると、Jackrong さんの Qwopus3.5-9B-v3-GGUF が出てきます。Qwen3.5-VL ベース + Claude Opus 蒸留、Apache-2.0、165k DL、323 likes。十分人気で安定してそう。

ollama pull hf.co/Jackrong/Qwopus3.5-9B-v3-GGUF:Q4_K_M
# pulling 5.6 GB GGUF + 921 MB mmproj + 設定 = 5 blob、全部成功
ollama run hf.co/Jackrong/Qwopus3.5-9B-v3-GGUF:Q4_K_M "say hello"

Error: 500 Internal Server Error: unable to load model:
  /Users/h.yamamoto/.ollama/models/blobs/sha256-19d52ddc...

500 エラー。Ollama server log を見ると：

llama_model_load: error loading model: error loading model architecture:
  unknown model architecture: 'qwen35'

新アーキテクチャ qwen35 を llama.cpp が知らない。GGUF metadata を覗くと qwen35.ssm.conv_kernel、qwen35.ssm.state_size、qwen35.full_attention_interval のような hybrid Transformer-SSM 系のキーが並んでいる。Qwen3.5 は新しいアーキテクチャらしい。

これは Ollama version 古いとかではなくて（0.21.2 は最新クラス）、llama.cpp 本体に qwen35 architecture の実装が未マージ。フレームワーク本体の対応を待つ必要があり、ユーザーレベルでは詰み。

教訓：ollama pull 完走しても ollama run が 500 出すパターンは architecture 未対応。Ollama server log で unknown model architecture を見たら今は諦めるのが時間効率良い。

連敗 3 …… ではなく逆転 — Gemma 4 26B が無加工で tool_calls OK

ここまで 2 連敗して、note 記事の「Gemma 4 が日常の王者」評価を試そうと最後の希望で：

ollama pull gemma4:26b   # 18 GB GGUF
coderouter doctor --check-model ollama-gemma4-26b

[1/6] auth+basic-chat …… [OK]
[2/6] num_ctx ………………… [NEEDS TUNING]
[3/6] tool_calls ………… [OK]    ← !!
      native `tool_calls` observed; matches declaration.
[5/6] reasoning-leak …… [OK]
[6/6] streaming ………… [NEEDS TUNING]

tool_calls が無加工で [OK]。これが今日の最大の発見。num_ctx と streaming は doctor --apply で patch を当てれば解消できる。Gemma 4 26B は MoE で active 3.8B、18 GB GGUF + α で 64GB Mac なら余裕で乗る（24GB クラスでも実用範囲）。

note 記事の「Gemma 4 ＝ 日常・バランスの王者」評価が、Claude Code agentic 用途でも裏付けられた瞬間でした。

v1.8.1 で何を変えたか

実機 evidence を反映した patch release を出しました。

1. examples/providers.yaml の coding profile primary を入れ替え

# 旧 (v1.8.0):
- name: coding
  providers:
    - ollama-qwen3-6-35b      # ← 実機で動かない
    - ollama-qwen3-coder-30b
    - ollama-qwen-coder-14b
    ...

# 新 (v1.8.1):
- name: coding
  providers:
    - ollama-qwen-coder-14b   # ← 実機検証済みの枯れた選択
    - ollama-gemma4-26b       # ← 無加工 tool_calls OK
    - ollama-qwen-coder-7b
    - ollama-qwen3-coder-30b  # ← agentic 専用 (llama.cpp 対応)
    # Qwen3.6 系は末尾退避線にコメントアウトで降格
    ...

順序原則は「枯れて確実に動くものを上、note 推奨で新しいものは安定確認後に昇格」。

2. claude_code_suitability: ok の撤回

CodeRouter の bundled model-capabilities.yaml で qwen3.6:* に claude_code_suitability: ok を declare していたのを 撤回。これは v1.7-B (note 記事を読んだ時点) で先回り宣言したフラグだったが、実機で動かない以上 declaration 過信は害。

# 旧:
- match: "qwen3.6:*"
  capabilities:
    tools: true
    claude_code_suitability: ok   # ← 撤回

# 新:
- match: "qwen3.6:*"
  capabilities:
    tools: true   # tools の事実は維持
    # claude_code_suitability は実機検証で OK 確認できるまで宣言しない

実機で動いた人は user 側 ~/.coderouter/model-capabilities.yaml で claude_code_suitability: ok を override 可能。

3. docs/troubleshooting.md §4-2 新設

「ローカル Ollama 経由で踏みやすい既知問題」として、4 サブセクションで詳細記録：

• §4-2-A: Qwen3.6:27b/35b の 3 重 NEEDS_TUNING、/no_think でも改善せず

• §4-2-B: Qwen3.5 系 (Qwopus 等) は llama.cpp qwen35 architecture 未対応で unable to load model

• §4-2-C: Gemma 4 26B 無加工 tool_calls OK

• §4-2-D: ベスト実践「枯れたモデル + 観測ツール（doctor）」

4. loader bug fix (副次的)

ついでに、v1.8.0 で導入した用途別 4 プロファイルが NIM example yaml ベースのユーザーで cr serve --mode coding が validation エラーで起動失敗するバグも修正。CODEROUTER_MODE env が mode_aliases を経由せず直接 default_profile に代入されていた v0.6-A の素朴実装を、runtime の X-CodeRouter-Mode ヘッダと symmetric に揃えました。

振り返り — 「先回り実装より実機 evidence」

これは CodeRouter の plan.md §5.4 に書いたプロジェクト原則そのものです：

v1.7-B → v1.8.0 で「note 記事の推奨モデル」を片っ端から登録したのは、ある意味で先回り実装でした。実機で動くかは v1.8.0 出荷後に確認するしかなく、実際 3 つ中 2 つ詰んだ。

教訓：

1. note / r/LocalLLaMA / HF 評判は重要だが、Ollama 経由の動作は別軸の問題

2. 新しい architecture は llama.cpp の実装待ちで、ユーザー側で何ともならない

3. declaration（registry の tools: true / claude_code_suitability: ok）は仮説であって、実機検証で裏付けてから初めて信用できる

4. doctor で 6 probe を回せば 30 秒で「動くかどうか」がわかる — これが CodeRouter の実用価値の中核

「動くもの」を見つけるのが遠回りに見えても、それが結局一番速い。

v1.8.1 の入手方法

PyPI に出した v1.8.1：

# 既存ユーザー
uv tool upgrade coderouter-cli

# 新規ユーザー
uvx coderouter-cli serve --port 8088 --mode coding

--apply 機能（doctor の YAML パッチ自動書き戻し）を使うなら：

uv tool install --reinstall coderouter-cli --with ruamel.yaml

または pip install 'coderouter-cli[doctor]'。

まとめ

「note で絶賛されてる最新モデル → Ollama に pull → Claude Code から叩く → 動かない」という現実を、v1.8.1 で 3 段の対策で吸収しました：

1. doctor で 6 probe を回して動作確認

2. --apply で YAML パッチ自動適用

3. 動かなかったら chain の primary から外して、cloud (NIM / OpenRouter free) や枯れたローカル (qwen2.5-coder:14b / gemma4:26b) に流す

これでようやく Phase 2（Claude Code 実プロンプト）に進める状態。残りは実運用しながら追加の発見をフィードバックしていく形です。

ローカル LLM 界隈で「動くモデル探し」に時間使ってる方の参考になれば幸いです。

質問・感想は GitHub Issues または X (@zephel01) までどうぞ。

（リリース日: 2026 年 4 月 26 日 / バージョン: v1.8.1）

続編 (v1.8.2)

この記事を書いた翌日、Gemma 4 26B の num_ctx [NEEDS_TUNING] の正体を深掘りしたら、自分が作った doctor probe の偽陽性に騙されていたことが判明しました。3 連敗のうち 1 つは実は完全勝利だった話 → 自分が作った診断ツールに自分が騙された話 (v1.8.2)。

v1.8.2 で確定した結論:

• Gemma 4 26B: 実機完全動作確定 (/v1/messages で "Hello." が 2 秒応答)。doctor の num_ctx / streaming NEEDS_TUNING は thinking モデルの reasoning トークン消費分を見ていない max_tokens=32/128 バジェットによる偽陽性だった

• Qwen3.6 系: tool_calls [NEEDS TUNING] だけが本物の課題として残る (Ollama 経由の tool 仕様未成熟、thinking 起因とは別の問題)

• Qwopus3.5 系: llama.cpp qwen35 architecture 未対応は変わらず (フレームワーク本体の対応待ち)