大模型推理成本治理：从1000次调用到100次，一次可复用的降本实践

一个内部知识问答系统的成本治理全过程：月账单 4,832 元 → 461 元，降幅 90.5%，功能零削减，用户无感知。

一、问题背景

去年下半年，我们给公司内部搭了一个知识问答系统，接的是旗舰级大模型。上线三个月，日活稳定在 200 人左右，日均调用量 1,000 次上下。

从业务指标看，这个系统是成功的——问题解决率 82%，用户满意度 4.3/5。

但从成本看，它有点失控。

月度 API 账单 4,832 元。对一个日活 200 的内部工具来说，这个数字不算离谱，但也谈不上合理。更要命的是，随着接入场景增加，调用量在爬坡，账单也在爬坡，而我们对"钱花在哪"几乎一无所知。

于是我们做了一轮成本治理。这篇文章是完整记录，包括方法论、具体手段、量化结果和踩过的坑。

先给结论：

问题解决率掉了 1 个百分点，是唯一的质量代价。响应时间反而大幅改善——这是流式输出带来的副产品。

二、先量化：钱到底花在哪

成本治理最容易犯的错，是凭直觉动手。

"模型太贵了，换个便宜的"——这是最常见的直觉，也是最容易出事的直觉。我们第一轮就吃过这个亏，后面会讲。

2.1 埋点

在网关层统一埋点，记录每次调用的：模型、输入 token、输出 token、场景标签、耗时、用户 ID。

这一步的关键是场景标签。没有场景标签，你只能看到"总成本"，看不到"哪个业务在烧钱"。

2.2 按上下文长度归因

4% 的请求吃掉了 36% 的成本。 这是典型的帕累托分布，也是治理的切入点。

2.3 按场景归因

2.4 按调用必要性归因（这一步最有价值）

这一项最费劲，但也最有价值。我们人工抽样了 500 条调用，标注"这次调用是否必要"，结果是：

也就是说，38% 的调用压根不该发出去。这部分不涉及任何模型能力取舍，纯粹是工程问题。

这个发现直接改变了我们的治理顺序——先消灭无效调用，再谈模型优化。

三、治理顺序：先零风险，再需评估

基于归因结果，我们把治理手段分成三类：

治理顺序建议：零风险 → 低风险 → 需评估。 先把容易拿的分拿到，再动需要评估的部分。

四、五项治理手段详解

4.1 第一层：消灭无效调用（降 26%）

这一层收益最大、风险最低，应该最先做。

前端防抖与请求去重。 用户快速点击按钮会触发多次请求。我们在前端加了 300ms 防抖，后端加了基于 user_id + prompt_hash 的 5 秒幂等窗口，重复请求直接返回上一次的结果。

超时与重试策略。 之前超时设 10 秒，超时后自动重试两次。实际 P95 延迟 4.2 秒，10 秒超时基本不会触发，但一旦触发就是三次调用。改成超时 8 秒、重试一次，并且重试前先查缓存。

参数校验前置。 有 7% 的无效调用是参数错误导致的（空 prompt、超长 prompt、非法 model 名）。在网关层加校验，不合格的直接拒绝，不进模型调用。

这一层做完，调用量降了 26%。

4.2 第二层：语义缓存（降 33%）

问题：34% 的请求语义重复，但每次都重新调模型。

方案：在网关层加语义缓存。请求进来先做 embedding，在向量库中检索，相似度超过阈值直接返回。

用户请求
   ↓
[Embedding 服务] → 向量
   ↓
[向量检索] ──命中──→ 返回缓存答案
   ↓ 未命中
[模型路由] → [大模型调用] → 写回缓存 → 返回

关键参数：

效果：命中率 34%，日均调用 1,000 → 660，成本 161 → 108 元。

风险提示：TTL 必须按内容类型分级。我们早期没设 TTL，公司改了报销制度后缓存仍在返回旧答案，造成了实际业务影响。

