MLOps-Basics 第九周实战：从 ONNX 模型到 Lambda 无服务器推理与 Kibana 日志监控-平芜编程栈

示例工程

【免费下载链接】MLOps-Basics

项目地址：https://gitcode.com/GitHub_Trending/ml/MLOps-Basics

导读

本篇技术指南以week_9_monitoring模块为骨架，完整演示一条 MLOps 生产链路：用 PyTorch Lightning 训练 CoLA 文本模型 → 导出 ONNX → 用 DVC 把模型版本化到 S3 → 构建 Docker 镜像推送 ECR → 以 AWS Lambda 无服务器方式承载推理 → 最后用 Elasticsearch + Kibana 对 CloudWatch 日志做集中监控。读完本文，你将掌握模型导出、容器化部署、无服务器推理与日志监控之间的完整衔接方式，并能在自己的推理 API 中复现这套链路。

一、项目背景与模块定位

MLOps-Basics 是一个循序渐进探索 MLOps 工具链的学习型仓库，其核心目的（见 week_9_monitoring/README.md 开头声明）是“探索各种库并学会如何使用它们，而非构建 SOTA 模型”。第九周模块聚焦“监控（Monitoring）”，即把前面几周已经搭建好的训练、版本化、容器化能力收拢到生产部署形态：

训练与实验跟踪：PyTorch Lightning + Hydra + W&B
数据/模型版本化：DVC + S3
模型导出：PyTorch → ONNX
服务化：FastAPI + Docker
无服务器化：AWS Lambda（镜像部署）
日志监控：CloudWatch → Elasticsearch → Kibana

从源码结构看，week_9_monitoring目录下同时保留了 app.py（FastAPI 推理服务）、lambda_handler.py（Lambda 入口）与 Dockerfile（以amazon/aws-lambda-python为基座，入口指向 lambda_handler），可以推断本模块的实际运行形态是“Lambda 镜像承载推理”，而 FastAPI 版本主要服务于本地调试与 Docker 直接运行场景。

环境要求：Python 3.8。创建虚拟环境并安装依赖：

conda create --name project-setup python=3.8 conda activate project-setup pip install -r requirements.txt

二、训练：PyTorch Lightning + W&B 实验跟踪

2.1 训练入口

安装依赖后直接运行：

python train.py

训练脚本由@hydra.main(config_path="./configs", config_name="config")装饰，训练配置（batch_size、max_length、max_epochs 等）来自 configs/config.yaml 及各子目录默认配置。脚本核心逻辑：

通过DataModule加载 GLUE CoLA 数据集并做 tokenize；
通过ColaModel加载google/bert_uncased_L-2_H-128_A-2轻量 BERT 模型；
配置ModelCheckpoint（保存到models/best-checkpoint.ckpt，监控valid/loss取最小）与EarlyStopping（patience=3）；
使用WandbLogger将训练过程记录到 W&B 项目 “MLOps Basics”。

2.2 W&B 面板查看

训练结束时日志尾部会输出类似：

wandb: Synced 5 W&B file(s), 4 media file(s), 3 artifact file(s) and 0 other file(s) wandb: wandb: Synced proud-mountain-77: https://wandb.ai/raviraja/MLOps%20Basics/runs/3vp1twdc

点击链接即可进入 W&B 仪表盘查看全部图表。值得说明的是，这些图表并非仅靠框架自动生成——model.py 中ColaModel在training_step/validation_step里显式记录了train/loss、train/acc、valid/loss、valid/acc、valid/precision_macro、valid/recall_macro、valid/precision_micro、valid/recall_micro、valid/f1等指标；validation_epoch_end中又通过wandb.plot.confusion_matrix记录混淆矩阵。此外 train.py 中的自定义回调SamplesVisualisationLogger会在每个验证阶段结束时，把“预测错误”的样本以wandb.Table形式记录到 W&B，方便人工检查模型在哪些句子上犯错。这为“监控”主题提供了训练侧的实验监控能力。

三、模型导出：PyTorch → ONNX

3.1 导出命令

训练完成后执行：

python convert_model_to_onnx.py

convert_model_to_onnx.py 从models/best-checkpoint.ckpt加载 checkpoint，取一个训练 batch 作为示例输入，调用torch.onnx.export导出到models/model.onnx。关键导出参数：

opset_version=10：ONNX 算子集版本；
input_names=["input_ids", "attention_mask"]：对应 BERT 的 token 输入与注意力掩码；
output_names=["output"]：模型输出；
dynamic_axes：将batch_size维度声明为动态轴，使导出模型可接受任意 batch 大小的输入。

