LLM Servingとは？推論をAPI提供する仕組みと主要フレームワーク比較【2026年版】

LLM Serving（LLMサービング）とは、学習済みの大規模言語モデルを推論エンジンに載せ、APIとして継続的に提供する仕組みを指します。モデルを手元で1回動かすことと、多数のリクエストを低レイテンシ・高スループットでさばき続けることは別問題で、その差を埋めるのがサービング技術です。本記事では、推論との違い、GPUを使い切るPagedAttentionと連続バッチの仕組み、vLLM・SGLang・Ollamaなど主要フレームワークの比較、自前でサーバーを立てる際の必要スペックと起動コマンド、情報漏洩を防ぐ設計までを2026年時点の一次情報で整理します。

まとめ：LLM Servingの要点

• LLM Servingは「推論の実行」だけでなく、バッチ化・スケジューリング・API提供・スケーリング・監視まで含む本番運用の枠組み。
• 速さの核心はPagedAttention（KVキャッシュの断片化を無くす）と連続バッチ（GPUの遊びを無くす）の2技術。
• 本番GPUでの高スループットはvLLM・SGLang・TensorRT-LLM、ローカル検証はOllama・llama.cppが定番。Hugging FaceのTGIは2025年12月に保守モードへ移行した。
• 自前運用の主目的の一つは、機密データを外部APIに送らずに済ませる情報漏洩対策。GPUメモリはモデルサイズと量子化で見積もる。

以下、それぞれを具体的に見ていきます。

LLM Servingの定義と推論との違い

サービングは、学習済みモデルを「いつでも呼び出せる本番サービス」に変換する工程全体を指します。単語としては、モデル提供（serving）と推論（inference）が混同されがちですが、両者は包含関係にあり、実務では区別して設計する必要があります。LLMに限らない汎用の機械学習モデルまで含めた配備基盤の層はモデルサービングの構成とランタイム選定で整理しています。

推論（inference）とサービングの包含関係と役割分担

推論とは、入力に対してモデルが出力トークンを1つずつ生成する計算そのものです。一方サービングは、その推論を中心に、受付API（REST／gRPC）、リクエストのキューイングとバッチ化、GPUへの割り当て、認証・レート制限、ログと監視、モデルの更新・ロールバックまでを束ねたシステムを指します。推論単体をいくら速くしても、リクエストが直列に詰まればGPUは待ち時間だらけになるため、実サービスの速さはサービング層の設計で決まります。

モデルをそのまま動かすだけでは本番で破綻する理由

Transformerの推論では、生成済みトークンのKey/Value（KVキャッシュ）をGPUメモリに保持し続けます。文脈が長いほど、同時ユーザーが多いほどKVキャッシュは膨張し、素朴な実装ではGPUメモリが枯渇してリクエストが落ちます。加えて1リクエストずつ処理するとGPUの並列演算器が空くため、実効スループットは理論値を大きく下回ります。この「メモリの無駄」と「演算器の遊び」を同時に潰すために生まれたのが、次のPagedAttentionと連続バッチです。

LLM Servingを支える2つの核心技術

近年のサービングフレームワークが高速なのは、多くがこの2つの技術を実装しているからです。フレームワーク選定の前に、何が効いているのかを押さえておくと比較の軸がぶれません。

PagedAttention：KVキャッシュを16トークン単位の非連続ブロックで管理

PagedAttentionは、vLLMの論文（Kwonら、SOSP 2023）で提案されたKVキャッシュ管理方式です。OSの仮想メモリのページングに着想を得ており、KVキャッシュを固定長ブロック（vLLM既定は16トークン分・--block-sizeで変更可）に分割し、GPUメモリ上の空いている非連続な物理ブロックへ配置します。各シーケンスは論理ブロックから物理ブロックへの対応表を持ち、必要になった分だけブロックを確保します。これにより、従来方式で最大60〜80%に達したメモリ断片化がほぼ解消し、同じGPUでより多くの同時リクエストをさばけます。共通の接頭辞（システムプロンプト等）を持つリクエスト間では、同じ物理ブロックを参照して重複を避けられるのも利点です。

なお、PagedAttentionはKVキャッシュをGPUとCPUに分けて退避する技術ではありません。要点はあくまでGPUメモリ内での非連続ブロック配置による断片化の解消であり、CPUオフロードは別系統の最適化です。この誤解は設計判断を誤らせるため注意してください。

連続バッチ（continuous batching）：反復単位のリクエスト差し替え

