API成本与性能

3.1 AI API 的性能不是一个指标，而是一组体验约束#

传统 API 的性能通常用平均响应时间、P95 响应时间、QPS、错误率来衡量。AI API 也需要这些指标，但不够。因为大模型生成不是简单查库，它有一个逐步生成 Token 的过程，用户感受到的速度通常分成两个阶段：

1
用户发起请求
2
-> API 鉴权和参数校验
3
-> AI 编排层组装上下文和 Prompt
4
-> 调用模型
5
-> 模型开始生成第一个 Token
6
-> 模型持续生成完整答案
7
-> 后处理、风控、格式校验
8
-> 返回前端或业务系统

这里至少有两个关键时间：

对产品经理来说，不能只问“接口平均多久返回”。平均值经常掩盖问题。客服场景中，平均 2 秒但 P99 20 秒，用户依然会投诉；经营分析场景中，平均 20 秒可能可以接受，因为用户愿意等一份完整报告；输入法联想或搜索改写场景中，500 毫秒都可能太慢。

所以性能指标必须和场景绑定。

1
实时交互类：首字延迟优先，例如客服、导购、写作助手。
2
后台生成类：吞吐和成本优先，例如批量商品文案、合同摘要。
3
决策辅助类：正确性和可解释优先，例如经营分析、风险审核。
4
高风险动作类：安全和审计优先，例如自动发券、自动改价、自动发邮件。

这会直接影响产品设计。实时交互场景要优先支持流式输出，让用户尽早看到内容；后台生成场景可以排队、批处理、异步通知；决策辅助场景可以允许更长延迟，但必须保留引用、日志和复核入口。

3.2 成本的本质是“请求数 × Token 数 × 模型单价 × 失败放大系数”#

很多团队低估 AI API 成本，是因为只看一次调用的价格。真实成本通常来自四个乘法项：

1
总成本 =
2
有效请求数
3
× 单次平均输入 Token
4
× 单次平均输出 Token
5
× 模型单价
6
× 重试和失败放大系数
7
× 高峰冗余系数

如果一个客服机器人每天 10 万次请求，每次输入上下文 3000 Token，输出 500 Token，使用较强模型，且失败重试率 8%，成本会比“每次只问一句话”的估算高很多。更现实的是，很多上下文并不是用户真正需要的，而是系统为了保险把一大段知识库、用户历史、订单信息、政策文档都塞进 Prompt。

成本浪费常见于 8 个地方：

这里有一个重要判断：成本优化不是单纯压低模型单价，而是减少不必要的智能调用，把强模型留给真正需要强推理的任务。

一个成熟的 AI API 应该像运营预算一样被管理。你需要知道每个业务线消耗多少、每个功能消耗多少、每类用户消耗多少、每个模型版本消耗多少，以及这些消耗换来了什么业务指标提升。否则增长团队一做活动，客服入口流量上来，API 成本可能比转化收益增长更快。

3.3 流式输出解决的是体验，不一定解决总耗时#

流式输出是 AI 产品中非常重要的交互能力。它让模型边生成边返回，用户可以很快看到第一个字。

1
非流式：
2
用户提交 -> 等待完整生成 -> 一次性显示答案
3

4
流式：
5
用户提交 -> 很快显示第一段 -> 持续追加内容 -> 结束

流式输出对聊天、客服、写作助手、报告生成尤其有效，因为用户会觉得系统正在工作。但产品负责人要清楚：流式输出主要改善“感知速度”，不一定缩短完整响应时间。模型仍然要生成同样多 Token，甚至因为用户看到了生成过程，更容易容忍长答案，反而增加输出长度。

因此，流式输出要和输出控制一起设计：

• 首屏先给结论，再展开理由。

• 对长回答提供“继续展开”按钮，而不是默认生成全部。

• 客服场景先返回可执行建议，再补充政策解释。

• 报告场景先展示目录和关键结论，再异步补全文档。

