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

24GBメモリを搭載したM4でのローカルモデルの実行

概要

  • ローカルLLM のセットアップ体験談と実用性について解説
  • Ollama・llama.cpp・LM Studio など複数ツールの比較と選定ポイント
  • Qwen 3.5-9B モデルを中心に設定例やチューニング方法を紹介
  • Pi・OpenCode の設定ファイル例と実際のユースケース
  • SOTAモデルとの比較 やローカル運用のメリット・デメリットを具体例で説明

ローカルLLM環境の構築と選定ポイント

  • ローカルで動作するLLM を使うことで、インターネット接続なしでの基本的なタスク・リサーチ・プランニングが可能
  • 大手USテック企業への依存軽減 という観点でも意義あり
  • セットアップは簡単ではなく、 Ollama・llama.cpp・LM Studio など複数の実行方法から選択する必要
    • それぞれに 対応モデル・制約・癖 が存在
  • モデル選定時は メモリ使用量・コンテキストウィンドウ長・動作速度 などのバランスが重要
    • 64K以上(理想は128K以上)のコンテキストウィンドウを目指す

モデル選定と動作検証

  • Qwen 3.6 Q3・GPT-OSS 20B・Devstral Small 24B など大きめのモデルはメモリには収まるが実用性に難
  • Gemma 4B は動作するがツール利用に難あり
  • Qwen 3.5-9B(4b量子化) が最もバランス良好
    • 約40トークン/秒 の速度、 thinking有効化・ツール利用成功・128Kコンテキストウィンドウ
    • 24GB Macbook Pro でも他のアプリと併用可能

推奨設定例(Thinkingモード・コーディング用途)

  • 温度(temperature): 0.6
  • top_p: 0.95
  • top_k: 20
  • min_p: 0.0
  • presence_penalty: 0.0
  • repetition_penalty: 1.0
  • thinking有効化には Prompt Template{%- set enable_thinking = true %} を追加

Pi・OpenCodeの設定例

  • Piのmodels.json例
    {
      "providers": {
        "lmstudio": {
          "baseUrl": "http://localhost:1234/v1",
          "api": "openai-completions",
          "apiKey": "lm-studio",
          "models": [
            {
              "id": "qwen3.5-9b@q4_k_s",
              "reasoning": true,
              "compat": {
                "thinkingFormat": "qwen-chat-template"
              }
            }
          ]
        }
      }
    }
    
  • thinking表示を隠すには settings.json"hideThinkingBlock": true を追加
  • OpenCodeのopencode.json例
    {
      "$schema": "https://opencode.ai/config.json",
      "provider": {
        "lmstudio": {
          "npm": "@ai-sdk/openai-compatible",
          "name": "LM Studio (local)",
          "options": {
            "baseURL": "http://127.0.0.1:1234/v1"
          },
          "models": {
            "qwen3.5-9b@q4_k_s": {
              "name": "Qwen 3.5 9B Q4_K_S",
              "tools": true,
              "context_length": 131072,
              "max_tokens": 32768
            }
          }
        }
      },
      "model": "lmstudio/qwen3.5-9b@q4_k_s"
    }
    

Pi・OpenCodeの使い勝手比較

  • Pi は動作がやや軽快だが、設定の自由度が高い反面、 初期設定に時間がかかる 傾向
  • OpenCode は設定が明快で、ツール統合も容易

SOTAモデルとの比較と運用ワークフロー

  • Qwen 3.5 9B (Q4) はSOTAモデルに比べて 長期的・複雑な問題解決 は苦手
  • 1回で全てを任せるのではなく、 逐次的・対話的なワークフロー が有効
    • モデルに細かく指示しながら進める運用
  • SOTAモデルは 思考のオフロード が容易だが、ローカルモデルは ユーザーの関与度が高まる
  • ローカルモデルでも リサーチアシスタント・ラバーダック・プログラミング知識の即時参照 などには十分活用可能

実際の利用例

  • Elixir linter(Credo)の警告修正提案
    • length(list) > 0list != [] へ修正指示、モデルが該当箇所を正確に編集
  • git conflictの解決提案
    • 依存パッケージのバージョン競合を認識し、選択肢を提示
    • ただし 自動編集やrebase操作の一部で失敗 することもあり

ローカルLLMのメリット・デメリットと今後

  • インターネット不要 で、飛行機内作業も可能
  • コストは電気代のみ、サブスクリプション不要
  • 環境負荷もデータセンター利用よりは低減
  • 自由なカスタマイズ・実験の楽しさ
  • SOTAモデルのような 劇的な生産性向上 は難しいが、 自分の思考や計画力を活かした利用 ができる
  • LLMとの付き合い方としてより持続可能でポジティブ
  • 失敗も含めて楽しい、今後も発展が期待される分野

Hackerたちの意見

