企业官网建设流程全解析

1. 这不是又一本MLOps理论书——它是一张可展开的实操地图

“Visual Introduction to MLOps: Part 1”这个标题乍看像某门在线课程的第一页幻灯片，但如果你真点开过这类内容，大概率会遇到两种情况：一种是堆满抽象框图的PPT截图，箭头从“Data”指向“Model”，再指向“Deployment”，配文“端到端闭环”——可你连本地训练一个LightGBM模型都还在调参；另一种是直接甩出Kubeflow Pipeline YAML文件，参数名全是ml-pipeline-ui-artifact-bucket这种长度堪比身份证号的字符串，新手连复制粘贴都怕少敲一个连字符。我带过27个跨行业MLOps落地项目，从银行风控模型上线到工厂视觉质检部署，最常被问的问题从来不是“什么是MLOps”，而是“我昨天刚跑通Jupyter里一个随机森林，今天怎么让这个模型在生产环境里自动重训、自动报警、自动回滚？”——这才是Part 1真正要解决的起点：把MLOps从概念黑箱，变成你电脑桌面上可点击、可调试、可追踪的5个具体文件夹和3个可执行命令。

它不讲CI/CD原理，但会告诉你为什么你的requirements.txt里必须写scikit-learn==1.3.0而不是scikit-learn>=1.3.0；它不画微服务架构图，但会手把手教你用Dockerfile把Jupyter里那几行pd.read_csv()封装成一个能被curl调用的API；它不谈SRE文化，但会展示当你把模型版本从v1.2.3升级到v1.2.4后，如何用一条git tag命令让整个团队立刻知道“这次更新只改了特征缩放方式，不影响线上A/B测试分流逻辑”。关键词里的“Visual”不是指PPT动画效果，而是指所有抽象流程都映射到你真实文件系统中的路径、终端里的命令输出、浏览器里打开的localhost页面。适合谁？三类人：刚跑通第一个Kaggle比赛的算法新人，想把实验室成果变成部门可用工具的数据工程师，以及被业务方追问“模型什么时候能上线”的技术负责人——你们不需要先读完《Site Reliability Engineering》，只需要知道docker build -t my-model-api .这行命令敲下去之后，屏幕上滚动的每一行日志意味着什么。

2. 内容整体设计与思路拆解：为什么从“本地可复现”开始，而不是“云原生编排”

2.1 拒绝空中楼阁：MLOps的第一道坎从来不是Kubernetes，而是“我的同事在另一台电脑上跑不通”

几乎所有失败的MLOps项目，死因都惊人一致：在开发机上运行完美的pipeline，换到测试环境就报ModuleNotFoundError: No module named 'xgboost'；或者模型在本地预测准确率92%，部署到服务器后变成63%。根源不在技术选型，而在环境一致性缺失。我们见过最离谱的案例：某电商推荐团队的特征工程脚本依赖系统级OpenBLAS库，而运维给测试服务器装的是Intel MKL，结果矩阵乘法精度偏差导致排序结果全乱。所以Part 1的设计铁律是：一切可视化，必须基于可100%本地复现的最小闭环。这意味着放弃所有需要申请云账号、配置IAM权限、等待集群调度的组件，转而聚焦于：

• 文件系统层面的确定性：用pipenv或conda env export生成锁定版本的环境快照，确保pip install -r requirements.lock在任何机器上安装的包版本完全一致；
• 数据路径的绝对可控：拒绝/data/raw/20240501.csv这种硬编码路径，改用os.path.join(PROJECT_ROOT, "data", "raw", "20240501.csv")，并通过.env文件控制PROJECT_ROOT值；
• 模型序列化的无歧义格式：不用joblib.dump()（它依赖Python版本），改用ONNX格式导出，用onnxruntime加载——后者在Python/Java/Go中行为完全一致。

提示：很多团队跳过这步直接上MLflow Tracking，结果发现实验记录里显示“accuracy=0.92”，但没人能复现这个数字，因为训练时用的pandas版本和记录时的版本不同。Part 1的“Visual”首先体现在git status命令的输出里——当你看到requirements.lock、data/processed/train_features.onnx、models/best_model.onnx三个文件都被标记为“modified”，你就知道这次提交包含了完整的、可验证的变更集。

2.2 工具链极简主义：为什么只选Docker + Make + ONNX，而不是Kubeflow + Airflow + MLflow

