企业官网建设流程全解析

很多人学完深度学习理论，真正卡住的地方往往不是反向传播或损失函数，而是“模型训完之后怎么让它跑到生产环境里”。吴恩达这门MLOps课程的Week1，标题是Overview of the ML Lifecycle and Deployment，核心就是把机器学习从“实验室玩具”变成“工业可用系统”的第一步：部署深度学习模型。配套作业也不是让你再调一轮准确率，而是逼着你把模型封装、启动推理服务、处理真实请求，甚至考虑边缘端还是云端跑。这篇就把我完成这类部署作业时的完整思路和实操过程拆给你看，从生命周期大框架到一行一行可复现的代码都有。

这门课适合谁？一是已经有了一个能用的深度学习模型但不知道怎么对外提供服务的同学，二是在做算法落地、想把模型交给工程团队的同学，三是被“部署”这个词吓住、想快速搞清楚全流程的小白。我默认你至少会一点Python，用过TensorFlow或者PyTorch，剩下的跟着做就行。

1. 项目概述：Week1为什么把“生命周期”和“部署”绑在一起

1.1 模型训完不算结束，ML项目的重头戏在后面

很多初学者有个错觉：模型在验证集上跑出95%的准确率就“大功告成”了。实际在企业里，这最多算完成了30%的工作。一个深度学习模型要真正产生价值，必须被人或系统调用，也就是部署上线。MLOps这个名字，说白了就是把机器学习当作一条流水线来运营：从业务问题定义、数据采集、特征工程、模型训练、模型评估，到部署上线、持续监控、迭代更新。Week1用整个生命周期把“部署”放在什么位置讲得清清楚楚。

我在开发一个图像识别Demo时深有体会。模型在离线测试集上表现完美，可一到线上，图片尺寸不对、光线变化、接口超时、GPU显存不足，各种问题全冒出来。这就是生命周期思维缺失的典型症状：只盯着训练环节，没把部署和监控当回事。吴恩达这门课第一周就把生命周期画出来，目的就是让你从一开始就意识到，部署不是训练结束后随便加一步，而是贯穿整个项目始终的设计约束。

1.2 课程要解决的核心痛点：为什么深度学习部署这么难

传统软件部署相对成熟：写代码、编译、打包、放到服务器上跑。但深度学习模型部署多了一层不确定性。模型本身是个黑盒，它的行为依赖训练数据的分布，数据一变，线上效果就可能崩。加上模型文件动辄几百MB，推理一次要几十毫秒甚至几秒，资源消耗和延迟都是实打实的问题。

课程的Week1通过一系列真实案例，把部署模型的方法论总结成了几个关键问题：你这个模型是跑在云端GPU服务器还是用户手机边缘端？推理时延要求是多少？模型需不需要持续学习更新？数据分布漂移了怎么办？这些问题听起来很抽象，但它们直接决定了你在作业里用哪种部署方案。说白了，部署不是“把模型文件复制到服务器”这么简单，而是设计一套系统来承载模型的生命。

2. 部署的技术地图：从模型到可用服务的方案选型

2.1 云端部署与边缘部署的本质区别

作业里最常见的题目，就是给你一个场景，让你判断用云端还是边缘部署。这不是玄学，是有明确依据的工程决策。我画了一张非常实用的对照表，你可以直接拿来做决策参考。

举个例子，如果做一个智能客服机器人，模型需要频繁更新知识库，那就适合放云端，因为不能每次改一句回复就让用户升级APP。但如果做一个残障人士的实时语音助手，网络环境复杂且隐私敏感，就必须考虑端侧推理。我在作业里遇到过一个“野生动物相机识别”场景，设备在野外没有稳定网络，答案毫无疑问是边缘部署加低功耗硬件。

2.2 模型格式与转换：跨框架部署的第一步

无论云端还是边缘，第一步都是把训练好的模型转换成标准化或目标环境可识别的格式。用PyTorch训练的自然不能直接丢给TensorFlow Serving，反之亦然。常见的部署格式有：

• ONNX：跨框架中间格式，PyTorch、TensorFlow都能导出，非常通用。
• SavedModel：TensorFlow原生格式，配合TensorFlow Serving或TFLite非常好用。
• TorchScript / PT格式：PyTorch原生部署格式，配合LibTorch或TorchServe比较省事。
• TFLite / CoreML：面向移动端和边缘设备优化的格式，适合在手机和嵌入式设备上部署。

