大模型成本怎么降，5 个动作先做前两个

上个月我算了笔账，一个 8 步的 Agent 任务，跑 DeepSeek-V4-Pro 高峰时段，约合四毛四。这个数字单看没什么感觉，放到日活一万的量级就是一年一百六十万。

问题出在两个地方，一是步数，二是缓存。缓存这一项我原先的预期是命中 95% 能省下一大半，实测只省 30%。原因不复杂，历史对话会越滚越大，它吃掉了大部分输入，而那部分没法靠前缀缓存解决。这篇把大模型成本这件事拆开算，代码可以直接跑。

一、先把单价抄下来

讨论降本之前得知道基准价。我抓了 DeepSeek 官方定价页（2026-10-18，zh-cn 版），单位元（人民币）每百万 token。

模型	时段	缓存命中输入	缓存未命中输入	输出
deepseek-v4-pro	高峰	¥0.30	¥9.00	¥27.00
deepseek-v4-pro	低谷	¥0.15	¥4.50	¥13.50
deepseek-flash	高峰	¥0.04	¥2.00	¥8.00
deepseek-flash	低谷	¥0.02	¥1.00	¥4.00

提一句型号版本，deepseek-flash 对应 DeepSeek-V4.1-Flash-1017，deepseek-v4-pro 对应 DeepSeek-V4-Pro-0813。两者都支持非思考与思考模式（flash 默认非思考），上下文 1M、最大输出 384K，并发限制 flash 2500、v4-pro 500。另外 Search 和 Fetch 按次计费，每 1000 次成功请求 5 元，官方注明 2026 年 11 月 1 日起对 Harness、Claude Code、Codex 里的服务端调用也开始收费。

两个细节值得注意。

第一，缓存命中和未命中的差价是 30 倍。v4-pro 高峰时段，未命中 ¥9.00，命中 ¥0.30。这条差价是后面所有缓存优化的基础。

第二，官方现在按峰谷计价。定价页写的高峰时段是北京时间周一至周五（不含中国法定节假日）9 点到 12 点、14 点到 18 点，其余时段（含周末及法定节假日全天）都算空闲时段。有意思的是空闲时段价格正好是高峰时段的一半。

二、一次任务到底花多少

场景设定如下，8 步任务，系统提示 1200 token，工具定义 800 token，每步输出 300 token，工具返回按回答长度三倍估算。

复制代码

  deepseek-v4-pro      peak     ¥0.4356
  deepseek-v4-pro      offpeak  ¥0.2178
  deepseek-flash       peak     ¥0.1016
  deepseek-flash       offpeak  ¥0.0508

同一份任务，v4-pro 和 flash 差 4 倍多，峰谷之间又差 2 倍。这两个杠杆是白捡的，前提是你的调用量足够大，能撑起错峰调度。

三、缓存的真实收益，比宣传的小

我一开始的预期是前缀缓存能省 50% 到 90%。实测下来，8 步任务里前缀命中率 95%，只省了 30.4%。

复制代码

  前缀命中率    0%  ¥0.4356
  前缀命中率   50%  ¥0.3660
  前缀命中率   80%  ¥0.3242
  前缀命中率   95%  ¥0.3034

    8 步累计　前缀 16000 token，历史 25200 token
    前缀只占输入的 38.8%
    全部未命中　　¥0.4356
    只有前缀命中　¥0.3034　省 30.4%
    整个输入都命中 ¥0.0951　省 78.2%

那 47.8 个百分点的差距去哪了。历史对话。前缀是固定的 2000 token，8 步累计 16000。历史部分从 0 开始累积到 25200，反而更大。前缀缓存只能救前者。

这带来一个反直觉的结论。压大模型成本的时候，光盯着缓存命中率不够，还得同时压历史长度。知识库里把「上下文压缩」和「Prefix Cache」并列成两条降本法，顺序上把压缩排在缓存前面，从这个数字看是有道理的。

另外前缀缓存有个前提经常被忽略，前缀必须稳定。系统提示里插时间戳、随机 ID，工具定义顺序变了，命中率直接归零。这一条在代码里体现不出来，只能靠约定。

四、步数是最大的杠杆

同样的场景，改步数。

复制代码

    5 步  ¥0.2115
   10 步  ¥0.6255
   20 步  ¥2.0610
   40 步  ¥7.3620

从 5 步到 40 步翻了 34 倍。看起来是线性增长，实际更陡，因为历史在累积，每一步的输入都比上一步长。

失控的情况更夸张。我跑了 80 步，正常 8 步是四毛四，80 步是二十七块七，63.6 倍。Agent 按步计费，一个死循环能把一整天的预算烧光。

所以 max_steps 必设，而且不能只限输出长度。知识库给的区间是简单问答 5 到 8 步，复杂多步任务 15 到 25 步，取真实分布的 P99 再加余量。

五、预算熔断要转降级

