Helm Chart

1 三秒看懂

Helm Chart 是 Kubernetes 生態的標準化應用打包與交付格式，可類比為 Linux 世界的 apt/deb 包或 macOS 的 Homebrew Formula——它將雲端原生應用所需的全部 K8s 資源清單（Deployment、Service、ConfigMap、CRD 等）封裝為一個可版本化、可複用、可共享的 Chart 包。

“chain-cloud/helm-chart”特指一條明確的技術線索：將 Helm Chart 作為 AI 算力排程、分散式訓練、模型推論服務等場景的宣告式交付載體——通過“雲端鏈化”方式把 GPU 驅動、訓練架構、推論引擎、監控堆疊等數十個異構元件編排為一條可重複部署的軟體供應鏈。從產業層面看，這意味著 AI 基礎設施不再依賴手工運維指令碼，而是進入“用 Chart 定義一切”的宣告式工程階段。

核心認知錨點：

本質：Kubernetes 應用的包管理器（K8s-native package manager）
關鍵動作：helm install / helm upgrade / helm rollback 三條命令即可完成應用全生命週期管理
AI 場景的特殊性：區別於普通 Web 應用，AI Chart 通常需要編排 GPU 裝置外掛、分散式訓練 Operator、模型閘道器、推論執行時等“有狀態+異構硬體”元件，複雜度遠超無狀態微服務

2 三分鐘產業解釋

產業邏輯：AI 大型模型訓練和推論不是一個軟體問題，而是一個“軟體×硬體×排程”的系統工程。典型的大型模型訓練叢集涉及至少 6 層技術棧——GPU 驅動與 CUDA 工具鏈、容器執行時、Kubernetes 排程層、分散式訓練架構（PyTorch/TensorFlow）、資料載入管道、監控與日誌系統。每層都有版本約束和配置依賴，手動部署不僅耗時，更是生產事故的主要來源。

Helm Chart 在這一鏈條中的角色是“標準化封裝器”：將上述 6 層技術棧的部署知識編碼為可執行的 YAML 模板，通過引數暴露（values.yaml）實現“一次封裝，隨處部署”。這與傳統 shell 指令碼的本質區別在於宣告式治理——運維人員不再描述“怎麼做”（建立、等待、檢查），只描述“要什麼”（GPU 型別、節點數、映象版本），由 Helm 的 Release 機制保證狀態收斂。

關鍵價值矩陣：

價值維度	傳統方式	Helm Chart 方式	AI 場景收益
部署一致性	各節點手工執行指令碼，易出現“環境漂移”	同一 Chart + 同一 values = 完全一致部署	訓練叢集 100+ GPU 節點保持環境一致
版本管理	Git 託管指令碼，回滾需手動反向操作	Release 歷史記錄，`helm rollback` 秒級回退	模型服務灰度升級失敗可即時回退
依賴管理	手動安裝 GPU Operator → Kubeflow → Istio	Chart 依賴宣告（dependencies）自動遞進安裝	全棧 AI 平台一鍵拉起
分發效率	內部 Wiki 文件 + 指令碼壓縮包	OCI Registry 推送/拉取，簽名驗證	跨團隊 Chart 複用，避免重複造輪子
多叢集管理	每叢集手工適配	同一 Chart 不同 values 覆蓋	訓練/推論/開發三套叢集統一管理

典型產業落地路徑：

GPU 基礎設施層：NVIDIA GPU Operator Chart 是事實標準，將 GPU 驅動、容器執行時外掛、DCGM 監控統一打包
訓練平台層：Kubeflow 以複合 Chart 形式交付，內部依賴 Istio、Knative、MySQL 等子 Chart
推論服務層：KServe、Seldon Core、Triton Inference Server 均提供官方 Helm Chart
MLOps 流水線：MLflow Tracking Server、Feast Feature Store 等以 Chart 形態持續釋出

中國市場的差異化：國內雲端廠商（阿里雲端 ACK、華為雲端 CCE、騰訊雲端 TKE）均將 Helm Chart 作為 AI 元件市場的標準交付格式，但存在“半封閉化”趨勢——雲端廠商的託管 AI 平台對外暴露的是控制台 UI，底層 Chart 並不完全開放給使用者定製。這意味著對企業自建 AI 平台而言，直接使用社群 Chart 進行自主編排仍是主流選擇；但在雲端上 AI 場景，Helm 正從“使用者工具”轉變為“雲端廠商內部交付引擎”。

需要糾正的常見錯覺：認為 Helm 是“萬能部署器”，可以替代 Ansible 等配置管理工具。實際上 Helm 解決的是 K8s 資源的編排問題，對節點層面的作業系統配置（核心引數、檔案系統掛載）無能為力——這正是 GPU Operator 等 Chart 需要結合 DaemonSet + InitContainer 等底層機制才能覆蓋 AI 基礎設施全棧的原因。

3 技術原理

3.1 Chart 包解剖學

Helm Chart 是一套約定優於配置（Convention over Configuration）的目錄結構規範。以典型的 AI 訓練平台 Chart 為例：