我在导出ONNX时踩过一个坑：模型里有自定义算子，标准ONNX导出不支持，后来通过注册自定义算子解决。所以你在做作业前一定要先检查模型用到了哪些层，提前确认目标部署框架是否支持。

2.3 作业决策思路：什么场景该用什么方案

作业里常给你几个部署场景，让你做选择题并说明理由。我的答题思路很简单，先看四个要点：

1. 数据能否离开本地（隐私约束）。
2. 网络是否稳定可用。
3. 延迟要求是否苛刻。
4. 模型更新频率和成本。

如果一个应用既需要低延迟，又涉及个人隐私数据，比如手机上的实时美颜滤镜，那铁定是边缘部署。如果数据量大但延迟要求不高，比如舆情分析，那云端集中式部署更合理，因为可以用GPU做批处理，成本也更低。

3. Week1作业实操：从零实现一个深度学习推理服务

3.1 作业目标的拆解：你要交付什么

虽然每周作业形式可能不同，但“部署”类作业的最终交付物非常明确：一个可以被外部请求调用的推理接口。我给自己定的验收标准有四点：

1. 输入一张图片或一段文本，接口能返回预测结果。
2. 服务可以并行处理多个请求，不会一次只能处理一个。
3. 超时、错误输入能被优雅处理，而不是直接崩溃。
4. 有完整的启动、日志、关闭流程，看起来像生产服务的样子。

下面我以一个图像分类模型为例，完整演示怎么做。这个做法对99%的模块化模型都适用，你换成自己的模型一样能跑通。

3.2 环境准备与依赖安装

我习惯用虚拟环境隔离项目，避免依赖污染。这里以Linux环境和Python 3.9为例。

mkdir ml_deploy_demo cd ml_deploy_demo python3 -m venv venv source venv/bin/activate pip install flask torch torchvision

注意，如果你用的是TensorFlow，就把torch torchvision换成tensorflow。这里不需要装一堆后端服务，Flask已经能应付绝大多数教学部署场景。为了防止版本冲突，我建议用一个干净的requirements.txt来锁定版本，让作业结果其他人能直接复现。

flask==2.3.3 torch==2.0.1 torchvision==0.15.2

还需要准备一个已经训练好的模型权重文件。课程作业一般会给你预训练模型或让你用官方样例权重，我这里就用一个在ImageNet预训练的图像分类模型做演示。

3.3 模型封装：把预处理和后处理全部包进函数

部署模型最容易犯的错误，是把训练代码里的预处理逻辑散落在各个地方。线上请求来时，要么忘了归一化，要么忘了调整尺寸，导致推理结果崩掉。正确做法是写一个模型封装类，把预处理、推理、后处理全部塞进去，外部只暴露一个predict方法。

import torch import torchvision.transforms as transforms from torchvision import models from PIL import Image import json class ImageClassifier: def __init__(self, model_path, label_path): self.device = torch.device("cuda" if torch.cuda.is_available() else "cpu") self.model = models.resnet18(weights=None) self.model.fc = torch.nn.Linear(512, 1000) self.model.load_state_dict(torch.load(model_path, map_location=self.device)) self.model.to(self.device) self.model.eval() with open(label_path, "r") as f: self.labels = json.load(f) self.transform = transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ]) def predict(self, image_bytes): image = Image.open(io.BytesIO(image_bytes)).convert("RGB") tensor = self.transform(image).unsqueeze(0).to(self.device) with torch.no_grad(): outputs = self.model(tensor) probs = torch.softmax(outputs, dim=1) conf, idx = torch.max(probs, dim=1) label = self.labels[str(idx.item())] return {"label": label, "confidence": round(conf.item(), 4)}

注意self.model.eval()是关键。PyTorch模型默认是训练模式，如果不切换，BatchNorm和Dropout的行为会完全不一样，部署后结果会“飘”。这个坑极其隐蔽，我见过不止一个同学在部署作业里栽在这里。

3.4 推理API实现：Flask封装HTTP接口

模型封装好后，接口部分就相对简单了。我用Flask写一个/predict端点，接收POST上传的图片文件，返回JSON结果。

