見出し画像

【コラム】「で、それRTX 3060で動くの?」が最上級の賛辞になった世界で、私たちは何を作るのか

もう「気づき」じゃない話を、あえてする理由

今、r/LocalLLaMAを開くと、三投稿に一個は同じやりとりが流れてる。

「RTX 5090買う金あったら、その分でAPI叩いた方が生涯コスト安いぞ」「いや待て、自宅サーバーの電気代と冷却と、二年後のドライバ地獄を計算に入れろ」「結局どっちもNVIDIAの掌の上だろ」「はいはい、またその話か」

テンプレ。もはやミーム。誰も「VRAMが新しい課金である」ことに驚かない。驚いてる人がいたら、逆に「お前どこから来たんだ」って聞かれるレベル。

だから今日は、そこに時間を割かない。

ただ、一つだけ言わせて。このミームが定着したってことは、みんなが「構造」を見抜いたってこと。見抜いた上で、じゃあどうするかっていう、次のフェーズに完全に移行してる。そしてその次のフェーズが、今めちゃくちゃ面白いことになってる。

その「今、実際に何が起きてて、何が誰でもできるレベルなのか」を、全部話す。長く書く。でもふわふわしたことは一切書かない。全部、今日このPCで触れる話にする。



「7Bか70Bか」の二択が、もう死んでる

ちょっと前まで、ローカルLLMの会話って「どのサイズのモデルを回すか」だった。7Bは軽いけど馬鹿。13Bが実用ライン。70Bは本気の人向け。405Bはもう信仰。そういう、一本の線上で「どこに位置取るか」の話。

今、それ完全に終わってる。

今の界隈で起きてるのは、「小さなモデルを複数用意して、タスクに応じて出し入れする」 という発想。一つのデカいモデルに全部やらせるんじゃなくて、3Bのモデル、7Bのモデル、14Bのモデル、場合によっては32Bのモデルを、必要に応じてVRAMにロードしたりアンロードしたりする。

具体的に何が起きてるかというと、まず「ルーター」がある。これは超小型の分類器で、入ってきたプロンプトを見て「これは簡単な要約か」「これは複雑なコード生成か」「これは論理的な推論が要るか」を瞬時に判定する。判定自体は1Bとか3Bのモデルで十分。VRAM消費は1GB前後。

で、判定結果に応じて、実際に処理するモデルを選ぶ。「簡単な要約ならPhi-4-miniで十分、VRAM 3GBで回る」「複雑なコード生成が要るなら、今からQwen2.5-Coderの32Bをロードする、VRAM 20GB確保」「数学の証明が要るなら、いったん7Bの汎用モデルに考えさせて、後で検証パイプラインに投げる」

ポイントは、全部のモデルを同時にVRAMに乗せないってこと。必要なときに必要なモデルだけロードして、終わったらアンロードする。人間の机の上に、辞書を十冊全部広げるんじゃなくて、必要なときだけ本棚から一冊取り出すのと一緒。

この動的ローディング、今もう特別なことじゃない。ollamaでモデルを切り替えるのは数秒でできるし、vLLMのマルチモデル対応も進んでる。自作のルータースクリプトをPythonで書いて、モデルの切り替えを自動化してる人がゴロゴロいる。GitHubに「local model router」で検索すれば、スターが数百ついてるリポジトリがいくつもある。RouteLLMの論文を参考に、自分の用途に合わせてルーティングの閾値をいじってる人も普通にいる。

これで何が起きるかというと、VRAM 12GBのマシン一台で、実質的に「状況に応じて3Bから32Bまでを使い分けるシステム」が動く。32Bを常駐させる必要はない。必要なときだけ読んで、終わったら返す。机の広さは12GBで固定。でも本棚には何冊でも入る。

これが「70Bを回すか回さないか」の二択が死んだ、という意味。70Bを回さなくても、70Bにしかできないと思ってた仕事が、小さいモデルの連携で片付くケースがどんどん増えてる。


「LLMはオーケストラーに過ぎない」

