はじめに

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への移行を検討する、という段階的なアプローチも良さそうです。

参考資料

公式ドキュメント

Red Hat Developer / ブログ

その他の参考記事

Red Hat Brings Distributed AI Inference to Production AI Workloads with Red Hat AI 3 | Business Wire