#成本与性能专题总览

AI 应用的成本与性能问题，通常不是“模型太贵”或“接口太慢”这么简单。

同一个功能，输入长度、上下文策略、模型选择、是否流式、是否调用工具、是否排队、是否缓存，都会改变最终成本和用户等待时间。很多团队上线前只看单次模型价格，上线后才发现真正昂贵的是长上下文、重复重试、工具等待、无效生成和高峰期排队。

成本与性能的目标不是把每次调用都压到最低价，而是在业务体验、质量、风险和预算之间做可解释的取舍：

• 哪些 token 是必要上下文，哪些只是“看起来更保险”？
• 用户在什么环节真的需要低延迟，什么环节可以异步？
• 用更贵模型带来的质量收益，是否覆盖成本和等待时间？
• 系统吞吐瓶颈来自模型、工具、数据库、队列，还是前端交互？
• 高峰期应该限流、排队、降级，还是切换模型？
• 什么时候简单 prompt 裁剪就够，什么时候需要完整 infra？

这篇总览先按典型场景拆解 token 成本、延迟、吞吐和模型价格，再给出从简单到复杂的优化阶梯。核心观点很直接：先证明成本或延迟真的来自哪里，再决定优化方案。

#场景

先看一个具体场景。

在 B2B SaaS 客服后台，客服每天用 AI 助手处理用户工单。用户提交的问题可能只有一句话，也可能包含截图说明、历史对话、订单信息和内部知识库引用。系统希望 AI 完成三件事：

• 判断问题类型和紧急程度。
• 检索相关知识和客户状态。
• 生成一段客服可编辑的回复草稿。

使用规模从试点阶段的每天 300 次请求，增长到线上高峰每分钟 120 次请求。客服希望 2 秒内看到首字，10 秒内得到可编辑草稿。业务方希望每月模型成本可预测，不能因为几个长工单或频繁重试突然翻倍。

没有 AI 时，客服平均 6 分钟处理一条复杂工单；有 AI 后，如果草稿质量稳定，每条可以节省 2 到 4 分钟。但如果系统为了“更准确”把完整历史、所有知识片段和客户画像都塞进 prompt，单次成本会明显上升，延迟也会拖慢客服操作。

这个场景里的成本性能问题来自多处：

• token 成本：历史消息、知识库片段、工具结果、模型输出都在计费。
• 延迟：上下文检索、模型 TTFT、工具调用、流式传输、队列等待都会增加等待。
• 吞吐：高峰期并发请求、供应商限流、服务端连接数和工具 QPS 都会形成瓶颈。
• 模型价格：不同模型的输入、输出、缓存命中、长上下文和工具能力价格不同。

如果只看“每百万 token 多少钱”，会漏掉更关键的问题：这些 token 是否必要，用户是否需要同步等待，昂贵模型是否只用在真正需要的任务上。

#问题类型

成本与性能问题可以拆成四类。

这些问题对应的 AI 任务类型不同。

模型不应该负责判断“这次调用花多少钱是否值得”。成本归因、预算、限流、缓存、路由和降级都应该由系统控制。

#收益和成本判断

优化成本与性能的收益包括：

• 降低单位任务成本，让 AI 能覆盖更多业务量。
• 缩短等待时间，让 AI 嵌入核心工作流而不是成为阻塞点。
• 提高高峰期成功率，减少排队、限流和超时。
• 把昂贵模型用在高价值任务上，避免默认过度配置。
• 让账单、延迟和质量有数据可解释，便于持续迭代。

但优化也有成本：

• prompt 裁剪可能降低答案质量或遗漏关键上下文。
• 缓存需要失效策略、权限隔离和命中率评估。
• 模型路由会增加评估、回归和一致性成本。
• 队列、异步任务和限流会增加系统复杂度。
• 本地模型需要部署、显存、运维和质量兜底。
• 过度优化会让系统难以调试，质量问题更隐蔽。

可以用四个问题判断是否值得优化：

低风险、低并发、内部使用的功能，通常先做输入裁剪、输出长度限制、流式返回和基础日志。生产级客服、销售、代码、数据分析或自动化场景，才需要更完整的成本归因、路由、队列和 fallback。

#方案阶梯

成本与性能优化应该从可观测和低风险动作开始。

第一层是记录成本和延迟。至少要知道每次请求的输入 token、输出 token、模型、TTFT、完整耗时、工具耗时、重试次数和用户场景。

第二层是裁剪输入输出。控制历史轮数、知识片段数量、工具结果长度和输出 token 上限。很多成本问题到这一层就能缓解。

第三层是缓存。对稳定系统提示词、检索结果、工具查询、分类结果和重复草稿做缓存，但要处理权限和过期。

第四层是模型路由。把分类、抽取、改写交给小模型或便宜模型，把高风险推理、复杂生成和最终判断交给强模型。

