小模型的第二春

今年上半年，小模型还常常被当作「够用就好」的妥协选项。这周几份端侧推理的数据出来，情况有点不一样了。

驱动变化的不是模型变小，而是每瓦性能改善：同样的功耗能跑更大的模型，或者同样的模型跑得更省电。

直接的后果是一些被放弃的功能重新可行——实时字幕、离线摘要、常驻的个人助手。这些功能的共同点是对延迟和隐私敏感，而对能力上限要求不高，正好落在小模型的甜区。

值得警惕的是另一面：当端侧能跑，团队就容易把模型塞进每个功能。这和云端时代的老毛病是同一个。

一篇论文解释了长上下文为什么仍然会「忘事」

这周读到一篇论文，它把「长上下文模型为什么还是找不到中间那段话」拆解得相当干净。结论不新，但论证过程值得记一笔。

容量不等于可及性

论文的核心观察是：上下文窗口是一种容量指标，而任务需要的是可及性。把一本书放进窗口，和让模型在需要的时候找到其中一页，是两件事。

作者构造了一个受控实验：把关键信息放在不同深度，观察召回率。

• 放在开头和结尾，召回率稳定；
• 放在中段，随深度增加明显下滑；
• 窗口再放大，中段的衰减依然存在。

加长窗口没有解决「中间那一段」，只是把中间变得更长了。

他们给出的解释

论文把它归因于注意力在长序列上的分配：位置靠后的内容在生成时有更近的位置先验，中段内容既不够近、也不够醒目。

这个解释的实践含义比较直接：别指望窗口替你组织信息。 该做检索的还是要做检索，该给结构提示的还是要给。

我的保留意见

实验用的是合成任务，真实文档有标题、段落、格式，这些结构线索本身就能缓解中段衰减。所以结论更适合读成「不要因为窗口大就放弃组织结构」，而不是「长上下文没用」。