Wiki Notes

Appearance

推理加速与成本优化专题 ​

版本：v1.2

最后更新：2026-07-09

适用对象：正在做线上 AI 应用、Agent、RAG、实时语音、多模型路由、离线批处理，以及需要同时回答“为什么慢、为什么贵、为什么一降本就掉质量”的平台、架构、应用与运维同学

AI 系统一旦进入真实生产，最先被追问的两个问题通常就是：

  • 为什么这么慢
  • 为什么这么贵

更麻烦的是，这两个问题通常不是分开的。

一次请求变慢，常常意味着：

  • 上下文更长
  • 工具调用更多
  • 模型更重
  • 重试更多
  • 控制面更复杂

而这些因素几乎都会一起推高成本。

所以这篇专题不只讲“怎么省钱”，而是讲：

  • 如何同时优化延迟、成本、质量和稳定性

1. 先明确：推理优化是系统问题，不只是模型问题 ​

很多团队一看到“慢”和“贵”，第一反应就是：

  • 模型太大了，换轻一点

但真实路径通常更像：

text
Client
 -> Gateway
 -> Auth / Policy
 -> Retrieval
 -> Prompt Assembly
 -> Model Inference
 -> Tool Calls
 -> Post-process
 -> Render

任意一个环节都可能成为主要瓶颈。

常见真实原因包括：

  • 检索召回过多
  • 历史上下文越来越长
  • system prompt 过重
  • 工具调用链过长
  • 外部接口慢
  • 模型选型不匹配任务
  • 该异步的任务被硬做成同步
  • 轮询和回调控制面过重

所以推理优化的第一原则通常是：

  • 先拆路径，再谈模型

2. 成本和延迟为什么经常被绑在一起 ​

根据 OpenAI 当前 Cost optimization 与 Latency optimization 官方文档：

  • 降低 token 和请求次数通常会同时改善成本和延迟
  • Batch、Flex processing、Prompt caching、Background mode 等能力，本质上都在处理“重复、可延后、可批量”的请求

这背后的核心规律是：

  • 不必要的上下文、重复请求、错误架构选择，通常同时制造慢和贵

所以与其把“省钱”和“提速”分成两个项目，不如统一看成：

  • 请求设计优化

3. 推理优化的目标不该是“最便宜”，而是“单位业务价值最优” ​

很多团队初期会把优化目标写成：

  • 降低平均请求成本

这太窄了。

更成熟的目标通常是同时优化：

  • 单成功任务成本
  • 首响应体验
  • 端到端完成时长
  • 成功率
  • 质量下限
  • 峰值稳定性

一句话理解：

  • 不是最便宜的请求最好，而是 在满足 SLA 和质量下限前提下，单位业务价值最优 的请求最好

4. 真正要先做的，不是换模型，而是做“请求剖面” ​

在你开始改任何一项策略之前，最好先把请求拆账。

一份有工程价值的请求剖面，至少要回答：

  1. 输入 token 有多少
  2. 输出 token 有多少
  3. reasoning token 有多少
  4. 工具 schema 占多少
  5. 检索注入占多少
  6. 历史会话占多少
  7. 模型推理用了多久
  8. 工具与外部系统等了多久
  9. 最终这个任务是不是成功完成了

如果没有这份剖面，后面很多“优化”都会变成：

  • 只是在凭感觉删内容

5. 推理成本主要来自哪里 ​

最常见的成本来源通常不是一项，而是多项叠加。

5.1 输入 token 太多 ​

例如：

  • system prompt 过长
  • few-shot 堆太多
  • 检索片段过多
  • 历史会话无限保留
  • 工具定义过宽

5.2 输出 token 太多 ​

例如：

  • 要求模型长篇解释
  • 未设置输出边界
  • 本来只需要 JSON，却生成大段自然语言
  • reasoning budget 过宽

5.3 请求次数太多 ​

例如：

  • 不必要的多轮调用
  • 工具循环太长
  • 同一问题反复问模型
  • 容错靠重试堆出来

5.4 模型规格过重 ​

例如：

  • 简单分类任务也走重模型
  • 路由、提取、生成全都走同一模型

5.5 模态成本 ​

例如：

  • 图像输入
  • 音频输入
  • 视频生成
  • 长语音会话

5.6 链路冗余 ​

例如：

  • 检索结果重复
  • 工具返回大块无关文本
  • 多模型之间重复消费相同上下文

5.7 控制面成本 ​

例如：

  • 轮询过密
  • webhook 失败重试
  • 过度细碎的任务拆分
  • 状态机切换太频繁

6. 延迟优化必须先分清 TTFT、生成时延和端到端时延 ​

很多团队只有一个“平均响应时间”指标，这在 AI 系统里不够用。

至少要拆成三类：

6.1 TTFT：首 token 时间 ​

这更接近用户体感里的：

  • “为什么一直没反应”

6.2 生成时延 ​

这是模型开始吐字后，到产出完整结果所需的时间。

6.3 端到端时延 ​

这包括：

  • 检索
  • 模型
  • 工具
  • 后处理
  • 审批等待
  • 渲染

