Kubeflow加速云原生AI演进，毕业CNCF仍待关键验证

导语

Kubeflow正在从一套面向机器学习的Kubernetes工具集合，进一步走向覆盖AI开发全生命周期的平台。近期更新并非单一组件升级，而是同时触及实验开发、数据处理、分布式训练、模型目录、在线推理、安全和社区治理等环节。项目由此释放出一个清晰信号：在接近CNCF毕业阶段之际，Kubeflow更关注生产环境的标准化和可运维性。

核心进展

• 实验到管道更顺畅。 Kale 2.0支持原生Spark，并可将经过标注的Jupyter Notebook转换为生产就绪的管道。它适配Kubeflow Pipelines v2，数据科学家不必直接编写KFP SDK代码，就能把实验流程推进到管道化运行。
• 交互式开发走向声明式。 Kubeflow Notebooks v2采用从头设计的CRD驱动架构。平台团队可以通过模板统一管理JupyterLab、VS Code等环境，Alpha版本已开放测试。
• 训练与高性能计算进一步融合。 Kubeflow SDK提供统一的Python接口，用于Spark数据处理、管道编排、分布式训练和超参数调优，并加入大语言模型微调蓝图。新的Trainer通过MPI支持分布式AI训练，并正式集成Flux Framework，使AI任务与大规模HPC模拟能够在同一Kubernetes环境中协调运行。
• 模型管理和推理能力扩展。 Model Registry更名为Hub，范围扩展至Model Catalog和MCP Catalog，并使用OCI作为模型及MCP服务器存储与分发的标准。KServe新增LLMInferenceService CRD，为跨节点大模型推理提供平台级抽象，并支持兼容OpenAI的API。
• 安全与可观测性成为重点。 Kubeflow Community Distribution 26.03验证支持Kubernetes 1.34及更高版本，强化多租户默认配置，并兼容Pod Security Standards的Restricted策略。后续SDK计划加入OpenTelemetry检测和MLflow跟踪，以补强AI生命周期观测。

意义与影响

这些更新体现了云原生AI平台竞争的变化。用户需要的不只是训练算力，还需要把Notebook、数据任务、训练作业、模型资产和推理服务连接起来，并在多租户环境下保持安全边界。Kubeflow通过CRD、OCI、OpenAI兼容API等机制，尝试减少平台之间的定制集成成本。

不过，接近毕业并不等于所有能力已经成熟。Kale与Notebooks v2仍需要在不同组织的工作流中验证，分布式训练、跨节点推理以及Spark与HPC协同也会带来资源调度和运维复杂度。项目能否顺利毕业，最终仍取决于版本稳定性、生态协同和生产用户的持续反馈。外联项目与ML体验工作组的成立，则说明社区也在通过改善界面和贡献者支持，降低采用与参与门槛。

来源：InfoQ 中文