KubeAI：把 vLLM 與 Ollama 當成 Kubernetes 原生工作負載來管
AI Inference Operator for Kubernetes. The easiest way to serve ML models in production. Supports VLMs, LLMs, embeddings, and speech-to-text.
秒懂
- 它是什麼？
- KubeAI 是一個以 Go 撰寫的 Kubernetes Operator，把模型推論伺服器的部署、擴縮與路由收進單一元件。它的核心主張是零外部依賴，代價是排程與擴縮邏輯得自己養。
- 適合誰用？
- KubeAI 適合已經有 Kubernetes、想用單一 Operator 把 vLLM 或 Ollama 跑起來、而且願意接受它自帶 proxy 與 autoscaler 的團隊；如果你的瓶頸是跨節點的 GPU 排程與佇列公平性，或你已經在用 KServe、Ray Serve 這類推論平台，KubeAI 不會取代它們。採用前先確認三件事：你的 Kubernetes 版本與 Helm chart 0.23.4 是否對得上、你的 GPU 類型是否落在它預先配置的 catalog 裡、以及 prefix-aware 路由在單一 replica 或無共享前綴的流量下是否還有意義。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 12 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的不是部署，而是部署之後的那一段
自己寫一份 vLLM 的 Deployment 不難。難的是之後：模型權重從哪裡來、要不要掛 EFS、GPU 節點不夠時怎麼排、沒有流量時 replica 要不要縮到零、多個 replica 之間請求怎麼分。KubeAI 把這些收進一個 Model CRD，讓模型變成叢集裡的一等資源，而不是一組手寫的 YAML。
它的目標讀者是已經有 Kubernetes 叢集、不想再引入 Istio 或 Knative 的團隊。README 把這點寫得很直白：KubeAI 不依賴 Istio、Knative（用於 scale-from-zero），也不依賴 Prometheus metrics adapter（用於 autoscaling）。對維運者來說，這代表少一層版本矩陣要對齊；對平台團隊來說，這也代表擴縮與路由的品質由 KubeAI 自己負責，出了問題沒有第二個社群可以問。
涵蓋的推論類型包括 LLM、embedding、reranking 與語音轉文字，對應的後端引擎在 README 中列為 vLLM、Ollama、Infinity 與 FasterWhisper。這是一個刻意收窄的集合：它不打算支援所有推論框架，而是替常見的幾種做好預設設定。
兩個子元件：proxy 與 model operator
README 的架構章節把它拆成兩塊。model proxy 對外提供 OpenAI 相容 API，對內實作 prefix-aware 負載平衡，並負責請求排隊（在系統從零 replica 擴起來的期間）與請求重試（換掉狀況不好的後端）。model operator 則直接管理後端 server 的 Pod，處理模型下載、volume 掛載，以及透過 Model CRD 在多個 replica 之間載入動態 LoRA adapter。
兩者目前放在同一個 deployment 裡，README 也註明它們「could be deployed independently」，並連到 issue #430。這意味著現在還不是可獨立部署的狀態，而是被視為未來方向。如果你的架構要求控制面與資料面分離，這是需要先確認的點。
prefix-aware 這一段值得多說一句。KubeAI 的理由是：kube-proxy 背後那種隨機負載平衡，在跑多個 vLLM replica 時表現不好，因為 vLLM 不是無狀態服務，它的效能受 KV cache 狀態影響很大。同一個前綴的請求如果落到不同 replica，等於每次都要重算。KubeAI 的 proxy 因此改用前綴感知的策略來提高 KV cache 命中。README 附了一張 TTFT 基準圖，並連到一篇題為 llm-load-balancing-at-scale-chwbl 的文章。我沒有跑過那份基準，圖上的數字無法在此驗證，但機制本身是可理解的。
反過來說，這個設計的價值高度取決於流量形態。如果你的請求前綴彼此無關，或你只跑單一 replica，prefix-aware 排序帶來的差異會很小，而你仍然要接受 proxy 位於請求路徑上這件事。
從 kind 到第一個模型：實際指令
README 的 Local Quickstart 走 Helm。先準備一個本機叢集，kind 或 minikube 皆可，然後加入 chart repository：
helm repo add kubeai https://www.kubeai.org helm repo update
安裝本體並等待元件就緒，README 給的逾時是 10 分鐘：
helm install kubeai kubeai/kubeai --wait --timeout 10m
接著用 models chart 啟用預先定義的模型。README 的範例是把 catalog 寫成一份 values 檔再餵給 helm install kubeai-models kubeai/models。範例中啟用了三個：deepseek-r1-1.5b-cpu、qwen2-500m-cpu、nomic-embed-text-cpu。前者的欄位比較完整，可以看到這個 CRD 的形狀：features 為 TextGeneration，url 用 ollama://deepseek-r1:1.5b 這種 scheme 指向模型來源，engine 指定為 OLlama，minReplicas 設 1，resourceProfile 設 cpu:1。
這裡有兩個細節值得注意。url 的 scheme 決定由哪個引擎拉模型，這是把「模型從哪來」與「用什麼跑」綁在一起的做法。resourceProfile 則是一個抽象層，把資源需求對應到叢集實際的 GPU 或 CPU 類型，而不是讓你直接寫 nvidia.com/gpu。抽象換來的是可移植性，代價是你得確認自己的節點標籤落在 KubeAI 認得的 profile 裡。
README 另外提到，若用 Podman 跑 kind，預設記憶體上限是 2G，需要先 podman machine stop、podman machine rm，再以 podman machine init --memory 6144 --disk-size 120 重建並啟動。這是本機測試時最容易卡住的一步。
OpenAI 相容的邊界在哪裡
KubeAI 對外宣稱 OpenAI API 相容，README 列出的端點是 /v1/chat/completions、/v1/completions、/v1/embeddings、/v1/rerank、/v1/models 與 /v1/audio/transcriptions。
這份清單有兩個訊號。第一，涵蓋範圍比多數只做 chat 的推論閘道廣，rerank 與 audio transcriptions 都在裡面，對應到它支援的 cross-encoder 與 FasterWhisper 後端。第二，它沒有列出 /v1/images/generations 或 /v1/audio/speech，也沒有提到 tools、function calling 或 structured output 的相容程度。README 沒有說明這些，我不會替它推測。
實務上的意思是：如果你的用戶端只用 chat completions 與 embeddings，替換成本很低，換個 base URL 就好。如果你依賴 function calling、JSON schema 約束輸出或串流的細節行為，這些在 README 中沒有承諾，得自己對著實際部署驗證。相容性宣告的範圍，往往比「OpenAI Compatible」這四個字給人的印象窄。
零依賴是設計選擇，也是責任轉移
KubeAI 把「不依賴 Istio、Knative、Prometheus adapter」當成賣點。這個選擇在維運上是真的省事：少三個元件要升級、少三組 CRD 要協調、少三個地方會因為版本不匹配而壞掉。
但省下來的工作並沒有消失，只是換了位置。scale-from-zero 由 KubeAI 自己的 proxy 排隊機制處理，autoscaling 由它自己的邏輯決定，路由由它自己的策略決定。當這些行為不如預期時，你面對的是一個專案的實作，而不是 Istio 或 Knative 這種有大量文件與除錯經驗累積的系統。
README 提到它附了一份常見模型的 catalog，並依 GPU 類型預先配置，還說未來計畫建立模型最佳化流程。前半句是現在式，後半句是未來式，兩者不該混為一談。現階段你能拿到的是預先調好的 vLLM 旗標，不是自動調校。
還有一點：README 的 Adopters 表列出 Telescope、Google Cloud Distributed Edge、Lambda、Vultr、Arcee、Seeweb 等採用者，並說明是「known adopters」。這是使用者的存在證明，不是效能或穩定性的證明。判斷是否採用時，這張表能回答「有沒有人在正式環境跑」，不能回答「跑得好不好」。
什麼情況下它是錯的工具
KubeAI 管的是「模型伺服器 Pod」這一層。它不做跨節點的 GPU 拓撲感知排程，不處理多租戶的配額與公平性，也不提供推論圖或前後處理管線。如果你的需求是後者，這不是它的範圍。
具體的失效情境有三類。第一，流量沒有共享前綴。prefix-aware 路由要有效，前提是請求之間存在可重用的前綴（例如同一份 system prompt）。純隨機的短查詢下，這個策略的優勢會縮小，而 proxy 仍然在你的請求路徑上。第二，你已經有既有的推論平台。KServe 走的是以 Knative 為基礎的推論服務路徑，提供 predictor、transformer、explainer 這種推論圖抽象，並且有標準化的推論協定；Ray Serve 則是以 Python 為中心的部署模型，把多模型組合與業務邏輯寫在同一份程式裡。KubeAI 的差異在於它直接管 Pod、不引入這些依賴，並且把重點放在 KV cache 感知的路由。三者解決的問題有重疊，但切入點不同，硬要疊在一起只會多一層。第三，你需要精細的 GPU 共享。README 沒有提到 MIG、time-slicing 或 MPS 這類機制，resourceProfile 是抽象層而非共享機制。
還有一個尚未落地的限制：proxy 與 operator 目前同一個 deployment，README 自己連到 issue #430 說明獨立部署是待辦。如果你的架構要求控制面與資料面分離，現在做不到。
版本節奏與授權的實際含義
從 release 清單看，KubeAI 的節奏相當密。0.23.4 的兩個 chart（helm-chart-kubeai 與 helm-chart-models）在 2026 年 7 月 30 日同日發布，v0.23.3 則在 7 月 20 日。chart 與應用程式版本分開編號，安裝時要留意兩者的對應關係，因為 models chart 的 catalog 結構會跟著應用程式版本變動。
授權是 Apache-2.0。這對企業採用相對寬鬆，允許修改與再散布，也包含專利授權條款。需要注意的不是授權本身，而是它與後端引擎的關係：KubeAI 負責編排，實際跑推論的是 vLLM、Ollama、Infinity、FasterWhisper，這些引擎各自的授權與商用條件要分別確認。KubeAI 的 Apache-2.0 不會覆蓋它們。
升級成本主要落在兩處。一是 Model CRD 的欄位，例如 resourceProfile 與 url scheme 這類抽象若調整，既有 manifest 需要跟著改。二是 proxy 的路由行為，因為它直接影響延遲，升版後值得用實際流量對照一次 TTFT，而不是只看 Pod 是否 Running。README 沒有提供升級指南或相容性矩陣，這部分得靠 release notes 自行比對。
編輯結論
KubeAI 適合已經有 Kubernetes、想用單一 Operator 把 vLLM 或 Ollama 跑起來、而且願意接受它自帶 proxy 與 autoscaler 的團隊；如果你的瓶頸是跨節點的 GPU 排程與佇列公平性，或你已經在用 KServe、Ray Serve 這類推論平台，KubeAI 不會取代它們。採用前先確認三件事：你的 Kubernetes 版本與 Helm chart 0.23.4 是否對得上、你的 GPU 類型是否落在它預先配置的 catalog 裡、以及 prefix-aware 路由在單一 replica 或無共享前綴的流量下是否還有意義。這三項都通過，再從 deepseek-r1-1.5b-cpu 這種 CPU 模型開始試。
社群筆記