#成本优化方案阶梯

AI 成本优化最容易走偏的地方，是一上来就讨论“换便宜模型”。

模型单价当然重要，但真实账单往往来自更隐蔽的地方：过长历史、无关知识片段、冗长输出、重复重试、工具结果原样塞入 prompt、低价值任务使用大模型、缓存缺失，以及没有按场景做成本归因。

成本优化不是单纯省钱。它要回答一个工程问题：在哪些请求上降低成本不会破坏业务质量，在哪些请求上必须保留昂贵能力。

#场景

假设一个面向企业客户的销售助手，每天帮助销售生成跟进邮件、会议纪要、客户风险摘要和下一步行动建议。

输入来自多个地方：

• CRM 里的客户阶段、合同金额、最近沟通记录。
• 邮件和会议转写文本。
• 销售手动输入的目标和语气要求。
• 产品资料、报价规则和合规说明。

输出会被销售人员编辑后发给客户，部分摘要会写回 CRM。调用量在月末和季度末明显上升，大客户团队使用频率更高。上线初期团队默认使用强模型，并把最近 20 条沟通记录、完整会议转写和相关产品文档都放进上下文。

问题很快出现：

• 会议纪要和邮件草稿的 token 成本差异很大，但账单里看不出来源。
• 很多短邮件改写也走强模型，单位成本偏高。
• 同一客户资料在一天内被多次读取和重复注入 prompt。
• 销售频繁点“重新生成”，重复消耗输出 token。
• 为了避免漏信息，系统带入大量旧沟通记录，质量没有明显提升。

这个场景里，成本优化不能只换模型。需要先知道钱花在什么任务、什么客户、什么上下文和什么输出上。

#问题类型

成本问题通常不是一种问题，而是一组任务和链路叠加。

对应的 AI 任务也要分层。

模型适合处理语言理解和表达。成本预算、缓存、路由、限额和归因应该由系统处理。

#收益和成本判断

成本优化的收益包括：

• 降低单位任务成本，让功能能覆盖更多用户。
• 让不同租户、团队和功能的成本可解释。
• 把昂贵模型留给真正需要的复杂任务。
• 通过缓存减少重复 token 和工具调用。
• 减少重试、冗长输出和无效生成。

但每种优化都有成本：

• 裁剪上下文可能漏掉重要事实。
• 摘要压缩可能引入失真或丢失细节。
• 缓存可能返回过期、越权或不适用结果。
• 模型路由可能造成质量不一致。
• 小模型可能需要更多 prompt 约束和校验。
• 本地模型会引入部署、显存、监控和兜底成本。

判断收益是否值得，可以先看三组指标：

如果一个优化能节省 30% 成本，但导致人工修改时间增加 1 分钟，未必划算。成本优化要和人工时间、用户体验、错误成本一起算。

#方案阶梯

成本优化可以从轻到重分为五层。

#裁剪

裁剪是最先做的成本优化，因为它直接、低风险、容易回滚。

可裁剪的内容包括：

• 历史消息：只保留当前任务相关轮次，旧内容用摘要或结构化状态替代。
• 检索片段：限制数量、长度和相似度阈值，只带能支撑答案的证据。
• 工具结果：返回给模型前做字段白名单和摘要，不把完整 JSON 原样塞入。
• 系统提示词：去掉重复说明，把稳定规则抽成短句和结构化约束。
• 输出长度：明确字数、格式、列表项数量和停止条件。

裁剪的成本是可能漏信息，所以要配套观察质量变化。对于高风险判断，不要仅靠裁剪省钱；应优先提高上下文选择质量。

#缓存

缓存适合稳定、重复、可判定失效的内容。

常见缓存对象：

缓存不是简单的 key-value。多租户产品至少要把租户、用户权限、数据版本、prompt 版本、模型版本和语言等因素纳入缓存键或失效策略。

#模型路由

模型路由的目标是把任务分配给足够好的模型，而不是默认最强模型。

常见路由规则：

• 简单分类、抽取、短文本改写走小模型。
• 复杂推理、高风险判断、长文生成走强模型。
• 低价值或免费用户请求使用便宜模型和更短上下文。
• 高价值客户、敏感任务或低置信度结果升级强模型。
• 主模型失败或限流时进入 fallback 模型或人工队列。

路由必须有评估集。否则“看起来便宜”可能只是把错误推迟到人工修正阶段。

#小模型

小模型适合稳定、边界清晰、输出可校验的任务。

适合小模型：

• 意图分类。
• 字段抽取。
• 简单摘要。
• 翻译和格式转换。
• prompt 前的输入清洗。
• 大模型调用前的上下文筛选。

不适合小模型直接承担：