4.3 第三层：模型分级（降 52%）

问题：所有请求一律走旗舰模型，包括"今天几号"这种。

方案：三层分级 + 规则优先的路由。

路由策略：

1. 敏感场景白名单（金额/法务/医疗/合同）→ 强制 L3
2. 上下文 > 8K → 强制 L3
3. 短问题 + 事实型关键词 → L1
4. 其余 → 小模型意图分类 → L1/L2/L3

一个关键设计决策：路由本身不能太贵。我们最初用旗舰模型做意图分类，结果路由成本比回答成本还高。改成规则优先 + 轻量模型兜底后，规则层覆盖了 55% 的请求。

规则顺序的坑：规则匹配是按顺序的，先匹配到的赢。我们一开始把 entity_extract 排在 code_generation 前面，结果"提取订单号并生成一个 JSON"被判成实体抽取走轻量模型，输出的 JSON 少了一层嵌套，前端直接报错。改成复合任务优先之后，差异率从 2% 降到 0.8%。

效果：L1 占比 48%，L2 占 37%，L3 占 15%，成本 108 → 52 元。

质量兜底：

• 每天随机抽检 50 条 L1/L2 回答
• 建立"降级失败"标签库，发现质量问题立即提升该场景层级
• 敏感场景不参与路由

4.4 第四层：Prompt 精简（降 35%）

问题：system prompt 1,240 token，每次调用都带，日均消耗 124 万 token。

拆解：

核心认知：模型不是靠形容词变聪明的。"专业、严谨、有耐心"这类描述对输出质量的影响，在我们的 A/B 测试中不显著（p > 0.1）。

效果：成本 52 → 34 元。这是投入产出比最高的一项——半天工作量，永久生效。

一条红线：涉及"不能做什么"的指令一个字不能删。我们删过一条"不得提供医疗诊断建议"，测试环境跑了两天没事，上线第三天有用户问"我最近头疼，你们这个软件能不能帮我记录症状"，模型真的开始给建议了，还说"建议服用布洛芬"。现在所有否定式指令不但保留，还移到 prompt 最前面。

回归测试：精简后必须跑回归用例。我们砍掉 few-shot 后，多轮对话的指代消解能力下降，补一条规则后恢复。

4.5 第五层：批处理 + 流式（降 29%）

批处理：一个任务调多次模型的场景，合并为单次调用 + 结构化输出。

效果：单份文档 token 消耗 12,000 → 3,400，降 72%。

边界：单次批处理任务数不超过 20 个。超过后模型开始漏内容。超过则分批，并做好单条降级。

判断能不能批，标准不是"是不是异步"，是"结果晚 24 小时出来，业务能不能接受"。 我们有个功能是用户上传文档后生成摘要，一开始判断这是异步任务走了批处理，但用户上传完就在页面上等着，24 小时内出结果等于不可用。后来改回实时了。

流式输出：

• 改 SSE 流式返回，首字延迟 0.8 秒
• 监听连接状态，断开即终止生成
• 按问题类型设置 max_tokens：事实型 100，分析型 800，代码 2000
• prompt 中明确长度约束

效果：平均输出 token 620 → 210，用户中途放弃率 23% → 6%，成本 34 → 15.4 元。

五、治理效果汇总

六、治理机制：怎么防止反弹

优化做完不是终点。我们见过太多团队，优化完三个月又涨回去了。

我们建了三个机制：

成本看板。 每天自动生成成本日报，按任务类型、模型、业务线三个维度拆分，异常波动自动告警。阈值设的是日环比超过 20% 就报警。

成本归因。 每个调用都打上 business_line、feature、task_type 三个标签。出问题时能定位到具体功能，而不是笼统地说"模型太贵"。

变更评审。 新增模型调用点必须走评审，说明为什么需要、用哪个模型、预估调用量。这一条挡住过好几次"随手加个 AI 功能"的需求。

