LLMOps与生产化
核对日期：2026-05-13。
不稳定项：模型价格、API 限流、供应商 SLA、网关能力、Batch API、缓存计费、OpenTelemetry 语义约定、LLMOps 工具版本会持续变化；上线前必须核对当前官方文档、账单和压测数据。
专题文件索引
本阶段已拆分为 5 个专题文件。README.md 仍保留完整阶段讲义和练习入口；专题文件用于深入学习和后续站点导航。
| 专题 | 重点 |
|---|---|
| 01-模型网关与Provider适配.md | 内部 AI SDK、LLM Gateway、Provider Adapter、统一请求响应、streaming 和错误分类 |
| 02-路由Fallback与降级.md | 模型路由、retry、fallback、熔断、降级、高风险任务处理 |
| 03-成本预算与缓存.md | 成本账本、预算维度、缓存 key、Batch、成本异常排查 |
| 04-可观测性与Trace.md | trace span、metrics、logs、RAG/Agent 观测、日志脱敏 |
| 05-灰度发布回滚与供应商治理.md | 发布门禁、灰度、A/B、回滚、kill switch、供应商风险 |
生产闭环交叉引用
LLMOps 负责把 Agent、评测和安全控制变成可运营的平台能力：
| 当前问题 | 继续阅读 |
|---|---|
| Agent 工具、状态和 trace 从哪里来 | ../09-Agent系统设计/01-agent-loop与控制流.md |
| 变更上线前如何设定 eval 和发布门禁 | ../10-评测体系/05-线上评测与发布门禁.md |
| RAG、Agent 和安全负例如何做分层评测 | ../10-评测体系/01-评测集与Rubric设计.md |
| Gateway 和供应商治理如何处理数据与合规风险 | ../11-安全与治理/05-事故响应供应链与合规治理.md |
| 日志、缓存和输出处理如何避免二次泄漏 | ../11-安全与治理/03-数据外泄与输出处理.md |
1. 阶段目标
本阶段目标是掌握 AI 系统生产化所需的 LLMOps 能力。LLMOps 不是“把调用封装一下”，而是把模型调用变成可路由、可观测、可预算、可灰度、可回滚、可审计的生产平台能力。
学完本阶段，你应该能做到：
- 解释为什么生产 AI 系统需要 LLM Gateway 或模型访问层。
- 设计多模型路由、fallback、重试、熔断和降级策略。
- 设计缓存、Batch、队列、限流和预算控制。
- 建立 token、成本、延迟、错误、模型版本、Prompt 版本和 trace 的可观测体系。
- 设计模型和 Prompt 的灰度发布、A/B 测试、回滚和发布门禁。
- 评估供应商风险、区域合规、数据保留和密钥治理。
- 为高峰流量、上游故障、模型退化和成本异常设计运营预案。
本阶段的核心产出是：
- 一个 LLMOps 架构方案。
- 一张模型路由和 fallback 表。
- 一份监控指标面板设计。
- 一份灰度发布和回滚流程。
- 一份成本治理方案。
2. 学习前置条件
建议已完成：
08-AI应用工程，理解 streaming、异步任务、缓存和成本账本。09-Agent系统设计，理解工具、状态和 trace。10-评测体系，理解评测集、回归和发布门禁。11-安全与治理，理解权限、审计和供应商风险。- 具备基础服务端、监控和运维认知。
不要求：
- 自研完整 LLM Gateway。
- 立即接入十几个模型供应商。
- 在第一版就建立大型平台团队。
3. 核心知识地图
4. 详细讲义
4.1 为什么需要 LLMOps
单个 demo 可以直接调用模型 API；生产系统不行。
生产环境会遇到：
- 多业务团队都要调用模型。
- 多模型、多供应商、多区域。
- 价格、速率、配额经常变化。
- 上游模型失败或变慢。
- Prompt 和模型版本需要灰度。
- 需要统一日志、成本、审计和安全策略。
- 需要回滚和停用开关。
LLMOps 的目标：让模型调用像数据库、缓存和消息队列一样，成为可治理的基础设施能力。
4.2 LLM Gateway 的作用
LLM Gateway 是业务应用和模型供应商之间的访问层。
核心能力：
| 能力 | 说明 |
|---|---|
| 统一 API | 屏蔽不同 provider 参数和响应差异 |
| 鉴权 | 用户、租户、团队、功能级访问 |
| 路由 | 按任务、成本、延迟、质量选择模型 |
| 限流 | 控制请求速率和并发 |
| 预算 | 控制 token 和金额 |
| 重试 | 处理瞬时错误 |
| Fallback | 上游失败时切换方案 |
| 缓存 | 降低重复请求成本 |
| 观测 | 记录 token、延迟、错误和 trace |
| 审计 | 记录谁调用了什么模型 |
| 安全 | 脱敏、DLP、策略检查 |
Gateway 不一定必须自研，可以用云服务、开源网关或内部 SDK 起步。关键是统一治理入口。
4.3 内部 AI SDK 和 Provider Adapter
业务代码不应该散落调用各家模型 SDK。推荐分两层：
业务应用 -> 内部 AI SDK -> LLM Gateway / Provider Adapter -> 模型供应商
内部 SDK 负责：
- 标准请求对象。
- 标准响应对象。
- 错误分类。
- usage 字段。
- trace 上下文。
- Prompt version。
Provider Adapter 负责：
- 参数映射。
- 流式事件转换。
- 工具调用协议适配。
- 错误码归一。
- usage 提取。
- provider request id 记录。
这样模型切换不会污染业务代码。
4.4 模型路由策略
模型路由不是“便宜优先”这么简单。
常见路由维度：
| 维度 | 示例 |
|---|---|
| 任务类型 | 分类、摘要、代码、RAG、Agent |
| 风险等级 | 低风险用小模型，高风险用强模型 |
| 延迟要求 | 实时交互优先低延迟 |
| 成本预算 | 免费用户和企业用户不同 |
| 上下文长度 | 长文档需要长上下文模型 |
| 模态 | 文本、图像、音频 |
| 区域合规 | 数据不能出特定区域 |
| 评测结果 | 按任务 eval 分数选择 |
路由表示例：
| 任务 | 默认模型 | Fallback | 约束 |
|---|---|---|---|
| 分类 | small-fast | medium | 低温度，JSON |
| RAG 问答 | medium | strong | 必须引用 |
| 合同审查 | strong | human_review | 高风险，不自动降级到弱模型 |
| 批量摘要 | batch-cheap | queued | 可延迟 |
| Agent 工具规划 | strong | stop_escalate | 不盲目 fallback |
高风险任务不要在失败时自动切到未经评测的弱模型。
4.5 Retry、Fallback、熔断和降级
| 机制 | 解决问题 | 风险 |
|---|---|---|
| Retry | 瞬时网络或 429 | 重复扣费、非幂等副作用 |
| Fallback | 上游不可用 | 输出质量变化 |
| Circuit breaker | 上游持续失败 | 误判导致可用性下降 |
| Degradation | 保留核心功能 | 体验变差 |
重试策略：
- 只对可重试错误重试。
- 指数退避。
- 设置最大次数。
- 幂等请求才自动重试。
- streaming 中断要单独处理。
降级示例：
- 强模型不可用 -> 返回排队状态。
- RAG rerank 不可用 -> 使用 hybrid top k 并降低置信度。
- 生成失败 -> 提供模板或人工处理。
- Agent 工具失败 -> 停止并交接给人。
4.6 缓存和成本优化
缓存策略：
| 类型 | 适用 | 注意 |
|---|---|---|
| 精确缓存 | 相同输入、相同版本 | key 包含权限和版本 |
| Prompt prefix cache | 长系统提示和长上下文 | 依赖 provider 支持 |
| Semantic cache | FAQ 类相似问题 | 高风险任务慎用 |
| Retrieval cache | 热点检索结果 | 权限入 key |
| Tool cache | 外部 API 结果 | 注意数据过期 |
缓存 key 必须包含：
- tenant_id / user_scope。
- feature。
- model。
- prompt_version。
- input_hash。
- output_schema_version。
- rag_index_version。
- policy_version。
成本优化顺序：
- 减少无效 token。
- 选择合适模型。
- 缓存重复输入。
- 对离线任务用 batch。
- 对长任务异步化。
- 优化 RAG top_k 和 rerank。
- 用小模型做前置分类或路由。
不要为了省钱牺牲高风险任务的正确性和安全性。
4.7 Batch 和异步处理
Batch 适合：
- 离线摘要。
- 大量分类。
- 数据清洗。
- 评测运行。
- 周期性报告。
不适合：
- 实时聊天。
- 用户等待的交互。
- 高风险且需要逐条审批的任务。
Batch 任务设计：
- 输入文件版本。
- 任务 ID。
- 模型和 Prompt 版本。
- 失败重试策略。
- 输出校验。
- 成本估算。
- 结果回写和审计。
4.8 限流、配额和预算
限流控制系统稳定，预算控制成本风险。
维度：
- 用户级。
- 租户级。
- 应用级。
- 功能级。
- 模型级。
- 工具级。
- 时间窗口级。
策略：
- 免费用户低额度。
- 企业租户独立预算。
- 高风险任务单独配额。
- 异常 token 增长报警。
- 单请求最大 input/output token。
- 单 Agent 最大步骤数。
预算超限处理：
- 提示用户缩短输入。
- 排队等待。
- 切换低成本模式。
- 请求管理员批准。
- 停止任务并保存状态。
4.9 可观测性：Trace、Metrics、Logs
AI 系统需要普通服务观测，也需要 LLM 特有字段。
Trace span 建议：
request
auth
prompt.build
rag.retrieve
rag.rerank
model.call
output.parse
tool.call
eval.sample
模型调用字段：
| 字段 | 说明 |
|---|---|
| model | 模型 |
| provider | 供应商 |
| prompt_version | Prompt 版本 |
| input_tokens | 输入 token |
| output_tokens | 输出 token |
| cached_tokens | 缓存 token |
| cost | 预估成本 |
| latency_ms | 总延迟 |
| first_token_ms | 首 token 延迟 |
| finish_reason | 结束原因 |
| error_type | 错误类型 |
| retry_count | 重试次数 |
| fallback_used | 是否 fallback |
日志要脱敏。不要为了可观测性牺牲隐私和合规。
4.10 监控告警
监控面板至少包含：
| 类别 | 指标 |
|---|---|
| 可用性 | 成功率、错误率、provider 状态 |
| 延迟 | P50/P95/P99、首 token 延迟 |
| 成本 | 每日成本、功能成本、租户成本 |
| 用量 | 请求数、token 数、工具调用数 |
| 质量 | eval 通过率、用户反馈、采纳率 |
| 安全 | 拦截数、越权尝试、敏感信息命中 |
| Agent | 平均步数、循环中止、人类介入率 |
告警示例：
- 某模型错误率超过 5%。
- 某功能 token 成本比 7 日均值上涨 50%。
- P95 首 token 延迟超过阈值。
- 安全拦截突然增加。
- fallback 比例异常上升。
- eval 每日抽样通过率下降。
4.11 灰度、A/B 测试和回滚
AI 变更必须灰度：
- 模型升级。
- Prompt 变更。
- RAG 索引策略变更。
- 路由策略变更。
- 安全策略变更。
- 工具 schema 变更。
灰度步骤：
离线 eval 通过
-> 内部用户灰度
-> 1% 流量
-> 10% 流量
-> 50% 流量
-> 全量
每一步都看：
- 质量指标。
- 成本。
- 延迟。
- 错误率。
- 安全拦截。
- 用户反馈。
回滚要求：
- Prompt 可回滚。
- 模型路由可回滚。
- RAG 索引可回滚。
- 工具权限可关闭。
- Gateway 有 kill switch。
4.12 供应商治理
供应商治理要关注：
- 数据保留和训练政策。
- 企业合规协议。
- 区域和数据驻留。
- SLA 和状态页。
- 价格和计费口径。
- 模型版本稳定性。
- 限流和配额。
- 日志和审计能力。
- 退出方案。
不要把业务完全绑定在单一供应商的非标准能力上。可以使用抽象层，但也要避免最低公分母设计导致高级能力用不上。
4.13 Prompt、模型和数据版本管理
生产调用必须能复现：
- 业务功能版本。
- Prompt id/version。
- 模型名和版本。
- 推理参数。
- 输出 schema version。
- RAG index version。
- 工具 schema version。
- policy version。
版本记录让你能回答：
- 为什么今天答案和昨天不同？
- 这次成本上涨是谁造成的？
- 哪个 Prompt 版本引入了格式错误？
- 哪个索引版本导致召回下降？
4.14 容量规划
AI 系统容量规划要看：
- QPS。
- 并发 streaming 连接数。
- 平均和峰值 token。
- 上游限流。
- 队列堆积。
- worker 并发。
- RAG 检索耗时。
- rerank 耗时。
- 工具调用耗时。
高峰期策略：
- 限制低优先级任务。
- 降低 max output tokens。
- 延迟离线任务。
- 关闭非必要 rerank。
- 切换备用供应商。
- 提示用户排队。
4.15 LLMOps 成熟度模型
| 等级 | 特征 |
|---|---|
| L0 Demo | 直接调用模型，无日志 |
| L1 应用封装 | 有 SDK、错误处理、token 记录 |
| L2 统一网关 | 统一鉴权、路由、成本、日志 |
| L3 评测门禁 | Prompt/模型变更有 eval 和灰度 |
| L4 平台治理 | 多团队预算、安全、审计、供应商管理 |
| L5 持续优化 | 线上反馈自动进入 eval，成本和质量动态优化 |
大多数团队应先做到 L2-L3，再考虑更复杂的平台化。
5. 关键概念表
| 概念 | 含义 | 工程意义 | 常见问题 |
|---|---|---|---|
| LLM Gateway | 模型访问层 | 统一治理 | 单点故障 |
| Provider Adapter | 供应商适配层 | 屏蔽 API 差异 | 抽象过薄或过厚 |
| Routing | 模型路由 | 成本/质量/延迟平衡 | 规则不可解释 |
| Fallback | 失败切换 | 提升可用性 | 质量不一致 |
| Circuit Breaker | 熔断 | 防止持续失败拖垮系统 | 阈值不当 |
| Batch | 批处理 | 降低离线成本 | 不适合实时 |
| Budget | 预算 | 控制成本 | 维度太粗 |
| Trace | 调用链 | 定位问题 | 日志含敏感数据 |
| Release Gate | 发布门禁 | 防止回归 | 阈值随意 |
| Kill Switch | 停用开关 | 事故止血 | 没有预案 |
6. 工程案例
6.1 企业内部模型网关
目标：所有业务团队通过统一入口调用模型。
能力：
- 团队级虚拟 key。
- 每团队预算。
- 模型白名单。
- 日志和审计。
- 成本报表。
- 安全策略。
价值：避免每个业务服务各自保存供应商密钥和重复实现限流、日志、重试。
6.2 多模型成本路由
场景：内容分类、摘要、RAG 问答和合同审查都使用 AI。
策略：
- 分类走小模型。
- 普通摘要走中模型。
- 合同审查走强模型 + 人工复核。
- 离线批量任务走 batch。
评测：每个路由策略必须绑定任务 eval，不允许只按价格切模型。
6.3 高峰期降级
场景：活动期间请求量暴涨，上游 429 增加。
降级：
- 低优先级任务排队。
- 非核心生成功能暂停。
- max output tokens 降低。
- 离线任务延后。
- 部分请求切备用 provider。
要求：用户界面要明确显示排队或降级状态。
6.4 Prompt 版本灰度
场景：客服草稿 Prompt 从 v1.7 升到 v1.8。
流程：
- 离线 eval 通过。
- 5% 内部灰度。
- 观察采纳率、编辑距离、投诉率。
- 出现关键指标下降时回滚到 v1.7。
记录：每条调用必须带 prompt_version。
6.5 成本异常排查
现象：某天 AI 成本上涨 80%。
排查：
- 按功能聚合 token。
- 按 prompt_version 对比。
- 查看平均 input_tokens。
- 查看 RAG top_k 是否变大。
- 查看 Agent 平均步数。
- 查看重试和 fallback。
常见根因：历史消息未裁剪、Prompt 变长、RAG 召回过多、Agent 循环。
7. 常见误区与反模式
| 反模式 | 表现 | 后果 | 修正 |
|---|---|---|---|
| 业务直连模型 | 每个服务自己放 key | 难治理、难审计 | 统一 Gateway |
| 路由只看价格 | 便宜模型处理高风险任务 | 质量事故 | 基于 eval 路由 |
| 盲目 fallback | 上游失败切任意模型 | 行为不一致 | fallback 也要评测 |
| 无成本账本 | 只看总账单 | 无法定位 | 按功能/用户/token 记录 |
| 日志全量明文 | 调试方便 | 隐私风险 | 脱敏和访问控制 |
| Prompt 不版本化 | 线上手改 | 无法回滚 | Prompt registry |
| 模型升级无灰度 | 直接全量切换 | 质量回归 | eval + 灰度 |
| 没有 kill switch | 出事故只能发版 | 扩大影响 | 功能开关和回滚 |
| 忽略上游限流 | 只压测自己服务 | 线上 429 | 容量和配额规划 |
| 观测只看延迟 | 不看质量和安全 | 错误不被发现 | 质量指标入面板 |
8. 阶段练习
8.1 模型网关路由表
为以下任务设计路由：
- 文本分类。
- 文档摘要。
- RAG 问答。
- 合同风险审查。
- Agent 工具规划。
每个任务写默认模型、fallback、预算、评测门禁和安全要求。
8.2 成本预算设计
为 3 类用户设计预算：
- 免费用户。
- 团队用户。
- 企业租户。
包含日额度、月额度、单请求 token 上限和超限处理。
8.3 429 降级策略
设计上游 429 时的处理：
- 哪些请求重试。
- 哪些请求排队。
- 哪些请求 fallback。
- 哪些请求直接失败。
- 用户看到什么提示。
8.4 监控面板
画出 AI 系统监控面板，至少包含：
- 请求量。
- 成功率。
- 延迟。
- token。
- 成本。
- fallback。
- eval 通过率。
- 安全拦截。
8.5 灰度和回滚流程
为一次模型升级设计：
- 离线 eval。
- 灰度比例。
- 观察指标。
- 回滚阈值。
- 事故通知。
- 复盘和回归样例。
9. 项目任务
9.1 项目要求
完成一个 LLMOps 架构方案。
必须包含：
- 业务应用到模型供应商的架构图。
- Gateway 或内部 SDK 设计。
- 模型路由表。
- fallback、retry、熔断和降级策略。
- 缓存和 batch 策略。
- 成本账本和预算。
- 监控告警面板。
- Prompt/模型/RAG 版本管理。
- 灰度发布和回滚。
- 数据、日志和供应商治理。
9.2 架构方案模板
# LLMOps 架构方案
## 1. 背景和目标
## 2. 系统架构
## 3. Gateway / SDK 设计
## 4. 模型路由和供应商管理
## 5. Retry / Fallback / 降级
## 6. 缓存、Batch 和异步任务
## 7. 成本账本和预算
## 8. 可观测性和告警
## 9. 评测门禁和灰度发布
## 10. 安全、日志和合规
## 11. 容量规划
## 12. 事故响应和回滚
9.3 评分标准
| 维度 | 分值 | 标准 |
|---|---|---|
| 架构完整性 | 20 | Gateway、SDK、provider、应用边界清晰 |
| 路由与降级 | 20 | 路由可解释，fallback 和降级有质量约束 |
| 成本治理 | 15 | 有 token、预算、缓存和 batch 策略 |
| 可观测性 | 15 | trace、metrics、logs 和面板完整 |
| 发布治理 | 15 | eval、灰度、A/B、回滚流程明确 |
| 安全合规 | 15 | 密钥、日志、供应商和数据治理清楚 |
10. 验收题
- 为什么生产 AI 系统需要 LLM Gateway？
- Provider Adapter 应该屏蔽哪些差异？
- 模型路由为什么不能只看价格？
- Retry、fallback、熔断和降级分别解决什么问题？
- AI 缓存 key 为什么必须包含权限、模型和版本？
- Batch 适合哪些任务，不适合哪些任务？
- 成本账本应该记录哪些字段？
- AI 系统监控除了延迟和错误率，还应该看什么？
- Prompt 和模型升级为什么必须灰度？
- 生产事故中 kill switch 和回滚如何设计？
11. 延伸阅读
官方与工具资料
- Cloudflare AI Gateway: https://developers.cloudflare.com/ai-gateway/
- LiteLLM Documentation: https://docs.litellm.ai/docs/
- OpenTelemetry Documentation: https://opentelemetry.io/docs/
- OpenAI Batch API: https://developers.openai.com/api/docs/guides/batch
- OpenAI Production best practices: https://developers.openai.com/api/docs/guides/production-best-practices
- LangSmith Tracing: https://docs.smith.langchain.com/observability
建议阅读方式
- 先读 Gateway 文档，理解统一入口能提供哪些治理能力。
- 再读 OpenTelemetry，把 trace、metrics、logs 和现有监控体系接上。
- 最后读 Batch、路由、缓存和成本相关文档，建立生产运营视角。
12. 本阶段总结
LLMOps 的核心是把模型调用从“业务代码里的一个 API 请求”升级为“可治理的平台能力”。它解决的不是模型聪不聪明，而是稳定性、成本、延迟、版本、观测、发布、安全和供应商风险。
你应该形成一个判断：只要 AI 能力进入生产，就必须能回答这些问题：谁调用了哪个模型，花了多少钱，为什么失败，能不能回滚，是否越权，质量有没有退化。
下一阶段进入 AI 产品与业务落地。你会学习如何判断哪些 AI 能力值得做，如何设计 ROI、产品体验、组织流程和业务验收。