Wiki Notes

Appearance

04. 成本、延迟与异步运行策略 ​

版本：v1.2

最后更新：2026-07-09

适用对象：已经开始接真实流量，遇到 token 成本上涨、响应时间抖动、长任务超时、缓存收益不稳定，或者正在设计同步链路、后台任务、批处理、优先级分层与成本治理的团队

很多团队会把“成本优化”和“延迟优化”拆成两条线。

但一旦系统进入生产，你很快就会发现：

  • 长上下文既会涨成本，也会涨延迟
  • 重复前缀既会浪费钱，也会拖慢响应
  • 本该异步的任务硬塞同步链路，既贵又慢
  • 低价值任务挤占高价值 lane，会同时打坏 SLA 和预算

OpenAI 当前 Cost optimization、Latency optimization、Background mode、Batch、Flex processing、Priority processing、Conversation state 放在一起看，最重要的工程结论其实不是“用哪个开关”，而是：

  • 你要先设计运行 lane，再决定每类任务放到哪条 lane。

这页会把这个问题完整拆开。

1. 先建立一个更实用的心智模型：不是模式开关，而是运行 lane ​

很多团队会问：

  • 要不要上 batch
  • 要不要开 priority
  • 要不要做 background

这些问题单独看都不完整。

更实用的问题应该是：

  • 哪类任务必须同步返回
  • 哪类任务适合后台运行
  • 哪类任务应该去批处理
  • 哪类任务值得花高优先级预算
  • 哪类任务只需要便宜兜底

所以生产系统里真正要治理的通常不是“功能开关”，而是下面这些 lane：

  1. realtime lane
  2. standard sync lane
  3. priority lane
  4. background lane
  5. batch lane
  6. cost-saving lane，例如 flex

一旦 lane 分错，最容易出现的后果不是一点小抖动，而是：

  • 高价值实时流量被低价值作业挤爆
  • 长任务占满连接和工作线程
  • 批处理作业吃掉在线限额
  • 团队为了保延迟，被迫一刀切降模型
  • 月账单上升却说不清到底是哪类任务在烧钱

2. 成本和延迟为什么经常是同一个问题的两种表现 ​

OpenAI 当前 Cost optimization 和 Latency optimization 都在强调一件事：

  • 影响成本和延迟的核心变量高度重叠

最常见的共同驱动因素包括：

  • 输入 token 太多
  • 输出 token 太多
  • 重复发送稳定前缀
  • 请求次数太多
  • 工具循环太多
  • 同步等待了本可异步完成的工作
  • 把本可批处理的任务逐条串行发送

所以更成熟的优化目标不是：

  • 只降成本
  • 或者只降延迟

而是：

  • 在满足业务 SLA 的前提下，降低单位成功任务的总体资源消耗。

3. 成本、延迟和异步不是三个独立专题 ​

这三者在真实系统里的关系通常是：

  • 成本决定你能不能大规模跑
  • 延迟决定用户能不能等
  • 异步策略决定你是否一定要让用户一直等

很多时候最有价值的优化不是：

  • 再抠 10% token

而是：

  • 把不该同步完成的事情移出同步链路

例如：

  • 长文档深度分析
  • 大量评测任务
  • 批量抽取与改写
  • 晚间补算
  • 重型多工具编排

如果这些任务还跑在用户主链路里，你后面做多少缓存和 prompt 压缩，收益都有限。

4. 别先急着换模型，先看调用结构 ​

很多团队遇到账单上涨的第一反应是：

  • 模型太贵，换个便宜点的

但真实系统里更常见的浪费来自：

  • 上下文越拼越长
  • 稳定前缀每轮都重发
  • 工具定义太宽
  • 检索证据塞太多
  • 本可批量的任务逐条同步发
  • 本可后台跑的任务被硬做成请求阻塞
  • 一个任务里发生太多无意义重试

所以更高价值的第一步往往不是“先降模型”，而是：

  • 先把调用结构理顺，再决定模型档位。

5. 延迟真正由哪些环节组成 ​

很多团队的观测里只有一个指标：

  • 模型响应时间

这在生产里远远不够。

一个面向用户的 AI 请求，端到端延迟通常至少包含：

  1. 输入准备延迟
  2. 检索或预处理延迟
  3. 模型首 token 延迟
  4. 模型生成延迟
  5. 工具调用或外部系统等待
  6. 后处理与渲染延迟
  7. 审批或人工接管等待

