LM Studio Headless CLIとClaude CodeでローカルでGoogle Gemma 4を実行する

 (ai.georgeliu.com)
17 ポイント 投稿者 GN⁺ 23 일 전 | 1件のコメント | WhatsAppで共有
  • Gemma 4はmixture-of-experts構造により一部のパラメータのみを有効化し、低スペックなハードウェアでも高性能な推論をサポート
  • LM Studio 0.4.0は新しい**Headless CLI（llmster）**を導入し、デスクトップアプリなしでモデルのダウンロード・ロード・チャット・APIサーバー実行が可能
  • OpenAI・Anthropic互換APIを通じてGemma 4をローカルサーバーとして提供でき、Claude Codeを完全オフラインのコードアシスタントとして活用可能
  • コンテキスト長・GPUオフロード・並列リクエストなどの細かなハードウェアチューニングで、性能とメモリ効率を調整できる
  • MoEモデルベースのローカル推論はAPIコストなしで高速なコードレビューとプロンプトテストを可能にし、開発者向けオフラインAI環境構築の中核技術として浮上

ローカルでGoogle Gemma 4を実行する — LM Studioの新しいHeadless CLIとClaude Code連携

  • ローカル実行の必要性

    • クラウドAI APIには料金、速度制限、プライバシー、ネットワーク遅延などの制約がある
    • コードレビュー、下書き作成、プロンプトテストなどの高速な反復作業にはローカルモデル実行が有利
    • ローカル実行にはAPIコスト0、データの外部送信なし、常時利用可能という利点がある

    • Gemma 4**はmixture-of-experts（MoE）構造により、26Bモデルのうち4Bパラメータのみが有効化されるため、**低スペックなハードウェアでも高性能に実行可能

      • M4 Pro MacBook（48GB）で毎秒51トークンの生成速度を記録し、Claude Code内ではやや遅くなる

  • Gemma 4モデル系統

    • GoogleはGemma 4を4種類のモデル群として公開し、さまざまなハードウェアに最適化
    • **Eシリーズ（E2B、E4B）**はPer-Layer Embeddingsを使用し、**音声入力（音声認識・翻訳）**をサポート
    • 31B denseモデルはMMLU Pro 85.2%、AIME 2026 89.2%の性能
    • 26B-A4Bモデルは128個のエキスパートのうち8個（3.8Bパラメータ）のみが有効化され、10B級の品質を4B級のコストで実現
    • MMLU Pro 82.6%、AIME 88.3%で31B denseモデルに近く、Elo 1441で400B+モデルと競合
    • 256Kコンテキスト、ビジョン入力、関数呼び出し、推論モード設定をサポートし、ローカル推論に適している

  • LM Studio 0.4.0の主な変更点

    • llmster**という独立型推論エンジンの導入により、**デスクトップアプリなしでCLIから完全に実行可能

      • lms CLIにより、モデルのダウンロード、ロード、チャット、サーバー実行をすべて行える
      • 主な機能:
      • llmster daemon: バックグラウンドでモデルのロード・推論を管理
      • 並列リクエスト処理: continuous batchingにより複数リクエストを同時処理
      • Stateful REST API: /v1/chatエンドポイントで会話履歴を維持
      • MCP統合: ローカルのModel Context Protocolをサポート

  • インストールとモデルのダウンロード

    • インストールコマンド: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
    • デーモン起動: lms daemon up
    • ランタイム更新: 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 load google/gemma-4-26b-a4bでロード

  • ローカルモデル管理

    • インストール済みモデル一覧の確認: lms ls
    • 出力例にはGemma 4、Qwen 3.5、GLM 4.7 Flashなど多数のMoEモデルを含む
    • MoEモデルは有効化されるパラメータの一部のみを使うため、効率的な推論が可能

  • 会話実行と性能

    • 会話開始: lms chat google/gemma-4-26b-a4b --stats
    • 出力例: 
      Tokens/Second: 51.35
