#AI 应用如何做成本优化

AI 成本优化不是把模型换便宜一点这么简单。

便宜模型可能降低单次价格，但也可能带来更多重试、更差的结构化输出、更低的用户满意度和更高的人工处理成本。真正有效的优化，需要同时看成本、延迟、质量和体验。

对前端和全栈工程师来说，AI 成本优化最好从系统链路入手：先建立观测，再控制 token，再做模型路由和缓存，最后用队列、限流、降级和产品交互把成本稳定在可运营范围内。

#先定义优化目标

成本优化最怕目标含糊。

如果只说“降低 AI 成本”，团队很容易做出局部优化：减少上下文、换小模型、缩短输出、提高缓存 TTL。短期账单降了，长期可能带来答非所问、引用缺失、用户重复提问、人工介入增加。

更好的目标应该同时包含四类指标：

优化时要明确是哪一种成本在失控：是长文档输入太贵，还是输出太长，还是 Agent 步数太多，还是某个租户滥用，还是失败重试过多。

没有这个拆分，优化动作很容易打偏。

#第一步是可观测

AI 成本优化的第一步不是改 prompt，而是把每次请求记录清楚。

推荐把一次模型调用抽象成 run，并记录这些字段：

• run id。
• feature、task type、user id、tenant id。
• model、provider、route policy。
• prompt version。
• input tokens、output tokens。
• estimated cost。
• TTFT、total latency。
• cache key、cache hit、cache layer。
• retry count、fallback target。
• status、error code。
• metadata，例如文档大小、检索片段数、工具调用数。

这些数据应该在服务端统一生成，并且能和前端消息、用户反馈、Eval 样例关联起来。

有了这些数据，你才能回答：

• 哪个功能最贵？
• 哪个模型最慢？
• 哪个 prompt 版本让输出变长？
• 哪些请求没有命中缓存？
• 哪个租户接近预算？
• 哪个 fallback 被频繁触发？

没有观测的优化，常常是在黑箱里调参。

#给 token 设置预算

Token 预算是 AI 成本优化的基本盘。

每个功能都应该有清晰的上下文预算，而不是“能塞多少塞多少”。预算可以按任务类型定义：

预算不只是 max_tokens。它还包括：

• system prompt 最大长度。
• 历史消息保留规则。
• 检索片段数量和单段长度。
• 工具 schema 注入数量。
• 示例数量。
• 输出结构和详细程度。

前端也能参与 token 预算设计。例如给用户提供“简短 / 标准 / 详细”输出长度选择，对超大文件上传做提示，默认折叠低价值上下文，允许用户停止生成。

一个重要原则是：默认输出应该足够有用，但不要默认无限详细。

#缩短上下文，而不是盲目压缩

减少输入 token 的常见做法是压缩 prompt，但真正有效的是减少无关上下文。

可以从几个方向做：

第一，历史消息分层。

保留最近几轮原文，把更早的对话总结成结构化记忆。总结要包含用户目标、已确认事实、未解决问题和关键偏好，而不是把旧聊天压成一段模糊摘要。

第二，检索片段筛选。

RAG 不应该只看 topK。还要考虑片段去重、权限过滤、时间新鲜度、引用覆盖、重排和 token 预算。宁愿给模型 5 段高相关内容，也不要给 20 段混杂材料。

第三，工具按需暴露。

不要每次请求都注入所有工具。可以先做轻量意图识别，再只提供当前任务需要的工具集合。工具 schema 很长时，这个优化非常明显。

第四，模板精简。

Prompt 里常常堆积历史遗留规则。应该定期检查哪些规则真正影响质量，哪些只是心理安慰。可以通过 Eval 对比删除前后的效果。

第五，输出格式精简。

结构化输出字段越多，生成越长，失败面也越大。只保留前端渲染和业务处理真正需要的字段。

#模型路由是成本杠杆

模型路由的目标，是让每类任务使用“刚好够用”的模型。

一个基础路由策略可以包含：

• cheap：高频、低风险、可校验任务。
• fast：实时交互、短输出任务。
• smart：复杂推理、长上下文、低容错任务。
• coding：代码理解、修改和解释。
• vision：图片、截图、OCR、视觉问答。
• local：隐私敏感、离线、可接受本地能力边界的任务。

路由决策可以来自任务类型、用户套餐、输入长度、风险等级、SLA、预算、模型健康状态和 Eval 结果。

这里最关键的是质量门槛。模型路由必须和 Eval 绑定，否则团队无法知道便宜模型在哪些任务上已经不够用。

还要注意 fallback。主模型失败时切到备用模型，可能成本更高，也可能输出风格不同。fallback 应该记录清楚，并在必要时告诉前端进入 degraded mode。

#缓存要分层设计