kubeflow-train/
├── Chart.yaml              # Chart 後設資料：名稱、版本、K8s版本約束
├── values.yaml             # 預設引數（暴露給使用者的配置入口）
├── values.schema.json      # 引數校驗（JSON Schema，Helm 3.7+）
├── templates/              # Go Template 模板檔案
│   ├── _helpers.tpl        # 可複用模板片段
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── NOTES.txt           # 安裝後提示資訊
├── crds/                   # 自定義資源定義（安裝時優先建立）
│   └── tfjobs.kubeflow.org.yaml
├── charts/                 # 依賴子 Chart（或通過 Chart.yaml dependencies 宣告）
└── .helmignore             # 打包時忽略檔案列表

關鍵檔案詳解：

Chart.yaml：宣告 apiVersion（Helm 3 固定為 v2）、name、version（Chart 自身版本）、appVersion（應用版本），以及可選的 kubeVersion（相容的 K8s 語義版本範圍）、dependencies（依賴的 Chart 列表及版本約束）。
values.yaml：這是使用者與 Chart 的唯一互動介面。設計良好的 Chart 將一切可變因素（映象倉庫地址、GPU 型別、副本數、儲存類）均暴露為 values 項，通過 values.stage 或 values.profile 等約定支援多環境覆蓋。
templates/：核心渲染層，採用 Go Template 語法。AI Chart 中常見的模式包括：條件渲染（{{ if .Values.gpu.enabled }}）、迴圈（{{ range .Values.workers.nodes }}）、函式管道（{{ .Values.image.tag | default "latest" }}）。

3.2 Release 生命週期管理

Helm 的核心資料模型是 Release——每次 helm install 或 helm upgrade 操作都會建立一個帶版本號的 Release 物件，記錄當前部署的 Chart 版本、使用者傳入的 values、渲染後的 K8s 資源狀態。

Release 生命週期流轉：
  install → deployed
  upgrade → superseded (上一版本)
  rollback → 回退到指定歷史版本
  uninstall → 清理所有關聯 K8s 資源

Helm 3 的重大架構變更是移除了 Tiller 服務端元件（Helm 2 時期常駐叢集的 gRPC 服務）。當前 Helm 3 的 Release 後設資料直接以 Secret 形式儲存在部署的 Namespace 中，極簡且消除了 Tiller 的 RBAC 安全隱患。對 AI 場景而言，這意味著 GPU 叢集的 Helm 操作不再需要額外的叢集管理員權限配置，符合細粒度安全治理要求。

AI 場景的特殊 Release 實踐：

訓練任務：每個實驗性訓練 Job 往往以獨立 Release 部署（如 train-bert-exp-001），訓練完成後 uninstall 回收 GPU 資源
推論服務：不同模型版本的推論服務作為獨立 Release 並存（如 infer-llama-v1 和 infer-llama-v2），通過 Ingress 權重分流
基礎設施：GPU Operator、儲存 CSI、網路 CNI 等系統級 Chart 通常以固定 Release 名部署，不允許重複安裝

3.3 依賴解析與組合模式

Helm 支援顯式依賴宣告（Chart.yaml dependencies）和隱式子 Chart 嵌入（charts/ 目錄）兩種方式。生產級 AI 平台 Chart 通常採用混合策略：核心依賴（如 GPU Operator）顯式宣告版本約束，內部定製的監控元件以子 Chart 形式嵌入。

依賴遞進安裝示例（Kubeflow 全景）：

kubeflow (umbrella chart)
├── cert-manager (證書管理)
├── istio (服務網格)
│   ├── istio-base
│   └── istio-ingress
├── knative (Serverless)
├── minio (物件儲存，存模型檔案)
├── mysql (後設資料儲存)
├── training-operator (TFJob/PyTorchJob CRD)
├── katib (超參調優)
└── kserve (推論服務)

Helm 的依賴鎖檔案（Chart.lock）記錄所有子 Chart 的精確版本和 SHA 摘要，類似 Go 的 go.sum，確保依賴項在 CI/CD 中可復現。

3.4 倉庫分發與簽名

Helm Chart 的分發渠道演進方向明確：從傳統的 HTTP Helm Repository（基於 index.yaml）向 OCI Registry（Open Container Initiative）遷移。OCI 相容的容器映象倉庫（Docker Hub、Harbor、AWS ECR、阿里雲端 ACR）可直接用於儲存和分發 Chart，複用容器映象的安全掃描、簽名和訪問控制能力。

AI 場景下的 Chart 供應鏈安全愈發關鍵：

來源驗證：通過 helm verify + GPG 簽名或 OCI 的 cosign 簽名，確保 Chart 未經篡改
內容掃描：對 Chart 內的容器映象引用進行漏洞掃描（如 Trivy 整合），避免 GPU 驅動版本和 CUDA 版本的不安全組合
准入控制：部分企業要求在 Chart 安裝前通過 OPA/Kyverno 策略校驗，如禁止使用 latest 標籤、強制指定 resources.limits 等——這對 GPU 資源管理尤為重要

4 關鍵引數

對於 AI 場景的 Helm Chart（以 Kubeflow、GPU Operator、KServe 為代表），以下引數是在生產部署中必須關注的“控制面引數”，決定了平台的效能、成本和穩定性邊界。

