LLM推論エンジン（エルエルエムスイロンエンジン）
LLM推論エンジン（LLM Inference Engine）は、大規模言語モデルの推論処理を高速かつ効率的に実行するための専用ソフトウェア基盤。vLLM・TensorRT-LLM・SGLang・llama.cpp・Text Generation Inference（TGI）などが代表格で、KVキャッシュ管理・連続バッチング・量子化・テンソル並列といった最適化技術を組み合わせ、GPUメモリ効率とスループットを最大化する。
LLM推論エンジンとは
LLM推論エンジンは、数十億〜数千億パラメータの大規模言語モデル（LLM）を本番環境で効率的に動作させるための専用ソフトウェアスタックである。素のPyTorchやHugging Face Transformersで推論を行うと、KVキャッシュのメモリ断片化・逐次デコードの低GPU利用率・リクエスト間のアイドル時間といった問題が発生し、スループットは最適値の10〜30%程度にとどまる。推論エンジンはこれらのボトルネックを体系的に解消し、同一ハードウェアで3〜10倍の処理効率を実現する。
2024〜2026年の主要推論エンジンは以下の通りである。
| エンジン | 開発元 | 主要技術 | 対応GPU | ライセンス | 特徴 |
|---|---|---|---|---|---|
| vLLM | UC Berkeley / vLLM Project | PagedAttention, Continuous Batching | NVIDIA, AMD, TPU | Apache 2.0 | OpenAI互換API、最大級のコミュニティ |
| TensorRT-LLM | NVIDIA | FP8/INT4量子化, Flight Recorder | NVIDIA専用 | Apache 2.0 | NVIDIA GPU最大性能、Triton連携 |
| SGLang | UC Berkeley | RadixAttention, Constrained Decoding | NVIDIA, AMD | Apache 2.0 | 構造化出力に強い、高速プレフィックスキャッシュ |
| llama.cpp | Georgi Gerganov | GGUF量子化, CPU/Metal最適化 | CPU, Apple Metal, CUDA | MIT | ローカル推論の標準、低リソース対応 |
| TGI | Hugging Face | Flash-Decoding, Token Streaming | NVIDIA, AMD, Intel Gaudi | Apache 2.0 | HF Hub統合、プロダクション実績豊富 |
| MLC LLM | CMU / OctoAI | TVM コンパイル最適化 | NVIDIA, AMD, Metal, WebGPU | Apache 2.0 | マルチプラットフォーム対応 |
推論エンジンのアーキテクチャ
典型的なLLM推論エンジンは以下の階層構造で構成される。
リクエスト管理層
HTTPサーバー（FastAPI/gRPC）がクライアントリクエストを受け付け、トークナイザでプロンプトをトークン化する。OpenAI互換API（/v1/chat/completions、/v1/completions）を提供するエンジンが主流で、既存アプリケーションからの移行を容易にしている。vLLMとSGLangはOpenAI互換、TensorRT-LLMはTriton Inference Serverを経由してOpenAI互換エンドポイントを提供する。
スケジューラ層
複数リクエストのバッチ構成・優先度制御・プリエンプション（中断と再開）を管理する。Continuous Batching（連続バッチング）により、あるリクエストの生成が完了した時点で即座に新リクエストをバッチに投入し、GPUアイドル時間を最小化する。vLLMのスケジューラは公平性ベースのFCFS（First Come First Served）を採用し、SGLangはRadixAttentionによるプレフィックス共有を考慮したスケジューリングを行う。
KVキャッシュ管理層
Transformerの各層で生成されるKey-Valueペアを効率的に格納・再利用する。PagedAttention（vLLM発祥）は仮想メモリのページング機構を模倣し、KVキャッシュを固定サイズブロックに分割して非連続メモリ領域に配置する。これにより従来の連続メモリ確保方式と比較してメモリ使用効率が60〜80%向上する。
カーネル実行層
FlashAttention-2/3、FlashDecoding、FusedRoPE、量子化カーネル（FP8/INT8/INT4）といった最適化CUDAカーネルを用いて、実際のテンソル演算を実行する。TensorRT-LLMはNVIDIA独自のTensorRTコンパイラでモデル全体を最適化グラフに変換し、カーネルフュージョン・メモリプランニングを自動化する。
性能ベンチマーク比較
2025年後半〜2026年のベンチマーク結果に基づく性能比較（Llama 3.1 70B、A100 80GB×1、FP16、入力512トークン・出力256トークン）:
| エンジン | スループット (tokens/s) | レイテンシ P50 (ms) | レイテンシ P99 (ms) | GPUメモリ使用率 |
|---|---|---|---|---|
| vLLM 0.8.x | 3,200 | 45 | 120 | 92% |
| TensorRT-LLM 0.16.x | 4,100 | 32 | 85 | 88% |
| SGLang 0.5.x | 3,500 | 38 | 105 | 90% |
| TGI 3.x | 2,800 | 52 | 145 | 91% |
| llama.cpp (CUDA) | 1,200 | 110 | 280 | 78% |
TensorRT-LLMはNVIDIA GPU上で最高性能を示すが、モデルのビルド（コンパイル）に数十分〜数時間を要する。vLLMとSGLangはビルド不要で即座に起動でき、開発・実験サイクルが速い。llama.cppはCPU推論にも対応し、GPUなし環境でのLLM利用を可能にする。
デプロイメントパターン
単一GPU構成（7B〜13Bモデル）
単一のNVIDIA RTX 4090（24GB VRAM）またはA100 40GBで運用可能。vLLMの場合、python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3.1-8B-Instruct --dtype float16のような1コマンドで起動でき、最も手軽なデプロイ形態。量子化（AWQ/GPTQ/GGUF）を適用すれば、RTX 3060 12GBクラスでも7Bモデルが動作する。
テンソル並列構成（70B〜405Bモデル）
70B以上のモデルは単一GPUのVRAMに収まらないため、複数GPUにモデルを分割する。テンソル並列（TP: Tensor Parallelism）は各Attention層・FFN層の重み行列をGPU間で分割し、NVLink/PCIe経由でAll-Reduceを行う。vLLMでは--tensor-parallel-size 4、TensorRT-LLMでは--tp_size 4で指定する。A100 80GB×4構成でLlama 3.1 70Bを FP16運用するのが標準的。
パイプライン並列構成
パイプライン並列（PP: Pipeline Parallelism）はTransformerの層を複数GPUに分割する。TPと比較してGPU間通信量が少ないが、パイプラインバブル（GPUアイドル時間）が発生する。405Bクラスの超大規模モデルではTPとPPを組み合わせた2D並列（例: TP=4, PP=2の8GPU構成）が一般的。
Kubernetes / コンテナオーケストレーション
KServe、Ray Serve、Triton Management ServiceなどのMLサービング基盤と組み合わせて、オートスケーリング・ローリングアップデート・A/Bテスト・カナリアデプロイを実現する。vLLMはRay上で分散推論を行うRayLLMとの統合が成熟しており、大規模本番環境での採用が多い。
選定ガイドライン
用途・制約に応じた推論エンジンの選定基準を示す。
| 用途 | 推奨エンジン | 理由 |
|---|---|---|
| 汎用本番API | vLLM | コミュニティ最大、OpenAI互換、安定性高い |
| NVIDIA最大性能 | TensorRT-LLM | FP8量子化+カーネル最適化で最速 |
| 構造化出力（JSON等） | SGLang | RadixAttentionによるプレフィックスキャッシュが構造化出力に有効 |
| ローカル・エッジ | llama.cpp | CPU/Metal対応、低リソース、GGUF量子化 |
| HF Hub統合 | TGI | モデルダウンロード〜デプロイが最もシームレス |
| マルチプラットフォーム | MLC LLM | WebGPU/Metal/CUDA/Vulkan対応 |
選定時の主要チェックポイント
- 対応GPU: NVIDIA専用か、AMD/Intel/Apple対応か
- 量子化サポート: AWQ/GPTQ/FP8/GGUF等の対応状況
- OpenAI互換API: 既存アプリケーションからの移行容易性
- コミュニティ規模: GitHub Stars、Issue対応速度、ドキュメント充実度
- ビルド要否: TensorRT-LLMはビルドが必要、vLLM/SGLangは不要
- ストリーミング対応: SSE/WebSocketでのトークンストリーミング
よくある質問（FAQ）
Q1: vLLMとTensorRT-LLMのどちらを使うべきですか？
開発速度と柔軟性を重視するならvLLM、NVIDIA GPU上の絶対性能を追求するならTensorRT-LLMが適している。vLLMはモデルの切り替えが即座に行え、AWQ/GPTQ/FP8など多様な量子化フォーマットをサポートする。TensorRT-LLMはモデルのビルド（TensorRTエンジンへのコンパイル）に時間を要するが、ビルド済みエンジンの推論速度はvLLMを20〜30%上回ることが多い。プロダクションで固定モデルを長期運用するならTensorRT-LLM、頻繁にモデルを入れ替える実験環境ならvLLMが良い。
Q2: llama.cppはGPUなしでも実用的ですか？
実用的である。Q4_K_M量子化のLlama 3.1 8Bモデルであれば、Apple M2 Pro（16GB RAM）で約15 tokens/sの生成速度が得られる。対話的な用途（チャット、コード補完）には十分な速度で、M3 Max/M4 Proではさらに高速化する。ただし70B以上のモデルをCPUのみで動かすのは遅延が大きく非実用的であるため、32GB以上のRAMとQ3_K_M以下の量子化が必要。
Q3: 推論エンジンを自前で構築する必要がありますか？
ほとんどのケースでは不要である。vLLM・TensorRT-LLM・SGLangは本番品質のエンジンで、Fortune 500企業からスタートアップまで幅広く採用されている。自前構築が正当化されるのは、極めて特殊なハードウェア（独自ASIC、FPGAアクセラレータ）への対応、または既存エンジンでは実現できない独自のスケジューリングアルゴリズムが必要な場合に限られる。まずvLLMで始め、性能要件に応じてTensorRT-LLMやSGLangを検討するのが推奨アプローチ。
Q4: 複数モデルを1台のGPUで同時にサービングできますか？
可能だが制約がある。vLLMは--max-model-lenでモデルごとのKVキャッシュサイズを制限し、複数プロセスで異なるモデルを同一GPU上にロードできる。ただしVRAMを共有するため、各モデルに割り当てられるKVキャッシュが減り、同時処理可能なリクエスト数が低下する。A100 80GBに7Bモデル2つ程度なら実用的だが、それ以上はGPU追加が推奨される。LoRAアダプタを動的にロード・アンロードするLoRA Servingを使えば、ベースモデル1つで複数タスクに対応でき、メモリ効率が大幅に向上する。