2026年のローカルLLMについてのほとんどの議論は、チャット目的での使用についてだ — クラウドアシスタントへのプライバシー代替として。それは良いユースケースだ。 過去一年間の私のエンジニアリングを形作ってきたものではない。私のローカルLLMスタック — Ollama + llama.cpp + vLLM + Open WebUI + いくつかのサポートビット — は、 Postgresと並んで私の実際のエンジニアリングパイプラインに配線されており、そうでなければ APIクレジットのコストになる、またはコストなしで出荷されるが質が低くなる実際の タスクで本物の作業をしている。
スタックの形
アーキテクチャは聞こえるほど奇妙ではない：
- Ollamaは日常のドライバーだ。ホームラボのGPUで動き、OpenAI互換のAPIを 公開し、コーディングとスクリプティング中に行うすべてのローカルルーティングの インファレンスを提供する。モデルはオンデマンドで引かれ、いくつかはホットな 状態を保つ。インターフェースがシンプルなので、ほとんどのツール統合は「別の ベースURLを持つ別のOpenAIエンドポイント」として扱う。
- llama.cppはCPUクラスのフォールバックだ。GPUアクセスのないラップトップに いるとき、またはレイテンシが問題ない小さなモデルをスクリプトタスクで走らせたい とき、llama.cppが動かす。Ollamaとのオーバーラップは意図的だ — llama.cppは より低レベルで、量子化、コンテキスト長、サンプリングパラメータを精密にコントロール したいときに使う。
- vLLMはリアルスループットが欲しいもの向けのサービングレイヤーだ。バッチ インファレンスタスク、評価ラン、テスト用の合成データ生成 — vLLMはollamaが かかる時間の何分の一かでやる。それが最適化された用途だから。
- Open WebUIは人間向けのサーフェスだ。ローカルモデルとチャットしたいとき、 アウトプットを並べて比較したいとき、またはスクリプトには気軽すぎるマルチターンの 会話を走らせたいとき、そこに行く。
- LM StudioとJanは時々似たギャップを埋める。インストールしておくが 上記よりは少なく使う。
スタック全体はAPIの一ヶ月のスペンドより安価なGPUを持つホームラボマシンに座っている。 本物のインファレンスボリュームを走らせると経済的な交差点は速く来る。
実際に使っていること
ローカルスタックに永久スロットを獲得したタスクを、発火頻度の大まかな順で：
1. コミット前のレビューのプレパス
実質的なコミットの前に、ローカルモデルが構造化されたレビューパスを走らせる： 「diffを読んで、おかしく見えるものをリストし、重篤度でグレードしろ。」目標は レビューを置き換えることではない — PRを開く前に明らかなことを捕まえるために だ。人間のレビューが文体的なミスや不足しているエラーハンドリングに費やされないように。 これをローカルで走らせるのは無料だ。毎コミットのクラウドAPIで走らせると高くて遅い。
2. テスト用の合成データ
ユニットテストは頻繁に作り物のペイロードを必要とする：ユーザーレコード、製品カタログ、 ログライン、イベント形状。ローカルモデルはこれらを安価に、シードで決定論的に、 そしてデータをサードパーティサービスにラウンドトリップさせることなく生成する。 シードスクリプトは生成するフィクスチャの隣のテストツリーに保持する。
3. コード説明
不慣れなコードベース — 他の誰かのOSSプロジェクト、新しいフレームワーク — を 探索するとき、ローカルモデルが「このファイルが何をするか、平易な英語で」の 最初のパスを与えてくれる。権威的ではない。出発点の地図だ。それからコードを読んで、 LLMが間違っていた場所でメンタルモデルを修正する。組み合わせはどちらか単独より速い。
4. ドキュメントドラフト
README、ランブック、ポストモーテムを書くのは通常、構造化されたプロンプトと 最初のドラフト生成から始まり、それから大幅な人間の編集が続く。ローカルモデルが 秒で白紙問題を過ぎさせてくれる。編集がクレジットを稼ぐ場所だ。この記事も そうやって始まった。
5. リサーチの蒸留
たくさんのブックマークやリンクをモデルに与えて合成を求める。合成は直接行動するのに 十分なほど良いことは稀だ — でも三つのリンクを完全に読む価値があるかを知るのに 十分なほど良いことは多い。これは私が持った最も安価なリサーチ優先付けツールだ。
うまくいかないこと
ローカルモデルがクラウドフロンティアに負けるいくつかのカテゴリ、差はないに等しい：
- 長期的な推論タスク。 大きなフロンティアモデルは複雑なマルチステップ計画を 保持することが本当に得意だ。ローカルの70B以上のモデルはこれを近似できる。 ローカルの30B モデルは本当にはできない。
- 一貫した声で複数の言語での書き物。 ローカルモデルは翻訳で声を均一化する傾向が ある。フラッグシップのクラウドモデルはよりよく保持する。（これはこのサイトの 三言語バージョンには非常に重要だ。）
- 不慣れなフレームワークでのコード生成。 フロンティアモデルはロングテールを より多く見ている。古いスナップショットでトレーニングされたローカルモデルは、 例えばAstro 6の慣習でつまずくことがある。
正しい分け方：ローカルスタックを高ボリューム、低水平、コスト敏感なタスクに使え。 フロンティアAPIを深さと新規性に使え。 2026年のほとんどのエンジニアリングチームは どちらか一方を走らせている。両方を、意図的に、正しい分け方で走らせることが本物の アンロックだ。
コストの計算
私の使用量の大まかな一ヶ月：
- ローカルインファレンス： 数千のリクエスト。電力コスト：ごくわずか。GPU の減価償却：一年以上に償却すると意味はある。
- クラウドフロンティアAPI： 数十から数百のリクエスト、ほとんどが「本当に 難しい」もの。コスト：意味はあるが境界はある。
ローカルスタックなしでは、クラウドスペンドは10〜30倍高くなる。それがあると、 クラウドスペンドはそのスペンドが明らかに稼ぎを得ているものに向く。それが遡ると 明らかに見えるだろう二層パターンで、今ほとんどのチームに軽視されている。
Fulcrumsとのつながり
ローカルスタックの使用量のかなりの部分は、私自身のエージェントコントロールプレーン （Fulcrum）を通じて動く。速いフィードバックが必要なエージェントランは ローカルモデルにルーティングされ、深さが必要なものはクラウドにルーティングされる。 ルーティングポリシーはコントロールプレーンにあり、個別のツールにはない — つまり 「どのモデル？」という問いは一回、設定によって解決され、タスクごとに再学習しない。
2026年に自分のローカルスタックをセットアップするなら、最初に構築すべきものは インファレンスレイヤーではない — それは簡単だ、Ollamaが扱う。ルーティングレイヤーを 構築しろ：タスクごとに、どのモデルを呼ぶかを決めるもの。そこにエンジニアリングの 規律が宿る。そこが10倍のコスト節約が来る場所だ。まだ誰もそれについて話していない、 そして18ヶ月後に最も重要になるものだ。