缓存是降低 AI 成本的高收益手段，但必须谨慎设计 cache key 和失效策略。

不要只想“缓存最终回答”。AI 应用更适合分层缓存：

设计 cache key 时，至少要考虑：

• prompt version。
• model 或模型能力等级。
• 用户和租户权限。
• 知识库版本。
• 工具结果版本。
• 输出语言和格式。
• temperature 等影响输出的参数。

如果 key 太粗，容易返回错误结果或泄漏权限。如果 key 太细，命中率很低。

对于前端体验，缓存命中可以让响应变快，但也要避免让用户觉得 AI “机械重复”。创作类任务可以缓存中间结果，问答类任务可以缓存引用和检索，强个性化任务要谨慎缓存最终回答。

#控制多步任务

Agent、Workflow 和工具调用是成本放大的重灾区。

多步任务应该设置硬边界：

• 最大模型调用次数。
• 最大工具调用次数。
• 总 token 预算。
• 总耗时上限。
• 最大重试次数。
• 需要人工确认的高风险动作。

模型不能无限规划、无限反思、无限尝试。即使每一步都看起来合理，整体也可能变成不可控任务。

对长任务，应该尽量异步化。前端不一定要一直挂着一个 HTTP 请求等待，可以让后端创建 job，前端订阅状态或轮询结果。这样可以更好地做队列、取消、恢复和优先级。

成本优化不是让所有任务都更快，而是让昂贵任务进入合适的执行通道。

#前端交互会影响成本

前端不是成本优化的旁观者。

一些交互设计会直接减少浪费：

• 默认开启 Streaming，让用户尽早判断方向。
• 提供停止生成，避免无效输出继续消耗。
• 对重复点击做请求去重和按钮状态锁定。
• 对长文档上传显示大小和处理预估。
• 对输出长度提供简短、标准、详细选项。
• 对高成本动作做确认，例如“分析整个代码库”。
• 对失败重试解释原因，避免用户盲目连点。
• 对缓存结果提供刷新入口。

也有一些交互会放大成本：

• 输入变化就自动调用大模型。
• 每个候选卡片都实时生成一段 AI 文案。
• 页面加载时为所有用户预生成个性化内容。
• 用户未确认前就启动长任务。
• 重试按钮没有幂等保护。

AI 体验设计必须把“等待、取消、确认、重试、刷新、降级”当成一等状态。

#限流和预算不是失败

很多团队不愿意在 AI 功能里做限制，担心伤害体验。但没有限制的 AI 功能，很难长期运营。

常见控制方式包括：

• 按用户限制每分钟请求数。
• 按租户限制每日或每月 token。
• 按功能设置预算。
• 按模型设置并发上限。
• 对免费用户限制高成本模型。
• 对超大任务进入后台队列。
• 对异常行为触发冷却时间。

关键是提示要清楚。用户不应该只看到“失败了”，而应该知道是额度用完、任务排队、输入过大、模型繁忙，还是需要升级套餐。

从架构上看，限流和预算最好放在 AI Gateway 或统一模型调用层。否则每个业务接口各做一套，很难统一口径。

#常见坑

第一个坑，是先换便宜模型。

模型价格是成本的一部分，但不是全部。便宜模型如果导致格式失败、用户反复追问、人工介入增加，总成本可能更高。先做观测和 Eval，再换模型。

第二个坑，是把 max_tokens 当作成本控制。

限制输出长度有用，但输入 token 也可能很贵。很多高账单来自长 system prompt、长历史、长检索片段和工具 schema。

第三个坑，是缓存没有权限维度。

企业 AI 应用尤其危险。同一个问题，不同用户可能有不同可见数据。缓存 key 如果不包含权限范围，可能出现越权答案。

第四个坑，是忽略失败成本。

超时、格式错误、重试、fallback 都会花钱。一个错误率很高的功能，账单可能被失败请求吃掉。

第五个坑，是只优化平均值。

成本长尾很重要。要看 P95、P99、重度用户、超大文档、长会话和 Agent 最大步数。

第六个坑，是没有把优化结果回归测试。

删 prompt、缩上下文、换模型、加缓存都可能让质量退化。每次优化都应该跑核心 Eval，并对线上反馈保持观察。

#小结

AI 成本优化是一套系统工程。

先观测，知道钱花在哪里；再给 token、步骤和延迟设置预算；然后用模型路由、分层缓存、上下文裁剪、异步队列和限流控制高频成本；最后通过前端交互减少无效生成和重复请求。

最重要的是，不要把成本、延迟和质量分开看。一个真正可运营的 AI 应用，应该能解释每次请求为什么选这个模型、为什么带这些上下文、为什么可以缓存、为什么允许重试，以及它花的钱是否换来了足够稳定的用户价值。