3.2 ONNX 推理

导出后可用 ONNX Runtime 做推理：

python inference_onnx.py

inference_onnx.py 中的ColaONNXPredictor使用onnxruntime.InferenceSession加载模型，输入构造为input_ids与attention_mask的np.expand_dims(..., axis=0)形式，输出经 softmax 后取 argmax，得到 “acceptable / unacceptable” 二分类结果，并返回text、label、score三元组。同时，predict方法被 utils.py 中定义的@timing装饰器包裹，每次推理都会打印耗时（秒），方便在监控场景观察推理延迟。

作为对照，也可用标准 PyTorch 做推理：

python inference.py

inference.py 中的ColaPredictor直接load_from_checkpoint并freeze()模型，输出每个类别的 softmax 分数列表。两种推理路径（PyTorch / ONNX Runtime）并存，正是本仓库演示“如何以不同运行时承载同一模型”的意图所在。

四、数据与模型版本化：DVC + S3

4.1 初始化 DVC 与远端

在仓库根目录执行 DVC 初始化，并把远端指向 S3 bucket：

dvc init # 在仓库根目录执行 dvc remote add -d model-store s3://models-dvc/trained_models/

4.2 配置 AWS 凭证

按 week_9_monitoring/README.md 指引在 AWS 控制台创建凭证，切勿泄露密钥，然后写入环境变量：

export AWS_ACCESS_KEY_ID=<ACCESS KEY ID> export AWS_SECRET_ACCESS_KEY=<ACCESS SECRET>

4.3 托管模型并推送到远端

将训练好的 ONNX 模型纳入 DVC 管理：

cd dvcfiles dvc add ../models/model.onnx --file trained_model.dvc

这条命令会生成 dvcfiles/trained_model.dvc 指针文件，记录模型文件的哈希。接着把模型推送到 S3 远端：

dvc push trained_model.dvc

之后在任何新环境（例如构建 Docker 镜像的 CI 环境）中，只需dvc pull dvcfiles/trained_model.dvc即可按哈希还原同一版本的模型，这正是“模型即版本化资产”的核心实践。

五、容器化：Docker 与 docker-compose

5.1 构建并运行镜像

本模块的 Dockerfile 与其他周次不同：README 明确提示“默认命令已被修改以支持 Lambda，若要脱离 Lambda 运行请使用前一周的 Dockerfile”。构建与本地运行方式：

docker build -t mlops-basics:latest . docker run -p 8000:8000 --name inference_container mlops-basics:latest

或者使用 docker-compose 一键构建并启动：

docker-compose up

docker-compose.yml 定义了名为prediction_api的服务，容器名inference_container，将宿主 8000 端口映射到容器 8000 端口，构建上下文即当前目录。本地以镜像运行时，默认执行的是 Lambda 风格的入口，因此 FastAPI 版的 app.py（提供GET /与GET /predict?text=...接口）更适合作为本地调试服务；若要以 API 形式对外提供推理，建议使用前几周基于 uvicorn/FastAPI 的镜像配置。

5.2 镜像内容剖析

从 Dockerfile 可以看出本模块的镜像设计要点：

基座为amazon/aws-lambda-python，镜像内部具备 Lambda Runtime 的入口约定；
通过ARG AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY接收凭证，并写入容器环境变量；
安装dvc[s3]后在构建阶段dvc init --no-scm、dvc remote add -d model-store s3://models-dvc/trained_models/，再dvc pull dvcfiles/trained_model.dvc把模型拉进镜像——即“镜像在构建期内置模型”；
依赖仅安装 requirements_inference.txt（pytorch-lightning、datasets、onnxruntime、fastapi、uvicorn、dvc、tokenizers、transformers 等推理所需子集），比训练依赖更精简；
构建期执行python lambda_handler.py做一次冒烟验证，确保模型能正常加载与推理；
CMD [ "lambda_handler.lambda_handler"]声明 Lambda 运行时入口。

六、推送到 ECR 与无服务器化

6.1 推送镜像到 ECR

创建 ECR 仓库后，按以下三步推送镜像：

# 1) 认证 Docker 客户端到 ECR aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 246113150184.dkr.ecr.us-west-2.amazonaws.com # 2) 打标签 docker tag mlops-basics:latest 246113150184.dkr.ecr.us-west-2.amazonaws.com/mlops-basics:latest # 3) 推送 docker push 246113150184.dkr.ecr.us-west-2.amazonaws.com/mlops-basics:latest

