ローカル LLM 入門：Ollama / vLLM の使いどころ

「自社の手元で大規模言語モデル（LLM）を動かす」ローカルLLMは、機密データを外に出さず、利用量が増えてもコストを読みやすく、応答の遅延も自分でコントロールできるのが魅力です。本記事は、開発者がすぐ触れるOllamaと、本番の高負荷に耐える推論サーバーvLLMを軸に、「動かす」から一歩進んだ運用の勘所を、図とともに初めての人にも分かるよう整理します。

FIG.1　クラウドはデータが社外へ出る／ローカルはデータも推論も自社環境の中で完結する

ローカル運用には、向く場面とそうでない場面があります。社内文書を扱う検索拡張生成（RAG）のようにデータを外に出したくない用途、利用が増えてコストを定額の自社設備に寄せたい用途では強みが出ます。一方、最新・最高品質のモデルをすぐ使いたいだけなら、クラウドAPIのほうが手間もリスクも小さいことが多い。両者は対立ではなく使い分けです。

01OllamaとvLLM、役割の違い

最初に二つの道具の立ち位置を分けておくと、後の判断が楽になります。ざっくり言えば、Ollamaは「手元で素早く試す」、vLLMは「本番で大勢にさばく」ための道具です。

Ollama：ローカル開発とプロトタイピングの最短ルート

Ollamaはモデルの取得・起動・実行をひとつのコマンド群で扱えるツールです。macOS / Windows / Linux で導入しやすく、NVIDIA（CUDA）・AMD（ROCm）・Apple Silicon（Metal）のいずれでも動きます。GPUがあれば7B〜8Bクラスの応答が体感で数秒に収まり、「まずローカルで試す」段階に最適です。

vLLM：本番運用や高負荷に強い推論基盤

vLLMは推論最適化（後述のPagedAttentionと継続的バッチング）により、同じGPUでも同時リクエストをさばくスループットを大きく稼げる推論サーバーです。長時間の連続稼働、多数の同時アクセス、複数アプリからの共通利用といった場面で本領を発揮します。

迷ったら、まずOllamaで選定と検証、要件が固まったらvLLMで本番。

かつては「OpenAI互換APIが使えるのはvLLMだけ」という整理がされがちでしたが、現在はどちらもOpenAI互換APIを提供します（Ollamaは http://localhost:11434/v1、vLLMも同様のエンドポイント）。そのため、既存アプリのコードは接続先URLとモデル名を差し替えるだけで、OllamaからvLLMへ段階的に移行できます。違いは「互換APIの有無」ではなく、後述する同時処理性能にあります。

02事前準備：ハードウェアとモデル選定

GPU / VRAM の目安

必要なリソースは「モデルサイズ」と「量子化（精度を少し落として軽量化する手法）」で決まります。あくまで目安ですが、次のイメージで見当をつけられます。

モデル規模	VRAMの目安と主な用途
7B〜8B	量子化で6〜10GB程度から現実的。開発・チャット・PoC向け
13B〜14B	12〜24GBが安心。品質と速度のバランス型
30B以上	48GB級の単体、または複数GPU。本格的な推論基盤

CPUだけでも動かせますが、日常的に使う社内ツールならGPUのほうがストレスが少ないです。なお、ここで挙げた数値は構成や量子化方式で変わるため、最終的には自分の環境で実測して確かめてください。

モデルは「用途別」に割り切る

万能の一つを探すより、用途で割り切るほうが運用は安定します。チャット・要約には汎用の指示追従が得意なモデル、コード補助にはコードに強いモデル、社内QAでは（モデルより）RAGの検索設計が品質を左右します。日本語品質を重視するなら、日本語に強い派生モデルを、自分で用意した10〜30問程度の小さな評価セットで比べておくと後で迷いません。

03Ollamaで確実に回す

基本の流れ

Ollamaは「モデルを取得（pull）して実行（run）する」流れが直感的です。ローカルでAPIサーバーとしても立ち上がるので、業務ツールやフロントエンドからすぐ呼び出せます。

運用で効く：Modelfileで品質を揃える

OllamaはModelfileでモデルの初期設定をまとめられます。チームで使うなら、これを使って「誰が使っても同じ品質」に寄せるのがコツです。代表的な設定は次の通り。

• SYSTEM（システムプロンプト）：社内規約（機密の取り扱い、出力フォーマット）を毎回の会話に固定する
• temperature：出力のブレを抑えたいなら低め（既定は 0.8。社内用途では 0.2〜0.5 を出発点に）
• num_ctx：扱える文脈の長さ（トークン数。既定は控えめなので、長文を扱うなら明示的に上げる）
• num_predict：出力の最大トークン数。無限に喋らせず、待ち時間とコストを抑える

「チームで」使うときの注意

1人の開発端末で動かすうちは快適ですが、複数人で使い始めると課題が出ます。端末ごとのGPU有無やVRAM差で体験が変わり、pullした時期でモデルの挙動が微妙にずれ、誰が何を投げたか（特に機密）がブラックボックスになりがちです。

さらに本質的な制約として、Ollamaは多人数同時利用のための推論サーバーではありません。同時に2〜3人を超えると性能が伸びにくく、同じハードでも、混雑時はOllamaが合計でおよそ40トークン/秒どまりなのに対し、vLLMは約800トークン/秒に達するという比較もあります。この段階に来たら、次のvLLMへ寄せるのが自然です。

