jola.dev の記事「Running local models on an M4 with 24GB memory」は、24GBメモリのM4 MacBook Proでローカルモデルを動かす試行錯誤をまとめた内容です。
ここでいう「ローカルモデル」は、ChatGPTのようなクラウドサービスではなく、自分のPCの中でAIモデルを動かすこと。つまり、インターネット接続なしでも使えるし、データを外に出さずに済むのが大きな利点です。
著者は、かなり率直に「これはSOTAモデルみたいな出力ではない」と認めています。
SOTAは State of the Art の略で、要するにその時点で最先端レベルのモデルのこと。ここでは、ClaudeやGPTの上位モデルみたいな、かなり高性能なやつを想像するとわかりやすいです。
とはいえ、著者は「それでもローカルで、基本的な作業・調査・計画ができるのはかなり楽しい」と感じている。
この感覚、すごくわかります。**“全部をAIに任せる” ではなく “手元の賢い相棒” として使う**方向は、むしろ健全だと思うんですよね。
著者いわく、ローカルLLMは「動かすまで」がまず大変です。
候補として挙げているのは次の3つです。
それぞれに癖があり、使えるモデルも完全には同じではないそうです。
つまり、「どれでも同じでしょ」とはならないのが面倒なところ。ここはローカルAI界隈あるあるです。
しかもただのモデル選びではありません。
context window は、ざっくり言うとAIが一度に覚えておける文章の長さです。
長ければ長いほど、長文のやり取りや大きめのコードベースにも対応しやすい。
著者は、以下のモデルも試したそうです。
これらは「理屈の上ではメモリに入る」けれど、実際には使い物にならなかったとのこと。
一方で Gemma 4B は軽く動くけれど、tool use（ツール連携） が弱かった。
このあたり、ローカルモデルの現実がよく出ています。
“大きければ良い” でもないし、“小さければ軽いだけ” でもない。かなり難しいバランスゲームです。
著者が最も手応えを感じたのは、Qwen 3.5-9B の q4_k_s 量子化版でした。
量子化は、モデルのデータを軽く圧縮して、少ないメモリで動かしやすくする工夫です。
精度は少し落ちることがありますが、そのぶん動作が軽くなる。
この記事では、このモデルが:
という点で、かなりバランスが良かったと評価しています。
tokens はAIが扱う文章の細かい単位です。
ざっくり言えば、出力の速さの指標と思ってよいです。
40 tokens/s なら、ローカル実行としてはかなり実用的な部類ではないでしょうか。
もちろんクラウドの超高性能モデルには及びませんが、「遅すぎて話にならない」からは抜けているのが大きい。
著者の感想もかなり好意的で、
「24GBのMacBook Proで、しかも他のアプリをたくさん動かしたまま使えるのは驚き」
というニュアンスです。これは素直に面白い結果だと思います。
記事では、thinking mode（思考モード） の設定も紹介されています。
ざっくり言うと、これはモデルが答えを出す前に途中の考え方を内部で扱うモードのようなものです。
モデルによっては、これを有効にすることで、より慎重な推論やコード作業がしやすくなることがあります。
著者は、コード作業向けに以下のような推奨設定を使っていました。
temperature=0.6top_p=0.95top_k=20min_p=0.0presence_penalty=0.0repetition_penalty=1.0細かい数字の意味を全部覚える必要はありません。
大事なのは、LLMは「モデルを選べば終わり」ではなく、出力の性格を調整するパラメータがあるということです。
正直、このへんは一般ユーザーにはかなり沼です。
でも、ローカルLLMを使う醍醐味はまさにこの「チューニングの楽しさ」にあるとも言えます。面倒だけど、ハマる人はハマるやつです。
著者は、このモデルを pi と OpenCode の両方で使っています。
pi は反応が少し速いと感じている一方で、
設定の自由度が高いぶん、逆に最適化に時間を取られやすいとも述べています。
これはかなり本音っぽい。
「自分好みに組める」のは魅力だけど、気づくとAIを使いたいのにAI環境の調整ばかりしている、あの現象ですね。
OpenCode では、設定ファイルで LM Studio をローカルプロバイダとして指定しています。
ここでは、モデルに tools: true を付けたり、context_length を 131072 にしたり、max_tokens を設定したりしています。
要するに、ローカルLLMを単にチャット相手として使うだけでなく、ツールを使える作業用エージェントとして接続しているわけです。
この方向性はかなり実用的だと思います。
この記事の面白いところは、「夢物語ではなく、地味な実例」で評価している点です。
著者は、Elixirのコードで credo の警告を直したいときに、Qwenに確認させました。
するとモデルは、length(list) > 0 のような書き方を見つけて、
list != [] に置き換えるべきだと提案したそうです。
これはかなりいい。
Elixirでは、空リストとの比較のほうが自然で、不要な長さ計算も避けられます。
さらに著者が編集を依頼すると、4つの箇所を並列で丁寧に修正できたとのこと。
この用途なら、ローカルモデルはかなり頼れる相棒ですね。
次は dependabot の PR で発生した git conflict。
著者は、片方の変更を使えばいいだけの単純な衝突をQwenに見せたところ、モデルはどのバージョンを採用するかの方針はちゃんと理解しました。
ここまでは良かったのですが、実際に変更させたところで問題が発生します。
モデルは編集を忘れて、git add と git rebase --continue だけを実行しようとしたのです。
しかも git rebase --continue はエディタを開くので、OpenCode がそこで止まった可能性がある、と著者は書いています。
この失敗はすごくローカルAIっぽいです。
「わかっている風なのに、最後の1手が抜ける」。
このあたり、AIに全部任せる怖さがよく出ています。個人的には、こういう“詰めの甘さ”を前提に使うのが正解だと思います。
著者ははっきりと、Qwen 3.5 9B（Q4）はSOTAモデルのように複雑な問題を長時間自律的に解くのは無理だと述べています。
ここは大事です。
ローカルモデルに、巨大クラウドモデルと同じ期待をかけると、たいていがっかりします。
ただし、著者はそれを欠点だけとは見ていません。
つまり、「全部やって」ではなく「一緒に考えて」 のほうが向いているわけです。
これ、実はすごく健全な使い方ではないかと思います。
強力なクラウドAIは便利ですが、つい思考を外注しすぎる危険もある。
ローカルモデルは性能こそ控えめでも、自分が主導権を握りやすい。このバランスはかなり魅力的です。
記事の締めくくりでは、著者はローカルモデルのメリットを次のようにまとめています。
特に最後の「楽しい」は重要です。
技術って、結局のところ便利だから使うだけでなく、触っていて面白いから続くんですよね。
もちろん、ローカルLLMは万能ではありません。
トレーニングには大きな環境コストがあるし、性能でも最先端モデルには及びません。
それでも著者は、「もっと持続可能で、前向きなLLMとの付き合い方」として、ローカルモデルをかなり肯定的に見ています。
この視点はとてもまともだし、個人的にも好感が持てます。
AIを“巨大な雲の向こうの魔法”ではなく、自分の机の上に置ける道具として扱う感覚があるんですよね。
この投稿の肝は、
「M4 MacBook Pro 24GBでも、ちゃんと工夫すればローカルLLMはかなり実用的になる」
という実例にあります。
ただしそれは、最先端モデルをそのまま期待する話ではなく、
モデル選び・量子化・context window・thinking mode・ツール連携を含めて、じっくり調整していく世界です。
そしてその結果として、
みたいな仕事なら、かなり面白く使える。
個人的には、この記事は「ローカルLLMは性能競争だけじゃない」と教えてくれるのが良いと思いました。
“ちょうどいい賢さ” を自分の手元に置く。その価値は意外と大きいです。
参考: Running local models on an M4 with 24GB memory | jola.dev