第五层是 streaming 和超时。TTFT 影响用户感知，完整耗时影响任务完成。两者要分开优化。

第六层是队列和并发控制。高峰期不要让所有请求一起打到模型和工具。排队、优先级和限流比盲目扩容更可控。

第七层是 fallback。供应商失败、模型慢、工具超时、上下文过长时，要有降级模型、部分结果、异步处理或人工接管。

第八层是本地或专用模型。只有当调用量、任务稳定性和质量要求足以覆盖运维成本时，才考虑本地模型。

第九层是 Eval + Ops。每次降本和加速都要通过评估集、线上指标和人工反馈验证，避免用更便宜更快换来不可见的质量下降。

#什么时候简单优化足够

以下情况通常先做简单优化：

• 功能还在试点期，每天调用量不大。
• 输出只是草稿，用户会编辑。
• 成本主要来自少数过长输入。
• 延迟主要来自模型生成本身，而不是复杂工具链。
• 高峰并发不高，偶发失败可以手动重试。
• 任务类型固定，不需要自动模型路由。

这时可以先做：token 日志、上下文预算、输出长度限制、流式返回、少量缓存、基础超时和手动降级。

#什么时候需要 infra 方案

以下情况应该升级到工程化方案：

• 月度模型成本已经影响产品毛利或预算。
• 高峰期出现排队、限流、超时或供应商错误。
• 同一产品里有多种任务，质量和价格差异明显。
• 工具调用慢，且用户不应该同步等待全部结果。
• 多租户场景需要按客户、功能或团队做成本归因。
• 需要在主模型不可用时继续服务。
• 本地模型或专用模型的长期成本可能低于 API 调用。

这时要把成本和性能当成产品基础设施：有预算、指标、路由、队列、fallback、告警和评估，而不是靠某个 prompt 参数控制。

#方案选型表

#反模式

第一种反模式：只看模型单价，不看完整链路成本。

一次请求的真实成本包括输入 token、输出 token、缓存命中、检索、工具、重试、排队和人工兜底。便宜模型如果导致更多重试或人工修正，可能并不便宜。

第二种反模式：把所有上下文都塞进去换“稳”。

长上下文会增加成本和延迟，也会让模型被无关信息干扰。上下文管理的目标是够用、可信、可追踪，不是越多越好。

第三种反模式：所有任务默认大模型。

分类、抽取、格式转换、短文本改写通常可以由更便宜的模型处理。大模型应该留给复杂推理、高风险生成和最终判断。

第四种反模式：用无限重试提升成功率。

重试会放大成本和延迟，也可能重复执行工具。重试必须基于错误类型、幂等和预算。

第五种反模式：只优化完整耗时，不看 TTFT。

用户对“完全没反应”的等待更敏感。很多交互场景里，流式首字和明确状态比压缩最后 1 秒总耗时更重要。

第六种反模式：缓存不做权限和失效。

多租户产品里，缓存命中如果没有租户、角色、数据版本和权限维度，可能带来越权和过期答案。

第七种反模式：没有成本归因。

只知道总账单上涨，不知道是哪个功能、客户、模型、prompt 版本或工具链造成的，就无法做有效优化。

#工程清单

• 场景边界：哪些功能需要低延迟，哪些可以异步或批处理。
• 成本归因：是否记录用户、租户、功能、模型、输入 token、输出 token 和重试。
• 延迟指标：是否区分 TTFT、完整耗时、排队耗时、工具耗时和网络耗时。
• token 预算：历史消息、检索片段、工具结果和输出长度是否有上限。
• 模型路由：不同任务、风险和用户等级是否有模型选择规则。
• 缓存策略：缓存键、权限、过期、命中率和回源策略是否明确。
• 队列策略：高峰期是否有优先级、限流、并发控制和用户可见状态。
• fallback：模型、供应商、工具和上下文失败时是否有降级路径。
• 质量评估：降本或加速后是否用评估集验证质量没有不可接受下降。
• 预算告警：是否有日预算、月预算、异常请求和单租户成本告警。
• 安全合规：日志和缓存是否脱敏，是否避免敏感上下文长期保存。
• 回放复盘：是否能按一次请求重建成本、延迟、路由、工具和错误链路。

#小结

成本与性能优化不是单独调一个模型参数，而是围绕“每次 AI 请求到底花在哪里、慢在哪里、值不值得”建立判断框架。

低风险早期功能，可以先做 token 日志、上下文裁剪、输出限制和 streaming。只要进入高并发、多租户、工具调用、模型路由或成本预算约束，就需要把成本、延迟、吞吐和质量放进同一个可观测系统里治理。

这个专题的后两篇会继续展开：

• 如何用裁剪、缓存、模型路由、小模型和本地模型做成本优化。
• 如何围绕 TTFT、streaming、队列、工具延迟和 fallback 做延迟优化。