ML Operations（MLOps）

• LLMOps 与 MLOps 差异
• 多类版本管理
• 可复现性

差异：传统 MLOps 以"模型训练→部署"为核心，重数据/特征/训练；LLMOps 以"Prompt + 模型 + 评测"为核心，重提示词工程、上下文、评测与安全，模型多为预训练/微调而非从零训练。可复现版本管理：Prompt 版本（Prompt 管理平台）、数据集版本（DVC/数据仓库）、模型版本（Model Registry）、评测集版本（评测平台）四者都以不可变版本号管理，并互相绑定（一次实验记录 prompt+数据+模型+评测+结果）。用"实验记录"（如 MLflow）把四者关联，保证可复现。

LLMOps 的独特在于"Prompt 是发布物"且评测是关键。可复现的核心是"四类版本都不可变 + 互相绑定 + 实验记录"。运维上通过 registry 与实验 tracking 把 prompt/数据/模型/评测锁定在一份记录，任何结果可回溯。

• 平台分层职责
• 层间衔接
• 端到端流程

MLOps 平台分层：数据管理（数据版本、特征、标注）→ 实验跟踪（参数/指标/产物记录）→ 训练编排（可复现的训练任务、超参）→ 模型注册（模型版本、元数据、审批）→ 部署监控（线上服务与质量）。衔接：数据注册后训练引用数据版本；实验产物（模型）注册进 registry；registry 模型经审批部署；部署后监控回流信号更新实验。各层通过"版本与元数据"串联，形成从数据到线上监控的闭环。

分层衔接的关键是"版本与元数据贯穿"——每层输出版本化产物，下一层引用。数据版本→训练→模型版本→部署→监控，形成可追溯闭环。运维上平台要保证各层接口一致与元数据完整，支撑端到端治理。

• MLflow 功能
• W&B 功能
• 选型

MLflow 是开源的 ML 生命周期平台，提供实验跟踪（参数/指标/产物）、模型管理（Model Registry）、模型部署与服务，开源、可自托管、与主流框架集成；Weights & Biases（W&B）是商业化实验跟踪平台，提供可视化（图表、对比）、日志记录、协作、数据集与模型管理，UI 与协作体验好，但云端/商业。价值：MLflow 侧重完整生命周期与开源自托管，W&B 侧重实验可视化与协作。选型：需要开源自托管全生命周期用 MLflow，重视实验可视化与团队协作用 W&B。

两者核心都是"实验跟踪"，MLflow 更开源完整、W&B 更可视化协作。运维上按团队需求与数据隐私选型（自托管 vs SaaS）。监控实验记录（参数/指标/模型）支撑可复现。

• 模型注册与审批
• 金丝雀与回滚
• registry 与 CI/CD 衔接

流程：实验模型 → 注册进 Model Registry（带元数据/评测）→ 审批（质量门禁、负责人审批）→ 打标（staging/production 状态）→ CI/CD 触发部署 → 金丝雀发布（先小流量验证）→ 评估通过转全量，否则回滚。model registry 与 CI/CD 衔接：CI 跑评测并将结果写入 registry 状态，CD 检测到 production 状态变化自动触发部署；部署时引用 registry 的不可变模型版本。回滚即切回旧版本引用。

核心是"registry 作为模型发布物的唯一事实源 + CI/CD 自动化"。registry 承载版本与审批状态，CI/CD 依据状态自动部署。金丝雀与回滚保证线上安全。运维上把门禁、审批、发布、回滚都绑定到 registry，形成可追溯的发布链路。

• BentoML 功能
• Ray Serve 功能
• 选型

BentoML 是模型打包与部署框架，把模型+预处理+依赖打包成 Bento（统一产物），支持部署到各种平台（K8s、Docker、云），提供 API 服务、批处理、监控，重"模型即服务"的打包与部署；Ray Serve 是 Ray 上的模型服务框架，支持部署/扩展多个模型服务、请求路由、动态批处理、弹性伸缩，与 Ray 生态集成，重"分布式可扩展的服务"。价值：BentoML 打包部署简单、Ray Serve 弹性扩展强。选型：需快速打包部署用 BentoML，需弹性/分布式服务用 Ray Serve。