如果你不拆这三类，最常见的误判就是：

  • 明明是检索慢，却怪模型慢
  • 明明是工具慢，却去压 token

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

结合 OpenAI 当前 Latency optimization、Prompt caching、Background mode、Production best practices 等官方资料，可以把高价值建议翻译成更具体的工程动作：

  1. 缩短输入
  2. 缩短输出
  3. 减少无意义请求次数
  4. 让重复前缀吃缓存
  5. 让不该同步的任务离开同步链路
  6. 并行化可并行步骤
  7. 收缩工具面与状态面
  8. 把回放、轮询、重试纳入成本口径

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

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

8. 优化路径一：先减少无效 token ​

很多高收益优化并不需要换模型，而是：

  • 先让模型少看无效内容

8.1 压 system prompt ​

最常见的问题不是“规则太少”，而是：

  • 规则重复
  • 历史版本残留
  • 本应写进 schema 的内容继续堆在 prompt 里

8.2 控制 few-shot ​

few-shot 的问题通常不是“有没有用”，而是：

  • 用得太多
  • 顺序不稳定
  • 对当前 route 其实并不相关

8.3 控制检索上下文 ​

别把“多给几段更保险”当默认策略。

真正更稳的方向通常是：

  • 控证据密度
  • 去重
  • 只留高价值片段

8.4 控制会话历史 ​

无限追加历史几乎一定会带来：

  • 成本涨
  • TTFT 涨
  • 旧信息污染新任务

8.5 控制工具 schema ​

大工具面和宽 schema 是最常见的隐性成本源之一。

9. 优化路径二：让重复前缀变成缓存收益 ​

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

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

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

通常包括：

  • instructions
  • 稳定 policy
  • 固定 few-shot
  • 长期不变的 schema
  • 稳定工具定义

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

通常包括：

  • 用户输入
  • 实时变量
  • 本轮临时证据
  • 刚返回的工具结果

9.3 缓存真正的关键不在“开没开” ​

真正关键在于：

  • 前缀是否稳定
  • 顺序是否稳定
  • route bundle 是否稳定

如果每次都重排规则、重排工具、重排 few-shot，命中率就会很差。

9.4 缓存命中最好按 route / tenant / task bucket 看 ​

全局平均命中率通常没有太大指导意义。

更实用的观察方式通常是按：

  • route
  • tenant tier
  • task bucket
  • model family

拆开看。

10. 优化路径三：让请求走对模型，而不是都走最强模型 ​

这一步真正的关键不是：

  • “换便宜模型”

而是：

  • 不同任务应该被不同能力档位承接

10.1 按任务分层 ​

例如：

  • 分类
  • 抽取
  • RAG 问答
  • 长分析
  • 多工具 Agent

10.2 按价值分层 ​

不是所有任务都值得花高成本。

10.3 按置信度分层 ​

如果一个轻量模型已经足够确定，就没有必要把所有请求都升级。

10.4 路由不是一次性规则，而是持续评测的策略 ​

这意味着你最好同时看：

  • 任务级成功率
  • 单成功任务成本
  • 路由后的错误分布

11. 优化路径四：把不该同步的任务移出同步链路 ​

这是很多系统里最被低估、但收益极高的一步。

11.1 什么时候适合同步 ​

更适合同步返回的通常是：

  • 短问答
  • 低延迟客服回复
  • 快速分类与路由

11.2 什么时候适合后台模式 ​

更适合 background 的通常是：

  • 长文档分析
  • 多步工具编排
  • 长推理任务
  • 报告生成

11.3 什么时候适合 Batch ​

更适合 batch 的通常是：

  • 样本评测
  • 批量抽取
  • 批量改写
  • 历史补算

11.4 什么时候适合 Flex ​

更适合 flex 的通常是：

  • 成本敏感型低优先级任务
  • 非紧急异步任务
  • 夜间补算

12. 优化路径五：把检索链路做短，而不是只怪模型 ​

很多“模型太慢”的问题，根因其实在检索链路。

12.1 常见问题 ​

  • chunk 太多
  • top-k 太高
  • rerank 过重
  • retrieval 和 post-filter 设计不合理
  • 无意义证据重复

12.2 优化原则 ​

  • 控召回数量
  • 控证据密度
  • 控重排成本
  • 控跨租户与跨源噪声

12.3 常见高收益动作 ​

  • 先去重
  • 缩短 chunk
  • 重新设计 metadata
  • 改成 hybrid
  • 只对候选做 rerank

13. 优化路径六：减少工具循环和失败重试 ​

很多团队看到高账单，会先看 token。

但真实系统里的大头经常来自：

  • 过长工具循环
  • 写错参数后的重复调用
  • 失败重试链路

13.1 真实成本往往来自哪里 ​

例如：

  • 工具定义太宽，模型试错太多
  • 失败结果语义不清，模型重复撞墙
  • 同一步骤被多个模型重复执行

13.2 这类问题最常见的优化方式 ​

  • 收缩工具面
  • 增强失败类型语义
  • 把幂等和重试边界写清
  • 对高副作用工具加审批

14. 优化路径七：让控制面也进入优化视野 ​

很多团队会低估控制面的成本。

