裸辞半年后，我用 Amazon Q 和 Moltbot 把模型部署效率翻了三倍

去年十一月，我从某大厂裸辞了。不是因为卷不动，纯粹是想喘口气。Gap 的这半年，一边带娃（其实是打游戏），一边刷 LeetCode，顺便研究点 AI 新玩意儿。最近准备跳槽，投了几家，发现面试官开口闭口都是“模型上线”、“推理延迟”、“A/B 测试”——光会调参可不够了，得会部署。

于是，我咬牙接了个外包项目：帮一个做智能客服的初创公司把他们的意图识别模型从 Jupyter Notebook 里“捞”出来，变成能扛住线上流量的 API。听起来简单？呵，等你看到他们用 Flask 写的“生产级”服务，你就知道什么叫“祖传代码”。

今天这篇文章，不讲理论，就聊实战。聊聊我在折腾模型部署时踩过的坑、用过的工具（比如 Amazon Q、Moltbot、Claude、Windsurf），以及最后怎么把 P90 延迟从 800ms 干到 200ms 以下的。

---

一、别再拿 Flask 当“生产环境”了

项目初期，团队给我的“部署方案”是这样的：

from flask import Flask, request
import joblib

app = Flask(__name__)
model = joblib.load("intent_model.pkl")

@app.route("/predict", methods=["POST"])
def predict():
    text = request.json["text"]
    pred = model.predict([text])
    return {"intent": pred[0]}

乍一看，没毛病。但当我用 locust 模拟 50 并发请求时，服务器直接卡死。CPU 飙到 100%，响应时间超过 3 秒。更离谱的是，这个模型加载一次就要 4GB 内存，而他们只配了一台 2C4G 的 EC2 实例。

产品经理还一脸无辜地问我：“你们算法不是说准确率 95% 吗？怎么上线就崩了？”

我心想：准确率高不代表能跑啊兄弟！

---

二、重构部署架构：从单体到容器化

第一步，我干掉了 Flask。不是说它不行，而是它不适合高并发、低延迟的场景。我选了 FastAPI + Uvicorn + Gunicorn 组合：

• FastAPI：异步支持好，自动生成 OpenAPI 文档，调试方便
• Uvicorn：ASGI 服务器，性能比 WSGI 高不少
• Gunicorn：管理多个 worker，避免单点故障

# 启动命令
gunicorn -k uvicorn.workers.UvicornWorker --workers 4 --bind 0.0.0.0:8000 main:app

但光这样还不够。模型加载慢、内存占用高，怎么办？

解法1：模型瘦身 + ONNX 转换

原始模型是 BERT-base，参数量 1.1 亿。我用 Hugging Face 的 transformers 库做了量化和蒸馏，再导出为 ONNX 格式：

from transformers import AutoModelForSequenceClassification, AutoTokenizer
from optimum.onnxruntime import ORTModelForSequenceConversion

model = AutoModelForSequenceClassification.from_pretrained("my_intent_model")
tokenizer = AutoTokenizer.from_pretrained("my_intent_model")

# 导出 ONNX
ORTModelForSequenceConversion.from_pretrained(
    "my_intent_model", 
    export=True,
    provider="CUDAExecutionProvider"  # 如果有 GPU
)

ONNX Runtime 的推理速度比原生 PyTorch 快 2~3 倍，而且内存占用更低。P90 延迟从 800ms 降到 400ms。

解法2：预热 + 模型缓存

很多团队忽略“冷启动”问题。每次请求都重新加载模型？那肯定慢。我把模型加载提到全局作用域，并在服务启动时做一次预热推理：

# main.py
import onnxruntime as ort

# 全局加载
ort_session = ort.InferenceSession("model.onnx")

# 预热
dummy_input = tokenizer("hello", return_tensors="np")
ort_session.run(None, {k: v for k, v in dummy_input.items()})

这一招，让首请求延迟从 1.2s 降到 300ms。

---

三、用 Amazon Q 自动化运维脚本

部署到 AWS 后，运维成了新问题。每次更新模型都要手动 SSH、停服务、换文件、重启……我这种懒人根本受不了。

这时候，我试了 Amazon Q Developer（AWS 最近推的 AI 编程助手）。我直接在 VS Code 里问它：

“写一个 Bash 脚本，自动从 S3 下载最新 model.onnx，替换当前文件，然后重启 Gunicorn 服务”

它秒回：