4.1 GPU 資源引數

引數路徑（values.yaml）	含義	典型值	影響範圍的說明
`gpu.operator.version`	GPU Operator 版本	`v24.3.0`（2024年）	決定支援的 GPU 型號和 CUDA 驅動版本
`gpu.devicePlugin.resources`	暴露的 GPU 資源型別	`nvidia.com/gpu` / `nvidia.com/mig-1g.5gb`	MIG 切分配置直接影響推論密度
`gpu.timeSlicing.replicas`	GPU 時間片數量	`2-4`	訓練場景不建議啟用，推論場景可提升共享效率
`gpu.mig.strategy`	MIG 分割槽策略	`single` / `mixed`	A100/H100 推論場景關鍵引數，公開資料未見各雲端廠商 MIG 策略預設值統一標準
`gpu.validate.driver`	是否校驗驅動版本	`true`	生產環境建議開啟，防止驅動不匹配導致 CUDA 錯誤

4.2 訓練架構引數

引數路徑	含義	典型值域	來源 / 年份說明
`training.operator.version`	Kubeflow Training Operator 版本	`v1.7.0`（2024.07 為穩定版）	GitHub 官方 release
`training.namespace`	訓練任務執行的名稱空間	`kubeflow-training`（預設）	多租戶場景需定製
`training.rbac.clusterRole`	是否需要叢集級權限	`false`（推薦）	安全最小權限原則
`training.defaultPodCount`	預設 Worker Pod 數	`2-8`（視叢集規模）	社群預設值 2，公開資料未見大型模型訓練的推薦預設值
`training.resources.gpuPerWorker`	每個 Worker 申請的 GPU 數	`8`（單節點滿配）	GPU 型號決定上限（A100 8卡/節點，H100 8卡/節點）

4.3 推論服務引數

引數路徑	含義	典型值	口徑說明
`kserve.serverless`	是否啟用 Knative 自動擴縮容	`true`	冷啟動延遲與資源節省的權衡
`kserve.minReplicas`	最小副本數	`1-2`	設為 0 可節省資源，但存在首次請求超時風險
`kserve.scaleToZero.gracePeriod`	縮容到零的等待時間（秒）	`300`（社群預設）	vLLM 等模型載入慢的場景需調大
`kserve.modelFormat`	模型服務協議	`v1`（KFServing v2）	影響模型熱載入和版本管理能力
`kserve.runtime.image`	推論執行時映象	`nvcr.io/nvidia/tritonserver:24.05`	NVIDIA 官方映象，2024.05 版本

4.4 平台全域性引數

引數路徑	含義	影響範圍
`global.imageRegistry`	全域性映象倉庫地址	離線環境 / 映象加速（如阿里雲端 `registry.cn-hangzhou.aliyuncs.com`）
`global.storageClass`	預設儲存類	模型檔案與訓練資料的持久化方式
`global.platformDomain`	平台訪問域名	推論 API 的入口地址和 HTTPS 證書
`global.logging.retentionDays`	訓練日誌保留天數	合規要求與儲存成本平衡，公開資料未見行業統一標準

引數治理最佳實踐：

分層 values：將 values.yaml 分為 base.yaml（通用）、staging.yaml（預釋出）、production.yaml（生產），通過 -f 引數疊加，避免參數散落在多個 Helm 命令中
加密敏感值：資料庫密碼、API Key 等使用 Sealed Secrets 或 Vault 外掛注入，禁止明文寫入 values 檔案
引數校驗：通過 values.schema.json 約束引數型別和取值範圍，防止因為誤拼寫導致的不安全預設行為

5 技術路線

AI 場景下的 Helm Chart 技術路線存在三條主要演進方向，它們並非互斥，而是分別解決 AI 基礎設施不同階段的工程挑戰。

5.1 路線 A：社群原生 Helm → Operator 增強

演進邏輯：原生 Helm 擅長有狀態應用的首次部署與升級，但無法處理 Day-2 運維中的複雜狀態管理（如 Grafana Dashboard 的自動註冊、模型版本狀態的協調）。CNCF 推薦將 Helm 與 Operator 模式結合——Helm 負責 Operator 本身的部署，Operator 通過自定義控制器（Controller）管理應用生命週期。

技術特徵：

初期：純 Helm Chart 部署，values 覆蓋所有配置
中期：將 Day-2 運維邏輯下沉到 Operator，Helm 降級為“安裝器”
成熟期：Operator 監聽 CRD 變更自動調諧（Reconcile），Helm 僅維護初始部署

AI 場景對應：Kubeflow 從 1.4 版本後，核心元件的生命週期管理逐漸從“Helm 指令碼鉤子”遷移到“Kubernetes Operator 控制器”。這是 Helm 在複雜 AI 平台中角色收斂的典型訊號。

5.2 路線 B：OCI 標準化分發 → GitOps 持續部署