熔断不能直接抛异常，用户看到的是报错。知识库的做法是转降级，返回一句「未能完成，请简化问题」或者转人工，同时打告警。

三层预算各管一段。任务级防单次失控，租户级防某个客户刷，全局级防整体击穿。

python 复制代码

class BudgetGuard:
    """三层预算守卫：任务级、租户级、全局级。

    熔断时不直接崩，转降级（返回提示或转人工）。
    """

    def __init__(self, task_budget, tenant_budget, global_budget):
        self.limits = {
            "task": task_budget,
            "tenant": tenant_budget,
            "global": global_budget,
        }
        self.spent = {k: 0.0 for k in self.limits}

    def can_afford(self, estimated_next):
        return all(
            self.spent[k] + estimated_next <= limit
            for k, limit in self.limits.items()
        )

    def charge(self, amount):
        for k in self.spent:
            self.spent[k] += amount
        return dict(self.spent)

单步成本约 ¥0.026，任务级设 ¥0.07，跑到第三步就熔断。

复制代码

  第 1 步扣费 ¥0.0261，任务级已用 0.0261
  第 2 步扣费 ¥0.0261，任务级已用 0.0522
  第 3 步熔断，转降级：返回「未能完成，请简化问题」并告警

  熔断时各层用量：
    task     ¥0.0522 / ¥0.07  (74.6%)
    tenant   ¥0.0522 / ¥0.35  (14.9%)
    global   ¥0.0522 / ¥1.4  (3.7%)

注意任务级已经用掉 74.6% 的时候，租户级才 14.9%。这种场景下如果只设一层全局预算，熔断会晚很多才触发，前面烧掉的钱全是浪费。

六、降本五法的优先级

知识库列了七法，按 ROI 排了序，我结合上面的数字重新说一遍。

先做前缀稳定 + 缓存实测。 前提是稳定，收益 30% 起，但要注意它有天花板。

第二步压历史长度。 这是我这次算完才意识到的一条。历史占输入 61.2%，它涨起来比前缀快得多。压缩历史、裁掉无效的工具返回，效果往往比调缓存参数立竿见影。

第三步设 max_steps 和熔断。 难度低，防的是尾部风险。63.6 倍那个数字就是理由。

第四步模型路由。 小模型做分类和简单工具调用，大模型只处理真需要推理的步骤。要注意路由不能降级效果，得先评测验证。

第五步结果缓存。 相同问题不重算。key 要带版本或时间戳，知识库更新后自动失效。金融医疗这类强时效场景慎用。

七、一个容易被忽略的坑

上面所有算法都建立在一个前提上，前缀稳定。系统提示开头插一行当前时间，或者给每个会话生成一个随机 ID，工具定义的顺序因为字典遍历而每次不同，缓存命中率会直接归零。

这个坑的隐蔽之处在于它没有报错。调用照样成功，账单照样出，你只是多付了钱。判断有没有中招，看命中率监控就行，突然掉到接近零，先查前缀里有没有随请求变化的东西。

还有一处细节，官方文档写得很明确。缓存按「完整前缀单元」匹配，必须整个对上才算命中，不存在按固定 token 数切块命中的说法。文档给的例子是，第一次请求是 A 加 B，第二次是 A 加 B 加 C，第二次能完整命中第一次的 A 加 B。反过来，第一次 A 加 B、第二次 A 加 C 就命不中，因为 A 加 C 没有完整匹配上 A 加 B 这个单元。

这也解释了另一个现象。前两次请求都没命中，第三次却命中了。文档说系统在多次请求之间检测到公共前缀后，会把这段公共前缀单独持久化成一个单元，第三次完整复用它就命中了。所以缓存有预热成本，短会话里可能一次都命中不了。

文档还有两条要留意。一是缓存是尽力而为，不保证百分之百命中。二是缓存闲置后会自动清理，通常几小时到几天。跨天的定时任务别指望昨天的缓存还在。

八、常见坑

Q 结果缓存会不会返回过期答案

会。key 里带版本号或时间戳。知识库更新后缓存自动失效。

Q 优化成本会不会牺牲效果

优先级是安全 > 效果 > 成本。先保证效果达标，再在达标线内压成本。用「成功任务成本」这个指标监控，不要用「单次调用成本」，后者会诱导你把任务做简单。

Q 怎么发现成本异常

靠成本看板，四个维度，总体看日环比，按场景看单任务成本，按工具看调用次数和失败率，按模型看用量分布。按工具拆最容易找出又贵又没用的那种。

Q 全局预算耗尽怎么办

对新请求返回 429 或者排队。不要静默放行。

九、小结

三点。

第一，缓存收益有天花板。8 步任务里前缀只占输入 38.8%，命中率推到 95% 也只省 30.4%。想再省得动历史。

第二，步数是最大的杠杆。5 步到 40 步差 34 倍，失控 loop 能到 63 倍。max_steps 必设。

第三，熔断要分层还要转降级。只设全局预算会晚触发，裸崩用户体验差。