Time to First Token: 1.551s
    • 51 tok/sec、初回応答1.5秒で、対話には十分な速度

  • モデル状態とメモリ確認

    • ロード済みモデル確認: lms ps
    • 例: 17.99GBのメモリ使用、48Kコンテキスト、並列2リクエスト、TTL 1時間
    • JSON出力（lms ps --json | jq）で確認できる主な項目:
      • "architecture": "gemma4"
      • "quantization": {"name": "Q4_K_M", "bits": 4}
      • "vision": true, "trainedForToolUse": true
      • "maxContextLength": 262144, "parallel": 2

  • コンテキスト長によるメモリ見積もり

    • --estimate-onlyオプションでメモリ要求量を予測可能
    • ベースモデルは約17.6GiBで、コンテキストが2倍になるごとに3〜4GiB増加
    • 48Kコンテキストでは約21GiB必要、256Kでは37.48GiB
    • コマンド例: 
      lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
    • コンテキスト長とメモリの線形関係により、容量計画に有用

  • ハードウェア別ロードチューニング

    • コンテキスト長

      • OS使用量（4〜6GB）を除いたメモリ上限内で設定
      • 例: lms load google/gemma-4-26b-a4b --context-length 128000

    • GPUオフロード

      • Apple Siliconはユニファイドメモリ構造で、--gpu=1.0によりGPU全体を使用可能
      • NVIDIAシステムではVRAM上限内で--gpu=0.5のように分割可能

    • 並列リクエスト

      • continuous batchingにより複数リクエストを同時処理
      • GUIでMax Concurrent Predictionsを設定（デフォルト4）
      • Gemma 4では48GBシステムで48Kコンテキスト、並列2が適切

    • TTL自動アンロード

      • --ttl 1800で30分間非アクティブ時に自動解除
      • デフォルトは1時間、0または-1で無効化可能

    • モデルごとのデフォルト値保存

      • デスクトップアプリのMy Models → 設定アイコンでGPU、コンテキスト、Flash Attentionのデフォルト値を保存

    • speculative decoding

      • MoEモデルでは非効率的で、Gemma 4では無効化が推奨される
      • Mixtralのテスト結果ではコード作業が39%向上する一方、数学作業は54%低下

    • Flash Attention

      • KVキャッシュのメモリ削減により長いコンテキストをサポート
      • Apple Siliconで有効化するとメモリ節約効果がある

  • LM Studioデスクトップアプリ

    • GUIでサーバー状態、モデルロード、APIエンドポイント、ログストリームを可視化
    • Anthropicプロトコル（POST /v1/messages）を含む
    • ビジョン機能で画像分析が可能
    • 例: Timezone Scheduler画像分析時に504トークンを生成し、54.51 tok/sec
    • システムモニタリング結果:
      • メモリ使用 46.69GB/48GB、スワップ 27.49GB
      • GPU 90%使用、CPU 91°C、GPU 92°C
      • 消費電力 23.56W（CPU 11.06W、GPU 13.32W）
    • ユニファイドメモリ構造によりCPU/GPU間のデータコピーが不要

  • APIサーバーとしてモデルを提供

    • サーバー起動: lms server start
    • OpenAI互換API: http://localhost:1234/v1
    • Anthropic互換エンドポイント: POST /v1/messages
    • ポート変更: --port 8080
    • JITモデルロードによりリクエスト時に自動ロードし、TTL後に自動アンロード
    • リアルタイムログストリーム: lms log stream --source model --stats
    • ネットワーク内の他デバイスからもアクセス可能で、APIトークン認証をサポート

  • Claude Codeとの連携

    • Anthropic互換エンドポイントを通じてClaude Codeをローカルモデルで実行可能
    • ~/.zshrcにclaude-lm関数を追加: 
      export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_MODEL="gemma-4-26b-a4b"
...
claude "$@"
    • Claude Codeのすべてのモデル呼び出し（Opus、Sonnet、Haiku）をGemma 4へルーティング
    • 48Kコンテキスト、8Kトークン出力制限、ローカル専用環境を構成
    • claude-lm実行時に完全オフラインのコードアシスタントを利用可能
    • 速度はクラウドより遅いが、コードレビュー・小規模修正・探索作業に適している

  • 主な教訓

    • MoEモデルがローカル推論の中核: Gemma 4 26B-A4Bは10B級の品質を4B級のコストで実現
    • Headlessデーモンにより完全CLIベースのワークフローが可能
    • コンテキスト長がメモリ使用量の主要変数
    • --estimate-onlyでOOM防止
    • Anthropic互換エンドポイントによりClaude Codeをローカルで完全オフライン実行可能

  • 限界点

    • lms chatではモデル名が直接表示されない
    • デフォルトの48Kコンテキストは保守的で、メモリに余裕があれば拡張推奨
    • Claude Codeのローカル実行はAnthropic APIの完全代替にはならず、大規模作業には制約がある
    • 48GBシステムではメモリ逼迫とスワップ使用が発生し、64GB以上が推奨される

  • 次のステップ

    • Qwen 3.5 35B、GLM 4.7 Flash、Nemotron 3 Nanoなどとの比較テストを予定
    • 実行手順の要約: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get google/gemma-4-26b-a4b
lms chat google/gemma-4-26b-a4b --stats
    • Claude Code連携: claude-lm関数を追加後、claude-lmを実行
    • ローカルAIワークフローの構築やWebアプリ・開発者環境との統合に活用可能

関連記事