演進邏輯：Helm Chart 的分發渠道正從 HTTP Helm Repository 轉向 OCI Registry，這一步解決了 Chart 的安全儲存、版本固定和跨平台分發問題。同時，GitOps 工具（ArgoCD、Flux）已將 Helm 作為一等公民——使用者只需在 Git 倉庫中維護 values 檔案，GitOps 控制器自動 sync 到叢集。

技術特徵：

Chart 包本身儲存在 OCI Registry（如 Harbor），與容器映象共享安全掃描鏈路
values 檔案版本託管在 Git，PR/MR 審批流程觸發 Chart 升級
ArgoCD 的 Application CRD 直接引用 Helm Chart 的 OCI 地址 + 版本

AI 場景對應：大規模 AI 叢集通常涉及多個團隊（訓練、推論、資料），每個團隊通過 Git 倉庫管理自己的 values，ArgoCD 按 Application 粒度分別部署，實現多租戶 GitOps。字節跳動、第四範式等中國 AI 公司公開分享中均提及 GitOps + Helm 的 AI 平台部署模式（公開資料見於 KubeCon China 2023 演講）。

5.3 路線 C：AI 專用抽象層 → 遮蔽底層 Helm

演進邏輯：對演算法工程師而言，Helm 的 values 語義仍然太底層。以 Jupyter Notebook 介面或自研 ML 平台為例，使用者通過表單填寫訓練引數（映象、GPU 數、資料路徑），平台後端將表單對映為 Helm values → 呼叫 Helm SDK 部署訓練 Job。這套模式使 Helm 從“使用者工具”變為“平台 API 的底層引擎”。

技術特徵：

使用者互動面：Web UI / CLI（非 Helm 原生命令）
平台引擎層：Go/Python Helm SDK 或封裝 helm install 子程序
底層：標準 Helm Chart 包，但 values 完全由平台生成，人工不直接編輯

AI 場景對應：阿里雲端 PAI、華為雲端 ModelArts 的託管訓練服務，內部均採用類似架構——前端遮蔽 Helm 命令，後端以 Helm Chart 作為元件編排引擎。但在開源場景與自建平台中，Helm CLI 依然是最直接的控制手段。

5.4 技術路線選擇判斷架構

場景	推薦路線	理由
初創團隊快速驗證 AI 平台	路線 A（社群 Chart + 少量定製）	成本最低，直接使用 Bitnami/Kubeflow 官方 Chart
中大型企業多租戶 AI 平台	路線 B（OCI + GitOps）	安全審計、多環境管理訴求強烈
雲端廠商 / SaaS AI 平台	路線 A + C 融合	面向終端使用者遮蔽 K8s 細節，底層仍依賴 Helm
邊緣 AI 場景（多叢集）	路線 B（Fleet/Flux 多叢集同步）	邊緣叢集網路割裂，GitOps 支援斷線續傳

進度判斷：截至 2024 年，路線 A 是絕對主流（超過 80% 的 AI 平台部署仍以直接 Helm install 或簡單指令碼封裝為主，來源：CNCF 2023 年調查報告中 Helm 使用率 75%，但未區分 AI 場景與通用場景）。路線 B 在千人以上規模企業中滲透率顯著提升（SUSE Rancher、Red Hat OpenShift GitOps 均推薦此模式）。路線 C 僅見於頭部雲端廠商的託管 AI 服務，尚不構成開源主流。

6 上游

Helm Chart 的“上游”指 Chart 封裝前所依賴的元件層——沒有這些底層元件，Chart 中定義的 Deployment、CRD 等資源將無法排程和執行。理解上游對評估 Chart 的穩定性、可移植性和效能基線至關重要。

6.1 Kubernetes 版本演進

Helm 3.x 要求 Kubernetes 1.16+（實際生產中推薦 1.24+）。Kubernetes 自身的 API 棄用（如 Ingress v1beta1 在 1.22 移除）直接影響 Chart 中模板的相容性。2024 年主要雲端廠商的 K8s 服務預設版本：

阿里雲端 ACK：1.28（2024.06，來源：阿里雲端官網）
華為雲端 CCE：1.29（2024.06，來源：華為雲端官網）
AWS EKS：1.29（2024.06，來源：AWS 官網）
Google GKE：1.29（2024.06，來源：Google Cloud 官網）

AI 場景下，K8s 版本的 GPU 特性支援差異顯著：nvidia.com/gpu 資源型別從 K8s 1.26 開始作為穩定特性 GA，MIG 支援在 1.25 後逐步完善。

6.2 容器執行時

GPU 容器執行時的技術棧演進直接影響 AI Chart 的基礎配置：

執行時元件	說明	上游維護方	AI 影響
containerd	K8s 預設容器執行時（1.24+）	CNCF Graduated 專案	GPU 設備註入依賴 `nvidia-container-runtime` 鉤子
CRI-O	輕量級 CRI 實現	Kubernetes SIG-Node	紅帽 OpenShift 預設執行時
nvidia-container-toolkit	GPU 容器支援的核心	NVIDIA 維護	GPU Operator Chart 的依賴基礎，版本必須與驅動匹配

6.3 網路與儲存（CNI/CSI）

