模型上线后，真正折磨人的是这五件事

去年我们帮一家做智能客服的创业公司部署 RAG 系统。模型选型、数据清洗、Prompt 调优，这些"体面"的工作花了三周。上线第一天，客户说"效果还行"。

然后噩梦开始了。

第一件事：Token 账单比预期贵三倍

客户给的预估 QPS 是 50，实际峰值冲到 200。更麻烦的是，他们把完整的用户历史对话都塞进上下文窗口——每条请求平均 4000 token 输入，模型返回 800 token。

我们做了三件事：
- 用滑动窗口把上下文截断到最近 20 轮对话
- 对超过 3 天的历史做摘要压缩
- 在网关层加了 QPS 限流和排队机制

结果：单次请求 token 量降到 1200 左右，月账单从预估的 8000 块压到 3500 块。

教训：永远按峰值的 1.5 倍做成本预算，别信客户给的"正常值"。

第二件事：GPU 显存泄漏，每周必崩

用的是开源模型 + vLLM 部署。一切正常，直到第七天——显存占用从 14GB 慢慢爬到 24GB，然后 OOM 崩溃。

排查发现是 vLLM 的 KV cache 在特定 batch size 下没有正确释放。临时方案是写了一个监控脚本，显存超过 20GB 就自动重启服务。根治方案是升级到最新版 vLLM 并调整 max_num_batched_tokens 参数。

教训：开源模型部署不是"跑起来就行"，必须做显存监控和自动恢复。

第三件事：客户的数据格式每天都在变

第一天给的是 JSON，第二天变成了 CSV，第三天直接甩了个 Excel 过来，里面还有合并单元格。

我们被迫在数据接入层写了一个"万能解析器"，支持 JSON、CSV、Excel、甚至 PDF 表格提取。同时加了数据 schema 校验，不符合格式的直接在接入层拦截，返回明确的错误信息。

教训：客户不会按你的规范来。接入层要足够宽容，校验层要足够严格。

第四件事：效果回退没人通知

上线第三周，客服的满意度评分从 85% 掉到 72%。客户没告诉我们，直到月底对账时才发现。

原因是客户那边换了数据源，新数据的标注质量差了很多。我们加了一个效果监控面板，每天自动跑 200 条样本的准确率评估，低于阈值就发告警。

教训：模型效果不是上线就结束的事，必须持续监控，而且监控指标要和客户关心的业务指标对齐。

第五件事：回滚方案根本没准备

有一次我们更新了指向的模型版本，结果新版本的输出格式变了，下游解析全部报错。因为没有回滚脚本，花了两个小时才恢复。

后来我们建立了标准流程：每次模型更新前，先在小流量（5%）上灰度，跑满 24 小时没问题再全量。同时保留上一个版本的镜像和配置，一键回滚。

教训：没有回滚方案的上线，就是在赌博。

写在最后

做 AI 项目交付，模型本身可能只占 30% 的工作量。剩下的 70% 是工程运维——成本控制、稳定性保障、数据治理、效果监控、变更管理。

这些工作不性感，但决定了项目能不能活过第一个月。