import io from flask import Flask, request, jsonify app = Flask(__name__) classifier = ImageClassifier("resnet18_weights.pth", "imagenet_labels.json") @app.route("/predict", methods=["POST"]) def predict(): if "image" not in request.files: return jsonify({"error": "no image uploaded"}), 400 file = request.files["image"] image_bytes = file.read() try: result = classifier.predict(image_bytes) return jsonify(result) except Exception as e: return jsonify({"error": str(e)}), 500 @app.route("/health", methods=["GET"]) def health(): return jsonify({"status": "ok"}) if __name__ == "__main__": app.run(host="0.0.0.0", port=8080)

这个接口看起来简单，但已经涵盖了生产服务的基本要素：健康检查、错误码、异常捕获。你在作业里可以再扩展一个/batch_predict来提高吞吐量，或者加上请求日志中间件。

为什么用Flask而不是FastAPI？因为课程环境里Flask是最常见的，依赖少、文档多、出问题容易查。实际企业的确更倾向FastAPI的异步能力和类型校验，但教学场景求稳优先，框架不重要的地方别折腾。

3.5 调用测试与结果验收

服务启动之后，可以用curl模拟真实请求。

curl -X POST -F "image=@cat.jpg" http://127.0.0.1:8080/predict

返回结果示例：

{"label": "tabby cat", "confidence": 0.9137}

为了确认服务在高并发下不崩，我用Python写了一个并发测试脚本，同时发20个请求。

import concurrent.futures import requests def send_request(path): with open(path, "rb") as f: resp = requests.post("http://127.0.0.1:8080/predict", files={"image": f}) return resp.status_code file_paths = ["cat.jpg"] * 20 with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor: results = list(executor.map(send_request, file_paths)) print(set(results))

实测下来，CPU模式下40个请求平均耗时大约在150毫秒左右。这个数字提醒我一件事：如果不加self.device判断，GPU环境自然没问题，但CPU环境会特别慢。所以在作业里一定要明确标注运行环境，否则老师复现作业时延迟表现会完全不同。

3.6 作业报告中必须写清楚的技术细节

这门课的老师很看重你在作业里对部署选型的解释。光把代码跑通不够，还得写清楚每一个选择的理由。我写报告的习惯是包含以下几个部分：

• 模型结构、训练框架、模型文件大小。
• 部署目标环境（CPU/GPU、内存限制、并发量假设）。
• 为什么选择云端或边缘部署。
• 预处理/后处理的具体流程。
• 压测结果比较（QPS、延迟P99）。
• 如果要上线，还缺哪些环节（日志、监控、模型更新流程）。

我特别强调QPS和延迟P99这两个指标，因为生产部署里大家最关心的就是这两件事。作业代码可以只跑通，但报告如果你能写清楚这两个指标，立刻就能和专业工程师看齐。

4. 部署之后：监控、漂移与模型更新

4.1 推理性能指标：延迟与吞吐量的权衡

作业里很多时候只让你把服务跑起来，但其实你推送到线上后，最要紧的指标是延迟和吞吐量。延迟指的是从发出请求到收到结果的时间，吞吐量则代表单位时间能处理多少请求。两者常常矛盾：单次推理越快，延迟越好，但如果一次只处理一个请求，吞吐量就上不去。工业界通常用批处理（batch inference）来平衡两者，把多个请求凑成一个batch一次性跑完，牺牲少量延迟换取整体吞吐量的大幅提升。

我在一个文本分类任务里实测过，单请求推理耗时80毫秒，把8个请求拼成一个batch后，单个请求耗时变成120毫秒，总吞吐量却从12QPS提升到约66QPS。如果你的场景是离线的批量分析，批处理非常合适，但实时交互场景就不太适合。

4.2 数据漂移：线上模型慢慢失效的原因

部署作业不会让你真跑几个月监控，但理解这一点对回答课程提问非常关键。数据漂移是线上模型失效的最常见原因：训练数据来自过去的分布，线上流量却在慢慢变化。比如一个图像分类模型是在晴天街景上训练的，上线后赶上连续阴雨天，识别精度会直线下降。

