「上下文加倍速度就减半」错在哪？

把一份长资料投给大模型，有人断言「上下文加倍速度就减半」，听上去符合直觉，实际并不成立。错在哪里？错在把一个受多因素影响的复杂过程，简化成了单变量的线性算术。真实情况是：上下文变长确实会增加计算量，但增加的幅度和速度的降幅都不按「加倍减半」这个比例走。

误区原话与它流行的原因

这个说法能流行，是因为它借用了生活经验的直觉——活儿多一倍，时间就该多一倍。但大模型推理不是一个人搬砖：模型架构里有专门的机制处理历史内容，多数已经处理过的部分无需重算，真正增加的开销集中在新增内容的读取与整合上。把工厂流水线的直觉照搬到推理引擎，比例自然对不上。

速度到底由什么决定

一次请求的耗时至少由四块拼成：排队等待、上下文读取、逐字生成、网络传输。上下文长度主要影响第二块；而逐字生成的速度更多取决于模型大小和输出长度。你让 DeepSeek 生成三千字长文，慢的大头是「写」，不是「读」。只盯着输入长度做判断，等于只看了账单的一行。

四块耗时各自受什么牵动，摊开对照。

用一个生活类比帮助记忆，但要用对：长上下文像搬家时多出来的箱子——搬运公司有专门处理存量箱子的传送带，旧箱子几乎不用再搬，真正增加的活是新箱子入库登记。总搬运时间确实涨了，但涨的是登记那一小段，不是全部重来。类比失效之处也要说清：如果传送带本身满了，内存吃紧、缓存被清，旧箱子也得重新搬，这时长上下文的代价才会陡增。所以看到「变慢」，先分清是常规增量还是缓存失守，两者差着量级。

加倍后真正发生的事

上下文翻倍时，实际发生的是读取阶段的负担上升，且上升幅度受缓存命中情况影响巨大——命中良好时，重复前缀几乎不产生新的计算，见提示缓存和 KV 缓存差在哪里的机制拆解。另外，服务端并发调度也在起作用：同一时刻很多人在用，你的等待时间跟整体负载相关，跟你的上下文长度关系反而没那么直接，「并发越高越好」错在哪从另一头讨论了这个变量。

自查清单

• 变慢时先看输出长度：写得长才是常见的慢因。
• 再看时段：高峰期的等待常被误记到上下文头上。
• 固定前缀能省则省：命中的部分几乎不耗时。

正确的说法是什么

更靠谱的表述是：上下文变长会增加读取开销，响应时间随之上升，但上升是平缓的、非线性的，且受缓存、负载、输出长度共同影响。给上下文窗口做规划时，用「实测几组不同长度的耗时」代替拍脑袋的比例推算，结论立刻扎实。窗口容量本身怎么理解，上下文窗口和检索窗口有什么区别有专文；想给长对话瘦身，策略见单轮长问和多轮短问差在哪。

最后补一个实验设计的小技巧：测耗时要在同一时段连续做，避免负载波动干扰；每组长度测三次取中位数；同时记录输出长度，把「读」和「写」的耗时分开看。如果手头是程序化调用，把这几组数据写进监控面板，长度与耗时的关系从此一目了然。二十分钟的实验，胜过十次口口相传。

把这句修正后的判断带走：长上下文有代价，但代价按实际机制计，不按道听途说的倍数计。

拿 Kimi 的长文档问答实测一组对照，体会会更直接：同样的资料量，压缩与不压缩各跑一次，耗时差异一目了然。

换个问法再问上下文变慢三句

• 长上下文会让生成质量下降吗？：内容过多可能稀释重点，压缩与分段是常用的应对办法。
• 为什么有时短提问也慢？：排队与负载主导了耗时，短提问同样要等。
• 有什么办法确认瓶颈在哪？：对比不同时段、不同输出长度的耗时，几轮实验就能定位。