9月21日、nexlab.netが「Self-hosted inference orchestrators compared: LocalAI, exo, GPUStack, Xinference, Ollama, vLLM and CoderAI (September 2026)」と題した記事を公開した。セルフホスト型のLLM推論オーケストレーター7種を実際のGitHubスター数や機能表とともに比較し、用途別の選択指針をまとめている。
⚠️ 注意：本記事の著者はCoderAIプロジェクトの作者本人である。 CoderAIに関する記述は自己評価を含む可能性があるため、その点を踏まえて読むことを推奨する。
記事の最大の読みどころは「Apple SiliconならexoがNo.1、そうでなければ現時点で選択肢に入らない」という断言だ。各ツールの立ち位置を端的に言い表したこの評価を軸に、以下で各プロジェクトの詳細を見ていく。
比較表：機能の有無を一目で
スター数は2026年9月20日時点でのGitHub API取得値。「Multi-machine」はモデルまたはリクエストが複数マシンにまたがれるか、「Cache-aware routing」はKVキャッシュ（推論の途中結果を再利用する仕組み）を考慮してリクエストをルーティングできるか、「Cloud burst」は負荷に応じて自動でクラウドGPUを調達できるかを指す。
| プロジェクト | Stars | マルチマシン | キャッシュ認識ルーティング | クラウドバースト | Kubernetes | 署名済みイメージ |
|---|---|---|---|---|---|---|
| Ollama | 181k | ✗ | ✗ | ✗ | コミュニティ | ✗ |
| vLLM | 92k | Ray（TP/PP） | ✗ | ✗ | ✓ | ✗ |
| LocalAI | 49k | P2P+llama.cpp | ✓（v3） | ✗ | Helm | cosign |
| exo | 47k | パイプライン+TP | ✗ | ✗ | ✗ | ✗ |
| GPUStack | 5.7k | llama-box RPC+vLLM/SGLang | ✗ | ✗ | Helm | ✗ |
| Xinference | 9.6k | supervisor/workers | ✗（vLLMで共有KV） | ✗ | Helm | ✗ |
| CoderAI | 新規 | mDNS+llama.cpp+vLLM+SGLang | ✓ | ✓（RunPod） | ✗ | cosign |
読みどころ：「exo」のApple Silicon特化は別格
記事中で最も切れ味のある記述はexoの評価だ。
「Apple SiliconならexoはNo.1、そうでなければ2026年9月時点では選択肢に入らない」というのが著者の断言である。
exoはゼロコンフィグ発見（設定なしでノード同士が自動認識）、各デバイスのメモリに比例したリング/パイプライン/テンソル並列分割、そしてThunderbolt 5上のRDMAによる高速通信を実装している。4台構成で3.2倍のスループットという数字を公式が出している。バックエンドはApple独自の機械学習フレームワークMLXを使用。
一方、LinuxではCPUのみで動作し、NVIDIAおよびAMD対応は「開発中」の段階にとどまる。Mac Studio/Mac Proを複数台持つ環境では有力だが、NVIDIAのGPUサーバーには対応していない。
LocalAI：「なんでもあり」の代償はスループット
LocalAI（Stars: 49k）は、テキスト・画像・動画・音声・埋め込みを一つのOpenAI互換エンドポイントで提供し、バックエンドごとにOCIイメージ（コンテナイメージ）として分離されている。GPUなしでも動作し、Helmチャートも用意されている。
2026年6月以降は分散モードが加わり、--p2pフラグで共有トークンを生成するとlibp2pベースのノード間発見が有効になる。v3ルーターはVRAM残量とプレフィックスキャッシュの位置を考慮してルーティングを決定する。イメージはcosignで署名済みというのも運用上の安心材料だ。
ただし著者は「専用エンジンに対してLLMスループットは数十%劣る」と明記している。汎用性のコストである。
vLLMとllama.cpp：「他が内部で使っているエンジン」
vLLM（Stars: 92k）とllama.cpp（Stars: 129k）は、LocalAI・GPUStack・Xinference・CoderAIが内部で呼び出すエンジンそのものだ。モデル管理・ユーザー管理・配置決定の機能はなく、1プロセス1モデルが基本。単一モデルで最大スループットが必要なら、ラッパーを挟まずエンジン直接が最もシンプルというのが著者の見立てだ。
なお、llama.cppは比較表の7種には含まれていないが、LocalAIやGPUStackのマルチマシン対応の基盤として内部利用されており、記事中でも独立したエンジンとして言及されている。
GPUStack vs Xinference：アジアで実際に使われている「企業向けコンソール」
両者ともsupervisor+workersの構成で、Webコンソール・ユーザー管理・APIキー管理を備える。著者は「アジアのクラスターで実際に展開されているのをよく見かける」と述べている。
- GPUStack（5.7k）：Prometheus/Grafana統合、Ascend・Hygon・MThreadsを含む9種のアクセラレーターベンダー対応、ロール管理、従量課金メタリングが強み
- Xinference（9.6k）：音声・画像・リランク等のモデル種が多い、vLLMレプリカ間のKV共有、エンタープライズ版でマルチテナント対応
どちらもノード自動発見・クラウドバースト・マルチメディアのファンアウト・トレーニングには非対応。「部門のGPUをダッシュボードで管理したい」用途向けの選択肢と位置づけられている。
用途別の結論
著者が示す選択指針は以下のとおり。
- 1台で手軽に動かしたい → Ollama（+ Open WebUI）
- 1モデルで最大スループット → vLLM直接、共有するならLiteLLMをルーターとして前段に置く
- Macを複数台持っている → exo一択
- Linux上で画像・音声・動画も含めて全部 → LocalAI
- 部門GPUをユーザー・キー・ダッシュボード込みで管理 → GPUStack（またはXinference）
- Kubernetes上のラック規模 → NVIDIA Dynamo / llm-d（Kubernetesネイティブの推論スケジューラー）、ジョブのクラウドバーストにはSkyPilot / dstack（マルチクラウド対応のMLインフラ管理ツール）
- 自前マシン+必要時にクラウドGPUを自動調達、全モダリティを1エンドポイントで → CoderAI（LoRAの分散トレーニングも唯一対応）
なお、Petals（最終コミット2024年）とHugging Face TGI（2026年3月アーカイブ済み）は比較対象から除外されている。
詳細はSelf-hosted inference orchestrators compared: LocalAI, exo, GPUStack, Xinference, Ollama, vLLM and CoderAI (September 2026)を参照していただきたい。
