Codex CLIでGemma 4をローカルモデルとして実行する
(blog.danielvaughan.com)- Gemma 4をクラウドではなくローカルのCodex CLI環境で実行し、ツール呼び出しの性能と安定性を検証した事例で、GPT-5.4と比べてコスト・プライバシー面の利点を確認
- Mac(M4 Pro) 24GBでは26B MoE、NVIDIA GB10 128GBでは31B Denseを用い、それぞれllama.cppとOllamaを使って同一のコード生成タスクを実行し、設定差による性能を比較
- ツール呼び出し成功率が6.6%から86.4%に向上し、ローカルモデルの実用可能性が実証され、GB10環境では完全なコード生成を達成
- Macは5.1倍高速なトークン生成速度を示したが、メモリ制約と量子化設定のため反復的な試行が必要で、GB10は遅いものの初回試行で成功
- 結果としてローカルモデルでも実務レベルのコード生成が可能であり、プライバシー重視のローカル処理と複雑な作業のクラウド切り替えを併用するハイブリッドアプローチを推奨
ローカルモデルへ移行した動機
- コストの問題として、Codex CLIを1日に複数セッション、時には並列で実行する中でAPI料金が積み上がる
- プライバシー要件として、一部のコードベースは外部サーバーへ送信できない
- 安定性確保の必要性として、クラウドAPIにはスロットリング・障害・価格変更のリスクがある
- 以前ローカルモデルを試さなかった理由は**ツール呼び出し(tool calling)**ができなかったためであり、Codex CLIの核心的価値は、モデルがファイル読み取り、コード作成、テスト実行、パッチ適用を行える点にある
- 以前のGemma世代はtau2-benchの関数呼び出しベンチマークで6.6%（100回中93回失敗）だったが、Gemma 4 31Bでは**86.4%**まで跳ね上がり、試す価値が生まれた
Macでの設定手順
- Ollamaから始めたが、v0.20.3ではGemma 4のツール呼び出し応答が
tool_calls配列ではなくreasoning outputへ誤ってルーティングされるストリーミングバグが発生 - Apple SiliconでGemma 4を使うと約500トークン超のプロンプトでFlash Attention freezeが発生し、Codex CLIのシステムプロンプトは約27,000トークンのため事実上利用不能
- llama.cppへ切り替えてHomebrewで導入し、動作するサーバーコマンドには6つの重要フラグが必要
-np 1: スロットを1つに制限。複数スロットはKVキャッシュメモリを倍増させる-ctk q8_0 -ctv q8_0: KVキャッシュ量子化により940MBから499MBへ削減--jinja: Gemma 4のツール呼び出しテンプレートに必須-mにはGGUFパスを直接指定する必要があり、-hfフラグを使うと1.1GBのビジョンプロジェクターが自動ダウンロードされ、OOMクラッシュを引き起こす
- Codex CLI設定では
web_search = "disabled"が必須。llama.cppが拒否するweb_search_previewツールタイプをCodex CLIが送信するため
GB10での設定手順
- vLLM 0.19.0はPyTorch 2.10.0ベースでコンパイルされているが、aarch64 Blackwell(compute capability sm_121)向けCUDA対応PyTorchは2.11.0+cu128しかなく、ABI不一致で
ImportErrorが発生 - llama.cppをCUDA付きでソースビルドするとコンパイルとベンチマークは通るが、Codex CLIの
wire_api = "responses"が送る非関数ツールタイプをllama.cppが拒否 - Ollama v0.20.5で成功。Apple Siliconで発生したストリーミングバグはNVIDIAでは再現しなかった
ollama pull gemma4:31bを実行後、SSHトンネルでポート11434をMacへフォワード（Codex CLIの--ossモードがlocalhostしか確認しないため）codex --oss -m gemma4:31bでテキスト生成とツール呼び出しの両方が初回試行で動作
- Macの設定には午後の大半を要した一方、GB10はモデルダウンロード待ちを含めても約1時間で完了
ベンチマーク結果
- 3つの構成すべてに同じタスクを付与:
codex exec --full-autoで**parse_csv_summary** Python関数を作成し、エラーハンドリングを含め、テストを書いて実行 - GPT-5.4（クラウド）: 型ヒント、適切な例外チェイニング、ブール型検出、整理されたヘルパー関数を含むコードを生成し、5つのテストが初回で通過、65秒で完了、後処理の整理も不要
- GB10 31B Dense: 型ヒントやブール検出はないが堅牢なエラーハンドリング、デッドコードなし、3回のツール呼び出しで5つのテストが初回通過、7分所要
- Mac 26B MoE: 実装部にデッドコードが残り、型推論ループを書いたあと放置し、その下に 'Actually, let's simplify' コメントを付けて書き直し、テストファイル作成に5回の試行が必要
- 毎回異なるheredocエラーが発生:
filerypt→file_path,encoding=' 'utf-8'（空白挿入）,fileint(file_path)など - GB10が3回で完了した作業に10回のツール呼び出しを要した
- この結果は24GB
Q4_K_MCodex CLI環境でのものであり、Gemma 4のApple Silicon全般に対する一般的評価ではない
- 毎回異なるheredocエラーが発生:
速度分析: Macが予想より速かった理由
- llama-benchで同じコンテキスト長における両マシンを測定したところ、MacはGB10よりトークン生成が5.1倍高速
- 両マシンとも273 GB/s LPDDR5Xメモリ帯域幅だが、トークン生成はメモリ帯域幅制約の処理
- 31B Denseは各トークンごとに312億個の全パラメータを読み込む（約17.4GB）
- 26B MoEは各トークンごとに38億個のみが有効化される（約1.9GB）
- 同一帯域幅でMacは52 tok/s、GB10は10 tok/sを記録
- プロンプト処理速度も予想に反してMacが健闘: 8KコンテキストでMac 531 tok/s vs GB10 548 tok/s、MoEの疎活性化がプロンプト処理にも有利に働いた
重要な教訓: トークン速度より初回成功率
- Macはトークン生成が5.1倍速いが、最終完了時間は30%短縮にとどまる（4分42秒 vs 6分59秒）
- 時間差の要因は再試行: 10回のツール呼び出し vs 3回、5回のテスト作成失敗、モデルが片付けなかったデッドコード
- クラウドモデルはこれをさらに明確に示す。最速でトークン使用量も最小、修正パスも不要で、5/5を65秒で完了
- それでもローカルは実用的であり、両マシンともテストを通る動作コードを生成できた
- Gemma 3（ツール呼び出し6.6%）からGemma 4（86.4%）への品質差が決定的な転換点であり、「動かない」から「動く」への段階がローカルのエージェント型コーディングを実用化する転機となった
- Macの結果に関する補足:
Q4_K_Mは24GBマシンでメモリに収まる最高量子化であり、より余裕のあるApple Siliconで高い量子化を用いて再実行すれば結果が変わる可能性がある - ハイブリッドアプローチも可能:
codex --profile localで反復作業やプライバシー機微な作業を処理し、複雑な作業はクラウド既定値を使う。Codex CLIのプロファイルシステムなら切り替えはフラグ1つ
設定時の実用的なヒント
- Apple Silicon: OllamaはGemma 4では使えず、llama.cpp +
--jinjaを推奨- Codex CLIプロファイルで
web_search = "disabled"を設定 -mでGGUFパスを直接指定し、-hfは使わない- コンテキストは32,768に設定（Codex CLIのシステムプロンプトに最低27,000トークン必要）
- KVキャッシュ量子化:
-ctk q8_0 -ctv q8_0
- Codex CLIプロファイルで
- NVIDIA GB10: Ollama v0.20.5が最初に安定動作した経路で、
codex --oss -m gemma4:31bを使用。リモートマシンならSSHでポート11434をトンネリング - プロバイダー設定では
stream_idle_timeout_msを最低1,800,000に設定する必要がある。Macでは単一のツール呼び出しサイクルに1分39秒かかり、既定タイムアウトだとセッションが終了する - llama.cppはバージョン固定を推奨。ビルド間で3.3倍の速度低下が報告されており、ベンチマークが一晩で変動しうる
6件のコメント
会社で H100 2枚を使って Gemma4-31B を運用してみたところ、
全体的に、小さくて機敏な動作を求めるなら Gemma4 で十分だと思います。私は GPT-OSS-120B → Qwen3.5-35B-A3B に置き換えたあと、今は Gemma4-31B に落ち着きましたが、かなり満足しています。このまま使い続けることになりそうです.
えっ、Web検索が使えないなんて！
searxngを構成しても使えないんですか？https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md
このスキルの代わりに使ってみてください（笑）
日本語もちゃんと動くのか確認してみたいですね
Hacker Newsのコメント
Gemma 4 26Bは、同じパラメータ規模のモデルの中では本当に例外的な性能を示していた
内部ベンチマークではGPT 5.2、Gemini 3 Pro Previewと近いスコアを出していたが、エージェント型コーディングと非コーディングの意思決定領域では弱かった
ツール使用、反復的改善、大規模コンテキスト管理などでスコアが低く、むしろツールを使うべき状況では性能が下がっていた
おそらく一般的なハーネスやベンチマークにオーバーフィットしているようだ。それでもMシリーズMacbookでの速度は驚異的
ベンチマークはgertlabs.comで確認できる
「1次元bin fitting計算機を単一のWebページとして実装せよ」という課題だったが、Qwen3.5、Nematron、Step 3.5、gpt-ossは通過した一方でGemmaはだめだった
ただ、自分のM5ではGPT-OSSより単純なコーディングミスを頻繁に起こした。それでも全体としては近いレベル
「モデル品質がトークン速度より重要だ」という結果に驚いたという声があった
実際には当然の話に聞こえる。コンテキストサイズを32kに制限する代わりに、
--cpu-moeオプションでMoE演算をCPUにオフロードすることもできるトークン速度だけが速ければ、結局「AIスロップコードベース」が爆発的に増えるだけだろう
自分はいまM3 Ultra（48GB RAM）でLM StudioとOpencodeを使って
google/gemma-4-26b-a4bを動かしているコンテキストを65536まで増やす必要はあったが、うまく動いている。ZedやACPとも簡単に連携できる
主に簡単なコードレビューやフロントエンドコード生成に使っている
システムプロンプトとツールオーバーヘッドが2kトークン未満なので、プリフィル遅延がかなり短い
速度は約100t/sでほぼ即時応答に近く、Claude Codeを使う頻度がだんだん減ってきた
チャットボットとしては悪くないが、XCode連携には不向きだった
いまはGoogle APIの1日1500回の無料リクエストを活用している
LM Studio 0.4.11+1のアップデート前はツール呼び出しが動かなかったが、今はCodexとOpencodeの両方で問題なく動く
「ローカルモデルはツール呼び出しができない」というのは誤り
すでに2年前からローカルでもツール呼び出しをしてきたし、Gemma3のツール呼び出し成功率が7%というのはありえない
Llama3.3でも最低75%は出ていた
Gemma 4 gguf Q4（16GB）のように過度に量子化されたモデルは性能がかなり落ちる
GB10マシンがあるなら、spark-vllm-dockerのセットアップやQwen 3.5 122B A10B最適化版を試すのを勧める。50tk/sほどでかなり速い
M4 Pro（24GB）からM5 Pro（48GB）にアップグレードしたところ、同じGemma 4 MoE（Q4）でt/sが8倍高速になった
ディスクからメモリへのロード速度も2倍向上した
MLX版を使っているか確認したほうがいい。mlx-lmのコミュニティ量子化版は最近修正された
自分は16GBのM1 Macbookでは厳しかったが、64GB RAMのAMD Framework 13ではCPUだけでも十分速く動く
プロンプトキャッシュ機能は大きなシステムプロンプトを差し込むときに便利
ローカルハードウェアを24/7で動かしてGemma 4のようなモデルで実験を自動化し、大きな判断はClaude Opusに任せるというハーネスのアイデアを提案していた
ローカルモデルが小さな実験やPOCを実行し、行き詰まったらOpusに助けを求める構成
こうすればプロンプトキャッシュを完全に制御でき、コストもほとんどかからない
デモ動画とpi-model-switchリポジトリを参照できる
コーディング用途では、Q6_K以下の量子化には意味がない
それより低い量子化ではコードエラー率が急激に上がる
メモリが許す限り、できるだけ高い量子化を使うのがよい
Q4_K_M、Q8_0、Q6_Kなど量子化方式ごとの品質比較があればいいのにと思う。単純なtok/sの数値より有用そう
Qwen3.5とGemma 4の比較が気になる
特にQwen3.5-27B-Claude-4.6-Opusモデルはツール呼び出しに特化しており、ダウンロード数も50万回を超えている
Qwenモデルはオーケストレーション中にエラー修正の要求が多く、生産性が落ちた
Ollama向けウェイトで動かしていた
最新版はQwopus3.5-27B-v3
ここ数日Gemma 4を使ってみたが、速くて賢い一方でツール使用の問題は依然としてある
速度より知能の限界が生産性を制約している。ループにはまることが多い
こうした状況を検知して、より賢いモデルに「助けを求める」ことができればよいのだが
もはやコーダーというよりエージェントオーケストレーターとして働いている。複数のエージェントを並列に走らせて管理する役割だ
chat_template.jinjaとtokenizer_config.jsonを差し替えたツール呼び出し関連の問題を解決したとのことなので、モデルを更新したほうがよい
ollamaでローカル LLM の構成は簡単ですが、オープンソースモデルごとにツール呼び出しが失敗する可能性が高いそうです。ollama内部の緩い規約と、モデルごとのツール呼び出しパーサーの問題が絡んでいるとのことです。実際のところ、Local LLM の最も根本的な問題は、中〜大規模モデルを動かすには高価なハードウェアが必要だということです。Mac Studio 32GB モデルが 300万円台半ば、GB10 は 500〜600万円程度なので、個人が趣味（?）のために購入するには負担が大きいです。Local LLM は小型モデル向けで、中〜大規模モデルは Cloud 以外に選択肢がありません。