前两天试了个小实验：让两个AI做同一件事——“把这个文件夹里的材料整理一下，按项目、年份和类型分类，找出重复文件，生成一份目录清单”。 第一个AI的回答很像样：建议先建几个文件夹，给了一段批量重命名的脚本，最后说“你可以把文件上传给我，我再帮你细看”。 第二个AI没怎么废话，直接打开了那个文件夹，读文件、判断格式、拆分类别、检查重复、生成目录，最后甩给我一份可以直接用的清单，附带一份“我做了什么”的执行记录。 两个AI背后可能是差不多水平的大模型，为什么一个只给建议，另一个真的动手把事办完了？这篇想把这件事拆开讲清楚。 一、点菜vs自己下厨 聊天机器人像坐在桌边帮你点菜的人。你问它今天吃什么、这道菜怎么做、三个人该点几个菜，它能分析、能建议、能讲得头头是道。但回答说完，这件事在它这儿就结束了——它不会去看冰箱里还剩什么、该采购点什么、火候不对了要不要重炒，更不会把菜端上桌。 Agent更像是接到目标后真正进厨房的人。你给它的不是一步步的指令，而是一个目标——“晚上六点前准备三菜一汤，有一个人不吃辣”。剩下的事它自己张罗：看现有食材、定菜单、决定先炒哪道、缺了什么自己想办法、中途火大了自己调整，直到达成目标为止。 这不是“服务员”和“更聪明的服务员”的差别，而是谁掌握了执行路径的决定权。区别不在于点菜的人只能说固定答案——他其实也能开放式地分析、建议、讲清楚利弊——而在于他说完以后，采购、烹饪、调整、验收，仍然要由你自己一步步完成。下厨时目标定了，用什么锅、先做哪样、中途要不要改主意，是他自己当场拿主意。 这个类比对应的是两家主流模型公司目前的工程定义，但需要先说明一句：行业对Agent并没有完全统一的术语边界。Anthropic把系统分成workflow和agent两类：workflow是LLM和工具按预先写好的代码路径走，agent则是LLM自己动态决定下一步做什么、调用什么工具。OpenAI的说法角度略有不同：workflow是为达成用户目标必须走完的一串步骤，agent则是能代表用户、由模型控制这串步骤执行的系统——换句话说，在OpenAI的语境里，Agent是在“执行workflow”，而不是把两者当成互斥的类别。两家措辞不完全一样，但共同强调的是同一件事：模型是否掌握了执行流程的控制权。 本文采用的是偏工程化的狭义口径：预设路径称为workflow，模型根据当前状态动态决定执行路径，才称为Agent。现实产品里，聊天、workflow和Agent能力往往被放在同一个界面里，不必强行归类。 二、真正的分界线：不是会不会说话，是谁决定下一步 聊天机器人的典型流程是这样的：用户提问，AI回答，用户判断这个答案有没有用，用户决定下一步该问什么，AI再回答。举个真实场景——让AI查资料，你复制结果，再让它整理，你保存成文档，再让它改格式，你发邮件出去。AI在每一步都参与了，但整条流程是靠你自己一步步连起来的。 Agent内部跑的是另一套循环：接收目标，判断当前处于什么状态，自己选择下一步该做什么，调用工具，拿到反馈，根据反馈修正计划，继续往下推进，直到自己判断“这件事完成了”。 判断一个系统的Agent成色，最核心的一问是：模型能不能根据当前状态决定下一步，并在拿到工具反馈后继续调整？这不是唯一条件，但它是区分固定workflow和Agent的第一道门槛。假设一套系统能搜网页、能读文件、能生成PPT，仍然要接着问——是你每次手动点选功能，还是程序按固定顺序走，还是模型根据当前结果自己拿主意？只有第三种，才算得上真正意义上的Agent。 这里有四个很容易被混淆的说法，值得单独拎出来说清楚： 能联网搜索≠Agent。搜索只是一件工具，如果搜什么、搜几次、什么时候停都是你在控制，它本质上还是个联网增强版的聊天机器人。 能记住上下文≠Agent。记忆能让多轮对话更连贯，但“记得你说过什么”和“能替你把事办完”是两码事。 能调用插件≠Agent。调一次天气、算一次数字、查一次数据库，都不构成对完整任务流程的控制权。 多个模型协作≠必要条件。单个Agent同样能完成复杂任务，OpenAI自己也建议先把单Agent做扎实，只有工具太多、逻辑分支太复杂、职责需要拆分时，才考虑上多Agent架构。 一句话小结这节：工具决定AI能做什么，执行权决定它是不是Agent。 聊天机器人、Workflow和Agent的真正区别：谁在决定下一步？ 三、“会执行”到底难在哪——两组基准，三层难题 概念讲清楚之后，容易冒出一个乐观误解：既然Agent就是“自己决定下一步”，那是不是接上工具就基本齐活了？现实要泼盆冷水——真正把一件事稳定执行完，比听起来难得多，而且难在三个不同的层次上。 第一层，完成一个受规则约束的业务闭环就不容易。Sierra研究团队2024年发布的τ-bench，测的不是Agent会不会调用某一个函数，而是它能不能在模拟的零售和航空客服场景中，一边和用户多轮沟通、一边调用API，还要遵守复杂的业务规则——这本身就和“给定所有信息、一次性执行”的旧基准不是一回事。评分重点也不只是数据库最终状态对不对，还要看Agent有没有把必要信息传达给用户。结果是，即便用GPT-4o跑function calling，零售场景的成功率也只有约61%，航空场景更是只有约35%。这说明“说清楚该怎么做”和“真的把这件事办对”，中间隔着一大截。 第二层，稳定执行比偶尔跑通更难。τ-bench提出了一个叫pass^k的指标，衡量的是同一个任务连续跑k次是不是次次都成功。直观理解，如果把每次执行看作相互独立，单次成功率即使有90%，连续8次全部成功的概率也只有43%左右。而在τ-bench的实际测试里，GPT-4o零售场景的平均成功率超过60%，pass^8却降到25%以下——这也是为什么“Agent能跑出一个漂亮的demo”和“Agent能每天稳定地跑”完全是两件事。 第三层，长链路任务是目前公认的最大短板。2026年发布的OSWorld 2.0专门测试长流程真实任务，一共108个，每个任务对熟练的人类操作者来说，中位耗时都要1.6小时。在论文测试的配置里，Claude Opus 4.8开最大思考、批量工具调用，严格意义上的完成率是20.6%（放宽到部分得分能到54.8%），token效率更高的GPT-5.5完成率约13%。这组数字只对应OSWorld 2.0所测的这类长流程电脑操作任务，不能代表客服Agent、代码Agent这些其他场景的整体水平；而且这个领域进展很快，7月Anthropic已经发布了新一代的Opus 5，官方称其在这项基准上的表现已经超过Opus 4.8，所以这里给出的仍是“当时那批模型能做到什么程度”，不是当前的最新水平。 三层难度合在一起，指向的是同一件事：Agent真正的门槛不在“能不能调用工具”，而在“能不能把一条受规则约束的长链路任务，稳定、正确地走到底”。 Agent执行能力的三道关 这几组数据来自不同模型、不同版本、不同评测框架，彼此之间不能直接换算比较，只用来说明“执行”这件事本身有多难，不做具体产品的排名依据。 四、Agent内部到底多了什么 拆开来看，一个能稳定干活的Agent，通常要具备六个部件： Agent = 大模型 + 工具 + 环境权限 + 任务状态 + 执行循环 + 安全护栏 大模型负责理解目标、判断下一步、处理意外情况，相当于厨房里的大脑，但光有大脑做不出饭 工具是它和外部世界打交道的手，包括读写文件、查数据库、发邮件、执行命令 权限决定它真正能动什么——没有权限，Agent说到底也只能给建议 状态让它知道任务走到哪一步了，不用每次都从头猜一遍 执行循环是“观察→规划→行动→反馈→检查→继续”这条闭环，这是Agent和“调用过一次工具的聊天机器人”最本质的区别 安全护栏决定哪些操作必须停下来问人，比如删除文件、发邮件前的确认 大模型能力已经相当普及，工具接入也越来越常见；真正拉开差距的通常是后四个部件——权限给到什么程度、状态记不记得住、循环转不转得起来、护栏立在哪儿。 五、真实片段：WorkBuddy的一次多步执行，和一个反例 上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里记录过几个真实场景，这里挑一个执行场景和一个对照场景重新看一遍。先说清楚：下面这个例子能证明它完成了多步任务，但不足以证明每一步都是“临场动态决策”——这一点留在下一节一起说。 一个是手机远程遥控电脑：在外面发一句“看一下当前文件夹下有哪些文件，把内容转写成markdown保存一份，总结主要内容给我”，到家活儿已经跑完了。这句话背后是它自己拆成了“列文件→读取→转写→总结”几步，而不是我手动点了四次功能——这至少说明它具备了“接收目标、自己拆解步骤”的能力，是本文第二节说的执行权的一种体现。 再对比同一篇里的“每日AI新闻推送”：设定好时间和内容规则，到点自动推送——这更接近固定workflow而不是严格意义上的Agent，因为触发条件和执行动作都是提前定好的，模型没有在中途做新的决策。这个对比恰好能落回本文第二节的核心判断：同一个产品里，不同功能可能分别落在workflow和Agent两端，不能一概而论。 六、Agent不是越自主越好 篇幅有限，这里只强调一个容易被忽略的判断：Agent能自主决策，不代表应该在所有事情上都放手自主。 先说一个真实的小例子：上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里，让WorkBuddy围绕一个主题跑一份调研报告，结果不算完美——报告里列的要点，有几个是没想到的，但也有几个是它“想当然”给出的，得自己核实过才能用。这提醒的是：Agent能自己往前推进，不代表它推进的每一步都对。在当前阶段，尤其是面对调研、发布、邮件和数据修改这类任务，把Agent的产出当成待验收的结果，而不是直接当最终结果使用，是正常的使用方式。 行业层面也有数据支撑这个判断。Gartner预测，超过40%的agentic AI项目会在2027年底前被取消，直接原因包括成本上升、业务价值不清晰、风险控制不足；同一份报告也指出，当前模型的成熟度和自主能力，仍不足以稳定完成复杂的业务目标。换句话说，项目失败通常不是单一的技术问题，而是能力、成本、价值和治理共同作用的结果。报告里还提到一个更扎心的现象：市面上数千家自称“agentic AI”的厂商里，真正名副其实的大概只有130家左右——这就是所谓的“agent washing”，把聊天机器人换个说法包装成Agent。 这个判断其实和第三节的执行数据是一体两面：在OSWorld 2.0测试的这类长流程电脑操作任务上，当时最佳配置的完整完成率也只有约两成。这不能代表所有Agent场景，但足以说明——面对长链路、高权限、难以回滚的任务，默认让Agent完全自治，在当下不是一个稳妥的选择。 ...

