P1-14.6 AI 服务在现实中遇到的约束¶
Section ID:
P1-14.6Version:v2026.07.20
在 P1-14.5 中，我们把 harness 看成一种执行环境：它会包裹模型与工具运行，并使 trace、log、evaluation 成为可能。接下来问题会进一步转向现实：
模型能生成答案。
工具也能接入。
执行过程还能被记录。那么，这套结构能否作为真实服务持续运行下去？
AI 服务并不会因为“回答得不错”就自动成立。如果太贵，就难以持续；如果太慢，用户不会等待；如果失败后无法解释或恢复，也很难真正进入工作场景。
这里会用 服务约束(service constraints) 的视角来看这些问题。成本(cost)、延迟(latency)、吞吐量(throughput)、使用量限制(usage limit)、速率限制(rate limit)、重试(retry)、批处理(batch)、缓存(caching)、监控(monitoring) 都是理解这些约束的基础词。
这里从导论层面说明：当 AI 服务真正被使用时，需要面对哪些约束。安全政策与隐私处理会在 P1-15.1、P1-15.2、P1-15.3 再讨论。这里先集中处理 为什么好的回答并不立刻等于可以运营成服务 这个问题。
| 术语 | 极简含义 | 本节中的作用 |
|---|---|---|
| 成本(cost) | 单次请求与整体运行消耗的资源 | 判断可持续性的标准 |
| 延迟(latency) | 从请求到响应的时间 | 用户等待体验的核心 |
| 吞吐量(throughput) | 一段时间内可处理的请求数量 | 判断服务规模的标准 |
| 速率限制(rate limit) | 短时间窗口内的调用上限 | 既是设计条件，也是故障来源 |
| 重试(retry) | 失败后再次执行的策略 | 恢复稳定性的手段 |
| 批处理(batch) | 把工作推迟后成批执行 | 提升非实时任务效率的方式 |
| 缓存(caching) | 复用重复输入的部分结果 | 缓解成本与延迟的方法 |
| 运维(operations) | 持续维护与调节服务的工作 | 观察与调优的视角 |
这里先把 只有质量不够、还必须同时看成本与延迟、失败与限制也是设计的一部分 作为基准线。
阅读现实服务约束的基准¶
- 从成本、延迟、吞吐量、失败响应四个方向理解 AI 服务约束。
- 把成本理解为不只是 token 数，还包括模型选择、请求次数、工具使用、重试、评估运行。
- 把延迟理解为不只是模型推理时间，还包括检索、工具调用、网络、后处理。
- 把 rate limit、usage limit、retry 看成服务设计的基础约束。
- 把 batch、caching、streaming 看成要因场景而定的选择，而不是万能解法。
三个基准¶
| 基准 | 为什么重要 | 本节所需的理解水平 |
|---|---|---|
| 仅有好的回答并不足以构成服务 | 这能把模型质量与运维可行性区分开。 | 只要理解成质量之外还要同时看成本与延迟即可。 |
| 成本不是单次模型调用产生的，而是整条流程共同产生的 | 这能让 RAG、工具使用、重试都进入“服务成本”的视野。 | 只要理解成检索、评估、失败重试也都消耗资源即可。 |
| 延迟与失败处理本身就是设计的一部分 | 这能把用户体验与运行稳定性放进同一视角。 | 只要理解成模型再好，如果又慢又常失败，也很难做成服务即可。 |
好答案并不够¶
刚开始时，人们往往只关心“模型答得对不对”。一旦它进入服务形态，问题就会改变。
| 学习阶段的问题 | 服务阶段的问题 |
|---|---|
| 回答是否正确？ | 这种质量能否反复稳定地产出？ |
| 解释是否自然？ | 是否能在用户可等待的时间内响应？ |
| 换更聪明的模型就行了吗？ | 成本与延迟是否处在可接受范围？ |
| 多接几个工具会不会更强？ | 工具失败与权限问题能否被处理？ |
| 记录日志和评估是不是就够了？ | 日志与评估本身带来的成本与风险能否承受？ |
因此，AI 服务至少要同时考虑三件事：
质量(quality)
成本(cost)
延迟与可靠性(latency and reliability)
成本不只是 token 问题¶
在 LLM 服务里，token 是理解成本的重要单位。输入越长、输出越长，通常就意味着更多计算，也往往意味着更高成本与更长延迟。
但成本不能只用 token 数来理解。
| 成本来源 | 说明 |
|---|---|
| 模型选择(model choice) | 更大的模型可能带来更好结果，但也会提高成本与延迟 |
| 输入 token(input tokens) | 长 prompt、长文档、多检索结果都会增加成本 |
| 输出 token(output tokens) | 长回答、长代码、长报告都会增加成本 |
| 请求次数(request count) | 一次请求里多次调用模型会累计成本 |
| 工具调用(tool call) | 检索、数据库访问、外部 API 调用会另外耗费时间与资源 |
| 重试(retry) | 失败后重跑请求，即使不成功也可能增加成本 |
| 评估运行(eval run) | 为了做质量验证而重复执行也会耗费资源 |
延迟不只是模型本身的时间¶
延迟(latency) 是用户发出请求后到收到回应为止等待的时间。在 AI 服务里，这并不只由模型推理时间决定。
用户请求
-> 输入校验
-> 检索或数据查询
-> 模型调用
-> 工具调用
-> 再次模型调用
-> 后处理
-> 用户响应
每个步骤都可能增加等待时间。
| 延迟来源 | 例子 |
|---|---|
| 网络(network) | 请求与响应往返时间 |
| 检索(retrieval) | 向量搜索、数据库查询、文档加载 |
| 模型推理(model inference) | 处理输入并生成输出所需时间 |
| 输出长度(output length) | 回答越长，生成时间越可能越久 |
| 工具调用(tool call) | 外部 API 或文件操作可能很慢 |
| 后处理(post-processing) | 格式校验、安全检查、存储 |
streaming 能缩短用户的体感等待时间，因为用户不必等到整段输出结束才开始看到结果。但 streaming 不会消除全部计算，完整完成时间仍然受模型、工具、网络、后处理影响。
prompt caching 也能在出现大量重复前缀时降低延迟与成本，比如稳定的系统指令或重复共用的上下文。
限制不是单纯故障，而是设计条件¶
服务提供方通常会施加 usage limit 与 rate limit。
rate limit 指的是在某个短时间窗口内，请求数或 token 数不能超过上限；usage limit 则可能是更宽范围的月度或项目级总量限制。
它们并不只是让人不舒服的限制，而是设计必须面对的条件。
| 限制 | 会引出的设计问题 |
|---|---|
| 请求数限制(request limit) | 同时涌入很多用户时怎么办？ |
| token 限制(token limit) | 长文档与长输出如何被压缩？ |
| 使用量上限(usage limit) | 预算接近上限前何时该停下？ |
| 模型级限制(model-specific limit) | 某个模型不可用时有没有后备路径？ |
| 批处理限制(batch limit) | 非实时工作如何分开处理？ |
因此，retry 一定要有策略。常见方法是 exponential backoff 加 jitter：
糟糕的重试：
失败 -> 立刻重试 -> 立刻重试 -> 立刻重试更好的重试：
失败 -> 先等一下 -> 重试 -> 再等更久 -> 重试 -> 停止或告知用户
实时任务与批处理任务不同¶
并不是所有 AI 任务都必须立刻给出答案。用户在聊天窗口里等待的任务，更接近 interactive work；而大规模文档分类、嵌入生成、评估运行、数据补全等任务，往往更适合看成 batch work。
| 任务类型 | 特征 | 例子 |
|---|---|---|
| 实时任务(interactive work) | 用户正在等待 | 聊天回复、代码辅助、搜索问答 |
| 批处理任务(batch work) | 结果可以稍后返回 | 批量文档分类、嵌入生成、评估运行 |
一个很简单的问题就能改变服务结构：
用户现在就必须看到结果吗？
还是稍后处理也可以？
运维是“重复使用的条件”¶
这里的 运维(operations) 并不指整个 DevOps 或 MLOps 方法论，而是更窄的问题：
在什么条件下，这个 AI 服务可以被反复使用并持续维护？
至少要观察下面这些指标：
| 需要观察什么 | 为什么 |
|---|---|
| 错误率(error rate) | 看哪些请求经常失败 |
| 延迟(latency) | 看用户等待时间是否变长 |
| 成本(cost) | 看预算是否超支，或某些功能是否过贵 |
| token 使用量(token usage) | 看输入输出是否变得不必要地长 |
| 工具失败(tool failure) | 看外部 API、文件、数据库是否成了瓶颈 |
| 质量指标(quality metric) | 看模型或 prompt 变更后质量是否下降 |
这里最重要的教训很简单：
即使服务已经开始运行，
它仍然需要被持续观察与调节。
即使是小服务，也要先定一些标准¶
一开始不必就搭建庞大的运维体系。即使只是一个很小的 AI 功能，只要先定下一些标准，系统也会更稳。
| 标准 | 例子问题 |
|---|---|
| 响应时间目标 | 用户最多愿意等几秒？ |
| 最大输出长度 | 回答允许长到什么程度？ |
| 最大工具调用数 | 一次请求最多允许调几次工具？ |
| 重试策略 | 失败后最多重试几次，什么时候停止？ |
| 预算标准 | 如何观察每天或每月使用量？ |
| 失败提示 | 执行失败时，要对用户说什么？ |
| 评估标准 | 改动后用哪些案例检查质量？ |
例如，一个基于文档的 Q&A 功能，初始标准可以写成：
尽量在 5 秒内开始响应。
最多只放入 5 份检索文档。
第一轮回答限制在约 800 字以内。
单次请求最多允许 3 次工具调用。
遇到 rate limit 最多重试 2 次。
如果没有来源，就不要把内容写成已验证事实。
这些数字并不是普遍正确答案。它们会随服务目标、用户、预算、风险而变化。
一次请求真正会经过的完整流程¶
第 14 章介绍过的这些元素，实际上都会在一条真实请求里交织出现。以文档型工作助手为例，用户表面上只问了一个问题，内部却可能经历很多步骤。
用户提问
-> 权限检查
-> 检索相关文档
-> 组装提示词
-> 模型调用
-> 必要时调用工具
-> 审查并记录结果
-> 响应用户
假设用户请求：
请从上周会议记录里只找出决议事项，
起草一份日程，
并把需要的事项加到日历里。
这个请求的内部流程可以这样理解：
| 阶段 | 内部工作 | 此处最重要的约束 |
|---|---|---|
| 权限检查 | 确认用户是否能访问会议记录和日历 | 安全、隐私、审批条件 |
| 检索 | 找会议记录文件与相关段落 | 检索延迟、选错文档的风险 |
| 第一次模型调用 | 提取决议事项与候选日程项 | 模型成本、输出长度、理解错误 |
| 工具调用 | 通过日历 API 注册草稿事项 | 权限、重试策略、外部状态变化 |
| 审查与记录 | 留下用了哪些文档、注册了什么 | 日志成本、可复现性、可审计性 |
| 用户响应 | 展示结果与其依据 | 响应时间、可解释性 |
这样一看，第 14 章前面几节介绍的元素也就会重新浮现出来：
| 第 14 章中的元素 | 在这条请求中承担的角色 |
|---|---|
RAG | 找到会议记录与相关资料，并贴进模型输入 |
工具使用(tool use) | 调用日历 API 执行真实登记 |
agent | 把检索、提取、调用、汇报这些步骤串起来 |
MCP | 可能用于标准化工具与数据的连接方式 |
harness | 追踪用了什么检索、发生了什么调用、结果如何 |
服务约束(service constraints) | 把成本、延迟、重试、审批条件变成设计标准 |
这个综合案例最重要的一点是：
一个“不错的模型”并不会自动变成“可运营的服务”。
真正的服务会把 读取、判断、执行、审查、记录、约束管理 一起塞进同一条请求里。
本节应记住的视角¶
AI 服务并不是靠模型质量单独维持的。
好答案是必要的。
但只有好答案并不够。成本决定可持续性。
延迟塑造用户体验。
限制与失败处理决定稳定性。
观察与评估决定能否持续改进。
尤其当 agent 与工具使用加入之后，调用次数与失败点都会增多，所以质量与约束必须一起读。
检查清单¶
- 能用成本、延迟、吞吐量、失败响应来解释服务约束。
- 能说明成本不仅由 token 决定，也与模型选择、请求次数、工具调用、重试、评估运行有关。
- 能说明延迟不仅来自模型推理，也来自检索、工具调用、网络与后处理。
- 能把 streaming、caching、batch 解释为因场景而定的选择。
- 能把 rate limit 与 usage limit 解释成设计条件，而不是单纯故障。
- 能说明为什么 retry 需要像 exponential backoff 与 jitter 这样的策略。
- 能把 operations 解释成为了重复使用而进行的观察与调节条件。
- 能说明即使是小型 AI 功能，也需要对响应时间、工具调用数、重试、预算与失败提示先有标准。
来源与参考资料¶
- OpenAI, Latency optimization, OpenAI API Docs, 确认日期: 2026-07-19.
- OpenAI, Cost optimization, OpenAI API Docs, 确认日期: 2026-07-19.
- OpenAI, Prompt caching, OpenAI API Docs, 确认日期: 2026-07-19.
- OpenAI, Batch API, OpenAI API Docs, 确认日期: 2026-07-19.
- OpenAI, Rate limits, OpenAI API Docs, 确认日期: 2026-07-19.
- OpenAI, Production best practices, OpenAI API Docs, 确认日期: 2026-07-19.
- OpenAI, Deployment checklist, OpenAI API Docs, 确认日期: 2026-07-19.