如果只盯模型本身，经常会误判：

  • 明明是检索慢，却以为模型慢
  • 明明是工具超时，却去换模型
  • 明明该异步化，却在同步链路里做 token 压缩

6. OpenAI 当前 latency 指南最值得记住的 8 个方向 ​

结合 OpenAI 当前 Latency optimization、Production best practices、Background mode、Prompt caching 等文档，可以把高价值建议翻译成工程动作：

  1. 缩短输入
  2. 缩短输出
  3. 减少无意义请求次数
  4. 让重复前缀吃缓存
  5. 不要默认把所有工作同步完成
  6. 对高价值流量做更稳定的 lane
  7. 并行化可并行步骤
  8. 把轮询和重试纳入成本口径

这些建议看起来很散，但放到工程里其实就是四件事：

  • 控上下文
  • 控输出
  • 控运行 lane
  • 控控制流

7. Prompt caching 在生产里真正解决什么 ​

OpenAI 当前 Prompt caching 文档强调的不是“缓存整次回答”，而是：

  • 共享稳定前缀的请求可以复用此前缀处理收益

这对生产系统的意义很直接：

  • 如果大量请求共享长前缀，就不要每次都把这部分当全新成本和全新延迟处理

7.1 哪些内容最适合做稳定前缀 ​

最适合放在稳定前缀里的通常是：

  • instructions 或 system / developer rules
  • 固定 policy
  • 稳定 few-shot
  • 长期不变的 schema
  • 相对稳定的工具定义
  • 固定工作流骨架

7.2 哪些内容更适合靠后放 ​

更适合放在变化区而不是稳定前缀区的通常是：

  • 用户输入
  • 实时变量
  • 当前租户个性化上下文
  • 本轮临时证据
  • 刚刚返回的工具结果

7.3 真正要治理的是“前缀资产” ​

很多团队会把 prompt caching 当成一个节流开关。

更长期有价值的视角其实是：

  • 哪些前缀值得被平台长期稳定化

这会反过来推动你治理：

  • prompt bundle
  • 工具定义版本
  • 规则模板
  • route bundle
  • 租户模板

所以 prompt caching 带来的不只是成本收益，还会倒逼：

  • 规则更稳定
  • 版本更可控
  • 路由更可复用

7.4 缓存命中不能只看全局平均 ​

如果只看全局 hit rate，很多问题会被掩盖：

  • 高频主路径命中很好
  • 高价值路径因为前缀抖动几乎不命中

更稳的做法是按这些维度拆开看：

  • route bundle
  • task bucket
  • tenant tier
  • prompt version
  • model family

这样你才能知道：

  • 是缓存策略没设计好
  • 还是这类路径本来就不适合依赖缓存

8. Conversation state 为什么也会直接影响成本和延迟 ​

OpenAI 当前 Conversation state 指南的工程意义并不只是“支持多轮对话”，而是：

  • 你如何保存和续接状态，会直接影响 token 成本和响应时间

如果你只是：

  • 把全部历史不断追加

通常会同时带来：

  • token 成本膨胀
  • 首 token 延迟抬高
  • 无关历史污染当前任务
  • 缓存命中变差

更稳的思路通常是把状态分层：

  • 原始历史
  • 摘要状态
  • 长期事实
  • 工具轨迹
  • 持久业务状态

也就是说，conversation state 不是“聊天功能”，而是：

  • 运行成本治理的一部分

9. 什么时候应该异步化 ​

OpenAI 当前 Background mode 文档明确适合：

  • 长时间运行的复杂任务

这给生产团队的核心提醒是：

  • 不是所有任务都值得让用户在前台一直等完

9.1 适合同步返回的任务 ​

更适合同步的通常是：

  • 短问答
  • 简短摘要
  • 低延迟客服回复
  • 快速分类与路由
  • 小规模结构化抽取

9.2 更适合后台运行的任务 ​

更适合 background lane 的通常是：

  • 长文档深度分析
  • 多步工具编排
  • 复杂推理任务
  • 大型报告生成
  • 需要审批插入的长任务

9.3 更适合批量离线处理的任务 ​

更适合 batch lane 的通常是：

  • 样本评测
  • 批量 enrichment
  • 批量重写
  • 历史数据补算
  • 全量归档摘要

9.4 高价值异步和低价值异步不是同一种任务 ​

很多团队把“异步”看成同一个盒子，但真实系统里至少应分成两类：

  • 高价值异步
  • 低价值异步

