Flash 降价七成，Agent 账单为什么没降

版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。

第1章 先看清「七成」是哪个七成

1.1 两次更新，两种计价单位

2026-10-19 晚间，MiniMax 发布 M3.1 Flash。官方博客写的是线上推理速度提升近 3 倍、使用成本降低 70%，同时给出美元挂牌价：每百万 token 输入 0.15、输出 0.60、缓存读取 0.015。两天前的 10-17，DeepSeek 把deepseek-flash更新到 V4.1-Flash-1017；截至 2026-10-24，官方定价页上这一档是输入 0.30 / 0.15 美元（峰时 / 谷时）、输出 1.20 / 0.60、缓存命中 0.006 / 0.003，官方对这次更新强调的是缩短输出长度和任务运行时间。

国内媒体转述的人民币价是每百万 token 输入 1 元、输出 4 元、缓存读取 0.1 元（截至 2026-10-24，出处见附表 A）。

两种币种不做换算，避免引入汇率假设；本文后面的账全部用人民币，只取 MiniMax 这一组价。

表里有一处值得停一下：人民币的 1 : 0.1 : 4，和官方英文博客的 0.15 : 0.015 : 0.60，比例完全一致。两套数字对得上，说明媒体转述没走样。顺带说一句，Flash 档的输入价只有同门 Pro 档的四分之一不到——你已经站在最便宜的那一档了，再往下压单价，空间有限。

缓存读取为什么能便宜一个数量级，值得单独说一句。服务端把上一次请求里「算过的前缀」的中间状态留着，下一次开头一模一样就直接复用，不用重算。它省的是算力，所以价格才敢压到输入价的十分之一。各家对这个机制的叫法不一样，但计费口径是同一个：命中的部分按缓存价，没命中的按全价。

1.2 「降七成」是任务口径，不是 token 口径

官方博客那句的原话是 reducing usage costs by 70%，紧挨着的限定语是 For agentic tasks——一个 Agent 任务跑完的综合成本。而同一篇里，输入输出单价的降幅写的是「五成以上」，缓存读取降「七成以上」。

单价降五成多，任务成本降七成，中间那两成从哪来？官方没有拆。我的读法是：任务成本 = 单价 × token 数，单价降五成多还能把任务成本降七成，剩下的差额只能来自 token 数变少——更短的输出、更少的重试轮次。

这不是抠字眼。它说明厂商自己也清楚：单价不是账单的全部。

1.3 看到「降价」，先问三句

降的是哪个价——挂牌价、缓存价，还是任务综合成本？按每 token 算，还是按每任务算？你自己的账单里，被降的那一部分占几成？

第三问答不上来，前两句就不用问了。

第2章 一笔 Agent 账单的四段

2.1 接口是无状态的，历史要自己重发

工具调用（tool calling）的循环长这样：模型回一段话 → 你的程序执行工具 → 把结果拼回消息列表 → 再请求一次。每次请求都要把完整消息列表发过去，因为服务端不替你记着上一轮。

于是第 10 轮的请求里，装着第 1 到第 9 轮的全部工具返回和全部回复；第 20 轮装着前 19 轮。这就是重放（replay）：同一段文字，被反复计费。

数一下重放的次数：第 1 轮的内容要被后面 19 轮各重发一次，第 2 轮被 18 轮重发，一路减到 1——总共 190 个「轮次对」。平均下来，每一段历史被重放 9.5 次。所以历史越长越贵不是加法，是乘法。

2.2 一段长 JSON，会被重放十几遍

第 3 轮，工具返回了一份 12,006 token 的 CDN 清单——每个对象的三个尺寸变体、etag、mime、更新时间都在里面，而模型真正要的只有 id 和一个尺寸。这一整段进了历史，之后 17 轮每轮重发一次：204,102 token，占整个任务历史重放的 40.6%。

这是本机模型里最刺眼的一行。你写代码时它只是一句return resp.json()，账单上它是一笔分期付款。

2.3 输出单价是输入的四倍

MiniMax 这组价里输出 4 元、输入 1 元。DeepSeek 那组更极端：输出是输入未命中价的 4 倍，是缓存命中价的 200 倍。所以「少说两句」在账单上是有价格的。