本文是「上下文窗口」系列第三篇。前两篇分别讲了《标称1M的token，为什么32K就开始变笨》（为什么会变笨）和《KV Cache：每读1个token，就要交一笔“显存税”》（为什么会爆显存）。这一篇不重复论证，直接回答一个更实际的问题：到底该设多大。 两位读者间隔两天，问了同一个问题： “Mac 24GB，到底该开16K还是32K？” “现在的模型动不动就说支持1M上下文，是不是就该一直开满？” 答案我已经在评论区打完字了，只是散在各处。这篇把它整理成一套能直接照抄的判断框架。 一、上下文有三个长度，不是一个 三个Context长度概念模型 先纠正一个直觉误区：Context越大越好。 前两篇已经用数据说清楚过：厂商标称的窗口，和模型真正“读懂”的窗口，从来不是一回事——在NoLiMa这项刻意排除关键词匹配、只测语义理解的基准测试中，32K的长度下，12个主流模型里有11个的表现跌到了短上下文性能的50%以下；而KV Cache这笔显存账，会随长度线性膨胀到硬件扛不住。这两条结论不重新展开，直接拿来当地基。 在这两条结论之上，这篇提出一个更好用的框架——任何一个模型的上下文窗口，其实是三个数字，不是一个： 标称长度（Advertised）：厂商发布会念的数字，128K、1M。它的含义仅仅是“技术上能塞进去”，不代表“能读懂”。 有效长度（Effective）：大海捞针、NoLiMa、RULER这类基准测出来的、模型表现开始明显滑坡之前的长度。这是“真正建议放心使用”的上限。 最佳长度（Optimal）：综合了速度、成本、显存、稳定性之后，日常真正该设的那个值。它通常比有效长度还要保守——因为有效长度只回答“模型还读得懂”，没回答“划不划算”“跑不跑得动”。 三层长度往往是层层递减的：标称1M，有效可能只有128K，而落到你的日常使用，最佳长度经常只有32K甚至更低。后面每一节，本质上都是在帮你把“最佳长度”这个数字，套到你的具体场景里去。 二、云端API：按任务场景，不按模型规格 面对一个API，第一反应不该是“这个模型支持多少”，而是“我这个任务该设多少”。按任务类型分场景，给一套可以直接抄的建议： 任务类型 建议长度 为什么 日常聊天 8K～16K 没必要背着几百页历史对话，多背的都是白付费 写作/总结单篇长文 16K～32K 覆盖绝大多数文档，还没进入U形曲线最吃亏的中段 代码Agent 32K～64K 需要跨文件理解，但推理能力和检索能力是两件事，别无脑往上加 RAG检索类任务 64K～128K 真正决定效果的是检索准不准，不是Context开多大——这条对应前一篇讲过的“新模型捞针能力已经不差” 法律/论文/合同/整本书级长文档 128K以上 就算窗口够大，也建议先分章节处理，一次性塞满不如分块问得准 这张表背后有一条硬规律：任务越接近“综合推理”“多步分析”，越不该无脑加长上下文；越接近“从一堆材料里找一个具体的点”，越可以放心用长窗口。这也是前一篇里讲过的机制——长上下文里干扰项越多、格式越相似，模型越容易自信地编答案。加长窗口能扩大你能塞的材料范围，但不会让模型的推理能力跟着变强。 把厂商的收费拐点，当成性价比参考线 2026年两个真实的定价规则：Gemini3.1Pro（即前两篇提到的Gemini3Pro系列）上下文超过200K开始阶梯涨价，GPT-5.5输入超过272K直接翻倍。 这两个数字不只是“厂商想多赚钱”这么简单。标准全量注意力机制的理论计算复杂度随长度平方增长——这是长上下文对厂商算力成本构成实打实负担的根本原因；当然，实际部署中MLA、滑动窗口注意力等架构优化（前一篇讲过的DeepSeek MLA就是典型）能显著降低真实计算和显存开销，但压力并不会被完全抹平，只是被推迟或减轻。厂商选择在哪个长度设收费闸门，某种程度上等于厂商自己交了一份“这个长度开始不划算”的答卷。你不需要知道他们后台的具体成本曲线，看价目表拐点在哪，就知道大概在哪一档之后，性价比开始变差。 需要说清楚的是：这只是一种经验性的判断框架，不是绝对规律——不同厂商的定价还会受市场策略、模型架构差异、竞争态势的影响，同样是长上下文，有的厂商靠架构优化（比如KV Cache本身压缩得狠）扛住了成本，定价就没这么陡。把它当参考线，而不是当铁律。 三、为什么Context越大，不只是变笨，还会变慢 KV Cache那篇算过一笔硬账，这里只提炼成一条因果链，不重新推导： Context↑ → KV Cache↑ → 显存占用↑ → 首字等待时间（TTFT）和生成速度↓ → 本地部署OOM风险↑ 翻译成人话：上下文每往上调一档，模型要保管的“草稿纸”就线性变厚。Prefill阶段（读入你的输入）变慢是因为要把这些草稿纸现算出来；Decode阶段（一个字一个字往外吐）变慢，是因为每吐一个字，都要把这张越来越厚的草稿纸整个翻一遍。云端用户感知到的是“响应变慢、账单变贵”；本地部署用户感知到的是“内存肉眼可见地涨、模型直接加载失败”。 本地部署为什么不能照搬云端的长度设置，答案就在这条链条里。 四、本地部署：显存决定你的上限，不是模型决定 本地部署24GB Mac推理限制模型 云端用户只受“有效长度”这一个约束——模型能力不够，顶多是回答质量下降。本地部署用户要同时扛住两个约束：能力上限和硬件上限，取较小值。硬件上限往往先到。 以一台MacBook Pro M4 Pro、24GB统一内存为例，这是项目里实测过的配置： 模型 量化 24GB Mac下的状态 已验证的上下文设置 Qwen3-32B IQ4_XS / MLX 4bit 临界状态，需要手动把GPU内存上限从默认约16GB抬高到21GB左右，且机器需要专用 先设8192（8K）跑通，验证过可以再往上试16384（16K） Gemma3-27B / Qwen3-27B Q4_K_M 同样临界，比32B多留一点余量 目前没有单独测过具体上限，暂不给精确数字 几个要点： ...

