6月21日、Vetted Consumerが「Serving a Local LLM as an API: From Ollama's Endpoint to vLLM Throughput (and When to Rent Instead)」と題した記事を公開した。ローカルLLMをAPIとして公開する方法をOllamaからvLLMまで体系的に解説し、用途別のツール選択指針を体系的に示している。
チャット画面でモデルを動かすのは簡単だ。問題は「別のソフトウェアからそのモデルを呼び出したい」と思った瞬間に始まる。コードエディタ、スクリプト、自作アプリ——それらがモデルを使うには、HTTPエンドポイントとしてサービングする必要がある。ここでOllama、vLLM、TGI、SGLangといった名前が乱立し、多くのエンジニアが迷走する。
サービングとは何か
サービングとは、モデルをHTTPエンドポイントの背後に置き、他のプログラムからリクエストを受け付けられる状態にすることだ。エンドポイントは事実上の業界標準となったOpenAI API互換フォーマットを話す。これが意味するのは、OpenAIに接続できるツール——コーディングアシスタント、自動化スクリプト、チャットUI、各種ライブラリ——は接続先をlocalhostに変えるだけで、ローカルモデルに対してそのまま動作するということだ。無料かつプライベートに。
OllamaとvLLMは「どちらが優れているか」ではなく「何人が使うか」で選ぶ
サービングエンジンはシンプルさと高スループットのスペクトラム上に並ぶ。
- Ollama / llama.cpp server（シンプル側）：コマンド1つでOpenAI互換エンドポイントが立ち上がる。CPU・Apple Silicon含むほぼ全環境で動作。個人利用、自分のエディタ、ホームオートメーション、サイドプロジェクト向け。
- vLLM / TGI / SGLang（高スループット側）：多数の同時リクエストを効率的に処理するためのエンジン。セットアップは重く、専用GPU・フルVRAM常駐が前提になる。
どちらが「優れている」かではなく、リクエスト量に応じて使い分けるものだ。
この差を生む核心：連続バッチング（Continuous Batching）
なぜvLLMは高負荷下で劇的に速く、1ユーザーにはオーバースペックなのか。答えは連続バッチングにある。
GPUはトークンを1ユーザー分だけ生成しているとき、メモリ帯域に律速されてコンピュートが大半アイドル状態になる。バッチングはそのアイドルコンピュートを活用し、複数リクエストを同時処理することでメモリからの1回の重み読み込みを全リクエストで共有する。
さらにその発展形が連続バッチングだ——あるリクエストが終了した瞬間に新しいリクエストをバッチへ投入し続ける、反復レベルのスケジューリング方式。これはOrca（Yu et al., OSDI 2022）が提唱し、現在は主要なサービングエンジンすべてに採用されている。vLLMはこれにPagedAttention（Kwon et al., 2023）——KVキャッシュのメモリ管理を効率化する仕組み——を組み合わせ、ナイーブなサービングに比べて最大24倍のスループットを報告している。
実用的な結論：ユーザーが自分1人なら、バッチングには何もバッチングするものがないためOllamaのシンプルさが勝つ。本当の同時トラフィックが発生した瞬間、vLLMのような連続バッチングエンジンがアイドルコンピュートを数倍のスループットに変える。
サービングのメモリ計算：見落としがちな罠
ハードウェアを選定する際に引っかかりやすいポイントがある。モデルの重みは一度ロードされれば全ユーザーで共有される。しかしKVキャッシュはリクエストごとに独立して存在する。
必要メモリ ≈ モデル重み + (KVキャッシュ × 同時リクエスト数)
長いコンテキストを持つユーザーが10人いると、KVキャッシュだけでモデル本体より多くのメモリを消費しうる。「自分1人では快適に動いていたモデルが10人に提供したら落ちた」という現象は、重みが増えたからではなくKVキャッシュが10倍になったからだ。PagedAttentionはまさにこの問題——最悪ケースを事前確保するのではなく多数のキャッシュを効率的にパッキングする——を解決するために設計された。
スループットvs.レイテンシ：どちらを最適化するか
「速い」という言葉は2つの異なる目標を隠している。
- レイテンシ：1リクエストが完了するまでの時間。1ユーザーが体感するもの。
- スループット：全リクエストを合わせたトークン/秒。高負荷サーバーが気にするもの。
バッチサイズを大きくするとスループットは上がるが、個別ユーザーのレイテンシは上がりうる。個人利用ならレイテンシを最適化すべきだし、サービスとして提供するならスループットを最優先にする。この違いを理解せずに「最適化」すると、個人用ボックスをサーバー指標で調整するミスを犯す。
判断のチートシート
記事の核心となる選択基準を表にまとめている。「何人が同時に使うか」と「モデルをどれだけの頻度で使うか」という2軸で判断が決まる点が要点だ。
| 状況 | 選択肢 |
|---|---|
| 自分だけ + ローカルツール | Ollama / llama.cpp server |
| 同時ユーザーがいるアプリ | vLLM / TGI / SGLang |
| 複数モデル / ローカル+クラウド混在 | ゲートウェイ/ルーター（LiteLLM等） |
| 巨大モデル、たまに使う | クラウドGPUを時間借り |
| 24時間365日の安定負荷 | 購入、ハードウェアを償却 |
この表が示す通り、ツール選択はモデルの「性能」ではなく「使われ方」で決まる。
公開時の注意：うっかり外部に晒すな
OpenAI互換エンドポイントは立ち上げが簡単な分、うっかり公開してしまうリスクも高い。デフォルトではlocalhostにバインドされる。しかし0.0.0.0にバインドしたりポートフォワードした瞬間、認証なしのAIエンドポイントがネットワークに晒される。インターネットから到達可能な状態なら、誰でもあなたのGPUを自分の電気代で使える。リモートアクセスが必要なら、APIキー・リバースプロキシ・VPNなどを必ず組み合わせること。
いつクラウドGPUを借りるか
自分のハードウェアで提供することに合理的な上限がある。以下のケースではクラウドGPU（RunPod、Vast.ai等）の時間借りが経済的に正しい選択だ。
- 200B+のモデルを時々使いたい場合：使う時間分だけ借りる方が、アイドル状態のハードウェアを所有するより安い。
- バースト性の高いトラフィックがある場合：負荷に応じてスケールアップ・ダウンできるクラウドの強みが活きる。
- 週1回の大規模バッチ処理：サーバーを所有する理由がない。
判断の基本原則：安定したベースライン負荷には購入、スパイクと大型モデルの一時利用にはレンタル。8Bモデルで24時間稼働の個人アシスタントなら買う。120Bモデルを週末10時間だけ使うなら借りる。
詳細はServing a Local LLM as an API: From Ollama's Endpoint to vLLM Throughput (and When to Rent Instead)を参照していただきたい。
