LLM 推論フレームワークは、モデルのロード、計算の実行、および Token の生成を担当します。
Model Serving はこれに加えて、API リクエスト、スケジューリング、バッチ処理、同時実行、キャッシュ、パフォーマンス監視にも対応する必要があります。
1. 推論ツールの分類
| 分類 | 主なツール | 代表的な用途 |
|---|---|---|
| 共通モデルフレームワーク | Hugging Face Transformers | モデルの読み込み、研究、開発 |
| 軽量推理 Runtime | llama.cpp | ローカルで低リソースの推論 |
| ご当地モデル商品 | Ollama、LM Studio | モデル管理、ローカル API、テスト |
| プロダクション Serving Engine | vLLM、SGLang | 高い同時実行性の GPU 推論 |
| ハードウェアに最適化された推論スタック | TensorRT-LLM | NVIDIA GPU 徹底的な最適化 |
| Serving Engine メンテナンス中 | TGI | 既存システムのメンテナンス |
これらのツールには重複する機能があり、厳密には相互排他的ではありません。
たとえば、llama.cpp には HTTP Server と Continuous Batching も提供されます。 vLLM および SGLang は、シングルユーザーのローカル テストにも使用できます。
2.Inference RuntimeとServing Engine
Inference Runtime
主に以下を担当します。
Model Weights
↓
Load Model
↓
Execute GPU / CPU Kernels
↓
Prefill / Decode
↓
Generated Tokens
Serving Engine
モデル実行機能に次の機能を追加します。
HTTP / OpenAI-compatible API
↓
Request Queue
↓
Scheduler
↓
Continuous Batching
↓
Prefill / Decode
↓
KV Cache Manager
↓
GPU Kernels
↓
CUDA / ROCm
↓
GPU
最新の Serving Engine は通常、次のサポートも必要とします。
- Prefix Caching。
- Quantization。
- Streaming。
- Structured Outputs。
- LoRA Adapters。
- Multi-GPU。
- Metrics / Observability。
3. Hugging Face Transformers
Transformers は一般的なモデル ライブラリおよび実行フレームワークであり、高同時実行性 Serving 向けに特別に設計されたものではありません。
主に提供されるもの:
- Model Architectureの実装。
- Pretrained Weightsがロードされました。
- Tokenizer。
- Generation。
- Training / Fine-tuning 対応。
基本的な例:
from transformers import AutoTokenizer, AutoModelForCausalLM
model_id = "your-model-id"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id,
device_map="auto",
)
inputs = tokenizer("Hello", return_tensors="pt").to(model.device)
outputs = model.generate(
**inputs,
max_new_tokens=100,
)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
以下に適しています:
- モデルのアーキテクチャを理解します。
- モデルをデバッグします。
- 生成的な行動を研究します。
- 微調整して実験してください。
- パフォーマンスと品質のベースラインを確立します。
ただし、多数の同時リクエストが必要な場合は、通常、特殊化された Serving Engine が考慮されます。
4. llama.cpp
llama.cpp は、主に C/C++ によって実装された効率的な推論プロジェクトです。
これは、ローカルの消費者向けハードウェアおよび定量モデルに特に適しています。
サポート:
- CPU Inference。
- CUDA、Metal、その他のハードウェア バックエンド。
- GGUF。
- Quantization。
- GPU Offloading。
- HTTP Server。
- Continuous Batching。
- Speculative Decoding。
- Embedding / Reranking。
- Structured Outputs。
公式 llama-server はすでに OpenAI-compatible API、マルチリクエスト推論、Continuous Batching を提供しています。
基本的なコマンド
llama-cli -m model.gguf
HTTP Server を開始します。
llama-server \
-m model.gguf \
--host 127.0.0.1 \
--port 8080
以下に適しています:
Apple Silicon
CPU-only
Consumer GPU
Limited VRAM
Local Quantized Models
Edge Devices
5. Ollama
Ollama は、ローカル モデルのダウンロード、管理、実行、および API サービスを使いやすいツールにカプセル化します。
ollama run qwen3
主な能力:
- モデルをダウンロードして管理します。
- ローカルモデルを実行します。
- モデルのパラメータとテンプレートを管理します。
- Modelfile 経由でカスタム モデル構成を作成します。
- HTTP APIを提供してください。
- 一般的な量子化モデルをサポートします。
通常、ローカル API のデフォルト アドレスは次のとおりです。
http://localhost:11434
Ollama は、ネイティブ API インターフェイスと OpenAI-compatible インターフェイスの両方を提供します。
ローカル モデルのデプロイメントを学習する場合、多くの場合、基盤となる推論エンジンを直接操作するよりも Ollama の方が簡単です。
ただし、基礎となる KV Cache 管理、Kernel、および複雑な GPU スケジューリング戦略を研究する必要がある場合は、vLLM、SGLang、または llama.cpp 自体をさらに研究する必要があります。
6. LM Studio
LM Studio は、ローカル モデルの使用および開発のためのツールです。
主な能力:
- GUI モデルを検索してダウンロードします。
- ローカル モデルをロードして実行します。
- モデルパラメータの調整。
- ローカルチャット。
- HTTP API Server。
- CLIツール。
llama.cpp Runtime はサポートされており、MLX モデルは Apple Silicon でサポートされています。
Ollama との主な違いは次のとおりです。
| コントラスト | Ollama | LM Studio |
|---|---|---|
| 主な経験 | CLI / API 優先度 | GUI優先度 |
| モデル管理 | サポート | サポート |
| HTTP API | サポート | サポート |
| ローカルモデルのテスト | サポート | サポート |
| 典型的なユーザー | 開発者、自動化プログラム | ローカルモデルのエクスペリエンスとデバッグ |
両者の位置付けは近く、通常はどちらかをマスターすれば十分です。
7. vLLM
vLLM は、高スループット、低遅延の LLM Serving 用のオープンソース推論エンジンです。
主な最適化:
- PagedAttention / Paged KV Cache。
- Continuous Batching。
- Chunked Prefill。
- Automatic Prefix Caching。
- Speculative Decoding。
- Quantization。
- Multi-GPU / Distributed Inference。
- LoRA Serving。
- OpenAI-compatible API。
vLLM の主な機能は、効率的なスケジューリングと KV Cache 管理を通じて GPU の使用率と全体的な Serving Throughput を改善することです。
モデルサービスを開始する
vllm serve your-model-id \
--host 127.0.0.1 \
--port 8000
モデル、GPU 環境、および依存関係を正しく構成する必要があります。
共通パラメータ:
| パラメータ | 目的 |
|---|---|
--model / モデル位置パラメータ | モデルを指定してください |
--dtype | 計算精度 |
--quantization | 量子化方法の指定 |
--max-model-len | コンテキストの最大長 |
--tensor-parallel-size | Tensor Parallel GPU個 |
--gpu-memory-utilization | GPU メモリ使用量バジェット関連の構成 |
--max-num-seqs | 同時シーケンススケジュールの上限 |
--max-num-batched-tokens | Token スケジュール ステップの予算 |
実際に利用可能なパラメータの値は、vLLM のバージョン、モデル、ハードウェアによって異なります。
代表的な用途
- 高い同時実行性 LLM API。
- RAGサービス。
- Agent バックエンド。
- マルチユーザーチャットシステム。
- GPU 推論パフォーマンス テスト。
8. SGLang
SGLangも高性能なLLM Serving Frameworkです。
以下を含む vLLM と機能的に重複する部分が大きくあります。
- Continuous Batching。
- Paged Attention。
- Quantization。
- Tensor / Pipeline / Expert Parallelism。
- Speculative Decoding。
- Structured Outputs。
- Multi-LoRA。
- Prefill-Decode Disaggregation。
SGLang の主な機能には、RadixAttention、Prefix Caching、および高性能 Runtime が含まれます。
RadixAttention / Radix Cache
共有 Prompt Prefix は Radix Tree などの構造で編成され、対応する KV Cache が再利用されます。
たとえば:
Request A:
System Prompt + User Question A
Request B:
System Prompt + User Question B
Shared Prefix
↓
Cached KV Blocks
↓
┌─────────┴─────────┐
Request A Request B
多数の共有 System Prompt、Few-shot Examples、または重複したプレフィックスを含むリクエストの場合、大幅な利益が得られる可能性があります。
ただし、vLLM は Prefix Caching もサポートしているため、これは SGLang に固有の機能ではありません。
vLLM および SGLang
| コントラスト | vLLM | SGLang |
|---|---|---|
| 位置決め | 一般高性能 Serving | 一般高性能 Serving |
| Continuous Batching | サポート | サポート |
| Prefix Caching | サポート | サポート、RadixAttention は重要な機能です |
| Structured Outputs | サポート | サポート |
| Multi-GPU | サポート | サポート |
| Agent Workloads | サポート | サポート |
| パフォーマンス | シナリオによる | シナリオによる |
一般に、1 つのエンジンが常に高速であると想定することはできません。
Benchmark は、同じモデル、ハードウェア、入力と出力の長さ、および同時実行条件に対して実行する必要があります。
9. TensorRT-LLM
TensorRT-LLM は、LLM 推論用に最適化された NVIDIA の技術スタックです。
NVIDIA GPU のハードウェア機能を最大限に活用することに重点が置かれています。
関連技術:
- Tensor Cores。
- CUDA Optimized Kernels。
- FP8 / FP4 Quantization。
- Kernel Fusion。
- In-flight Batching。
- Paged KV Cache。
- Chunked Prefill。
- Speculative Decoding。
- Multi-GPU / Multi-node Parallelism。
NVIDIA の公式ドキュメントには上記の主な最適化機能がリストされていますが、低精度フォーマットのサポートも GPU アーキテクチャに依存します。たとえば、FP4 の高性能サポートは、Blackwell などのハードウェアに関連しています。
以下に適しています:
- NVIDIA GPU 本番環境。
- 高性能推論の最適化。
- 特定の GPU アーキテクチャ向けの詳細なチューニング。
これは、NVIDIA ハードウェアおよびソフトウェア エコシステムに重点を置いており、すべてのハードウェア プラットフォームにわたる普遍的なソリューションではありません。
10. TGI:Text Generation Inference
TGI は Hugging Face が開発した LLM Serving Engine です。
重要なオープンソース モデルの実稼働展開ソリューションとして、以下をサポートします。
- Continuous Batching。
- Streaming。
- Quantization。
- Paged Attention。
- Prometheus Metrics。
- OpenAI-compatible API。
しかし、TGI は Maintenance Mode に入りました。
Hugging Face 現在、新しい展開では vLLM や SGLang などの代替を優先することが推奨されています。
したがって、TGIの歴史的な位置づけと基本的な仕組みを理解すれば十分です。 Serving を学習および作成するための最初の選択肢として使用することはお勧めできません。
11. OpenAI-compatible API
最新の推論エンジンは、多くの場合、OpenAI API スタイルと互換性のある HTTP インターフェイスを提供します。
たとえば:
Application
↓
OpenAI-compatible HTTP API
↓
Inference Server
↓
Model Runtime
↓
GPU
共通 Endpoint:
POST /v1/chat/completions
POST /v1/completions
GET /v1/models
Python の例
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="local-key",
)
response = client.chat.completions.create(
model="your-model-id",
messages=[
{"role": "user", "content": "Hello"}
],
)
print(response.choices[0].message.content)
base_url を変更すると、アプリケーションは互換性のあるさまざまな推論エンジンに接続できます。
ただし、OpenAI-compatible はすべての機能が完全に一致していることを意味するものではありません。ツール呼び出し、構造化出力、Reasoning、Streaming などには互換性の違いがまだある可能性があります。
さらに、外部に公開される推論サービスは、認証、電流制限、およびアクセス制御を正しく設定する必要があります。ローカルの例の API Key は、実稼働認証が構成されていることを意味するものではありません。
12. Prefill-Decode Disaggregation
Prefill と Decode には、異なるリソース要件があります。
Prefill
↓
Compute-intensive
Decode
↓
Memory-bandwidth-intensive
Prefill-Decode Disaggregation は、異なる Worker または GPU リソースで 2 つのフェーズを実行します。
Incoming Request
↓
Prefill Worker
↓
Transfer KV Cache
↓
Decode Worker
↓
Output Tokens
主な目的:
- Prefill と Decode を個別に最適化します。
- DecodeへのロングPromptの干渉を軽減します。
- テールITL/TPOTを改良しました。
- 異なるステージに異なるコンピューティング リソースを割り当てます。
費用:
- システムの複雑さが増します。
- KV Cacheの効率的な伝送が必要です。
- 追加の通信とスケジュールのオーバーヘッドが発生します。
vLLM と SGLang はどちらもすでに関連機能を提供していますが、具体的な完成度や展開方法はバージョンによって異なります。
これは主に大規模な運用展開に使用され、単一の GPU 学習段階では集中的な調査は必要ありません。
13. 推論エンジンの選び方
| 使用シナリオ | 最初に知っておくことをお勧めします |
|---|---|
| Transformer の学習とモデルの読み込み | Transformers |
| MacBook ローカル量子化モデル | Ollama / llama.cpp |
| GUI モデルをダウンロードしてテストする | LM Studio |
| 単一の GPU は Serving を生成します | vLLM / SGLang |
| 高い同時実行性、複数の GPU 推論 | vLLM / SGLang |
| NVIDIA 徹底的なパフォーマンスの最適化 | TensorRT-LLM |
| 既存の HF TGI サービスを維持する | TGI |
選定のポイント
実際に推論エンジンを選択する際の主なチェック項目は次のとおりです。
- Model Compatibility: このモデル アーキテクチャ、Tokenizer および Chat Template がサポートされているかどうか。
- Hardware Compatibility: CUDA、ROCm、Metal、GPU モデル。
- Quantization Support: 現在のモデルの量子化形式と最適化 Kernel をサポートするかどうか。
- Performance: TTFT、TPOT、Throughput およびビデオ メモリの使用量。
- Serving Features: Streaming、Tool Calling、Structured Outputs、LoRA、Metricsなど。
エンジン名だけでは機能サポートを判断できません。特定のバージョン、モデル、展開バックエンドを確認する必要があります。
概要
Model Framework
└── Transformers
Local Inference
├── llama.cpp
├── Ollama
└── LM Studio
Production GPU Serving
├── vLLM
├── SGLang
└── TensorRT-LLM
Legacy / Maintenance
└── TGI
最も重要な違い:
- Transformers: モデルの読み込みと一般的な実行フレームワーク。
- llama.cpp: 軽量でクロスハードウェアの効率的な推論 Runtime。
- Ollama/LM Studio: ローカル モデルの実行と管理を簡素化します。
- vLLM / SGLang: 高スループットと高同時実行性を重視します Serving。
- TensorRT-LLM: NVIDIA GPU 向けに徹底的に最適化されています。
- TGI: Hugging Face Serving Engine がメンテナンス モードに入ります。
推論展開学習の場合、llama.cpp/Ollama と vLLM の 2 つのルートをマスターすると、ローカル量子化推論と GPU プロダクション Serving のコア知識のほとんどをカバーできます。