文中价格与行业数据查证于2026年7月，逐条标注出处，所有数字均可在文末溯源。 一、一笔9.2亿美元的月租金 先说一件最近的事。 据24/7 Wall St.今年6月的报道（经Yahoo Finance转载），Google要向SpaceX支付每月9.2亿美元，租用大约11万张Nvidia GPU，合作期从2026年10月持续到2029年6月。这个租金水平，据Dwarkesh Patel在同期一篇博客文章中的测算，大约是这批卡现货价的2倍，而现货价本身，据其文中引用，比2026年2月的低点又涨了40%以上。 如果你只看新闻标题，这条信息很容易被淹没在“存储芯片涨价”“苹果Mac涨价”这类更抓眼球的消息里。但仔细想一下会发现，这条新闻讲的其实是一件不太一样的事：苹果涨价涨的是造一台电脑的成本，Google多付的这笔钱，涨的是租一张已经造好的卡的价格。 一个是硬件采购市场，一个是算力租赁市场。这是两件事。 而与此同时，如果你打开任何一家大模型厂商的API价目表，看到的又是另一个方向的走势——Token调用价格，还在持续往下探底。 三条线，三个方向。把这三条线分别拆开，看看它们各自在讲什么故事，以及它们为什么能同时成立。 二、拆开“算力”这个词——三层价格，三个逻辑 算力价格不是一个市场，而是三个市场 “算力会不会越来越贵”这个问题之所以长期争论不清，是因为很多时候大家讨论的并不是同一个市场。实际上，“算力价格”至少包含三个层面： 层次 近期走势 核心驱动力 硬件采购（芯片/显存） 涨 实物供给稀缺：HBM、DRAM产能被AI数据中心抢占，叠加电力瓶颈 算力租赁（GPU小时价） 涨 头部AI实验室营收增速远超算力供给增速，愿意为确定性支付溢价 Token调用（API单价） 跌 算法效率提升、开源竞争、推理优化持续压低完成同一任务所需的算力 下面按这个顺序，一层一层拆。 三、变贵的第一条线：硬件采购——供给side的实物通胀 这条线的证据链，我在《存储通胀：苹果涨21%、美光毛利80%、华为另起炉灶》里已经详细拆过，这里只做简要回顾。 核心逻辑：多家产业分析和机构研报（Wedbush等，经财经媒体转引）估算，AI服务器对DRAM的需求量约为普通服务器的8到10倍，这轮需求爆发叠加存储厂商主动向HBM倾斜产能，共同推高了价格。据21世纪经济报道今年3月的调查，三大存储厂商已将18%到28%的DRAM产能分配给HBM，且因为HBM良率仅50%到60%、单位容量实际消耗的产能相当于3到4颗标准DRAM，这部分产能挤占的效果被进一步放大；同期TrendForce的预测显示，2026年全球DRAM行业资本支出约613亿美元，同比增长约14%，但三星2026年DRAM产能预计仅增长约5%，扩产速度明显跟不上需求增速。 AI时代，瓶颈从芯片扩展到整个基础设施 电力也在成为新的硬约束。据Gartner今年6月的官方预测，2026年全球数据中心用电量将达到565TWh，较2025年的447TWh增长26%，AI优化服务器的耗电占比将从上一年的约20%升至31%。美国最大电力市场PJM的容量拍卖价格也印证了这一点：据PJM官方公布及IEEFA的整理，2024/25年度的清算价为每兆瓦日28.92美元，到2025/26年度涨至269.92美元，涨幅接近10倍；最新的2026/27年度拍卖进一步涨到329.17美元，触及了监管设定的价格上限。 这一层涨价，本质上和普通商品通胀是同一个逻辑：实物产能扩张需要两到三年周期，需求却是指数级涨上来的，供需缺口短期填不平。 四、变贵的第二条线：算力租赁——需求增速跑赢供给增速 这条线主要素材来自Dwarkesh Patel 2026年7月29日发布的博客《Why compute might get 10x+ more expensive in coming years》。这篇东西本身是作者标注为“两小时速写”的思想实验，不是严谨的预测报告，但里面的一部分证据和推理框架，值得认真对待。 先说最实的一块：文章开头那条Google-SpaceX的租赁交易（每月9.2亿美元、约11万张GPU），是全文唯一一条有具体交易、有第三方财经媒体信源支撑的硬数据。这条信息本身就足以说明，至少在头部实验室需要的那部分算力（不能用现货，要长期锁定、要保证数据安全和利用率）里，价格确实在涨。 作者给出的一个推理框架是这样的：如果头部实验室的营收继续保持年化10倍增长，而算力供给年化只能做到3倍增长（这个3倍的数字，作者引用了Epoch AI一篇关于头部实验室算力使用的分析），那么中间的差额只能靠三件事的组合来填：实验室利润率上升、算力单价上升、推理占算力支出的比例上升。而实验室并不希望第三项主导——如果大部分算力都花在了跑存量模型的推理上，等于变相承认继续投入训练已经不划算了。所以差额主要落在前两项。 3倍这个算力供给增速，作者拆成了三个乘数：摩尔定律贡献约1.4倍，新建晶圆厂贡献约1.2倍（受EUV光刻机设备供应制约，瓶颈预计持续到2030年），AI抢占先进制程晶圆份额贡献约1.8倍（预计2027年底见顶，届时AI将占N3产能的86%，目前约60%）。这三个数字都是作者自己的估算，我没能找到独立的第三方交叉验证，写在这里仅代表这篇博客的推理链条，不代表已核实的行业共识。 接下来这部分数字，需要打个更大的问号：作者提到Anthropic推理毛利率在近两年内出现了大幅上涨，但他自己在原文脚注里明确写这是“total vibe claim”（纯粹凭感觉的说法），不是查出来的实测数据，所以这个具体数字不予采用。倒是可以提供一组真实核实过的替代数据：据《华尔街日报》2026年5月报道（经Axis Intelligence整理），Anthropic的算力成本占营收比例从今年一季度的71美分/美元，降到了二季度的56美分/美元，方向上印证了“规模扩大后单位成本占比在下降”这个判断，但幅度远没有“vibe claim”里暗示的那么夸张。 文章里那个更出圈的“250万美元一张H100”的说法，前提是“如果一张H100真能跑出一个人类水平的软件工程师”，按当前软件工程师市场价，这张卡理论上应该能租到远超今天现货价的水平。这是一个完整的思想实验，但前提必须是AI真的达到了人类水平的工程能力，并且这个能力的边际价值不会因为供给暴增而崩塌。作者自己也承认，这个假设成不成立，目前谁也说不准——这个数字本身没有可核实的经验依据，只是作者论证逻辑的一部分，读的时候需要清楚这一点。 这里有一个值得借用的经济学工具，叫“Alchian-Allen效应”，简单的可以理解为：当一笔固定成本被加到两种不同质量的商品上时，优质品会变得“相对更便宜”，需求会转向优质品。放到算力上理解就是——当GPU小时成本本身已经很贵，用一个能力较弱、需要消耗更多Token才能完成同样任务的模型，反而变得非常不划算。所以效率更高、能力更强的模型，能收更高的溢价，而不是被拖入单纯的价格战。这也是为什么头部模型很可能持续保持定价权，而不是随着通用能力的普及一起被打成白菜价。 五、变便宜的第三条线：Token调用——效率通缩仍在继续 前面两条是涨价的线，这一条来看跌价的。 以第三方定价追踪站PricePerToken.com和TokenCost.app整理的历史数据为锚点（这两个都是聚合追踪各家API定价的独立站点，不是OpenAI官方一手页面，但相互印证、数字一致）：2023年3月GPT-4发布时，每百万Token输入30美元、输出60美元；到2024年5月GPT-4o发布，降到输入5美元、输出15美元。如果以GPT-4发布价作为高位锚点，仅这一次换代就带来了约6倍的降幅，此后价格战仍在持续压低通用Token的价格。 国产大模型这边，据中国信通院的数据（经业内文章转引，未能找到信通院原始报告链接，标注为二手引用），2026年国内大模型API平均价格较2023年下降超过90%，同期性能提升了3到5倍。同时也值得指出一个反直觉的现象：据证券日报今年的报道，2026年上半年海外部分云厂商API价格因为存储和GPU成本上涨反而在涨价，最高涨幅据报道达到463%，DeepSeek却在这个背景下于5月22日宣布旗舰模型V4-Pro永久降价75%——这说明“Token降价”并不是全球统一的必然规律，国内这轮降价更多是市场竞争策略的结果，而不是纯粹的成本下降传导。 这条降价曲线背后的技术支撑，其实已经很熟悉了——MoE稀疏化让每次推理只激活总参数的一小部分；量化和蒸馏压缩模型体积；KV Cache优化能让同样的上下文占用直接减半，这部分逻辑在我之前那篇KV Cache文章里讲过“降税”的比喻；Prompt Caching命中和未命中的价格能相差数十倍甚至更多，据Apifox今年5月整理的中国大模型价格对比，月之暗面Kimi K2.6的缓存命中价低至0.07美元/百万Token。 但这条降价曲线并不等于企业的AI账单在变小。恰恰相反——通用Token价格在探底，企业的AI运营总支出却在膨胀，原因是企业正在从简单问答转向Agent协作、代码生成这类更消耗Token的复杂工作流。这一点可以用Anthropic自己的数字来印证：据Anthropic自己在融资公告中披露（经VentureBeat、Simon Willison等多方转载核实），其年化营收从2025年末的约90亿美元，一路涨到2026年5月的470亿美元，公司自己的原话是“过去三年里，每一年都保持了10倍以上的年化增长”。这条数据同时说明两件事：一是Token价格确实在降，厂商靠规模和效率仍能维持业务增长；二是需求膨胀的速度，远远盖过了降价带来的成本节约。 ...