两个容易漏掉的点：思考型模型先写推理再写答案，推理 token 按输出计价；上一轮吐出的内容会作为下一轮的输入再算一次。同一段文字，可能先按输出收一次，再按输入收若干次。

把四段合起来看——固定前缀、历史重放、新增观察、输出——就是一笔 Agent 账单的全部来源。第 3 章会把这四段分别算成钱。

第3章 本机实测：把 20 轮拆成 token 结构

3.1 建模方式与三条边界

脚本在work/2026-10-24_04_账单实测.py，纯标准库，不联网、不调接口。

cdworkPYTHONIOENCODING=utf-8 python2026-10-24_04_账单实测.py>2026-10-24_04_账单实测.log

三条边界先写清楚，免得被当成账单截图：

• 这是按公开挂牌价乘 token 数的结构化估算，不是任何一家厂商的真实账单；
• token 数由字符长度折算（中文 0.7 token / 字，英文 3.8 字符 / token），不是分词器实测，同一段中文换个分词器能差两三成；
• 缓存命中率是设定值，不是线上观测值。

3.2 结果：77.1% 花在重放上

20 轮下来单次 0.6516 元。按每天 2,000 次、30 天算（6 万次），月账 39,096 元。这个数不算夸张，但看构成就不好受了：四分之三的钱，花在把已经说过的话再说一遍。

换个算法看同一件事：0.6516 元里，模型真正「读进新东西」只花了 0.0302 元，剩下的 0.62 元都在重复读旧东西。这个比例不是模型差，是循环本身决定的——你把同一段历史发了 20 次，就得付 20 次的钱。

3.3 逐轮看，贵是怎么长出来的

第 1 轮 0.0068 元，第 20 轮 0.0513 元，7.5 倍。前缀 token 从 3,057 涨到 45,553——同一件事越往后越贵，因为要求模型「记得」的东西越来越多。

下面是脚本里的核心循环，删掉了逐轮明细和打印部分。

defrun_task(rounds=20,cache_hit=0.0,price=PRICE_BASE,big_round=3,big_tokens=None,obs_tokens=None,out_tokens=700,final_tokens=1200,cap_obs=None,window=None):price=priceorPRICE_BASE fixed=est_tokens(SYSTEM)+est_tokens(TOOLS)big=est_tokens(BIG_OBS)ifbig_tokensisNoneelsebig_tokens obs_n=est_tokens(OBS_NORMAL)ifobs_tokensisNoneelseobs_tokens history,acc=[],{"cached":0.0,"uncached":0.0,"obs":0.0,"out":0.0}foriinrange(1,rounds+1):obs=bigifi==big_roundelseobs_nifcap_obsisnotNoneandobs>cap_obs:obs=cap_obs out=final_tokensifi==roundselseout_tokens hist=history[-window:]ifwindowelsehistory prefix=fixed+sum(o+tforo,tinhist)cached=prefix*cache_hit# 只命中「本轮之前」的稳定前缀uncached_prefix=prefix-cached acc["cached"]+=cached/1e6*price["cache_read"]acc["uncached"]+=uncached_prefix/1e6*price["input_miss"]acc["obs"]+=obs/1e6*price["input_miss"]acc["out"]+=out/1e6*price["output"]history.append((obs,out))return{"acc":acc,"total":sum(acc.values())}

这个循环里没有任何优化，它只是把你每天在写的 agent loop 翻译成账单。看懂它，就知道该在哪里动手：history的长度、obs的长度、out的长度。

第4章 命中率：三档敏感性

4.1 0 / 50 / 90 三档

同一份任务结构，只改命中率，价格一分没动。

forhin(0.0,0.5,0.9):r=run_task(cache_hit=h)print("%5.0f%% %s 元 月账 %s 元"%(h*100,money(r["total"]),monthly(r["total"])))

4.2 为什么九成不是天方夜谭

前缀缓存（prompt caching）的规则很硬：从第一个 token 开始完全相同的部分才算命中。Agent 循环天生就该命中——系统提示不变、工具定义不变、历史只往后追加。

