云原生机器学习平台的建设难点，常常出现在 AML 工作台和 Kubernetes 底座之间。数据科学团队希望快速启动 Notebook、提交训练任务、登记模型和发布服务；平台团队关注资源配额、镜像安全、任务隔离、日志审计和集群稳定。两类诉求如果各做各的，机器学习平台会变成“上层体验很好、底层运维不可控”或“底座很规范、研发使用门槛很高”。
读完你会得到：一套把 AML 能力映射到 K8s 资源模型的建设方法，适合正在规划 AI 平台、MLOps 平台或模型工程平台的团队参考。
集成的第一步是确定对象模型，而不是先选界面
云原生机器学习平台通常会出现多个对象：项目、用户、数据集、Notebook、训练任务、模型版本、推理服务、实验记录、资源队列和审批单。AML 工作台需要把这些对象组织成研发体验，Kubernetes 则需要把它们落成 Namespace、Pod、Job、Service、PVC、Secret、ConfigMap、RoleBinding、ResourceQuota 等资源。
如果对象模型没有先定义清楚，后续会出现大量补丁式设计。比如项目和命名空间不对应，导致权限难以隔离；实验和训练任务没有版本关系，导致结果不可复现；模型登记和推理服务脱节，导致上线后无法追踪来源；Notebook 使用临时镜像，导致依赖环境无法审计。
AML与K8s集成的关键，是让上层研发对象在底层都有明确资源、权限和记录。 这比单纯把 Notebook 跑在集群里更重要。
资源调度要服务训练、调试和推理三类负载
机器学习平台上的负载并不相同。Notebook 偏交互式，训练任务偏长周期和批处理，推理服务偏稳定在线。三类负载对 GPU / CPU、内存、存储、网络、优先级和回收策略的要求差异明显。K8s 可以提供统一调度入口，但平台必须在上层把负载类型区分出来。
Notebook 需要限制闲置资源，避免个人调试长期占用昂贵算力；训练任务需要队列、配额、失败重试、日志持久化和结果保存；推理服务需要副本、健康检查、滚动升级、弹性伸缩和流量控制。把三类负载混在一个资源池里，会让调度策略难以解释，也会让平台组在资源争议中缺少依据。
下面是一个初步的资源策略表：
| 负载类型 | 平台入口 | K8s资源对象 | 重点控制 | 验收证据 |
| Notebook | 交互式开发环境 | Pod、PVC、Secret | 闲置回收、镜像来源、访问权限 | 登录记录、资源占用、镜像版本 |
| 训练任务 | 实验或流水线任务 | Job、Queue、PVC | 配额、优先级、失败重试 | 任务日志、指标、产物路径 |
| 模型推理 | 在线服务 | Deployment、Service、HPA | 可用性、版本、回滚 | 请求指标、发布记录、告警 |
| 批量推理 | 离线作业 | Job、CronJob | 输入输出、调度窗口 | 数据批次、完成状态、错误记录 |
表格的作用不是限制实现方式，而是帮助团队把不同负载的管理策略讲清楚。只有策略清楚，平台才能同时服务研发效率和运行稳定。
数据、镜像和模型版本要形成可复现链路
机器学习项目出现效果波动时，团队需要回答：使用了哪份数据，什么特征处理逻辑，哪个镜像，哪段代码，哪些参数，训练出了哪个模型，最终部署到了哪个服务。如果这些信息散落在个人目录、聊天记录或临时脚本里，AML 工作台再好看也无法支撑生产协作。
云原生平台可以把可复现链路拆成三条线。数据线记录数据集版本、访问权限和输入输出位置；镜像线记录基础镜像、依赖包、构建时间和扫描结果；模型线记录训练任务、指标、评估结果、模型文件、审批状态和部署版本。三条线需要在平台里互相关联，而不是分别放在三个孤立系统中。
可复现不是科研附加项，而是企业机器学习平台进入生产的基本条件。 当模型服务出现问题时，平台必须能追到训练任务和环境；当训练结果变差时，团队必须能比较数据、代码和参数差异。
权限边界不能只按“数据科学家”和“管理员”划分
机器学习平台的角色通常比传统应用平台更复杂。数据科学家需要实验和训练权限，算法工程师需要镜像和代码权限，平台管理员需要资源和集群权限，业务方可能需要查看指标和审批模型，安全团队需要审计数据访问。简单区分普通用户和管理员，会导致权限过大或流程过慢。
建议按项目、环境和动作划分权限。项目决定谁能访问数据和模型；环境决定开发、测试、生产的操作边界；动作决定能否创建 Notebook、提交训练、读取密钥、发布推理服务、回滚版本或查看日志。K8s 的 RBAC、Namespace 和 Secret 管理可以承接底层隔离，AML 层则应提供更贴近业务的角色视图。
权限设计还要考虑临时授权和到期回收。比如外部协作人员只能访问某个项目的脱敏数据，生产发布需要双人审批，高权限调试必须有时间限制。没有回收机制的临时权限，往往会变成长期风险。
从PoC到生产要补齐观测和运维责任
PoC 阶段常见目标是跑通训练和推理，但生产阶段必须关注运行证据。训练任务失败是数据、镜像、资源、代码还是调度问题？推理服务延迟升高是模型、负载、GPU、网络还是外部依赖问题？这些问题需要日志、指标、事件和链路信息共同回答。
平台至少应提供三层观测。第一层是资源观测，包括 GPU / CPU、内存、存储、队列等待和节点状态。第二层是任务观测，包括训练进度、失败原因、重试次数、产物路径和运行时长。第三层是服务观测，包括请求量、延迟、错误、版本、发布事件和回滚记录。
运维责任也要明确。平台组负责底座和公共能力，算法团队负责代码、数据和模型质量，业务系统团队负责调用方式和容量预估，安全团队负责权限和审计。责任不清会让所有问题都回到平台组，最终影响平台扩展。
建设落地建议：先打通一条闭环，再扩展能力目录
云原生机器学习平台不适合一开始就追求功能完整。更稳妥的路径是先打通一条闭环：创建项目、启动 Notebook、提交训练任务、登记模型、部署测试服务、查看指标、回滚版本。闭环跑通后，再扩展自动化流水线、特征管理、模型评估、批量推理、多集群调度和成本治理。
下一步可以先梳理现有 AI 项目的对象和痛点：哪些环境不可复现，哪些任务排队无序，哪些模型上线缺少审批，哪些服务没有观测。把这些问题映射到 AML 和 K8s 的集成点，建设优先级会更加清晰。
常见问题
云原生机器学习平台一定要基于 Kubernetes 吗？
不一定，但 Kubernetes 适合作为统一调度、隔离和服务化底座。若团队已有大量容器化应用、GPU 资源池和平台运维经验，基于 K8s 构建机器学习平台更容易统一资源与治理。如果团队规模很小，早期也可以从轻量实验管理工具起步，再逐步引入 K8s。
AML 工作台和 MLOps 平台有什么关系？
AML 更偏上层研发体验和机器学习对象管理，MLOps 更强调从开发、训练、评估、部署到监控的工程闭环。实际项目中两者常常重叠：AML 提供工作台和对象入口，MLOps 提供流程、门禁、版本和运维机制。企业建设时应按能力边界拆解，而不是纠结名称。
如何判断平台已经适合生产模型上线？
至少要能回答四类问题：模型来源是否可追踪，数据和镜像是否可复现，发布和回滚是否有记录，运行指标和告警是否能定位责任。若这些证据缺失，即使模型效果在测试中很好，也建议先以试运行或灰度方式推进。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/1238/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