高价值异步通常特点是：

  • 用户能接受等待
  • 但结果很重要
  • 需要可恢复、可取消、可人工接管

低价值异步通常特点是：

  • 更关心吞吐和成本
  • 允许较大完成窗口
  • 更适合批量或低优先级承载

前者更适合：

  • background lane
  • 状态机
  • webhook / callback
  • checkpoint / resume

后者更适合：

  • batch
  • flex
  • 夜间补算

10. Background mode 的真正价值不是“异步”，而是“可治理的长任务” ​

OpenAI 当前 Background mode 文档对生产系统真正重要的，不只是“任务可以后台跑”，而是：

  • 你终于可以不把长任务强行塞在同步超时窗口里

更成熟的 background 设计应该回答：

  • 谁创建任务
  • 如何拿到任务 ID
  • 用 polling 还是 webhook
  • 任务可以取消吗
  • 失败后如何重试
  • 哪些中间结果可恢复
  • 审批插入后如何继续

10.1 不要把 background task 当成“同步请求换个线程跑” ​

真正后台化不只是把工作挪位置，而是要补齐：

  • 状态模型
  • 生命周期
  • 重试策略
  • 回调策略
  • 权限与审计

10.2 Webhook 与 polling 要分场景选 ​

如果用 polling，要把这些成本算进去：

  • 轮询请求数
  • 轮询频率
  • 超时与退避
  • 大量任务并发时的控制面负担

如果用 webhook，要补齐：

  • 签名校验
  • 幂等处理
  • 重放保护
  • 回调失败重试

很多系统“后台化后还是贵”，根因并不在推理，而在：

  • 状态检查与控制流本身失控了

11. Batch lane 的价值远不只是“更便宜” ​

OpenAI 当前 Batch API 文档强调：

  • 异步
  • 更低成本
  • 适合大规模任务

很多团队第一次接触 batch，只看到了：

  • 单价更低

但它真正更大的价值通常在于：

  • 把本就不该在线跑的流量彻底隔离出去

11.1 Batch 更适合哪些工作负载 ​

常见高收益对象包括：

  • 离线评测
  • 样本回放
  • 大量抽取
  • 大规模改写
  • 历史工单归档摘要
  • 夜间规则回填

11.2 为什么 batch 先解决的是资源隔离 ​

如果这些任务继续混在主在线 lane，最常见的后果是：

  • 抢限额
  • 抬高峰值延迟
  • 干扰核心用户请求
  • 把高价值流量拉进降级

所以 batch 的价值通常先体现为：

  • 在线面被保护住了

然后才是：

  • 单价更低了

11.3 批处理更适合“任务级成功率”而不是“单请求响应” ​

实时请求最关心：

  • 单次能不能快回

批处理更关心：

  • 一批任务是否按时完成
  • 成功率如何
  • 单任务平均成本如何
  • 失败重跑成本如何

这意味着你监控 batch lane 时，口径应当和在线面分开。

12. Flex processing 更适合做“成本兜底 lane” ​

OpenAI 当前 Flex processing 文档明确强调：

  • 更适合低优先级、异步、可接受更慢响应的任务

这意味着更稳妥的用法通常不是：

  • 把 flex 当默认主路径

而是：

  • 把它当成本敏感型 lane

12.1 哪些任务最适合 flex ​

更典型的对象是：

  • 回放补算
  • 离线指标重算
  • 大量低优先级改写
  • 非紧急批量评测
  • 后台报告补全

12.2 为什么 flex 不是“免费午餐” ​

便宜通常对应的是：

  • 响应更慢
  • 调度更松
  • 不适合关键在线路径

所以 flex 的关键问题从来不是：

  • 能不能省

而是：

  • 这类任务本来就该不该用更便宜、但更慢的 lane 承接

13. Priority processing 不是加速按钮，而是 SLA 预算 ​

OpenAI 当前 Priority processing 文档强调：

  • 更低、更稳定的延迟
  • 适合高价值、用户直面的常规流量

对生产系统来说，这意味着 priority 的角色更像：

  • SLA 保障 lane

而不是：

  • 大家一着急就开的快车道

13.1 Priority lane 最好有明确资格门槛 ​

更稳的做法通常会明确：

  • 哪些产品入口能走 priority
  • 哪些租户等级能走 priority
  • 哪些 task bucket 能升级进去
  • 哪些 incident mode 允许临时切换

13.2 Priority lane 需要单独成本核算 ​