BentoML 侧重"打包-部署"，Ray Serve 侧重"分布式服务扩展"。二者可结合。运维上 BentoML 简化部署、Ray Serve 提供弹性。选型按服务规模与弹性需求。

• 各工具定位
• 功能差异
• 选型

ClearML 是开源 ML 平台，提供实验跟踪、管道编排、模型管理、数据版本，开源可自托管；Neptune 是商业实验跟踪平台，重元数据管理与可视化、团队协作、与框架集成；Comet 是商业实验跟踪平台，重实验对比、可视化、超参搜索与协作。三者核心都是"实验跟踪与可视化"，差异在开源（ClearML）vs 商业（Neptune/Comet）、侧重点。价值：记录实验参数/指标/产物，支持对比与协作。选型：开源自托管用 ClearML，商业可视化协作用 Neptune/Comet。

三者的共同价值是"实验可追踪、可对比、可协作"。ClearML 开源完整，Neptune/Comet 商业可视化。运维上按开源/商业、自托管/云需求选型，保证实验记录完整。

• DVC 原理
• 工程价值
• 与 Git 协作

DVC 是数据版本控制工具，把数据集/模型等大文件用 Git 管理元数据（哈希/指针），实际数据存到外部存储（S3、本地、NAS），通过 Git 提交记录数据版本，支持数据的 checkout、diff、回滚。工程价值：让数据/模型像代码一样版本化——数据变更可追溯、实验可复现、数据集可回滚；配合管道（dvc.yaml）实现数据→训练的可复现。价值：解决"数据不可版本化、实验不可复现"问题。

DVC 的核心是"用 Git 管数据元数据 + 外部存储存数据"，把数据版本纳入 Git 工作流。价值是数据可追溯、可复现、可回滚。运维上结合 DVC 与 CI 做数据驱动的训练触发。局限是需配合外部存储。

• Feature Store 概念
• 两者功能
• 选型

Feature Store（特征平台）统一管理特征的存储、计算与在线/离线一致性，避免特征重复开发与训练/推理不一致。Feast 是开源的 Feature Store，提供特征定义、离线（训练）/在线（推理）存储、特征检索，开源可自托管；Tecton 是商业 Feature Store，提供特征工程、实时/批量计算、监控、与 ML 平台集成，功能更全但商业。价值：解决特征复用与一致性（在线/离线同源）。选型：开源自托管用 Feast，需要完整实时特征平台用 Tecton。

Feature Store 的价值是"特征一次定义、在线/离线复用、保证一致性"。Feast 开源基础、Tecton 商业完整。运维上 Feature Store 解决训练-推理特征不一致（Training-Serving Skew）。选型按功能与成本。

• 各框架定位
• 功能差异
• 选型

Kubeflow 是 K8s 原生的 ML 平台，提供 Pipelines、Training Operator、Notebook，与 K8s 深度集成；Metaflow 是 Netflix 开源，以 Python 为中心的 ML 工作流/管道框架，重易用性、版本、与云端执行；Flyte 是数据分析/ML 的编排平台，提供类型安全、可复现、可扩展的管道，K8s 原生，重生产级编排。差异：Kubeflow 平台全、Metaflow 易用 Pythonic、Flyte 生产级编排。选型：K8s 平台用 Kubeflow，Python 易用用 Metaflow，生产级复杂编排用 Flyte。

三者都是 ML 工作流编排，差异在定位：Kubeflow 平台化、Metaflow 易用、Flyte 生产级。运维上按团队技术栈与编排复杂度选型。共同价值是"可复现、可编排、可监控的训练管道"。

• Kubeflow Pipelines 定位
• Airflow 定位
• 选型

