はじめに
LLM（大規模言語モデル）を本番環境で運用する際、推論エンジンの選択は重要なポイントの一つかと思います。2025年後半から2026年にかけて、Red HatがOpenShift AI上でllm-dをGA（一般提供）したことで、エンタープライズ向けの選択肢が広がってきているようです。
本記事では、公式ドキュメントや各種ベンチマーク記事を参考に、以下の3つの推論エンジン/プラットフォームを比較してみます。
- Ollama: ローカル開発向けのシンプルなLLM実行ツール
- vLLM: 高スループット・高効率な推論エンジン
- llm-d (OpenShift AI): Kubernetes上での分散推論プラットフォーム
用語解説
本記事で登場する主な技術用語を簡単に説明します。
| 用語 | 説明 |
|---|---|
| PagedAttention | GPUメモリを「ページ」単位で動的に割り当てる技術。従来の静的割り当てと比べ、メモリ使用効率が大幅に向上 |
| Continuous Batching | 新しいリクエストを待たずに、完了したリクエストの空きスロットに動的に追加する手法。スループットが向上 |
| Tensor Parallel | 1つのモデルを複数GPUに「横方向」に分割して並列処理。大きなモデルを複数GPUで動かす際に使用 |
| Pipeline Parallel | モデルのレイヤーを複数GPUに「縦方向」に分割。Tensor Parallelと組み合わせて使うことも |
| Prefill | ユーザーのプロンプト（入力テキスト）を処理してKVキャッシュを生成する段階。計算量が多い |
| Decode | Prefill後、トークンを1つずつ生成していく段階。メモリ帯域がボトルネックになりやすい |
| KVキャッシュ | Attention計算で使うKey/Valueを保存しておくキャッシュ。再計算を避けて高速化 |
| NIXL | NVIDIA主導の高速データ転送ライブラリ。GPU間・ノード間のKVキャッシュ転送を効率化 |
| Kubernetes Inference Gateway | Kubernetes Gateway APIをベースにした推論専用のルーティング機構 |
各技術の概要
Ollama
Ollamaは、ローカルでLLMを簡単に実行するためのツールです。単一のバイナリで動作し、モデル管理機能も統合されており、最小限の設定で使い始められます。
特徴:
- シングルバイナリで簡単セットアップ
- 量子化モデルへの簡単アクセス
- OpenWebUIなどとの連携が容易
- 個人開発者・プロトタイピング向け
vLLM
vLLMは、高スループットとメモリ効率を追求した推論エンジンとして知られています。PagedAttentionによる動的メモリ管理とContinuous Batchingにより、高い並行処理性能を実現しているとのことです。
特徴:
- PagedAttentionによる動的メモリ割り当て
- Continuous Batchingで高スループット
- Tensor Parallel / Pipeline Parallel対応
- プロダクション環境での高負荷処理向け
llm-d (OpenShift AI)
llm-dは、Red HatがOpenShift AI 3.0でGAとしてリリースした、Kubernetes-nativeな分散推論プラットフォームです。vLLMをベースに、エンタープライズ向けの拡張を加えています。
"There is no llm-d without vLLM. They are designed to be teammates."
— Red Hat公式ブログ
なぜOpenShift AIが注目されているのか:
すでにOpenShiftを運用している企業にとって、llm-dは魅力的な選択肢になりそうです。
- 既存のKubernetes運用ノウハウがそのまま活かせる — 新しいインフラを学び直す必要がない
- Red Hatのエンタープライズサポート — 本番環境での安心感
- マルチクラウド・ハイブリッドクラウド対応 — オンプレミスでもクラウドでも同じ運用
- Google Cloud、NVIDIA、IBM等との共同開発 — 業界標準を目指したオープンソースプロジェクト
特徴:
- vLLMを分散サービングに拡張
- Prefill/Decode段階の分離（Disaggregated Serving）
- KVキャッシュ考慮のインテリジェントルーティング
- Kubernetesとの深い統合
デプロイ要件（公式ドキュメントより）:
- Kubernetes 1.29以上
- vLLM（推論エンジン）
- NIXL（データ転送ライブラリ）
- Kubernetes Inference Gateway
主要コンポーネント:
| コンポーネント | 役割 |
|---|---|
| インテリジェント推論スケジューラ | Gateway APIベースのLB、プリフィックスキャッシュ対応ルーティング |
| Prefill Server | プロンプト処理専用インスタンス |
| Decode Server | トークン生成専用インスタンス |
| 階層型KVキャッシュ | CPU → ローカルSSD → リモートストレージの多層オフロード |
| ワークロードオートスケーラー | SLO対応のコスト最適化、異種ハードウェア対応 |
アーキテクチャ比較
メモリ管理
| 項目 | Ollama | vLLM | llm-d |
|---|---|---|---|
| メモリ割り当て | 静的（モデルロード時） | 動的（PagedAttention） | 動的 + マルチティアKVキャッシュ |
| マルチGPU対応 | レイヤーオフロード | Tensor Parallel | 分散Tensor Parallel |
| マルチノード | 非対応 | Ray経由で対応 | Kubernetes-native |
バッチ処理
Ollama: リクエスト単位の処理（最大4並列がデフォルト）
vLLM: Continuous Batching（動的にリクエストをバッチ化）
llm-d: Disaggregated Serving（Prefill/Decodeを独立スケール）
llm-dの分散アーキテクチャ
llm-dの特徴的なポイントとして、Prefill（プロンプト処理）とDecode（トークン生成）を分離できる点が挙げられています。
Schedulerの主な機能:
- プリフィックスキャッシュ対応ルーティング
- 利用率ベース負荷分散
- マルチテナント対応
Disaggregated Servingのメリット（公式ドキュメントより）:
- 独立スケーリング: PrefillとDecodeを別々にスケールできる
- レイテンシ分離: 一方のボトルネックが他方に影響しにくい
- リソース最適化: 各フェーズに最適なハードウェアを割り当てられる可能性
- 即時効果: デフォルト設定でも約25%のパフォーマンス向上が報告されている
階層型KVキャッシュ
llm-dの特徴的な機能の一つが、マルチティアKVキャッシュオフロードです。
この階層化により、ベンチマークではKVキャッシュヒット率が約90%（vLLM単体比45%向上）を達成したとの報告があり、応答時間の改善につながる可能性があります。
パフォーマンス比較
注意: ベンチマーク結果は、ハードウェア構成、モデルサイズ、量子化方式、同時接続数などの条件により大きく変動します。以下の数値は参考値としてご覧ください。
シングルユーザー性能
RTX 4090でLlama 3.1 8Bを実行した場合（複数のベンチマークより）：
| エンジン | トークン/秒 | 備考 |
|---|---|---|
| Ollama (Q4_K_M) | ~62 tok/s | 量子化モデル |
| vLLM (FP16) | ~71 tok/s | フル精度 |
| vLLM (AWQ) | ~68 tok/s | 量子化 |
シングルユーザーでは両者の差は約13%程度と比較的小さいようです。Ollamaはllama.cppカーネル最適化により、この条件では競争力のある性能を発揮しているとの評価があります。
高並行時の性能差
各種ベンチマークによると、高並行処理では性能差が顕著になるようです。
Red Hat Developerベンチマーク（出典）：
| 指標 | vLLM | Ollama | 差 |
|---|---|---|---|
| ピークスループット | 793 TPS | 41 TPS | 約19倍 |
| P99レイテンシ（ピーク時） | 80ms | 673ms | 約8倍高速 |
10並列ユーザー時（RTX 4090、Llama 3.1 8B）：
| 指標 | vLLM | Ollama |
|---|---|---|
| 総スループット | ~485 tok/s | ~150 tok/s |
| TTFT | ~145ms | ~3,200ms |
Ollamaはデフォルトで最大4並列リクエストに制限されており、高負荷時にキューイングが発生するとのことです。一方、vLLMのContinuous Batchingは新規リクエストを動的にバッチに取り込むため、スケーラビリティに優れているとされています。
llm-d vs vLLM（2026年1月ベンチマーク）
| 指標 | llm-d | vLLM | 改善率 |
|---|---|---|---|
| P50 TTFT | 92ms | 123ms | 25%高速 |
| P95 TTFT | 272ms | 745ms | 64%高速 |
| P99 TTFT | 674ms | 841ms | 20%高速 |
| KVキャッシュヒット率 | ~90% | ~62% | 45%向上 |
| キャッシュ高速化倍率 | 3.84× | 1.79× | 2.1倍改善 |
このベンチマークでは、llm-dの複数レプリカ間でのプリフィックス認識ルーティングにより、キャッシュ再利用効率が向上しているようです。特にマルチターン会話での応答性の改善が期待できそうです。
ユースケース別選択ガイド
公式ドキュメントやベンチマーク結果を踏まえると、以下のような使い分けが考えられそうです。
Ollamaが向いていそうなケース
- ローカルでのプロトタイピング・実験
- 個人開発者の学習用途
- 少人数（1-3人）での利用
- 量子化モデルを手軽に試したい場合
- セットアップの簡単さを優先したい場合
vLLMが向いていそうなケース
- 本番環境での高スループット処理
- 5並列以上のリクエスト処理
- 推論パラメータの細かい制御が必要な場合
- 単一ノード内でのマルチGPU活用
- コンテナ化されたデプロイ
llm-d (OpenShift AI)が向いていそうなケース
- エンタープライズ規模の本番運用
- Kubernetesベースのインフラがある場合
- マルチノード分散推論が必要な場合
- DeepSeekなどMoE（Mixture of Experts）モデルの運用
- 予測可能なSLO/SLA達成が求められる場合
- Red Hatのサポートが必要な場合
選択フローチャート
実践的ユースケースでトレンドが有りそうなもの：規模別の選択についての考察
具体的なユースケースでの選択として実現可能か、について考えてみます。実際の運用では環境や要件によって異なる結果になる可能性がある点、ご了承ください。
ユースケース1: Voice Agent（音声エージェント）
音声エージェントは、レイテンシ要件が厳しいユースケースの一つです。人間の会話は200-300ms程度の応答ウィンドウで動作しており、これを超えると会話の流れが途切れる感覚が生じると言われています。
Voice Agentの一般的なレイテンシ目標:
| 指標 | 目標値 | 備考 |
|---|---|---|
| Voice-to-Voice応答時間 | < 1,500ms | 自然な会話に必要とされる |
| LLM TTFT | < 300ms | 推論が全体の大部分を占める |
| End-to-End目標 | < 800ms | プロダクション品質の目安 |
同時ユーザー数による選択の目安:
| 同時ユーザー | 候補となるエンジン | 構成例 |
|---|---|---|
| 少数（〜5人程度） | Ollama | ローカルGPU、7B-8Bモデル |
| 中規模（5-20人程度） | vLLM | L4/A10 GPU |
| 大規模（20-100人程度） | vLLM + 複数GPU | H100、Tensor Parallel |
| 非常に大規模（100人以上） | llm-d | Disaggregated Serving、マルチノード |
llm-dが効果を発揮しそうなケース:
大規模な同時接続を捌く必要がある場合、llm-dのDisaggregated Servingが効果的かもしれません。Prefill（プロンプト処理）とDecode（トークン生成）を分離することで、以下のようなメリットが期待できそうです：
- Prefill専用Pod: 新規会話の開始を高速処理
- Decode専用Pod: 継続中の会話のトークン生成に集中
- 独立スケーリング: 負荷に応じて各フェーズを個別にスケール
ユースケース2: RAG（Retrieval-Augmented Generation）
RAGシステムでは、検索結果を含む長いプロンプトを処理する必要があります。社内ドキュメント検索やFAQボットなど、企業での活用が増えているユースケースです。
RAGの処理フロー:
RAGでllm-dが有効と考えられる理由:
RAGではプリフィックス共有が発生しやすい点がポイントです。
- 同じシステムプロンプト
- 同じ検索ドキュメント（よく参照される社内資料など）
- 類似のコンテキスト
これらが複数のリクエストで共有される場合、llm-dのプリフィックスキャッシュ対応ルーティングにより、同じキャッシュを持つPodにリクエストが振り分けられるため、効率が上がる可能性があります。
RAGでの選択の目安:
| 利用規模 | 候補となるエンジン | ポイント |
|---|---|---|
| 少人数・検証 | Ollama | 手軽に始められる |
| チーム利用 | vLLM | スループットが向上 |
| 全社展開・マルチターン多 | llm-d | キャッシュ効率が向上しそう |
ユースケース比較まとめ
まとめ
各種資料を調査した結果を簡単にまとめると、以下のような傾向がありそうです。
| 観点 | Ollama | vLLM | llm-d |
|---|---|---|---|
| 難易度 | 簡単 | 中程度 | 複雑 |
| スループット | 低め | 高め | 最も高い傾向 |
| スケーラビリティ | 限定的 | 中程度 | 高い |
| 運用コスト | 低め | 中程度 | 高め |
| 対象ユーザー | 個人 | チーム | エンタープライズ |
ざっくりとした選択の目安：
- 手軽に試したい → Ollamaが良さそう
- 本番で高性能が必要 → vLLMが候補になりそう
- Kubernetes上でエンタープライズ運用 → llm-d (OpenShift AI)を検討する価値がありそう
公式ドキュメントによると、llm-dはvLLMを置き換えるものではなく、補完する関係とのことです。vLLMというエンジンに、llm-dというオーケストレーターを組み合わせることで、Kubernetes上での分散推論が実現される設計になっています。
llm-dチームのvLLMへの貢献
llm-dチームは、上流のvLLMプロジェクトに対して以下の機能を貢献・メンテナンスしています：
- Disaggregated Serving（分離サービング）
- KV Connectorインターフェース
- フロンティアOSS MoEモデル（DeepSeek等）のサポート
- プロダクション向けの可観測性・回復性機能
最新リリース情報（v0.4）
2026年初頭のv0.4リリースでは以下の改善が含まれています：
- DeepSeek V3.1のH200 GPUでの出力トークンレイテンシ40%削減
- Intel XPU、Google TPUでのDisaggregation対応
- vLLMネイティブCPUメモリティアリングによるプリフィックスキャッシュオフロード
- ワークロードバリアントオートスケーラーのプレビュー
OpenShift AIを検討するなら
もし「LLMを本番運用したいけど、どこから始めればいいかわからない」という状況であれば、OpenShift AIは検討に値するプラットフォームかもしれません。
OpenShift AIが向いていそうな組織:
- すでにOpenShift/Kubernetesを運用している
- LLMの本番運用に向けてセキュリティ・ガバナンスが求められる
- マルチテナントで複数チームがLLMを利用する予定
- オンプレミス・クラウドのハイブリッド構成を検討している
まずはOllamaやvLLMで小さく始めて、スケールが必要になったタイミングでOpenShift AI + llm-dへの移行を検討する、という段階的なアプローチも良さそうです。
参考資料
公式ドキュメント
- llm-d 公式サイト
- llm-d Architecture | llm-d
- Red Hat OpenShift AI ドキュメント
- vLLM Distributed Serving ドキュメント
- vLLM GitHub リポジトリ
Red Hat Developer / ブログ
- Ollama vs. vLLM: A deep dive into performance benchmarking | Red Hat Developer
- What is llm-d? | Red Hat
- Introduction to distributed inference with llm-d | Red Hat Developer
- Accelerate multi-turn LLM workloads on OpenShift AI with llm-d | Red Hat Developer
- Distributed inference with vLLM | Red Hat Developer
- Demystifying llm-d and vLLM: The race to production | Red Hat Blog
- How vLLM accelerates AI inference: 3 enterprise use cases | Red Hat