• 对移动端限制默认字数，避免用户在小屏幕等待长文本。

产品上要避免一种错误：把流式输出当作性能优化的全部。它解决的是用户感知，但成本、吞吐、并发和失败率仍然要靠缓存、路由、限流、降级和架构优化。

3.4 缓存不是“偷懒”，而是 AI API 的必要产品能力#

很多 AI 场景有大量重复或近似重复问题。客服就是典型例子：

• “怎么退货？”

• “七天无理由怎么退？”

• “收到货不满意能不能退？”

• “退货运费谁出？”

• “我买的衣服可以退吗？”

这些问题不应该每次都完整调用大模型生成。合理做法是建立缓存层。

缓存可以分成三类：

客服场景中，一个实用缓存链路可以这样设计：

1
用户问题
2
-> 输入清洗和意图识别
3
-> 精确缓存命中？
4
   -> 是：返回标准答案
5
   -> 否：进入语义检索
6
-> 语义缓存命中且置信度高？
7
   -> 是：返回缓存答案，并记录命中
8
   -> 否：调用 RAG 或模型生成
9
-> 生成结果通过质检？
10
   -> 是：返回，并按策略写入缓存
11
   -> 否：规则兜底或人工接管

缓存的产品难点不在技术实现，而在边界。什么答案可以缓存？缓存多久？政策变化后如何失效？哪些问题不能用缓存？命中后是否需要显示“根据最新政策”？不同用户的订单状态不同，能不能共用答案？

一般原则是：

• 政策类、流程类、解释类问题适合缓存。

• 涉及个人订单、价格、库存、账户、风控的问题必须谨慎缓存。

• 高风险问题即使命中缓存，也要检查知识版本和权限。

• 缓存答案必须有来源、版本、过期时间和命中日志。

对增长负责人来说，缓存还有一个现实价值：它让 AI 功能可以支撑活动流量。如果大促期间每个用户都实时调用大模型，高峰成本和延迟会双双上升；如果常见问题可以缓存命中，系统能把模型资源留给复杂问题。

3.5 小模型路由：不是所有任务都需要最强模型#

很多 AI API 的成本问题来自“所有任务都用同一个强模型”。这是最简单的接法，但不是合理的产品架构。

不同任务对模型能力的要求不同：

小模型路由的基本思路是：先判断任务难度，再决定使用哪个模型。

1
请求进入
2
-> 场景识别
3
-> 难度评估
4
-> 风险评估
5
-> 成本预算检查
6
-> 选择模型：
7
   - 规则 / 缓存
8
   - 小模型
9
   - 中等模型
10
   - 强模型
11
   - 人工接管

产品上要定义清楚路由标准，而不是让研发随意配置。例如：

• 意图分类置信度大于 0.9：走缓存或标准答案。

• 问题涉及个人订单：必须查询订单系统，不能只依赖通用回答。

• 用户情绪等级高：回答前先触发人工关注标签。

• 涉及退款金额、处罚、法律、医疗、金融：禁止自动决策。

• 连续两次模型回答不合格：停止重试，转人工或返回兜底说明。

小模型路由会带来一个项目管理挑战：评估复杂度上升。你不再评估一个模型，而是评估一套路由策略。指标也要拆开看：

• 路由准确率：简单问题是否真的走了低成本路径？

• 升级率：多少请求从小模型升级到强模型？

• 误降级率：复杂问题被低能力路径处理导致错误的比例。

• 成本节省率：与全量强模型相比节省多少。

• 用户满意度：节省成本是否伤害体验。

3.6 降级不是失败，而是稳定性设计#

传统互联网产品很早就有降级机制。AI 产品更需要降级，因为模型供应商可能限流，网络可能抖动，模型输出可能格式错误，高峰期可能排队，敏感内容可能被安全策略拦截。

AI API 常见降级层级：

