3、环境与工具链搭建：Python环境管理、Docker容器化、Kubernetes集群、CI/CD工具（Jenkins/GitLab CI）、MLflow/Kubeflow等平台选型

MLOps 工程化的落地，首先取决于一套稳定、可复现且可扩展的环境与工具链。本章聚焦于从单机 Python 开发环境到生产级 Kubernetes 集群的完整链路搭建，并深入对比 CI/CD 工具与 MLflow/Kubeflow 等平台选型。我们将从环境管理的底层逻辑出发，逐步构建容器化镜像、编排集群，最终形成一套支撑模型持续交付的标准化流水线。下图展示了本章涉及的核心组件及其在 MLOps 生命周期中的位置关系。

环境与工具链的搭建并非简单的软件安装，而是一场关于标准化、自动化与可观测性的工程实践。一个成熟的 MLOps 环境，应当让数据科学家在本地开发时拥有充分的灵活性，同时确保代码提交后能在统一的环境中构建、测试并部署到生产。本章将按照从开发到生产的路径，逐一拆解各环节的关键技术选型与实施要点。

3.1 Python 环境管理：从混乱到有序

核心原理：依赖隔离与可复现性

Python 环境管理的核心矛盾在于全局解释器与项目依赖冲突。多个项目可能依赖同一包的不同版本，而系统级安装会导致“依赖地狱”。MLOps 要求环境具备可复现性——即今天构建的环境，三个月后仍能精确重建。这需要锁定传递依赖的完整版本，而不仅仅是直接依赖。

判断方法：选择合适的环境管理工具

对于 MLOps 项目，推荐使用 Poetry 或 Conda。Poetry 的 poetry.lock 文件能锁定所有依赖的精确版本，而 Conda 则更适合需要 CUDA、MKL 等非 Python 库的场景。关键实践是：将环境定义文件（如 pyproject.toml 或 environment.yml）纳入版本控制，作为环境构建的唯一事实来源。

实战场景：构建可复现的 ML 开发环境

# 使用 Poetry 初始化项目
poetry new ml_project
cd ml_project
poetry add numpy pandas scikit-learn
poetry add --dev pytest black flake8

# 导出锁定依赖
poetry export -f requirements.txt --output requirements.txt

# 使用 Conda 创建包含 CUDA 的环境
conda create -n ml_env python=3.10
conda activate ml_env
conda install cudatoolkit=11.8 pytorch=2.0.1 -c pytorch

在团队协作中，建议统一使用 Docker 镜像作为开发环境的最终载体。将 Poetry 或 Conda 环境封装进镜像，确保所有成员在完全一致的 Python 环境中开发，消除“在我机器上能跑”的问题。

3.2 Docker 容器化：构建不可变交付物

核心原理：镜像分层与构建缓存

Docker 镜像由只读层组成，每一层代表一个 Dockerfile 指令。构建时，Docker 会缓存已存在的层，仅重建发生变化的层。理解这一机制是优化构建速度的关键。MLOps 场景中，模型训练依赖的 Python 包体积庞大，合理利用缓存可将构建时间从数十分钟缩短至几分钟。

操作流程：编写高效的 Dockerfile

1. 选择基础镜像：优先使用官方 python:3.10-slim 而非 python:3.10，减小体积。
2. 先复制依赖清单，再复制源码：利用缓存机制，仅当依赖变化时才重新安装包。
3. 多阶段构建：在构建阶段安装编译工具，在运行阶段仅保留运行时依赖。
4. 非 root 用户运行：提升安全性，避免容器内权限过大。

# 多阶段构建示例
FROM python:3.10-slim AS builder
WORKDIR /app
COPY pyproject.toml poetry.lock ./
RUN pip install poetry && poetry export -f requirements.txt -o requirements.txt
RUN pip install --prefix=/install -r requirements.txt

FROM python:3.10-slim
WORKDIR /app
COPY --from=builder /install /usr/local
COPY src/ ./src/
RUN useradd -m appuser
USER appuser
CMD ["python", "src/main.py"]

案例拆解：模型推理服务的镜像优化

某金融风控团队需要部署一个基于 XGBoost 的推理服务。初始镜像体积为 2.3GB，构建耗时 12 分钟。通过以下优化：

• 将基础镜像从 python:3.10 更换为 python:3.10-slim，体积降至 1.1GB。
• 使用多阶段构建，仅复制编译后的 .so 文件，避免在运行镜像中保留 gcc 等工具。
• 将模型文件作为独立层复制，利用缓存避免每次代码变更都重新打包模型。

优化后镜像体积降至 680MB，构建时间缩短至 3 分钟。更重要的是，由于模型文件单独分层，当模型更新时，仅需重新构建最后一层，CI 流水线效率提升 70%。

3.3 Kubernetes 集群：从单机到弹性调度

核心原理：声明式 API 与控制器循环

Kubernetes 的核心价值在于声明式管理——用户描述期望状态（如“运行 3 个副本”），控制器持续对比实际状态并调谐至期望状态。对于 ML 工作负载，这意味着：训练任务可以按需启动和销毁，推理服务可以自动扩缩容，GPU 资源可以被多个团队共享。

判断方法：集群规划与资源管理

在集群搭建时，推荐使用 kubeadm 或云厂商托管服务（如 AKS/EKS/GKE）。对于 GPU 工作负载，需要安装 NVIDIA Device Plugin 并配置节点池的 GPU 驱动。关键操作包括：