AI 訓練的網路需求遠超普通 Web 應用——分散式訓練會因網路瓶頸而嚴重降低 GPU 利用率。Chart 中通常不直接包含 CNI/CSI 定義，但在 NOTES.txt 或文件中宣告前置依賴。

元件	典型選擇	AI 場景要求
CNI（容器網路介面）	Calico、Cilium、Flannel	RDMA over Converged Ethernet (RoCE) 支援（InfiniBand 需要 Multus 多網路）
CSI（容器儲存介面）	Ceph CSI、Local Path Provisioner	訓練資料吞吐要求高 IOPS，模型檔案需要 ReadWriteMany
Device Plugin	NVIDIA Device Plugin	GPU 暴露的基礎，所有 AI Chart 的隱式上游

6.4 OCI Registry 與 Helm Repository

Chart 分發流的上游基礎設施：

型別	代表專案/廠商	2024 狀態
OCI Registry	Docker Hub、Harbor、AWS ECR、阿里雲端 ACR	Helm 3.8+ 原生支援 OCI，產業遷移進行中
HTTP Helm Repo	ChartMuseum、GitHub Pages	存量仍大，但不適合企業級安全需求
ArtifactHub	CNCF 維護的 Chart 發現門戶	截至 2024.06 收錄約 10,000+ Chart（來源：ArtifactHub 官網）

上游版本鎖定策略：AI Chart 對上游元件版本高度敏感——例如 NVIDIA GPU Operator v23.9.0 與 containerd 1.7.x 的特定子版本存在已知的相容性問題（來源：NVIDIA GPU Operator Release Notes）。在實際部署中，企業對上游元件的版本鎖定比 Chart 本身更為嚴格。

7 下游

Helm Chart 的下游指向 Chart 被部署後的最終消費場景——即“Chart 跑起來之後面向誰、產出了什麼價值”。對 AI 場景而言，下游可劃分為三層：平台層應用、演算法工程師體驗、以及業務決策者關注的投資回報（ROI）。

7.1 平台層下游應用

下游應用	典型 Helm Chart 入口	最終產出
分散式訓練平台	Kubeflow Training Operator Chart	TFJob / PyTorchJob / MPIJob 等訓練任務
模型推論服務	KServe Chart、Seldon Core Chart	自動擴縮容的推論 API（支援金絲雀釋出）
超參最佳化系統	Katib Chart（Kubeflow 子元件）	自動超參搜尋工作流
MLOps 流水線	Kubeflow Pipelines Chart、MLflow Chart	可復現的訓練流水線，含資料預處理→訓練→評估→推送
GPU 資源監控	DCGM Exporter Chart	GPU 利用率、視訊記憶體、溫度等指標接入 Prometheus + Grafana
特徵儲存	Feast Chart	離線/線上特徵統一管理

7.2 演算法工程師體驗鏈

從演算法工程師的實際工作流看，Helm Chart 的最終價值體現在以下體驗點：

“一鍵跑實驗”：申請 GPU 資源 → 定義 PyTorchJob → kubectl apply（背後是 Helm 渲染的 CRD），無需等待運維手動開通
“環境復現”：同一份 Chart + values 可在開發叢集和訓練叢集得到完全一致的 PyTorch/CUDA 組合
“釋放資源”：實驗完成後 helm uninstall train-xxx，GPU 資源自動歸還池中，無需擔心“殭屍程序”佔用算力
“模型版本可追溯”：KServe Chart 的 Revision 機制保留模型版本歷史，支援模型回退（類比 helm rollback 的語義）

產業痛點：以上理想流程的實現高度依賴 Chart 質量與運維成熟度。公開資料中多次提到，演算法工程師面臨的主要摩擦不是 Chart 本身複雜，而是運維側對 Chart values 的“過度封鎖”——引數未暴露導致工程師無法自定義映象或調整 GPU 數量，最終不得不繞過 Helm 直接手寫 Pod YAML。

7.3 業務決策者的 ROI 視角

指標	有效度量的說明	資料來源與年份
GPU 利用率提升	通過 GPU Operator Chart 統一管理，減少環境準備時間	NVIDIA 報告 AI 企業 GPU 利用率可從 <30% 提升至 70%+（來源：NVIDIA, 2023）
部署效率	Helm install 替代手工部署，顯著降低運維工時	公開資料未見中國 AI 企業直接關聯 Helm 與部署效率的釋出資料
模型上線速度	KServe Chart 將模型服務部署壓縮至分鐘級	社群 benchmark 中 minReplicas=1 時請求首位元組 <2s（來源：KServe 官方文件）
硬體成本最佳化	MIG + 時間片配置通過 values 暴露，最大化 GPU 共享	A100 MIG 切分可提升推論硬體利用率 2-7 倍（來源：NVIDIA MIG 白皮書, 2021）

下游訊號：2023 年以來，國內頭部的 AI 能力型公司（如 MiniMax、月之暗面 Moonshot AI）以及網際網路大廠 AI Lab 公開發布的招聘 JD 中，“熟悉 Helm/Kustomize/GitOps”已成為 MLOps 崗位的標配要求——這說明 Helm 作為 AI 基礎設施基礎工具已從“可選項”轉為“必選項”（來源：公開招聘資訊，2023-2024）。