連続バッチ（continuous batching、in-flight batchingとも）は、Orca（OSDI 2022）で示された反復単位スケジューリングに基づく手法です。従来のバッチ処理はバッチ内の全リクエストが生成し終わるまで次を待ちますが、連続バッチは1トークン生成するたびに、完了したリクエストを抜き、待機中のリクエストを空いた枠へ差し込みます。生成長がまちまちなLLMでは、短い応答が長い応答を待たされる無駄が消え、GPU使用率が大きく向上します（高負荷時に9割前後へ達する報告もあります）。vLLMやSGLangはこれを標準実装しており、チャットのような可変長・多同時接続の用途で特に効きます。

主要LLMサービングフレームワークの比較（2026年）

フレームワークは「本番GPUで高スループットを狙うもの」と「ローカルで手軽に動かすもの」に大別できます。2026年時点の代表格を、開発元・最新版・特徴で整理します。

数値の性能差は「どのGPUで」「どんなリクエスト分布か」で逆転します。以下、選定軸ごとに要点を補足します。

本番GPU向け：vLLM・SGLang・TensorRT-LLM

vLLMはV1エンジンが既定で、0.25系ではレガシーな旧実装（V0）が撤去されました。チャンク化プレフィルや自動プレフィックスキャッシュを備え、OpenAI互換APIで既存アプリからそのまま呼べるため、迷ったらまず選ぶ標準です。SGLangはRadixAttentionで接頭辞を共有し、リクエストが共通プロンプトを持つ場合にH100で約29%（16,200対12,500トークン/秒）の優位を示しますが、プロンプトが毎回ユニークなら差はほぼ出ません。TensorRT-LLMはモデルをNVIDIA GPU向けにコンパイルして最速のスループットとレイテンシを出しますが、モデルやGPUによって十数分から数十分のコンパイル工程を要し、モデルとGPUが固定される制約があります。頻繁にモデルを差し替える環境では、起動の速いvLLMの方が運用は楽です。

ローカル・検証向け：Ollama・llama.cpp

Ollamaは0.32.0時点で、ollama run1つでモデルの取得から対話までを済ませられる手軽さが特徴です。GPUが無いPCでもCPUで動き、既定ポート11434でOpenAI互換エンドポイントを提供します。llama.cppはセマンティックバージョンを使わずビルドタグ（記事時点でb9985）で配布され、llama-serverがポート8080でOpenAI互換APIを立てます。C++実装でApple Siliconのネイティブ実行が速く、GGUF形式の量子化モデルをエッジや組み込みで動かす用途に向きます。どちらもPoCや社内検証には十分ですが、大規模同時接続の本番はvLLM系に譲るのが現実的です。より手軽なローカル実行はMicrosoftのFoundry Localとは？使い方・対応モデル・SDK実装を解説【Microsoft製ローカルAI】も選択肢になります。

Text Generation Inference（TGI）は2025年12月に保守モードへ

Hugging FaceのTGIは長らく本番サービングの定番でしたが、2025年12月に保守モード（maintenance mode）へ移行しました。Hugging Face自身が新規の最適化はvLLM・SGLang・llama.cpp・MLXへ向かうと表明しており、これから構築するならTGIを第一候補にする理由は薄くなっています。既存のTGI資産（V3の挙動を含む）を活かしたい場合を除き、新規はvLLMかSGLangを起点にするのが無難です。

自前でLLMサーバーを立てる：必要スペックと起動手順

「ローカルLLMサーバーのスペックが知りたい」「とりあえず立てて試したい」という要望に応えるため、GPUメモリの見積もりと、vLLM／Ollamaでの最短の起動手順を示します。

モデルサイズ別に見るGPUメモリの目安

重みのメモリはおおよそ「パラメータ数×精度のバイト数」で決まります。fp16なら1パラメータ2バイト、int4量子化なら約0.5バイトです。これに加え、同時に処理するトークン数に比例してKVキャッシュ用のメモリが必要になる点を見落とさないでください。下表は重みのみの概算で、実運用では2〜4割程度の余裕を見ます（正確な必要量は各モデルのモデルカードで確認してください）。

目安として、8Bクラスのfp16なら24GBのGPU1枚で動き、70Bを1枚に載せるにはint4量子化かモデル並列（複数GPUへの分散）が要ります。GPUが無い場合はint4のGGUFをllama.cppやOllamaでCPU実行できますが、生成速度は大きく落ちます。

vLLMでのOpenAI互換APIサーバー起動手順

vLLMはインストール後、vllm serveにモデル名を渡すだけで、既定ポート8000にOpenAI互換のエンドポイントが立ちます。既存のOpenAI用クライアントのベースURLを差し替えるだけで移行できます。

pip install vllm

# OpenAI互換サーバーを起動（既定ポート8000）
vllm serve meta-llama/Llama-3.1-8B-Instruct --max-model-len 8192

