大模型应用如何做成本控制？

简化版

大模型成本控制不能只看 Token 单价，应看“每次成功任务成本”。完整成本包括输入/输出 Token、重试、多模型调用、检索与重排、工具、GPU 空闲、人工审核及失败返工。

做法是先按租户、场景、模型和版本建立成本账本，再从减少无效调用、压缩上下文、限制输出、缓存、模型路由、批处理和容量规划逐层优化。所有节省措施必须同时回归质量、P95/P99 延迟与安全，避免便宜但失败率更高。

详细版

先计算基线：

cost_per_success = total_model_and_system_cost / successful_tasks

然后拆出成本驱动项：输入 Token、输出 Token、平均调用轮数、失败重试率、缓存命中、模型分布和人工接管率。优先删除没有业务价值的重复上下文与无界 Agent 循环，再做小模型路由、语义/前缀缓存和推理量化。

手段	主要收益	主要风险
Prompt/RAG 压缩	降低输入成本	丢失关键证据
输出预算	降低生成成本	答案被截断
模型路由	简单任务用小模型	错误路由损害质量
缓存	避免重复计算	过期、权限和隐私
Batch/量化	降低自部署单位成本	延迟或精度变化

预算要有事前配额、运行时硬上限和事后归因；上线用固定评测集和 A/B 比较“成本—质量—延迟”Pareto，而不是只报告总账下降。

完整版教学

一、成本口径为什么先于优化

API 账单只是显性成本。一次回答还可能包含 Embedding、向量检索、重排、审核、工具调用、重试和人工接管；自部署还包括 GPU、空闲容量、网络和运维。

若只优化模型单价，可能把工作转移到更多调用或人工环节。应先定义任务成功和端到端核算范围。

二、每次成功任务成本怎么算

total_cost = model + retrieval + tools + infrastructure
           + retries + human_review
cost_per_success = total_cost / successful_tasks

例如便宜模型单次成本降低 40%，但任务成功率从 90% 降到 55%，重试后未必更省。分母必须是业务成功，不是 HTTP 200。

三、建立可归因的成本账本

每次调用记录租户、场景、模型版本、Prompt 版本、输入/输出 Token、缓存命中、调用轮数、延迟和结果状态。单价使用带生效时间的版本表，避免价格变更后历史账单漂移。

对自部署模型，可按 GPU 秒、显存占用或 Token 分摊固定成本，但方法需一致并能解释。成本标签禁止直接包含用户敏感文本。

四、先消灭无效调用

常见浪费包括客户端超时后模型仍在生成、Agent 无界循环、解析失败无限重试、相同请求重复提交和已无证据仍继续调用。

设置 Deadline、取消传播、幂等键、最大步骤和重试预算，通常比换便宜模型风险更低。每次重试要记录原因，避免把确定性错误当瞬时故障反复执行。

五、输入 Token 如何优化

System Prompt 去重，历史对话按任务摘要，RAG 对文档去重并动态选择 TopK，Few-shot 只保留对当前任务有贡献的示例。

压缩后必须验证证据召回和指令遵循。简单按字符截断可能删掉权限、安全规则或答案依据，属于错误节省。

六、输出 Token 如何控制

明确输出 Schema、长度要求和停止条件，按场景设置 max tokens。分类、抽取类任务不应默认生成长解释，创作任务则不能用同一短预算。

流式服务在客户端断开后立即取消生成；否则无人消费的 Token 仍产生费用。截断率和 finish reason 应进入监控。

七、模型路由如何降成本

简单、高置信任务路由到小模型，复杂、低置信或高风险任务使用强模型。路由器可结合任务类型、输入长度、风险等级和小模型置信度。

expected_cost = route_cost
              + model_cost
              + fallback_probability × fallback_cost

必须把误路由与二次升级成本算入，而不是只统计首选模型价格。

八、缓存什么时候有效

精确缓存适合确定性、重复请求；语义缓存适合答案容忍同义问题的场景；前缀缓存降低共享长前缀的 Prefill 成本。

缓存键绑定模型、Prompt、知识库、权限和策略版本，并设置 TTL/主动失效。个性化、高时效或高风险回答不能仅凭相似度复用。

九、自部署如何提高资源效率

连续批处理、量化、KV 分页和合适卡型可降低单位 Token 成本。低流量模型可安全共置或缩容，高流量模型根据 SLO 曲线选择副本数。

GPU-Util 高不等于经济性高。应比较在相同质量与 P99 下的每百万有效 Token 或每成功任务成本。

十、配额与预算如何分层

租户级设置日/月预算和 Token 速率，场景级设置单请求 Token、调用次数和工具费用，平台级设置总预算与异常熔断。

控制阶段	机制	作用
事前	配额、成本预估	阻止明显超预算任务
运行时	Token/步骤/Deadline	防止单次失控
事后	归因、告警、复盘	修正策略与预算