本文接着「术语解构」系列往下写。前两篇《上下文窗口：标称1M的token，为什么32K就开始变笨》和《KV Cache：每读1个token，就要交一笔“显存税”》，一篇讲的是“标称窗口和有效窗口之间隔着什么”，一篇讲的是“这份窗口最后要占多少显存”。这两个问题都不是这篇要重新论证的，这一篇只问一件事：长上下文值不值得为它多付这份钱。 我们第一次用上1M上下文，大概率都会干一件事：把PDF、聊天记录、代码仓库、会议纪要一股脑塞进去，然后问模型“帮我总结一下”。 这件事很爽，账单也很诚实。问题是模型真的把这1M token都用上了吗？ 这个问题的答案大概率是：长上下文有价值，但它不是智力外挂。它更像一张很大的工作台，能放更多材料，不代表模型会按你的重点全部读完，也不代表中间那张关键的纸不会被忽略。贵不贵，从来不是问题，更重要的是贵得值不值。 一、1M上下文最容易出现的三个错觉 第一个错觉：能塞进去，就等于能稳定用出来。1M token解决的是输入上限，不是注意力分配。它允许你把更多材料交给模型，但模型在这些材料里怎么找、怎么权衡、会不会漏掉中间某个关键证据，是另一件事。规格表上的上下文长度，更像仓库面积；真正决定任务结果的，是模型能不能在这片仓库里找到正确的那只箱子。 第二个错觉：一次性塞完，就更省钱。长上下文的成本不只是在模型变贵时才出现，输入本身就在计费。以发稿前重新核对的OpenAI官方GPT-4.1价格为例：约1M上下文，输入2美元/百万token，缓存输入0.5美元/百万token，输出8美元/百万token。这几个数字保质期短，Token那篇也提过，大概一个季度就可能变。单看一次调用不吓人，30万token材料，未命中缓存的输入成本大约是0.6美元。但如果每天调用20次、每次都带30万token材料，光输入就是600万token，一天12美元，一个月大约360美元。假设每次还输出2000token，一个月输出再加大约9.6美元。这还只是每天20次的轻量用法。Agent场景里，模型可能每一轮都带着几十万token在跑，规划、检索、改写、校验、重试，十几轮之后，这笔钱会变得很具体。长上下文不是不能用，而是别把它当免费内存用。 第三个错觉：needle测试好看，就等于复杂任务可靠。找出资料中的一句暗号，和从几十份合同里判断责任边界，不是一回事。前者像在大海里找一个发光浮标，后者要把定义、例外、补充协议、历史版本、责任条款串起来看。很多模型在简单needle测试里已经很漂亮，但一换成多针、多跳、聚合、冲突判断，成绩就没那么稳了。 二、真正的问题：有效利用率，不是能不能装下 上一篇提到过NoLiMa和RULER这两个基准测试的名字。NoLiMa做了一件很朴素的事：把问题和答案之间的字面重合去掉，只留下需要推理才能建立的关联，比如问题问的是“和某座歌剧院有关的人是谁”，而材料里只写了这个人住在歌剧院所在的城市，没有直接提到歌剧院三个字。这种设计逼着模型真正理解，而不是靠关键词匹配蒙对。 标称上下文 vs 有效利用率 结果是，论文测试的一批声称支持128K以上上下文的模型里，短文本（1K以内）表现都不错，但随着上下文变长，表现明显下滑。在常被引用的原始结果里，GPT-4o从短文本几乎满分的99.3%，掉到32K时的69.7%。NoLiMa后续公开结果又加入了GPT-4.1等模型，个别模型的排名和数字会变化，但主线没有变：长窗口标称长度越大，越需要单独评估有效利用率，不能只看规格表。 RULER则是从另一个角度补刀：不满足于“找一根针”，而是让模型同时找多根针、做多跳推理、再把结果聚合起来。它的评测里能看到，模型在简单needle测试里可能接近满分，但换成更接近真实任务的组合检索后，表现会随着上下文变长出现明显下滑。 这两组测试合起来看，32K还不到1M窗口的十分之一，但在更难的评测里，很多模型已经明显掉分。窗口越做越大，只是把能装下的上限往后推，并没有同步把能认真读完的能力往后推。所以长上下文真正要问的不是“最多能塞多少”，而是关键证据放在材料的第70%位置时，模型还能不能稳定找到它、用对它，并且解释清楚它为什么重要。 三、什么任务是真需求 材料天然长、需要跨位置对照。合同审查是最典型的例子，A处定义了一个概念，B处写了例外情形，C处的补充协议又悄悄改过一次，最后还要结合邮件往来才能判断责任边界。这几处往往不在同一页，却要放在一起看。招股书比对、长会议纪要复盘、论文综述，这些任务都是同一类问题。重点不是总结某一份文档，而是把散落在全篇不同位置的线索串起来。 代码仓库可以归进这一类，但有一个边界值得记住：长上下文模型在小型、结构良好的代码仓库上，表现可以匹配甚至超过检索式方案；但当仓库规模和复杂度增加，检索式方案的优势就会逐渐显现出来。换句话说，几万行、结构清楚、依赖关系不复杂，长上下文可能很舒服；一旦变成多语言、多服务、历史债务很重的大仓库，直接一股脑全塞往往不如先把相关文件和调用链找出来。 不能提前知道哪段有用。事故调查、内部审计、客服历史追踪，这类任务都属于，你没法提前判断关键线索藏在哪一轮对话、哪一条日志、哪一次提交里。这种情况下，先做检索反而可能把真正相关的那段筛掉，给模型更完整的现场，是更保险的做法。 材料结构稳定、可以缓存复用。固定的代码库、固定的知识库、固定的产品文档，长上下文配合前缀缓存，天生适合“同一批材料反复问不同问题”。这时候的成本结构，和每次现查现搜完全不一样。Prompt Caching那篇里算过一个例子：固定的角色设定和规则放前面、每天变化的数据放后面，缓存命中率能跑到97%以上，账单直接压缩十几倍。这种场景下，长上下文的贵，其实被摊得很薄。 多模态长材料。长视频、长音频、扫描件这类材料，切片处理最容易丢掉时间线和跨片段的关联。比如一场两个小时的会议，前40分钟有人提出了一个约束条件，后面又绕了几轮，最后才落到行动项。如果只按时间切成小段分别摘要，模型很容易把前后这层因果关系拆散。长上下文在这里的价值，是让材料按原本的时间线和结构留在一起。厂商演示里经常会展示长视频、长音频里的针检索能力，但这块公开测试没有前面几类那么扎实，先按“值得一试、但别只信演示”的态度看待。 四、什么是伪需求 长上下文：真需求 vs 伪需求 把不会整理材料，包装成需要1M上下文。问题其实只需要三段证据，却把三百页全塞进去问模型“你自己找”。模型可能找对，也可能找错，而且找错了你更难复查，因为你自己都没读过这三百页，拿什么去核对它的答案。这和KV Cache那篇讲过的道理是一回事：新草稿要记状态，不要抄流水账。懒得筛选材料，只是把筛选的责任和风险，一起转嫁给了模型。 把长期记忆误认为上下文窗口。上下文是这一次请求模型能看到的材料，不是可靠的记忆库。真正靠谱的长期记忆，应该有索引、有来源、有更新时间、能处理信息冲突，而不是靠一个聊天窗口越拖越长，指望模型自己记住三个月前说过的话。窗口能装下不等于记得住，这两者是完全不同的工程问题。 把低质量材料越堆越多。重复的、过期的、彼此矛盾的材料堆得越多，模型越容易给出一个看起来面面俱到、实际上是和稀泥的答案。长上下文不会替你清洗数据，材料的质量问题，不会因为窗口够大就自动消失。 简单任务硬上长窗口。分类、改写、短摘要、单文档问答、结构化抽取，这些任务本来就不需要模型读很多，短上下文加检索通常更便宜、更快、也更容易复查。 五、怎么判断自己该不该为长上下文买单 先窄化，再长上下文推理 可以用四个问题来排查： 关键证据是不是可能分散在材料的很多个位置？ 答案是不是必须能引用原文、保留来源出处？ 这批材料会不会被反复使用，而不是问完就扔？ 错一次的代价高不高，值不值得多花钱换一次更稳的判断？ 四条里只中一条，先别急着上1M；中了两三条，可以考虑；全中了，长上下文才是一笔正经投入。 落地的时候，更稳的流程是：先用检索或规则把材料粗筛一遍，收窄到候选片段，再把这些候选片段放进长上下文让模型做深度推理，输出时要求模型标注引用的具体位置，关键任务再做一轮反查校验，把结论倒回原文核对一遍。这不是把检索和长上下文硬凑在一起，有专门的对比研究发现，资源足够时长上下文模型整体表现更强，但检索式方案的成本优势明显，而混合方案能在接近纯长上下文效果的同时把计算成本压下来。放到实际工程里，就是别让模型一上来就读全量材料，也别指望检索一步到位。先窄化，再推理，最后反查，这条链路更像人做严肃审阅时的工作方式。 长上下文不是越贵越好，也不是越长越聪明。它值不值，取决于你有没有把它用在真正需要全局材料的任务上。 如果只是懒得筛材料，1M上下文只会让你更快地把钱花出去；如果任务确实需要跨文件、跨时间线、跨证据链地判断，它才真正开始值这份钱。 窗口大小是能力上限，不是使用说明书。 资料来源 NoLiMa: Long-Context Evaluation Beyond Literal Matching（arXiv 2502.05167）：arxiv.org/abs/2502.05167 NoLiMa公开结果表，用于核对GPT-4.1、GPT-4o等模型数字：github.com/adobe-research/NoLiMa RULER: What’s the Real Context Size of Your Long-Context Language Models？（arXiv 2404.06654）：arxiv.org/abs/2404.06654 Retrieval-Augmented Code Generation综述，代码仓库规模与RAG/长上下文选择的发现（arXiv 2510.04905）：arxiv.org/pdf/2510.04905 Retrieval Augmented Generation or Long-Context LLMs？ 混合方案SELF-ROUTE研究（arXiv 2407.16833）：arxiv.org/abs/2407.16833 OpenAI GPT-4.1官方定价与参数页：developers.openai.com/api/docs/models/gpt-4.1