#!/bin/bash
aws s3 cp s3://my-model-bucket/model.onnx /opt/app/model.onnx
systemctl restart gunicorn

更骚的是，它还能生成 CloudFormation 模板、Terraform 配置，甚至帮你写监控告警规则。虽然有时候会“幻觉”，但配合人工 review，效率提升巨大。

上周五晚上，我边喝冰美式边用 Amazon Q 生成了完整的 CI/CD 流水线：GitHub Push → Build Docker Image → Push to ECR → Deploy to ECS Fargate。整个过程不到 20 分钟。以前在大厂，光走审批流程就得三天。

---

四、Moltbot：让 A/B 测试不再痛苦

模型上线后，怎么验证新版本效果？传统做法是灰度发布，但需要改 Nginx 配置、加权重、看日志……太重了。

我用了 Moltbot（一个开源的轻量级流量切分工具）。它基于 Envoy，支持动态路由规则，配置超简单：

# moltbot-config.yaml
routes:
  - name: intent-service-v1
    weight: 70
    host: intent-service-v1:8000
  - name: intent-service-v2
    weight: 30
    host: intent-service-v2:8000

通过 Web UI 或 API，就能实时调整流量比例。更重要的是，它自动收集每个版本的 latency、error rate、QPS，生成对比报表。

有一次，我上线了一个蒸馏后的小模型，准确率只降了 1%，但延迟降了 60%。Moltbot 的数据一拉，老板当场拍板全量上线。数据驱动决策，真香。

---

五、Claude 和 Windsurf：我的“外挂大脑”

老实说，很多技术细节我也不熟。比如 ONNX 的优化选项、ECS 的 task 定义、Prometheus 的指标采集……这时候，我就靠 Claude 和 Windsurf。

• Claude：长上下文能力强，适合解释复杂概念。比如我问它“ONNX Runtime 的 execution providers 有哪些区别？”，它能列个表，还附带使用场景。
• Windsurf：实时联网，能查最新文档、GitHub issues、Stack Overflow。有一次我遇到 CUDA out of memory，Windsurf 直接搜到 Hugging Face 论坛的解决方案：加 torch.cuda.empty_cache()。

它们不是替代思考，而是加速学习。裸辞这半年，我靠它们啃下了 Triton Inference Server、KServe、BentoML 等一堆部署框架。虽然最后没用上，但知识储备让我在面试时底气十足。

---

六、避坑指南：这些雷千万别踩

1. 别在生产环境用 pickle 保存模型

joblib 或 pickle 有安全风险，且跨版本兼容性差。优先用 ONNX、TorchScript、TensorFlow SavedModel。

2. 日志别打太多

一开始我每条请求都 log 模型输入输出，结果磁盘爆了。后来改用结构化日志 + 采样（比如只 log 1% 的请求），配合 CloudWatch Logs Insights 查询，又快又省。

3. 监控必须做

至少监控：

• 请求延迟（P50/P90/P99）
• 错误率（HTTP 5xx）
• GPU 显存使用率（如果有）
• 模型输入分布漂移（用 Evidently 或 WhyLabs）

4. 别忽略依赖版本

本地跑得好好的，上 Docker 就崩？八成是 requirements.txt 没锁版本。我用 pip freeze > requirements.txt 锁死所有依赖，包括 transitive ones。

---

七、效果对比：从“能跑”到“稳如狗”

指标	旧方案（Flask）	新方案（FastAPI + ONNX + Moltbot）
P90 延迟	820ms	180ms
内存占用	4.2GB	1.1GB
最大并发	20 QPS	200 QPS
部署时间	30分钟（手动）	3分钟（CI/CD）
A/B 测试成本	高（需改网关）	低（Moltbot 动态切流）

上线一周，0 故障。客户说：“你们这系统，比我们之前花 200 万买的商业方案还稳。”

---

写在最后

裸辞这半年，我最大的感悟是：AI 工程师不能只盯着 loss 曲线，得懂部署、懂运维、懂业务。

工具在变，但核心不变：稳定、高效、可观测。

Amazon Q、Moltbot、Claude、Windsurf 这些 AI 工具，不是来取代我们的，而是让我们从重复劳动中解放出来，专注解决真正的问题。

现在，我简历上终于能写“主导端到端 ML 系统落地”了。下周去面一家 AI 初创公司，希望别再让我手写 Transformer 了（笑）。

如果你也在折腾模型部署，欢迎留言交流。或者，一起组队刷题？LeetCode 双周赛见。