LM Studioの新しいヘッドレスCLIとClaude Codeを使用して、Gemma 4をローカルで実行する

50日前原文(ai.georgeliu.com)

概要

Cloud AI API の課題（レート制限、コスト、プライバシー、遅延）を回避するにはローカルモデルが有効
Google Gemma 4 はMixture-of-Experts構造でローカル推論に最適
LM Studio のCLI対応でコマンドラインからの運用が容易
26B-A4Bモデル は高性能・低メモリ消費でMacBook Proにも最適
実用的な導入・運用方法 とメモリ見積もり手順を詳細解説

Cloud AI APIの課題とローカルモデルの優位性

Cloud AI API は利便性が高いが、 レート制限 ・ 利用コスト ・ プライバシー問題 ・ ネットワーク遅延 が課題
コードレビューやプロンプト作成など、 短時間・小規模タスク ではローカルモデルが有利
APIコストゼロ、 データ漏洩リスクなし、 常時利用可能 という利点

Google Gemma 4の特徴とMixture-of-Experts構造

Google Gemma 4 は Mixture-of-Experts (MoE) アーキテクチャ採用
- 26Bパラメータモデルだが、1回の推論で4Bのみ有効化
- 14インチMacBook Pro M4 Pro（48GBメモリ） で快適動作・51トークン/秒生成
Claude Code との組み合わせでは体感的に遅延あり
Gemma 4ファミリー は4種類のモデルをラインナップ
- E2B/E4Bは 音声入力対応 ・ Per-Layer Embeddings 搭載
- 31B Denseモデルは最高性能（MMLU Pro 85.2%、AIME 2026 89.2%）
26B-A4B は128エキスパート＋1共有エキスパート、1トークンで8エキスパート（3.8Bパラメータ）有効化
- 推論コストは4B Dense相当、実効品質は10B相当
- ベンチマーク：MMLU Pro 82.6%、AIME 2026 88.3%、31B Denseに迫る性能
Eloスコア で見てもGemma 4 26B-A4Bは高効率・高性能
- 400B+パラメータモデルと同等のスコアを大幅に少ないパラメータで実現
- MoEモデル はローカル推論に革命をもたらす存在

LM Studioによるローカルモデル運用

LM Studio v0.4.0 で llmster （スタンドアロン推論サーバ）導入
- lms CLI でコマンドラインからモデル運用・管理が可能
- 並列リクエスト処理 ・ REST API ・ MCP統合 など新機能
インストール手順
- Linux/Mac: curl -fsSL https://lmstudio.ai/install.sh | bash
- Windows: irm https://lmstudio.ai/install.ps1 | iex
デーモン起動: lms daemon up
推論ランタイム更新 （macOS）:
- lms runtime update llama.cpp
- lms runtime update mlx
Gemma 4 26Bモデルのダウンロード: lms get google/gemma-4-26b-a4b
- Q4_K_M量子化版（17.99GB）が標準
ダウンロード済みモデル一覧: lms ls
- MoEモデル（Gemma 4, Qwen 3.5, GLM 4.7 Flashなど）はローカル推論で高効率

パフォーマンス・メモリ管理・運用Tips

チャットセッション開始: lms chat google/gemma-4-26b-a4b --stats
- 51トークン/秒、1.5秒で最初のトークン、インタラクティブ用途に十分な応答性
モデルロード状況確認: lms ps
- メモリ使用量、コンテキスト長、並列リクエスト数、TTL（自動アンロード）など確認可能
詳細メタデータ取得: lms ps --json | jq
- アーキテクチャ、量子化方式、ビジョンサポート、最大コンテキスト長など把握可能
メモリ見積もり: lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
- 基本モデルは約17.6GiB、コンテキスト倍増ごとに3-4GiB追加
- 48GB Macなら256Kコンテキスト（37.48GiB）も運用可能
メモリ見積もり用スクリプト例
- 任意のモデル名・コンテキスト長でテーブル出力可能
最適なコンテキスト長選択
- OS分のメモリ（4-6GB）を差し引き、最大許容値を見積もり
- lms load google/gemma-4-26b-a4b --context-length 128000などでロード
- 不明な場合は--estimate-only推奨
Apple Siliconのユニファイドメモリ特性
- --gpu指定でGPU/CPU割り当て調整可能（--gpu=1.0でGPUフルオフロード）
- ディスクリートGPU環境では--gpu=maxや部分オフロードも選択肢
並列推論設定
- 連続バッチ処理 で複数リクエストを同時処理
- GUIから「Max Concurrent Predictions」設定（CLI未対応）
- 並列数増加＝追加メモリ消費増加

まとめ：Gemma 4 26B-A4BによるローカルAI活用の実践

高性能・低メモリ消費 なMoEモデルでノートPC単体運用が現実的
LM Studio CLI でサーバレス・自動化・CI/CD連携も容易
用途・ハードウェアに合わせた最適化 が柔軟に可能
プライバシー・コスト・可用性 を重視する開発者・研究者に最適な選択肢

Hackerたちの意見

ここに、macOSでローカル推論用にGemma 4 26Bを設定する方法があるよ。Claude Codeと一緒に使えるよ。

└

いいまとめだね！

ollama launch claude --model gemma4:26b

└

これがこんなにシンプルだなんて驚きだよ。ollamaとclaudeをインストールしてれば、ちゃんと動くしね！

