第 18 章：LLMOps、部署与生产化¶

1. 本章要解决的问题¶

到第 17 章为止，我们已经把一个大模型应用最吸引人的部分讲出来了：

能检索知识
能调用工具
能围绕目标多步完成任务

如果只是在 notebook、本地脚本或者课程 demo 里跑通，这已经很不错了。

但只要你真的把系统交给别人用，问题立刻会变一类。

不再只是：

这个回答看起来对不对？

而会变成：

为什么今天延迟突然翻倍了？
为什么这周 token 成本超预算？
为什么同一个问题线上和本地答案不一样？
为什么新版本上线后 citation 变少了？
为什么 Agent 开始频繁调用无关工具？

这时你会发现：

从“把功能做出来”到“把系统稳定跑起来”，中间隔着一整套工程问题。

这就是 LLMOps 要处理的内容。

如果说前几章主要解决的是：

模型怎样训练
模型怎样对齐
模型怎样接知识和工具

那么本章要解决的就是：

当这些能力进入真实环境后，怎样部署、监控、评估、回滚，并把质量、延迟和成本一起管起来。

从全书结构上看，这一章也是前面所有内容的落地收束：

第 15 章讲知识如何变成可检索对象
第 16 章讲 RAG 如何把检索接进回答
第 17 章讲 Agent 如何调用外部能力完成任务
本章讲这些系统上线后如何真正“像产品一样活着”

2. 你学完后应该会什么¶

能解释什么是 LLMOps，以及它和传统 MLOps、后端运维的联系与差别
能说明为什么大模型 demo 往往很惊艳，但 production 往往很脆弱
能画出一个最小可用的 LLM 服务架构：网关、应用层、模型层、检索层、日志监控层
能理解吞吐、延迟、成本、质量之间为什么总在互相拉扯
能描述常见推理优化方法：streaming、batching、cache、量化、路由
能区分 offline eval、online eval、人工抽检各自解决什么问题
能理解生产系统里为什么必须做 prompt/version/model/config 的可追踪管理
能从工程视角识别发布、灰度、回滚、告警、安全和预算控制的关键点

3. 为什么 demo 和 production 差这么远¶

很多人第一次做大模型应用时，都会经历一个很典型的错觉：

本地已经能答对了，为什么上线后还是一堆问题？

因为 demo 证明的通常只是：

在若干理想样例上，这个思路可能有效。

而 production 要证明的是：

在真实用户、真实流量、真实脏数据、真实预算约束下，系统还能持续有效。

这两件事不是一个难度级别。

3.1 demo 通常只看“能不能做”¶

例如你本地做一个课程问答助手，可能只验证了：

问几条示例问题能不能答出来
检索结果看起来相关不相关
模型输出是不是通顺

这些当然重要，但还不够。

3.2 production 还要看“能不能稳定地做”¶

上线后你还要面对：

高峰流量时是否超时
某个上游模型 API 波动时如何降级
文档更新后索引是否同步
prompt 改动后效果是否回退
错误回答是否能被发现和定位
每天预算是否会被异常请求打爆

所以一个很重要的认知是：

LLM 产品的问题，只有一部分是“模型问题”，另一大部分其实是“系统问题”。

3.3 大模型系统比普通服务多了哪些不稳定性¶

和传统后端服务相比，LLM 系统往往额外引入了几类不确定性：

输出不是严格确定的
质量很难用单一指标衡量
prompt 微调可能导致行为明显变化
上下文长度、tool use、检索结果都会影响输出
成本和延迟会随输入长度、模型选择、调用链深度一起变化

这意味着你不能只盯着 HTTP 200。

对 LLM 系统来说，很多时候：

接口成功返回，不等于用户真的成功。

4. 什么是 LLMOps¶

可以先给一个偏工程而不是偏概念的定义。

LLMOps 就是围绕大模型应用的开发、部署、评估、监控、迭代与治理的一整套工程实践。

它和传统 MLOps 有重叠，但又不完全一样。

4.1 它和 MLOps 的相同点¶

相同点包括：

都关心版本管理
都关心部署与发布
都关心监控和告警
都关心评估与回归测试

4.2 它和传统 MLOps 的不同点¶

不同点主要在于，大模型应用往往多了这些对象：

prompt
system instruction
retrieval pipeline
tool schema
context construction
model routing
conversation state

也就是说，被管理的不再只是“模型文件”。

你真正要管理的是一整条推理链路。

4.3 更准确地说，LLMOps 管的是“系统行为”¶

