KubeAI: Kubernetes に推論エンジンを同居させる Operator の設計と導入判断
AI Inference Operator for Kubernetes. The easiest way to serve ML models in production. Supports VLMs, LLMs, embeddings, and speech-to-text.
ひと目でわかる
- これは何？
- KubeAI は vLLM、Ollama、FasterWhisper、Infinity といった推論サーバを Model CRD で管理し、OpenAI 互換 API を前面に立てる Kubernetes Operator である。導入価値はモデル配信の自動化とプレフィックス対応ロードバランシングにあり、その代わりに独自の抽象化とモデルカタログの保守を引き受けることになる。
- 誰に向いている？
- 既に Kubernetes 上で vLLM や Ollama を自前の Deployment として動かしており、モデルのダウンロードやボリュームのマウント、LoRA アダプタの配布を Operator に寄せたいチームに向く。逆に、Istio や Knative を既に標準基盤として運用している組織や、OpenAI 互換 API をクラウドのマネージド推論で足りると考えている場合は、KubeAI を挟む理由が薄い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 12 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
KubeAI が埋めるのは「モデル配信」と「ルーティング」の隙間
Kubernetes で LLM を動かすこと自体は難しくない。問題はその後の運用手順にある。vLLM の Deployment を書き、モデルの重みをダウンロードする initContainer を用意し、共有ストレージをマウントし、LoRA アダプタを各レプリカに配り、トラフィックが来ていないときにレプリカをゼロに落とす仕組みを別途用意する。この配線はどのチームも似たものを書き、どのチームも似たところで壊れる。
KubeAI はこの部分を Model という Custom Resource に畳む。README によれば、モデルオペレータはバックエンドの Pod を直接管理し、モデルのダウンロード、ボリュームのマウント、動的 LoRA アダプタのロードを自動化する。対象は LLM だけでなく、埋め込み、リランキング、音声認識まで含む。つまり「推論エンジンを Kubernetes のワークロードとして扱う」ための共通の型を提供するのが役割で、モデルそのものの品質や推論速度を上げる類のツールではない。
proxy と operator の二層構造
アーキテクチャは二つのサブコンポーネントに分かれる。ひとつはモデルプロキシで、OpenAI 互換の API を外側に公開する。対応エンドポイントとして README は /v1/chat/completions、/v1/completions、/v1/embeddings、/v1/rerank、/v1/models、/v1/audio/transcriptions を挙げている。既存の OpenAI クライアントライブラリをそのまま向けられるという主張はこの点に支えられている。
もうひとつがモデルオペレータで、バックエンドの Pod を直接管理する。README は両者が同一の Deployment に同居していると明記したうえで、独立配置も可能だとしている。ただしそれは issue #430 で議論されている段階の話であり、現時点で分離構成がどの程度検証されているかは素材からは判断できない。
プロキシ側の実装で特徴的なのは、リクエストのキューイングとリトライである。レプリカがゼロの状態からスケールする間、リクエストは捨てられずに待たされる。バックエンドが不調な場合のリトライもプロキシが持つ。ここが素の Service との差になる。
kube-proxy のランダム分散が vLLM で不利になる理由
KubeAI が繰り返し主張する技術的な論点は、vLLM はステートレスではないというものだ。推論の性能は KV キャッシュの状態に強く依存する。ところが Kubernetes Service の背後では kube-proxy がランダムに近い分散を行うため、同じプレフィックスを持つリクエストが別のレプリカに飛び、それぞれのレプリカで KV キャッシュをゼロから作り直すことになる。README はこれが TTFT とスループットの両方を悪化させると説明している。
KubeAI のプロキシはプレフィックスを考慮したロードバランシングを行い、KV キャッシュの利用効率を上げる。README には TTFT のベンチマーク画像と、blog/posts/llm-load-balancing-at-scale-chwbl.md へのリンクがある。ただし本稿はその数値を検証していない。効果の大きさはプレフィックスの共有度合いに依存するはずで、毎回プロンプトが大きく異なる用途では差が出にくいと考えられる。この点は README に明示的な条件が書かれていないため、実測で確かめる以外にない。
依存を減らすという設計判断
KubeAI は Istio や Knative を必要としない。スケール・トゥ・ゼロを Knative に頼らず、オートスケーリングを Prometheus の metrics adapter に頼らずに実装している。README はこれを「ほぼどの Kubernetes クラスタでもそのまま動く」ことと、day-two 運用の単純化につながると位置づけている。プロジェクト間のバージョンや設定のずれを気にしなくてよいという主張である。
これはトレードオフでもある。Istio を既に全社標準として運用している組織にとっては、KubeAI が独自に持つルーティング層は新しい運用対象になる。メッシュ側の可観測性やポリシー適用の仕組みをそのまま流用できるかは別途確認が要る。依存を減らすという選択は、依存を持たない組織には利益になるが、既にその依存を運用しきっている組織には重複になる。
導入手順とモデルカタログの書き方
ローカルで試す場合の流れは README に具体例がある。まず kind か minikube でクラスタを作る。Podman を使う場合はメモリ上限に注意が必要で、README は podman machine init --memory 6144 --disk-size 120 のように 6G 程度を確保する例を示している。
次に Helm リポジトリを追加し、本体を入れる。
helm repo add kubeai https://www.kubeai.org helm repo update helm install kubeai kubeai/kubeai --wait --timeout 10m
モデルは別チャートで入れる。README の例では kubeai-models.yaml に catalog 配下のエントリを書き、helm install kubeai-models kubeai/models -f ./kubeai-models.yaml のように渡す。エントリには enabled、features、url、engine、minReplicas、resourceProfile といったキーが並ぶ。url は ollama://deepseek-r1:1.5b のようなスキーム付きで書き、engine には OLlama のような値を指定する。features には TextGeneration のような機能種別を書く。
ここで実務上の制約が出る。同梱カタログに目的のモデルがなければ、この url と engine の組み合わせを自分で書く必要がある。カタログは一般的な GPU 向けに事前設定されていると README は説明しており、GPU の種類やモデルの組み合わせによっては自分で埋める前提で読んだほうがよい。
向かないケースと、KServe という別解
KubeAI が適さない場面はいくつかある。第一に、推論を Kubernetes の外に置いている場合。マネージドの推論 API で足りているなら、OpenAI 互換のエンドポイントを自前で立てる意味は薄い。第二に、モデルの形式やランタイムが vLLM、Ollama、FasterWhisper、Infinity のいずれにも収まらない場合。README が挙げるエンジンはこの範囲であり、独自ランタイムを載せる前提の作りには見えない。
比較対象として KServe が挙げられる。KServe は推論サービングを Kubernetes の標準的な抽象として提供することを狙い、Istio や Knative と組み合わせる構成が一般的だ。KubeAI との差は依存の置き方にある。KServe はメッシュやサーバーレス基盤の上に乗ることでトラフィック管理やスケールの機能を委譲する。KubeAI はそれらを内側に抱え込み、代わりに vLLM の KV キャッシュを意識したルーティングを自前で実装する。どちらが優れているかではなく、組織が既に何を運用しているかで選ぶ話になる。
もうひとつの制約はモデルキャッシュの置き場所だ。README は EFS などの共有ストレージのマウントを自動化すると書いているが、クラスタ外にストレージを用意できない環境では、この自動化が前提とする構成を組めない可能性がある。
Apache-2.0 とメンテナンスの実際
ライセンスは Apache-2.0 で、GitHub のバッジにもこれが表示されている。Apache-2.0 は商用利用や改変、再配布を許容し、特許条項を含む。ただし本稿は法務上の助言を行うものではない。自組織のポリシーに照らした確認は別途必要になる。
保守コストの観点では、リリースの刻みが参考になる。素材にある直近のリリースは v0.23.3 が 2026-07-20、Helm チャートの 0.23.4 が 2026-07-30 で、本体とチャートが別々のバージョン番号で動いている。helm install で入れる側はチャートのバージョンを見ることになり、Model CRD のスキーマがどのリリースで変わったかを追う必要がある。アップグレード時はチャートのバージョンと CRD の互換性をリリースノートで確認するのが現実的だ。
もう一点、モデルカタログは本体とは別チャートで配布される。つまりカタログの更新は本体のアップグレードとは独立して入ってくる。カタログ側の変更が既存の Model 定義に影響しないかは、上げる前に差分を見ておきたい。
編集部の結論
既に Kubernetes 上で vLLM や Ollama を自前の Deployment として動かしており、モデルのダウンロードやボリュームのマウント、LoRA アダプタの配布を Operator に寄せたいチームに向く。逆に、Istio や Knative を既に標準基盤として運用している組織や、OpenAI 互換 API をクラウドのマネージド推論で足りると考えている場合は、KubeAI を挟む理由が薄い。導入前に確認すべきは、自分のモデルが同梱カタログに存在するか、存在しない場合に Model CRD の url と engine を自分で書けるか、そして対象クラスタでプレフィックス対応ロードバランシングが効くだけのレプリカ数とリクエスト量があるかである。
コミュニティノート