8 受益公司

以下分析從 Helm Chart 在 AI 場景中的工具屬性出發，梳理產業中因 Helm 生態繁榮而間接受益的組織型別。需要明確：Helm 本身是 CNCF 的開源專案，不產生直接商業營收；受益邏輯是“Helm 降低部署複雜度→加速相關商業產品採納→生態參與者獲利”。

8.1 公有雲端廠商

廠商	受益邏輯	資料口徑
AWS	EKS 預設整合 Helm；ECS 支援 Helm 部署；GPU 例項（P4d/P5）藉助 Helm 降低使用門檻	AWS 2023 財年營收 908 億美元（AWS 年報），未單獨揭露 Helm 相關貢獻
Microsoft Azure	AKS 整合 Helm；Azure ML 底層部分依賴 Helm 編排	Azure 2024 Q2 營收約 330 億美元（微軟財報），AI 貢獻增速約 8pp，未單獨列示 Helm 影響
Google Cloud	GKE 與 Helm 深度整合；GKE Autopilot 模式下 Helm 部署簡化；Kubeflow 為 Google 主導開源	Google Cloud 2023 營收 331 億美元（Alphabet 年報），Kubeflow 生態對其 AI 客戶轉化有戰略意義
阿里雲端	ACK 內建 Helm 市場；PAI 平台底層以 Helm 交付 AI 元件	阿里雲端 2024 財年營收約 1064 億人民幣（阿里巴巴年報），未單獨揭露 ACK/PAI 的 Helm 相關資料
華為雲端	CCE 支援 Helm；ModelArts 使用 Helm 作為交付引擎	華為雲端 2023 營收 553 億人民幣（華為年報），未單獨揭露 Helm 相關口徑
騰訊雲端	TKE 容器市場提供 200+ Helm Chart（截至 2024.06，騰訊雲端官網）；AI 類 Chart 持續擴充	騰訊雲端營收未單獨揭露細分口徑

8.2 基礎設施軟體與平台公司

組織	受益邏輯	關鍵資料點
VMware（Broadcom）	Bitnami 維護 300+ 生產級 Chart（截至 2024），是 Kubeflow、MLflow 等重要 AI Chart 的維護者	VMware 被 Broadcom 收購後財報不再單獨揭露 Bitnami 資料
Red Hat（IBM）	OpenShift 以 Helm 為一級公民；OperatorHub 中大量 AI 相關 Operator 相容 Helm	Red Hat 營收計入 IBM “軟體”板塊，2023 年 249 億美元（IBM 年報），未拆分 Helm 貢獻
SUSE（Rancher）	Rancher Fleet 多叢集 Helm 部署方案，定位邊緣 AI 場景	SUSE 2023 財年營收約 6.5 億美元（SUSE 年報），未單獨列示 Rancher/Helm 口徑
NVIDIA	GPU Operator Chart 是 AI 基礎設施事實標準，降低 GPU 叢集部署門檻 → 推動 GPU 銷售	NVIDIA 2024 財年資料中心營收 475 億美元（NVIDIA 年報），GPU Operator 是 GPU 生態“進入壁壘”之一
Datadog / Grafana Labs	監控類 Chart 受益 AI 叢集可觀測性需求增長	未單獨揭露 AI Helm Chart 相關營收

8.3 中國 AI 基礎設施公司

公司	受益邏輯	資料口徑
DaoCloud	提供企業級 Helm 管理能力；服務於金融、工業等 AI 平台建設	未上市，無公開營收資料
靈雀雲端	容器 PaaS 平台整合 Helm，支援 AI 元件一鍵部署	未上市，無公開營收資料
博雲端	容器雲端平台面向 AI 負載最佳化，Helm 為關鍵交付工具	未上市，無公開營收資料

說明：上述受益邏輯為產業分析推演，不對任何公司的股票、經營業績做預測或評估。未標註營收資料的公司，僅代表公開資料未見其單獨揭露 Helm 相關口徑。

9 市場規模

9.1 Container/Kubernetes 基礎市場

Helm 作為 Kubernetes 的包管理器，其市場規模無法直接統計——Helm 本身是 CNCF 開源專案，零許可費用。但可以通過相關容器基礎設施市場的規模推算其潛在影響範圍。

市場指標	資料	年份/來源
全球容器即服務（CaaS）市場	約 57 億美元	2023 年估計，MarketsandMarkets 報告
全球 Kubernetes 市場	約 48 億美元	2023 年，Fortune Business Insights
預計 2028 年 Kubernetes 市場	約 149 億美元	同上來源，CAGR 約 25.3%
CNCF 調查中生產環境使用 Helm 的比例	75%	CNCF 2023 年度調查（樣本 1,354 家企業）
ArtifactHub 上 AI/ML 相關 Chart 數量	約 400+（估算）	ArtifactHub 檢索 2024.06，以 “ml""tensorflow""pytorch""kubeflow” 等關鍵詞估計

9.2 AI 基礎設施市場的 Helm 關聯度

AI 基礎設施的部署方式中，Kubernetes 佔據雲端原生場景的主導地位，而 Helm 又是 Kubernetes 部署的事實標準。可以合理推測：