04vLLMで本番の推論サーバーを作る

なぜ速いのか：PagedAttentionと継続的バッチング

vLLMの速さの核心は二つの工夫です。ひとつはPagedAttention。会話の文脈を覚えておくメモリ（KVキャッシュ）を16トークン単位の「ページ」に分けて管理し、同じ前置き（プロンプト）を持つ複数リクエストでページを共有することで、長い文脈でのVRAM消費を抑えます。もうひとつが継続的バッチング。先に終わったリクエストの席へ次のリクエストを随時詰め込み、GPUを遊ばせません。この二つで、1台のGPUを上手に使い切れます。

FIG.2　Ollamaは少人数なら快適だが同時負荷で頭打ち／vLLMは継続的バッチングで同時リクエストを束ねる

OpenAI互換APIで提供する

vLLMはOpenAI互換のエンドポイントを立てられます。既存アプリがOpenAI SDK前提でも、base_urlとモデル名の差し替えが中心で移行コストを抑えられます。社内の共通LLM基盤として横展開しやすく、前段にゲートウェイ（認証・レート制限）を置く構成とも相性が良いです。

本番運用で見る主な設定

運用では「速度・安定性・品質」の落とし所を、いくつかの起動オプションで調整します。代表的なものは次の通りです。

• --max-model-len（コンテキスト長）：長くすると便利だがKVキャッシュでメモリを食う。用途に必要な長さに絞る
• --gpu-memory-utilization：GPUメモリをどこまで使うか（0〜1）。上げるほどKVキャッシュに回せるが、上げ過ぎは不安定の元。0.9前後から調整する例が多い
• --tensor-parallel-size：モデルを複数GPUに分割する数。基本は使うGPU枚数に合わせる。1枚に載らない大きなモデルを動かす鍵
• 量子化（FP8 / AWQ など）：速度・VRAM・品質のトレードオフ。AWQで品質をほぼ保ちつつスループットを伸ばせる例もある。まず小さく検証する

複数GPUに分割しても、性能は枚数ぶん素直には伸びません。GPU間の接続が高速なNVLink環境では1枚増やすごとに約1.8倍、一般的なPCIe接続のコンシューマGPUでは約1.4倍にとどまる、という実測傾向が知られています。「2台にすれば2倍」と単純計算しないのが安全です。

05運用設計の勘所：本当に困るところ

「動かす」より「動かし続ける」ほうが難しい——ここがセルフホスティングの本番です。特に効く4点を押さえます。

1) 監視（Observability）

LLMは「なぜ遅いか」を追うのが難しく、CPUやメモリだけ見ても原因に届きません。GPU使用率・VRAM・キュー待ち・トークン生成速度（tokens/sec）まで見て初めて把握できます。最低限の推奨メトリクスは、P50/P95レイテンシ、同時リクエスト数、tokens/sec、GPU使用率、VRAM使用量。可視化はPrometheus + Grafanaが定番です。

2) ログ：機密とデバッグの両立

プロンプトのログはデバッグに役立つ一方、社内文書がそのまま残るのは危険です。原文を保存しない（メタ情報のみ・ハッシュ化）、保存するならマスキング（メール・電話・顧客ID）、そしてアクセス権と保管期間（例：一定日数で自動削除）を明確にします。どこまで残すかは、扱うデータの機密度に応じて決めてください。

3) 安全策：ガードレールはモデル任せにしない

ローカルモデルでも、危険な指示や社外秘の出力リスクは消えません。モデルの賢さに頼り切らず、アプリ側にも対策を置きます。

4) RAGと組み合わせるなら「検索が8割」

社内データ活用では、モデルを強くしようと沼にはまりがちです。実務では回答品質の多くが検索（Retriever）と文書整備で決まります。ベクトルDB（Qdrant / Milvus / Weaviate など）と埋め込みモデルは日本語性能と速度のバランスで選び、チャンク（文書の断片）は小さすぎると文脈が欠け、大きすぎるとノイズが増えます。「どのPDF／社内Wikiのどこを引いたか」を必ず示すようにすると、現場の納得感が一段上がります。

06よくある構成例：小さく始めて育てる

いきなり全社基盤を目指さず、規模に応じて段階的に。三つの典型を挙げます。

段階	構成と用途
A 個人〜小チーム	推論はOllama（各自PC）、UIは簡易ツールやCLI。モデル比較・プロンプト検証・少人数の業務支援に。
B 部署内共有	推論はvLLM（社内GPU1台）、前段にゲートウェイ（認証・レート制限）、監視はPrometheus + Grafana。社内チャットやRAGを複数ツールから共通利用。
C 全社基盤	vLLMを複数GPU/複数ノードで、オートスケールも検討。SSO連携と監査ログ、入出力フィルタやDLP連携。業務システムへの統合・製品組み込みに。

07まとめ：自由だからこそ「型」をつくる

Ollamaは試行錯誤のスピードを上げ、vLLMは本番での安定運用を支えます。今はどちらもOpenAI互換APIを持つので、Ollamaで選定・検証してからvLLMへ寄せる移行が現実的です。ローカルLLMは自由度が高いぶん、放っておくと環境差・品質差が出やすい。モデル・設定・評価・監視をセットの「型」にしていくのが、長く使い続けるいちばんの近道です。まずは用途を一つに絞り、小さく動かすところから始めましょう。