一个线上回答变差，问题可能来自：

模型换了
prompt 改了
检索 top-k 变了
rerank 关了
chunk 逻辑更新了
工具超时了
上下文截断了

因此 LLMOps 的核心不是只看某个单点组件，而是：

把最终用户体验往回拆，映射到整条链路的可观测、可评估、可回滚。

5. 一个最小生产化 LLM 系统长什么样¶

不妨先建立一个整体图景。

一个最小可用的生产系统，通常至少包含下面几层：

接入层：Web、App、API 网关
应用编排层：prompt 构造、会话管理、工具路由、权限控制
模型推理层：本地推理服务或外部模型 API
知识与工具层：向量库、数据库、搜索、内部接口、执行器
观测治理层：日志、指标、评估、告警、灰度、回滚

可以把它粗略画成：

User
  ↓
API / Gateway
  ↓
LLM App Server
  ├─ Prompt Builder
  ├─ Session Memory
  ├─ RAG Pipeline
  ├─ Tool Router
  └─ Guardrails
  ↓
Model Serving
  ├─ Hosted API
  └─ Self-hosted Inference
  ↓
Data / Tools
  ├─ Vector DB
  ├─ SQL / KV
  ├─ Search
  └─ Internal APIs
  ↓
Observability
  ├─ Logs
  ├─ Metrics
  ├─ Traces
  └─ Eval Dashboard

注意这里最容易被忽略的一点：

模型只是其中一层，不是整个系统。

6. 部署并不只是“把模型 API 调起来”¶

很多初学者会把“部署”理解成：

写个 FastAPI，然后转发到模型接口。

这当然是第一步，但离真正可用还差很多。

6.1 生产部署至少要回答四个问题¶

请求怎么进来，如何鉴权、限流、记录？
应用怎么组织上下文、检索、工具和模型调用？
模型如何服务，容量如何规划，失败如何降级？
出问题后，怎样发现、定位和回滚？

6.2 托管 API 和自部署推理，各自适合什么场景¶

先建立一个很实用的判断。

托管 API 的优点¶

接入快
省去推理基础设施维护
模型升级方便
适合快速验证产品方向

托管 API 的代价¶

成本更难压到极致
延迟和配额受上游影响
可控性有限
某些数据合规要求下不方便

自部署模型的优点¶

可控性更强
可以做更细的推理优化
私有化和数据隔离更容易
对稳定高流量业务可能更经济

自部署模型的代价¶

需要显存、机器、调度和运维能力
模型升级、量化、并发调优都要自己做
容量估算失误会直接影响 SLA

现实里常见的做法往往不是二选一，而是分层：

核心链路用稳定模型
长尾复杂任务走更强模型
非关键任务走便宜模型

这就是后面会讲到的模型路由。

7. 推理性能：线上最先把你打醒的问题¶

在 production 里，用户最直观的体验通常不是“loss 多少”，而是：

快不快
稳不稳
贵不贵

这三个问题里，性能几乎总是最早暴露出来的。

7.1 你至少要关心两个指标¶

latency：单次请求多久返回
throughput：单位时间能处理多少请求

很多优化都是在这两者之间做权衡。

7.2 延迟为什么经常比你想象中高¶

一次看似简单的问答，实际可能包含：

网关接入
用户鉴权
查询改写
embedding
检索
rerank
prompt 拼接
模型生成
工具调用
后处理

如果是 Agent，这里面还可能循环多轮。

所以延迟不是只看“模型生成多久”，而是整条链路的累计结果。

7.3 streaming：先把第一段内容尽快吐出来¶

对聊天产品来说，用户往往并不要求“整体完成时间绝对最短”，而更在意：

有没有马上开始响应。

这就是 streaming 的价值。

即使总耗时没变太多，只要首 token 时间明显缩短，主观体验就会好很多。

7.4 batching：提高吞吐，但不一定降低单用户等待¶

batching 的核心思想是：

把多个请求攒在一起算，提高硬件利用率。

它通常有利于：

GPU 吃满
单位 token 成本下降
高并发场景吞吐提升

但 batching 也可能带来：

队列等待时间变长
低并发时收益不明显
实时交互体验下降

所以你要分场景看：

离线任务适合 aggressive batching
在线对话更需要平衡首响应时间

7.5 cache：很多钱不是靠更强模型省的，而是靠别重复算¶

LLM 系统里最容易立刻见效的优化之一就是 cache。

常见缓存包括：

prompt cache
retrieval cache
embedding cache
response cache
tool result cache

