单价 1 元的国产 Flash 模型，为什么你的账单没降：一份可直接用的成本核算方法

概要

一周之内，MiniMax 发了 M3.1 Flash，输入 1 元、输出 4 元每百万 token；DeepSeek 更新了 V4.1-Flash-1017，输入 2 元、输出 8 元，空闲时段半价。单价确实腰斩了，但很多团队换完之后账单一分没少。 这篇讲清楚为什么，给三样能直接用的东西：一个正确的成本公式，一段能跑的 Python 核算脚本，一张按任务类型选模型的对照表。 所有价格数据标注了公开报道来源和时间，实际以厂商当期定价为准。

一、先把这一周发生了什么说清楚

10 月 17 日，DeepSeek 更新 V4.1-Flash-1017，重点提升完整项目开发能力，同时缩短输出长度和任务运行时间。据公开报道，其输入约 2 元每百万 token，输出约 8 元，空闲时段半价，缓存命中输入约 0.04 元。同日还开放了自研搜索 API，Search 与 Fetch 接口均为 5 元每千次。

10 月 19 日晚，MiniMax 发布 M3.1 Flash。输入 1 元、输出 4 元、缓存读取 0.1 元每百万 token。官方称推理速度提升近三倍，日常输出 200+ TPS，中位数稳定在 170+ TPS，综合使用成本降幅约七成。评测方面，DeepSWE v1.1 得 73.7，OSWorld V2 得 61.7，CyberGym 得 82%，BankerToolBench 得 76.2。

把两个模型的关键参数放一起看：

价格单位统一为每百万 token。以上来自公开报道，两家都有各自的时段或条件限制，签约前一定去官网核对当期价格。

表面看，这是明显的降价。但换完之后账单没降，这件事非常常见。

二、单价不等于成本，差在三个地方

差异一：输出才是账单的大头

看单价表的时候，人的注意力容易停在输入那一栏。1 元看着是很便宜。但真正决定账单的是输出 token。

原因很直接：一次对话里，输入通常只有几百到几千 token，输出也是类似量级，看着差不多。但在 Agent 场景里，输出的量会被放大得非常厉害。多步任务每一步都要输出思考和动作，工具返回的内容又要重新进输入，一个任务跑下来，输出 token 可能是输入的几倍。

举个例子，假设某任务单次调用输入 8 万 token、输出 20 万 token：

• MiniMax M3.1 Flash：0.08 x 1 + 0.2 x 4 = 0.88 元
• DeepSeek V4.1-Flash-1017：0.08 x 2 + 0.2 x 8 = 1.76 元

差价一倍。而如果反过来，输入 20 万、输出 8 万，两边差距会缩小，但仍然明显。

这就是第一个认知修正：先量出你自己的输入输出比例，再谈单价。 不看比例直接比价，等于没算。

差异二：重试和返工

真实的调用不是一次成功的。改写、纠错、格式不对重来、工具调用参数错了重试，这些都算钱。

一个成功率 90% 的模型和一个成功率 85% 的模型，看起来只差 5 个百分点。但换算成平均调用次数，前者是 1.11 次，后者是 1.18 次，成本差 6% 左右。如果一个任务要串联五步，每步都有 90% 的成功率，整体一次通过率只有 59%，平均要跑接近两次。

所以正确的算法是有效成本，不是单价乘 token 数：

有效成本 = 单次调用成本 × 平均调用次数
平均调用次数 = 1 / 一次通过率

这一步经常被跳过，因为它需要你真的去测自己场景的成功率，而不是看厂商榜单。但恰恰是这一步，决定了你换模型是真的省钱还是白折腾。

差异三：缓存命中率

这一条在长上下文场景里是决定性的。

两个模型的缓存价格差了两倍多：DeepSeek 约 0.04 元，MiniMax 是 0.1 元。但要注意，缓存只对命中的那部分生效，输入里没命中的部分仍按原价算。所以缓存价格能省多少，完全取决于命中比例。

如果你的场景是「同一份长文档反复问不同问题」，缓存命中的比例可能到 80% 以上，这时候缓存价格才开始有实际影响。反过来，如果每次请求都是全新的内容，缓存一次都用不上，那这个参数对你没有意义。

缓存价格只在有缓存的时候才算数。 判断标准很简单：你的请求里，有没有大段内容在各次调用之间重复出现。

三、一段能直接跑的核算脚本

把上面三件事合起来，写成代码就是这样。改几个参数就能用在自己的场景上：

def cost_per_task(
in_tokens, out_tokens,
price_in, price_out,
cache_hit_rate=0.0, price_cache=0.0,
pass_rate=1.0,
runs=1,
):
"""
计算单个任务的有效成本，单位：元
in_tokens / out_tokens: 单次调用的输入输出 token 数
price_in / price_out: 每百万 token 价格，单位元
cache_hit_rate: 输入中命中缓存的比例，0 到 1
price_cache: 缓存命中部分的每百万 token 价格
pass_rate: 一次通过率，0 到 1
runs: 一个任务需要串行调用几次
"""
if not 0 <= pass_rate <= 1:
raise ValueError('pass_rate 必须在 0 到 1 之间')