达到软阈值可告警或降级，硬阈值才拒绝；高风险业务不能为省钱绕过安全校验。

十一、异常成本怎样发现

监控每请求 Token、调用轮数、缓存未命中、重试、模型分布和单位成功成本的分位数。按租户和版本比较，识别 Prompt 发布或流量变化造成的突增。

告警要基于相对基线和绝对预算双阈值。新业务自然增长不应与单请求泄漏混为一谈。

十二、如何做优化实验

固定线上回放与质量评测，分别比较总成本、成功率、TTFT/P99、安全和人工接管。只改变一个主要变量，例如模型路由阈值或 RAG TopK。

对新策略做小流量灰度，设质量下降和成本反弹回滚线。节省比例应在相同任务分布下计算，避免样本变简单造成假收益。

成本优化的目标不是让一次调用最便宜，而是用最低可持续成本交付一次合格结果。

十三、常见误区与追问

误区：换最便宜模型就是成本优化。 成功率下降会增加重试和人工成本。
误区：Token 单价就是总成本。 检索、工具、基础设施和失败返工也要计入。
误区：上下文越短越省且无副作用。 关键证据和安全规则可能被删。
误区：缓存命中越高越好。 过期或越权命中会制造质量与安全事故。
误区：GPU 利用率越高单位成本越低。 尾延迟和失败率可能同步恶化。
追问：先优化哪里？ 优先取消无效调用和重复 Token，再评估模型路由与基础设施。
追问：如何证明真的省钱？ 在同一质量和延迟约束下比较每成功任务成本。

十四、加强记忆

先定口径：端到端总成本除以成功任务；再做归因：租户、场景、模型、版本、Token 和重试；再删浪费：取消、幂等、步骤与重试上限；再省 Token：压输入、控输出，但回归质量。再做路由缓存：算上误路由、升级与失效风险；再提资源效率：Batch、量化、容量和卡型；最后用 Pareto 验收：成本、质量、延迟、安全一起看。

项目实战落地

项目里怎么做的

《AI Agent智能会议纪要辅助系统》的运行观测页把 ai_call_log 当成本账本，先把每条日志里的用量读准，再按几个维度汇总：

用量从哪来。 文本模型调用把 LangChain 返回消息的 usage_metadata 存进 usage_json，转写把百炼录音识别结果里的用量原样存进去；失败的调用 usage_json 为空。
两套字段名都认。 读用量时兼容两种写法，缺总量时用输入加输出补上：

# LangChain 的 usage_metadata 用 input_tokens，另一种写法是 prompt_tokens；失败的调用按 0 算
input_tokens = int(usage.get("input_tokens") or usage.get("prompt_tokens") or 0)
output_tokens = int(usage.get("output_tokens") or usage.get("completion_tokens") or 0)
total_tokens = int(usage.get("total_tokens") or input_tokens + output_tokens)

一次循环按四个维度累计。 全部日志的输入、输出、总 Token；按天（先给日期范围内每一天放一个零值，没有调用的日子在趋势图上也显示）；按调用类型（转写、纪要分段、纪要合并、自检审查、自检重写、说话人匹配）；按模型配置主键（两条配置用同一个模型名也分开统计）。每天记调用量、失败量和 Token；调用类型和模型配置两组还算成功率和平均耗时。
日期按东八区归档。 建每日键和读日志时间都过同一个 to_local，两边口径一致。

《AI面试官与刷题训练平台》的做法更直接：AI 调用日志页的列表和统计接口共用同一段筛选条件（服务商、模型名、调用场景、调用状态），统计 SQL 返回总调用次数、成功数、失败数、平均耗时和总 Token，页面顶部五张卡片随筛选条件变化。

《AI Agent智能教务排课与教学质量分析系统》的 AI 调用日志页用一条统计 SQL 算出总调用次数、成功数、失败数、平均耗时和总 Token；运行日志与调用观测页再把 AI 调用总数和 Token 消耗做成指标卡片，配上 AI 调用状态分布和最近 AI 调用记录。工具调用也记在这张表里，但不带 Token，总 Token 只来自模型调用。

为什么这样取舍

先有账本，再谈省钱。 成本控制的第一步是知道钱花在哪个场景、哪个模型上；调用类型和模型配置两个分组，正好回答「哪类调用最费 Token」「哪条配置最慢、失败最多」。
按配置主键而不是模型名分组。 两条配置可能填的是同一个模型名，合在一起就分不清是哪条配置的问题。
失败调用也进账。 失败的调用 Token 记 0，但次数和耗时照样累计，失败率和平均耗时才是真实的。

面试官还会追问

运行观测页的「模型」下拉框，选项是从哪里来的？选中某个模型再查询之后，下拉框里的选项会不会跟着变少？
页面上的「Agent 成功率」和「产生修订稿」两张卡片，分别按自检运行表的哪个字段统计？

学完《AI Agent智能会议纪要辅助系统》，上面这些追问你都会迎刃而解。

简化版

详细版