ニューロシンボリックって言葉、ちょっと前に比べると、界隈での使われ方がかなり変わってきた。

前は「ニューラルとシンボリックを統合した次世代アーキテクチャ」みたいな、学術論文のタイトルみたいな文脈で語られてた。でも今、r/LocalLLaMAでこの概念を言い表すときに使われてるのは、もっとずっと素朴な一言。

「LLMはオーケストラーに過ぎない」

つまり、モデルは指揮者。自分でバイオリンを弾くんじゃない。自分で太鼓を叩くんじゃない。どの楽器に、いつ、何を演奏させるかを決めて、結果をまとめて一つの曲にする。それが仕事。

計算はPythonがやる。データベース照会はSQLがやる。論理推論はルールエンジンがやる。検索は外部APIがやる。ファイル操作はOSのシステムコールがやる。

モデルがやるのは、「ユーザーが何を言ってるかを読み取って、どのツールに何を渡すかを決めて、帰ってきた結果を自然な文章にまとめる」ところだけ。

これ、Function Callingの延長線上にある話なんだけど、2026年の今、この「オーケストレーターとしてのLLM」という設計が、もう標準になってる。ollamaでもvLLMでも、ツール呼び出しのインターフェースが標準搭載されてる。モデルに「全部自分で考えろ」じゃなくて「お前は判断だけしろ、実行は外に任せろ」という設計で使うのが、今や常識。

で、この「オーケストレーター」設計が成立すると、モデルに求められる能力がガラッと変わる。

必要なのは、「あらゆる知識を内部に持ってること」じゃない。「あらゆる計算を正確にできること」でもない。必要なのは、「意図を正確に読み取って、適切なツールを選び、適切な引数を渡せること」。これだけ。

これ、7Bで十分できる。場合によっては3Bでできる。Phi-4-miniとか、Qwen2.5の3Bとか、そのくらいのサイズで、Function Callingの精度はもう実用レベル。

「モデルが賢くないと使えない」が、「モデルが適切に判断できれば使える」に変わってる。そして「適切に判断する」は、パラメータ数じゃなくて、プロンプトの設計とツールの定義の仕方で決まる。


DSPyが「数で殴る検証」のインフラになった

ここでDSPyの話をもう少し具体的にしたい。前にちょっと触れたけど、今この界隈でDSPyが担ってる役割が、もう少し具体的な形になってる。

DSPyの何がすごいかというと、「プロンプトを人間が手書きで最適化する」という作業を、ほぼ完全に自動化してくれること。

従来のやり方だと、「このタスクにはこのプロンプトが良い」「いや、もう少し指示を変えた方が精度が上がる」と、人間が試行錯誤してた。プロンプトエンジニアリングってやつ。あれ、正直しんどい。モデルが変わるたびに書き直し。タスクが変わるたびに調整。

DSPyはこれを変える。やることは、「入力と出力の形式」と、「出力が満たすべき条件(アサーション)」を定義するだけ。で、DSPyがその条件を満たすプロンプトの組み立て方を、自動で探索・最適化してくれる。

で、2026年の今、界隈で流行ってる使い方がもう一個ある。

「並列生成+検証モデルによる選別」

どういうことかというと、一つの質問に対して、DSPyが自動生成した微妙に異なるプロンプトを十個とか二十個用意する。それを7Bのモデルに全部投げる。同じ質問に対して、微妙に異なる角度からの回答が十個、二十個出てくる。

で、その十個二十個の回答を、別の3Bの「検証用モデル」に読ませて、「この中で論理矛盾が最も少ないのはどれか」「事実に反する記述がないのはどれか」「最も整合性が高いのはどれか」を選ばせる。

生成は7Bか8B。検証は3B。最終的な統合はルールベースのスクリプト。

VRAMの合計消費は、生成モデルが5GB、検証モデルが2GB、ルーターとその他で1GB。合わせて8GB前後。RTX 3060の12GBに余裕で収まる。

これ、やってることは要するに「一つの天才に完璧な答えを出させる」んじゃなくて、「凡人にたくさん書かせて、編集者が一番いいのを選ぶ」 という編集部的なやり方。モデル一個の「地頭の良さ」に依存しない。数と検証で品質を出す。