1
L0 正常路径：缓存 / 小模型 / 强模型按策略工作
2
L1 体验降级：流式输出关闭、缩短回答、减少引用片段
3
L2 能力降级：强模型不可用时切到备用模型
4
L3 功能降级：复杂生成改为标准答案或表单引导
5
L4 人工接管：高风险或连续失败转人工
6
L5 暂停入口：极端情况下关闭高成本功能入口

产品上必须提前写清楚：降级时用户看到什么。不能让前端只显示“系统错误”。例如客服场景可以这样设计：

这里的关键不是让 AI 看起来永远正确，而是让系统在不确定时仍然可控。真正成熟的 AI 产品不是“永不失败”，而是“失败时不造成更大损失”。

3.7 成本和性能要进入 PRD，而不是只留在技术方案#

很多 PRD 写 AI 功能时只写“用户输入问题，系统返回答案”。这不够。AI API 的 PRD 至少要补上这些约束：

这类内容对产品负责人非常关键，因为它决定了 AI 功能能不能持续运营。没有成本上限的 AI 功能不适合大规模增长；没有性能 SLO 的 AI 功能不适合进入核心链路；没有降级策略的 AI 功能不适合承接高风险用户场景。

4.1 业务背景#

某国内综合电商平台在大促期间上线智能客服助手，目标是减少人工客服压力，提高售后问题的首响速度。接入初期采用统一大模型回答用户问题，所有咨询都走同一个模型接口。

大促前日均咨询 8 万次，大促当天峰值预计超过 40 万次。上线测试发现两个问题：第一，晚 8 点活动开始后接口延迟明显上升，P95 完整响应超过 18 秒；第二，按峰值估算，单日模型调用成本可能超过原预算 4 倍。

4.2 相关角色#

4.3 原始流程#

1
用户进入客服
2
-> 输入问题
3
-> 后端拼接用户问题、订单信息、售后政策
4
-> 调用统一大模型
5
-> 返回完整答案
6
-> 用户继续追问或转人工

原流程的问题很明显：

• 所有问题都调用强模型，包括“怎么退货”“物流到哪了”这类简单问题。

• 每次 Prompt 都带入完整政策片段，Token 成本高。

• 没有缓存，重复 FAQ 每次重新生成。

• 模型超时后自动重试，重试成本进一步放大。

• 转人工策略滞后，用户多轮不满意后才转人工。

• 业务无法看出哪些问题消耗最多成本。

4.4 AI 改造流程#

改造后，平台将客服 AI API 拆成“前置判断、缓存、模型路由、生成、质检、降级”六层。

1
用户问题
2
-> 输入清洗：去除无效字符、识别重复点击
3
-> 场景识别：物流、退款、退货、发票、活动、投诉
4
-> 权限和订单校验：判断是否需要读取个人订单
5
-> 缓存层：
6
   - 精确 FAQ 缓存
7
   - 语义缓存
8
   - 政策版本缓存
9
-> 模型路由：
10
   - 规则答案
11
   - 小模型分类
12
   - 中模型生成
13
   - 强模型复杂处理
14
-> 输出质检：格式、敏感承诺、政策引用、置信度
15
-> 返回答案 / 转人工 / 标准流程兜底

具体策略：

4.5 数据 / 系统依赖#

4.6 方案架构#

1
客服前端
2
  |
3
客服业务后端
4
  |
5
AI API 网关
6
  |-- 鉴权 / 限流 / 成本归因
7
  |-- 输入校验 / 防重复点击
8
  |
9
AI 编排层
10
  |-- 意图识别
11
  |-- 精确缓存
12
  |-- 语义缓存
13
  |-- 订单查询工具
14
  |-- 知识库检索
15
  |-- 模型路由
16
  |-- 输出质检
17
  |-- 降级和转人工
18
  |
19
模型层
20
  |-- 小模型：分类、提取、情绪识别
21
  |-- 中模型：政策解释、常规回复
22
  |-- 强模型：复杂投诉、多轮总结
23
  |
24
工单与监控

4.7 关键指标#

4.8 主要风险#

4.9 复盘结论#

