セルフホスト型推論オーケストレーターの比較：LocalAI, exo, GPUStack, vLLM

セルフホスト型推論オーケストレーターの比較：LocalAI, exo, GPUStack, Xinference, Ollama, vLLM、およびCoderAI（2026年9月）

これは、私が自身のプロジェクトのために行った調査の参照版であり、CoderAIを実行していない人にも役立つように書かれています。GPUを1台以上搭載したマシンがあり、それらの前面にOpenAI互換のエンドポイントを設置したい場合、2026年9月時点で存在するセルフホスト型オーケストレーター、それぞれの機能、そして状況に応じた選択肢について解説します。スター数は2026年9月20日時点のGitHub APIからのものです。機能セルは、末尾にリンクされているプロジェクト自身のREADMEとドキュメントからのものです。確認できなかった項目については、推測ではなくその旨を記載しています。

表

モダリティ: プラグインが到達できるものではなく、サーバー自体が生成するもの。
マルチマシン: 1つのモデルまたは1つのリクエストが複数のボックスを使用できるかどうか。
キャッシュ対応ルーティング: 後続のターンが、KV/プレフィックスキャッシュが既に存在する場所に送信されるかどうか。
クラウドバースト: サーバーが自身でGPUをレンタルできるかどうか。
非LLMファンアウト: 画像/オーディオ/埋め込みリクエストがマシン間で分割されるかどうか。
Petals（最終コミット2024年）とHugging Face TGI（2026年3月アーカイブ）は除外されています。

各ツールの用途

OllamaとOpen WebUI — デフォルト、1台のマシン向け

1つのバイナリ、ollama pull、そして回答。妥当なデフォルト設定のモデルライブラリ、Modelfile形式、そしてOpen WebUIを前面に置けば、エンジニアでないユーザーでも使えるチャット製品。ラップトップやデスクトップ1台に最適なソリューションです。これは1台のマシン、一度に1つのモデルであり、Open WebUIが複数のOllama URLをラウンドロビンで処理する以上のクラスタリング機能はありません。もしそれが必要なら、ここで読むのをやめてください。

llamafile — 1つのファイルにまとまったllama.cpp

Mozillaによるllama.cppとモデルを単一の実行ファイルにパッケージ化したもので、Linux、macOS、Windows、BSDsでそのまま動作します。「このモデルをあのラップトップで実行したい」という要望に最適な回答です。設計上シングルマシン向けで、オーケストレーションはありません。Ollamaと同じカテゴリに位置します。読者からの「なぜこれが欠けているのか？」という質問を受けて追加されました。もっともな質問です。

llama.cppとvLLM — 他の多くのツールがラップするエンジン

これらはどちらも、マシンを跨いで利用できるという狭い意味でのみオーケストレーターです。llama.cppは各ボックスにrpc-serverを、サーバーには--rpcを使用し（デフォルトで行分割、高速リンクではテンソル並列のために列分割）、vLLMはRayを使用してテンソル並列とパイプライン並列を実現します。どちらもモデル、ユーザー、配置などを管理せず、プロセスごとに1つのモデルを処理するだけです。これらはLocalAI、GPUStack、Xinference、CoderAIが基盤として使用しており、もし1つのモデルしか必要ない場合は、エンジンを直接実行するのが最も簡単です。

LiteLLM — ランタイムではなくルーター

これは、100以上のプロバイダーや自身のエンドポイントの前面に配置され、キー、予算、支出追跡を行います。モデル自体は実行しません。複数のチームが共有する場合に、これらのいずれかの前面に配置するコンポーネントであり、しばしばセルフホスティングソリューションと混同されますが、そうではありません。

LocalAI — 「すべて」に最も近いもの

テキスト、画像、ビデオ、オーディオ、埋め込みに対応したOpenAI互換API。各バックエンドは独自のOCIイメージ内のgRPCサービスとして動作し、GPUは不要です。Helmチャートも提供されており、2026年6月からは真の分散モードも利用可能になりました。--p2pオプションで共有トークンが生成され、インスタンスはlibp2p/EdgeVPN経由で互いを検出し、リクエストは最も負荷の低いノードにフェデレートされるか、llama.cppモデルがワーカー間でシャーディングされます。また、NATSベースの「v3」ルーターはVRAMとプレフィックスキャッシュを認識します。バックエンドイメージはcosignで署名されています。できないこと：GPUのレンタル、非LLMリクエストのマシン間分割、トレーニング。その汎用性の高さゆえに、専用エンジンと比較して生のLLMスループットは数10パーセント低下します。大規模なコミュニティを持ち、エスカレーションを必要としない広範な機能性を求めるなら、これが主流の選択肢です。

exo — Macのスタックを1つのコンピュータとして

ゼロコンフィグ検出、各デバイスのメモリ量に応じたリング/パイプライン/テンソルパーティショニング、MLXを基盤とし、最新のmacOSではThunderbolt 5経由のRDMAにより、真にスケーラブルなテンソル並列（公式発表では4デバイスで3.2倍）を実現します。2026年9月現在、LinuxではCPUのみで動作し、NVIDIAとAMDは「開発中」です。言語モデル（画像生成はフィーチャーフラグの後ろ）を提供します。ハードウェアがApple Siliconであれば、これに匹敵するものはありません。そうでなければ、exoはまだあなた向けではありません。