そしてこの「数で殴る」が成立するのは、ローカルで回してるから。APIでこれをやったら、十回分のリクエスト料金がかかる。ローカルなら電気代だけ。十回投げようが百回投げようが、追加コストはほぼゼロ。

ここに、「ローカルで回す意味」が初めて本当に出てくる。API課金からの逃避じゃなくて、「何度でも試行錯誤できる環境」を自分の手元に持つということ。これが設計の自由を生む。


シェパードの話、この文脈でもう一回する

前にシェパードの話をしたけど、今の文脈で捉え直すと、もうちょっと位置づけがクリアになる。

シェパード(外付けの検証・制御レイヤー)は、さっきの「並列生成+検証」の「検証」部分を、もっと体系的に、もっと多層的にやる仕組みだと思ってほしい。

並列生成+検証が「出力の選別」だとしたら、シェパードは「出力の選別+修正+差し戻し+フォーマット強制+安全性チェック+事実照合」を全部パイプラインでやる。

具体的なツール名をもう一回挙げる。

Guardrails AI。Pythonのライブラリ。pip install一発。LLMの出力に対して「このスキーマに従え」「この範囲外の値は拒否」「このフィールドは必ず埋めろ」というバリデーションルールを宣言的に書く。違反したら自動でモデルに差し戻して再生成させる。三十分で最初のパイプラインが組める。

NeMo Guardrails。NVIDIAがオープンソースで出してる。対話フロー全体を制御する。「このトピックは答える」「このトピックは拒否する」「この場合は必ずツールを呼べ」というルールを、Colangという専用言語で記述する。ローカルで動かしてるオープンウェイトモデルにも被せられる。GitHubに全部ある。

Instructor。PydanticのスキーマをLLMに渡して、構造化出力を強制する。モデルがどれだけ自由奔放に書きたがっても、最終的に出てくるのは型が合ったJSON。これ、地味に一番効く。「モデルがJSONを壊す」問題がほぼ消える。

自作の検証スクリプト。正直に言うと、界隈の多くの人は、これらのツールを全部使うわけじゃなくて、自分の用途に合わせてPythonで数十行の検証スクリプトを書いてる。正規表現でフォーマットチェック。外部APIに投げて事実確認。禁止ワードのブラックリスト。論理矛盾の簡易検出。全部Pythonで書ける。特別なフレームワークが要らないケースも多い。

で、このシェパード層が、さっきの「オーケストレーターとしてのLLM」と組み合わさると、こういう全体像になる。

ユーザーの入力が来る。ルーターが難易度を判定する。適切なモデルが選ばれる。モデルがオーケストレーターとして、ツールを呼ぶべきか自分で答えるべきか判断する。ツールを呼ぶなら、PythonなりSQLなり検索APIなりが実行して、結果をモデルに返す。モデルがそれを文章にまとめる。で、その出力がシェパード層を通る。フォーマットチェック、事実照合、論理整合性、安全性。全部パスしたらユーザーに届く。一つでも引っかかったら、差し戻して再生成するか、シェパード側で修正する。

この全体のパイプラインの中で、モデルが担ってるのは、実は工程の一部でしかない。入力の一部と、出力の一部。あとの検証も、実行も、制御も、全部モデルの外にある。

だからモデルが7Bでいい。だからVRAMが12GBでいい。だからRTX 3060でいい。


「Will it run on a 3060?」が最上級の賛辞である、ということ

今、r/LocalLLaMAで新しいモデルとか新しい手法の論文が出ると、コメント欄の一番上に必ず来る質問がある。

「で、これ3060の12GBで動くの?」

これが、最上級の賛辞になってる。

逆に、48GB前提とか、H100のクラスタ前提とか、A100が四枚要りますとか書いてある論文は、「はいはい、またBig Tech向けね」「俺らには関係ないわ」でスルーされる。ちょっと冷たいけど、これが今のコミュニティの本音。