这类项目的关键不是“让 AI 尽量回答所有问题”，而是把问题分层。FAQ、订单状态、政策解释、复杂投诉、赔付争议本来就不该走同一条链路。通过缓存、路由和降级，平台把强模型资源留给真正复杂的问题，同时让高峰期服务稳定。

从产品角度看，成本优化不是削弱用户体验，而是让体验更可持续。一个每次都用强模型但高峰期排队的客服系统，不如一个能快速处理 70% 标准问题、稳妥接管 20% 复杂问题、明确拒绝 10% 高风险问题的系统。

5.1 业务背景#

一家 B2B SaaS 公司为销售团队提供客户健康度分析。原功能是用户点击“生成客户分析报告”，系统把 CRM 记录、邮件摘要、会议纪要、工单历史全部拼进 Prompt，调用大模型生成一份完整报告。

Demo 阶段效果很好，但上线后出现三个问题：

• 报告生成平均需要 35 秒，用户经常关闭页面。

• 长上下文调用成本高，销售团队频繁重复生成同一客户报告。

• 高峰时段多个销售经理批量生成报告，接口排队严重。

5.2 相关角色#

5.3 原始流程#

1
用户点击生成报告
2
-> 后端读取 CRM、邮件、会议、工单
3
-> 拼接长上下文 Prompt
4
-> 调用强模型
5
-> 等待完整生成
6
-> 页面展示报告

主要问题：

• 所有数据都在点击时实时读取和生成，用户等待时间长。

• 每次报告都重新总结历史数据，即使数据没有变化。

• 长上下文模型成本高，但很多报告只需要更新最近一周变化。

• 报告生成失败后用户只看到错误，没有可用替代内容。

5.4 AI 改造流程#

改造方案把报告生成拆成“预计算摘要 + 异步任务 + 增量更新 + 前台快速预览”。

1
后台定时任务
2
-> 每日汇总客户数据变化
3
-> 生成分模块摘要：CRM、会议、工单、风险、机会
4
-> 写入客户分析缓存
5

6
用户点击报告
7
-> 立即展示上次可用报告和更新时间
8
-> 判断数据是否有新增
9
-> 如需更新，创建异步生成任务
10
-> 前端展示任务进度
11
-> 完成后推送通知并刷新报告

具体策略：

5.5 数据 / 系统依赖#

5.6 方案架构#

1
数据源
2
  |-- CRM
3
  |-- 邮件
4
  |-- 会议
5
  |-- 工单
6
  |
7
数据聚合层
8
  |-- 清洗
9
  |-- 权限过滤
10
  |-- 增量检测
11
  |
12
AI 摘要层
13
  |-- 每日模块摘要
14
  |-- 风险分类
15
  |-- 机会识别
16
  |
17
报告服务
18
  |-- 上次报告缓存
19
  |-- 异步生成任务
20
  |-- 版本管理
21
  |-- 通知
22
  |
23
前端
24
  |-- 快速预览
25
  |-- 生成进度
26
  |-- 报告更新提醒

5.7 关键指标#

5.8 主要风险#

5.9 复盘结论#

这个案例说明：不是所有 AI 能力都应该设计成同步聊天接口。报告、分析、总结、批量生成更适合异步任务和预计算。用户真正需要的不是“看着模型实时写完整报告”，而是快速看到已有结论，并在必要时得到更新。

对项目负责人来说，这类改造往往比换更快的模型更有效。因为瓶颈不是模型速度本身，而是产品流程把所有工作都压到了用户点击后的几十秒里。通过预计算、缓存、异步和增量更新，可以同时降低延迟和成本。

任务：为智能客服设计缓存与降级策略#

选择一个你熟悉的客服场景，例如电商售后、在线教育课程咨询、本地生活退款、SaaS 产品支持、企业内部 IT 服务台。为它设计一份 AI API 成本与性能方案。

必须包含：

1. 场景说明：用户是谁，什么时候发起咨询，业务目标是什么。