# 別ターミナルから推論リクエスト
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"meta-llama/Llama-3.1-8B-Instruct","messages":[{"role":"user","content":"こんにちは"}]}'

--max-model-lenで最大コンテキスト長を絞ると、KVキャッシュの上限が下がりメモリに余裕が生まれます。同時接続を増やすときはこことGPUメモリのバランスを調整します。

Ollamaでのローカルサーバー構築手順

Ollamaはインストール後、ollama runでモデルを取得してすぐ対話でき、バックグラウンドではポート11434のAPIサーバーが動きます。OpenAI互換エンドポイントも用意されているため、アプリからはvLLMとほぼ同じ形で呼べます。

# モデルを取得して対話（初回はダウンロードが走る）
ollama run llama3.1

# APIサーバーを明示起動（既定ポート11434）
ollama serve

# OpenAI互換エンドポイントへリクエスト
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.1","messages":[{"role":"user","content":"こんにちは"}]}'

Web検索やRAGと組み合わせる場合の具体的な設定は、Ollama Web Searchとは？使い方・APIの設定・料金とPython実装をわかりやすく解説やOllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法が参考になります。

自社運用で情報漏洩を防ぐセキュリティ設計

「LLMで情報漏洩が怖い」という懸念は、そのままセルフホスティングの主要な動機になります。外部APIに機密データを送らない構成と、入出力の防御をセットで設計します。

セルフホスティングによるデータの外部非送信

自前サーバーでLLMをサービングする最大の利点は、プロンプトや社内文書を外部の生成AIサービスに送信せずに済むことです。医療・金融など秘匿性の高いデータを扱う場合は、オンプレミスやプライベートクラウドにvLLMやllama.cppを置き、ネットワークを閉域にすることで、学習データへの流用や第三者送信のリスクを断てます。個人開発でローカルLLMを使う流れも広がっており、コーディング用途ではOllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法のように、手元完結でエージェントを動かす構成が実用段階にあります。

プロンプトインジェクションと入出力フィルタリング

自社運用でも、ユーザー入力を通じてモデルの挙動を乗っ取るプロンプトインジェクションは残ります。入力側では、外部から取り込む文字列をシステム指示と分離し、想定外の命令文を検知・無害化します。出力側では、氏名・住所などのPII（個人識別情報）を検出してマスキングし、応答ログを匿名化して保存します。APIキーやOAuthでアクセスを制御し、リクエスト元・入力・出力・エラーコードを監査ログに残せば、インシデント時の追跡とガバナンス報告に使えます。GDPRや個人情報保護法への準拠が必要な領域では、これらを技術と運用規程の両面で担保します。

よくある質問

LLM ServingとLLM推論（inference）の違いは何ですか？

推論は入力から出力トークンを生成する計算そのもの、サービングはその推論を中心にAPI・バッチ化・スケジューリング・スケーリング・監視までを束ねた本番システムです。推論はサービングの一部であり、実サービスの速さや安定性はサービング層の設計で決まります。

vLLMとOllamaはどちらを使うべきですか？

多数の同時リクエストを本番GPUでさばくならvLLM、GPUの無いPCでの検証や個人開発ならOllamaが向きます。どちらもOpenAI互換APIを備えるため、まずOllamaで試作し、本番でvLLMへ移す運用も現実的です。

PagedAttentionとは何ですか？

KVキャッシュを16トークン単位の固定長ブロックに分け、GPUメモリの空き領域へ非連続に配置する管理方式です（vLLM論文・SOSP 2023）。メモリ断片化を解消して同時処理数を増やし、共通接頭辞のブロック共有も可能にします。GPUとCPUに分割退避する技術ではありません。

ローカルLLMサーバーに必要なGPUスペックの目安は？

8Bクラスのfp16なら24GBのGPU1枚が目安で、int4量子化なら6GB前後まで下がります。70Bはint4でも約40GBを要し、fp16では複数GPUへの分散が前提です。実際は同時トークン数に応じたKVキャッシュ分の余裕を2〜4割見込みます。

Hugging FaceのTGIはもう使わない方がよいですか？

TGIは2025年12月に保守モードへ移行し、Hugging Face自身が新規はvLLM・SGLang等を推奨しています。既存のTGI資産を維持する場合を除き、これから構築するならvLLMかSGLangを起点にするのが無難です。

関連記事

• Ollama Web Searchとは？使い方・APIの設定・料金とPython実装をわかりやすく解説
• OllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法
• OllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法
• Foundry Localとは？使い方・対応モデル・SDK実装を解説【Microsoft製ローカルAI】
• DiffusionGemmaとは｜4倍速い拡散型LLMの仕組み・スペックとローカルでの動かし方