例如一个课程问答系统里，很多热门问题其实会被重复问。

如果答案生成逻辑、知识版本和权限范围都一致，那么缓存命中后就可以显著降低：

延迟
token 成本
上游 API 压力

但缓存一定要小心两个问题：

过期策略
权限隔离

共享缓存如果不考虑租户或用户权限，可能直接造成数据泄漏。

7.6 KV cache 和长上下文成本¶

当上下文越来越长时，推理成本会迅速上升。

这也是为什么很多系统即使模型支持超长上下文，也不应该无脑全塞。

你要意识到：

上下文越长，延迟通常越高
token 越多，成本通常越高
无关上下文过多，还可能让答案变差

所以生产优化的一个基本原则是：

给模型足够的信息，而不是给模型所有信息。

7.7 quantization：用更便宜的资源跑起来¶

如果是自部署模型，量化通常是绕不过去的主题。

它的核心目标是：

在尽量少损失效果的前提下，降低显存占用和推理成本。

但量化不是银弹。

你不能只问：

能不能从 FP16 变成 8-bit 或 4-bit？

还要问：

变完后准确率掉多少？
复杂推理是否更差？
工具调用稳定性会不会下降？

8. 质量、延迟、成本为什么总在互相拉扯¶

做 LLM 产品时，一个非常现实的感受是：

你几乎不可能同时把质量、延迟、成本都优化到极致。

8.1 想提升质量，常见做法往往会变贵变慢¶

例如：

换更强模型
给更长上下文
加 rerank
做多路采样
让 Agent 多走几步

这些通常都可能提升效果，但也常常意味着更多 token、更多链路步骤和更高延迟。

8.2 想压成本，常见做法往往会伤效果¶

例如：

换更小模型
降低 max tokens
少检索一些文档
减少工具调用次数
减少多轮规划

这样能省钱，但很可能把边缘问题、复杂问题、长上下文问题一起伤掉。

8.3 所以生产系统真正需要的是“分层策略”¶

比较常见的做法包括：

简单问题走小模型
高风险问题走强模型
首轮用便宜模型分类，再决定是否升级
热门问题优先走缓存
低价值请求做更严格限流

这类策略的本质不是追求单点最优，而是：

让整体系统在预算内达到足够好的体验。

9. 成本控制：别等账单来了才开始学¶

大模型应用最容易在早期被忽略的，就是成本治理。

因为本地开发时你看到的只是：

这次请求成功了。

但线上你要看到的是：

这次请求花了多少钱，为什么花这么多，以后能不能少花一点。

9.1 至少要按请求记录这些信息¶

使用了哪个模型
输入 token 数
输出 token 数
检索了多少文档
是否发生了工具调用
工具调用次数
总耗时
估算成本

没有这类明细，你后面几乎没法做优化归因。

9.2 成本异常通常来自几类问题¶

prompt 过长
历史会话无上限累积
Agent 步数失控
重复检索和重复调用
输出长度约束太松
路由策略把太多请求送进大模型

9.3 最实用的几条控费手段¶

给会话历史做压缩或摘要
限制最大步数、最大工具次数、最大输出长度
做缓存和去重
给请求做模型分级路由
把离线批处理和在线交互分开设计
对低价值或滥用请求限流

你会发现，这些方法很多都不是“模型算法创新”，而是很朴素的系统工程。

10. 评估：线上系统不能只靠“看起来还行”¶

到了 production，评估必须从“印象派”变成“机制化”。

10.1 offline eval 解决什么问题¶

offline eval 主要用于：

新 prompt 是否比旧 prompt 更好
新模型是否值得替换旧模型
检索链路调整后召回是否退化
工具路由修改后成功率是否变化

它的优势是：

成本可控
可重复
方便做 A/B 对比

它的局限是：

覆盖不到真实线上分布
很难完全还原用户行为
标注标准可能和真实业务目标有偏差

10.2 online eval 解决什么问题¶

online eval 更关注真实使用表现，例如：

用户是否继续追问
用户是否复制结果
是否点击引用来源
是否中途退出
人工反馈是赞还是踩

在线指标离业务更近，但噪声也更大。

所以实践里通常不是 offline 和 online 二选一，而是配合使用：

offline 用来做发布前回归
online 用来做真实效果观测

10.3 LLM 系统的评估常常要分层¶

不要只盯一个“最终满意度”。

更实用的做法是把链路拆开看。

例如对一个 RAG + Agent 系统，可以分别评估：

