【大模型两年狂飙，为何上下文长度原地踏步？】

Simon Willison 抛出一个有趣的观察：过去两年大模型能力突飞猛进，唯独上下文长度几乎没动。我们在20万到100万token这个区间已经停留很久了。

他的判断是，这更像一个硬件瓶颈。上下文需要显存，而内存带宽是核心制约因素。

但讨论中涌现出更深层的洞见。

有人指出，真正的瓶颈不是长度，而是注意力质量。一个能真正追踪依赖关系的20万token窗口，远胜于读到第50页就忘了第3页的200万token窗口。这话说到点子上了。

另一位开发者分享实战经验：试着把关键信息放在15万token的位置，然后看模型假装它不存在。这才是行业不愿公开的秘密。所谓的百万级上下文，很大程度上是营销数字。

从技术角度看，推理成本不是线性增长的。长上下文会把注意力机制变成一种类似自旋玻璃的状态，太多弱耦合的token会制造出大量浅层竞争盆地，而不是一个深井。简单说，模型会迷失在信息海洋里。

有趣的是，实践者们反而不那么渴望更长的窗口。一位开发者说得好：1万token精准的上下文，胜过10万token的大杂烩。瓶颈已经从「能不能装下」转移到「该装什么」。

还有人提出更激进的观点：与其追求更长的上下文，不如实现持续学习，让上下文窗口扩展变得没有必要。这可能才是研究者们真正努力的方向，只是持续学习太难，进展都藏在水面下。

据透露，Google内部已有1000万token的上下文能力，只是成本上还不可行。而Magic LTM-2-Mini声称达到1亿token，Llama 4 Scout推到1000万。但这些数字背后，是三个残酷的瓶颈：算力、成本、以及模型实际利用这些上下文的能力。

一个类比很贴切：人们在喷气发动机真正量产前几十年就知道它能工作。同样的动态正在上演。当前架构下，2到3倍的改进不会带来惊艳感。真正的突破需要100倍甚至1000倍的有效上下文提升，这需要有人愿意押注全新的模型架构。

目前的解决方案是子代理模式。Claude Code可以精心设计恰到好处的上下文，发送给子代理，等待回复。这本质上是用工程手段绕过了硬限制。

所以现状是：标签上写着百万token，实际可用的可能只有十分之一。行业正在从「堆长度」转向「用好长度」。这个转变本身，或许比单纯的数字增长更有价值。

x.com/simonw/status/2018706006457360690