因为它的意义不是：

  • 让所有请求都快一点

而是：

  • 保住关键流量的低抖动低延迟

所以更实用的治理方式是单独统计：

  • priority 请求占比
  • priority 成功任务成本
  • priority SLA 达成率
  • priority lane 被低价值任务侵占的比例

14. 实时 lane、后台 lane、批处理 lane 最好从第一天就分池 ​

很多系统的问题不是“某个 API 不够强”，而是：

  • 所有类型任务在抢同一组额度、线程和连接

一个更稳的最小分池方式通常是：

  1. realtime lane
  2. background lane
  3. batch lane
  4. priority lane
  5. cost-saving lane

即使一开始物理上还没完全分池，至少逻辑上也应该分开：

  • 队列
  • 配额
  • 指标
  • 告警
  • 降级策略

否则到了线上，你会连下面这些问题都答不清：

  • 到底是谁把在线面挤爆了
  • 是哪个租户在抢高优先级通道
  • 是不是后台补算把主链路限额吃掉了

15. Admission control 和 backpressure 为什么属于 LLMOps 主线 ​

只要系统开始分 lane，就必须处理：

  • 谁能进来
  • 进来多少
  • 满了怎么办

这就是 admission control。

更成熟的系统不会默认所有请求都立刻执行，而是会基于：

  • tenant tier
  • task class
  • current backlog
  • lane quota
  • SLA class
  • estimated token cost

决定：

  • 直接执行
  • 排队
  • 降级
  • 转 background
  • 转 batch
  • 拒绝

15.1 没有 admission control，异步系统也会被打穿 ​

很多团队做了后台队列，就以为稳了。

但如果没有入口节流，最终只是把同步拥塞换成：

  • 队列爆满
  • 任务积压
  • 回调雪崩

15.2 backpressure 不只是技术措施，也是产品策略 ​

当系统繁忙时，更好的处理通常不是默默变慢，而是显式：

  • 降低某类任务优先级
  • 暂停低价值入口
  • 把部分请求引导到异步
  • 降模型或收缩工具面

16. 成本优化至少应该从 5 层下手 ​

16.1 输入层 ​

包括：

  • 压缩上下文
  • 去掉重复说明
  • 收缩 few-shot
  • 做 prompt caching
  • 裁剪检索证据

16.2 路由层 ​

包括：

  • 简单任务不上最强模型
  • 高风险任务才升级
  • 长任务和短任务走不同 lane
  • 不同租户按 SLA 分层

16.3 执行层 ​

包括：

  • 同步改异步
  • 单条改批量
  • 多步串行改并行
  • 控制无意义重试

16.4 结果复用层 ​

包括：

  • cache
  • 中间结果复用
  • 工具结果复用
  • 检索结果复用

16.5 控制流层 ​

包括：

  • 减少轮询
  • 优化 webhook
  • checkpoint / resume
  • 更细的失败分类

很多团队只做前 4 层，忽略控制流层，结果就是：

  • 推理便宜了，但后台控制面反而越来越贵

17. 一个更稳的延迟优化顺序 ​

OpenAI 当前 Latency optimization 的建议放到工程里，更实用的顺序通常是：

  1. 先拆分延迟构成
  2. 先减输入 token
  3. 再减输出 token
  4. 再减请求次数
  5. 再分同步 / 异步 / 批处理
  6. 最后再做高优先级 lane 和复杂策略

为什么不是先上复杂 lane？

因为如果你还没搞清：

  • 哪部分在慢

就很容易把 lane 设计成：

  • 用架构复杂度掩盖基本浪费

18. 成本和延迟最值得统一的统计口径 ​

很多团队只报：

  • 平均请求成本
  • 平均响应时间

这对治理帮助很有限。

更实用的口径通常至少包括：

18.1 单请求成本 ​

  • 一次请求花了多少

18.2 单任务成本 ​

  • 完成一个业务任务全链路花了多少

18.3 单成功任务成本 ​

  • 真正交付成功结果的平均成本是多少

18.4 分层延迟 ​

  • 检索延迟
  • 模型延迟
  • 工具延迟
  • 审批延迟
  • 控制面延迟
  • 端到端延迟

18.5 lane 级成本与延迟 ​

  • realtime lane
  • priority lane
  • background lane
  • batch lane
  • flex lane

只有把口径拆到这个粒度，你才能回答：

  • 到底是哪条 lane 在烧钱
  • 到底是哪条 lane 在拉低整体 SLA