Kubeflow Pipelines 是 K8s 原生的 ML 管道，用组件（component）定义训练/推理步骤，原生支持 GPU 资源、K8s 调度、可复现，适合 ML 训练/推理管道；Airflow 是通用工作流编排（DAG），调度灵活、生态成熟、适合数据管道/ETL/跨系统编排，但 ML 训练资源管理弱。差异：Kubeflow Pipelines 重 ML 生态（K8s/GPU），Airflow 重通用调度（DAG/数据）。选型：ML 训练/推理管道用 Kubeflow Pipelines，数据管道/通用编排用 Airflow，二者可结合（Airflow 触发 Kubeflow）。

Kubeflow Pipelines 面向 ML（K8s/GPU 原生），Airflow 面向通用调度（DAG 灵活）。实际常结合：Airflow 做数据/触发，Kubeflow 做训练。运维上按场景选型，避免用错工具。

• 三者定义
• 差异
• 应用场景

MLOps（机器学习运维）——把机器学习模型从开发到生产生命周期管理的工程实践，重数据、训练、部署、监控；AIOps（智能运维）——把 AI/ML 应用在 IT 运维上（日志分析、异常检测、根因定位），用 AI 运维 IT；LLMOps（大模型运维）——大语言模型应用的运维，重 Prompt、上下文、评测、安全、token 成本。差异：MLOps 管"模型生命周期"，AIOps 用"AI 做运维"，LLMOps 管"LLM 应用"。三者场景不同：MLOps 目标是模型开发部署，AIOps 目标是 IT 运维自动化，LLMOps 目标是 LLM 应用质量/成本/安全。

容易混淆但本质不同：MLOps 是"把 ML 做成产品"，AIOps 是"用 ML 优化运维"，LLMOps 是"LLM 应用的专门运维"。理解差异助于选对工具与流程。三者可互相促进（LLMOps 用 AIOps 手段）。

• MLOps 与 DevOps 差异
• 模型/数据/实验挑战
• 工程应对

DevOps 管"代码→部署"的软件发布，输出确定；MLOps 有"数据+模型+代码"三重依赖，输出是模型，具有不确定性（训练结果受数据/随机影响）。挑战：模型迭代——模型不是代码，更新需重新训练/评测，是否变好需评估；数据依赖——数据版本变化影响模型，需数据版本管理；实验管理——大量实验需跟踪参数/指标/产物，保证可复现。应对：引入数据版本、模型 registry、实验跟踪、评测门禁，把"模型发布"接入 CI/CD。

差异核心是"ML 有数据与模型作为可变输入，且有不确定性"。MLOps 在 DevOps 基础上增加数据版本、实验管理、评测、模型注册。挑战是"可复现性与质量评估"。运维上把模型发布纳入 CI/CD 并加评测门禁。

• 数据触发训练
• 评测门禁
• 自动部署

流水线设计：数据变更（DVC 版本变更/新数据入库）→ 触发训练任务（CI 检测数据版本变化，启动训练）→ 训练产物（模型）注册 → 评测门禁（离线评测集打分，与基线对比，达标才通过）→ 通过后自动部署（CD 拉取 registry 模型金丝雀发布）→ 监控。门禁控制：评测指标不达标则阻断部署。用 CI/CD 工具（GitHub Actions/Airflow/Argo）编排，数据/模型/评测集版本化。

核心是"数据驱动重训 + 评测门禁 + 自动部署"闭环。数据变更触发训练保证模型跟得上数据，评测门禁防止劣化模型上线，自动部署保证快速迭代。运维上把数据版本、评测结果、部署状态绑定，实现可追溯。

• Pachyderm 原理
• 工程价值
• 适用场景

Pachyderm 是数据驱动的 ML 管道平台，提供数据版本管理（类似 Git 的数据）、自动化管道（数据变更触发）、可复现（数据+代码+结果绑定）、数据血缘。工程价值：数据版本化——每次数据变更可追溯；管道自动化——数据更新自动触发依赖管道；可复现——数据集+代码+运行结果固定，可重放；生产级数据管道。适用：需要数据版本与可复现的 ML 管道、数据驱动的训练。

Pachyderm 的核心是"数据版本 + 数据驱动管道 + 可复现"。它把数据变更作为触发管道的机制，保证每次运行可复现。与 DVC 类似但更偏管道平台。运维上用它建立数据血缘与可复现训练。

