Books pro: ローカルLLMをサービス提供するためのOSS・ソース公開ソフトウェア調査比較報告書

# ローカルLLMをサービス提供するためのOSS・ソース公開ソフトウェア調査比較報告書

## エグゼクティブサマリ

本調査は「ローカル（オンプレ／自組織管理下の単体サーバ、もしくは閉域Kubernetes等）でモデル推論を実行し、APIやUIとして“サービス提供”できるソフトウェア」を対象に、主要OSSおよび“OSSに近いが追加条件を伴うソース公開ライセンス”を含めて、機能・導入要件・運用性・ライセンス・コミュニティ指標（スター数・リリース状況）で比較した。2026-04-07（JST）時点の公式リポジトリ／公式ドキュメントを優先している。

結論として、**推論サーバ（Inference Engine/Server）**と**体験・アプリ層（UI／RAG／ワークフロー）**は分離して設計するのが主流であり、API形態としてはOpenAI互換（Chat Completions等）を提供できる実装が最も統合しやすい（vLLM、SGLang、llama.cpp、LMDeploy、MLC LLM、LocalAI、TabbyAPI、TGIなどが明示的に対応を掲げる）。citeturn21search32turn5view1turn21search31turn20view0turn5view3turn9view0turn22view0

推奨スタックは、目的別に大きく4系統に整理できる。

- **高スループットGPU推論（多同時・長文・本番API）**：vLLM（PagedAttention＋continuous batching）、SGLang（RadixAttention等のサービング最適化）を中心に据え、認証・レート制御はAPIゲートウェイで担保するのが合理的。citeturn5view2turn21search32turn3search20turn9view5

- **NVIDIA最適化（最大TPS／マルチGPU／運用基盤統合）**：TensorRT-LLM（最適化ライブラリ）＋Triton Inference Server（汎用サービング基盤、HTTP/GRPC、dynamic batching、metrics）という分業が明確で、Kubernetes／監視に乗せやすい。citeturn9view6turn34view3turn31view0

- **CPU/エッジ・ローカル体験（簡易配布、ノートPC〜小型サーバ）**：llama.cppはC/C++ベースで多様なバックエンド（CPU/GPU）に対応し、llama-serverでOpenAI互換APIや監視エンドポイントを提供できる。Ollamaは「ローカルでモデルを動かす」UXを強く意識した周辺エコシステムがあり、UIと組み合わせやすい。citeturn5view1turn12view1turn25search3turn25search30

- **“一台でそれっぽく社内サービス化”志向（認証や多バックエンド統合込み）**：LocalAIはOpenAI互換の“ドロップイン置換”を掲げつつ、多数のバックエンド統合とAPIキー認証・RBACなど運用寄り機能がREADMEに明示されている。citeturn5view3turn12view4

一方で、**ライセンス面の注意**が重要である。DifyはApache 2.0をベースにしつつ「マルチテナントでの提供禁止（要商用許諾）」等の追加条件が明記されており、SaaS提供やグループ会社跨ぎの提供では法務確認が必須となる。citeturn18view0turn17view0 Open WebUIも“Open WebUI”のブランディング改変に強い制限（例外条件あり）がライセンス条項として明示されるため、白ラベルや再配布での自由度は低い。citeturn19view1turn9view11 LangServeも第三者向けホステッドサービス提供を禁じる条項を含み、商用SaaSの中核に据える用途には不向きである。citeturn29view0turn26view0

最後に、TGI（Text Generation Inference）は機能面で完成度が高いが、2026-03-21にアーカイブ（読み取り専用化）され、メンテナンスモードであることが明記されているため、新規本番採用には慎重な判断が必要である。citeturn24view0turn24view3turn24view1

## 調査範囲と方法

対象範囲は次の条件を満たすものとした。

- **ローカルでモデル推論を実行**できる（同一ホスト、もしくは自組織管理下のノード群で推論が走る）

- **サービス提供形態（HTTP/REST、gRPC、もしくはWeb UI）**を持つ、または容易に提供できる（例：OpenAI互換API、独自REST、UI）

- ライセンスは**OSI準拠のOSS（MIT/Apache/BSD等）**を優先しつつ、現実の導入判断に影響が大きいことから、**追加条件付きのソース公開（“Open Source License”を名乗るが制限付き）**も比較対象に含め、明示的に区別した（例：Dify、Open WebUI、LangServe）。citeturn18view0turn19view1turn29view0

