ハクソク

世界を動かす技術を、日本語で。

Codex CLIでローカルモデルとしてGemma 4を実行しました

27日前原文(blog.danielvaughan.com)

概要

  • Gemma 4のローカル推論 が実用的か、MacBook ProとDell GB10で検証
  • コスト・プライバシー・レジリエンス の観点からローカルモデル導入を検討
  • セットアップの難易度 やトラブルシューティングの詳細な記録
  • ベンチマーク結果 とモデルアーキテクチャの意外な発見
  • 品質重視の結論 と実践的なハイブリッド運用の提案

Gemma 4ローカル推論比較：MacBook Pro vs. Dell GB10

  • 目的 ：Gemma 4が日常的なエージェント的コーディングにおいてクラウドモデルの代替となるか実践検証
  • 利用環境 ：
    • MacBook Pro 24GB（M4 Pro、llama.cppによる26B MoE）
    • Dell Pro Max GB10（128GB、NVIDIA Blackwell、Ollama v0.20.5による31B Dense）
    • 両者ともCodex CLIのカスタムプロバイダーとして設定
  • クラウドモデル ：GPT-5.4（Codex CLI標準、比較用）

ローカルモデル導入の動機

  • コスト削減 ：API利用料の増大回避
  • プライバシー保護 ：機密性の高いコードベースの外部送信防止
  • レジリエンス向上 ：クラウドAPIの制限や障害、価格変更リスク回避

過去の課題とGemma 4の進化

  • ツールコール機能 の未熟さが障壁
    • 旧Gemmaはtau2-benchで6.6%（約93%失敗）
    • Gemma 4 31Bは86.4%達成、実用レベルへ進化

セットアップ詳細とトラブル

  • MacBook Pro ：
    • Ollamaはバグ・フリーズで利用不可
    • llama.cpp（Homebrew経由）で動作
      • 重要フラグ ：-np 1（スロット数制限）、-ctk/-ctv q8_0（KVキャッシュ量削減）、--jinja（ツールコールテンプレート）、-m（直接パス指定）
      • Codex CLIのweb_search = "disabled"必須
    • セットアップ所要時間 ：半日程度、情報が分散・未整理
  • Dell GB10 ：
    • vLLMはPyTorchバージョン不一致で失敗
    • llama.cpp（CUDAビルド）はCodex CLIとの互換性問題
    • Ollama v0.20.5で即動作
      • SSHトンネルでMacから利用
    • セットアップ所要時間 ：1時間程度（モデルDL待ち含む）

ベンチマークと品質比較

  • タスク ：parse_csv_summary関数の実装・テスト生成・実行
  • 結果 ：
    • GPT-5.4 ：型ヒント・例外処理・補助関数も完璧、65秒、初回全テスト合格
    • GB10 31B Dense ：型ヒント・bool判定はなし、堅実な実装、7分、初回全テスト合格
    • Mac 26B MoE ：デッドコード残存、型推論ループの書き捨て、テスト5回失敗、10回のツールコール、4分42秒

モデルアーキテクチャによる速度差の理由

  • Macが5.1倍速い （52 tok/s vs 10 tok/s）
    • MoE（Mixture of Experts） ：1トークンあたり3.8Bパラメータのみ活性化（1.9GB分）
    • Dense ：毎トークン31.2Bパラメータ全読み込み（17.4GB分）
    • 同じメモリ帯域 でも、MoEは圧倒的に軽量・高速
  • プロンプト処理速度も僅差 （531 tok/s vs 548 tok/s）

最大の発見

  • トークン生成速度よりモデル品質が重要
    • Macは5倍速でもリトライやエラーで時短効果限定
    • 品質が高いモデルは一発で正解→結果的に最速
  • ローカルでも実用可能な時代へ
    • Gemma 3→Gemma 4のツールコール精度向上が決定的
    • ハイブリッド運用推奨 ：ローカルは反復作業・プライバシー重視、クラウドは複雑なタスク

実践者向けセットアップTips

  • Apple Silicon
    • Gemma 4はOllama非推奨、llama.cpp + --jinja必須
    • Codex CLI：web_search = "disabled"、-mはGGUF直指定
    • コンテキスト32,768以上、KVキャッシュは-ctk/-ctv q8_0で量削減
  • NVIDIA環境
    • Ollama v0.20.5が安定、codex --oss -m gemma4:31b
    • リモート利用時はSSHトンネルでポート転送
  • タイムアウト設定 ：stream_idle_timeout_msを1,800,000以上に
  • llama.cppのバージョン固定 ：ビルドごとに速度大幅変動の報告あり

ベンチマーク条件

  • 日付 ：2026年4月12日
  • ソフトウェア ：Codex CLI v0.120.0
  • Mac ：llama.cpp ggml 0.9.11、gemma-4–26B-A4B-it Q4_K_M
  • GB10 ：Ollama v0.20.5、gemma-4–31B-it Q4_K_M
  • クラウド ：GPT-5.4（高推論モード）
  • 同一プロンプト・同一自動実行コマンドで比較

Hackerたちの意見