最近のモデル(Qwen 3.6やGemma)は、ローカルでコーディングができるんだよね。たぶん、1年前の最先端って感じ?でも、合計で32〜40GBのメモリが欲しいところ。24GBだとちょっと足りないかな。16GBのグラフィックカードと32GBのRAMを搭載したゲーミングPCなら、使えるコーディングシステムにかなり近づくよ。

そのRAMをGPUとどう使ってるの?

「コーディングシステム」「ローカルでコーディングができる」って感じで、ここにいるコーダーたちは、SaaSクローンのために(見た目も独創性もない)ダッシュボードを作ったからって、すべてのソフトウェア開発が解決されたと思ってるのかな。彼らの3x3機能カードのランディングページは、他のすべての「バイブコーダー」のスタートアップと同じだし。

もしかして、1年前のSOTAって感じ?同意だけど、小さなプロジェクトに限るね。1年前のSOTAは大きなプロジェクトではまだ勝ってる。

それって俺のデスクトップと全く同じRAM/VRAMの組み合わせだね。ゲームPCのセットアップにはどのモデルを勧める?

自分はM4 Pro 48GBでQwen 3.6の9b量子化モデルを動かしてるけど、基本的なpi.dev/cc駆動の開発をするにはほとんど役に立たない。128GBのデスクトップが実際に意味のある作業をするための理想的なセットアップだと思う。でも、今はそういうマシンを手に入れるのが難しいんだよね。ローカルでこれらを動かすのは楽しいけど、時間はタダじゃないことを忘れないで。自分は徐々にユースケースをオープンルーターに移行してて、個人プロジェクト用に大きなQwenモデルを1日2〜3ドルで運用してるよ。

オープンルーター版はChatGPT 5.5やClaude Opus 4.6と比べてどうなの?

こんな小さいモデルを選んだのは、高いトークン/秒を求めてのことなの?M4 Pro 48GBのマシンなら、もっと大きなモデルも動かせるから、モデルのインテリジェンスが役立つなら、そっちの方がいいと思って。

自分は同じスペックで30b MOEモデルを65kトークンのサブエージェントとして使ってるけど、ちゃんとしたコードを書けるよ。密な9bはあんまり良くなかったのには同意する。

これ言ってくれてありがとう。オンラインにはローカルモデルがOpus 4.7より優れているっていうナンセンスがいっぱいあるけど、普通のユーザーには全然当てはまらないよ。俺は最新のM5 MacBook Proを持ってるけど、スペックも最高で、ローカルモデルを試してみたけど、ほとんど機能しなかった。

ローカルモデル、特に著者が使ってる9Bみたいな小さいモデルで何ができるか現実的に考えるのは大事だと思う。9BモデルはSonnet 3.6レベルで、自動補完や小さな機能はできるけど、大きな問題を理解しようとすると迷っちゃう。でも、面白くて遊ぶにはいいよ!自分はローカルエージェントのハーネスとかでたくさん作業してるけど、ほとんどは楽しみのため。今やってるプロジェクトはゼロインストールエージェントで、Python、SQL、Reactがブラウザ内で完全に動くんだ。Gemma E4Bが最高の体験を提供するよ!これは重い開発中で、HTML5ファイルシステムAPIのサポートとLiteRTのためにChromeが必要だけど、ほとんどのChromiumベースのブラウザでも動かせるよ。これはほとんどのエージェントとは違って、ゼロインストールなんだ。モデルはブラウザ内でLiteRT/LiteLLMを使って動くから、Transformers.jsよりもパフォーマンスがいいし、ファイルシステムAPIを使ってディレクトリにアクセスできるオプションもある。自己文書化されていて、「システムプロンプトはどう使われるの?」みたいな質問をライブヘルプペインで聞けるし、自分のソースコードにもアクセスできる。かなりの情報があるから、「ツアー」を押して全部見てみて。来週オープンソースになる予定だよ。

でも、Sonnet 3.5ではオートコンプリートや小さな機能以上のことをやってたよ。

細かいことを言いたくはないけど、4-12bモデルの多くはGPT-3.5とGPT-4o-miniの間にいる感じ。良い比較を見つけるのは難しいけど、モデルを評価するベンチマークが頻繁に変わるからね。参考までに、Sonnet 3.6はGPT 3.5の約1年後に出たよ。

いい感じに近づいてる!Gemma 4 31B(密度あり/ MoEなし)をローカルモデルの新しい基準だと思ってる。フロンティアモデルには明らかに劣るけど、今まで使ったローカルモデルよりは科学実験っぽくない。GPT OSS 120BやNemotron Super 120Bも含めてね。M5 Maxに128GBのRAM、256Kのコンテキストウィンドウを使ってるけど、RAM使用量が約70GBまで上がって、システムオーバーヘッドが14GBくらい。フルArc B390の64GB Panther Lakeマシンや、48GB Snapdragon X2 Eliteマシンなら、128Kから256Kのコンテキストウィンドウで動かせるかも。32GB(使えるのは27.5GB)で32Kのコンテキストウィンドウに収められるかも?去年の今頃、これくらいのパフォーマンスがメインストリームな構成で見られるなんて夢のまた夢だったよ。