情報源は、(1)公式GitHubリポジトリ（README、LICENSE、Release表示）、(2)公式ドキュメント、(3)主要な導入・運用記事（ただし本結論を左右しない補助）を優先して統合した。スター数・最新リリース日はGitHubの表示（2026-04-07近傍に取得）を採用した。citeturn12view1turn6view1turn6view0turn16view0turn31view0

留意点として、GitHubの静的HTMLでは**コントリビュータ“人数”が確定取得できないリポジトリが多い**ため、コントリビュータ数は原則「未指定」とし、代替としてスター数・リリース頻度・アーカイブ有無で活性度を近似した。citeturn12view1turn24view0

## 技術的整理

ローカルLLMの“サービス化”は、概ね次の層に分解できる。

- **推論エンジン／サーバ層**：KVキャッシュ管理、バッチング、並列化、量子化等の“性能の肝”を実装（例：vLLM、SGLang、llama.cpp server、LMDeploy、MLC LLM、TensorRT-LLM）。citeturn5view2turn9view5turn5view1turn21search0turn20view0turn9view6

- **サービング基盤層**：複数モデルの同居、動的バッチ、プロトコル（HTTP/GRPC）、メトリクス、デプロイ（Docker/K8s）を整備（Tritonなど）。citeturn31view0

- **アプリ／UI／ワークフロー層**：ユーザ管理、RAG、エージェント、プロンプト管理、観測（オブザーバビリティ）など“プロダクト要件”を満たす（Open WebUI、Dify、AnythingLLM、Flowise、Haystack/Hayhooks、PrivateGPT等）。citeturn16view0turn17view0turn15view3turn15view4turn26view2turn9view9

典型アーキテクチャは、推論サーバを中心に、認証・レート制御・監視・永続化を外部化して組む（特に本番）ことが多い。TritonはmetricsやHTTP/GRPCを含む多機能サーバとしてこの“外側の運用機能”も強めに提供し、TGIもPrometheus/OpenTelemetry等の運用機能を内包していた。citeturn31view0turn22view0

```mermaid

flowchart LR

U[利用者/アプリ] -->|OpenAI互換 or 独自REST| GW[APIゲートウェイ/認証/レート制御]

GW --> S1[推論サーバ vLLM / SGLang / llama-server / LMDeploy / MLC LLM / LocalAI]

GW --> UI[Web UI/アプリ層 Open WebUI / Dify / AnythingLLM / Flowise]

UI -->|プロバイダ設定| S1

S1 -->|必要に応じて| RAG[RAG/エージェント実行 Haystack/Hayhooks/PrivateGPT等]

RAG --> VDB[(Vector DB / 検索基盤)]

RAG --> OBJ[(永続ストレージ ドキュメント/会話/ログ)]

S1 --> MET[監視/メトリクス Prometheus等]

S1 --> LOG[ログ/トレース OpenTelemetry等]

```

上図において“OpenAI互換API”を中核に置くと、既存のSDKや上位UI（Open WebUI等）が接続しやすい。実際にllama.cpp serverはOpenAI互換APIを掲げ、vLLMもOpenAI互換サーバの提供を明示し、MLC LLMやLocalAI、TabbyAPIなども同様の互換性を前面に出している。citeturn5view1turn21search32turn21search1turn5view3turn9view0turn20view0

## 主要プロジェクト比較表

以下の表は、主要プロジェクトを「推論・サービング中心」と「UI/アプリ中心」に分け、指定属性を要約した。未確認事項は指示通り「未指定」とした。

### 推論・サービング中心

|---|---|---|---|---|---|---|---|---|---|---|

| llama.cpp（llama-server） | `https://github.com/ggml-org/llama.cpp` citeturn12view1 | C/C++推論。llama-serverでOpenAI互換API、embeddings、multimodal、continuous batching、監視エンドポイント等を提供。citeturn5view1turn12view1 | multi-user support（詳細な認証は未指定）citeturn5view1 | 未指定 | 多様なバックエンド（CPU/GPU）を掲げる。citeturn12view1 | 監視エンドポイントあり（具体方式未指定）。citeturn5view1 | MIT citeturn12view1 | 102k / 最新リリース 2026-04-06 citeturn12view1 | 未指定 | 長所：移植性・単体導入が容易。短所：認証/テナント等は外付け前提。用途：エッジ/単体サーバのOpenAI互換API、PoC〜社内小規模API。 |

