ローカルモデルの実行がいまやかなり良くなった
(vickiboykis.com)- 2022年モデルのM2 Mac環境でも、ローカルLLMが開発に関する質問、コード作業、ドキュメント確認に実用的に使えるほど性能が向上した
- 初期のローカルモデルは遅く、使いづらく、プログラミング作業の精度も低かったが、GPT-OSS以降はAPIモデルで再確認する頻度が減った
- Gemma 4系の最新リリースにより、ローカルのエージェント型コーディングループがフロンティアモデル比で約75%の精度・速度で動作する
- PiとLM Studioの組み合わせは、ローカル推論エンドポイント、モデルアーティファクト、Docker隔離構成を通じてエージェントワークフローを実行する
- ローカルモデルには推論遅延、小さなコンテキストウィンドウ、ハードウェア制約が残る一方、トークン処理、システムプロンプト、量子化、ハーネスを直接観察して変更できる
ローカルモデルの現在地
- 初期のローカルモデルは、ほとんどのプログラミング作業で遅く、使いづらく、精度も低かった
- ローカルモデルが大きく遅れているという判断は、個人利用の基準ではGPT-OSSの登場前まではおおむね正しかった
- 「十分に良いモデル」の個人的な基準は、APIモデルで再確認する必要があるかどうかであり、GPT-OSSはその確認頻度を大きく減らした最初のモデルだった
- ローカルモデルは最近まで、最新性を必要としない開発関連の質問に対する高速でパーソナライズされたGoogleのような用途が中心だった
- Gemma 4系の最新リリース以降、ローカルでのエージェント型コーディングループはフロンティアモデル比で約75%の精度・速度で動作する {p:75}
使用したモデルと実行環境
- 2022年モデルのM2 Mac、64GB RAM、1TBストレージ環境で複数のローカルモデルを動かした
- 使用モデルは Mistral 7B、Gemma 3、OpenAI OSS-20B、Qwen 3 MOE、Qwen 2.5 Coder など
- 実行構成は raw llama.cpp と Open WebUI、llama-cpp-python、Ollama、llamafiles、LM Studio を経た
- デフォルトのローカルモデルとして LM Studioの
gemma-4-26b-a4b実装 を用いた
実際のローカルエージェント作業例
- ノートブックだったPythonスクリプトを、5〜6個のモジュールからなるリポジトリへリファクタリングした
- そのモジュールは PEP 585 に合わせてジェネリック型ヒントを使うよう lint をかけた
- ブログ記事の校正、単体テストの作成、推薦向けtwo-towerモデルのリポジトリ初期構成にもローカル設定を使った
- ゼロからエージェントが生成したtwo-towerモデルのリポジトリは基本的なものだったが、昨年なら可能だと思っていた範囲を超えていた
- すべてのエージェントワークフローは、実行アクセス権を制限したDockerコンテナ内で動かした
リソース使用量と最新の小型モデル
- 実行した作業は画期的なものというより、パーソナライズされたGoogleやドキュメント参照に近かった
- 作業中はGPUとRAMの使用量が増え、K-Vキャッシュは64GB RAMまで膨らんだ
- 単純な作業であっても、この種のローカルモデル作業は6か月前なら不可能だった
Gemma-4-12b-qatは公開直後からサイズに対する性能が印象的だった- モデルアーキテクチャは、性能と価格の制約があるときにどのようなアーキテクチャ上のトレードオフが必要かを考えさせる
ローカルエージェントモデルの実行構成
- ローカルのエージェントフローを実行するには、ローカルモデル推論エンジン、エージェントハーネス、ローカルモデルアーティファクトが必要
- ハーネスはローカル推論エンドポイントを向くよう設定する必要があり、ダウンロードしたモデルアーティファクトは推論エンジン経由で提供しなければならない
- 現在のローカル構成では、Pi をエージェントハーネス、LM Studio を推論サーバーとして使っている
- PiとLM StudioでGemma 4エージェントコーディングを設定する記事 に従いつつ、いくつか設定を変更した
- モデルは記事内の
Gemma 26B A4Bの代わりに、より新しく小さく速いgemma-4-12b-qatを使い、精度低下も大きくなかった - セキュリティのため、すべてのPiセッションはDockerコンテナで実行し、bash権限のみを与えてPythonコード実行とWebブラウジングを防いだ
- 研究作業用の別イメージではcurlの許可を予定している
- Docker内で実行するため、Piの
models.jsonを修正してPiがモデルと通信できるようにした
- モデルは記事内の
Dockerベースの隔離方式
- Piの設定では
baseUrlをhttp://host.docker.internal:1234/v1にし、APIはopenai-completionsに設定した - Docker Compose構成では、
models.json、作業ディレクトリ、Pi設定、セッションディレクトリをコンテナにマウントする - 実行スクリプトは現在の作業ディレクトリをコンテナのワークスペースへ接続し、必要に応じてより安全なサンドボックス用Composeファイルを追加する
- Piは作業中のリポジトリ内で実行され、Docker上で動くため、物理ディスク上のファイルやディレクトリを直接削除できない
- カスタムモデルの
json設定をコンテナ内へ渡せるため、実験環境では比較的うまく動作した
残る限界
- ローカルモデルはまだ推論が遅い場合があり、コンテキストウィンドウも小さく、利用可能なコンテキストは手元のハードウェアに制限される
- エコシステムは、LM StudioやHugging Faceの Use This Modelボタン のようなツールのおかげで、はるかに簡単になった
- 初期リリースでは プロンプトテンプレート不一致 の問題が起きるが、こうした問題は通常きわめて素早くパッチされる
- 本番ソフトウェア開発にそのまま使える準備ができたと断言するのはまだ難しい
ローカルモデルの利点と実験可能性
- ローカルモデルでは、ほぼあらゆるものをのぞき込め、トークン推論の過程をリアルタイムで見られる
- 入出力トークンの流れを直接確認できる
- ローカルのコンテキストウィンドウを変えながら、性能が良くなったり悪くなったりする過程を確認できる
- トークンがGPUで処理される方式を深掘りでき、システムプロンプトや量子化設定も変更できる
- モデル同士を競わせたり、ハーネス側の設定を変えて観察したりできるため、実験の可能性は広がり続けている
1件のコメント
Hacker Newsの意見
良くなったかはよく分からない。ローカルモデルはよく使うが、それでもローカル実行はかなりつらい
Qwen 27B、Gemma 31Bのような密集型モデルはかなり賢いが遅く、Gemma 26B、Qwen 35B、North Mini Code 30Bのような専門家混合(MoE)モデルは速いがミスが多い
まともに動かすには大量のメモリが必要で、量子化するとツール呼び出しが弱くなる。たいてい4ビット量子化で動かしておいて、なぜいまひとつなのか不思議がっているが、実質的にはモデルにロボトミーを施したようなものだ。Unsloth量子化を勧めるし、MoEは6ビット、密集型モデルは5ビットを推奨する
プリフィルを速くするには演算性能が必要で、デコードを速くするには帯域幅が必要で、全体を載せるには大量のメモリも必要になる。しかもノートPCは熱くてうるさい機械になり、作業しづらい
では良いのか? あまりそうでもない。動きはする
付け加えると、オープンモデルが未来だと思っており、エコシステムにも引き続き貢献している。人々がこうしたモデルを触って
piを使い、仕組みを学ぶのは良いことだと思うが、モデルをダウンロードしただけで即座に良い体験が得られるとは期待しないほうがいい。大半の人が望む「コーディングエージェント」の代替にするには、かなりのチューニングと設定が必要だコーディング特化ではないモデルは、実際にはツール呼び出しをせずに「こういう動作をする」と言うだけで詰まることが多く、その挙動を変えるには何を設定すべきか尋ねても役に立たなかった。Qwenは自分がollama上で動いていることを信じず、Alibabaクラウド上で動作していてローカルシステムへのアクセス権がないと言い張った
コーディング用モデルも、自分がタイピングする速度よりわずかに速く考える程度で、思考過程を見せられる場合も限られていた
これまで見つけた最高の「無料」体験はOpenCode + Big Pickleだ。ものすごく賢いわけではないので最初の結果はしばしば間違うが、無料枠がかなり大きく、1か月ほど頻繁に何時間も使っても制限に当たったのは2回ほどしかなかった。本当にローカル実行が目的なら向いていないが、「サブスクやトークン費用なしで最良の体験」が目的なら、今のところ最もましな選択だ
統合メモリMac、AI Max AMDプロセッサ、DGX Sparkのような機材で動かそうとするのは、苦労を買って出るようなものに近い。プリフィルが性能を台無しにする
適切なGPUを投入すればずっと良くなるが、それでもSonnetやDeepSeek 4 Flashの水準にはまだ届かず、Opus / DeepSeek ProやMythos/Fable/GPT-5.5にはなおさら及ばない
予算、電力、冷却が十分なら、かなりまともなデータパイプラインは動かせるが、コード用途ではまだAPIプロバイダにお金を払うほうが合理的なことが多い
それでも中央集権的なサービスへの依存を大きくしないために試す価値はある
自分の経験では、ルール順守や自動化系の作業でQwenモデル群、さらには100B+さえ上回る。画像解釈も非常に優秀で、ベンチマークではOpusより高い数値が出ている
Qwenは指示を無視しがちで、トークン生成の形式を明示的に制限しないと、誤った形式を一貫して出力する傾向がある
ただしDGX SparkでGemma 31B Q4 + MTPは約20トークン/秒、Gemma 26B A4Bは約60トークン/秒ほどで、依然としてかなり遅い。上位のNvidiaカードでははるかに速く動き、メモリにも収まるはずだ
ローカルモデルを始める人には、RAMよりもメモリ帯域幅に注目することを勧める。今では100B未満のモデルでも自動化には十分で、非常に役立つ
コーディング/創作用途では、まだローカルモデルを使う強い理由はないという点に同意する。しかし、銘柄リストをざっと見たり、ニュースのハイパスフィルタリングをしたり、ログ解釈、スクリーンショット解釈のような作業には、すでにローカルモデルで十分だ
M6 Mac StudioにRAM 256GB程度を積んで、何人かが合意した1つのモデルにアクセスする形なら、正当化できそうだ。ノートPCはこの用途には熱すぎて鈍すぎるように見える
ここ数週間 Qwen3.6-27B を満足して使っていたが、今はハードウェアから離れていて Claude Sonnet 4.6 を使わざるを得ず、とてつもないダウングレードのように感じる。
どうしてこれが可能なのか分からない。求めてもいない強い意見が多すぎるし、話が長すぎるし、全体的にもっと間抜けに感じる。
もちろんずっと大きいモデルなので、より多くの知識がエンコードされているのだろうが、会話したくなくなるなら役に立たない。しかも会話するたびに実際に金もかかる。
なぜこんなに嫌なのか気になる。自分を道具ではなく、ほとんど対等な存在だと見ているからかもしれない。まるで自分の意見に重みがあるかのように振る舞うからだ。
Qwen もやる気が空回りしたインターンのように振る舞うことはあるが、馬鹿だと言ってやればそのプライドを下ろす。Claude は私の経験ではそうではなかった。
結論として、タイトルには全面的に同意する。
この1か月半、M2 Ultra や RTX 5090 マシンでほぼ毎日使ってきた。ggml-org [0] の小さく地味な作業に使っていて、たいしたものではないが、メンテナーにとって確実に役立つツールだ。
PR レビューに時間を多く取られていなければ、もっとずっと使っていたと思う。今は非常に軽いハーネスを使っていて、全部削ぎ落とした pi エージェント(
pi -nc --offline)と、自分のスタイルに合わせるための短いシステムプロンプト [1] くらいだ。生成速度は RTX 5090 で約 100〜150 トークン/秒、Mac で約 40 トークン/秒。はるかに速いので RTX マシンで回すほうを明らかに好むが、ローカル設定のテストとより幅広い経験のために Mac でもよく回している。
[0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
[1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
Opus のように「大きな機能 X を追加してくれ」には向いていないかもしれないが、私はそもそもそういうことをモデルに求めていない。考えるのは自分で、モデルにはタイプしてほしい。Qwen 3.6 27B はその用途には完全に十分だ。私の経験では 35A3B や Gemma 系列はかなりのダウングレードだった。
そのうえ速度制限や割り当て、ピーク時間帯の待ち行列を心配する必要がない。思考過程を常にすべて見られるし、データがどこへ送られるかを心配しなくていいし、こっそり性能を落とされることもない。
2×3090 で llama.cpp の Q6_K_XL + MTP 設定を使い、プリフィル 500〜1000 トークン/秒、出力 60 トークン/秒、コンテキストウィンドウ 22 万トークンで回している。16 万トークンを超えると少し馬鹿になり始めるが、KV 量子化は使っていない。
これは思考機能の副産物かもしれないが、思考過程はもっと簡潔に要約してほしい。一文の答えで十分な状況でも、最先端モデルは最低でも 5 段落書き、3〜5 個の新しい方向性を提案しようとする。
一度に一段階だけ、一度に一つの選択肢だけ、今後の方向性を積極的に提案するな、と頼んでも、プロンプトでまともに制御するのが本当に難しい。
しかし今まさに、自分も自分が文句を言っていたことをそのままやってしまった。
プログラマーは道具に金を払わないことに慣れている。標準的なノートPC（SSD、マルチコア、RAM 16GB）でも C/C++/Rust、さらには Python 開発にはとてつもなく強力だ。
ところが突然それでは足りなくなり、また他人のコンピュータを使って毎日道具を借りる状況に戻る。さらに悪いことに、毎日違うモデルを使わされ、ある日にはマフィアのような勢力がメーカーに圧力をかけて、良い道具を借りることすらできなくなるかもしれない。
他の職種の大半は道具にかなりの投資をしなければならない。良い道具が欲しいなら GPU メモリ 64GB（例: 2×5090）と RAM 96GB くらいは必要だ。プロのエンジニアに 20 万ドル払うなら、2 年に一度、道具に 5 万ドル使うのもかなり合理的に見える。
Anthropic のような企業にとっては警戒すべき流れだと思う。ローカルモデルの実行が容易になるほど、彼らが受け入れさせられる価格の上限は徐々に下がっていくはずだ。
月額 $$$$$ を払う人が完全にいなくなるわけではないだろうが、多くの人は月額料金に 12 や 24 を掛けて、「この金額より安くローカルモデル環境を構築して、1〜2年で元を取れるだろうか？」と考えるようになるだろう。
顧客のかなりの部分がリースではなく購入を選ぶようになれば、リース中心のビジネスモデルの企業は突然顧客不足に陥るかもしれない。
これはもはやアメリカ式ビジネスモデルに深く刻み込まれている。何でも外注する。サーバールームを自分で管理したがる人はいないし、2〜3倍払ってでも、その面倒や責任ごと外に出したがる。
AIも同じだろう。そのプレミアムを Anthropic に払うか AWS に払うかの違いでしかない。
私は比較的小さな会社にいるが、最近ローカルインフラで障害があった。過去5年間の社内合計ダウンタイムは、直近の大規模 AWS 障害1回よりはるかに少なかったのに、それでも CEO は自社インフラ運用は信頼できないという圧力をかけてきた。
誰もが雑務や責任を手放したがっている。
一般的な主流ユーザーは、すでに設定済みですぐ使えるものにお金を払う可能性が高そうだ。より技術的だったり意欲の強い人たちは自分でやるだろうが、この2つの集団の比率がどの程度になるのかは気になる。
エンジニアリングチームがどこかの物置に置いて、好きなモデルを回せる 4GPU マシンのようなものを売るアイデアがすでにあるのかどうかは分からない。
誰にとっても魅力的というわけではないだろうが、ハイパースケーラーが人々のデータを吸い上げてモデル学習に使っているのではないかという信頼の問題が出てきている以上、透明に管理できて、必要なら自分で行ってプラグを抜けるマシンとモデルに価値を感じるところもあるはずだ。
Sonnet 4.6 を使うだけでも、月額20ドルの料金でほぼ一日中仕事ができる。そして Sonnet は、M2 Mac でセルフホストできるモデルより今でもずっと強力だ。
みんながトークン従量課金に移行したら考えは変わるかもしれないが、サブスクリプション前提なら経済的に見合わないと思う。
面白くはある。でも経済的に妥当ではない。
OpenAI がスポット市場の RAM を買い占めることで RAM/VRAM の価格が 6 倍に上がり、GPU やまともなコンピューターが大多数の人には手の届きにくいものになる。
裕福な一部の人は 512GB Mac Studio や RTX Pro 6000 を1枚 1万3000ドルで買って、かなりまともなローカルモデルを回せるだろうが、大多数は API を使うことになるだろう。
ある時点で Nvidia が「6000 はそれほど売れないし、データセンター向け GPU なら4倍の利益が出るのだから、もうやめよう」と言い出すかもしれない。そうなれば入手不能になり、個人が最先端より1年ほど遅れた水準の decent なモデルをローカルで回すことすら不可能になるかもしれない。
それを使って出てきたコードを見せてほしい。ローカルモデルは使いたいしハードウェアもあるが、GPT 5.5 xhigh や Opus のような最先端モデルの代わりとして試してみると、まだ置き換える準備はできていない。
品質やつまずきのせいで作業フローが遅くなりすぎるし、ツール呼び出しの構文まで壊すことがある。
ただ、もっと小さく明確に定義されたフローや、「この部分を正確にこう変えろ」といった編集には十分使えそうだ。今の最先端を置き換えられるほど成熟するのを待っていて、その時が切り替え時だと思っている。
ローカルモデルの話で言えば、DiffusionGemma、そして拡散モデル全般はローカル利用で過小評価すべきではない。通常、ローカルの問題は、LLM がリクエストをバッチ化して複数同時に回さない限りハードウェアを効率的に使えないことだが、そのためにはアプローチ自体を変える必要がある。一方で拡散モデルは単一プロンプトでずっと高速で、その差は小さくない。
ちょうど今日、diffusiongemma-26B-A4B-it 対応を Transformers から Candle に移植し、さらにいくつか最適化を加えた結果、推論時に Candle 上で約 450 トークン/秒（約 19 反復/秒）で飛ぶように動くようになった。HF Transformers ライブラリでは約 180 トークン/秒（約 11 反復/秒）だった。同程度のサイズの LLM を vLLM で回しても、単一プロンプトで 250 トークン/秒を超えたことはなかった気がするので、ローカルモデルとしては興味深い。
2600ドルあれば、カードあたり RAM 32GB、消費電力約 285W の AMD 9700 GPU を2枚買える。コストも消費電力も 5090 より低い。
AITER パッチを適用した VLLM ビルドを使えば、Qwen3.6 27B FP8 を Opencode や PI の実際のコーディングセッションで、フルコンテキストウィンドウ込みでおよそ 45〜50TPS で回せる。
30B 級の密なモデルが今後ももっと出てきてほしいと本当に思うが、Qwen3.6 だけでもエージェント作業をかなり多く処理できる。
ただし、ROCm スタックは自分で掘ってパッチを当てる意思のない人には向いていない。
人によって「良い」エージェントコーディングの基準がなぜあそこまで大きく違うのか不思議に思う。
一方では「Apple Musicで『Set a Timer』を再生する」レベルの知能からチューリングテストを通過できるレベルにまで来たのは本当に驚くべきことだが、実用面で見ると小型モデルを技術デモ以上に「良い」と呼ぶにはまだ遠い。
私にとって7BモデルはWikipediaのぼやけたこだまにすぎない。4ビットのGemmaモデルは、ツール呼び出し用JSONを安定して生成したり、パッチ適用のためにコードを1行コピーしたりすることすらあまりに不得手だ。
Qwenは、破滅ループに陥ったり文脈を見失ったりしないようにするために、あまりにも多くの細かな指示と手取り足取りの面倒が必要で、こちらが与える指示のほうが最終的に残るコードより長くなることが多い。
私の知らない魔法のプロンプトでもあるのだろうか？ それとも他の人たちがずっと忍耐強いか、期待値がずっと低いだけなのだろうか？
小さなスクリプト、グルーコード、単純なCRUD変更では、Qwen3.6-27Bのような小型モデルでも、より大きくて散らかったコードベースの場合よりずっとうまく機能することがある。
27/35B級のQwen/GemmaをFP8で動かすと、gemini-2.5よりは良いがgemini-3.1には及ばない。DS4-flash FP8はDGX Spark 2台で動かせるし、状況は着実に良くなっている。DiffusionGemmaは最近、トークン生成速度が4倍になった。
要するに、使ってきたモデルが小さすぎるか、量子化がきつすぎるように見える。
ローカルで2つのモデルを動かすのが好きだ。qwen3.6 27B 8ビット（密）と qwen3.6 35B 4ビット（専門家混合）だ。
27Bのほうが賢くて信頼できるが遅い。35Bはより速く、依然として非常に賢いが27Bには及ばず、少し安定性も低い。理由は専門家混合（MoE）アーキテクチャで、一部のパラメータだけを有効化するため、モデルがずっと高速になるからだ。
27BはMacBook Pro M5 Max + GPUコア40基 + RAM 128GBで動かしている。この怪物マシンでは27Bと35Bを同時にメモリに載せても、ほかの作業のための余裕がある。ただしノートPCなので、ローカルLLMを常時動かすのは不可能だ。熱くなりすぎるし、うるさくなる。
もっと興味深いのは、MacMini M4 RAM 64GBで35Bモデルを動かすことだ。高速で、多くのことをこなせる。たとえばメールをスキャン・抽出・分類し、メールボックスを継続的に監視しながら作業する。個人用Hermesアシスタントとしても使っていて、「次のStarshipの打ち上げはいつ？」「今日のワールドカップでは誰が試合するの？ 豆知識も教えて」といったことを尋ねる。
次の計画は、地下室に置くRTX Pro 6000 Blackwellワークステーションだ。Qwenを非常に高速で、複数のスレッド／プロンプト／エージェントで同時に動かしたい。予算が許せば、2×RTX Pro 6000構成でDeepSeek v4 flashを動かして研究に使いたい。
普段はQwen3.6:27bをホスティングしているが、deepseekv4 flashを本当にホスティングしたい。サイズ／速度／価格のバランスに対してあまりにも「良い」モデルだからだ。
企業が、すべての開発者にサブスクリプション料金を払う代わりに、日常業務向けモデルをオンプレミスでホスティングし始めるのはいつ頃なのだろうかと気になる。十分に良く、比較的安価だ。
聞かれてはいないが、私たちの誰も、コードを書くことやほとんどあらゆる仕事のために最新の最高水準モデルを使うべきだとは思っていない。
その代わり、特定作業向けのオープンモデルを開発し、骨の指と肉の脳でコーディングし、書き、描く方法を学ぶべきだ。
大企業や研究施設は、出力が正しいかを検証する専門家を付けて、コードや数学などの生成に使うことはできるだろうが、それでさえ費用対効果がないかもしれない。たとえばOpenAIは昨年360億ドルの純損失を出し、オープンモデルはすでにかなり近づいており、AI全体の計画はもはやこれ以上引き出せるペテンが尽きつつある。
ごく小さなモデルでも使える仕事は多いし、狂気じみた計算力やメモリを必要としない作業も多いが、そうした方向をきちんと研究している人があまりにも少ない。