示例工程【免费下载链接】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 WB数据/模型版本化DVC S3模型导出PyTorch → ONNX服务化FastAPI Docker无服务器化AWS Lambda镜像部署日志监控CloudWatch → Elasticsearch → Kibana从源码结构看week_9_monitoring目录下同时保留了 app.pyFastAPI 推理服务、lambda_handler.pyLambda 入口与 Dockerfile以amazon/aws-lambda-python为基座入口指向 lambda_handler可以推断本模块的实际运行形态是“Lambda 镜像承载推理”而 FastAPI 版本主要服务于本地调试与 Docker 直接运行场景。环境要求Python 3.8。创建虚拟环境并安装依赖conda create --name project-setup python3.8 conda activate project-setup pip install -r requirements.txt二、训练PyTorch Lightning WB 实验跟踪2.1 训练入口安装依赖后直接运行python train.py训练脚本 由hydra.main(config_path./configs, config_nameconfig)装饰训练配置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取最小与EarlyStoppingpatience3使用WandbLogger将训练过程记录到 WB 项目 “MLOps Basics”。2.2 WB 面板查看训练结束时日志尾部会输出类似wandb: Synced 5 WB 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点击链接即可进入 WB 仪表盘查看全部图表。值得说明的是这些图表并非仅靠框架自动生成——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形式记录到 WB方便人工检查模型在哪些句子上犯错。这为“监控”主题提供了训练侧的实验监控能力。三、模型导出PyTorch → ONNX3.1 导出命令训练完成后执行python convert_model_to_onnx.pyconvert_model_to_onnx.py 从models/best-checkpoint.ckpt加载 checkpoint取一个训练 batch 作为示例输入调用torch.onnx.export导出到models/model.onnx。关键导出参数opset_version10ONNX 算子集版本input_names[input_ids, attention_mask]对应 BERT 的 token 输入与注意力掩码output_names[output]模型输出dynamic_axes将batch_size维度声明为动态轴使导出模型可接受任意 batch 大小的输入。3.2 ONNX 推理导出后可用 ONNX Runtime 做推理python inference_onnx.pyinference_onnx.py 中的ColaONNXPredictor使用onnxruntime.InferenceSession加载模型输入构造为input_ids与attention_mask的np.expand_dims(..., axis0)形式输出经 softmax 后取 argmax得到 “acceptable / unacceptable” 二分类结果并返回text、label、score三元组。同时predict方法被 utils.py 中定义的timing装饰器包裹每次推理都会打印耗时秒方便在监控场景观察推理延迟。作为对照也可用标准 PyTorch 做推理python inference.pyinference.py 中的ColaPredictor直接load_from_checkpoint并freeze()模型输出每个类别的 softmax 分数列表。两种推理路径PyTorch / ONNX Runtime并存正是本仓库演示“如何以不同运行时承载同一模型”的意图所在。四、数据与模型版本化DVC S34.1 初始化 DVC 与远端在仓库根目录执行 DVC 初始化并把远端指向 S3 bucketdvc 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_IDACCESS KEY ID export AWS_SECRET_ACCESS_KEYACCESS SECRET4.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-compose5.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 updocker-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.txtpytorch-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七、日志监控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 能力整合成一条可落地的生产链路训练WB 实验监控→ 导出 ONNX → DVC 版本化到 S3 → Docker 镜像内置模型 → ECR 推送 → Lambda 无服务器推理 → Kibana 日志监控。关键要点模型即资产DVC 哈希保证模型可复现镜像构建期自动 pull 模型双推理路径PyTorchinference.py与 ONNX Runtimeinference_onnx.py并存ONNX 更适合容器化与无服务器环境Lambda 入口封装了 API Gateway 与直调两种事件格式冷启动后复用 ONNX 会话监控是闭环训练期有 WB 指标与样本可视化部署后有 CloudWatch Elasticsearch Kibana 日志链路。如果希望进一步深入本仓库的完整学习路径可对照 week_5_dockerFastAPI 镜像方案、week_6_github_actionsCI/CD 工作流与 week_7_ecrECR 推送逐周推进第九周则在其之上补上了无服务器与监控的最后一块拼图。赞分享示例工程【免费下载链接】MLOps-Basics项目地址https://gitcode.com/GitHub_Trending/ml/MLOps-Basics点击查看免费下载相关推荐MLOps-Basics Week 8 实战将 ONNX 模型封装为 Docker 镜像并部署到 AWS Lambda 无服务器推理MLOps Basics Week 8 实战将 ONNX 模型封装为 Docker 镜像并部署到 AWS Lambda 无服务器推理 本指南以开源仓库 MLO示例工程Handsontable 实时数据更新实战通过 WebSocket 与 setDataAtRowProp 实现股票行情网格Handsontable 实时数据更新实战通过 WebSocket 与 setDataAtRowProp 实现股票行情网格 本篇技术指南讲解如何将 Hands示例工程MLOps-Basics 第四周实战将 PyTorch Lightning 模型导出为 ONNX 并使用 ONNX Runtime 加速推理MLOps Basics 第四周实战将 PyTorch Lightning 模型导出为 ONNX 并使用 ONNX Runtime 加速推理 导读 本文聚焦示例工程上一篇downkyi文件夹命名终极指南5种智能分类方法让下载视频井井有条下一篇clipboard.js构建工具配置ESBuild与SWC性能对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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 WB数据/模型版本化DVC S3模型导出PyTorch → ONNX服务化FastAPI Docker无服务器化AWS Lambda镜像部署日志监控CloudWatch → Elasticsearch → Kibana从源码结构看week_9_monitoring目录下同时保留了 app.pyFastAPI 推理服务、lambda_handler.pyLambda 入口与 Dockerfile以amazon/aws-lambda-python为基座入口指向 lambda_handler可以推断本模块的实际运行形态是“Lambda 镜像承载推理”而 FastAPI 版本主要服务于本地调试与 Docker 直接运行场景。环境要求Python 3.8。创建虚拟环境并安装依赖conda create --name project-setup python3.8 conda activate project-setup pip install -r requirements.txt二、训练PyTorch Lightning WB 实验跟踪2.1 训练入口安装依赖后直接运行python train.py训练脚本 由hydra.main(config_path./configs, config_nameconfig)装饰训练配置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取最小与EarlyStoppingpatience3使用WandbLogger将训练过程记录到 WB 项目 “MLOps Basics”。2.2 WB 面板查看训练结束时日志尾部会输出类似wandb: Synced 5 WB 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点击链接即可进入 WB 仪表盘查看全部图表。值得说明的是这些图表并非仅靠框架自动生成——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形式记录到 WB方便人工检查模型在哪些句子上犯错。这为“监控”主题提供了训练侧的实验监控能力。三、模型导出PyTorch → ONNX3.1 导出命令训练完成后执行python convert_model_to_onnx.pyconvert_model_to_onnx.py 从models/best-checkpoint.ckpt加载 checkpoint取一个训练 batch 作为示例输入调用torch.onnx.export导出到models/model.onnx。关键导出参数opset_version10ONNX 算子集版本input_names[input_ids, attention_mask]对应 BERT 的 token 输入与注意力掩码output_names[output]模型输出dynamic_axes将batch_size维度声明为动态轴使导出模型可接受任意 batch 大小的输入。3.2 ONNX 推理导出后可用 ONNX Runtime 做推理python inference_onnx.pyinference_onnx.py 中的ColaONNXPredictor使用onnxruntime.InferenceSession加载模型输入构造为input_ids与attention_mask的np.expand_dims(..., axis0)形式输出经 softmax 后取 argmax得到 “acceptable / unacceptable” 二分类结果并返回text、label、score三元组。同时predict方法被 utils.py 中定义的timing装饰器包裹每次推理都会打印耗时秒方便在监控场景观察推理延迟。作为对照也可用标准 PyTorch 做推理python inference.pyinference.py 中的ColaPredictor直接load_from_checkpoint并freeze()模型输出每个类别的 softmax 分数列表。两种推理路径PyTorch / ONNX Runtime并存正是本仓库演示“如何以不同运行时承载同一模型”的意图所在。四、数据与模型版本化DVC S34.1 初始化 DVC 与远端在仓库根目录执行 DVC 初始化并把远端指向 S3 bucketdvc 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_IDACCESS KEY ID export AWS_SECRET_ACCESS_KEYACCESS SECRET4.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-compose5.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 updocker-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.txtpytorch-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七、日志监控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 能力整合成一条可落地的生产链路训练WB 实验监控→ 导出 ONNX → DVC 版本化到 S3 → Docker 镜像内置模型 → ECR 推送 → Lambda 无服务器推理 → Kibana 日志监控。关键要点模型即资产DVC 哈希保证模型可复现镜像构建期自动 pull 模型双推理路径PyTorchinference.py与 ONNX Runtimeinference_onnx.py并存ONNX 更适合容器化与无服务器环境Lambda 入口封装了 API Gateway 与直调两种事件格式冷启动后复用 ONNX 会话监控是闭环训练期有 WB 指标与样本可视化部署后有 CloudWatch Elasticsearch Kibana 日志链路。如果希望进一步深入本仓库的完整学习路径可对照 week_5_dockerFastAPI 镜像方案、week_6_github_actionsCI/CD 工作流与 week_7_ecrECR 推送逐周推进第九周则在其之上补上了无服务器与监控的最后一块拼图。赞分享示例工程【免费下载链接】MLOps-Basics项目地址https://gitcode.com/GitHub_Trending/ml/MLOps-Basics点击查看免费下载相关推荐MLOps-Basics Week 8 实战将 ONNX 模型封装为 Docker 镜像并部署到 AWS Lambda 无服务器推理MLOps Basics Week 8 实战将 ONNX 模型封装为 Docker 镜像并部署到 AWS Lambda 无服务器推理 本指南以开源仓库 MLO示例工程Handsontable 实时数据更新实战通过 WebSocket 与 setDataAtRowProp 实现股票行情网格Handsontable 实时数据更新实战通过 WebSocket 与 setDataAtRowProp 实现股票行情网格 本篇技术指南讲解如何将 Hands示例工程MLOps-Basics 第四周实战将 PyTorch Lightning 模型导出为 ONNX 并使用 ONNX Runtime 加速推理MLOps Basics 第四周实战将 PyTorch Lightning 模型导出为 ONNX 并使用 ONNX Runtime 加速推理 导读 本文聚焦示例工程上一篇downkyi文件夹命名终极指南5种智能分类方法让下载视频井井有条下一篇clipboard.js构建工具配置ESBuild与SWC性能对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考