参数名称、默认值截至2026年7月核对。思考控制机制这半年迭代较快，如果你按本文操作，建议先去对应模型的官方文档确认一遍当前版本的参数是否还是这个名字。 上一篇讲token价格梯队时，提过一句“看不见的思考token也在计费”。 一、一个真实的踩坑现场 2026年4月，OpenAI开发者社区里有人发帖求助。发帖者在调用GPT-5.4时，传了reasoning_effort: "none"，想关掉思考模式——单独测试时这个参数确实有效，思考token归零。但当他在同一个请求里加上max_completion_tokens这个参数后，reasoning_effort的设置被API整体忽略，模型照常进入思考模式，把整段预算全部花在了看不见的推理过程上，最后返回一个空字符串，finish_reason标记为length`。 翻译一下这意味着什么：你以为自己关掉了思考模式，账单却按开着算；你以为请求会给你一个答案，实际上连答案都没能生成，钱已经被思考过程花光了。 这是社区里真实的bug反馈帖[1]。之所以拿它开头，是因为它把这篇文章要讲的核心问题，用一次意外浓缩到了极致：思考token的计费，和你看到的可见文本，从来不是一回事。 二、先把机制讲清楚：你看不见，不代表没生成 看不见，不代表没生成 推理模型（OpenAI的o系列和开启reasoning_effort的GPT-5.x、Google Gemini的Thinking系列、Claude开启thinking参数后的模型）在给出你看到的那句回答之前，会先生成一段内部的“草稿”——业内把这部分叫reasoning tokens或thinking tokens。 关键在于三点： 第一，这段草稿本身也是token，一个一个生成出来的。 它不是模型“想了一下”这么抽象的说法，而是实打实占用计算、实打实计入用量的一段文本，只是大多数平台默认不把它完整展示给你。 第二，计费按的是完整生成量，不是你看到的展示量。 Claude的官方文档写得很直白：即使思考内容被折叠、不返回给用户，依然要按内部实际生成的thinking token数计费——你在响应里看到的字数，和账单上算的输出token数，本来就不是同一个数字[2]。 第三，思考token和最终答案，被算进同一个“输出token池”，按输出价计费。 这意味着模型越贵，“多想一会儿”的每一秒都是按这个模型最高的单价计时——这也是“思考税”这个说法的字面来源。 举个例子方便理解（注意，这是一个用来说明比例关系的示意性推算，不是某次真实调用的实测数据）：假设一次问答，你看到的可见回复只有300个字左右，但模型在给出这句话之前，内部生成了3000个思考token，那么这次调用真正被计费的输出量，大概是3300个token左右——你以为自己在为300字付钱，实际上在为3300字付钱，多出来的十倍，你一个字都没看见。 三、四种翻车方式：钱是怎么被“偷偷”吃掉的 思考税的四种翻车方式 思考税不是一种统一的坑，至少有四种不同的发生机制，前三种都能找到具体的真实案例。 机制一：预算耗尽型——思考吃光配额，答案直接消失 有开发者用GPT-5-mini搭配web_search_preview工具，把max_output_tokens设成了8000，结果依然频繁收到“不完整”的响应。原因是模型把大部分预算花在了思考和搜索调用这两件事上，留给最终JSON输出的token所剩无几[3]。 这暴露的问题很实际：工具调用和思考模式叠加时，预算消耗的速度比单独用思考模式快得多，如果还按“平时够用”的老经验设预算，很容易在这种组合场景里翻车。 机制二：开关失灵型——你以为关了，其实没关 Qwen3.6-35B-A3B有开发者在Hugging Face反馈，设置thinking_budget试图限制思考长度，但实际不起作用[4]；另一份GitHub issue里，有人本地部署Qwen3-14B，同样遇到无法关闭思考模式的问题[5]。 这里有个更容易被忽略的细节：Qwen的开源版模型，enable_thinking参数默认是True；只有部分商业版模型默认是False。也就是说，自己部署开源模型时，如果没有显式传参把思考模式关掉，它很可能一直是开着的——这和你调用商业API时的默认体验，可能完全相反。 机制三：习惯性无感型——两周后才发现的账本 有人在一篇复盘文章里提到，自己跑了两周的代码审查流水线，直到某天去查用量明细里的output_tokens_details.reasoning_tokens字段，才发现每次审查平均生成了约8000个推理token，只为了产出一段大约300字的可见结果[6]。 这类翻车最普遍，也最值得普通用户警惕——不是被平台坑了，是从来没有专门去看过那个隐藏字段，任务一直在跑，账单一直在涨，直到某次心血来潮翻明细才发现。 机制四：累加型——Agent的每一步都在重新“动脑子” 前三种机制，都是单次调用里的问题。Agent场景不一样：读一份文件要判断一下，调一次工具要判断一下，看到工具返回结果要再判断一下，写完代码要判断能不能跑，测试失败还要判断怎么改。 如果每一步都开着思考模式，隐藏token就在跟着每一次决策不断累加。单次调用看着不大，循环几十次之后，滚成的费用就很可观了——Agent的成本，不只来自上下文变长，还来自每一轮决策都在重新计费的“动脑子”。 四、什么样的问题特别容易变贵 拆开看，容易在思考token上多花钱的，通常是这四类： 判断题伪装成简单题。 “这是不是高风险客户”“这段代码有没有安全漏洞”，问题看着是个是非题，但判断过程可能要在内部比对好几条规则、排除好几种歧义，答案短，思考不短。 开放任务。 “帮我优化这篇文章”“重构一下这个模块”，模型不知道优化到什么程度算够，容易在内部反复权衡，多想一轮又一轮。 长上下文任务。 合同、代码库、财报，输入本身就长，模型除了要读完，还要在里面定位关键线索，这个过程本身会拉长思考。 带工具的任务。 每次工具结果返回，模型都要重新判断下一步该怎么走，思考token跟着工具调用次数一起叠加。 落到判断上：这些任务不是不能用推理模型，而是不能默认开最高档去处理。 不同模型，同一个问题：思考上限要显式设置 五、六家怎么设上限：一张对比表 各家的参数名不一样，但机制是相通的：都有一个字段控制思考深度，都建议按任务复杂度显式设置，而不是用默认值糊弄过去。 厂商/生态 控制参数 默认行为 能否完全关闭思考 OpenAI（GPT-5.x / o系列） reasoning.effort（none / low / medium / high / xhigh，具体档位视模型而定） GPT-5.1起默认none，需显式开启 部分模型可以，但max_completion_tokens同传时曾出现开关被忽略的bug Anthropic（Claude） thinking.budget_tokens（旧）→ 新模型迁移为自适应effort 默认关闭，需显式启用 可以，不传thinking参数即可 Google Gemini 2.5系列用thinkingBudget（0关闭，-1动态）；3/3.1系列改用thinkingLevel（low/medium/high） 不显式指定thinkingLevel时，Gemini 3/3.1 Pro默认走high，也就是最贵的一档[7] 2.5系列可以关闭；3系列不可完全关闭，最低只到low 阿里Qwen（DashScope/开源） enable_thinking + thinking_budget 开源版默认True，部分商业模型默认False 可以，但需按版本核实默认值 智谱GLM thinking: {type: "enabled"}（原生API）/ enable_thinking（兼容接口） 需显式启用 可以；官方文档明确写着“思考模式下，思维链按照输出Token计费”[8] DeepSeek 随模型别名路由（如推理专用别名） 思考模式绑定模型别名，非逐次开关 需换用非推理模型别名 这张表里最值得单独说一句的，是Gemini这一条。Gemini 3.1 Pro相比上一代，把思考档位从两档（low/high）扩成了三档（low/medium/high），控制粒度确实变细了；但如果你没有显式传thinking_level，API默认会走high，也就是最贵的那一档。这意味着很多什么参数都没改、只是升级了模型版本的老代码，可能在悄悄地多花钱——这条比“能不能关闭”更值得写进你的检查清单。 ...

价格数据核对时间：2026年7月下旬。文中价格以官方定价页为准，第三方转述的地方我会单独标注。 一开始我以为这篇会写成“模型又便宜了几倍”。真把几家官方价格页翻完，结论反而没那么顺口：最强的那几档没有一路降价，有的主力模型输入价还在往上走。便宜得更明显的，是平时真正拿来写代码、跑客服、做摘要、批量处理文档的那一层。 不是所有模型都便宜了，是能干活的中间档位在往下沉。 过去一年，价格变化最集中的地方不在旗舰档，而在主力档、性价比档、缓存命中和批处理。也就是说，模型厂商没有简单把“最强模型”打折甩卖，而是把更便宜的入口拆得越来越细。 一、先看两张价格表 看价格表之前先统一口径：美元/百万token，输入/输出，不混人民币，不混包月订阅。表里优先用官方API列表价；如果是第三方聚合平台或媒体口径，会在后面单独说明。选型也定一条规则：每家只放它当前最常被开发者拿来干活的那一档，不拿旗舰去对标别家的性价比档，也不拿性价比档去对标别家的旗舰档。 表1：主力档，一年对比 厂商 一年前（2025年7月） 现在（2026年7月） 变化 Anthropic Claude Sonnet 4，$3 / $15 Claude Sonnet 5，首发价$2 / $10（8月31日后回到$3 / $15） 优惠期名义上降了约三分之一，但新tokenizer会让同样文本切出更多token，官方口径约多30%，实际省钱幅度要打折扣 OpenAI GPT-4.1，$2 / $8 GPT-5.6 Terra，$2.5 / $15 输入涨25%，输出涨近一倍 Google Gemini 2.5 Pro，$1.25 / $10 Gemini 3.1 Pro，$2 / $12 按当前价格算，输入涨60% DeepSeek DeepSeek V3，$0.27 / $1.10 DeepSeek V4-Pro，$0.435 / $0.87 输入涨61%，输出降21%，两头打平 表2：性价比档，一年对比 厂商 一年前 现在 变化 OpenAI GPT-4o mini，$0.15 / $0.60 同一型号仍在售，价格没动过 两年持平 Google Gemini 2.5 Flash-Lite，$0.10 / $0.40 Gemini 3.1 Flash-Lite，$0.25 / $1.50 涨150%～275% DeepSeek 一直是$0.14 / $0.28 还是$0.14 / $0.28 两年零变化 阿里 Qwen Plus，约$0.26 / $0.78（第三方聚合平台低价口径） Qwen3.7 Plus，$0.40 / $1.60（官方国际区，256K以内） 官方Plus档位抬高，但不同地域和渠道价差很大 模型价格没有一起下降，真正变化的是价格结构 “性价比档”这个名字听起来该一路走低，但表2里Gemini Flash-Lite反而是涨幅最大的一行。阿里的情况也要小心看，官方国际区、国内区、香港/美国节点、第三方聚合平台的价格并不完全一样，不能只拿最低渠道价当成全网统一价。 ...

先算两笔账。 同样是2000输入token加1000输出token的一次对话，跑500次： 用DeepSeek V4 Flash（输入0.14美元/输出0.28美元每百万token），成本约0.28美元。这时候如果某个应用收你$20/月，账面上就是71倍。 换成Claude Sonnet 5（首发价输入$2/输出$10每百万token），同样规模500次约7美元。这时候$20/月只是不到3倍。 同一句“10倍”，参照系不同，结论能从“离谱”摆到“合理”。这也是这篇文章想讲清楚的第一件事：判断一个AI应用贵不贵，不能只看倍数，要看它到底在用哪个价位的模型，以及这10倍里，哪些是看得见的产品成本，哪些是看不见的加价。 一、中间商加价链条：应用卖的不是一层API 先把这条链条从良性到恶性拆开看，不要一上来就骂“套壳”。 合理的那一层：产品能力叠加 模型API成本只是底层。上面还压着模型路由、并发池、失败重试、内容审核、RAG检索、文件解析、联网搜索、多模态工具、账单系统、客户端开发，最后还有支付通道和应用商店抽成——Apple标准佣金30%，小型开发者计划下，符合上一日历年App收益不超过100万美元等条件的开发者佣金可降到15%；Stripe美国本土卡标准费率是2.9%+30美分。这些都是真实存在、写在合同里的成本。 拿两个真实产品对照： Cursor卖的不是“转发一次对话”，是Agent能力、云端代码库理解、多模型路由——Pro $20/月、Pro+ $60/月、Ultra $200/月（2026年7月定价），价格分层对应的是包含的模型调用额度和优先级，不是纯粹的转发差价。 TypingMind是另一个方向的例子：一次性买断前端功能（Standard档一次性$39，终身授权；更贵的Extended档$79、Premium档$99解锁多模型面板等更多功能），API费用你自己用自己的key去付。这个模式很适合拿来对照——它把“应用费”和“模型费”彻底切开了，你能清清楚楚看到自己到底为界面和功能付了多少钱，用得越多，$39这个门槛摊得越薄。 AI应用加价链条 渠道成本产生的加价：国内的“中转站”生态 国内接大模型API，渠道选不同，价格差距是真实存在的，但多数属于走量折扣、支付便利和接入服务，不一定是欺诈。因为这类中转站价格变动很快，不适合引用几个月前的单一评测价。更稳妥的是看机制：如果渠道方明示模型、单价、发票、服务条款和可用性边界，价差通常属于商业服务；如果它不说明底层模型，还把低价模型包装成旗舰模型，就进入了后面要讲的风险区。 恶性的那一层：套壳与模型偷换 这一层的数据扎实到值得单独拎出来讲。 软件工程师Teja Kusireddy用三周时间逆向了200家拿到融资、公开宣称“自研AI”的创业公司，监控网络流量、反编译JS打包文件、比对API指纹。结果：73%的公司实际是套壳。 最典型的案例：一家号称“革命性自然语言理解引擎”的公司，融资时讲了23次“自研模型”，反编译后发现全部技术含量就是一个系统提示词——“请假装你不是GPT-4”。他们的真实成本约每次查询0.033美元（GPT-4 API输入0.03美元/千token、输出0.06美元/千token，平均一次查询500输入+300输出token），对用户收费每次查询2.50美元，或者$299/月200次——收入约为直接模型成本的75倍。 RAG套壳的情况更夸张：嵌入模型用OpenAI的text-embedding-ada-002，向量库用Pinecone或Weaviate，生成用GPT-4，全部原样调用第三方服务，包装成“先进神经检索+自研嵌入模型”。实际成本约0.002美元/次查询，用户实际支付0.50到2.00美元/次——收入约为直接成本的250到1000倍。调查里200家公司中，真正从零训练模型的只占7%。 这还只是消费级应用。学术界的情况更让人意外。CISPA亥姆霍兹信息安全中心的论文《Real Money, Fake Models: Deceptive Model Claims in Shadow APIs》（arXiv 2603.01919）追踪了17个被称为“影子API”的第三方代理服务，发现它们已经被引用进187篇学术论文，其中116篇（62.03%）发表在同行评审会议或期刊，包括ACL、CVPR、ICLR等。论文揭露了三种经济欺骗手段： 信息溢价：收旗舰版的钱，用能力相近但更便宜的旧版本模型顶替——某API标榜提供Gemini 2.0早期版本，实际用2.5版本的价差超过7倍来牟利 折扣替换：原价收费，后台把闭源大模型换成开源小模型——用户高价点名要GPT-5，指纹识别却发现后台跑的是GLM-4-9B 加价倒卖：在前两者基础上再加一层服务费 经过换算，在GPQA的1273次请求口径下，用户按官方标准费率约支付14.84美元，但实际拿到的等价token价值只有5.70到7.77美元——中间商在这个差价里就能赚走过半利润。 这节的结论：同样一句“加价10倍”，产品能力叠加是合理的（Cursor这类），渠道成本是可以理解的（国内中转站几倍以内），但套壳偷换模型这层，价差可以从75倍一路飙到上千倍，这已经不是“贵”，而是欺诈。 二、怎么判断一个AI应用是不是在割韭菜 给两套检查清单，一套给普通用户，一套给要认真评估的开发者/采购方。 普通用户能自己做的5件事 它是否说清楚具体模型版本。只写“顶级模型驱动”、“GPT级智能”而不说具体模型名和额度规则的，要多留心。 它是否说清楚额度口径。“无限使用”通常不是无限token，看有没有每日限额、高峰降级、慢速队列、积分过期这些细则。 它是否把基础转发包装成高级能力。如果只是转发一次对话，却收费接近专业工具的价格，又没有项目管理、文件解析、协作、历史管理这些配套，这个溢价就站不住。 是否存在未明示的模型降级路由。你以为一直在用旗舰模型，实际大量请求被悄悄路由到便宜模型——这不一定是坏事，但应该被告知。 是否有同类的BYOK方案可对照。允许你自带API key的工具（比如上面提到的TypingMind），最容易照出“前端功能”到底值多少钱，因为模型那部分的钱是你自己直接付给厂商的。 更直接的技术侦查（来自Teja Kusireddy的调查方法） 打开浏览器DevTools的Network标签，跟应用的AI功能互动，看有没有直连api.openai.com、api.anthropic.com——中间可以加一层业务逻辑，但AI能力本身不是它自己的。响应延迟也是一个信号：官方API的延迟通常稳定在一个区间，套壳中转站的延迟经常剧烈抖动。网页源码里搜一下有没有系统提示词残留的关键词，比如“永远不要说自己是OpenAI”这类指令。营销语言也是一个粗筛：具体的技术术语大概率是真的，“先进AI引擎”“智能核心”这类模糊词往往在掩饰什么都没有。 面向开发者/企业采购的审计标准 如果是要给生产环境或研究工作流选API，CISPA论文给出的审计协议值得参考：用LLMmap之类的指纹识别工具，通过输出的余弦距离比对判断模型真实身份——论文实测显示，被测的24个模型端点里，45.83%直接未通过指纹验证，另外12.50%表现出与官方模型的巨大偏差，合计过半的“影子API”偷换了底层模型。在高风险任务上验证更直观：官方Gemini-2.5-flash在MedQA医疗基准上准确率83.82%，影子API平均只有36.95%。这不等同于真实医疗诊断表现，但在该基准上已经显示出明显能力缺口。论文给出的最低审计门槛是：至少24次指纹探测、500样本分布测试比对p值、多次独立会话检查延迟和方差是否异常。 三、词膨胀现象：为什么应用的真实成本比你想的大 用户一句话背后的词膨胀税 前两节讲的是纯利润，这一节讲一笔真实存在、但用户从来看不到的成本。 你看到的是一句简单的提问，模型看到的可能是：系统提示词、角色设定、工具定义、历史对话、上传文件摘要、检索片段、格式约束、审查规则，最后才是你那句话本身。这层膨胀不是应用方故意坑你，而是为了让通用模型套上产品人设、遵守话术规范、能调用一堆功能，必须付出的真实代价。 这个现象在学术界有正式名字——prompt bloat（提示膨胀）。论文《RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation》（arXiv 2505.03275）专门研究了这个问题：当一个应用能调用的外部工具越来越多，把所有工具描述一次性塞进提示词，会导致模型在一堆干扰项里越来越难找到正确的工具——这个现象和“大海捞针”测试是同一个机制，工具池越大，选对工具的准确率下降得越明显。论文设计的检索增强方案，只把和当前任务相关的工具描述注入提示词，实测能把提示词token减少约49%，同时把工具选择准确率从13.62%提升到43.13%，提升超过3倍。反过来说，没做这个优化的应用，光是“膨胀”这一项就在吃掉将近一半的无效token——这些token你不会看到，但每次调用都在计费。 ...

前两篇分别拆了缓存怎么算钱（《同一份材料，为什么第二次交给AI只收1/10？缓存计费拆解》）和这笔钱到底省在哪张显存上（《KV Cache：每读1个token，就要交一笔“显存税”》）。这一篇把两条线合到一起——问题往往不出在缓存机制本身，而出在你喂给缓存的那份提示词，正在悄悄变胖。 一、系统提示词正在膨胀 很多团队的系统提示词，都是这样长起来的。 一开始可能只有一句话：你是一个专业助手，请按用户要求完成任务。后来慢慢补角色设定、输出格式、禁用事项、工具说明、异常处理、合规边界、历史经验、项目背景、风格要求。半年下来，这句话变成了一份几千字的说明书。 系统提示词是怎么变胖的 看起来很专业，像是把模型管住了。问题是，这些字每一轮都要进上下文，每一轮都可能被计费，每一轮也都可能影响缓存命中。 这不是错觉，而且不是哪一家的孤例。 Anthropic在2026年4月30日发过一篇官方博客《Lessons from building Claude Code: Prompt caching is everything》，作者Thariq Shihipar是Claude Code团队成员。他复盘了几个具体翻车案例：曾经把一个很详细的时间戳放进静态系统提示词，曾经让工具定义的排序变得不稳定，还改过工具参数（比如Agent工具可以调用哪些子Agent）——这些看似很小的改动，都破坏过缓存。这条材料很硬，因为不是外部用户猜测，而是做Claude Code的人自己说的。 用户侧也能看到类似现象。anthropics/claude-code的一个GitHub issue（#45188）里，有用户报告Claude Code在2.1.89到2.1.96版本之间，首次缓存创建量从约38-52K token涨到112-119K token，5天左右涨了约7万token。作者说这让可用上下文明显变小，多步任务还没跑完就要频繁手动/compact。他还做过排除法：关掉自定义hook、拔掉候选MCP、删掉过期插件，重新测量体积都没变——说明这次膨胀来自版本本身的迭代。这是一条用户实测个案，不是Anthropic官方确认的数字，引用时需要标清楚。 OpenAI Codex的用户也报告过类似现象（issue #19212）：只问一句“2+2等于几”，就消耗了约1.3万token。他让Codex自己估算这些开销来自哪里，得到的拆解是：系统指令、网页浏览策略、编码风格开发指令、工具schema、以及AGENTS.md和环境上下文。这同样是用户观察，不是官方统计，但说明一件事：Agent类产品的系统开销，很大一部分发生在用户输入第一个字之前。 这不是单一厂商的问题，而是Agent工作流的共同代价。OpenRouter联合a16z在2025年12月发布的实证研究《State of AI: An Empirical 100 Trillion Token Study with OpenRouter》（Aubakirova等人，arXiv:2601.10088）分析了平台上超过100万亿token的真实调用数据，其中一个发现是：平均提示词长度从约1,500token涨到超过6,000token，涨幅接近4倍，驱动因素是工具调用和多步推理这类智能体工作流的兴起。这条数据来自OpenRouter平台的真实流量，是一手实证研究，但样本边界是“OpenRouter平台”，不代表全行业所有调用场景，引用时应保留这个限定。 膨胀本身不一定是错误。真正的问题是，很多膨胀不是因为任务变复杂了，而是因为大家习惯把所有东西都塞进同一份不断变化的系统提示词里。 二、膨胀为什么会拖累缓存 要理解膨胀为什么烧钱，得先理解Prompt Caching到底在缓存什么。 Claude官方文档写得很清楚：缓存层级是tools→system→messages，某一层发生变化，这一层以及它后面的所有层都会一起失效。也就是说，工具定义一变，系统提示词和后面的对话历史都可能要重算；系统提示词一变，后面的对话历史缓存也会被连带打掉。 缓存不认“差不多一样”，只认前缀是否逐字节一致。前面动一个地方，后面内容再长也要重新处理一遍。这时候，系统提示词越胖，一次失效的代价就越大：如果你把当前时间、随机trace、用户ID这类临时信息塞进了本该稳定的前缀里，这个前缀每一轮都不一样，缓存自然吃不到，模型还要反复处理这段越来越胖的上下文。 Prompt Caching 只认稳定前缀 更麻烦的是，缓存写入本身也不是免费的，而且这件事正在变得更贵。Anthropic的写入计费是：5分钟有效期收标准输入价的1.25倍，1小时有效期收2倍，只有命中读取才是0.1倍。而OpenAI在2026年7月9日GA的GPT-5.6系列上，第一次对缓存写入收费——同样是标准输入价的1.25倍，最短缓存生命周期30分钟。更准确地说，OpenAI在GPT-5.6系列开始把缓存写入单独计价；Anthropic侧则早已把5分钟写入、1小时写入和缓存读取分成不同倍率。两边的共同信号是：缓存失效不再只是性能问题，而是可以在账单字段里被直接看见的成本问题。 膨胀还会拖慢响应。前一篇《KV Cache》讲过，模型处理请求分Prefill和Decode两个阶段：Prefill阶段要把完整输入过一遍、把每个token的K和V算出来存好，这一步耗时随输入长度增长；命中缓存时，这一整段Prefill会被直接跳过。NVIDIA NIM的官方基准测试文档里也确认了同一个规律：提示词越长，首字延迟（TTFT）通常越高，因为注意力机制要先处理完整输入、建立好KV缓存，才能开始生成第一个token。用户看到第一个字之前，模型已经先读了一大堆前文——这笔延迟账，跟token计费账是并行发生的两笔账。 一个量级参照：Claude Code官方博客提到，一次100轮的Opus长会话，不靠缓存要花50-100美元输入token费用，靠缓存能压到10-19美元，差距接近5倍。这个量级基本就是“膨胀又频繁失效”和“精简且稳定命中”之间的现实落差。 长上下文还有一重更隐蔽的代价：不一定让模型变聪明。Chroma Research 2025年7月发布的论文《Context Rot: How Increasing Input Tokens Impacts LLM Performance》测试了18个主流模型（含GPT-4.1、Claude 4、Gemini 2.5、Qwen3等），发现即便是很简单的任务，模型表现也会随输入变长而下降，而且这种下降不均匀、因模型而异，跟“待检索信息在上下文里的位置”“是否存在语义相似的干扰内容”这些因素都有关系。换句话说，“模型看得到”和“模型能稳定用好”不是一回事——这也是很多Agent跑到后半程会变得犹豫、绕路、反复确认的原因之一：上下文还在，有效上下文已经被稀释了。 三、怎么写“缓存友好”的提示词 原理和坑都清楚了，落地按优先级排。 ...

你可能遇到过这种情况：让一个Agent改个bug、整理一份竞品资料，或者帮你写一篇文章。你只发了一句话，等账单出来，却发现费用比想象中高很多。 这通常不是平台多算。你看到的“一句话”，在后台已经变成了几十次模型调用。Agent要先理解任务，再查资料、读文件、调工具、看结果；发现不对，还要回头改；改完再跑一遍验证，最后才把结果总结给你。你发出去的是一句话，它执行的是一串来回。 更麻烦的是，Agent自己也很难提前估准这次任务会花多少钱。密歇根大学、斯坦福大学等团队做过一个实验：让Agent动手前先估算自己接下来会用多少token。结果不管换哪个模型，估出来的数字普遍低于实际消耗，预测值和真实值的相关性最高也只有0.39。这笔账连模型自己都很难算准。 这篇文章想讲清楚三件事：Agent的token到底花在哪，为什么它天然比普通对话贵得多，以及一条真实Agent任务的账单拆开后长什么样。 一、先看懂账单里的四个科目 一次API调用里的四类Token 在讲Agent为什么贵之前，先把账单里的几个科目认清楚。不管是OpenAI还是Anthropic，API返回的用量数据里，token通常会拆成几类： input tokens：你喂给模型的上下文，包括系统提示词、历史对话、工具返回内容 output tokens：模型生成出来的内容 reasoning tokens：部分模型在回答前用于内部推理的token，你看不到内容，但通常按输出token计费 cached tokens：命中缓存的重复上下文，单价比普通input低 这些都会出现在每次API调用返回的usage元数据里，是追踪用量和拆账的基本单位。 有个细节很容易被忽略：只要请求里带了tools参数，账单的起点就已经变了。费用不一定等到工具真正调用之后才发生，工具定义本身就会进入请求上下文。哪怕这一轮模型最后没有调用任何工具，这部分内容也可能已经算进input。 Anthropic文档里有个很直观的例子。Claude Sonnet 5只要请求里传了tools，就会多出一段tool use system prompt。如果tool_choice是auto或none，这段是354个token；如果是any或tool，也就是强制模型调用工具，这段会变成474个token。这类费用写在官方文档里，只是很多人在估Agent成本时不会把它算进去。 二、Agent贵在反复读上下文 Agent比普通对话贵，核心原因是它常用的ReAct模式，也就是思考、行动、观察循环。这个循环有个很要命的特点：每一轮都要把前面的历史重新塞回上下文。上一轮的推理过程、工具调用记录、工具返回结果，都会跟着进入下一轮输入。 拆开看，大概是这样： 规划阶段，模型要读任务描述、约束条件和项目背景，先判断从哪里下手。这一步还没真正动工具，但已经开始产出推理和计划。 工具调用阶段，工具定义、调用参数、执行结果都会进入上下文。工具返回的内容不是读完就结束，它会变成下一轮input的一部分。 反思和重试阶段，失败日志、测试输出、之前试过的路径又会被喂回模型。排查越久，历史越厚，下一轮输入就越贵。 Agent贵在反复读上下文 密歇根大学、斯坦福大学等团队基于OpenHands框架，跑了SWE-bench Verified里的真实编程任务。实验覆盖8个前沿模型、500个任务，每个任务独立跑4次。结果很夸张：Agentic Coding任务平均消耗约417万token，是单轮代码推理任务的约3500倍，是多轮代码聊天任务的约1200倍。输入输出token比例达到153.85，也就是模型每生成1个输出token，平均要读153个输入token。普通多轮代码聊天的这个比例只有1.33。 Agent贵，主要贵在模型读得多。历史上下文越滚越厚，账单里最大的一块也跟着越滚越大。 如果再叠上Plan-and-Solve这类架构，成本还会继续放大。它会先生成一份多步计划，再逐步执行每个子任务；而每个子任务里，又可能各自跑一轮完整的ReAct循环。看起来只是任务拆得更清楚了，账单上却可能变成循环套循环。 三、一条真实轨迹里，钱花在了哪几轮 说“Agent会滚账单”还不够，直接看一条真实轨迹更清楚。 还是上面那篇研究，里面公开了一条任务轨迹：任务编号astropy-7336，用Claude Sonnet 4.5跑，一共31轮才完成。研究者把整条轨迹按功能分成五个阶段： 阶段 对应的工作 占总轮次 Setup（规划） 任务理解、环境初始化、复现问题 9.98% Explore（检索） 代码搜索、文件检查、根因分析 30.37% Fix（执行/反思） 代码修改、调试迭代、补丁完善 33.53% Validate（校验） 测试、回归检查 16.59% Closeout（总结） 最终检查、清理、总结输出 9.53% 一条Agent任务的31轮账单轨迹 Explore和Fix加起来接近三分之二。也就是我们平时感觉最耗时间的“查文件”和“改了又改”，确实也是Agent最容易消耗轮次的地方。 再往细看，每一轮的成本主因会来回切换。第1轮主要贵在输出token，因为模型在做初始规划；第10轮主要贵在未缓存输入token，因为它在读测试文件、创建复现脚本；第17轮又变成输出token为主，因为模型在写调试脚本；第23轮和第28轮再次由未缓存输入主导，用在跑测试、清理临时文件；最后第31轮主要是输出token，用来生成总结。 单轮看，输入和输出会交替成为成本大头。拉长看，输入token，尤其是反复带入的历史，才是总账单里最重的部分。即便很多历史命中了缓存，单价已经便宜很多，量一旦大到一定程度，便宜的input照样会超过高单价但数量少的output。 下面这张表可以直接拿去套自己的Agent任务。如果手头有真实usage日志或trace数据，就把数字填进去；如果暂时没有实测数据，也可以先用公开定价做模拟账，但一定要标清楚是模拟，不要写成实测。 阶段 模型回合 工具调用 主要Token来源 容易滚账单的原因 规划 1-2 0 任务、系统提示、项目约束 一开始就带全量规则 检索 5-10 10-30 文件内容、搜索结果、工具返回 工具结果进入下一轮上下文 执行 3-8 5-20 patch、命令输出、错误日志 每次失败都会增加历史负担 反思 2-6 0-5 失败路径、测试输出、候选方案 模型会带着前面的错误继续判断 总结 1-2 0 全部变更和验证结果 输出不多，但输入已经很厚 模型档位也会明显影响同一条轨迹的账单。OpenAI在2026年6月预览、7月正式开放的GPT-5.6系列就是一个例子：Sol每百万token输入5美元、输出30美元；Terra输入2.5美元、输出15美元；Luna输入1美元、输出6美元。同样的token轨迹套进去，最贵和最便宜相差5倍。 ...

数据核对时间：2026年7月下旬。文中标注“网络测算”的数字均非官方数据，仅供方向参考；具体以各厂商官方文档为准。 你可能也遇到过这种情况：豆包平时用得好好的，某天突然弹出一句“今日额度已用完”。你没觉得自己做了什么特别重的操作，但服务就是停在这里了。 免费额度看起来像一个产品规则，其实背后是一笔账。厂商每天都在算：一个免费用户最多可以消耗多少算力？这些消耗能不能被转化、数据、生态位或者广告收入补回来？一旦这笔账变了，额度就会跟着变。 这篇文章聊的就是这件事：AI工具的免费额度到底是怎么算出来的，为什么有时会突然收紧。 一、免费额度先看成本账 免费额度是一笔账 免费不是厂商一拍脑袋决定的。更接近真实情况的算法，大概是这样： 免费额度上限 ≈ 厂商愿意为每个免费用户承担的成本上限 = 这个用户能带来的预期回报（数据反哺、转化概率、生态位、广告收入）− 服务这个用户的边际成本 右边任何一个变量变了，左边的免费额度就会被重新算一遍。所以免费额度很少是一个永远不动的承诺，它更像一个会随成本和商业压力调整的预算线。 这个成本也不轻。网络上有过一组针对豆包的粗略测算，口径不是官方数据，只能看方向：假设日活用户500万，其中30%的人每天用5次生成、转写、解析这类核心功能，日均调用量就是750万次。只算这几类基础操作，硬件成本每天就可能到六位数。这里还没把模型训练、内容安全审核、峰值并发预留的冗余算力算进去。 所以，免费不是技术天然带来的结果，更多时候是厂商用资本、生态位或者增长目标换来的让利。融资节奏变慢、算力成本变高、商业化压力上来，免费额度就很难一直按原来的尺度给。 二、厂商不会告诉你花了多少钱，只会改规则 厂商不会在页面上写“你今天最多只能消耗X元算力”。它会把这笔预算翻译成几种你能感知到的产品规则：几点重置、还能问多少次、还能不能用最强模型。 第一种，是时间窗口。Claude免费版和Pro版都不简单按“每天0点重置”来算，而是用滚动的5小时窗口，再叠加每周总量。规则看起来复杂，目的其实很直接：把用户请求摊到全天，避免大家卡在同一个重置点一起涌进来。 第二种，是按模型分层给次数。Gemini走的是这条路。综合多个独立开发者社区对Google官方限额页面的追踪，口径有差异，但方向一致：轻量级的Flash系列免费额度比较宽，可能到每天1500次请求；旗舰级的Pro系列就收得很紧，每天可能只有50次左右，每分钟请求数也被压到个位数。同样叫免费版，背后用的算力并不是同一档，越贵的模型，免费额度越少。 第三种，是模型降级。很多人以为免费层只是“同一个模型，少给几次机会”，实际更常见的是限次再加降级。你仍然在同一个入口提问，但系统可能已经把你切到更便宜的模型、更低的推理深度，或者更弱的功能组合上。ChatGPT免费版就是类似逻辑：消息数、文件上传、图像生成分别计数，默认模型和推理能力也会受限，免费用户很难稳定使用最强推理模式。 机制 代表产品 逻辑 滚动时间窗口 Claude免费版（5小时+每周） 平滑并发，不按自然日重置 按模型分层的固定次数 Gemini（Flash系列约1500次/天，Pro系列约50次/天） 越贵的模型，免费额度收得越紧 消息数/功能项独立计数+模型降级 ChatGPT免费版 各项功能分别限额，且默认模型和推理深度打了折扣 还有一层更隐蔽：厂商会把功能拆到免费墙和付费墙两侧，而不是简单地对整个产品收费。以豆包为例，免费层保留了大量高频但单次价值密度不高的功能，比如日常聊天、简单文案；长文档精读、批量视频生成、深度数据分析这类明显提高单次产出质量、也更耗资源的功能，则更容易被放进付费区。 免费额度的三种产品化方式 轻度用户每天聊几句、改几段文字，基本感受不到这堵墙。会撞上它的，通常是消耗远高于平均值的重度用户。 三、豆包为什么走到收费这一步 回头看豆包的调整，它不是一次孤立的商业新闻，更像是免费额度这笔账算到某个阶段后的结果。 多方媒体报道显示，2026年5月4日，字节跳动旗下豆包在苹果App Store上线三档付费方案：标准版68元/月、加强版200元/月、专业版500元/月。官方口径是“基础功能永久免费+高阶增值付费”，日常聊天、简单文案、简单翻译等核心功能承诺永久免费且不限次。 这个消息之所以引发讨论，不只是因为豆包开始收费，而是用户马上会担心：免费版会不会变慢？会不会排队？会不会把好模型藏起来？官方没有宣布免费额度缩水，但用户的反应说明了一件事，额度收紧很多时候不会写在公告里，而是慢慢体现在体验上。 第一，用户规模已经大到不能忽略成本。据QuestMobile数据，2026年第一季度豆包月活跃用户约3.45亿。到了这个体量，单个免费用户哪怕只多消耗几分钱，乘起来也是很大的成本。 豆包收费背后的三股压力 第二，上游成本也在变贵。2026年5月9日起，腾讯云宣布AI算力相关产品价格上调5%；阿里云部分产品价格出现上调，公开报道中的最高涨幅达到34%；智谱AI相关订阅和API价格也在年内多次调整，2月GLM Coding Plan提价超过30%，3月GLM-5-Turbo API价格上调20%，4月GLM-5.1继续提价10%。 智谱这几次调价可以单独看一下。假如是在同一条产品线上连续上调，复合涨幅会是： 1 1.30 × 1.20 × 1.10 ≈ 1.716 这意味着同一产品连续涨三次，理论累计涨幅会接近72%。但这里要把边界说清楚：这三次提价分别对应GLM Coding Plan、GLM-5-Turbo API、GLM-5.1，不是同一个SKU连续涨价，所以不能直接写成“同一件商品涨了72%”。更稳的说法是，这几次调价方向一致、间隔很近，反映出2026年上半年模型服务成本在收紧。 第三，收费也是一种用户分层。豆包3.45亿月活里，大量消耗算力的深度用户只占一小部分，但他们的token消耗会远高于平均水平。三档定价的作用，就是把这部分重度用户筛出来，让高消耗和付费对应起来。绝大多数轻度用户每天聊几句、翻译几段文字，可能几乎感觉不到变化。 免费额度收紧最常见的样子，大多不是全面砍掉免费版，而是先卡高消耗场景。ChatGPT从免费版到Go、Plus、Pro多档分层，背后也是同一条路，轻度用户尽量留住，重度用户自然进入付费层。 写在最后 免费额度很难看成厂商的长期承诺，它更像一套会被反复重算的成本模型。算力成本涨了，用户规模大了，变现压力来了，任何一个变量变化，额度都会被重新评估。 只不过这个过程通常不会直接告诉你。它更多会变成限速、排队、次数减少、模型降级，最后落到你的使用体验里。 所以下次再看到一款AI工具说自己完全免费，可以换个角度看：它的用户增长和算力成本是不是越拉越开。两条曲线背离得越明显，免费额度被收紧的可能性就越高。 ...