所以命中率低，通常不是模型的问题，是拼接方式的问题。四个常见的自毁动作：

• 把当前时间、请求 id 写进系统提示的最前面；
• 每轮按相关度重新排序工具列表；
• 在历史中间插一条「当前进度摘要」；
• 把刚取回的检索结果插到历史前面，而不是末尾。

每一个都会让「相同前缀」在某个位置断掉，断点之后全部按未命中计价。

怎么验证自己的命中率：看接口返回的用量字段里有没有「缓存命中」这一类计数。两家厂商都在价目表里单列了缓存价，说明这是明码计费的一项。拿到这个数，4.1 那张敏感性表就能换成你自己的曲线。

4.3 提命中率的三个动作，各有代价

一是把会变的东西挪到最后，代价几乎为零，只改拼接顺序；二是冻结工具定义的顺序和措辞，代价是改工具要发版、不能热更新；三是裁剪只从最早的一整轮开始裁，代价是丢早期约束，第 6 章细说。

判据一句话：**如果你的消息列表是每轮重新拼出来的，而不是追加出来的，命中率大概率是 0。**去代码里搜一下有没有messages = [...]这种重建，比看任何教程都快。

第5章 降价七成 vs 命中率九成，谁更省

5.1 对照实验

B 和 D 打平了：0.1955 对 0.1952，差 0.0003 元。一个单价打三折，一个命中率做到九成，在账单上几乎等价。

5.2 为什么打平，以及为什么不能照搬

算一遍就明白：降价是对所有输入输出打三折；命中率九成相当于把输入成本抹掉 81%，但对输出一点用没有。本模型里输出只占 8.9%，两个效应刚好抵消。

换一组参数就分开了：输出占比更高的任务——长文写作、代码生成——命中率的天花板会明显低于降价；缓存价不是输入十分之一的厂商，命中率的杠杆也会变短。这个「打平」是这组参数的结论，不是规律。

真正的差别在三个地方：

• 降价是厂商动作。48 小时内两家接连更新，谁都能拿到，它不构成你的优势；
• 命中率是代码动作。写一次长期生效，换模型也带得走；
• 覆盖面不同。降价对所有 token 生效，命中率只对「重复的前缀」生效，新增观察永远按未命中算。

5.3 判据：先看输入占比，再看命中率

输入占账单八成以上、命中率低于五成 → 先做命中率；命中率已经八成以上 → 再谈换更便宜的模型。

还有个信号值得留意：命中率做到九成之后，输出在账单里的占比从 8.9% 涨到 29.7%（0.0580 除以 0.1952）。战场换人了——这时候压输出才开始划算，在那之前压输出只是挠痒。

再补一个反例：如果你的任务平均只有 3 到 5 轮，历史重放占不到一半，那第 4 章这套敏感性对你几乎无效。这种任务里，降价是真降价，换个更便宜的模型就是最直接的动作。先量轮数，再决定信谁。

大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过。第 5 章这种「先算清账再挑模型」的顺序，正好对应路线图里工程化那一段。放在资料包里，扫码即可获取：

第6章 你该改的三步

6.1 历史怎么裁

整轮滑窗：只保留最近 N 轮。本机把 N 设成 6，命中率为 0 时省 41.8%，命中率九成时省 26.5%。代价是早期约束丢失——第 2 轮交代的「别动生产库」，到第 15 轮已经不在上下文里了。

滚动摘要：把前 N 轮压成一段话。代价是要多调一次模型，这次调用的输出按 4 元计价；而且摘要本身也会进历史，被后面每轮重放。

状态外置：把「已经确认的事实」写成结构化字段，每轮只带这个字段，不带原始对话。代价最大——要改工具协议，工具得能读写这份状态。

一个反直觉的点：滑窗在命中率高的时候省得更少（41.8% 掉到 26.5%），因为被裁掉的那段本来就已经是 0.1 元的缓存价。它真正省的是上下文窗口和首 token 延迟，账单只是附带。

这里有个容易忽略的冲突：裁剪会打断前缀。前缀缓存只认从头开始逐字相同，你删掉中间某一轮，断点之后的内容全部按未命中重算。于是「裁历史省 token」和「提命中率省钱」是互相拉扯的：裁掉一段，省下它后面每轮 0.1 元的缓存价，但要付一次重新预填的全价。