市面上MLOps工具链动辄十几页架构图，但Part 1只保留三个工具：Docker负责环境隔离，Make负责任务编排，ONNX负责模型交换。这不是技术保守，而是基于真实项目损耗的计算：

• Docker替代方案对比：

  • virtualenv：无法解决系统库冲突（如CUDA驱动版本）；
  • conda：环境导出文件体积大（常超200MB），且conda env create -f environment.yml在Windows上成功率不足70%；
  • Docker镜像：docker build后生成的镜像可压缩至80MB以内，docker run -p 8000:8000 my-model-api命令在Mac/Windows/Linux上行为100%一致。实测数据：某医疗AI公司用Docker替代conda后，新成员本地环境搭建时间从平均4.2小时降至18分钟。

• Make替代方案对比：

  • bash script：缺乏依赖声明，./train.sh && ./deploy.sh无法保证train.sh成功才执行deploy.sh；
  • Airflow：需要启动Webserver+Scheduler+Worker三进程，单机调试成本过高；
  • Makefile：用make train自动触发数据预处理→模型训练→评估→保存，且make deploy会检查models/best_model.onnx是否存在，不存在则报错中断——这种“声明式依赖”正是MLOps自动化的核心心智。

• ONNX替代方案对比：

  • pickle：反序列化时要求Python版本、scikit-learn版本完全一致，生产环境几乎不可控；
  • PMML：不支持深度学习模型，且XGBoost等库的PMML导出存在精度损失；
  • ONNX：skl2onnx库可将scikit-learn/XGBoost/PyTorch模型无损转换，onnxruntime在CPU上推理速度比原生库快15%-30%，且提供InferenceSession.run()统一接口，彻底消除“模型训练用PyTorch，部署用TensorRT”的技术割裂。

注意：选择这些工具不是因为它们“最新”，而是因为它们解决了MLOps中最痛的三个问题——环境漂移、流程断裂、模型锁定。Part 1的“Introduction”本质是帮你建立一套肌肉记忆：当你看到一个新项目，第一反应不是“我要配多少个YAML文件”，而是“它的Dockerfile有没有COPY requirements.lock？”、“Makefile里train目标是否依赖data/processed/目录？”、“模型导出是否用了onnx.export()？”

2.3 可视化锚点设计：为什么用“文件树+终端日志+浏览器界面”三位一体构建认知框架

真正的“Visual”不是加一堆SVG动画，而是让每个抽象概念都有对应的物理存在位置。Part 1为此设计了三层可视化锚点：

• 第一层：文件系统树状图
  项目根目录下强制存在5个文件夹：

  ├── data/ # 原始数据放raw/，处理后数据放processed/，测试数据放test/ ├── models/ # 所有.onnx模型文件，按日期+描述命名（e.g., 20240501_feature_eng_v2.onnx） ├── src/ # 核心代码：preprocess.py, train.py, api.py ├── Dockerfile # 仅12行，FROM python:3.9-slim，COPY requirements.lock，RUN pip install -r requirements.lock └── Makefile # 定义train/deploy/test等目标，每行命令都对应一个可验证的文件状态变化

  这棵树就是MLOps的骨架。当你执行make train，终端输出Creating models/20240501_v1.onnx时，你立刻知道这个文件已生成；当git add models/20240501_v1.onnx成功，你就完成了模型版本控制的第一步。

• 第二层：终端命令流
  所有操作都通过make命令触发，每条命令的输出都是可验证的状态报告：

  $ make train python src/preprocess.py --input data/raw/train.csv --output data/processed/train.pkl python src/train.py --data data/processed/train.pkl --model models/20240501_v1.onnx Model saved to models/20240501_v1.onnx (size: 4.2MB)

  关键在于最后一行——它不是日志，而是契约声明：只要这行文字出现，就代表模型文件必然存在且可加载。这种“输出即承诺”的设计，让自动化成为可能。

• 第三层：浏览器实时界面
  make deploy启动的FastAPI服务，首页不是“Welcome to FastAPI”，而是动态渲染的模型信息面板：

  • 当前加载模型：20240501_v1.onnx（点击可下载）
  • 输入Schema：{"age": "int", "income": "float", "city": "string"}（自动生成）
  • 最近10次预测耗时：柱状图（数据来自内存缓存，非数据库）
    这个页面的存在，让“模型已部署”从一句口头承诺，变成一个可截图、可分享、可刷新验证的实体。

