← AIページの先頭へ

Inference Engines & Model Serving

LLM 推論フレームワークは、モデルのロード、計算の実行、および Token の生成を担当します。

Model Serving はこれに加えて、API リクエスト、スケジューリング、バッチ処理、同時実行、キャッシュ、パフォーマンス監視にも対応する必要があります。

1. 推論ツールの分類

分類主なツール代表的な用途
共通モデルフレームワークHugging Face Transformersモデルの読み込み、研究、開発
軽量推理 Runtimellama.cppローカルで低リソースの推論
ご当地モデル商品Ollama、LM Studioモデル管理、ローカル API、テスト
プロダクション Serving EnginevLLM、SGLang高い同時実行性の GPU 推論
ハードウェアに最適化された推論スタックTensorRT-LLMNVIDIA 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 との主な違いは次のとおりです。

コントラストOllamaLM 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-sizeTensor Parallel GPU個
--gpu-memory-utilizationGPU メモリ使用量バジェット関連の構成
--max-num-seqs同時シーケンススケジュールの上限
--max-num-batched-tokensToken スケジュール ステップの予算

実際に利用可能なパラメータの値は、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

コントラストvLLMSGLang
位置決め一般高性能 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

選定のポイント

実際に推論エンジンを選択する際の主なチェック項目は次のとおりです。

  1. Model Compatibility: このモデル アーキテクチャ、Tokenizer および Chat Template がサポートされているかどうか。
  2. Hardware Compatibility: CUDA、ROCm、Metal、GPU モデル。
  3. Quantization Support: 現在のモデルの量子化形式と最適化 Kernel をサポートするかどうか。
  4. Performance: TTFT、TPOT、Throughput およびビデオ メモリの使用量。
  5. 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 のコア知識のほとんどをカバーできます。


参考資料