# 创建 GPU 节点池（以 AKS 为例）
az aks nodepool add --resource-group rg-mlops --cluster-name aks-ml \
  --name gpunp --node-vm-size Standard_NC6 --node-count 2 \
  --node-taints sku=gpu:NoSchedule

# 部署 NVIDIA Device Plugin
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/nvidia-device-plugin.yml

实战场景：使用 Kueue 管理训练任务队列

当多个团队共享 GPU 集群时，直接提交训练任务会导致资源争抢。引入 Kueue 作为队列管理器，实现训练任务的排队与优先级调度。团队 A 的紧急任务可以抢占团队 B 的非紧急任务，但需设置 preemptionPolicy 保证公平性。通过定义 ClusterQueue 和 LocalQueue，将 GPU 资源池化，利用率从 40% 提升至 75%。

3.4 CI/CD 工具选型：Jenkins 与 GitLab CI 对比

核心原理：流水线即代码

CI/CD 工具的核心是将构建、测试、部署流程代码化，实现自动化执行。MLOps 的 CI/CD 与普通软件开发的差异在于：需要处理数据验证、模型评估、模型注册等 ML 特有步骤。因此，流水线不仅要编译代码，还要验证数据质量、评估模型指标，并将符合条件的模型自动注册。

对比分析：Jenkins vs GitLab CI

对于新建 MLOps 项目，推荐 GitLab CI。其原生支持 rules 条件触发、needs 依赖控制，且与代码仓库无缝集成。Jenkins 更适合已有大量 Jenkins 投资或需要高度定制化插件的团队。

案例拆解：GitLab CI 实现模型训练与部署流水线

# .gitlab-ci.yml 关键片段
stages:
  - validate
  - train
  - evaluate
  - deploy

validate:
  stage: validate
  script:
    - python scripts/validate_data.py --input data/raw/
  artifacts:
    paths: [validation_report.json]

train:
  stage: train
  script:
    - python scripts/train.py --data data/processed/ --output model/
  artifacts:
    paths: [model/]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

evaluate:
  stage: evaluate
  script:
    - python scripts/evaluate.py --model model/ --test data/test/
  after_script:
    - python scripts/register_model.py --model model/ --metric accuracy --threshold 0.85

deploy:
  stage: deploy
  script:
    - kubectl set image deployment/inference api=registry.example.com/ml/inference:$CI_COMMIT_SHA
  environment: production
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v.*$/'

该流水线实现了：数据验证失败则终止后续流程；模型评估指标低于阈值则不注册；仅当打上 v 开头的 Git Tag 时才触发生产部署。通过 artifacts 在阶段间传递数据，确保每个阶段使用相同的输入。

3.5 MLflow 与 Kubeflow 平台选型

核心原理：实验跟踪与工作流编排

MLflow 和 Kubeflow 解决的是 MLOps 不同层面的问题。MLflow 聚焦于实验跟踪、模型注册与部署，轻量且易于集成；Kubeflow 则是完整的 Kubernetes 原生 ML 平台，涵盖 Notebook、训练、超参调优、推理等全流程。选型的关键在于团队规模、基础设施现状和业务复杂度。

判断方法：平台选型决策矩阵

实战场景：混合架构落地

某互联网公司采用混合架构：使用 MLflow 作为统一的实验跟踪和模型注册中心，所有团队的训练代码均通过 mlflow.start_run() 记录参数和指标；同时，使用 Kubeflow Pipelines 编排需要多步骤的定时训练任务（如每周特征工程 + 模型重训 + 评估）。MLflow 负责“模型生命周期管理”，Kubeflow 负责“工作流调度”，两者通过模型注册表衔接。

# 在训练脚本中集成 MLflow
import mlflow

mlflow.set_tracking_uri("http://mlflow-server:5000")
with mlflow.start_run(run_name="xgboost_v2"):
    mlflow.log_param("learning_rate", 0.1)
    mlflow.log_metric("auc", 0.923)
    mlflow.sklearn.log_model(model, "model")
    mlflow.register_model("runs:/<run_id>/model", "credit_risk_model")

该架构下，数据科学家只需关注模型开发，平台团队负责维护 Kubeflow 的稳定性。模型上线时，通过 MLflow 的 models:/credit_risk_model/Production 获取最新生产模型，由 CI 流水线自动部署到 Kubernetes。

3.6 工具链整合与最佳实践

核心原理：端到端链路打通

环境与工具链的最终目标是形成一条自动化、可观测、可回滚的交付链路。从代码提交到模型上线，每个环节都应可追踪、可审计。关键整合点包括：

• Git 触发 CI：代码推送自动触发流水线。
• CI 构建镜像：将 Python 环境 + 代码 + 模型打包为不可变镜像。
• 镜像推送仓库：Harbor 或 ECR，支持漏洞扫描。
• CD 部署至 K8s：通过 Helm 或 Kustomize 更新部署。
• 模型注册与版本管理：MLflow 记录模型版本与生产状态。

操作流程：搭建最小化 MLOps 工具链

1. 初始化 Git 仓库，创建 pyproject.toml 和 Dockerfile。
2. 搭建 GitLab Runner，注册至项目。
3. 编写 .gitlab-ci.yml，包含构建、测试、部署阶段。
4. 部署 MLflow 服务（使用 Docker Compose 或 Helm）。
5. 创建 Kubernetes 命名空间 ml-dev、ml-prod，配置资源配额。
6. 编写 Helm Chart 部署推理服务，配置 HPA 自动扩缩容。