大模型账单翻了三倍，成本怎么归因、怎么压？

-- 成本拆解：按周对比，看增长来自哪个因子
SELECT scenario,
       DATE_TRUNC('week', event_time)            AS wk,
       COUNT(DISTINCT turn_id)                   AS turns,         -- 用量
       COUNT(*) * 1.0 / COUNT(DISTINCT turn_id)  AS calls_per_turn,-- 每次提问的调用数（步数）
       AVG(input_tokens)                         AS avg_input,     -- 上下文长度
       AVG(output_tokens)                        AS avg_output,
       SUM(cached_tokens) * 1.0 / SUM(input_tokens) AS cache_ratio,-- 缓存命中率
       SUM(CASE WHEN is_retry = 1 THEN cost_amount END) / SUM(cost_amount) AS retry_cost_ratio,
       SUM(cost_amount)                          AS cost
FROM dwd.fct_llm_call
WHERE dt >= '2026-08-01'
GROUP BY scenario, DATE_TRUNC('week', event_time)
ORDER BY scenario, wk;

# 提示结构：稳定前缀在前，动态内容在后，提高缓存命中
messages = [
  {"role": "system", "content": SYSTEM_PROMPT},     # 固定：角色、规则（版本化）
  {"role": "system", "content": TOOL_GUIDE},        # 固定：工具使用说明
  {"role": "system", "content": SEMANTIC_LAYER_DOC},# 较稳定：指标口径（按天更新）
  # ---- 以上是可缓存的稳定前缀，不要在这里插入时间戳、用户名等动态内容 ----
  {"role": "user", "content": f"当前时间：{now}；用户角色：{role}"},
  *summarize_history(history, keep_last=4),           # 动态：历史摘要 + 最近几轮
  {"role": "user", "content": question},
]
 
# 模型分级：先用小模型判断复杂度，再路由
level = small_model.classify(question)               # simple / complex
model = "small-model" if level == "simple" else "large-model"

展开三：建立长效机制

一次性降本之后，如果没有机制，几个月后成本又会涨回来。我会建立以下机制：

• 成本看板：按场景、租户、Agent 版本展示总成本和单位成本（每次成功提问的成本）。单位成本比总成本更能反映效率。

• 预算和配额：每个场景、每个租户设定月度预算；超出阈值先告警，再限流或降级到小模型。

• 异常告警：日成本、单次平均 Token、重试率出现突增时自动告警，第一时间发现问题。

• 上线成本评审：新版本上线前，用评测集跑一遍，对比单次成本变化。效果提升但成本翻倍的改动，需要明确评估是否值得。

-- 单位成本：每次成功提问的成本，比总成本更能反映效率
SELECT t.scenario, t.agent_version,
       SUM(c.cost_amount) / NULLIF(COUNT(DISTINCT CASE WHEN t.is_success = 1
                                               THEN t.turn_id END), 0) AS cost_per_success
FROM dwd.fct_agent_turn t
JOIN dwd.fct_llm_call c ON t.turn_id = c.turn_id AND c.dt = t.dt
WHERE t.dt BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY t.scenario, t.agent_version;

注意这里用的是“每次成功提问的成本”。如果一个优化让成本降了一半，但成功率也降了一半，单位成本其实没有变好。

实战经验：数据成本治理的思路完全通用

我在某出海硬件品牌做过数据平台的成本优化，最终存储成本降低了 35%、整体 ETL 执行时间减少了 40%。这类成本治理的通用方法论是：先把成本按业务线、按表、按任务归因清楚，找到头部的大户；再针对性地优化存储和作业；最后建立成本看板和新增资源的评审机制。

大模型成本治理是同一套方法论：归因到头部，针对性优化，用机制防反弹。只是成本单元从“表和任务”变成了“场景和调用”。面试时把这层迁移讲出来，比单纯罗列降本技巧更有说服力。

追问链

追问一：换小模型会不会影响效果？怎么权衡？

一定会有影响，所以必须用评测集验证。我会把任务按复杂度分层，在每一层上对比大小模型的效果和成本。通常分类、抽取、简单问答这类任务，小模型效果差距不大但成本低很多；复杂推理、多步规划，大模型优势明显。路由策略就是基于这个对比结果制定的，并且上线后持续监控各层的效果指标。

追问二：怎么把成本分摊到各个业务部门？

前提是每次调用都带上租户或部门标签，以及场景标签。直接成本按调用归属分摊；公共部分（比如评测、离线索引构建的 Embedding 成本）按使用量比例分摊。这和数据平台按业务线分摊计算存储成本是一样的做法。分摊结果做成月度账单，让业务方看到自己的用量和成本，本身就有很强的约束作用。

追问三：提示缓存为什么能省钱？有什么注意事项？

大模型服务通常支持对请求中相同的前缀部分做缓存，命中缓存的输入 Token 价格明显低于普通输入，延迟也更低。注意事项是：缓存基于前缀匹配，所以稳定的内容要放在前面，动态内容放在后面；任何对前缀的修改都会让缓存失效；缓存有有效期，低频请求可能命中不了。具体的价格和规则以所用服务的官方文档为准。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
先归因：用量、步数、上下文、缓存、重试、单价	直接全部换成便宜的模型
上下文治理和提示缓存通常收益最大	限制用户使用次数
模型分级路由，用评测集验证	只看总成本不看单位成本
看单位成本（每次成功提问成本）	一次性优化，没有长效机制
预算、配额、告警、上线成本评审	不知道缓存命中率这回事

怎么挂到你的项目上

话术模板：“我做过数据平台的成本治理，存储成本降了 35%，方法是先按业务线和表归因，再针对头部做优化，最后用看板和评审机制防反弹。大模型成本我会用同样的方法：先按场景、版本、调用用途拆解，看增长来自用量、步数、上下文还是缓存失效；优化时优先做上下文治理和提示缓存，再做模型分级；最后用单位成本看板和预算配额建立长效机制。”

总结

成本题的标准答法是归因 → 优化 → 机制三步。归因要能拆到具体因子，优化要知道每种手段的收益和代价，机制要落到看板、预算和评审。数据开发做过存储和计算的成本治理，这套方法论可以原样迁移，是非常好的加分点。

下一篇聊可靠性：多 Agent 协作调用链很长，失败了怎么重试，才能既幂等又不重复执行？

你们的大模型成本，主要花在哪个环节？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长