Katib：把超參數搜尋搬進 Kubernetes 的控制器
Automated Machine Learning on Kubernetes
秒懂
- 它是什麼？
- Katib 用 Kubernetes 自訂資源描述 AutoML 實驗，由控制器負責產生 Trial、跑訓練、回報指標。它解決的是排程與框架綁定問題，不是演算法問題；代價是你得先有一座能跑訓練工作的叢集。
- 適合誰用？
- 如果你的訓練工作本來就定義成 Kubernetes 自訂資源，而且團隊已經有 Kubeflow Training Operator、Argo Workflows 或 Tekton Pipelines 在跑，Katib 值得裝進現有叢集試一輪，因為它不需要你改寫訓練程式，只要換掉 Trial 範本。反過來說，單機或少數 GPU 工作站上的實驗、或只想在筆電上比較幾組 learning rate 的人，導入 Katib 只是把 kubectl 與 YAML 疊在原本就很短的迴圈上，Optuna 或 Ray Tune 直接寫在 Python 裡更省事。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Katib 要解的不是演算法，是排程與框架綁定
手動調超參數的實際痛點很少是「不知道用哪個演算法」。真正麻煩的是當你要試兩百組組合時，得自己寫迴圈、自己排隊等 GPU、自己在某個 trial 爆掉之後決定要不要重跑。Katib 把這一段接過去：你宣告一個 Experiment，裡面包含搜尋空間、演算法、以及一個 Trial Template，剩下的由控制器執行。
README 對它的定位寫得很清楚，Katib is the project which is agnostic to machine learning (ML) frameworks，而且 it can tune hyperparameters of applications written in any language of the users' choice。這句話的含義比表面更大：Katib 不要求你的訓練程式用 Python，也不要求它 import 任何 Katib 的東西。它只要求那個程式能被包成一個 Kubernetes 工作。
所以它的目標使用者是已經在叢集上跑訓練的團隊。如果你的訓練還在本機 Jupyter 裡，Katib 提供的價值會少很多，因為它最有用的部分（並行排程、工作生命週期、指標收集）都建立在 Kubernetes 之上。
Experiment、Suggestion、Trial 三層的分工
從 README 與官方文件的結構可以看出，Katib 的控制平面把一次 AutoML 拆成三種角色。Experiment 是你提交的宣告，描述搜尋空間與目標。Suggestion 負責演算法，決定下一組超參數是什麼。Trial 是一次實際的訓練執行，對應到一個 Kubernetes 工作。
資料流是單向的：Suggestion 產生參數組合，控制器依 Trial Template 把參數填進去並建立 Trial，Trial 跑完後由 metrics collector 取出目標指標，結果回到 Suggestion，Suggestion 再產生下一批。這個迴圈的關鍵在於指標怎麼被取出來。README 沒有在本文中說明 collector 的細節，但 Trial Template 的存在意味著你的訓練程式必須在某個可被讀取的位置輸出指標，否則搜尋會失去方向。
值得注意的是 Trial Template 的抽象層級。Katib 可以 perform training jobs using any Kubernetes Custom Resources，並對 Kubeflow Training Operator、Argo Workflows、Tekton Pipelines 提供 out of the box 支援。這代表 Trial 不必是單一 Pod，也可以是一個 TFJob、一個 Argo Workflow。對多節點分散式訓練來說，這個設計比把整個搜尋塞進一個 Python process 的框架更有彈性。
搜尋演算法清單與它背後的實作
README 列出的超參數調校演算法包括 Random Search、Grid Search、Bayesian Optimization、TPE、Multivariate TPE、CMA-ES、Sobol's Quasirandom Sequence、HyperBand 與 Population Based Training。神經架構搜尋則有 ENAS 與 DARTS。Early Stopping 目前只列出 Median Stop 一種。
這些演算法不是 Katib 自己從頭寫的。README 明講它支援 Goptuna、Hyperopt、Optuna、Scikit Optimize 這四個框架來執行上述演算法。也就是說 Katib 在演算法層更像是一層協調層，把既有的最佳化函式庫接到 Kubernetes 的工作生命週期上。這個架構決定的好處是演算法行為與上游一致，代價是當上游版本或介面變動時，Katib 需要跟著調整。
Early Stopping 只有 Median Stop 一項，是這份清單裡最明顯的缺口。Median Stop 的邏輯是比較同批 trial 的中位數表現，對訓練曲線前期不穩定、或各 trial 收斂速度差異很大的任務，判斷容易失準。文件也提供 Use custom algorithm in Katib 的指引，讓你自己接演算法，但那就變成你要維護的程式碼。
安裝：兩行指令，但前提在別處
控制平面的安裝用 kustomize 直接從 repo 拉。README 給的是：
kubectl apply -k "github.com/kubeflow/katib.git/manifests/v1beta1/installs/katib-standalone?ref=v0.17.0"
要跟最新變更則把 ref 換成 master。這裡有個細節值得注意：README 範例中的 ref 是 v0.17.0，而最近一次發布是 v0.19.0。範例沒有跟著更新，實務上你應該把 ref 改成自己驗證過的版本標籤，而不是照抄。
Python SDK 走 PyPI，指令是 pip install -U kubeflow-katib，README 說明它的用途是 simplify creation of hyperparameter tuning jobs for Data Scientists。SDK 是選配，不用它也能直接寫 YAML。
安裝真正的門檻不在這兩行，而在 README 指向的 prerequisites 頁面。Katib 是 Kubeflow 生態的一部分，Trial 要能跑起來，你的叢集得先有對應的 Training Operator 或工作引擎。standalone 安裝只裝控制平面，不會替你補上這些依賴。
什麼情況下 Katib 是錯的工具
第一個明確的邊界是規模。Katib 的價值來自並行執行大量 trial，如果你的 GPU 配額只夠同時跑一到兩個工作，Experiment 的 parallelTrialCount 只能設得很低，整個搜尋會退化成序列執行。這時候控制器、Suggestion、metrics collector 這些額外元件的維運成本，換不到對應的加速。
第二個邊界是迭代速度。在 Kubernetes 上建立一個 Trial 牽涉到排程、拉映像檔、啟動容器，每組超參數的固定開銷比在本地呼叫一次訓練函式高得多。當單次訓練只要幾十秒，這個開銷會主導整體時間。
第三個是除錯路徑變長。訓練失敗時，你要判斷是 Trial Template 填錯參數、是 metrics collector 沒取到值、還是 Suggestion 給出的組合本身有問題。這三層分散在不同元件裡，日誌不在同一個地方。相較之下，單一 Python 行程裡的搜尋迴圈出錯時，traceback 直接指向那一行。
還有一個容易被忽略的點：README 明說 Katib 對 ML 框架 agnostic，這同時意味著它對你的模型一無所知。它不會幫你檢查搜尋空間是否合理，也不會告訴你 objective 設錯了。搜尋空間的設計責任完全在使用者身上。
與 Optuna、Ray Tune 的差別在執行模型
Optuna 和 Ray Tune 同樣提供 TPE、CMA-ES、HyperBand 這類演算法，Katib 的演算法清單與它們高度重疊，因為底層本來就可能是同一批函式庫。真正的差別不在演算法，在誰負責執行訓練工作。
Optuna 的典型用法是在 Python 行程裡定義 objective 函式，study.optimize 呼叫它。訓練與搜尋在同一個 process 或同一組 worker 裡，狀態存在關聯式資料庫或 in-memory storage。要分散式執行，得自己處理 worker 的啟動與容錯。
Ray Tune 走另一條路，用 Ray 自己的 actor 模型管理 trial 的排程與資源分配，同樣不依賴 Kubernetes。
Katib 把這一層交給 Kubernetes。Trial 就是一個自訂資源，排程、重試、資源配額、多租戶隔離全部沿用叢集既有的機制。如果你的訓練工作本來就是 TFJob 或 Argo Workflow，Katib 幾乎不需要你新增執行層的程式碼；反過來說，如果你沒有叢集、也不需要叢集，Katib 等於是要你先建一座。這兩個世界的選擇標準是執行環境，不是演算法效能。
維護成本與授權
Katib 以 Apache-2.0 授權發布，這是寬鬆授權，允許修改與再散布，也包含專利授權條款。實際使用前仍應就你的散布方式與內部合規要求確認義務，這裡不構成法律意見。
版本節奏可以從發布紀錄觀察：v0.18.0 在 2025 年 3 月底，v0.19.0 在 2025 年 10 月底，中間隔了約七個月，另外有 v0.18.0-rc.0 這種候選版本。README 的安裝範例還停在 v0.17.0，說明文件更新落後於發布。升級時你要自己確認 manifests 路徑與 CRD 版本是否變動，不能只依賴 README 的指令。
維運面上，Katib 的控制平面本身是幾個 Deployment 與 CRD，負擔不算重。真正會隨時間累積的是 Trial Template。你的訓練映像檔、Training Operator 版本、指標輸出路徑，任何一項變動都可能讓 Experiment 靜默地跑出無效結果。這是採用 Katib 之後需要長期維護的部分，也是比較少被寫進評估清單的一項。
編輯結論
如果你的訓練工作本來就定義成 Kubernetes 自訂資源，而且團隊已經有 Kubeflow Training Operator、Argo Workflows 或 Tekton Pipelines 在跑，Katib 值得裝進現有叢集試一輪，因為它不需要你改寫訓練程式，只要換掉 Trial 範本。反過來說，單機或少數 GPU 工作站上的實驗、或只想在筆電上比較幾組 learning rate 的人，導入 Katib 只是把 kubectl 與 YAML 疊在原本就很短的迴圈上，Optuna 或 Ray Tune 直接寫在 Python 裡更省事。決定採用前先確認三件事：你的 Trial Template 是否對得上現有的 Training Operator 或 Argo 範本、Experiment 的 maxTrialCount 與 parallelTrialCount 是否符合你的 GPU 配額、以及 metrics collector 能不能從你的訓練輸出裡取到 objective 值。最後一項最常出問題，因為它決定了整個搜尋是否只是在盲跑。
社群筆記