モデルサービング（モデルサービング）
学習済みのMLモデルやLLMをAPIエンドポイントとして公開し、リアルタイム推論リクエストを処理するインフラストラクチャ。バッチ推論とは異なり、低レイテンシ（数十ms〜数秒）で逐次リクエストに応答する。vLLM、TGI、Triton Inference Server、BentoML等のサービングフレームワークが主流。
モデルサービングとは
モデルサービング（Model Serving）は、学習済みの機械学習モデルをプロダクション環境でリアルタイムに推論可能な状態で提供するインフラストラクチャである。学習フェーズで作成されたモデルをHTTP/gRPCエンドポイントとして公開し、アプリケーションからのリクエストに対してリアルタイムで推論結果を返す。
LLMの台頭により、モデルサービングの要件は大きく変化した。従来の分類・回帰モデル（数MB〜数百MB）のサービングと、LLM（数GB〜数百GB）のサービングでは、GPU メモリ管理・トークン生成の逐次処理・KVキャッシュの最適化など、根本的に異なるアーキテクチャが求められる。
サービングフレームワークの比較
| フレームワーク | 開発元 | 対象 | 特徴 | ライセンス |
|---|---|---|---|---|
| vLLM | UC Berkeley | LLM | PagedAttention、最速のLLMサービング | Apache 2.0 |
| TGI (Text Generation Inference) | Hugging Face | LLM | HFモデルハブ統合、Flash Attention | Apache 2.0 |
| Triton Inference Server | NVIDIA | 汎用ML | マルチフレームワーク、バッチ最適化 | BSD-3 |
| TensorRT-LLM | NVIDIA | LLM | NVIDIA GPU最適化、INT4/FP8量子化 | Apache 2.0 |
| BentoML | BentoML Inc | 汎用ML+LLM | Pythonic API、マルチモデル | Apache 2.0 |
| SGLang | UC Berkeley | LLM | RadixAttention、構造化出力最適化 | Apache 2.0 |
| Ollama | Ollama Inc | LLM (ローカル) | ワンコマンドデプロイ、GGUF対応 | MIT |
| LiteLLM | BerriAI | LLMプロキシ | 100+プロバイダ統一API | MIT |
LLMサービングの主要技術
PagedAttention（vLLM）: GPUメモリ上のKVキャッシュを仮想メモリのページングのように管理する技術。従来のサービングではKVキャッシュに連続メモリ領域を確保する必要があったが、PagedAttentionにより断片化したメモリを効率的に利用できる。これによりバッチサイズが2〜4倍に増加し、スループットが大幅に向上する。
Continuous Batching: リクエストごとにバッチを組むのではなく、生成が完了したリクエストのスロットに新しいリクエストを即座に挿入する技術。従来のStatic Batchingでは最も長い生成が終わるまで全リクエストが待機するが、Continuous Batchingでは各リクエストが独立して完了する。
Speculative Decoding: 小型のドラフトモデルで複数トークンを先行生成し、大型モデルで一括検証する技術。検証に通ったトークンはそのまま採用し、不一致のトークンのみ大型モデルで再生成する。レイテンシを30〜50%削減できるが、ドラフトモデルの品質に依存する。
量子化サービング: FP16/BF16の重みをINT8/INT4/FP8に量子化してサービングすることで、GPUメモリ使用量を50〜75%削減する。GPTQ、AWQ、GGUF等の量子化形式がvLLM/TGIで直接サポートされている。品質劣化はperplexityで1〜3%程度。
デプロイメントパターン
| パターン | 構成 | レイテンシ | コスト | 用途 |
|---|---|---|---|---|
| シングルGPU | 1×A100/H100 | 低い | 中 | 7B〜70Bモデル |
| テンソル並列 | 2〜8×GPU | 低い | 高い | 70B〜405Bモデル |
| パイプライン並列 | 2〜4×GPU | やや高い | 中〜高 | メモリ不足時 |
| マルチレプリカ | N×シングルGPU | 低い | 高い | 高スループット |
| サーバーレス | GPU on-demand | 高い（コールドスタート） | 変動 | 低トラフィック |
コスト最適化
LLMサービングのコストはGPU時間が支配的である。A100 80GBのクラウドインスタンス（AWS p4d.24xlarge）は$32.77/hで、70Bモデルを常時サービングすると月額約$23,600となる。
コスト削減の手法:
- 量子化: INT4量子化で同じモデルを半分のGPUで実行（コスト50%削減）
- バッチ最適化: Continuous Batchingでスループットを2〜4倍に向上（1リクエストあたりのコスト削減）
- スポットインスタンス: AWS Spot / GCP Preemptible で60〜80%割引（中断リスクあり）
- モデル選択: 70Bモデルの代わりに8Bモデル+プロンプト最適化で同等品質を達成
よくある質問
Q1: vLLMとTGIのどちらを選ぶべきですか？
スループット重視ならvLLM、Hugging Faceエコシステムとの統合重視ならTGIが適している。vLLMはPagedAttentionによるメモリ効率が業界最高水準で、大量の同時リクエスト処理に優れる。TGIはHugging Faceモデルハブからワンコマンドでデプロイでき、Flash Attention 2やGPTQ/AWQ量子化にも対応している。2026年時点ではvLLMがデファクトスタンダードになりつつある。
Q2: オンプレミスとクラウドのどちらでサービングすべきですか？
月間GPU使用時間が720時間（常時稼働）を超える場合、オンプレミスGPU（A100 80GB約$15,000〜$20,000）の方がクラウドより安くなる。ただし、トラフィックが変動する場合やGPU管理の人的コストを考慮するとクラウド（AWS SageMaker、GCP Vertex AI等）の方がTCOで有利なケースも多い。ハイブリッド構成（ベースロードをオンプレ、ピークをクラウド）が最もコスト効率が高い。
Q3: ローカルLLMサービングにOllamaとvLLMのどちらが適していますか？
Ollamaは個人開発者やチーム内利用に最適で、ollama run llama3.1のワンコマンドでサービングを開始できる。GGUF量子化モデルに対応し、CPU推論もサポート。一方vLLMはプロダクション向けで、高スループット・Continuous Batching・OpenAI互換APIを提供する。開発・検証にはOllama、本番環境にはvLLMという使い分けが一般的。