GPUStackとXinference — エンタープライズコンソール

どちらもスーパーバイザーとワーカーの構成でWebコンソールを備えており、どちらも企業によってサポートされています。アジアでは実際にクラスターとしてデプロイされているのをよく見かけます。GPUStackはよりオペレーション指向です。ユーザーとロール、メータリング付きAPIキー、PrometheusとGrafana、失敗したモデルの自動復旧、UIでのRayワーカーログ、llama-box（llama.cpp RPC）とvLLM/SGLang/TensorRT-LLMによるテンソルおよびパイプライン並列、そしてAscend、Hygon、MThreadsを含む9つのアクセラレーターベンダーのサポートを提供します。ワーカーはLinuxのみです。Xinferenceは、より多くのモデルタイプ（音声、画像、リランク）をカバーし、組み込みレジストリ、vLLMレプリカ間での共有KV、そしてマルチテナント機能を持つエンタープライズエディションを備えています。どちらもノード検出、クラウドへのバースト、非LLMワークの分割、トレーニングは行いません。部門のGPUを管理し、ダッシュボードを誰かに見せる必要がある場合は、これらのいずれかを選択してください。

NVIDIA Dynamoとllm-d — データセンターファブリック

プリフィルとデコードの分離、KVキャッシュ対応ルーティング、マルチティアKVストレージをKubernetes上でNVIDIAハードウェアに実装します。これらはラック単位で始まる問題を解決し、それ以下の規模では不向きなツールです。「KV対応ルーティング」というアイデアが、より小規模なプロジェクトで現在借用されているため、ここに含めました。

SkyPilotとdstack — リクエストではなくジョブをバースト

どちらもオンプレミスのKubernetesとあらゆるクラウド全体でジョブをスケジューリングし、オンプレミスが満杯になったらクラウドにバーストして最も安価なキャパシティを見つけます。それらの用途には優れていますが、推論サーバーではありません。vLLMを持ち込めば、それらが配置してくれます。リクエストごとにローカルで実行するかレンタルするかを決定するエンドポイントが必要な場合、これらのどちらもそれに該当しません。

CoderAI — エスカレーションと、あらゆるモダリティの分散

これは私のプロジェクトなので、その点を考慮して読んでください。テキスト、画像、ビデオ、TTS、STT、話者分離、埋め込み、リランク、OCRに対応した単一のOpenAI互換エンドポイントで、モデルごとにエンジンが選択されます（CUDAとVulkan対応のllama.cppを同一マシンで、Transformers、vLLM、ktransformers、および3つの純粋Cエンジン）。マルチマシンレイヤーはGPUStack（ノードをエンジンとして、llama.cpp RPCでレイヤーまたは行分割、Ray上のvLLM、SGLangマルチノード）とLocalAIのゼロコンフィグ（共有トークン1つ、mDNS検出、プレフィックスキャッシュルーティング）およびオペレーション（Prometheus、キーごとの使用量、ノードログ、cosign署名済みイメージ）に似ています。他にはない部分は、3段階のエスカレーションです。モデルはまず自分のカードで実行され、次に所有するマシンで、そして最終的には1秒あたりに価格上限と予算付きでレンタルされるRunPod GPUで実行されます。これはモデルごとに選択され、「ビジー時のみ」に切り替え可能です。画像、ビデオ、埋め込み、音声、文字起こし、OCRリクエストをモデルを持つすべてのマシンにファンアウトさせ、ビデオパイプラインは部分ごとにリレーされます。また、LoRA/QLoRAトレーニングは、同じサーバーからノード間でデータ並列で実行されます。欠けているもの：Kubernetes、Apple Silicon、モデルカタログ、コミュニティ。そして、マルチマシンパスは実際のケーブルではなく、フェイクやlocalhostに対してテストされている段階です。

状況に応じた選択

• 1台のマシンで、とにかく簡単に動作させたい場合: Ollama (+ Open WebUI)。
• 単一モデルで、最大スループット、多数のユーザー: vLLMを直接、チームで共有する場合はLiteLLMを前面に。
• Macのスタック: exo。Apple Siliconではこれに匹敵するものはありません。
• すべて（画像、オーディオ、ビデオも）をLinuxで、大規模コミュニティ、クラウドなし: LocalAI。
• ユーザー、キー、ダッシュボードを備えた部門のGPU: GPUStack。より広範なモデルレジストリが必要ならXinference。
• Kubernetes上のラック: Dynamoまたはllm-d。ジョブのバーストにはSkyPilotまたはdstackを使用。
• 所有する数台のマシンと、それらが不十分な場合にレンタルするカード、あらゆるモダリティ、単一のエンドポイント: CoderAI。また、LoRAを自分のボックス間でトレーニングできる唯一のツールです。

ソース

ollama/ollama · llama.cpp RPC README · Mozilla-Ocho/llamafile · vLLM distributed serving · BerriAI/litellm · LocalAI P2P / federated inference · mudler/LocalAI · exo-explore/exo · xorbitsai/inference · gpustack/gpustack · GPUStack inference backends · ai-dynamo/dynamo · llm-d introduction · SkyPilot on Kubernetes · dstack · CoderAI docs/cluster.md。
スター数：GitHub API、2026-09-20。
修正歓迎 — CoderAIリポジトリでイシューを開いていただければ、表を修正します。