所谓控制面，包括：

  • 轮询
  • webhook
  • 状态机切换
  • 队列调度
  • 审批回调

14.1 轮询不是免费动作 ​

如果 background 任务很多，过密 polling 会带来：

  • 额外请求风暴
  • 控制面延迟
  • 账单与限额浪费

14.2 webhook 也要算总成本 ​

webhook 的问题通常不是“能不能发”，而是：

  • 重试多少次
  • 签名校验怎样做
  • 回调失败如何兜底

14.3 状态机过细也会制造成本 ​

如果任务被拆得过细，可能会带来：

  • 过多控制流切换
  • 过多日志与事件
  • 过多状态同步

15. 实时语音、长文本分析和普通问答，优化重点完全不同 ​

这三类场景不应该共用同一套优化目标。

15.1 普通问答 ​

更关注：

  • TTFT
  • 请求成本
  • 准确率

15.2 长文本分析 ​

更关注：

  • context 管理
  • background / batch
  • checkpoint / resume

15.3 实时语音 ​

更关注：

  • 流式响应
  • 会话连续性
  • 实时成本曲线
  • 中途打断与恢复

如果把这三类任务都用同一套指标和同一条 lane 承接，系统很容易变形。

16. 成本优化必须和评测绑定，否则很容易“省出事故” ​

这是最重要的工程边界之一。

任何降本动作如果不配套评测，都很容易导致：

  • 结构化输出成功率下降
  • 工具参数错误率上升
  • 检索相关性退化
  • 高风险动作误执行

16.1 最值得评测的优化动作 ​

例如：

  • 缩 prompt
  • 缩 few-shot
  • 减 top-k
  • 降模型
  • 改 lane
  • 改 output 上限

16.2 不是所有变快变便宜都是真优化 ​

如果代价是：

  • 用户成功率下降
  • 人工接管暴增
  • 审批拒绝率上升

那就不是优化，而是：

  • 把成本转嫁到了别处

17. 一个稳妥的最小优化顺序 ​

更成熟的顺序通常是：

17.1 第一步：先测量 ​

没有剖面，就没有真正优化。

17.2 第二步：先减无效上下文 ​

通常这是收益最高、风险相对可控的动作。

17.3 第三步：再做同步 / 异步 / 批处理拆分 ​

把不该同步的任务移出去，经常比抠 token 更值。

17.4 第四步：再做模型路由和缓存 ​

这一步建立在你已经知道请求结构和 lane 分层的前提上。

17.5 第五步：最后再细抠复杂策略 ​

例如：

  • 更复杂的 rerank 策略
  • 更细的多模型升级链
  • 更复杂的优先级与 incident mode

18. 建议重点监控哪些指标 ​

18.1 成本类 ​

  • 单请求成本
  • 单任务成本
  • 单成功任务成本
  • reasoning token 占比
  • 缓存收益

18.2 延迟类 ​

  • TTFT
  • 生成时延
  • 工具等待时延
  • 端到端时延
  • background 完成时长

18.3 质量类 ​

  • 结构化输出成功率
  • tool args 正确率
  • 最终任务成功率
  • 审批后可执行率

18.4 架构类 ​

  • 各 lane 请求占比
  • 重试率
  • polling 频率
  • webhook 失败率
  • 队列 backlog

18.5 检索与上下文类 ​

  • 输入 token
  • 检索注入 token
  • 历史 token
  • 工具 schema token
  • rerank 耗时

19. 最常见的反模式 ​

19.1 还没测量，就开始换模型 ​

19.2 只看平均请求成本，不看单成功任务成本 ​

19.3 只优化模型，不优化检索、工具和控制面 ​

19.4 把长任务硬塞同步链路 ​

19.5 prompt caching 开了，但前缀天天变 ​

19.6 降本动作不跑评测 ​

19.7 所有任务共用一套模型和一条 lane ​

19.8 只看 token，不看重试和轮询 ​

20. Anthropic 和 Gemini 的优化思路，为什么也值得借鉴 ​

虽然这页主线以 OpenAI 的运行能力为参照，但其他主流平台的官方资料也在强调非常相似的工程方向。

20.1 Anthropic ​

Anthropic 当前官方资料强调：

  • prompt caching
  • token-efficient tool use
  • rate limits
  • 批处理与长上下文治理

这些结论和 OpenAI 的核心模式并不冲突，反而在重复确认：

  • 长前缀要治理
  • 工具面要收缩
  • 配额和限流要进入架构设计

20.2 Gemini ​

Google Gemini 当前官方资料同样强调：

  • context caching
  • batch API
  • long context
  • structured output

这说明跨厂商放在一起看，真正稳定的不是某个字段，而是：

  • 长上下文时代，缓存、批量化、分 lane 和结构化 contract 才是长期有效的优化方向

21. 推荐搭配阅读 ​

22. 重点官方资源 ​

23. 一句话总结 ​

推理加速与成本优化真正要做的，不是零散地“砍 token”或“换便宜模型”，而是：

  • 把上下文、模型、工具、lane、缓存、批处理和控制面一起纳入一套可观测、可评测、可分层的性能工程体系