| LMDeploy | `https://github.com/InternLM/lmdeploy` citeturn9view4 | LLMの圧縮/デプロイ/サービング。OpenAI互換サーバ（api_server）を公式Docsで説明。citeturn21search0turn21search31turn9view4 | 未指定 | 未指定 | pip/whl等（詳細は未指定）。複数GPU跨ぎのOpenAI互換サービングを想定。citeturn21search0turn15view5 | Request Distribution Server等の概念をDocsで言及。citeturn21search0 | Apache 2.0 citeturn9view4 | 7.8k / 最新リリース 2026-03-18 citeturn15view5turn11view3 | 未指定 | 長所：公式にOpenAI互換サービング手順がまとまる。短所：認証/テナントは未指定。用途：OpenAI互換での社内API化、GPU複数枚で単一モデル運用。 |

| TensorRT-LLM | `https://github.com/NVIDIA/TensorRT-LLM` citeturn11view5turn34view3 | NVIDIA GPU向け最適化ライブラリ（custom kernels、prefill-decode分離等）を掲げ、単一GPU〜マルチGPU/マルチノードまでの推論を想定。Triton等の推論エコシステム統合を明示。citeturn9view6turn34view3 | 未指定 | 未指定 | 前提：NVIDIA GPU。詳細は未指定。citeturn9view6 | “サービング製品”というより最適化ライブラリ色が強い（フロントはTriton等）。citeturn9view6 | Apache 2.0（本体。含有コードは別ライセンスあり）citeturn34view3turn34view1 | 13.3k / 最新リリース 2026-03-12 citeturn32view0 | 未指定 | 長所：NVIDIA環境での最大性能を狙いやすい。短所：運用サーバは別途必要。用途：マルチGPU本番、最高TPS/コスト最適化。 |

| Triton Inference Server | `https://github.com/triton-inference-server/server` citeturn31view0 | OSS推論サービング基盤。複数FW（TensorRT/PyTorch/ONNX/OpenVINO/Python等）対応、dynamic batching、HTTP/REST＋gRPC、メトリクス等をREADMEで明示。citeturn31view0 | 未指定 | モデルリポジトリ方式（詳細未指定）citeturn31view0 | GPU/CPU（x86/ARM）等の多様な配置を掲げる。citeturn31view0 | Metrics、Secure Deployment Considerationsへの導線あり。citeturn31view0 | BSD-3-Clause citeturn31view0 | 10.5k / 現行リリース2.67.0（README記載）citeturn31view0 | 未指定 | 長所：運用基盤としての機能が厚い。短所：LLM特化の手軽さは低い。用途：複数モデル同居、監視/ガバナンス込みの推論プラットフォーム。 |

| Text Generation Inference（TGI） | `https://github.com/huggingface/text-generation-inference` citeturn22view0turn24view0 | Rust/Python/gRPCサーバ。continuous batching、SSEストリーミング、OpenTelemetry＋Prometheus metrics等を列挙。OpenAI互換Messages APIを明示。citeturn22view0 | 未指定 | Docker例では重みを`/data`にボリューム共有。citeturn22view0 | Nvidia/AMD/Inferentia/Intel GPU/Gaudi/TPU等のHWサポートを列挙。citeturn22view0 | 分散トレーシング、Prometheus等“本番運用機能”を内包。citeturn22view0 | Apache 2.0 citeturn24view1turn23view1 | 10.8k / 最新リリース 2025-12-19、ただし2026-03-21にアーカイブ（読み取り専用）citeturn24view1turn24view0 | Hugging FaceでHugging Chat等を支えると明記。citeturn22view0 | 長所：本番運用の作り込み。短所：アーカイブ済みで将来性が限定。用途：既存資産の保守、参考実装、短期の限定運用。 |

### UI/アプリ開発・オーケストレーション中心

|---|---|---|---|---|---|---|---|---|---|

| Open WebUI | `https://github.com/open-webui/open-webui` citeturn11view8turn16view0 | Ollama等対応のWeb UI。RBAC（事前定義ロール/グループ）をDocsで明示。Basic Auth（シングルユーザ向け）もドキュメント化。Docker例でデータ永続化ボリューム（`/app/backend/data`）を提示。citeturn1search10turn1search33turn16view2turn16view0 | Ollama/OpenAI API等（UI側設定）。citeturn16view0 | Docker運用が中心（詳細未指定）citeturn16view2 | 認証/RBACは実装済みだが、ライセンス上“ブランド改変不可”など制限。citeturn19view1turn9view11 | 追加条件付きライセンス（ブランド制限等）citeturn19view1turn19view0 | 130k / 最新リリース 2026-03-27 citeturn16view0 | 未指定 | 長所：UI + 権限管理が強い。短所：白ラベル/再配布の自由度が低い。用途：社内チャットUI、複数ユーザでのローカルLLM活用（ブランド制約許容時）。 |