吴恩达在Week1花了很多篇幅讲这个问题，因为ML的生命周期不是线性的，而是闭环。你部署之后必须不断监控模型表现，一旦发现漂移，就要重新收集数据、重新训练、再次部署。这就是MLOps里“持续训练”和“持续部署”的由来。我在作业里通常会补上一节，用KL散度或PSI指标来量化输入分布变化，这算是给作业加分的亮点。

4.3 灰度发布、回滚与A/B测试的作业延伸

如果你的模型真的进入生产环境，不可能第一天就让100%流量切到新模型。先切10%观察效果，没问题再逐步放量，万一出问题立即回滚到旧版本，这就是灰度发布。A/B测试则是同时跑新旧两个模型版本，按用户维度分流，比较业务指标决定哪个版本上线。

这些在课程视频中都有提及。作业实现里我不建议全部做一遍，但报告里写清楚设计方案，能够显著体现你对部署生命周期的理解。我当时在作业里加了一个非常简单的版本号参数，模型文件名带版本，服务启动时选择加载哪个，这样就已经具备基本的版本切换能力。

5. 常见问题与排查技巧实录

5.1 “模型加载失败”类问题

这类问题占我踩坑的一半。最常见的是PyTorch的torch.load在GPU环境训练的权重，在CPU环境下加载失败。解决办法是加载时加上map_location=torch.device('cpu')，或者训练完保存时直接state_dict()，而不是保存整个模型对象。另一个常见问题是模型类定义和权重不匹配，比如你作业里换了一个预训练模型结构，但加载的还是旧权重。先打印model结构检查最终层大小，再通过异常信息反查断言，往往很快就能定位。

5.2 “推理很慢”类问题

CPU慢是正常的，但如果慢到不可接受，就要检查是不是没有切换eval模式，或者每次请求都重复初始化模型、重复加载权重。一个隐蔽的性能杀手是你把图片转换处理写在了predict外部，每次请求都重新编译transform，实际上这应该只初始化一次。另一个常见问题是本地调试时开的线程数过大，导致资源争抢。建议先用单进程单线程确定基线，再逐步加并发，观察延迟曲线变化。

5.3 “输入数据报错”类问题

作业里的测试图片五花八门，可能是RGBA四通道PNG，可能是灰度图，也可能是一张损坏的残缺文件。我的经验是，预处理里统一做一次convert("RGB")，能规避大量通道不一致的问题。OpenCV读进来的是BGR不是RGB，如果你用PIL训练但用OpenCV读图，不转换就会颜色错乱，模型输出完全不可信。这些看似不起眼的小坑，恰恰是部署和训练代码最大的不同点。

我把这些常见问题整理成了排查速查表，方便你直接对照：

5.4 独家避坑技巧：先做端到端最小验证

做部署作业时最容易犯的错是一上来就完善前端界面、折腾Docker、写K8s配置，结果模型还没跑通，时间全浪费了。我的建议始终是先做最小闭环：直接从一张图片到返回JSON结果，确认模型封装和API接口没问题，再去添加并发、Docker、监控那些外围能力。先让单条路径跑通，再丰富工程细节。这套思路同样适用于任何模型部署作业，不管是图像、文本还是语音。

另外一个小技巧：保留一份完整的请求日志。在生产环境里，没有日志就等于睁眼瞎。你在作业里加一行print(request.remote_addr, len(image_bytes), result['label'])，立刻就能看到哪些请求成功了、哪些消耗时间过长、哪些数据格式是异常的。日志虽然简单，但它是后续监控和排障的地基。

结束语：部署作业透露出的MLOps思维

我做完这个Week1的部署作业，最深的体会不是“我会用Flask写API了”，而是终于理解了为什么吴恩达要把“ML Lifecycle and Deployment”放在课程最开始。真正难的不是把模型放进服务里，而是把一个模型当作一个持续运转的系统来维护：部署前要选型，部署后要监控，数据变了要重新训练，模型变了要平滑更新。没有这种全生命周期视角，你最多只是个模型训练师，而不是ML工程师。

如果你正在啃这门课，我给你一个具体的建议：作业完成后，不要急着交，先自己再造一个假设场景，比如把同一个模型部署到边缘设备或换成另一种部署框架，再跑一遍流程。这样折腾几次，你对部署的理解会比单纯刷作业深刻得多。这也是我目前带新人时最常用的一套训练方式，效果远好过反复看视频。