判断方法很朴素——被裁的那段还剩几轮要跑？剩 10 轮以上，裁；只剩两三轮就收尾，别裁。

6.2 工具返回怎么截

优先级：字段白名单 > 条数上限 > 字符截断。

defslim_observation(text,keep_records=8):"""字段白名单 + 记录条数上限：只留定位一个对象所必需的字段。"""data=json.loads(text)out=[]foraindata["assets"][:keep_records]:out.append({"id":a["id"],"title":a["title"],"url":a["cdn"]["path"],"bytes":a["cdn"]["bytes"]})returnjson.dumps({"ok":True,"assets":out},ensure_ascii=False,separators=(",",":"))

12,006 token 的清单，只留 id、title、url、bytes 和前 8 条，压到 246 token，压缩 98.0%。整个任务单次成本从 0.6516 降到 0.4399，省 32.5%；命中率九成时从 0.1952 降到 0.1455，省 25.5%。

对照一下无脑硬截到 2,000 token：只省 27.6% 和 21.7%，还可能把 JSON 截成半截，下游解析直接报错。

两件事要一起看：长度压掉 98%，账单只降 32.5%——剩下的钱在别的轮次的重放里。这就是「账单结构」四个字的含义：任何单点优化只能动一段，动不了全部。

还有一个细节：白名单按「下一轮会不会用到」来定，不是按「这个字段好不好看」。清单里的 mime、etag、updated_at 看着无害，但二十轮里没人在决策时读过它，它就是纯成本。判断标准只有一句——这个字段在后续任何一轮里被引用过吗？没有就去掉。

6.3 输出怎么压

输出单价是输入的 4 倍，但要不要压，得看你处在 5.3 说的哪个阶段。命中率低的时候，压输出省下的钱连零头都算不上；命中率高的时候，它一下子变成三成。

三个做法：只回字段名和结论，不复述原文；用 JSON schema 约束长度；把长解释留到最后一轮一次性给。

代价要认：过度压缩会让模型丢掉中间推理，返工一次就把省下的钱吐回去——而返工意味着多跑一整轮，一轮的成本还随轮数递增。

第7章 把这套算法搬到你自己的账单上

7.1 三个必看量

一是每轮平均输入 token，看趋势是抬头还是平的；二是输入里命中缓存的部分占多少，看接口返回的用量字段（字段名各家不同，以官方文档为准）；三是输出占总 token 的比例。

第一个告诉你结构有没有问题，第二个告诉你单价有没有兑现，第三个告诉你下一步该压哪里。

7.2 一周能做完的自查

• 把消息列表改成只追加，跑一百次，看命中率有没有从 0 起来；
• 找出 token 数最大的那一次工具返回，给它加字段白名单；
• 在日志里记下每轮的输入 token 数，画一条曲线；
• 把「当前时间」从系统提示挪到用户消息末尾；
• 用本机那个脚本，把你这周的真实参数代进去，算三种命中率下的差价。

五件事都不需要换模型，也不需要等下一次降价。

怎么算这一周有收获：命中率从个位数抬到五成以上，或者单次任务成本降三成，两个达成一个就够。都达不到，通常说明你的任务本身没有可复用的前缀——短任务、一次性问答，本来就不吃缓存这碗饭，别硬套。

7.3 单价是厂商给的，结构是你给的

截至 2026-10-24，这一周里两家先后更新过一次：MiniMax 直接下调了挂牌价，DeepSeek 走的是缩短输出这条路。两条路最后都落在「任务成本」上，而不是单价上。下一次更新还会来，但每次之后你的账单降不降，取决于你的 Agent 每一轮往上下文里塞了什么——塞了多少历史、塞了多长的工具返回、让它说了多少废话。

这三件事，厂商帮不了你。

AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可。第 6、7 章那些裁剪与截断的做法，配合知识库里的 Agent 专题看更容易落地。放在资料包里，扫码即可获取：

附表 A：本文引用事实与出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：

• 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
• 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
• AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
• 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
• 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「AI」，优先通过。

资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。