| Flowise | `https://github.com/FlowiseAI/Flowise` citeturn11view7turn15view4 | “Build AI Agents, Visually”を掲げるGUI構築。ライセンスApache 2.0を明示。citeturn9view10turn11view7 | 未指定（一般に外部LLM接続。詳細未指定） | Node.js等（READMEにNodeJS要件があり得るが本表では未指定）citeturn11view7 | 未指定 | Apache 2.0 citeturn9view10turn11view7 | 51.6k / 最新リリース 2026-03-23 citeturn15view4turn11view7 | 未指定 | 長所：非エンジニアでもワークフローを組みやすい。短所：本番セキュリティ設計は別途。用途：社内プロトタイピング、RAG/エージェントの可視化構築。 |

| Haystack | `https://github.com/deepset-ai/haystack` citeturn27view1turn26view1 | PythonのAIオーケストレーション。ローカルモデル含むベンダー非依存統合を説明し、REST API化にはHayhooksを推奨。citeturn26view1turn25search39 | ローカルLLMは各Generator統合（例：OllamaGenerator）。citeturn25search3turn26view1 | pip等（詳細未指定）citeturn26view1 | Telemetry（匿名統計）とopt-outを言及。citeturn26view1 | Apache 2.0（混在注記あり）citeturn26view1turn28view2 | 24.7k / 最新リリース 2026-04-01 citeturn28view2turn27view1 | READMEで多数の組織での利用例示（個別名の検証は未指定）。citeturn26view1 | 長所：RAG/評価/ルーティング等を構成要素で管理。短所：サービングや認証は別コンポーネントが必要。用途：RAG基盤、再現性の高いパイプライン運用。 |

| Hayhooks | `https://github.com/deepset-ai/hayhooks` citeturn27view2turn26view2 | HaystackのPipelines/AgentsをREST APIやMCPとしてデプロイ。OpenAI互換エンドポイント生成、Open WebUI連携、Chainlit UI埋込などを列挙。citeturn26view2turn25search25 | Haystack上の各Generator（ローカルLLM含む） | pip等（詳細未指定）citeturn26view2 | 認証/マルチテナントは未指定（APIゲートウェイ推奨）。 | Apache 2.0 citeturn26view2turn27view2 | 139 / 最新リリース 2026-03-31 citeturn28view3turn27view2 | 未指定 | 長所：Haystackを“即API化”できる。短所：新しめで導入実績は未指定。用途：社内RAGをOpenAI互換で提供し、UIに接続する薄いサーバ。 |

| LangServe | `https://github.com/langchain-ai/langserve` citeturn27view0turn29view0 | LangChainのrunnables/chainsをFastAPI統合でREST化。多数の同時リクエスト、/stream等を列挙。ただし新規はLangGraph Platform推奨、機能追加は限定的とREADMEで明記。citeturn26view0 | 外部推論（LangChain経由） | 未指定 | ライセンスで“第三者へのホステッド/マネージド提供禁止”。citeturn29view0 | 制限付き（LangServe License）citeturn29view0 | 2.3k / 最新リリース 2025-10-17 citeturn28view1turn27view0 | 未指定 | 長所：チェーンを即API化。短所：SaaS提供には不適、将来機能は限定。用途：社内限定のAPI化、短期プロジェクト。 |

## 評価軸別の比較・厳密評価

性能・運用・法務の3つが、ローカルLLMの“サービス成立”を左右する主要因である。

性能面では、**KVキャッシュ効率とバッチング**が同時接続に直結する。vLLMはPagedAttentionやcontinuous batchingを明示し、OpenAI互換サーバも提供しているため「既存アプリ互換＋高スループット」の要件に合致しやすい。citeturn5view2turn21search32 SGLangも高性能サービングと幅広いハードウェア対応を掲げ、推論基盤の選択肢を広げる。citeturn9view5turn3search20 NVIDIA環境で最大性能を狙う場合、TensorRT-LLMは最適化ライブラリとして単体GPU〜マルチノードまでを想定し、Tritonとの統合も明示されているため、運用基盤（Triton/Kubernetes）と合わせて設計するのが筋が良い。citeturn9view6turn31view0turn34view3

