ハクソク

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

macOSでローカルコーディングエージェントを設定する方法

2026年6月13日原文(ikyle.me)

概要

  • Gemma 4のMTP（Multi-Token Prediction）導入により、Mac上で2倍近い速度向上を実現
  • OpenAI互換API経由でローカルコーディングエージェントを構築
  • スクリーンショット/画像入力も可能なマルチモーダル対応
  • llama.cpp（Metal対応）とUnslothモデルを活用した高速推論
  • Qwen3.6との比較検証も実施し、速度面でGemma 4に軍配

Gemma 4のローカルコーディングエージェント高速化事例

  • Gemma 4 の MTP対応 により、ローカル環境でのコーディングエージェント運用を大幅高速化
  • Mac（Apple M1 Max, 64GB, macOS 15.7.7） で llama.cpp（Metal対応） をビルド・利用
  • Gemma 4 26B-A4B（GGUF形式） を主モデルに採用
  • Q8 MTPドラフトモデル を組み合わせてスペキュレーティブデコーディングを実現
  • Gemma 4マルチモーダルプロジェクタ を追加し、画像入力にも対応
  • Pi をターミナル用コーディングエージェントとして設定

ベンチマーク・速度比較

  • ベンチマークプロンプト：「unified diffを解析し変更ファイルパスを返すPython関数を作成し、2つのエッジケースを説明せよ」
  • llama.cpp + Metalのみ
    • セットアップ：298.0 tok/s
    • 生成速度：58.2 tok/s（十分実用的だが、さらなる高速化を目指す）
  • MTPドラフトモデル追加時
    • 生成速度：72.2 tok/s（約24%高速化）
    • --spec-draft-n-max 3が最速（1～6で最適値を探索）

MLXとの比較

  • llama.cpp + Metal + MTP ：72.2 tok/s（最速）
  • MLX-LM（mlx-lm） ：最大45.8 tok/s（Gemma 4 4bitモデル）
  • llama.cppの最適化により、MLXよりも高速

画像入力対応

  • Piで画像入力を有効化するには
    • モデルのinputに["text", "image"]を指定
    • llama.cppサーバーに mmproj-BF16.gguf （マルチモーダルプロジェクタ）を--mmprojで読み込む
  • 画像入力対応後もテキスト生成速度に変化なし

セットアップ手順（要点）

  • llama.cppのインストール・ビルド
    • brew経由で依存関係導入（cmake, git, tmux, python@3.11）
    • Metal・Accelerate有効でビルド
  • モデルファイルのダウンロード
    • HuggingFace CLIでGemma 4本体・MTPドラフト・mmprojを取得
  • ローカルサーバー起動
    • llama-serverコマンドに各種オプションを付与し、OpenAI互換API（http://127.0.0.1:8080/v1）で待機
    • tmuxを使ったラッパースクリプト例も紹介
  • Piの設定
    • ~/.pi/agent/models.jsonにローカルプロバイダを追加
    • inputに["text", "image"]を指定してマルチモーダル化
    • 必要に応じてデフォルトプロバイダに設定
  • Piでの利用例
    • pi --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf
    • スクリーンショット入力例：pi -p @"/path/to/screenshot.png" "Describe this image..."

最終構成まとめ

  • 推論ランタイム：llama.cpp（Metal + Accelerate）

  • メインモデル：gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf

  • ドラフトモデル：gemma-4-26B-A4B-it-Q8_0-MTP.gguf

  • MTP設定：--spec-draft-n-max 3

  • マルチモーダルプロジェクタ：mmproj-BF16.gguf

  • サーバー：llama-server（127.0.0.1:8080）

  • API：OpenAI互換 /v1

  • コーディングエージェント：Pi（["text", "image"]入力対応）

  • MTPドラフトモデルの導入 で、Gemma 4の生成速度は 58.2→72.2 tok/s に向上

  • ローカルOpenAI互換サーバーとして、シンプルかつ高速な構成が可能

Qwen3.6との比較・補足

  • Qwen3.6 35B-A3B はGemma 4よりも コーディング性能が高い が、速度は遅い
  • Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf + MTP + mmproj構成で 55 tok/s
  • Gemma 4の 72 tok/s と比較すると、待ち時間が大幅に異なる
  • Qwen3.6用モデルも同様にHuggingFace CLIで取得・llama-serverで起動可能
  • Piでの設定例もGemma 4と同様

参考リンク

Hackerたちの意見

llama.cppだけ使うなら、huggingface-cliは必要ないと思うよ。-hf ...を使えば、自動でモデルをダウンロードしてくれるし。ダウンロード先を変えたいなら、LLAMA_CACHEを設定すればOKだよ。例えば、LLAMA_CACHE="models" ./llama-server \ -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL \ ...

└

そうだね。ドラフトモデルには-hfdを使ってね。

ちょっと前に似たような投稿を書いたよ。ollamaとopencodeを使ったやつね。https://blog.kulman.sk/running-local-llm-coding-server/

└

実際に役立つし、ollamaのGUIはもっと簡単にできるかもしれないね。

└

これが正解だね、誰でもoh my piやpiなどに切り替えられるし。

ここに役立つ情報があって、数日前に見ておけばよかったなーって思ってるよ :-) M1 MaxでのQATモデルのMTP設定が速度にあまり影響しない気がするけど、試してみる価値はあるね。ローカルモデルでいじくり回すことで、何が起こっているのかの理解がかなり深まったよ。参考までに、Gemma 4のMTPヘッドは時々Opencodeのマークアップを壊して、思考が乱雑に表示されたり、場合によってはストップトークンが欠けたりすることがあったから、今はMTPは使ってないんだ。最近のQwen 3.6モデルは開発者役割のサポートがあって、時々構造化された選択式の質問が出てきて驚かされるよ。

└

M1 MaxでQwen3.6-35B-A3B-MTPと非MTP版を比べて、微妙なデメリットを見つけたよ。もう少し設定を試してみるかも。

└

最近QATを使い始めたら、それ以降は設定を改善しようとするのをやめちゃった。数ヶ月後にまたローカル環境を調整してみるつもりだけど、今のところQATで十分満足してるよ。

64 GB それが問題なんだよね。48GのM4を持ってるけど、これを試す価値があるか気になるな。過去の試み（OllamaやいろんなLLMを使った）は、使うには遅すぎたんだよね。

└

128のM5 MAXを持ってるけど、ローカルモデルはホスティングされたものと比べるとおもちゃみたいだね。1/2でもうまく動かそうと、かなりの時間とお金を使ったよ。

└

M3を搭載したAirで16GBだけど、インターネット接続なしでも「チャットモード」で役立つ結果が得られるよ。Claudeを使うのとは違う体験だけど、ちゃんと使える。最近はQwenのバリアントをよく使ってる。

└

ここにM4 24GBがあるよ。もし俺みたいな感じなら、ちょっとした遅延は許容範囲だと思うよ。プライバシー、信頼性、CI/CD/ガードレール、ネットワークの独立性、AIaaSに対する将来への備えが得られるならね。 https://omlx.ai/ では、インテリジェントなローカルハードウェアベースのモデルダウンロードのおすすめがもらえるよ。ただ、作業負荷やプロセス、仕上がりの期待によってかなり変わると思う。あと、https://news.ycombinator.com/item?id=48089091 も見てみて。

Hacker Newsで議論の続きを見る