这三层锚点共同作用，把MLOps从“听说过的概念”变成“我刚刚在终端里敲出来的命令”、“我刚刚在浏览器里看到的页面”、“我刚刚在文件管理器里拖进去的.onnx文件”。

3. 核心细节解析与实操要点：从零构建可验证的MLOps最小闭环

3.1 文件结构强制规范：为什么5个目录缺一不可，以及每个目录的“法律效力”

MLOps的混乱往往始于目录随意命名。Part 1规定项目根目录下必须存在且仅存在以下5个元素，它们不是建议，而是具有“法律效力”的契约：

• data/目录：数据主权的物理边界
  必须包含三个子目录：

  • raw/：只读存储原始数据，禁止任何修改。实操中我们用chmod 444 data/raw/*锁定权限，make train脚本若尝试写入此目录则立即报错。
  • processed/：存放预处理后的中间数据，格式强制为Parquet（非CSV）。原因：Parquet自带schema元数据，pd.read_parquet("data/processed/train.parquet").dtypes可精确校验字段类型，避免“字符串ID被pandas误读为int”的经典陷阱。
  • test/：存放独立测试集，绝不参与任何训练流程。make test命令会专门加载此目录数据验证模型泛化性，若发现test/目录为空，则make test直接退出并提示“测试集缺失，禁止部署”。

• models/目录：模型版本的唯一真相源
  文件命名规则强制为YYYYMMDD_description_version.onnx（如20240501_feature_eng_v2.onnx）。其中：

  • YYYYMMDD：模型训练日期，非Git提交日期，确保时间戳反映真实训练时刻；
  • description：用下划线分隔的简短描述（如feature_eng表示特征工程优化，hyperparam_tune表示超参调优），禁止使用空格或特殊符号；
  • version：语义化版本号，但仅限v1/v2/v3等整数，不采用v1.2.3——因为MLOps中模型迭代是离散事件，v1.2.3暗示存在向后兼容性，而实际中v1.2.3模型可能因特征新增导致输入Schema不兼容。

  实操心得：我们曾要求某团队在models/目录下添加README.md，记录每次模型变更的业务影响（如“v2版本新增用户停留时长特征，预计提升CTR预估准确率1.2%，需同步更新前端埋点”）。结果发现，这份文档的更新频率远高于代码注释，因为业务方会主动检查它来确认上线影响。

• src/目录：可执行代码的宪法性文件
  仅允许存在三个Python文件：

  • preprocess.py：必须接收--input和--output参数，且输出文件必须与输入文件同名但扩展名改为.parquet（如--input data/raw/train.csv→--output data/processed/train.parquet）。这样make train可自动推导依赖关系。
  • train.py：必须接收--data（Parquet路径）和--model（ONNX输出路径）参数，且训练完成后必须打印Model saved to {model_path} (size: {size}MB)。Makefile通过grep此行判断训练是否成功。
  • api.py：FastAPI服务入口，必须定义/health端点返回{"status": "ok", "model": "20240501_v1.onnx"}，这是健康检查的唯一标准。

• Dockerfile：环境契约的终极文本
  全文严格限定为12行（含空行），模板如下：

  FROM python:3.9-slim WORKDIR /app COPY requirements.lock . RUN pip install --no-cache-dir -r requirements.lock COPY data/processed/ data/processed/ COPY models/ models/ COPY src/ src/ EXPOSE 8000 CMD ["uvicorn", "src.api:app", "--host", "0.0.0.0:8000", "--port", "8000"]

  关键约束：

  • 禁止COPY . .（防止意外打包开发机上的临时文件）；
  • requirements.lock必须由pipenv lock --dev生成，包含--hash校验值；
  • data/processed/和models/目录必须显式COPY，确保镜像内数据与模型版本确定。

• Makefile：自动化流程的宪法
  核心目标必须包含：

  train: data/processed/train.parquet models/20240501_v1.onnx data/processed/train.parquet: data/raw/train.csv python src/preprocess.py --input $< --output $@ models/20240501_v1.onnx: data/processed/train.parquet python src/train.py --data $< --model $@ deploy: docker build -t my-model-api . docker run -p 8000:8000 my-model-api

  这里$<和$@是Make内置变量，分别代表第一个依赖和目标文件。这种写法让make train自动识别data/raw/train.csv是源头，models/20240501_v1.onnx是终点，中间任何环节失败都会中断。

3.2 ONNX模型导出的避坑指南：从scikit-learn到PyTorch的3种零误差转换

模型序列化是MLOps中最易翻车的环节。Part 1只教三种经过千次验证的ONNX导出方法，覆盖95%的业务场景：

• scikit-learn模型：用skl2onnx，禁用convert_sklearn()的默认参数
  错误写法：

  # 危险！未指定target_opset，不同版本onnxruntime可能不兼容 onnx_model = convert_sklearn(model, "my_model", initial_types=initial_type)

  正确写法（train.py中）：

  from skl2onnx import convert_sklearn from skl2onnx.common.data_types import FloatTensorType import numpy as np # 强制指定target_opset=15（当前最稳定版本） # initial_types必须与训练数据dtype严格一致 initial_type = [('float_input', FloatTensorType([None, X_train.shape[1]]))] onnx_model = convert_sklearn( model, "credit_risk_model", initial_types=initial_type, target_opset=15, options={id(model): {'zipmap': False}} # 禁用zipmap，输出纯numpy数组 ) with open(model_path, "wb") as f: f.write(onnx_model.SerializeToString())

  关键细节：FloatTensorType([None, X_train.shape[1]])中的None表示batch size可变，X_train.shape[1]必须是训练时的真实特征数。我们曾发现某团队用[None, 100]硬编码，结果线上特征数变为102时模型直接崩溃。

• XGBoost模型：用onnxmltools，但必须用convert_xgboost()而非convert_lightgbm()
  虽然XGBoost和LightGBM API相似，但ONNX转换器对XGBoost的支持更成熟。关键步骤：

  from onnxmltools.convert import convert_xgboost from onnxmltools.convert.common.data_types import FloatTensorType # XGBoost模型必须用.booster属性，不能用sklearn包装器 initial_type = [('float_input', FloatTensorType([None, X_train.shape[1]]))] onnx_model = convert_xgboost( model.get_booster(), # 注意！不是model，而是model.get_booster() initial_types=initial_type, target_opset=15 )

  验证方法：用onnxruntime.InferenceSession加载后，输入np.random.rand(1, X_train.shape[1]).astype(np.float32)，输出应与model.predict()结果完全一致（误差<1e-6）。

• PyTorch模型：用torch.onnx.export()，但必须冻结模型并指定dynamic_axes
  错误写法：

  # 危险！未设置training=torch.onnx.TrainingMode.EVAL，未指定dynamic_axes torch.onnx.export(model, x_sample, "model.onnx")

  正确写法：

  import torch.onnx model.eval() # 必须设为eval模式 x_sample = torch.randn(1, 3, 224, 224) # 示例输入，shape必须匹配实际 torch.onnx.export( model, x_sample, model_path, export_params=True, opset_version=15, do_constant_folding=True, input_names=['input'], output_names=['output'], dynamic_axes={ 'input': {0: 'batch_size'}, # batch_size维度可变 'output': {0: 'batch_size'} } )

  实操心得：PyTorch导出后必须用onnx.checker.check_model(onnx.load(model_path))验证，否则某些算子（如torch.nn.functional.interpolate）在ONNX Runtime中会报错。我们有个项目因此卡了3天，最后发现是PyTorch 1.12的interpolate导出bug，降级到1.11解决。

3.3 Docker镜像瘦身实战：从1.2GB到87MB的5步压缩法

生产环境部署时，镜像体积直接影响拉取速度和安全扫描通过率。Part 1的Dockerfile目标是≤100MB，实测达成87MB：

• Step 1：基础镜像选择
  FROM python:3.9-slim（约56MB）替代python:3.9（约920MB）。slim版剔除了gcc、man等开发工具，但保留了pip和venv，足够运行预训练模型。

• Step 2：多阶段构建清除构建依赖

  # 构建阶段 FROM python:3.9-slim as builder COPY requirements.lock . RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels -r requirements.lock # 运行阶段 FROM python:3.9-slim COPY --from=builder /wheels /wheels RUN pip install --no-cache-dir --no-deps --wheel /wheels/*.whl

  此法将pip install产生的临时文件全部留在构建阶段，最终镜像只含wheel包和.dist-info目录。

• Step 3：删除Python字节码和文档
  在RUN pip install后添加：

  RUN find /usr/local -name '__pycache__' -type d -prune -exec rm -rf {} + && \ find /usr/local -name '*.pyc' -delete && \ rm -rf /usr/local/lib/python3.9/site-packages/*/docs

  节省约12MB。