• 高风险业务判断。
• 多约束复杂推理。
• 需要强事实一致性的专业答案。
• 无法用规则或 schema 校验的开放生成。

小模型常见用法不是替代强模型，而是做前置过滤、压缩、分类和低风险分流。

#本地模型

本地模型适合稳定高频任务，或者有数据控制、低延迟、供应商独立性的要求。

适合考虑本地模型的条件：

• 调用量足够大，API 成本已经明显高于部署和运维成本。
• 任务边界稳定，评估集成熟。
• 输出格式可校验，风险可控。
• 团队有模型部署、监控、扩容和安全能力。
• 需要数据不出私有环境，或需要离线可用。

不适合一开始就本地化：

• 产品还在验证期，任务经常变化。
• 质量要求高但缺少评估集。
• 团队没有 GPU 运维能力。
• 只是为了“省 token 钱”，却忽略人力和硬件成本。

本地模型也需要 fallback。它可以承担一部分高频任务，但不应该成为没有质量兜底的单点。

#什么时候简单优化足够

以下情况通常不需要复杂 infra：

• 调用量还小，月度成本可接受。
• 成本主要来自明显过长的历史或输出。
• 用户会人工复核，轻微质量波动可接受。
• 任务类型单一，不需要动态路由。
• 没有多租户成本归因要求。
• 高峰期没有明显限流或预算风险。

这时优先做：记录 token、限制输出、裁剪上下文、缓存稳定工具结果、把简单分类从强模型拆出来。

#什么时候需要 infra 方案

以下情况需要工程化成本体系：

• 账单已经无法按功能、客户、团队或模型解释。
• 免费、试用、企业客户需要不同成本预算。
• 同一产品包含分类、抽取、生成、判断、工具调用等多种任务。
• 高峰期重试和 fallback 会放大成本。
• 需要自动选择模型、自动降级或自动限额。
• 要评估小模型、本地模型或私有部署的长期收益。

这时应建设成本归因、预算控制、模型路由、缓存治理、评估回归和告警，而不是只在 prompt 里写“请简短回答”。

#方案选型表

#反模式

第一种反模式：没有成本归因就开始优化。

如果不知道成本来自哪个功能、租户、prompt 版本、模型和 token 构成，就只能凭感觉优化。结果常常是改了低成本链路，真正高成本链路还在增长。

第二种反模式：只换便宜模型。

便宜模型可能需要更长 prompt、更多重试、更多人工修正。总成本要看任务完成成本，而不是单次调用单价。

第三种反模式：裁剪上下文没有评估。

裁剪能快速省钱，但也可能把关键证据删掉。至少要在典型样本和失败样本上比较采纳率、错误率和人工修改量。

第四种反模式：缓存不带权限和版本。

缓存命中如果跨租户、跨权限或跨文档版本，就可能返回越权或过期内容。成本优化不能牺牲安全边界。

第五种反模式：让小模型承担不可校验的高风险判断。

小模型适合低风险、可校验、边界稳定的任务。把合同风险、医疗建议、财务判断直接交给小模型，是把成本问题转成责任问题。

第六种反模式：本地模型只算 GPU，不算人力。

本地模型的成本包括部署、扩容、升级、安全、监控、评估和事故处理。没有稳定规模和团队能力时，本地化可能更贵。

#工程清单

• 场景边界：哪些任务是分类、抽取、改写、摘要、生成或判断。
• 成本归因：是否记录功能、租户、用户、模型、prompt 版本、输入输出 token。
• token 预算：历史、检索、工具结果和输出是否分别有预算。
• 裁剪策略：被裁剪内容是否有摘要、引用或可回查来源。
• 缓存策略：缓存键是否包含权限、数据版本、prompt 版本和模型版本。
• 模型路由：路由规则是否按任务、风险、置信度和用户等级设计。
• 小模型验证：是否有评估集、schema 校验、升级强模型和人工兜底。
• 本地模型评估：是否比较 API 成本、硬件、人力、质量和可用性。
• 重试预算：重试是否限制次数、错误类型和总成本。
• 预算告警：是否有单请求、单用户、单租户、单功能和总预算告警。
• 质量回归：每次降本是否验证采纳率、错误率、人工修改量和投诉。
• 审计复盘：是否能回放一次请求的上下文、路由、缓存命中和成本构成。

#小结

成本优化的第一步不是换模型，而是看清楚钱花在哪里。

裁剪、缓存、模型路由、小模型和本地模型是一条逐级加重的方案阶梯。早期功能通常先用裁剪和缓存就能获得明显收益；当调用规模、任务类型和预算约束变复杂时，才需要模型路由、小模型体系和本地模型评估。

真正可靠的成本优化，不是把每次调用压到最低，而是让每一分钱都花在能产生业务质量的地方。