注意：上面示例中的 AWS 账号 ID 与区域来自 README 演示文本，实际使用时请替换为你自己的 ECR 仓库地址。

6.2 CI/CD 自动化

week_9_monitoring/README.md 提到仓库中的.github/workflows/build_docker_image.yaml（仓库根目录未列出该文件，属文档引用的外部工作流约定）用于“自动构建包含训练模型的镜像并推送 ECR”。整体自动化思路可理解为：CI 拉取代码 → DVC pull 模型 → 构建镜像 → ECR push → Lambda 更新函数。

6.3 Lambda 推理入口

lambda_handler.py 是推理的无服务器入口，逻辑如下：

模块加载时即创建全局ColaONNXPredictor("./models/model.onnx")实例，复用 ONNX Runtime 会话，避免每次调用重复加载模型（Lambda 冷启动后热实例复用）；
lambda_handler(event, context)区分两种输入形态：
- 若event含"resource"键，说明请求来自 API Gateway，从event["body"]解析 JSON 并取sentence，返回包含statusCode、headers、body的标准 API Gateway 响应；
- 否则视为直接调用（如测试），直接以event["sentence"]为输入，返回推理结果对象；
推理结果由predict返回{"text", "prediction": {"label", "score"}}。

if __name__ == "__main__"分支提供本地自测：lambda_handler({"sentence": "this is a sample sentence"}, None)。

七、日志监控：CloudWatch → Elasticsearch → Kibana

这是本模块“监控”主题的核心环节。整体链路为：

用户请求 → API Gateway → Lambda 推理 └─ 运行日志 → CloudWatch Logs → Elasticsearch → Kibana 可视化

7.1 链路原理

Lambda 运行时会自动把函数日志（含print、logging输出）写入 CloudWatch Logs。要将日志可视化，需要：

在 AWS 上创建 Elasticsearch 集群（接收、索引日志）；
将 CloudWatch Logs 与 Elasticsearch 集成（通过 Lambda 订阅或 Logstash 等管道把日志推送到 ES）；
在 Kibana 中配置索引模式并构建 Dashboard，对inference_container/ Lambda 函数日志做检索与可视化。

Lambda 侧 lambda_handler.py 已通过logging.basicConfig()与logger.setLevel(logging.DEBUG)输出“加载模型”“Got the input: …”等结构化日志，这些日志正是监控面板上可检索的数据来源。

7.2 从代码看可监控的信号

结合 inference_onnx.py 的@timing装饰器，每次预测都会输出function:'predict' took: X.XXXX sec，这一信号可作为监控面板上的推理延迟指标。若把这类输出与 CloudWatch 日志一起接入 Kibana，就可以围绕“请求量、推理延迟、错误句子的分布”建立实时看板。

7.3 配置指引

详细的 Kibana / Elasticsearch 集群配置、CloudWatch 日志集成步骤，见 week_9_monitoring/README.md 指向的博文（此处仅说明：需要先创建 ES 集群，再让 CloudWatch 日志流向 ES，最后在 Kibana 中建索引模式与看板）。

八、运行 notebook 的环境配置

仓库使用 Jupyter lab 运行实验 notebook，并且为了确保虚拟环境生效，需要先执行：

conda install ipykernel python -m ipykernel install --user --name project-setup pip install ipywidgets

这样在 Jupyter 中选择project-setup内核即可使用当前 conda 虚拟环境运行 experimental_notebooks/data_exploration.ipynb。

九、总结

week_9_monitoring把前面各周的 MLOps 能力整合成一条可落地的生产链路：训练（W&B 实验监控）→ 导出 ONNX → DVC 版本化到 S3 → Docker 镜像内置模型 → ECR 推送 → Lambda 无服务器推理 → Kibana 日志监控。关键要点：

模型即资产：DVC 哈希保证模型可复现，镜像构建期自动 pull 模型；
双推理路径：PyTorch（inference.py）与 ONNX Runtime（inference_onnx.py）并存，ONNX 更适合容器化与无服务器环境；
Lambda 入口封装了 API Gateway 与直调两种事件格式，冷启动后复用 ONNX 会话；
监控是闭环：训练期有 W&B 指标与样本可视化，部署后有 CloudWatch + Elasticsearch + Kibana 日志链路。

如果希望进一步深入本仓库的完整学习路径，可对照 week_5_docker（FastAPI 镜像方案）、week_6_github_actions（CI/CD 工作流）与 week_7_ecr（ECR 推送）逐周推进；第九周则在其之上补上了无服务器与监控的最后一块拼图。