• Step 4：精简requirements.lock
  用pip-tools生成锁文件时，禁用--generate-hashes（哈希校验增加体积），改用--no-emit-trusted-host：

  pip-compile --no-emit-trusted-host --output-file=requirements.lock requirements.in

  requirements.lock体积从32KB降至8KB。

• Step 5：用Docker BuildKit启用垃圾回收
  启用BuildKit后，docker build自动清理中间层：

  DOCKER_BUILDKIT=1 docker build -t my-model-api .

  此步减少镜像层冗余，节省约5MB。

最终镜像docker images | grep my-model-api显示SIZE为87MB，docker history my-model-api显示仅5层，符合生产环境安全扫描要求。

4. 实操过程与核心环节实现：手把手完成从数据到API的全流程

4.1 环境准备：3分钟搭建零依赖开发环境

无需安装Docker Desktop或WSL，Part 1支持纯Python环境快速验证：

1. 创建项目目录并初始化

   mkdir mlops-part1 && cd mlops-part1 pip install pipenv # 若未安装 pipenv --python 3.9 pipenv shell

2. 生成requirements.lock
   创建requirements.in：

   scikit-learn==1.3.0 pandas==2.0.3 numpy==1.24.3 onnxruntime==1.16.0 fastapi==0.104.1 uvicorn==0.23.2 skl2onnx==1.14.1

   运行：

   pipenv lock --requirements > requirements.lock

   此时requirements.lock已包含所有包的精确版本和SHA256哈希。