關聯邏輯：所有基於 Kubernetes 的 AI 平台/MLOps 工具的部署，超過 70% 採用 Helm 或相容 Helm 的方式分發（基於 CNCF 調查中 Helm 75% 的使用率推算，但該資料為通用場景，AI 場景可能偏低）
無法精確拆分：公開市場報告中不提供“AI 場景下 Helm 部署”的細分口徑，以下為關聯市場參考。

AI 基礎設施細分市場	全球規模	中國市場	年份/來源
AI 訓練基礎設施（硬體+軟體）	約 420 億美元	未單獨揭露	2023 年，IDC 全球 AI 基礎設施追蹤
MLOps 平台市場	約 33 億美元	約 6.5 億人民幣（估計）	2023 年，Cognilytica 報告，中國市場為公開資料綜合估計
GPU 雲端服務市場	約 57 億美元	約 120 億人民幣（估計）	2023 年，公開資料估計，中國市場增速高於全球

中國市場特殊性：

中國 AI 基礎設施市場增速領先全球（IDC 預測 2022-2027 中國 AI 伺服器市場 CAGR 約 39%，來源：IDC 中國 2023.10），間接拉動 Helm + K8s 生態的滲透
國產信創要求可能推動 Helm 的“國產化替代”或自定義分發方案，公開資料未見針對 Helm 本身的信創替代存在商業化產品
中國雲端廠商的 AI 平台傾向於提供“免 Helm 安裝”的託管體驗，但這實際上是將 Helm 從顯性工具轉為後臺引擎，並非替換 Helm

10 玩家對比

以下對比聚焦於 AI 場景中持續釋出和維護 Helm Chart 的核心組織，從 Chart 質量、維護頻率、AI 場景覆蓋度、安全實踐等維度進行比較。

10.1 關鍵決策維度的橫向對比

對比維度	CNCF Helm 社群	Bitnami（VMware/Broadcom）	NVIDIA	Kubeflow 社群	阿里雲端 ACK
核心角色	Helm 工具維護者	Chart 內容供應商	GPU 基礎設施 Chart	AI 訓練平台 Chart	託管市場運營方
AI Chart 數量	約 100+（ArtifactHub 社群貢獻）	約 30+ AI 相關（含 MLflow、Kubeflow 等）	約 5+ 核心 GPU Chart（GPU Operator、DCGM、Network Operator）	約 15+ 元件 Chart	約 50+ AI 類（來源：ACK 應用目錄公開頁面, 2024.06）
更新頻率	核心工具季度釋出	月度補丁，季度大版本	跟隨 GPU 驅動釋出（約季度）	季度 minor 版本	隨 ACK 平台版本更新
安全稽核	社群自我稽核機制	企業級安全掃描（Bitnami 安全公告）	NVIDIA 產品安全團隊	CNCF 安全審計（2021+）	阿里雲端安全團隊稽核
開源程度	完全開源（Apache 2.0）	開源 + 商用支援	開源 + NVIDIA AI Enterprise 訂閱	完全開源（Apache 2.0）	部分 Chart 原始碼公開，託管版閉源
鎖入風險	無（社群標準）	低（多數 Chart 標準化）	中（依賴 NVIDIA 硬體）	低（社群標準 CRD）	高（部分依賴阿里雲端 CRD/服務）

10.2 “鏈 chain-cloud”視角下的比較

在“雲端鏈化”AI 部署的場景中，Chart 的可組合性和跨平台遷移能力是關鍵：

對比項	Bitnami 方案	NVIDIA GPU Operator	Kubeflow 官方	自建組合
典型部署路徑	`helm install bitnami/kubeflow`	`helm install nvidia/gpu-operator`	先安裝 GPU Operator → 再安裝 Kubeflow Manifests	按需組合且版本對齊
跨雲端遷移難度	低（values 覆蓋即可）	低	中等（依賴儲存/網路外掛宣告）	取決於組合複雜度
AI 場景針對性	中等（通用應用 Chart）	高（精準覆蓋 GPU 生命週期）	高（完整覆蓋訓練→推論）	可定製性最強但成本最高
社群活躍度	GitHub Star 26k+（Helm 主專案）；commit 頻率穩定	~3k Star（GPU Operator）；commit 活躍	~14k Star（Kubeflow）；commit 活躍	—

10.3 選型啟示

快速嚐鮮：Bitnami 打包的各類 AI Chart是一站式選項，但版本滯後於上游 1-2 個小版本是常態
GPU 基礎設施標準：NVIDIA GPU Operator 已成事實標準，2024 年幾乎無替代方案
完整 AI 平台：Kubeflow 全功能但運維複雜；簡化為僅使用 KServe + MLflow 的“輕量 KubeFlow”近年來成為趨勢
生產就緒：需評估自建組合與託管服務的長期運維成本比值，公開資料未見中國 AI 企業在 Helm 方案選型上的系統性對比資料

11 風險

11.1 供應鏈安全風險

