- M4 MacBook Pro 24GBでも、基本的な作業・調査・計画向けのローカルモデル構成が可能
- Qwen 3.5-9B Q4は約40トークン/秒で、思考モード、ツール使用、128Kコンテキストを満たす
- 最上位モデルのように複雑な問題を長時間自律的に解決するのは難しく、段階的な指示が必要
- Elixir Credoの警告は修正できたが、rebaseの競合解決はファイル修正なしでは失敗
- ローカルモデルはオフライン・サブスク不要が利点だが、性能と設定のトレードオフが大きい
ローカルモデルの実行環境と選定基準
- M4 MacBook Proの24GBメモリ環境でローカルモデルの実行設定を試し、最上位モデル（SOTA）の出力とは異なるものの、基本的な作業、調査、計画をインターネット接続なしで処理できる構成は可能だった
- ローカル実行ツールとしては Ollama、llama.cpp、LM Studio があり、それぞれ制約や提供モデルが異なる
- モデル選定では、メモリに収まりつつ一般的なElectronアプリを同時に動かせる余裕が必要で、最低64K、理想的には128K以上のコンテキストウィンドウが必要だった
- 最近試した Qwen 3.6 Q3、GPT-OSS 20B、Devstral Small 24B はメモリには収まったが実用は難しく、Gemma 4B は快適に動いたもののツール使用に難があった
- 設定項目は temperature のようによく知られた値から K Cache Quantization Type のような特殊オプションまで幅広く、思考（thinking）を有効にするかどうかで適切な値も変わる
Qwen 3.5-9B 4ビット量子化構成
- qwen3.5-9b@q4_k_s は、LM Studioで実行したときに約40トークン/秒、思考の有効化、ツールの正常利用、128Kコンテキストウィンドウを同時に満たした最良のモデルだった
- 最上位モデルより気が散りやすく、時々ループに陥り、リクエストを誤解することもあるが、24GBのMacBook Proで他の作業領域を残したまま動くモデルとしてはかなり良好だった
- 思考モードとコーディング作業向けの推奨設定は次の通りだった
temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
- 思考を有効化するには、LM Studioでモデルを選択した後 configuration に移動し、Inference タブ下部の Prompt Template に次の値を追加する必要がある
{%- set enable_thinking = true %}
- このモデルは pi と OpenCode の両方で使われ、pi のほうが機敏に感じられたが、ハーネスを自分で構築・カスタマイズできる利点とは別に、妥当なデフォルト値が不足していた
- pi の設定調整に、実際のプロジェクトより多くの時間を費やしてしまう可能性があった
pi の設定
~/.pi/agent/models.json には、LM StudioのOpenAI互換エンドポイントと qwen3.5-9b@q4_k_s モデルを登録した
{
"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" }
}
]
}
}
}
- 気の散る思考ブロックを隠すには、
~/.pi/agent/settings.json に "hideThinkingBlock": true を追加する
OpenCode の設定
~/.config/opencode/opencode.json には、LM StudioをローカルのOpenAI互換 provider として登録し、ツール使用、131072 のコンテキスト長、32768 の最大トークンを設定した
{
"$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"
}
最上位モデルとの違い
- Qwen 3.5 9B Q4 のようなモデルは、最上位モデルのように長時間にわたって複雑な問題を自律的に解決できる水準ではなかった
- アプリ全体を一度に作るよう求めるやり方は向いておらず、成果が出ないままノートPCだけが熱くなることもある
- より適していたのは、段階ごとに明確にコミュニケーションし、多くの指示を与える対話型ワークフローだった
- ローカルモデルを使う際は、ユーザー自身がより多くの思考と計画を担い、より具体的に指示する必要があるが、調査の補助役、ラバーダック、プログラミング言語の細かな仕様やコマンドライン呼び出しを即座に思い出す補助役としては有用だった
- 大手AI企業が宣伝するような10倍の生産性向上ではないが、意味のある支援と興味深い使用感は得られる
うまくいった作業と失敗した作業
-
Elixir Credo の警告修正
- Elixir linter の
credo を最新版に上げたところコードに警告が出るようになり、Qwen に mix credo --strict を実行して解決策を提案するよう依頼し、ただし編集はしないよう伝えた
- Qwen は、テストファイル4か所でリストが空でないか確認するために
length/1 を使っている問題を見つけ、length(list) > 0 の代わりに list != [] を使うよう提案した
- その後で編集を依頼すると、Qwen は4件の並列編集をきれいに実行した
- この作業は、ターミナルとエディタを行き来しながら自分でやってもよい単純作業だったが、便利な補助役になった
-
Dependabot PR の rebase 競合処理
- 依存関係更新の後、Dependabot PR に git 競合があり、Dependabot が rebase を拒否したため、自分で取得して rebase し、その後 Qwen に確認を依頼した
- 競合は各依存関係のより新しいバージョンを選べばよい単純なもので、Qwen は
sentry は 13.0.1、tailwind は 0.4.1 を維持する選択肢を推奨した
- しかし実際の変更を依頼すると、Qwen はファイルを修正しないまま競合マーカーが残った状態で
git add mix.lock && git rebase --continue を実行しようとした
git rebase --continue がエディタを開く動作も認識できず、OpenCode は停止し、この現象は一度きりだった可能性もある
ローカルモデルの利点と限界
- ローカルモデルには大きなトレードオフがあるが、インターネット接続なしで飛行機の中でも作業できるという利点がある
- どうせコンピュータを購入する前提なら、コストは使用電力にほぼ限られ、サブスクリプションも不要
- モデル学習には依然として大きな環境コストがあるが、オープンモデル企業は環境負荷の上位層とは距離があり、個人のハードウェアを使えばデータセンター依存も減る
- 自分で調整し、実験する楽しさがある
- LLM はすでに大きな影響を与えており、負の側面も多いが、今後も残る技術に見える。ローカルモデルの実験は、この技術とより持続可能かつ前向きに関わる方法のように感じられた
1件のコメント
Hacker Newsのコメント
ローカルでLLMを回すのは楽しくて強力だが、実際に仕事を終わらせるとなるとかなり厄介
事前に計画し、仕様を作り、準備する必要がある一方で、OpenAIやClaudeの大規模モデルは数文投げるだけですぐ理解してくれることが多い
すでに大規模モデルで本格的な作業をしているなら、そのまま使い続ければいい
ただしビジョン/OCR作業は別だと思う。小型・中型の公開ウェイトモデルでも最先端に近く、大規模バッチ処理ではプレフィルトークンのコストがかなりもったいない
それに、小さなLLMでも安定した個人サービスのように使うなら、16〜24GBのRAM/VRAMを別途空けて常時起動しておく必要があることをよく忘れがち
結局の核心的な問題は金だ
ほぼ実用的なレベルまで来たと思う
Gemma 4 31Bは、ローカルモデルの新しい基準線のように感じる。フロンティアモデルより劣るのは当然だが、これまで回してきたローカルモデルやGPT OSS 120B、Nemotron Super 120Bより、科学実験っぽさが薄い
M5 Max 128GB RAMで256Kフルコンテキストウィンドウを使うと、RAM使用量は約70GBまで跳ね上がり、システムオーバーヘッドが14GBほど見える
64GB Panther LakeにフルArc B390を積んだマシンや、48GB Snapdragon X2 Eliteマシンなら、128K〜256Kコンテキストウィンドウで回せそうで、32GBなら32Kコンテキストウィンドウで無理やり可能かもしれない
去年なら、こういう性能をメインストリームに近い上位構成で見るのは夢物語のように感じられた
結局のところ基準は「このモデルに何を安定して任せられるか」だ。Opusのほうが明らかに知識量が多く、より複雑な作業もできるが、コンテキストをきちんと入れればGemmaは驚くほど良い
2つのモデルに任せてよいと信じられる作業範囲の差は意外と小さい。個人ツールや複数のプロジェクトで最近とても良い結果を出していて、些細ではないプロジェクトでエージェントモードによる機能実装を信頼して任せられた最初のローカルモデルだ
https://thot-experiment.github.io/gradient-gemma4-31b/
これはOpenCode内でGemma 4がほぼ全部作った比較的複雑なツールで、数時間のあいだ手動介入は4回ほどだけだった
Q6_K_XL、128Kコンテキスト @ q8で、読み取り約800tok/s、書き込み約16tok/s程度
llama.cppのturboquantとMTPを待っているが、噂が本当なら256Kと25〜30tok/sまで行けそう
リリース直後はベンチマーク性能が印象的で、関連する記事も書いた [0]。ただ、その後より長いコンテキストのエージェントコーディング環境で回してみると、順位表での位置は少し下がった
[0] https://gertlabs.com/blog/gemma-4-economics
最新モデルで計画を立てて、小さいモデルで実行する流れだ。きちんと計画して、小さいモデルが解釈すべき曖昧さを残さなければうまくいく
週末ずっと同じ結論に達する前に、この記事を見ておきたかった
同じノートPCで、小さなバイブコーディングC++リポジトリのlintエラー約50件を直させる人工的なテストをした。小さな作業をたくさん処理しつつ、あまり頻繁に詰まらないことを期待していた
GPT OSS 20Bは使えなくはなかったが遅く、不要な文を付け足したり重複させたり、コードを修正していないのに直したと列挙してしまうミスが多かった
Opencodeと一緒に使ったQwen 3.5 9Bははるかに速く、圧縮を挟んでいる最中でもlint警告の大半を詰まらず処理し、すべての警告を正しい修正で直した
Qwen 3.5 9Bの4ビットMLX量子化も試したが、最終的にはメモリ不足でクラッシュし、llama.cppで回すGGUFに切り替えたらクラッシュせず動いた
フロンティアモデルとはまったく比較にならない。ずっと遅いし、基本情報も間違えるし、些細でない作業を一発で処理できない
プロジェクトアーキテクチャの要約をさせたら、リポジトリ内のどこにもないライブラリを使っていると主張した。人それぞれだろうが、それでも使いどころはあり、時間が経つにつれて、手頃なハードウェアでもローカルLLM環境がもっと良くなることを願っている
ローカルLLMは素晴らしいが、関連する記事をたくさん読んでいると、Opus 4.7にかなり近づいているかのように感じることがある
HNには、ローカルLLMの能力を大きく誇張する、とても小さいが声が大きく熱心な集団がいる
同じサイズ帯のモデルでは、ローカルGPUで回した中でも最速クラスだったが、試したのはNvidiaカードだけだった
後でMoEで有効パラメータが3.6Bしかないと知って、多くのことに納得がいった
ローカルモデル、特に筆者が使っている9Bのような小さなモデルで何ができるのかを現実的に見ることは有益だ
9BモデルはSonnet 3.6程度のレベルなので、自動補完や小さな関数はできるが、大きな問題を理解しようとすると流れを見失う
それでも面白くて遊びがいはある。主に遊びとして、ローカルのエージェントハーネスなどをたくさん作っている
現在のプロジェクトはインストール不要のエージェントだ: https://gemma-agent-explainer.nicklothian.com/
Python、SQL、Reactがすべてブラウザ内で完全に実行される。最良の体験にはGemma E4Bをおすすめする
まだ活発に開発中で、HTML5 Filesystem APIとLiteRT対応のためChromeが必要だが、大半のChromium系ブラウザでも動くようにできる
多くのエージェントと違う点は、インストール不要であることだ。モデルはLiteRT/LiteLLMでブラウザ内実行され、Transformers.jsより性能が良い。Filesystem APIにより、任意でサンドボックスディレクトリへの読み取りアクセスも可能
自己文書化されているので、リアルタイムのヘルプパネルで「システムプロンプトはどう使われているのか」のような質問をすると、自身のソースコードにアクセスして答えられる
「Tour」を押せば全体を見られ、来週オープンソースとして公開する予定だ
ただ、人々がモデルを評価するベンチマークは頻繁に変わりすぎるので、良い比較を見つけるのが難しい。ちなみにSonnet 3.6はGPT-3.5より約1年後に出た
批判的に見れば、これらのモデルが複雑なコーディング作業で最新の最高水準と同等ではないのは事実だ
しかし、ホワイトカラー業務のかなりの部分はExcel処理、ファイル移動、硬い法務文書の翻訳、メール草案、PPTの雑務のような作業だ
こうした作業は30〜35B以上のモデルで十分可能で、会社のデータを非公開のまま保てる利点もある
ローカルモデルについて語る人たちが期待しているのは、今年4月に出たモデルだ。Qwen 3.6 27Bと、GPUが弱いならqwen 35b a3bが対象になる
これらのモデルは、本気で最先端モデルと比較できる
代表例として、JPMorganのLondon Whale事件ではExcelのエラーで60億ドルの損失が出た
M5 Pro 18/20コア MacBook 64GB RAMを検討しているが、実際のモデルベンチマークを見つけるのが非常に難しい
たとえばQwen 3.6 35B/A3BのQ4とQ6量子化で、秒間トークン数がどのくらいなのか、誰か教えてほしい
ローカル推論の側はMoEモデルへ傾いていて、かなりの数が秒間トークン数は悪くない一方、最初のトークンまでの時間がひどい
32GB M2 Studioで使っている適当な設定をBlueskyに書いたので、フィードバックがほしい
自分で見ないとうまくできないタイプなので、助けを期待して共有する
https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...
M4 Pro 48GBでqwen 3.6 9b量子化モデルを回しているが、基本的なpi.dev/ccベースの開発にかろうじて使える程度だ
本当に意味のある作業をするには、128GBデスクトップがスイートスポットのように思える。ただ、今はそういうマシンを手に入れるのが難しい
ローカル実行は楽しいが、自分の時間もタダではないことを忘れてはいけない
個人プロジェクトでは徐々にOpenRouterへ移行しており、最大のqwenモデルを本気で使っても1日2〜3ドル未満で回している
M4 Pro 48GBならもっと大きいモデルも回せるので、モデルの知能が有用性を高める核心なら、より大きいモデルを使うほうが理にかなっているかもしれない
密な9Bがいまひとつという点には同意する
最新のM5 MacBook Proの最上位構成を使ってローカルモデルも試したが、ほとんどギリギリ動く程度だ
4090 24GBで、最近のturboquant/rotorquantのアクティベーション値メモリ最適化を活用して、qwen3.6:27Bを約128Kコンテキストで回している
そのくらいのモデルまで上げることを強く勧める。q4_xl+rotorquantの組み合わせがかなり良い
エージェントに投げる参考コードもある
https://github.com/rapatel0/rq-models
APIサブスクよりMacに数千ドル使うほうが良いと思う
ローカルモデルなら、プライバシー漏えいの心配なく、いつでもどこでも仕事ができる