最初のトークンまでの時間とトークン/秒を教えてもらえますか?

Gemma 4はいいよ。Opus 4.7が見逃したことを正確にやってくれたこともあるし、エッジがボロボロだけど、実際に使えるケースがたくさん見つかってる。結局のところ、重要なのは「何を信頼してできるか」ってこと。Opusは確かにもっと多くのことを知っていて、時にはもっと複雑なタスクもこなせるけど、特にコンテキストをしっかり与えればGemmaは素晴らしい。信頼できることのセットの違いは意外と小さいよ。最近は個人的なツールやランダムなプロジェクトでめちゃくちゃいい結果が出てる。エージェントモードで非自明なプロジェクトに機能を実装できる初めてのローカルモデルだよ。https://thot-experiment.github.io/gradient-gemma4-31b/ これはGemma 4だけでOpenCodeの中に完全に作られた比較的複雑なツールで、数時間の間に手動で介入したのは多分4回だけ。Q6_K_XLを動かしてて、128kのコンテキストでq8で約800トークン/秒の読み込み、16トークン/秒の書き込み。もし噂が本当なら、turboquantとMTPがllama.cppに来れば256kと25-30トークン/秒に到達するはず。

あなたの経験では、GemmaはQwen3よりも良いですか?

週末に同じ結論に達する前にこの記事があればよかった!同じノートパソコンで、俺のテストは小さなvibeコードのC++リポジトリで50個くらいのリンティングエラーを直させるっていうものだった。あまり詰まらずに小さなタスクをこなせるようにしたかったんだ。GPT OSS 20Bは使えたけど遅くて、実際に不必要に文を追加したり重複させたり、コードを編集せずに修正したことにしたりして、よくミスをしてた。Qwen 3.5 9BはOpencodeを使ってて、かなり速くて、リンティング警告の大半を詰まらずに処理できたし、圧縮中もすべての警告を正しく編集して直してくれた。Qwen 3.5 9Bの4bit MLX量子化も試したけど、最終的にはメモリ不足でクラッシュした。GGUFに切り替えて、llama.cppで動かしたら、クラッシュせずに動いた。フロンティアモデルとは全く比べ物にならない。すごく遅いし、基本的な情報を間違えるし、非自明なタスクを一度で処理するのは本当に無理。プロジェクトのアーキテクチャの要約を頼んだら、リポジトリに存在しないライブラリを使ってるって言われた。だから、あなたの環境によるけど、持っておくのはいいし、ローカルLLMの話が時間とともに普通のハードウェアでももっと良くなるといいな。

フロンティアモデルとは全く比べ物にならない。これはあまり言われてないよね。そう、ローカルLLMは素晴らしい!でも、HNのほとんどの投稿を読むと、Opus 4.7に手が届くと思っちゃう。HNにはローカルLLMの能力を過大評価してる小さな熱心なグループがいるんだ。

正直、GPT OSS 20BがMacハードウェアで遅いって聞いて驚いた。サイズに対してはローカルGPUで動かした中で一番速いモデルの一つだけど、Nvidiaカードしか試してない。追記:TIL、これはMoEで、アクティブなのは3.6Bだけだから、納得。

俺の4090(24GB)でqwen3.6:27Bを約128Kコンテキストで動かしてるけど、最近のturboquant/rotorquantのメモリ最適化を活用してる。これを試してみることを強く勧めるよ。q4_xl+rotorquantの組み合わせは結構いい感じ。エージェントを投げるための参考コードもあるよ。 https://github.com/rapatel0/rq-models

モデルが良くなるだけじゃなくて、DflashやMRT、turboquantみたいな新しいトリックで推論エンジン側でもまだ大きな進歩があるよ。特定のユースケースでは、これらが速度を何倍にもすることができる。DeepSeek 4 flash用のモデル特化型の最適化カーネルもあって、これがまたすごい。まだ最適には程遠い気がする。例: https://dasroot.net/posts/2026/05/gemma-4-speed-hacks-mtp-df... https://x.com/bindureddy/status/2052982206344409242?s=46

MRTって何?

APIにサブスクするより、Macに何千ドルも使いたいな。ローカルモデルなら、プライバシーの漏洩を心配せずにいつでもどこでも仕事ができるから。

デフォルトのhideThinkingBlockを維持するのは良いことだね。モデルを操作できるようにするために意図的にそうしてるんだ。

M3を36GB搭載で持ってるけど、Qwenや似たようなモデルが使えると思ってたんだ。設定は結構簡単で、CLIアクセスにはpiやhermesを使ったり、VS Codeで「Continue」を使ったりできるよ。モデルを実行するにはomlxやOllamaなど、いろいろ選べる。難しいことじゃないけど、結果はあんまり満足できるものじゃないね。たまにすごく簡単なタスクに使ったり、誤字を直したり、ブログのメタデータを更新したりしてる。だから、確かに生産性は上がるけど、コーディングに関してはCodexやClaudeたちには全然及ばないね。