@MaximeRivest: 当前的LLM架构很蠢(如果不算蠢,至少也是浪费)。以下三个包含4个上下文块的提示词:…
摘要
一条推文批评了当前LLM架构因依赖顺序的上下文而导致浪费的重计算,并提出将上下文单元分开编码,以实现与顺序无关的高效缓存和生成。
查看缓存全文
缓存时间: 2026/06/10 15:53
当前的LLM架构很糟糕(如果不算愚蠢,至少也是浪费的)。
举个例子,考虑以下3个包含4个上下文块的提示:
[file A][file B][task][tool specs] [tool specs][file B][file A][task] [task][file B][file A][tool specs]
这些块之间的顺序本应无关紧要——在上下文块内部,顺序至关重要,但块与块之间的顺序却应该无关紧要。
然而,当前架构破坏了缓存,当我们更改代码库中某个文件时,或者仅仅是生成任务改变了(而文件和工具未变)时,就得重新计算大量内容。
此外,这种方式难以低成本地精简上下文至核心内容,也难以检索上下文块并以节省计算的方式仅展示相关部分。
理想情况下,应该能够对这些上下文块进行编码,使得以下操作可行:
u1=encode(Unit(name=“file_a.py”, content=…)) u2=encode(Unit(name=“file_b.py”, content=…)) u3=encode(Unit(name=“tool_specs.yaml”, content=…))
model.generate( task=“提供修复 file_a.py 的差异,file_b.py 无关”, ctx_units=[u1, u2, u3] )
在这种情况下,u2(file_b)会被预先编码,它对该任务算力的影响应该会随着神经网络早期层识别出它与任务无关而迅速衰减。
同时,u1和u3虽然都相关,但它们的顺序也不重要。
有人训练过类似的东西吗?
感觉就像是针对生成任务的丰富后交互(rich late interaction)。
相似文章
@ickma2311: 高效AI讲座15:长上下文LLM 长上下文不仅仅是更大的提示窗口。关键问题是:哪些过…
本文总结了关于长上下文LLM的高效AI讲座15,涵盖用于上下文扩展的RoPE位置插值、大海捞针评估,以及StreamingLLM的注意力汇聚现象和KV缓存驱逐策略。
引用布莱恩·坎特里尔
布莱恩·坎特里尔批评LLM缺乏人类懒惰带来的优化约束,认为LLM会不必要地使系统复杂化而非改进,并强调人类时间限制推动了高效抽象的发展。
LLM架构的最新发展:KV共享、mHC与压缩注意力 [P]
Sebastian Raschka回顾了LLM架构中针对长上下文效率的最新创新,包括KV共享、压缩卷积注意力和来自Gemma 4、ZAYA1、Laguna XS.2和DeepSeek V4等模型的逐层注意力预算。
超越压缩:面向长周期智能体的结构化上下文驱逐
介绍了上下文窗口生命周期(CWL),这是一种面向长周期LLM智能体的结构化上下文驱逐方案,通过基于依赖图驱逐内容来维持有效无界的工作视野,避免了基于摘要的压缩和最近截断的局限性。
LLMs与记忆限制——请审阅我的想法
本文分析了LLM记忆限制,认为真正的个人AI需要单租户权重定制,这与当前多租户云经济模式相冲突,并指出开源权重模型可能是进步的关键来源。