query rewrite 是否合理
retrieval recall 是否足够
rerank 是否把关键文档提上来
final answer 是否回答了问题
citation 是否准确
tool selection 是否正确
tool arguments 是否合法
task completion 是否成功

这会让你更容易定位问题到底出在哪一段。

10.4 评估不是一次性工作，而是发布门槛¶

真正成熟一点的团队，通常会把评估接进发布流程：

新版本先跑离线评估
指标不过线不发布
小流量灰度观察线上指标
异常时自动回滚或人工回滚

这才是“评估工程化”的开始。

11. 监控与可观测性：你得知道系统到底在干什么¶

如果说评估是判断“做得好不好”，那么监控更像是判断：

它现在是不是在健康地运行。

11.1 你至少要监控三类东西¶

第一类：系统指标¶

QPS
错误率
P95 / P99 延迟
超时率
重试率

第二类：模型与链路指标¶

平均输入输出 token
每请求平均成本
检索耗时
工具调用次数
Agent 平均步数
模型路由分布

第三类：质量代理指标¶

用户追问率
人工差评率
citation 缺失率
空回答率
拒答率

很多线上事故，恰恰不是接口彻底挂了，而是质量 quietly 变差了。

11.2 trace 很重要，因为 LLM 请求不是单跳调用¶

传统接口可能只是一进一出。

但 LLM 应用常常是一串调用：

改写 query
检索
rerank
生成
调工具
再生成

如果没有 trace，你很难知道时间到底花在哪一步、错误到底出在哪一层。

所以对这类系统来说，链路追踪几乎是刚需。

11.3 日志要能复盘，不只是能打印¶

有价值的日志，至少应该能回答：

当时用户问了什么
走了哪个 prompt 版本
用了哪个模型版本
检索到了哪些文档
调了哪些工具
每一步耗时多少
最终输出是什么

当然，这里还必须同时考虑脱敏与合规。

不是所有原始输入、原始上下文都应该无条件长期保存。

12. Prompt、模型、配置都必须版本化¶

很多团队到了线上还在用一种很危险的方式迭代：

把 prompt 改一下试试。

这在 demo 阶段可能问题不大，但 production 不行。

12.1 为什么 prompt 必须像代码一样管理¶

因为 prompt 改动会直接影响：

回答风格
工具调用倾向
拒答边界
输出格式
安全行为

如果不做版本化，你后面连“效果为什么变了”都说不清。

12.2 真正应该一起版本化的对象¶

prompt 模板
model name / model version
system instruction
retrieval 参数
rerank 参数
tool schema
路由策略
安全规则

一个常见错误是只记录“当前线上模型是什么”，却不记录“当前线上系统其实是怎样拼出来的”。

12.3 线上问题排查时，最怕“无法复现”¶

如果某个用户说：

昨天还能答，今天不行了。

你至少要能回放出：

当时请求内容
对应系统配置
对应 prompt 版本
对应模型和知识版本

否则你只能靠猜。

13. 发布、灰度与回滚：别一次把全量用户变成测试集¶

大模型系统的发布风险，往往比普通前端文案更新高得多。

因为一个很小的改动，都可能带来行为级变化。

13.1 哪些改动都应该视为“高风险改动”¶

更换模型
修改 system prompt
调整检索逻辑
更新工具 schema
修改上下文拼接方式
放宽安全策略

这些改动都可能让系统行为发生明显偏移。

13.2 灰度发布的基本思路¶

一个比较稳妥的流程通常是：

本地验证
离线评估
小流量灰度
观察线上指标
逐步放量
异常时快速回滚

13.3 回滚能力比“自信上线”更重要¶

你不可能保证每次升级都更好。

所以成熟系统一定要具备：

prompt 回滚
配置回滚
模型回滚
索引回滚或版本切换

很多事故并不是因为团队不会优化，而是因为：

出问题时退不回去。

14. RAG 和 Agent 上线后，风险会进一步放大¶

第 17 章已经提过 Agent 的失败模式。
到了 production，这些问题通常不只是“答错”，而是会演化成真正的工程风险。

14.1 RAG 的线上典型风险¶

索引没有及时更新，导致回答过时
检索命中看似相关，但关键证据缺失
文档权限控制不严，导致越权召回
citation 看起来像真的，但指向不准确

14.2 Agent 的线上典型风险¶

误选工具
参数生成错误
工具链路超时
步数膨胀
prompt injection 诱导越权操作
在不该执行时执行了真实动作

14.3 所以 guardrails 必须成为系统的一部分¶

常见做法包括：