└

なぜかそれがうまくいかないんだよね、claudeが無限ループから戻ってこない。Nemotron、glm、qwen 3.5はちゃんと動くけど、gemmaはダメだ。

└

コンテキストウィンドウのサイズを増やさないと、ツール呼び出し機能がうまく働かないよ。

ちょっと待って、GemmaとClaudeの関係ってどうなってるの？

└

lm studioはAnthropicに対応したローカルエンドポイントを提供してるから、Claude Codeをそれに向けると、リクエストにローカルモデルを使ってくれるんだけど、LM StudioとClaude Codeが位置を失う問題が結構あったんだ。しばらく考えて、計画を立てて、実行し始めるんだけど、途中で止まっちゃう。続けてって頼むと、小さな変更をしてまた詰まる。ollamaのAPIを使うとそんな問題はないから、ローカル開発作業にはollamaを使ってるよ。

現在、Claude Codeは人気のあるフロントエンドみたいだね。Anthropicがもう少し使いやすくするアップデートを出すまで、どれくらいかかるんだろう？彼らはこの技術が特定の使い方以外で使われるのをあまり好んでないってことをはっきり言ってるし。

└

今のところ、彼らにはぴったり合ってるね。製品にお金を払えば、サーバーには何の負担もかからないし。

└

OpenCodeを使うのとあんまり変わらないんじゃない？それに、ローカルモデルでClaude Codeを動かすのって、ホスティングされたAnthropicモデルと比べて実用的に使えるのかな？

└

CCが人気なのは、一般的なプログラマーに合わせているからだと思うし、これからもそのスタイルを続けるつもりなんじゃないかな。特にCCが特別に使いやすいからってわけじゃないよ。

└

今のところ、オープンモデルがあんまり良くないから、そうするインセンティブはないと思う。ほとんどの企業は、フロンティアモデルにアクセスするための追加コストを払うだろうし。モデルが競争優位をもたらすんであって、ハーネスじゃないからね。ハーネスはOpusよりもずっと再現しやすいし、利点もあるよ。一部の開発者は、安いモデルを使って仕事以外でClaude Codeを学んで、そこでの使用を推奨するかもしれない（その後、彼らの会社はAnthropicやBedrockからアクセスを買うだろうし）。個人用の無料ESXiライセンスがインフラ系の人たちにその製品のスキルを身につけさせて、VMwareの伝道者が増えたのと似てるね。Anthropicはコストの関係でClaudeモデルへのアクセスをただで配ることはできないから、開発者がClaude Codeを使いこなす方法を学ぶための代替手段を提供する意味があるんだ。

└

まあ、もしそうしたら、自分たちの足を撃つようなもんだよね。だって、Claude Codeのソースが公開されてるし、みんな「クリーンルーム」再実装やフォークする口実を待ってるから。

ちなみに、MoEは(V)RAMをあんまり節約しないよ。メモリに全ての重みをロードする必要があるから、単に前方パスごとの参照が少なくなるだけなんだ。だから、トークン/秒は改善されるけど、VRAMの使用量は変わらないよ。

└

それは、VRAMからCPU RAMにいくつかのエキスパートをオフロードできる推論エンジンを使えば可能だよ。そうすれば、例えば12GBのVRAMを持つGPUと16GBのメモリで、35億パラメータのMoEを収められるってわけ。

└

全ての重みをメモリに保持する必要はないよ。RAMやディスク、ネットワークからスワップインできるからね。MOEは次の前方パスのためにスワップインする必要があるデータ量を減らしてくれるんだ。

RAMが48GBを超えるデスクトップフレームワークは、これを試すのにいいマシンかな？

└

チャットセッション専用だね、エージェント的なコーディングには向いてない。実用的には遅すぎるよ（2k LoCプロジェクトについての簡単な質問に答えるのに10分かかるし、5070のアドオンカード使ってるのに）。

小さいGemma 4Bモデルを使って、大きい31Bモデルのための推測デコーディングができるの？できるなら、なんで？できないなら、なんで？

すごいね、大きなソフトウェアを動かすハードウェアが軽ければ軽いほど、新しさが増すよね。

Claude Codeは、データパイプラインの作業を進めるための主なインターフェースになったよ。特に、政府の規制申告書（3つの異なる会計基準のXBRL）を正規化して、RESTとMCPを通じて公開する作業ね。MCPの部分が面白くなるところなんだ。エンドポイントを呼び出すクライアントを作る代わりに、ツールを宣言的に説明して、モデルがそれを呼び出すタイミングを決めるんだ。金融データの場合、これは驚くほど効果的だよ。「この会社のレバレッジトレンドを10年間のセクターの同業者と比較して」っていうクエリが、自動的に正しいツール呼び出しの順序に分解されるから、ロジックをハードコーディングする必要がないんだ。ただ、あまり話題になってないことが一つあって、会話型MCPの使用ではツールのレイテンシー感度がバッチパイプラインよりもずっと高いんだ。2秒のツール応答はスクリプトでは問題ないけど、会話の流れを壊しちゃう。結局、頻繁にアクセスされるテーブルをメモリにキャッシュして、100ms未満の応答を得るようにしたよ。レイテンシーがモデルの推論チェーンの質に影響を与え始めるしきい値に気づいたことある？

ハクソク