• Training-Serving Skew 定义
• 检测方法
• 校验手段

Training-Serving Skew 指训练时用的特征与线上推理时用的特征不一致（算法、时间、来源不同），导致模型效果差。检测方法：特征一致性校验——对比训练特征与线上特征的分布（均值、方差、PSI）、缺失率、生成逻辑是否一致；shadow 回放——把线上请求特征拿到离线环境用同样的特征逻辑重算，对比与训练特征是否一致；定期校验特征 schema 与计算逻辑。发现不一致即告警并修复特征管线。

Skew 的核心风险是"训练/推理特征管线分叉"。检测靠"一致性校验 + 回放对比"。Feature Store 是解决途径（统一特征）。运维上把特征一致性纳入监控，发现分布漂移即告警。

• 可复现的要素
• 联合锁定
• 复现流程

可复现需锁定：seed（随机种子）、框架版本（PyTorch/TF 版本）、数据版本（DVC/数据版本）、镜像（训练环境依赖）、代码版本、超参与配置文件。联合锁定——把这些都记录在实验/模型元数据中，训练时用锁定的环境（镜像）与数据重跑。复现线上模型：从 registry 取模型元数据（含 seed/框架/数据/镜像版本）→ 用锁定镜像+数据+seed 重训 → 对比结果（指标/权重）是否一致。一致性受 GPU 确定性影响（需设置确定性模式）。

可复现的核心是"环境+数据+代码+seed 全锁定"。GPU 计算有非确定性，需设置确定性模式（cudnn deterministic）。运维上把"镜像+数据+代码+seed"作为训练的可复现清单，存入 registry。

• 漂移类型与指标
• 告警设计
• Evidently 接入

数据漂移（输入分布变化）与概念漂移（输入-输出关系变化）需监控。指标：PSI（Population Stability Index）衡量特征分布偏移，KS（Kolmogorov-Smirnov）检验分布差异，另用 JS 散度、统计检验。告警：漂移超阈值（PSI>0.2 或显著性）即告警，提示重训或数据异常。Evidently 是开源漂移检测工具，可接入 ML 监控——对特征做漂移检测、数据质量、模型性能，输出报告与指标，集成到监控平台（Prometheus/仪表盘）。接入：采集线上特征，Evidently 计算漂移指标，超阈值告警。

漂移检测是"模型失效提前预警"。数据漂移看输入分布，概念漂移看预测关系。PSI/KS 是常用指标。Evidently 等工具自动化漂移计算。运维上接通线上特征与监控，超阈值触发重训/告警。

• 生命周期阶段
• 退役与保留
• 治理设计

生命周期管理：版本化——模型以不可变版本存在 registry；注册审批——新模型需评测门禁+负责人审批后上线；在线退役——下线的模型从线上摘除、明确退役状态，避免被误用；数据保留——按合规与业务约定保留模型训练数据、评测数据、日志，设置保留期与归档/删除策略。设计：registry 管理状态机（注册→审批→生产→退役→归档），退役模型保留元数据供追溯，数据按保留期处理。

生命周期管理核心是"版本与状态治理"——从创建到退役全程可控。退役是常被忽略但重要的（避免过期模型误用）。数据保留需合规（保留期、删除）。运维上建立模型资产清单与状态流转，保证可追溯与合规。

• 监控维度
• 关联告警
• 体系设计

模型监控体系三层面：数据漂移（输入分布变化）、性能指标（准确率/AUC 等，需用代理指标，因无真实标签）、线上反馈（用户反馈、业务结果）。关联告警——把三者关联：数据漂移触发→性能可能下降→反馈变差，形成因果链。建立：漂移/性能/反馈指标都用基线，任何恶化超阈值告警，并关联（漂移发生前告警、性能下降确认、反馈变差验证）。工具（Evidently、Prometheus）集成。告警触发重训/回滚。

关联告警的价值是"早发现、早确认"：数据漂移提前预警，性能/反馈验证影响。代理指标（无真实标签）是模型监控难点。运维上把三类指标统一观测，形成"漂移→性能→反馈"的关联告警，降低误报。