推理模型不该把什么都读一遍

一个量化研究员不会把十年的分钟级行情逐条读一遍再心算，他会先决定算什么，把活交给程序，再回来看结果。换成推理模型，很多团队反着做了。

一、发生了什么

InfoWorld 在 10 月 22 日发了一篇由 Opetek 的 Varqa Abyaneh 写的文章，讲的是上下文窗口这条路的边际效益。

文章先摆了一串时间线：2023 年 5 月 Claude 的窗口从 9 千涨到 10 万 token，同年 11 月到 20 万；2024 年 2 月 Gemini 1.5 Pro 到 100 万，6 月到 200 万；到今年 3 月，百万级窗口在 Claude 全系可用，另有十余个托管的前沿模型提供百万以上。

价格在跌，用量涨得更快。文章引 Ramp 的数据：美国企业每百万 token 的实际支出，从今年 3 月的高点跌到 9 月，降了 41%；高盛则预计到 2030 年，智能体带来的 token 消耗会涨 24 倍。

最具体的是一个自测：用十年的欧元兑美元汇率算已实现波动率，把原始时间序列直接塞进上下文，单次查询约 0.80 美元；把计算放到模型外面，只让模型读结果，约 0.07 美元。

文章给这种现象起了个说法：更大的窗口不等于更好的架构。在数据密集的场景里，模型得先把海量数字读完，才能开始理解问题、决定怎么分析、再解释结果。而这三步本来可以分开：模型决定算什么，常规程序去算，模型再对算出来的结果做判断。两件事是两种能力，合成一步就要为两边都付费。

二、跟你有什么关系

做数据分析类应用的：你的负载有个共同点——同一份底层数据被反复处理。这正是最贵的那种用法。

管云账单的：模型单价下降是真的，但它遮住了另一件事——每次请求要吞的数据量在涨。两个变量反向跑，多数团队只盯了前一个。

做 agent 的：工具调用越多，越容易把"取数"和"算数"混在一起交给模型。分工没写清，钱就花在让模型读它根本不需要读的行上。

三、怎么判断

1. 把一个请求拆成两问：这一步是判断，还是计算。判断留给模型，计算交给代码或数据库。
2. 找重复。同一份数据被不同问题反复读的，做成预计算或索引，只把结果送进上下文。
3. 量一下再改。先测出单次请求的输入 token 和成本，改完再测一次。没有基线，优化就是猜。
4. 分三层看效率：模型本身多便宜、检索能不能捞准、以及最容易被忽略的——到底哪些数据有必要进模型。文章认为第三层决定上限。
5. 找一个你已经上线两周的功能，把输入内容砍掉一半再跑。如果结果没变差，说明那一半从来没被用上。

四、三个别信的说法

窗口够大，就不用做数据工程了。 窗口决定"能不能放进去"，不决定"该不该放"。放进去的每一行都按 token 计费，还要占显存、拖慢首字延迟。

上下文越长，答案越准。 这篇文章没有给出这个结论，也不该被这么读。它讲的是成本，不是准确率。长上下文带来的注意力稀释是另一个话题，别混着用。

省 90% 是通用结论。 那个 0.80 对 0.07 的对比，来自厂商自家架构上的一个特定任务：确定性的数值计算。换成长文档摘要这种必须通读的活，同样的做法省不下来，甚至会更差。

五、一句话结论

下一轮降本不来自更便宜的模型，来自你决定不让模型读的那些数据。

信息来源

• InfoWorld：推理模型为什么不该通读所有数据，2026 年 10 月 22 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 23 日。