工具白名单
参数 schema 校验
高风险操作人工确认
最大步数与预算上限
输出审核与策略拦截
权限隔离与租户隔离

这里最重要的 mindset 是：

不要把安全希望寄托在模型“自己会懂”。

15. 一个最小可用的生产化方案¶

如果你现在要做一个“求职级别能讲清楚”的项目，不需要一开始就上特别复杂的基础设施。

你可以先做一个最小但完整的方案：

15.1 场景¶

一个课程资料问答助手，支持：

课程文档问答
带引用回答
简单工具调用，例如表格计算或 FAQ 查询

15.2 技术结构¶

前端：Streamlit 或 React
服务层：FastAPI
检索层：向量库 + rerank
模型层：一个主回答模型 + 一个便宜分类模型
存储层：文档库、日志库、配置版本
观测层：请求日志、延迟监控、简单评估面板

15.3 最低限度要补齐的工程能力¶

每个请求记录 prompt/model/retrieval/version
每个回答记录引用文档和耗时
每天抽样人工检查一批结果
新 prompt 上线前先跑固定测试集
出现异常时能一键切回旧版本

这套东西看起来不花哨，但非常能体现你已经开始用“产品系统”而不是“实验脚本”的视角做事。

16. 面试里怎么讲 LLMOps¶

如果面试官问你：

你怎么理解 LLMOps？

你不要只回答“就是大模型版的 MLOps”。

更好的讲法是按下面这个逻辑展开。

16.1 先讲它解决什么问题¶

LLMOps 解决的是大模型应用从 demo 走向 production 之后的一系列工程问题，包括部署、评估、监控、版本管理、成本控制和发布回滚。

16.2 再讲为什么它比传统服务更难¶

因为 LLM 系统往往：

输出不完全确定
质量难以直接度量
prompt 和上下文会显著影响行为
成本、延迟和质量强耦合
RAG、Agent、工具调用会让链路更长

16.3 再讲你会关注哪些核心模块¶

你可以说你会重点关注：

推理服务与容量规划
prompt / model / config 版本管理
offline + online 评估体系
日志、trace、告警与质量监控
灰度发布、回滚与预算控制

16.4 最后给一个实际判断¶

真正有工程感的回答，通常会落到一句很朴素的话上：

LLMOps 不是让模型更聪明，而是让系统更可控。

17. 本章小结¶

这一章其实是在回答全书最后一个很现实的问题：

当你已经能把模型、RAG、Agent 做出来之后，怎样让它真正稳定地服务真实用户。

你应该已经建立起这样的整体认识：

大模型应用上线后，问题不再只是“答不答得对”
还包括延迟、吞吐、预算、权限、回滚、监控和持续评估
LLMOps 管理的对象，不只是模型，而是整条推理与决策链路
生产系统里最重要的能力之一，不是某次 demo 很惊艳，而是长期可观测、可评估、可回退、可迭代

如果把全书后半段连起来看，可以得到一条比较完整的工程路径：

第 12 到第 14 章告诉你模型怎样被微调和对齐
第 15 和第 16 章告诉你模型怎样接入外部知识
第 17 章告诉你模型怎样调用外部工具完成任务
本章告诉你这些能力怎样被真正部署成一个能上线、能维护、能迭代的系统

到这里，这本书的主线也就基本闭环了：

从模型原理，到训练微调，到应用工程，再到生产化落地。

如果你能把这条链路讲清楚、做出最小项目、并知道每一层常见坑在哪里，那么你就已经不再只是“会调 API”，而是开始具备真正的大模型工程视角。

18. 练习题¶

为什么一个本地效果不错的 RAG 系统，上线后仍然可能用户体验很差？
请你分别解释 offline eval 和 online eval 更适合解决什么问题。
如果一个 Agent 系统线上成本突然暴涨，你会优先排查哪些环节？
为什么说 prompt、retrieval config、tool schema 都应该版本化？
请设计一个最小可用的 LLM 生产系统，并说明你会监控哪些核心指标。

19. 面试题¶

什么是 LLMOps？它和传统 MLOps 有什么联系和区别？
为什么说大模型系统上线后的难点，不只是模型效果本身？
线上大模型服务常见的性能优化手段有哪些？
如何理解质量、延迟、成本三者之间的权衡？
offline eval、online eval、人工抽检三者应该如何配合？
如果一次 prompt 改动让线上回答质量下降，你会怎样定位和回滚？
在 RAG 或 Agent 系统里，你认为最需要优先监控的指标有哪些，为什么？