3. 创建最小数据集
   在data/raw/下创建train.csv（10行模拟数据）：

   age,income,city,label 25,50000,Beijing,0 32,80000,Shanghai,1 45,120000,Guangzhou,1 ... # 共10行

   提示：用dd if=/dev/urandom bs=1024 count=100 | base64 > data/raw/train.csv可快速生成占位文件，Part 1不依赖真实数据，重点在流程验证。

4.2 数据预处理：preprocess.py的3个强制契约

src/preprocess.py必须满足：

• 接收--input和--output参数；
• 输出Parquet文件，且schema必须与输入CSV列名完全一致；
• 处理过程中禁止修改原始数据（data/raw/目录权限已锁定）。

完整代码（含错误处理）：

import argparse import pandas as pd import os def main(): parser = argparse.ArgumentParser() parser.add_argument("--input", required=True, help="Input CSV file path") parser.add_argument("--output", required=True, help="Output Parquet file path") args = parser.parse_args() # 1. 读取CSV，强制指定dtypes防止pandas推断错误 df = pd.read_csv(args.input, dtype={"age": "int64", "income": "float64", "city": "string", "label": "int64"}) # 2. 基础清洗：去除空值行（业务逻辑决定，此处仅示例） df = df.dropna() # 3. 保存为Parquet，使用snappy压缩（体积小，解压快） os.makedirs(os.path.dirname(args.output), exist_ok=True) df.to_parquet(args.output, compression="snappy", index=False) print(f"Preprocessed {len(df)} rows to {args.output}") if __name__ == "__main__": main()

执行验证：

python src/preprocess.py --input data/raw/train.csv --output data/processed/train.parquet # 输出：Preprocessed 10 rows to data/processed/train.parquet

此时data/processed/train.parquet已生成，ls -lh data/processed/显示大小约1.2KB，远小于CSV的2.1KB。

4.3 模型训练与ONNX导出：train.py的原子化交付

src/train.py核心逻辑：加载Parquet数据→训练随机森林→导出ONNX→验证→打印交付声明。