cached = in_tokens * cache_hit_rate
fresh = in_tokens – cached

single = (fresh / 1_000_000) * price_in
single += (cached / 1_000_000) * price_cache
single += (out_tokens / 1_000_000) * price_out

attempts = 1 / pass_rate
return single * attempts * runs

# MiniMax M3.1 Flash 与 DeepSeek V4.1-Flash-1017 的对比
cases = [
('短问答', 800, 600, 0.0, 1.00),
('长文档分析', 60_000, 3_000, 0.8, 1.00),
('代码生成', 8_000, 12_000, 0.0, 0.88),
('Agent 多步', 80_000, 200_000, 0.5, 0.85),
]

for name, i_tok, o_tok, hit, rate in cases:
mm = cost_per_task(i_tok, o_tok, 1.0, 4.0, hit, 0.1, rate, 3)
ds = cost_per_task(i_tok, o_tok, 2.0, 8.0, hit, 0.04, rate, 3)
print(f'{name}: MiniMax {mm:.4f} 元, DeepSeek {ds:.4f} 元')

上面这段在本机跑出来的结果是这样：

• 短问答：MiniMax 0.0096 元，DeepSeek 0.0192 元
• 长文档分析：MiniMax 0.0864 元，DeepSeek 0.1498 元
• 代码生成：MiniMax 0.1909 元，DeepSeek 0.3818 元
• Agent 多步：MiniMax 2.9788 元，DeepSeek 5.9351 元

四个场景 MiniMax 全胜，这是价格表决定的，它输入和输出两项单价都是对方的一半。但请注意差距的变化：短问答差了整整一倍，长文档分析只差 73%。

差距为什么会缩小？因为缓存。缓存价格是 DeepSeek 唯一占优的一项，约 0.04 对 0.1。命中率越高，这一项在总成本里的权重越大。

那命中率要到多少，DeepSeek 才能在这项上翻盘？

只看输入部分，设命中率为 h，两边列出来：

MiniMax 输入成本 = 未命中部分 x 1.0 + 命中部分 x 0.1
DeepSeek 输入成本 = 未命中部分 x 2.0 + 命中部分 x 0.04

令两者相等求解，命中率约 94.3%。低于这个数，MiniMax 的输入成本更低；高于这个数，DeepSeek 反超。

94.3% 在真实场景里很难达到，所以缓存价格在多数情况下不是决定性因素。但如果你有一个超长上下文加高重复率的场景，比如同一份代码库反复问不同问题，这个临界点值得自己算一遍，结论可能和直觉相反。

这就是为什么「哪个模型更便宜」这个问题没有统一答案，只能按任务算。

四、按任务类型选模型的对照表

把上面的结论落成一张表，可以直接当决策参考：

两条实操建议：

第一，先用真实流量跑一周，把输入输出比例量出来。 不用写复杂监控，在网关层记录每次调用的 in_tokens 和 out_tokens 就够。没有这个数据，所有比价都是猜。

第二，把成功率也记下来。 同一个任务重试几次、为什么重试，这个数据比单价表更有决策价值。

五、两件容易忽略的事

峰值和空闲的差别。 DeepSeek 的空闲时段半价，这是个实打实的折扣，但前提是你的任务能挪到空闲时段跑。批处理、离线分析、训练数据生成这类任务完全可以，实时对话不行。做成本规划的时候，把流量按时间分成可挪动和不可挪动两部分，能挪的那部分才是这个折扣的实际适用范围。

价格是会变的。 这一周两家接连降价，说明价格战还在进行中。所以成本核算的方法要比单次的价格结论更值钱。把上面那个脚本做成参数化的，价格一变，改两个数字重跑即可，比每次重新拍脑袋强。

六、我们自己的做法

我们在 FinAPI 里做成本归集的时候，按有效成本而不是单价算账，跨模型路由也以有效成本做决策依据。原因很实际：单价便宜但成功率低的模型，乘以重试次数之后往往更贵。

这个逻辑说起来简单，但要落地，前提是先把上面那几个变量量出来。核算方法本身不难，难的是有没有数据。

七、小结

回标题那个问题：单价降到 1 元，为什么账单没降。

三个原因：输出才是大头，重试会放大成本，缓存命中的前提是有重复内容。

换模型之前先做这三件事，比换十次模型都管用：量输入输出比例、量成功率、量缓存命中率。

价格战对开发者是好事，但红利只属于算得清的人。

我建了个 AI 技术交流群，平时聊模型接入、成本治理这些事。国产模型的价格变动和实测数据我会同步在群里~