19. 高延迟不一定意味着模型慢 ​

很多时候高延迟其实来自：

  • 检索候选池过大
  • 外部工具超时
  • 轮询过密
  • 重试链路太长
  • 审批等待
  • 连接重试
  • 超长上下文

所以如果你的可观测性只有：

  • 模型响应时间

那你会很容易把系统问题误判成模型问题。

更成熟的 trace 视角至少要能看见：

  • 任务进入哪条 lane
  • 在队列里等了多久
  • 预处理花了多久
  • 模型推理花了多久
  • 工具链花了多久
  • 回调 / 轮询花了多久

20. 长任务为什么更适合任务状态机 ​

一旦任务开始走后台，你就必须回答：

  • 当前跑到哪一步
  • 中间结果是否可恢复
  • 用户离开页面后是否还能回来接着看
  • 失败后从头跑还是断点续跑

所以异步运行最终总会和下面这些主题连在一起：

  • conversation state
  • background mode
  • workflow state
  • approval state
  • checkpoint / resume

20.1 background job 最好有明确状态机 ​

只记录：

  • pending
  • done
  • failed

通常是不够的。

对真实 AI 长任务来说，更稳的状态机至少会考虑：

  • queued
  • admitted
  • running
  • waiting_for_tool
  • waiting_for_review
  • waiting_for_callback
  • cancelled
  • failed_retryable
  • failed_terminal
  • completed

20.2 长任务最好显式设计 checkpoint / resume point ​

很多 background 任务最大的坑不是：

  • 一次失败了

而是：

  • 失败后只能从头再跑

如果任务里包含：

  • 长推理
  • 多步工具调用
  • 审批等待
  • 大文档处理

那更稳的做法通常是在关键节点打 checkpoint，并明确：

  • 哪一步之前的结果可复用
  • 哪一步之后必须重新算
  • 哪些副作用绝不能重放

20.3 取消语义必须提前定义 ​

后台任务不是只有“完成”和“失败”。

还要回答：

  • 用户取消时，已经发出的外部副作用怎么办
  • 审批中取消时如何收口
  • 部分工具成功、部分工具未执行时如何补偿

21. Realtime 场景还有自己的成本口径 ​

OpenAI 当前 Realtime costs 文档提醒：

  • prompt caching 同样会影响多轮实时会话成本

这对实时语音、实时协作和长会话系统特别重要，因为它意味着：

  • 状态设计会直接影响实时账单曲线

Realtime lane 通常还要额外考虑：

  • 首响应抖动
  • 会话保持成本
  • 流式回包策略
  • 中途打断与恢复

所以 realtime 成本治理通常不该直接套用普通文本接口口径。

22. Anthropic 和 Gemini 的异步 / 缓存思路，为什么也值得借鉴 ​

虽然这页主线以 OpenAI 运行模式为核心，但其他官方文档也给出了一些很重要的共识。

22.1 Anthropic：prompt caching、context windows、message batches ​

Anthropic 当前文档强调：

  • prompt caching 要治理可复用前缀
  • 长上下文要做明确预算
  • Message Batches 适合大规模异步任务

这说明：

  • “缓存 + 长上下文 + 批处理”的组合，并不是单一厂商特例，而是生产系统的通用模式

22.2 Gemini：context caching、batch mode、long context ​

Google Gemini 当前文档同样强调：

  • context caching
  • batch processing / batch mode
  • long context

这提醒我们：

  • 只要任务量上去，大家最终都得面对相同问题

也就是：

  • 同步链路承接什么
  • 可复用前缀怎么治理
  • 哪些任务搬到批量或后台更划算

22.3 真正该学的是共同模式，不是字段名字 ​

厂商 API 细节不同，但工程结论越来越一致：

  1. 长前缀要治理
  2. 长任务要异步化
  3. 低价值任务要批量化
  4. 高价值任务要分级保障
  5. 成本与延迟要按 lane 归因

23. 一个更稳的运行策略分层 ​

建议至少把任务分成下面 5 层：

23.1 实时主链路 ​

特点：

  • 用户正在等待
  • 需要快速回包
  • 对抖动敏感

23.2 高价值优先级链路 ​

特点：

  • 更高 SLA
  • 更稳定低延迟
  • 值得单独预算

23.3 后台长任务链路 ​

特点：

  • 用户可离线等待
  • 需要状态机
  • 需要 checkpoint / resume