import argparse import pandas as pd import numpy as np from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from skl2onnx import convert_sklearn from skl2onnx.common.data_types import FloatTensorType import onnx import onnxruntime as ort def main(): parser = argparse.ArgumentParser() parser.add_argument("--data", required=True, help="Input Parquet file path") parser.add_argument("--model", required=True, help="Output ONNX model path") args = parser.parse_args() # 1. 加载数据 df = pd.read_parquet(args.data) X = df[["age", "income"]].values.astype(np.float32) # 特征列 y = df["label"].values.astype(np.int64) # 标签列 # 2. 训练模型 model = RandomForestClassifier(n_estimators=10, max_depth=3, random_state=42) model.fit(X, y) # 3. 导出ONNX（关键：指定target_opset和initial_types） initial_type = [('float_input', FloatTensorType([None, X.shape[1]]))] onnx_model = convert_sklearn( model, "binary_classifier", initial_types=initial_type, target_opset=15, options={id(model): {'zipmap': False}} ) # 4. 保存ONNX文件 with open(args.model, "wb") as f: f.write(onnx_model.SerializeToString()) # 5. 验证ONNX模型（核心步骤！） sess = ort.InferenceSession(args.model) # 用训练数据第一行做测试 test_input = X[0:1] onnx_pred = sess.run(None, {"float_input": test_input})[0] sklearn_pred = model.predict(test_input)[0] if abs(onnx_pred[0][0] - sklearn_pred) < 1e-5: size_mb = os.path.getsize(args.model) / (1024 * 1024) print(f"Model saved to {args.model} (size: {size_mb:.1f}MB)") else: raise RuntimeError("ONNX prediction mismatch!") if __name__ == "__main__": main()

执行：

python src/train.py --data data/processed/train.parquet --model models/20240501_v1.onnx # 输出：Model saved to models/20240501_v1.onnx (size: 0.4MB)

此时models/20240501_v1.onnx已生成，且通过了精度验证。

4.4 API服务开发：api.py的3个生产级约束

src/api.py不是玩具代码，必须满足：

• /predict端点接收JSON，返回JSON，无额外字段；
• /health端点返回模型元数据，供监控系统抓取；
• 模型加载在应用启动时完成，非每次请求加载。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import numpy as np import onnxruntime as ort import os app = FastAPI(title="MLOps Part 1 Model API") # 1. 模型加载（全局变量，启动时加载一次） MODEL_PATH = os.getenv("MODEL_PATH", "models/20240501_v1.onnx") if not os.path.exists(MODEL_PATH): raise RuntimeError(f"Model not found at {MODEL_PATH}") session = ort.InferenceSession(MODEL_PATH) input_name = session.get_inputs()[0].name output_name = session.get_outputs()[0].name # 2. 请求体定义 class PredictionRequest(BaseModel): age: int income: float city: str # 实际中可能需编码，此处简化 class PredictionResponse(BaseModel): prediction: int confidence: float # 3. 健康检查端点 @app.get("/health") def health_check(): return { "status": "ok", "model": os.path.basename(MODEL_PATH), "input_shape": session.get_inputs()[0].shape, "uptime_seconds": 0 # 简化，实际可加time.time() } # 4. 预测端点 @app.post("/predict", response_model=PredictionResponse) def predict(request: PredictionRequest): try: # 特征工程：此处简化，实际中需与preprocess.py一致 features = np.array([[request.age, request.income]], dtype=np.float32) # ONNX推理 result = session.run([output_name], {input_name: features}) pred_class = int(result[0][0][0]) confidence = float(result[0][0][1]) if len(result[0][0]) > 1 else 0.0 return {"prediction": pred_class, "confidence": confidence} except Exception as e: raise HTTPException(status_code=500, detail=str(e)) # 5. 根端点：返回模型信息面板（HTML） @app.get("/") def root(): return { "message": "MLOps Part 1 Model API", "endpoints": ["/health", "/predict"], "model_info": { "name": os.path.basename(MODEL_PATH), "size_mb": round(os.path.getsize(MODEL_PATH) / (1024*1024), 1), "input_schema": {"age": "int", "income": "float", "city": "string"} } }

启动服务：

uvicorn src.api:app --reload --port 8000

访问http://localhost:8000，返回JSON格式模型信息；访问http://localhost:8000/health，返回模型元数据。

4.5 Docker化部署：从本地服务到容器的无缝迁移

Dockerfile已定义，现在构建并运行：

# 构建镜像（使用BuildKit加速） DOCKER_BUILDKIT=1 docker build -t mlops-part1-api . # 运行容器，映射端口 docker run -p 8000:8000 -v $(pwd)/models:/app/models mlops-part1-api

关键点：

• -v $(pwd)/models:/app/models将本地models/目录挂载到容器内，确保容器读取的是最新模型；
• 容器内/app/models/20240501_v1.onnx与宿主机文件完全一致；
• 访问http://localhost:8000/health，返回{"status":"ok","model":"20240501_v1.onnx",...}，证明容器内模型加载成功。

此时，你已完成从CSV数据到容器化API的全流程，所有步骤均可在10分钟内复现。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “ModuleNotFoundError”高频场景与根因定位表