部署的本质是让模型可被网页调用、用户访问且稳定运行，核心为模型轻量化（ONNX/TorchScript+量化）、接口标准化（FastAPI+Pydantic）、服务容器化（Docker+Nginx）。
想把训练好的模型真正用起来，不是只在Jupyter里跑通就行，得让它能被网页调用、被用户访问、稳定不崩——这才是“部署”的本质。核心就三点：模型轻量化、接口标准化、服务容器化。
模型导出与轻量化处理
PyTorch或TensorFlow训完的模型不能直接扔进Web服务。要先转成推理友好的格式，比如ONNX（跨框架通用）或TorchScript（PyTorch原生加速），再用量化（int8）、剪枝或知识蒸馏进一步压缩体积和延迟。
- PyTorch推荐走torch.jit.trace或torch.onnx.export，注意固定输入尺寸和关闭dropout/BN训练模式
- ONNX模型可用onnxruntime加载，比原生框架快2–5倍，还支持GPU/CPU自动切换
- 别忽略预处理逻辑：缩放、归一化、resize这些必须和模型一起固化，否则前后端数据不一致会静默出错
用FastAPI搭轻量推理API
不用Django或Flask大框架，FastAPI自带异步、自动文档（Swagger）、类型校验，几行代码就能暴露一个带JSON输入输出的端点。
- 定义Pydantic模型描述请求体，比如{"image_base64": str}，FastAPI自动校验+解析
- 模型加载放在lifespan事件里，启动时一次载入内存，避免每次请求都reload
- 加个@app.post("/predict")，里面做base64解码→tensor转换→model()→结果序列化，全程同步也够用；高并发可改用线程池或asyncio.to_thread
Docker打包 + Nginx反向代理
本地能跑不等于线上可靠。用Docker把Python环境、模型文件、API代码全打包成镜像，消除“在我机器上是好的”问题；Nginx负责负载、HTTPS、静态资源托管和请求限流。
- Dockerfile里用multi-stage build：build阶段装编译依赖（如onnxruntime-gpu），final阶段只复制编译好的wheel和模型，镜像缩小60%+
- 模型文件别硬编码路径，通过环境变量传入（如MODEL_PATH=/app/models/best.onnx），方便不同环境切换
- Nginx配置里加proxy_buffering off和client_max_body_size 10M，适配图片/音频上传场景
前端调用与错误兜底
网页调用API不是写个fetch就行，要考虑加载态、超时重试、错误提示、离线降级。用户不会看控制台报错，只会觉得“这网站坏了”。
- 用AbortController控制请求超时（建议设8–12秒），后端也要设timeout，避免长尾请求拖垮服务
- 对4xx错误展示友好提示（如“图片太大，请压缩到5MB以内”），5xx错误统一打日志并引导刷新或稍后再试
- 关键模型能力可预加载到Web Worker或用WASM做极简本地fallback（比如纯JS实现的轻量人脸检测），提升弱网体验
基本上就这些。不复杂但容易忽略细节——模型没固化预处理、API没设超时、Docker没清缓存、前端没做loading反馈，任何一个都可能让上线变救火现场。
