上线与运维：量化上线、缓存、监控与成本看板
硬件前提
单卡 24GB 起（自托管路线）；走 API 则不需要 GPU，但同样要这一套运维纪律。
上线前：量化版本怎么定
不要直接拿别人发布的 Q4 上线。流程：
- 选两个候选档位（如 Q5_K_M 与 Q4_K_M）；
- 用你自己的业务评测集（不是公开榜单）各跑一遍；
- 记录三列：质量分、每秒 token、可支持并发；
- 选「质量下降可接受」里最省的那一档。
经验：摘要/改写类任务 Q4 通常无痛；多步推理与精确输出常在 Q4 出现可见退化，需要回到 Q5/Q8 或换更大底座。
版本与回滚（最容易漏的一件事）
一次上线同时有三个版本，必须一起记：
| 版本 | 记什么 |
|---|---|
| 模型 | 底座 + 量化档位 + （LoRA 版本） |
| 提示 | 提示模板文件哈希 |
| 检索 | 索引版本 + embedding 模型名 |
任何一项单独变更都可能让线上变差。回滚必须能一键回到「模型+提示+索引」的旧组合，而不是只回滚模型。
缓存：把固定前缀放前面
多数 API 的提示缓存只对开头完全相同的部分生效。做法：
- system、工具说明、常用静态资料 → 放最前，措辞保持稳定；
- 用户输入、时间戳、随机 ID → 放后面；
- 会话内历史只追加，不重写前缀。
效果：命中部分的价格大幅下降，首 token 延迟也降。先改排列顺序，再谈换模型。
并发与降级
| 层 | 做法 |
|---|---|
| 入口 | 队列 + 限速，避免瞬时并发打爆显存 |
| 路由 | 简单任务走小模型；失败或低置信升级到大模型 |
| 降级 | 超时/限流时返回兜底文案或排队提示，而不是 500 |
| 熔断 | 连续失败或成本超阈值时停止调用，保护预算 |
监控：四个必看的指标
| 指标 | 阈值思路 | 异常通常意味着 |
|---|---|---|
| 首 token 延迟 / 每秒 token | 按 P50、P95 看 | 上下文变长、并发过高 |
| 错误率与重试率 | 重试率 >5% 就该查 | 限流、超时、解析失败 |
| 每请求 token 成本 | 周环比 | 上下文滚雪球、重试风暴、检索塞太多 |
| 质量代理指标 | 拒答率、解析失败率、用户重问率 | 模型/提示/索引某一项被改动 |
每日回归：把 30～50 条评测集当定时任务跑，分数掉超过阈值就告警。这是唯一能提前发现「悄悄变差」的办法。
成本看板（三行就够）
- 每天调用次数、输入/输出 token 总量、总成本；
- 按场景拆分（哪个功能最烧钱）；
- 缓存命中率与路由到小模型的比例。
多数成本失控都能在这三行里定位：某个场景的历史没裁剪，或某个功能全量走了大模型。
常见事故与处理
| 事故 | 根因 | 预防 |
|---|---|---|
| 换模型后格式全崩 | 只测了公开榜单 | 上线前跑业务评测集 |
| 成本一周涨 3 倍 | 对话历史无限增长 | 历史裁剪 + 成本告警 |
| 线上质量缓慢变差无人知 | 没有回归集 | 每日定时评测 |
| 供应商改模型导致行为变化 | 版本没锁定 | 锁版本号，灰度切换 |
| 注入导致越权 | 外部内容当指令 | 最小权限 + 两段式确认 |
| 单卡被打满 | 无队列无限流 | 入口限速 + 熔断 |
完成标志
- 一次可回滚的上线（模型+提示+索引三件套版本化）；
- 四个指标有看板与告警；
- 每日回归评测在跑，且有一次「靠回归发现变差」的实际记录。
到这里，「使用」这一档的闭环就完整了：本地跑通 → 选型 → 服务 → API → 上下文 → RAG → Agent → 数据 → 微调 → 训练决策 → 上线运维。