どうも、ローカルLLMおじさんです。
GPUにモデルを載せる。
Ollamaで動かす。
vLLMでスループットを出す。
量子化して、VRAMに押し込む。
全部、自分の手元で動く。
くぅ〜、たまらねぇ。
……と思っていた時期がありました。
気づけば、Agentを作っていたはずなのに、モデルのお世話をしていました。
うお、推論したいだけなのにVRAMと相談が始まった。
ローカルで推論できることが強い、と思っていた
昔の感覚では、ローカルで動かせることが強さでした。
APIに依存しない。
トークン課金を気にしない。
データを外に出さない。
モデルを自分で選べる。
オフラインでも動く。
それがちゃんとした構成だと思っていました。
もちろん、今でもこれは間違っていません。
機密データを外に出せない環境。
大量バッチで課金が効いてくる用途。
オフライン要件のあるシステム。
特定モデルに固定したい基盤。
そういう場所では、今でもローカル推論は強いです。
ただ、個人開発やPoC、Agent/RAGの実験で同じ重さを持ち込むと、話が少し変わります。
trend-to-rule でも、最初はローカルで回していた
実際、trend-to-rule でも最初はローカルのモデルを使っていました。
vertical判定、つまり入力がファッションのどの領域の話かを推論する部分に、gemma3 を使っていた時期があります。
そのあと gemma4 に上げました。
コミット履歴を見ると、ちゃんと残っています。
軽い判定だし、ローカルで十分だろうと思っていた。
モデルを上げれば判定も良くなるはず、とも思っていた。
でも、やっていくうちに、見ている場所がズレていることに気づきました。
gemma3 から gemma4 へ。
モデルを上げる。
VRAMを見る。
ロード時間を見る。
量子化を見る。
推論速度を見る。
見るものが増える。
でも、本当に見たかったのは、vertical判定の精度そのものではありませんでした。
そのvertical判定が、後段の retrieval や reasoning の足場として効いているかでした。
うお、モデルを上げていたはずなのに、責務どこいった。
モデルを上げても、欲しかった「軽さ」は来なかった
ローカルモデルを上げると、判定そのものは良くなります。
でも、体感として欲しかった「開発に戻れる軽さ」は、思ったほど来ませんでした。
モデルを変えるたびに、ロードし直す。
VRAMの空きを気にする。
別のモデルも試したくなる。
量子化の精度を比べる。
推論サーバーの起動を待つ。
そして、Agent本体のコードに戻る頃には、最初に何をしたかったか少し忘れている。
困っていたのは、モデルのベンチスコアではありませんでした。
モデルを差し替えるたびに発生する、環境ごとの摩擦でした。
必要だったのは、もう少し賢いローカルモデルではなく、モデルを気軽に差し替えられる状態だった。
OpenRouterに寄せたら、モデルが引数になった
そこで、OpenRouter に寄せました。
今は、メインの生成は google/gemini-3-flash-preview、属性推論まわりは gemini-2.5-flash-lite を使っています。
どちらも、API越しです。
昔の自分なら、たぶんこう思っていました。
いや、そこは自分で持つでしょ。
API課金、こわくない？
データを外に出すの？
ローカルで再現できないと不安では？
でも、寄せてみて分かったことがあります。
モデルが、設定の一行になった。
OPENROUTER_MODEL=google/gemini-3-flash-preview
gemma3 から gemma4 へ上げるとき、ローカルではVRAMとロードとの相談でした。
OpenRouter では、文字列を変えるだけになった。
試したいモデルがあれば、引数を変える。
合わなければ、戻す。
VRAMを見なくていい。
ロードを待たなくていい。
量子化を選ばなくていい。
推論サーバーの起動に祈らなくていい。
そのぶん、Agent Runtimeの設計に戻れました。
モデルを差し替えても、設計が残るかを見たかった
OpenRouterに寄せて、もう一つ良かったことがあります。
モデルを差し替えるのが軽くなったので、モデルを変えたときに何が崩れるかを観測できるようになりました。
ローカルだと、差し替え自体が重い。
だから、そう何度も試せない。
でも、引数を変えるだけなら、何度でも試せます。
そして、試して分かったのは、モデルを変えても、責務の切り分けの方は残るということでした。
vertical判定を gemma から gemini に変えても、判定結果を後段でどう使うかの構造は変わらない。
メインの生成モデルを変えても、retrieval を evidence として扱う流れは変わらない。
崩れるのは、特定のモデルの癖に寄せて書いていた部分だけでした。
モデルを切り替えた瞬間に全部が崩れるなら、それはモデルに設計を預けすぎていたということです。
切り替えても残るものが、設計でした。
うお、また同じ話に戻ってきた。
ローカル推論を捨てたのではなく、モデルのお世話を捨てた
OpenRouterに寄せたのは、ローカル推論を否定したかったからではありません。
ローカルでモデルを動かす知識は、今でも要ります。
むしろ、何を外に逃がしているのかを分かっていないと、API依存はただのブラックボックスになります。
だから、理解は必要です。
でも、理解していることと、毎回VRAMと相談することは別でした。
必要だったのは、最強のローカル推論環境ではありませんでした。
モデルを気軽に差し替えて、設計の方に集中できる状態でした。
ローカル推論を捨てたのではなく、モデルのお世話をする時間を捨てた。
正確には、モデルのお世話をする時間を、責務を見る時間へ移した。
ローカルLLMおじさん、OpenRouterに敗北しました
gemma3。
gemma4。
Ollama。
vLLM。
量子化。
VRAMとの相談。
対戦ありがとうございました。
ローカルLLMおじさん、OpenRouterに敗北しました。
でもたぶんこれは、悪い敗北ではありません。
Agentを作っていたはずなのに、モデルのお世話をしていた。
そこから、ようやくモデルを引数として扱える環境へ移っただけです。
そして、モデルを引数にできると、面白いことに気づきます。
軽量モデルでも、思ったより崩れないことがある。
それは、モデルが賢かったからではなく、retrieval や責務の切り分けが、モデルの外側で足場になっていたからかもしれない。
RAG設計の話としてちゃんと書いたのが、この本です。
軽量LLMでも崩れなかった理由を、retrieval が reasoning の足場になっていた、という観点から書いています。
『検索結果を増やす前に見るRAG設計』
モデルを上げる前に、見る場所があったという話です。