2. 问题分类：至少列出 8 类用户问题。

3. 成本分层：哪些问题走规则，哪些走缓存，哪些走小模型，哪些走强模型，哪些转人工。

4. 缓存策略：精确缓存、语义缓存、结果缓存分别用在哪里。

5. 降级策略：模型超时、知识库不可用、低置信度、高峰限流时如何处理。

6. 指标设计：至少 12 个指标，覆盖体验、成本、准确性、风险和增长。

7. PRD 片段：写出性能目标、成本上限、异常处理和监控需求。

验收标准#

7.1 理解题#

题 1：首字延迟和完整响应时间有什么区别？为什么 AI 产品要分别看这两个指标？

参考答案： 首字延迟是用户提交请求到看到第一个返回字符的时间，影响用户是否感觉系统有反应。完整响应时间是用户拿到完整答案的时间，影响业务流程是否能完成。流式输出可以降低用户感知等待，但不一定缩短完整生成时间，所以两者都要看。

题 2：为什么缓存是 AI API 成本优化的重要手段？

参考答案： 很多 AI 请求是重复或近似重复的，尤其是客服、导购、政策问答。缓存可以避免对相同或相似问题反复调用模型，降低 Token 消耗和模型费用，也能提高响应速度。但缓存必须管理版本、权限、过期时间和误命中风险。

题 3：小模型路由的核心价值是什么？

参考答案： 小模型路由的价值是把不同难度、不同风险、不同成本敏感度的任务分配给合适能力的处理路径。简单分类、字段提取、FAQ 可以用规则、小模型或缓存，复杂推理再使用强模型。这样可以降低成本，提高吞吐，同时保留复杂场景的质量。

题 4：降级策略为什么不能只写“接口失败提示重试”？

参考答案： AI API 失败可能来自超时、限流、模型格式错误、知识库不可用、置信度低或安全拦截。不同失败原因需要不同处理。简单提示重试会造成体验差、重复调用和成本放大。成熟方案应包括备用模型、标准答案、异步处理、人工接管和入口限流。

7.2 应用题#

题 5：一个商品文案生成 API 成本过高，你会从哪些方向排查？

参考答案： 先看调用量是否异常，再看平均输入和输出 Token 是否过高；检查 Prompt 是否包含不必要字段；检查是否重复生成同一商品；检查是否所有任务都用了强模型；检查失败重试率；检查是否支持批处理和结果缓存；最后按业务线、用户类型、商品类目拆分成本，判断成本是否带来点击率、转化率或运营效率提升。

题 6：客服机器人在大促期间 P95 响应时间从 5 秒升到 20 秒，你会如何处理？

参考答案： 短期先开启高峰限流、流式输出、FAQ 缓存、标准答案兜底和人工接管；降低默认输出长度，关闭非必要长解释；复杂问题进入队列或转人工。中期建立意图识别、语义缓存、小模型路由、备用模型和成本监控。复盘时要分析流量来源、缓存命中率、强模型占比、重试率、知识库延迟和供应商限流情况。

8.1 AI API 成本优化方案模板#

1
项目名称：
2
业务场景：
3
目标用户：
4
核心目标：
5

6
一、当前问题
7
1. 当前日调用量：
8
2. 峰值 QPS：
9
3. 平均输入 Token：
10
4. 平均输出 Token：
11
5. 当前使用模型：
12
6. 单次平均成本：
13
7. 主要性能问题：
14
8. 主要成本问题：
15

16
二、请求分类
17
| 请求类型 | 占比 | 风险等级 | 当前处理 | 优化后处理 |
18
|---|---:|---|---|---|
19
| FAQ |  | 低 | 强模型 | 精确缓存 |
20
| 政策解释 |  | 中 | 强模型 | RAG + 中模型 |
21
| 订单状态 |  | 中 | 强模型 | 查库 + 模板 |
22
| 投诉争议 |  | 高 | 强模型 | 强模型 + 人工关注 |
23