今、M3 Ultra（48GB RAM）でlm studio（https://lmstudio.ai/）とOpencodeを使ってgoogle/gemma-4-26b-a4bを試してるんだけど、うまくいってるみたい。Opencodeのプロンプトが動くようにコンテキストサイズを65536に増やさなきゃいけなかったけど、他には特に問題はないよ。メモリが少ないM3 Maxでも同じことを試したけど、Opencodeに役立つくらいコンテキストサイズを増やせなかった。Zedとの統合もACP経由で簡単だし、今のところは主に簡単なコードレビューや小さなフロントエンド関連のコードスニペットを生成してる。

└

M4 Maxと64GBのMacBook Proで同じことやってるよ。最近のLM Studioのアップデート（0.4.11+1）までは問題があったけど、ツール呼び出しがうまくいかなかったんだ。今はcodexとopencodeの両方がちゃんと動いてるみたい。

└

私も似たようなセットアップしてる。pi-coding-agent [0]をチェックする価値あるかも。システムプロンプトとツールはほとんどオーバーヘッドがないよ。（https://www.npmjs.com/package/@mariozechner/pi-coding-agent#...

└

ggufとmlx、どっちがいいかな？編集：コミュニティのmlxを試してみたけど、lm studioがまだ読み込みをサポートしてないって言ってた。

└

私もM1 MacbookでLMStudioをXCodeに統合してmlxバージョンを使って同じことをやった。コンテキストサイズを上げないといけなかったけど、かなり控えめなiOSコードベースに対して実行したら、あまりうまくいかなかった。途中でダメになっちゃった。変だな。結構いいチャットボットだけど、他のコードに対してはうまくいくかもしれないけど、XCodeでは私には役に立たなかった。

└

このモデルをAMD RX7900XTXの24GB VRAMで動かしてるんだけど、最大4つの同時チャットと512Kのコンテキストウィンドウを使ってる。めっちゃ速いし（約100 t/s）、瞬時に反応するし、すごく使える感じ。最近はClaude Codeを使うことが少なくなってきたよ。

└

もう試したか分からないけど、俺の経験ではGLM FlashとQwenモデルの方がGemmaよりずっと良いよ。俺は24GBのGPUを使ってるから、君の環境とは違うかもしれないけど、あんまり変わらないと思うよ。

コーディングに関しては、Q6_Kより悪い量子化を使う意味はないって、俺の経験上思う。もっと量子化されたモデルはミスが増えるし、テキスト処理ならまだしも、コーディングには向いてないよ。

└

ほとんどの人がそれに気づいてないと思う。トークンの質は量よりも重要だよ。いつもみんなにはできるだけ高い量子を使うように言ってるけど、メモリ容量が足りない時は下げるしかないね。

予想外だった発見：モデルの質はエージェントコーディングにおいてトークン速度よりも重要だ。これが明らかじゃなかったのが本当に驚きだよ。それに、コンテキストサイズを32kみたいに制限してトークン生成速度を半分にする代わりに、--cpu-moeを使ってMoEの処理をCPUにオフロードできる。

└

毎日codexを使ってる人には、これが明らかじゃないのがさらに不思議だよね。制限の原因は、LLMが無駄なことにこだわったり、考えすぎて決断できなくなることなんだ。生のスピードが本当に重要なのは、たくさんの新しいコードを追加しようとしてる時だけだよ。でも、トークン制限の速度でそれをやってたら、AIのクソコードベースの特異点にすぐに近づいちゃうよ。

└

そうだね、すごく疲れてる時にコーヒーを飲むみたいな感じ。結局まだ疲れてるけど、ただ「速く」なるっていう変な感覚。

└

仕事を早く終わらせる以外に、トークンの速度が重要な理由って何？名前に「スピード」って入ってるじゃん。

関連で、昨日M4 Pro 24GBをM5 Pro 48GBにアップグレードしたんだ。同じGemma 4 MoEモデル（Q4）がM5 Proで約8倍のトークン生成速度で動いて、ディスクからメモリへの読み込みも2倍速い。今日はもっとテストをする予定。

└

同じGemma 4 MoEモデル（Q4） あなたはたくさんのRAMを持ってるから、Q8_0を直接動かすことを勧めるよ。遅くはないし（初期モデルの読み込みを除いて）、元のモデルとほぼ同じ質で、むしろ速いかもしれない。念のため確認だけど、MLXバージョンを使ってるよね？先週試したとき、mlx-communityの量子化が壊れてたみたいで（ゴミが出てきた）、代わりにunslothバージョンをダウンロードしたんだ。それもmlx-lmで壊れてたけど（クラッシュした）、その後https://github.com/ml-explore/mlx-lmのメインブランチで修正されたよ。残念ながら、Macbook M1には16 GiBのRAMしかないけど、2023年のAMD Framework 13（64 GiB RAM）でQ8_0 GGUFバージョンをCPUだけで動かしてみたら、意外とトークン生成速度が速くて、出力を読むのが追いつかないくらいだった。プロンプトキャッシュも、大きなシステムプロンプトやファイルをデータマイニングするのにすごく便利だけど、スクリプトを使って手動でやるよりも良い方法があるかもしれない。