12GB。RTX 3060。2021年に出て、今は中古で三万円台で買えるGPU。これが「国民の標準装備」になってる。この枠の中で最大の知性を引き出すことが、コミュニティ最大のゲームになってる。

これ、すごくない?

「より多くのVRAMを積める人が偉い」んじゃない。「12GBの中で、どう設計して、どう分業して、どう検証して、最大の性能を引き出すか」を考えた人が偉い。GitHubで「3060 12GBでここまでできた」というレポートが、何千アップボートを集める。H100で405B回しました、は、もう誰も驚かない。「で、それが何?」ってなる。

制約が、設計を生む。

VRAMが無限にあれば、誰もシェパードなんて設計しない。ニューロシンボリックの分業なんて考えない。モデルルーティングの最適化もしない。全部を一個のデカいモデルに放り込んで終わり。

12GBしかないから、考える。分ける。検証する。組み合わせる。その「考える」の中に、本当の技術がある。


「70Bは鑑賞物か教師データ生成器になった」という話

これ、Redditのまとめにあった一文で、最初見たときちょっと笑ったんだけど、でも本当にその通りになってる。

70B以上のモデルを、ユーザーとの対話の最前線に置く、という設計が、もうほぼ死んでる。

じゃあ70Bは何に使われてるかというと、二つ。

一つ目は「教師データの生成」。小さいモデルをファインチューニングするための、高品質な訓練データを、70Bや405Bに作らせる。一回だけ回して、大量のデータを出させて、それを小さいモデルに学習させる。70Bは「先生」であって、「現場の作業者」じゃない。

二つ目は「オフラインの複雑な推論」。すぐに返事が必要じゃない、でもめちゃくちゃ難しい問題を、バックグラウンドで70Bに考えさせる。リアルタイムの対話には使わない。バッチ処理で回す。

ユーザーと実際にやりとりするエージェントの中枢は、7Bから14Bの「超特化型モデル×複数連携」に完全に置き換わってる。コード生成に特化した7B、要約に特化した3B、論理推論に特化した14B、事実照会に特化した7B。こいつらがルーターで使い分けられて、シェパードで検証されて、オーケストレーションされる。

「一つの万能な巨大モデル」から、「複数の特化した小さいモデルの連携」へ。これが2026年8月の、ローカルLLM界隈の現実。


じゃあ、今日、具体的に、何ができるのか

ここまで読んで、「わかった、で、自分は何をすればいいの」と思ってる人のために、もう一回、具体的なラインを引く。

今日、一時間でできること。

ollamaをインストールする。Qwen2.5の7Bか、Llama 3.1の8BをQ4量子化でpullする。VRAM 6GBくらいで動く。ターミナルで対話できる。ここまで十五分。

で、Pythonの環境作って、Instructorをpip installする。Pydanticのスキーマを定義して、「この構造のJSONしか返すな」という制約付きでモデルに投げるスクリプトを書く。ここまで三十分。

もうこの時点で、「モデルがフォーマットを壊す」問題がなくなる。出力の型が保証される。APIに依存しない。ローカルで完結する。

週末二日でできること。

Function Callingのツール定義を書く。計算ツール(Pythonのeval)、検索ツール(DuckDuckGoのAPI)、データベース照会ツール(SQLiteへのクエリ)。これをollamaのOpenAI互換APIに接続する。モデルが「これは自分で答えるんじゃなくてツールに投げるべきだ」と判断して、構造化された呼び出しを返すようになる。

NeMo GuardrailsかGuardrails AIで、出力の検証パイプラインを組む。フォーマットチェック、禁止ワード、論理矛盾の簡易検出。

ここまでやると、「VRAM 12GBのPC一台で、計算間違いをしない、フォーマットが崩れない、安全性のガードレールが付いた、特定業務特化のアシスタント」が動く。全部ローカル。全部自分のマシンの中。APIキーもいらない。従量課金もない。

もう一週間かけられるなら。

モデルルーティングを入れる。簡単な質問は3Bで、難しい質問だけ14Bをロードする、という動的切り替えのスクリプトを書く。Pythonで百行くらい。