風險項	說明	影響範圍
惡意 Chart 注入	2023 年 ArtifactHub 揭露多起惡意 Chart 事件，攻擊者通過仿冒知名專案名上傳含後門的 Helm Chart	AI 場景下惡意 Chart 可竊取模型權重、訓練資料路徑等敏感資訊
映象劫持	Chart 中 values.yaml 引用的容器映象若來自不可信倉庫，可能被替換為惡意映象	訓練任務容器可獲得 GPU 節點的高權限
依賴混淆	Chart dependencies 若使用寬鬆版本約束，可能拉取到被投毒的依賴 Chart	影響整個 AI 平台棧

緩解措施：

僅從 artifacthub.io 驗證過的釋出者（Verified Publisher）下載 Chart
OCI 分發 + cosign 簽名校驗
Helm 安裝前 --dry-run 渲染完整 YAML 進行人工/自動化審計
企業內部維護 Chart 白名單和映象白名單

11.2 運維複雜度風險

風險項	說明	AI 場景放大因素
版本相容性爆炸	K8s 版本 × Helm 版本 × Chart 版本 × GPU 驅動版本 × CUDA 版本 → 五維相容性矩陣	GPU 驅動與 CUDA 版本強繫結，一旦升級 K8s 可能導致訓練中斷
Values 繼承混亂	多層 values 覆蓋（預設 / 環境 / 全域性 / 本地）的優先順序規則不直觀，易誤覆蓋	AI 場景中訓練/推論環境引數差異大，values 檔案數量多且巢狀深
Hook 失敗回滾不完整	Helm 的 pre-install/post-upgrade hook 若失敗，手動清理殘留資源繁瑣	訓練資料初始化失敗的 hook 可能導致 PVC 殘留
“Chart 膨脹”	完整 Kubeflow Chart 渲染時間可達分鐘級，百個 Release 管理時 Helm 命令響應變慢	大型 AI 平台動輒數百個 Release，運維曲線陡峭

11.3 廠商鎖定風險

鎖定型別	具體表現	解鎖成本
私有 CRD 依賴	部分雲端廠商 AI Chart 依賴其自定義資源（如阿里雲端 LogConfig CRD），社群 K8s 無法識別	需替換為社群標準方案（如 Loki/Elasticsearch），可能導致監控/日誌不相容
映象倉庫繫結	Chart 預設 values 指向雲端廠商內部映象倉庫，離線環境或遷移時需重定向	需維護映象同步管道，成本中等
計費與 Chart 繫結	託管 AI 平台將計費邏輯嵌入 Chart 中（如自動申報 GPU 使用量），脫離平台無法部署	完全解綁需要重寫相關控制器，成本高

11.4 治理與合規風險

GPU 資源超賣：Helm 本身不限制 GPU 配額，若 values 中未正確設定 resource limits，多租戶下 GPU 超額分配可能導致 OOM 和任務失敗
資料合規：AI Chart 部署的訓練任務可能將資料下載到非合規地域的節點（取決於 Chart 的節點選擇器配置），需人工審查
安全審計難度：Chart 中的 RBAC 模板若無安全稽核，可能授予訓練 Pod 不必要的叢集級權限（如 cluster-admin）

公開資料缺口：公開資料未見針對 AI 場景 Helm Chart 安全事件的系統性統計，上述風險識別來源於 CNCF 安全審計報告（2021）、Kubernetes 安全社群揭露案例，以及行業實踐總結。

12 誤讀糾偏

12.1 “Helm 是 Kubernetes 的唯一部署工具”

事實糾正：Helm

Helm Chart

1 三秒看懂

2 三分鐘產業解釋

3 技術原理

3.1 Chart 包解剖學

3.2 Release 生命週期管理

3.3 依賴解析與組合模式

3.4 倉庫分發與簽名

4 關鍵引數

4.1 GPU 資源引數

4.2 訓練架構引數

4.3 推論服務引數

4.4 平台全域性引數

5 技術路線

5.1 路線 A：社群原生 Helm → Operator 增強

5.2 路線 B：OCI 標準化分發 → GitOps 持續部署

5.3 路線 C：AI 專用抽象層 → 遮蔽底層 Helm

5.4 技術路線選擇判斷架構

6 上游

6.1 Kubernetes 版本演進

6.2 容器執行時

6.3 網路與儲存（CNI/CSI）

6.4 OCI Registry 與 Helm Repository

7 下游

7.1 平台層下游應用

7.2 演算法工程師體驗鏈

7.3 業務決策者的 ROI 視角

8 受益公司

8.1 公有雲端廠商

8.2 基礎設施軟體與平台公司

8.3 中國 AI 基礎設施公司

9 市場規模

9.1 Container/Kubernetes 基礎市場

9.2 AI 基礎設施市場的 Helm 關聯度

10 玩家對比

10.1 關鍵決策維度的橫向對比

10.2 “鏈 chain-cloud”視角下的比較

10.3 選型啟示

11 風險

11.1 供應鏈安全風險

11.2 運維複雜度風險

11.3 廠商鎖定風險

11.4 治理與合規風險

12 誤讀糾偏

12.1 “Helm 是 Kubernetes 的唯一部署工具”

相關推薦

同產業鏈 · 相關公司

相關概念