📑 本页目录（点开跳转）
13 · LLMOps：把它当软件来运维
⏱ 28 分钟 ｜ ⭐ 你已经会大半
🎯 一句话
LLM 应用比传统软件多了三个麻烦：输出不确定、成本按量计费、质量会悄悄退化。LLMOps 就是应对这三件事的工程实践。
🆚 和传统 DevOps 的三个不同
流程图
💀 「静默退化」的四个真实来源
| 来源 | 典型场景 | 你什么时候才会发现 |
|---|---|---|
| 供应商换版本 | gpt-4 这类不带日期的别名指向了新模型 |
用户投诉时 ⚠️ |
| 用户输入分布漂移 | 产品火了，来了完全不同的一批用户 | 转化率跌了才查 |
| RAG 索引腐烂 | 文档更新了但索引没重建 | 用户说"它引用的是旧政策" |
| 提示词被人改了 | 有人为了修一个 case 改了共享提示词 | 别的 case 悄悄坏掉 ⭐ |
🔑 最实用的一条防线：别用不带版本号的模型别名。 用
claude-opus-5这种明确 ID 而不是latest一类的浮动别名—— 升级应该是你主动做的决定，而不是某天早上醒来发现的事实。
📉 怎么"看见"静默退化
操作步骤
- 最低成本的方案（一小时能搭好）：
- 准备 30~50 条【固定的】评测输入（覆盖你的核心场景）
- 每天定时跑一次，记录分数
- 分数掉出历史波动范围就告警 ⭐
- ⚠️ 关键在"固定"——输入变了，分数变化就没有意义了
💡 和《机器学习基础》第 5 章同一条纪律： 先测出噪声基准（同一套输入连跑 5 次的分数波动）， 才能判断"今天掉了 3%"是真退化还是随机波动。
🔧 五个核心实践
① 版本化一切
关键信息
- 要一起版本化的：
- 提示词（⭐ 最容易被忽略，改一个字效果可能大变）
- 模型名与参数（温度、max_tokens）
- 评测集
- RAG 的索引和切分配置
- 工具定义
- 👉 把提示词当代码管：进 git、走 code review、能回滚
② 可观测性（Tracing）
信息关系
③ 成本控制
| 手段 | 说明 | 典型节省 |
|---|---|---|
| Prefix Caching | 第 6 章，Agent 场景省最多 | 可达 90%（缓存命中部分）⭐ |
| 模型路由 | 简单请求给小模型（智能体第 2 章顾问策略） | 视分流比例，常 50%+ |
| 输出长度限制 | max_tokens 是硬约束 | 直接可控 |
| 缓存重复请求 | 语义相同的问题直接返回缓存 | FAQ 场景可达 30%+ |
| 预算护栏 | 单用户/单会话上限，防失控（智能体第 1 章 max_steps 的成本版） | 防的是尾部灾难 |
⚠️ Prefix Caching 有一条布局铁律： 把"每次都变的东西"放在提示词末尾，不变的放开头。 一个放在开头的时间戳会让缓存命中率变成 0% —— 因为前缀一变，整个缓存就失效了。这是最容易犯也最贵的一个错。
💰 成本该怎么算（单位经济性）
算一算
❌ 只看月账单总额 → 涨了不知道为什么
✅ 算【每次对话的成本】和【每个用户的月成本】⭐
单次对话成本 = (输入token × 输入单价) + (输出token × 输出单价)
÷ 命中缓存的折扣
⭐ 关键要记录的三个数：
· p50 / p95 单次对话成本 ← p95 才是失控风险所在
· 每个功能入口的成本占比 ← 找出那个吃掉 60% 预算的功能
· 成本 / 业务价值 ← 唯一真正重要的比值
💡 一个反直觉的现实：
输出 token 通常比输入贵 3~5 倍。 所以"让模型少说废话"（限制 max_tokens、要求简洁输出、用结构化格式） 往往比压缩输入更省钱——而大多数人在优化输入。
④ 持续评测
对照
上线前：跑评测集（智能体第 14 章）
上线后：抽样评测线上真实流量 ⭐
供应商更新时：立刻重跑全套 ← 最容易被忽略的一环
⑤ 数据飞轮
🚨 上线检查清单（浓缩版）
要点
☐ 提示词在 git 里，能回滚
☐ 有评测集，上线前必跑
☐ 有完整 tracing，能回放任意一次请求
☐ 成本有监控和上限护栏
☐ 有降级方案（模型挂了怎么办）
☐ 输出有校验（JSON 能解析？必填字段在？）
☐ 有灰度和 A/B 能力
☐ 供应商更新时有重测流程
☐ 线上失败会回流到评测集
🔗 更完整的版本在智能体教程附录 B，那份是给 Agent 场景的，这份是通用 LLM 应用的。
🔗 和站内其他章的关系
这一章几乎全部是你已学内容的重组：
| 已学的 | 对应 |
|---|---|
| 评测方法论（智能体第 14 章） | 持续评测 |
| 结构化 trace（挑战项目 A） | 可观测性 |
| 顾问策略、Prefix Caching | 成本控制 |
| 降级与护栏（智能体第 16 章） | 可靠性 |
| 循环工程（智能体第 16 章） | 数据飞轮 |
| A/B 实验（推荐算法第 12 章） | 灰度发布 |
📦 深挖的话要学什么
📍 每条后面标了它在哪： 📗 本库有 = 站内已经讲透，点进去就行；📙 半有 = 站内讲了一半，另一半得外找； 📕 要外找 = 站内没有，得去论文或别处。 （这份清单以前只列词不说去哪，指到的坑有些站内根本没挖过，按图索骥会扑空。） ⚠️ 这一章有个特殊情况：本章下面的判断是「不值得单独成套，80% 是已学内容的重新组织」。 下面的标记正好把这句话坐实了——大部分条目 📗 都指向别的板块，而不是指向"还没学的东西"。
- 工具链：LangSmith / Langfuse / Weights & Biases / Phoenix 等观测平台 → 📕 要外找：Weights & Biases 站内一次都没出现过；LangSmith / Langfuse / Arize Phoenix 只在 Claude博客 · 智能体评测-01 揭开评测面纱 的结尾被一句带过（「框架加速进度，但代替不了高质量的任务和评分器」），站内没有任何一个展开讲过。但先别急着去查文档——智能体工程 16b · 框架这层皮 讲的正是「框架替你做了什么、没替你做什么」这套判断方法，⭐ 拿它去看观测平台，比直接读产品文档更快看清哪些是你自己必须想清楚的。工具会换，这套判断不会
- 提示词管理：版本化、模板化、A/B、灰度 → 📙 半有：灰度和回滚的机制站内讲得很细——模型上线之后 03 · 灰度影子与回滚（影子流量、灰度节奏、回滚的前置条件），版本可复现在 17 · 版本回溯与可复现。这些是为模型版本写的，但换成提示词版本，机制一模一样。 只有"提示词模板该怎么组织"这一小块要外找
- 网关层：多供应商路由、限流、重试、fallback、统一计费 → 📙 半有：限流、超时取消、优雅关闭、健康检查、过载降级——AI基础设施 20 · 推理服务化 的「生产必备的五件事」逐条给了做法（⚠️ 客户端断开必须立刻停止生成并释放 KV Cache，这是一个真实且昂贵的 bug）。但"多供应商路由 + 统一计费"这一层站内没有，要外找——它是 API 应用特有的，自建推理那边不存在这个问题
- 在线评测：抽样策略、自动评分、告警阈值 → 📗 本库有，三块拼齐了：自动评分和抽样在 智能体工程 14 · 评测Evals（三类评分器 + 八步）；"没有标签怎么发现退化"在 模型上线之后 07——这正是本章「静默退化」那一节缺的方法；告警阈值在 模型上线之后 08 · 告警为什么没人看，⭐ 阈值设不对的后果不是漏报而是没人看，那一章讲的就是这件事
- 成本建模：单位经济性（每次对话/每个用户成本） → 📗 本库有：智能体工程 02 · 模型与 effort 选对大脑 的三个反直觉成本事实（大模型可能反而更便宜；小模型干活+大模型把关；长上下文比你以为的贵）、智能体工程 16 · 企业落地与生产化 的「算账的三条口诀」；自建那一侧在 AI基础设施 23 · 可观测性与成本，容量规划在 模型上线之后 18 · 成本与容量
- 缓存：精确缓存 vs 语义缓存的取舍 → 📙 半有：Prefix Caching（提示词前缀级的精确缓存）在 06 · 推理优化 和 AI基础设施 17 · 连续批处理与PagedAttention 都讲了，本章和 主线 1 · 文字怎样进入模型 还给了"不变的内容放最前面才能命中"这条布局规则。但应用层的语义缓存（用向量近似判断"问过没"）站内没有，要外找——⚠️ 它的坑也不在技术上：语义近似不等于答案可复用，缓存命中率和错答率是一对
需要的前置：后端/运维基础。没有新理论，全是工程实践。
⚖️ 要不要深挖
| 你的情况 | 建议 |
|---|---|
| 有 LLM 应用要上生产 | ✅ 必须做，但不必"学"——照着检查清单做即可 |
| 还在做原型 | ⛔ 先做出来再说，别过早工程化 |
| 做平台/基础设施 | ✅ 值得深挖网关和观测层 |
🔑 我的判断：这块不值得单独成套。 它 80% 是你已学内容的重新组织，剩下 20% 是具体工具（且工具变化快，看文档就行）。
✅ 现状更新：这些内容现在已经在《智能体工程教程》里了—— 评测看第 14 章、可观测性看挑战项目 A、循环工程看第 16 章、上线清单看附录 B。 本章的价值是给你一个"通用 LLM 应用"视角的浓缩版，深挖直接去那边。
✅ 检查点
- LLM 应用比传统软件多了哪三个麻烦？
- 「静默退化」有哪四个来源？最实用的一条防线是什么？
- 怎么用最低成本"看见"静默退化？为什么输入必须固定？
- Prefix Caching 有什么布局铁律？违反了会怎样？
- 成本该怎么算？为什么要看 p95 而不只看均值？
- 输入 token 和输出 token 哪个贵？这对优化方向有什么影响？
- 提示词该怎么管理？
- 什么是数据飞轮？
👀 答案
- 输出不确定（测试不能断言精确值）、成本按量计费且可变、质量会静默退化。
- ①供应商换版本 ②用户输入分布漂移 ③RAG 索引腐烂 ④提示词被人改了（为修一个 case 改了共享提示词，别的悄悄坏掉）。最实用的防线：别用不带版本号的模型别名——升级该是你主动的决定，不是某天醒来的事实。
- 准备 30~50 条固定的评测输入，每天定时跑，分数掉出历史波动范围就告警。输入必须固定，否则分数变化没有意义（分不清是模型变了还是题变了）。同时要先测噪声基准（同套输入连跑 5 次的波动），才能判断"掉 3%"是真退化还是随机。
- 把每次都变的东西放提示词末尾，不变的放开头。一个放在开头的时间戳会让缓存命中率变成 0%——前缀一变整个缓存失效。
- 算每次对话成本和每个用户月成本，而不只看月账单总额。看 p95 是因为尾部才是失控风险所在——均值正常但 p95 爆炸的场景很常见。
- 输出通常比输入贵 3~5 倍。所以让模型少说废话（限 max_tokens、要求简洁、用结构化输出）往往比压缩输入更省钱——而大多数人在优化输入。
- 当代码管：进 git、code review、可回滚、和模型参数一起版本化。改一个字效果可能大变。
- 线上真实失败案例回流进评测集，驱动改进，上线后再收集新失败，形成闭环。即"循环工程"——修流程，不修单个产出。
🛑 可以停在这里
⚡ 走神救援
先记住这几件事
- 把模型、提示词、索引与配置一起版本化，才能定位变化。
- 记录可回放的调用链，同时监控质量、延迟和单次任务成本。
- 用固定样例测出正常波动，再让线上失败回流到评测中。
下一节 👉 14-合规与伦理.md