23.4 离线批处理链路 ​

特点：

  • 无需即时反馈
  • 更看重吞吐和单价

23.5 成本敏感兜底链路 ​

特点：

  • 可等待
  • 对延迟不敏感
  • 优先节约预算

这样分层的好处是：

  • 你终于能按任务本质，而不是按 SDK 功能名做治理

24. 租户、路由和 lane 最好一起治理 ​

很多团队会把 lane 设计成纯平台问题，但实际上：

  • route
  • tenant
  • task class
  • lane

通常应该一起建模。

否则你会遇到：

  • 高价值租户和低价值租户抢同一条 priority lane
  • 批量回放和在线问答共用同一额度池
  • 某些 route 因为前缀过长缓存始终不命中

更成熟的治理通常会把这些维度一起打到指标里：

  • tenant tier
  • route bundle
  • task bucket
  • lane
  • model family
  • tool surface

25. lane 治理值得单独设一组指标 ​

除了单请求成本和延迟，建议额外观察：

  • 各 lane 请求占比
  • lane 间升级 / 回退比例
  • priority lane 占用率
  • background backlog
  • batch 完成时长分布
  • flex lane 平均等待时长
  • 任务在各 lane 的成功率
  • 各 lane 的单位成功任务成本
  • 因 incident mode 被强制改道的比例

这些指标非常重要，因为很多系统的问题不是某一条请求坏了，而是：

  • 某类任务整体走错 lane 了

26. incident mode 下的运行策略，最好提前定义 ​

生产系统总会遇到：

  • 上游模型波动
  • 限额吃紧
  • 工具服务异常
  • 队列积压

这时如果没有提前定义 incident mode，团队就容易：

  • 临场拍脑袋切流
  • 把所有任务一刀切降级
  • 把高价值和低价值流量一起伤到

更稳的设计通常会提前定义：

  1. 哪些任务优先保
  2. 哪些任务先降级到 background / batch / flex
  3. 哪些任务直接暂停
  4. priority 配额如何保护
  5. 恢复主路径的条件是什么

incident mode 的核心不是“先让系统活着”，而是：

  • 让系统在失常时仍然按价值排序地活着

27. 常见反模式 ​

27.1 一切任务都同步做 ​

这通常会导致：

  • 长任务超时
  • 在线面拥塞
  • 用户体验抖动

27.2 不分任务价值，全部走同一条高成本路径 ​

这会导致：

  • 高价值任务没有真正被保障
  • 低价值任务把预算吃空

27.3 prompt 前缀不稳定，缓存命中长期低 ​

这常见于：

  • 工具顺序经常变
  • 规则模板频繁抖动
  • few-shot 顺序随机

27.4 长任务没有状态恢复，只能超时重跑 ​

这会把一次偶发失败，放大成：

  • 持续成本放大器

27.5 没有 checkpoint，长任务一失败就整条重跑 ​

这对：

  • 长推理
  • 多工具编排
  • 审批任务

尤其致命。

27.6 没有 lane 配额，高价值和低价值任务抢同一池资源 ​

这是最容易在流量波动时把 SLA 打穿的原因之一。

27.7 把 flex 当默认主路径，而不是成本敏感补充 lane ​

这通常会让：

  • 该快的任务变慢
  • 该稳的任务变抖

27.8 只看月账单，不看任务级归因 ​

最终你只知道：

  • 很贵

却不知道：

  • 为什么贵
  • 是哪条 lane 贵
  • 哪类任务贵

28. 一个最小可用的优化顺序 ​

更稳妥的顺序通常是：

  1. 先统一成本和延迟口径
  2. 再拆调用链与 lane
  3. 再做 prompt caching 和上下文瘦身
  4. 再做模型路由与工具面收缩
  5. 再把长任务搬到 background
  6. 再把低价值任务搬到 batch / flex
  7. 最后才做更复杂的优先级和 incident mode 策略

这个顺序的价值在于：

  • 更容易快速拿到真实收益
  • 不会一上来就用架构复杂度掩盖基本浪费

29. 推荐搭配阅读 ​

30. 重点官方资料 ​

以下资源已按 2026-07-09 复核可访问：

31. 一句话总结 ​

今天做 LLMOps 时，真正该治理的不是几个零散 API 功能，而是：

  • 让不同价值、不同时效、不同成本容忍度的任务，进入不同运行 lane，并用状态机、缓存、配额和归因把这些 lane 经营起来