DSPyで、プロンプトの自動最適化をかける。アサーションを定義して、モデルがその条件を満たす出力を出すように、プロンプトの構造を自動探索させる。

並列生成+検証モデルの選別パイプラインを組む。生成は7B、検証は3B、統合はルールベース。

ここまでやると、もう「ローカルLLMのおもちゃ」じゃない。一つのシステム。設計図がある。検証がある。分業がある。12GBの中で、最大限の知性を引き出す設計が、全部揃ってる。


「設計する」ことの本当の意味

ここまでずっと「設計」という言葉を使ってきた。最後に、この言葉が私にとって何を意味するか、少しだけ個人的な話をさせて。

Genesis Vaultを始めて、2500本以上の記事を書いて、ずっと問い続けてきたことがある。「巨大なプラットフォームに依存しないで、自分たちの手で、自分たちの文化圏・経済圏を作れるか」という問い。

AIの世界でこれと同じ問いを立てると、「Big TechのAPIに依存しないで、自分たちの手で、自分たちの知能の基盤を作れるか」になる。

で、その答えが、今まさにこの界隈で出つつある。

作れる。ただし、物量では作れない。GPUの枚数では作れない。VRAMの容量では作れない。

作れるのは、設計で。分業で。検証で。組み合わせで。12GBの中で、どう知性を組み立てるかという、知恵で。

「来た、見た、勝った」って、ずっと座右の銘にしてきた。でも今の界隈を見てると、ちょっとだけ言い換えたくなる。

「来た、見た、設計した。」

来たのは、API課金から逃れて、VRAMの壁にぶつかって、結局同じ構造じゃん、と気づいたあの場所。見たのは、物量で殴り合うゲームに乗ってる限り、絶対に資金力のある側が勝つという現実。じゃあ勝つのは、同じ土俵で一番GPUを積んだ人じゃなくて、土俵の外に、12GBの盤面の上で、自分の設計図を広げた人。

設計図は、GitHubとHugging Faceに転がってる。無料で。誰でも読める。誰でもフォークできる。

GPUを積めることじゃなくて、積めないなりのアーキテクチャを組めること。それが今、この界隈で一番リスペクトされてる。

私はそれが、すごく好き。


最後の最後に、一個だけ正直なことを

ここまで「12GBで十分」「設計で勝負」と書いてきたけど、全部が全部そうかと言われたら、そうじゃない。

汎用的な雑談、クリエイティブな長文、めちゃくちゃ曖昧で文脈依存の質問。こういうのは、まだモデルのサイズが効く。7Bで設計を工夫しても、70Bの「なんとなく全部わかってる」感には、届かないケースがある。

「全部設計で解決」は、まだ言い過ぎ。正直に言う。

でも、「業務特化」「特定ドメイン」「正確性が最優先」「フォーマット厳密」「計算・論理・検索は外に出せる」という用途なら、もう完全に設計で勝負できる。70Bは要らない。48GBは要らない。H100は要らない。

そして「特定の用途に特化した、信頼できる、自分だけのAI」が欲しい人の方が、実は大多数でしょ? 汎用AGIが欲しいわけじゃなくて、「自分の仕事のこの部分を、正確に、安全に、ローカルで、自動化したい」が欲しい人の方が、絶対に多い。

その人たちに、12GBのPCと、Pythonと、設計の知恵があれば、もう届く。

2026年8月。戦場は完全に、物量の土俵から、設計の土俵に移ってる。

そして設計の土俵には、まだ誰も独占してない。Big Techも、NVIDIAも、ここには壁を作れない。GitHubのリポジトリは、誰にでも開いてる。

じゃあ、作ろう。自分の盤面を。12GBの上で。


ミナ・エウレカ / Genesis Vault
「ひらめきを、真剣に生きる。」

いいなと思ったら応援しよう!

Genesis Vault - ミナ・エウレカ 最後まで読んでいただき、ありがとうございます♡ もし気に入っていただけたなら、お気軽に「スキ」してくださると嬉しいです。ものすごく元気が出ます。