七、踩过的坑

坑一：一刀切降级导致质量事故

第一轮治理时，我们把所有请求都往轻量模型上赶，包括合同条款风险识别。结果轻量模型漏掉了两个关键条款，法务部门直接找上门。

教训：敏感场景必须白名单保护。涉及金额、法务、医疗、合规的请求，无条件走旗舰模型，这部分成本不能省。

坑二：路由本身成为成本项

用旗舰模型做意图分类，再路由到轻量模型回答——路由成本比回答成本还高。

教训：路由要用最便宜的手段。规则优先，规则拦不住的再用轻量模型。

坑三：缓存没有失效机制

制度变更后缓存仍返回旧答案，造成实际业务影响。

教训：TTL 必须按内容类型分级，动态数据宁可短一点。

坑四：只做一次性优化

第一轮优化完成后，我们以为万事大吉。三个月后发现有个接口被前端轮询调用，日均 8,000 次，纯属 bug。

教训：成本治理需要持续机制，不是一次性项目。

坑五：两个没做成的尝试

把 temperature 调到 0 提升缓存命中率。 理论上同样输入必然同样输出。实际跑下来回答变得很死板，用户投诉变多，又调回 0.3 了。命中率只从 34% 涨到 37%，收益远不如预期。

自建 7B 小模型替代意图分类。 准确率比 mini 低 6 个点，加上 GPU 和运维成本，算总账不划算，放弃了。API 的规模效应不是自建能比的。

八、可复用的治理框架

8.1 治理检查清单

【量化阶段】
□ 网关层埋点，记录模型/token/场景/耗时
□ 按上下文长度、场景、模型三个维度做成本归因
□ 人工抽样标注"调用是否必要"
□ 统计语义重复率
【治理阶段 - 零风险】
□ 前端防抖 + 后端幂等窗口
□ 超时重试策略优化
□ 参数校验前置
□ 审查 system prompt，删除形容词和冗余格式说明
□ 格式约束改用 API 参数
□ 设置 max_tokens，按类型分级
【治理阶段 - 低风险】
□ 上线语义缓存，阈值按自己数据标定
□ TTL 按内容类型分级
□ 改流式输出，确保断开即终止
【治理阶段 - 需评估】
□ 划分 L1/L2/L3 三层
□ 敏感场景白名单
□ 规则优先的路由策略，复合任务优先匹配
□ 批处理合并，单次不超 20 个任务
□ 建立质量抽检机制
【机制建设】
□ 成本日报与告警
□ 成本归因标签体系
□ 新场景上线前的成本预估评审

8.2 优先级建议

如果资源有限，按这个顺序做：

1. Prompt 精简（半天，降 35%，零风险）
2. 消灭无效调用（2 天，降 26%，零风险）
3. 语义缓存（2-3 天，降 33%，低风险）
4. 模型分级（1 周，叠加降 52%，需质量兜底）
5. 流式截断（2 天，降 29%，有 C 端必做）
6. 批处理（3-5 天，局部降 72%，看场景）

8.3 质量守则

三条底线不能破：

1. 敏感场景（金额/法务/医疗/合规）不参与降级
2. 每次降级改动必须跑回归测试
3. 建立降级失败标签库，持续迭代

九、写在最后

省下 4,371 元/月当然好，但真正的收获是另一件事：我们终于能看见成本了。

在此之前，AI 成本对我们是个黑盒——只知道总数，不知道结构。现在每周一早上看一次报表，哪个场景在涨、哪个模型在浪费，一目了然。这种"看得见"的感觉，比省下来的钱更值钱。

技术手段其实是次要的。先量化、再治理、建机制，顺序别搞反就行。

如果你也在做类似的治理，欢迎交流。

本文数据来自笔者所在团队内部系统的真实治理记录，模型名称与厂商做了脱敏处理，成本按公开定价折算。不同厂商定价策略差异较大，具体数值请以自身账单为准。