運用面では、**監視・セキュリティ・認証**が不可欠である。TritonはmetricsやHTTP/GRPC、Secure Deployment Considerationsへの導線をREADME上に持ち、一般的な推論プラットフォームとして“運用機能込み”で採用しやすい。citeturn31view0 LocalAIはAPIキー認証やRBAC、ユーザクォータ等を列挙しており、「単一OSSで社内向けに最低限の統制を効かせたい」要件で候補になりやすい。citeturn5view3turn12view4 Open WebUIはRBACとBasic Authを文書化しているが、UI製品としての強み（多ユーザ体験）と引き換えにライセンス上のブランド制約があるため、ガバナンスの観点では“機能だけでなく配布形態”まで含めて判断が必要である。citeturn1search10turn1search33turn19view1

法務・ライセンス面は、SaaS提供や外部提供の可否に直結する。MIT/Apache/BSDは一般に社内・社外提供の制約が少ないのに対し、Difyはマルチテナント提供に制限を課し、Open WebUIはブランド改変制限、LangServeは第三者へのホステッド提供禁止を明示する。citeturn18view0turn19view1turn29view0 したがって「社内限定（単一組織内）」であればDify等も強力な選択肢になり得るが、「外部顧客への提供」や「ホワイトラベル」ではOpenLLM/LocalAI/vLLM＋自前UIなど、より自由度の高いライセンスへ寄せるのが安全である。citeturn18view0turn30search0turn5view3turn21search32

また、プロジェクトの継続性も重要である。TGIは機能が豊富で、プロダクションで利用されていた実績を明記する一方、メンテナンスモードかつアーカイブ済みであるため、今後の追従（新GPU、新モデル、依存更新）のリスクが増大する。citeturn22view0turn24view0turn24view3

## 推奨ユースケース別の結論

社内のLLMサービスを成立させる上で、意思決定は「性能・運用・法務」を同時に満たす組合せ最適化になる。

社内チャット（多ユーザ・会話履歴・簡易管理）を最短で作るなら、Ollamaを推論プロバイダとして置き、Open WebUIのRBACやBasic Authで“社内UI”を構成するのが最短距離になり得る。ただし、Open WebUIのブランディング制約が要件に反する場合は、別UI（自前、またはライセンス制約の少ないUI）に切り替えるべきである。citeturn25search3turn1search10turn1search33turn19view1

社内API（既存アプリから呼ぶ、同時接続が多い）なら、vLLMのOpenAI互換サーバを中核に置き、APIゲートウェイで認証・レート制御を行う設計が最も一般化しやすい。vLLMのPagedAttention/continuous batchingはこの用途のボトルネック（KVキャッシュとバッチング）に正面から対処している。citeturn21search32turn5view2 さらに先進機能や幅広いHW選択を優先するならSGLangも候補となる。citeturn9view5turn3search20

オンプレ本番で“推論プラットフォーム”まで含めて整備する（複数モデル・複数FW・監視標準化）なら、Triton中心の設計が合理的である。LLMについてはTensorRT-LLMバックエンド（またはvLLMバックエンド等）を組み合わせることで、性能と運用の両立を目指せる。citeturn31view0turn9view6turn34view3turn30search6

RAG（文書QA）を早期に“APIとして”成立させるなら、PrivateGPTはFastAPI＋OpenAI API schemeとしてRAGプリミティブを公開すると明言しており、構成理解と拡張がしやすい。より汎用・構成管理重視ならHaystack＋HayhooksでREST化し、推論はOllama等のローカルプロバイダに委譲する構成が取りやすい。citeturn9view9turn26view2turn25search3turn25search25

## 補遺

本報告書は「推論をローカルで実行しサービス提供できる」主要OSSを中心に整理したが、実運用では用途に応じて派生・周辺OSS（SDK、UI、プロキシ、最適化ライブラリ、K8s統合）が組み合わされる。例えば、HaystackはOllamaGenerator等の統合を公式ドキュメントで提供し、LangChainもllama.cpp/Ollama統合を公式ドキュメントで提供している。citeturn25search3turn25search2turn25search30 また、TensorRT-LLMのLICENSEは“含有コードのライセンス一覧”も含んでおり、再配布や派生開発の際はサブディレクトリ単位のライセンス差異に注意が必要である。citeturn34view3turn34view1

Books pro

2026年4月9日木曜日

ローカルLLMをサービス提供するためのOSS・ソース公開ソフトウェア調査比較報告書

ラベル

ブログアーカイブ

2026年4月9日木曜日

ローカルLLMをサービス提供するためのOSS・ソース公開ソフトウェア調査比較報告書

ラベル

ブログ アーカイブ

ブログアーカイブ