1件のコメント

 
GN⁺ 23 일 전
Hacker Newsのコメント

  • llama.cpp server を直接使ってローカル LLM を動かし、Claude Code や他の CLI エージェントで活用できる
    M1 Max 64GB MacBook で Gemma4 など最新のオープンウェイト LLM を試した完全な設定ガイドをまとめている
    26BA4B モデルがこのハードウェアでは最も興味深く、Qwen3.5 35BA3B よりほぼ 2 倍速い トークン生成速度 (40 tok/s) を示した
    ただし tau2 ベンチの結果は Qwen 系より低く (68% vs 81%)、ツール中心の複雑な作業には不向きだろうと見ている

    • Claude Code で Anthropic と OpenAI の 仕様衝突 の問題はなかったのか気になる
      自分は mlx_vlm と vMLX を使っているが、Claude Code で 400 Bad Request エラーが出る
      llama-server ではそうした問題がなかったのか聞きたい

  • ローカルモデルは今や単に「動く」段階を超えて、快適に使える段階に入ったと感じる
    特に headless LM Studio の流れが印象的だ。実際のツールでローカル推論を使えるようにしてくれる
    自分は cloclo というオープンソースの CLI コーディングエージェントを開発中で、LM Studio、Ollama、vLLM、Jan、llama.cpp など多様なバックエンドをサポートしている
    ローカルモデルは 個人的で安価な日常用途、クラウドモデルは高性能な作業用という、理想的な組み合わせに近づいている

    • cloclo が pi-mono とどう違うのか気になる

  • 今回の話の核心は Gemma 4 自体より、ハーネス (harness) とモデルが完全に分離された点だ
    Claude Code、OpenCode、Pi、Codex はどれも任意のバックエンドで動く
    つまりコーディングエージェントはますます 汎用化されたレイヤー になっており、競争の焦点はモデルの品質とコストへ移っている
    ユーザーにとっては良いことで、ハーネス依存だった企業にとっては脅威だ

    • むしろ逆だと思う。汎用化しているのはモデルの方で、ハーネスとツーリング こそが実際の性能向上の鍵になっている
      たとえば “Improving 15 LLMs at Coding in One Afternoon” でも、ハーネスを変えただけで大きな改善があったとされている
    • 実際、Claude Code や OpenCode はローカル HTTP エンドポイントへ直接つなぐこともできた

  • ollama launch claude --model gemma4:26b コマンドで簡単に実行できる

    • context window のサイズを増やさないとツール呼び出し機能が動かない
    • ollama と claude さえインストールされていれば、こんなに簡単に動くのは驚きだ
    • ただ、自分の環境では動かなかった。claude が無限ループに入って応答しない
      Nemotron、glm、qwen 3.5 は問題ないのに、gemma だけが問題だった

  • このアプローチは Web ソフトウェアテストの自動化 にも役立ちそうだ
    Selenium や Puppeteer は Web デザインが少し変わるだけでテストが壊れやすい
    一方でこうしたモデルは変化に適応できるので、より 柔軟なテスト が可能になりそうだ
    特に小型モデルでも十分に活用できそうに見える

  • MoE は実際には (V)RAM を節約しない
    すべての 重みがメモリに常駐 している必要があり、1 回の推論でその一部だけを使うだけだ
    そのため tok/s は改善しても VRAM 使用量はそのままだ

    • 自分も最初は勘違いしていた。非アクティブなエキスパートは計算をスキップしても、依然としてメモリにはロードされている
      この可視化資料 が理解の助けになった
    • 一部の推論エンジンでは 一部のエキスパートを CPU RAM にオフロード できる
      たとえば 35B パラメータの MoE を 12GB VRAM の GPU + 16GB RAM の組み合わせで動かせる
    • すべての重みを同時にメモリへ置いておく必要はない
      RAM、ディスク、ネットワークなどから 必要な部分だけを入れ替えてロード できる
      MoE は次の推論ステップで入れ替える必要があるデータ量を減らしてくれる

  • 自分は Claude Code を データパイプラインの反復作業の主インターフェース として使っている
    特に政府の規制開示 (XBRL) を標準化し、REST と MCP で公開する作業だ
    MCP は面白い部分で、クライアントを直接呼ぶ代わりに ツールを宣言的に定義 し、モデルが呼び出すタイミングを決める
    たとえば「この会社の 10 年間のレバレッジ推移を業界平均と比較して」といった問い合わせが、自動的に適切なツール呼び出しシーケンスへ分解される
    ただし MCP の対話的利用では レイテンシ がずっと敏感になる
    2 秒応答はスクリプトでは問題なくても、会話の流れを壊してしまう
    そのためよく使うテーブルをメモリにキャッシュして、100ms 未満の応答を達成した
    他の人もこうした レイテンシの閾値 を経験しているのか気になる

    • 自分も MCP を便利に使っているが、トークン使用量 が多くなりうる
      単純な実装では、同じ機能に対して何万トークンも余計に消費する
      Anthropic の解説記事 があるが、少し古い資料だ
    • 自分の経験では、ツール呼び出し 1 回あたり 300〜500ms が 自然な上限 だ
      それを超えると多段チェーンが遅くなり、モデルが不要な推論を追加してコンテキストが膨らむ
      キャッシュ以外でも、複数のデータを一度に返すようにして 往復回数を減らす戦略 が効果的だった

  • macOS で Gemma 4 26B を Claude Code 用のローカル推論として設定する方法を共有している

    • とても良いまとめだと思う

  • 今後は主要な AI 研究所が ローカル LLM を併用運用 してクラウド負荷を減らし、重い計算だけをクラウドで処理する構成に向かうかもしれない

    • ただ、それは彼らの ビジネスモデルと衝突 しないのだろうかという疑問がある

  • Gemma 4 モデルが エージェント型コーディング作業 でどれほどうまく動くのか、実際の印象が気になる