24
三、缓存策略
25
1. 精确缓存：
26
   - 适用问题：
27
   - 缓存时间：
28
   - 失效条件：
29
2. 语义缓存：
30
   - 相似度阈值：
31
   - 人审策略：
32
   - 风险限制：
33
3. 结果缓存：
34
   - 适用对象：
35
   - 更新规则：
36

37
四、模型路由策略
38
| 条件 | 处理路径 | 说明 |
39
|---|---|---|
40
| 意图明确且命中 FAQ | 标准答案 | 不调用模型 |
41
| 置信度高的简单分类 | 小模型 | 控制成本 |
42
| 涉及政策解释 | RAG + 中模型 | 保证引用 |
43
| 涉及赔付争议 | 人工接管 | 避免错误承诺 |
44

45
五、降级策略
46
| 异常 | 用户体验 | 系统动作 |
47
|---|---|---|
48
| 模型超时 | 展示查询中或转人工 | 异步重试 |
49
| 供应商限流 | 返回标准流程 | 切备用模型 |
50
| 知识库不可用 | 提示人工确认 | 创建工单 |
51
| 置信度低 | 不直接回答 | 转人工 |
52

53
六、指标目标
54
| 指标 | 当前值 | 目标值 |
55
|---|---:|---:|
56
| 首字延迟 P95 |  |  |
57
| 完整响应 P95 |  |  |
58
| 缓存命中率 |  |  |
59
| 强模型调用占比 |  |  |
60
| 单次平均成本 |  |  |
61
| 日预算消耗 |  |  |
62
| 用户满意度 |  |  |
63
| 错误承诺率 |  |  |
64

65
七、上线计划
66
1. 灰度范围：
67
2. 回滚条件：
68
3. 监控看板：
69
4. 复盘节奏：

8.2 客服场景缓存与降级流程图#

1
用户提问
2
  |
3
输入校验与防重复点击
4
  |
5
意图识别
6
  |
7
是否命中精确 FAQ？
8
  |-- 是 -> 返回标准答案 -> 记录命中
9
  |
10
是否命中语义缓存？
11
  |-- 是，且置信度高 -> 返回缓存答案 -> 记录版本
12
  |
13
是否涉及个人订单？
14
  |-- 是 -> 查询订单系统 -> 模板化回答或模型补充解释
15
  |
16
是否高风险问题？
17
  |-- 是 -> 人工接管 / 只给流程说明
18
  |
19
调用模型生成
20
  |
21
输出质检
22
  |-- 通过 -> 返回答案 -> 可选写入缓存
23
  |-- 不通过 -> 降级或人工接管

8.3 PRD 片段：性能与成本约束#

1
功能名称：智能客服 AI 回复 API
2

3
性能目标：
4
- 首字延迟 P95 小于 2 秒。
5
- 完整响应 P95 小于 8 秒。
6
- 模型调用超时阈值 12 秒。
7
- 高峰期可支撑目标 QPS：____。
8

9
成本目标：
10
- 单次平均模型成本不超过 ____ 元。
11
- 日预算不超过 ____ 元。
12
- 强模型调用占比不超过 ____%。
13
- 缓存命中率目标不低于 ____%。
14

15
缓存规则：
16
- 通用 FAQ、政策解释、流程说明可缓存。
17
- 个人订单、价格、库存、账号、赔付决策不可跨用户缓存。
18
- 活动政策缓存必须绑定活动版本和失效时间。
19

20
降级规则：
21
- 模型超时：返回标准流程或转人工。
22
- 知识库不可用：不输出确定性政策承诺。
23
- 置信度低：提示人工确认。
24
- 连续失败两次：停止模型重试，创建工单。
25

26
监控需求：
27
- 按业务线、入口、用户等级、模型版本统计调用量和成本。
28
- 记录输入 Token、输出 Token、首字延迟、完整响应时间、错误码。
29
- 建立日预算 70%、90%、100% 告警。