実際に試すハードウェアは持ってないけど、Qwen3.5がGemma 4と比べてどうなるのか気になるな。特に、500k以上のダウンロードがあるツールコールに特化したこのモデルがどうなのか： https://huggingface.co/Jackrong/Qwen3.5-27B-Claude-4.6-Opus-...

└

ちょっと驚きなのは、個人開発者がそんなに控えめなリソースでモデルからより多くのパフォーマンスを引き出せるってこと。そんなにチューニングされたモデルが「良い」とされるのには懐疑的だな -- 特定のベンチマークではそうかもしれないけど、全体的にはどうなんだろう？ちなみに、そのファインチューニングの最新バージョンはここにあるよ： https://huggingface.co/Jackrong/Qwopus3.5-27B-v3

└

俺はハッカーニュースのただの一般人だけど、実際にDGX Sparkでこれを試してみたよ。何回かやった後、Gemma 4に戻った。オーケストレーションモデルがQwenモデルに間違いを直させるために戻さなきゃいけなくて、Gemmaならしなかったミスがあったんだ。結果的に、時間あたりの作業コードが減っちゃった。技術的には、Ollamaを使ってOpenWebUIを使ってるから、下記の重みを使ったけど、同じだと思うよ。 https://ollama.com/kwangsuklee/Qwen3.5-27B-Claude-4.6-Opus-R...

└

Jackrongがここにファインチューニングの手順を公開してるよ。ノートブックなどもあって、かなり詳しいみたい。今、自分でも見てるところ… https://github.com/R6410418/Jackrong-llm-finetuning-guide

いろんな量子化方法の間での質の結果を見てみたかったな - Q4_K_M、Q_8_0、Q_6_Kの代わりにトークン生成速度じゃなくて。

「以前これをやらなかった理由は、ローカルモデルがツールを呼び出せなかったからです。」なんて嘘だよ。私たちは2年前からローカルでツールを呼び出してるし、gemma3がツール呼び出しで7%以下だったなんて全然違う。実際、llama3.3で少なくとも75%のツール呼び出しができてたよ。

└

この記事全体がAIのゴミみたいに感じるな。GB10デバイス持ってる人は、spark-vllm-dockerのセットアップを試してみるといいよ。それと、最近リリースされた最適化されたQwen 3.5 122B A10Bのセットアップについて、NvidiaのGB10フォーラムもチェックしてみて。50tk/sは、 decentなローカルモデルとしてはかなりすごいよ！

└

この文には私も驚いた。著者がローカルでモデルを動かすのは初めての試みっぽいね。もしくは、ずっと重く量子化された小さなモデルを使ってたのかも — Gemma 4 ggufはQ4で、たったの16GBだし。私の経験では、こんな量子化されたモデルはパフォーマンスがかなり悪いことが多い。

ここ数日これで遊んでるけど、モデルは速いし、結構賢い。でもツール使用の問題には直面してる。このブログ記事は特に関連性が高いね。私のデュアル4090ではモデルの速度に問題はないけど、生産性は主に知能に制限されてる（高いけど、まだいくつかのタスクには足りない）し、ループにハマることもある。こういうことが起きたときに、もっと賢いモデルに「友達に電話する」みたいにアドバイスを求めてほしいな。私はエージェントオーケストレーションの領域に入ってきてて、いくつかのエージェントが常に動いて作業してる。オンプレミスとAIプロバイダーを混ぜて使うつもり。今の私の役割は、コーダーというよりデザイナー/マネージャー/アーキテクトって感じ。エージェントがすぐに脱線して、抜け出せないような混乱を引き起こすからね。

└

Googleが数日前にgemma-4-31B-itのchat_template.jinjaとtokenizer_config.jsonを置き換えたんだ。それでツールの呼び出しに関する問題がいくつか解決されたらしい。だから、もしモデルを更新してなかったら、更新した方がいいよ。

Gemma 4 26Bは、同じクラスの中では本当に異例だね。あまり知られていない、難しいベンチマークで、GPT 5.2やGemini 3 Pro Previewと同じくらいのスコアを出した。一発コーディング問題ではね。全体のベンチマーク手法を再確認させられたよ。でも、他の二つのセクションでは苦戦した：エージェント的コーディングと非コーディングの意思決定。ツール使用、反復的な改善、大きなコンテキストの管理、コーディング以外の推論がスコアを現実に戻した。ツールを使ってカスタムハーネスでコードを書くときは、逆にスコアが悪くなった。一発でできるチャンスがあったときよりもね。確かに、一般的なハーネスやエージェント的ベンチマークに過剰適合してるだろうけど、主な問題は小さなモデルでのコンテキストのスケーリングだと思う。それでも、素晴らしいモデルで、MシリーズのMacbookでの速度もすごい。ベンチマークはhttps://gertlabs.comで見られるよ。

このモデルには大きなシステムプロンプトはちゃんと機能するのかな？必要なら、デフォルトで4つのツールしか付いてない軽量CLIのPiを使うといいかも。