滑动窗口注意力
一种限制注意力计算范围的机制，每个token只关注固定窗口大小内的历史token，而非全序列，从而将注意力计算复杂度从O(n²)降低，常用于长上下文模型的内存优化
核心事实
时间轴 (近 90 天)
滑动窗口注意力让每个 token 只关注固定长度窗口内的邻近 token，从而将注意力计算与 KV 缓存从随序列长度线性增长降为常数级。
DeepSeek 的部分模型层使用滑动窗口注意力，只关注最近的 128 个 token；SWA 有界重放只重放提示末尾的短窗口，据称几乎消除总预填充工作量。
该架构的滑动窗口为 128 token，窗口层的 KV 缓存到 128 个位置后不再增长，无论上下文多长。
对于该架构，每 token 缓存字节数不是常数；仅窗口层的等效字节/token 在上下文为 8,192 时约为 688.0，131,072 时约为 43.0，1,048,576 时约为 5.4。
Muse Spark Open 支持 100 万 token 的上下文窗口，依靠混合注意力架构实现，在层间交替使用滑动窗口注意力和全注意力。
滑动窗口注意力是Transformer架构中的一种局部注意力变体，每个token只关注其前后固定长度窗口内的token，将注意力计算复杂度从O(n²)降到O(n·w)。
无限上下文的实现通常依赖于检索增强生成（RAG）或滑动窗口注意力机制的变体。
记忆注入会消耗上下文token，这是一种用token换取减少工具调用对话轮次和翻找的取舍
Spark X 2.5共有36层，采用重复的'4层一组'结构，每组包含三个只关注最近512个Token的滑动窗口层和一个读取整篇文本的全局层
业界改善长上下文注意力衰减的方案包括稀疏注意力、滑动窗口注意力和RoPE位置编码外推，但目前没有任何方案能完全消除这一根本性限制
还有 1 条时间轴事件
全部知识事实 (14)
记忆注入会消耗上下文token，这是一种用token换取减少工具调用对话轮次和翻找的取舍
65%待验证Gemma 4使用滑动窗口注意力（SWA）架构，该架构在处理数千行混淆JavaScript时导致模型遗忘早先读入的关键上下文
80%待验证滑动窗口注意力将标准Transformer O(n²)的复杂度降至O(n·w)，但模型无法直接看到窗口之外的信息
70%待验证滑动窗口注意力让每个 token 只关注固定长度窗口内的邻近 token，从而将注意力计算与 KV 缓存从随序列长度线性增长降为常数级。
50%待验证DeepSeek 的部分模型层使用滑动窗口注意力，只关注最近的 128 个 token；SWA 有界重放只重放提示末尾的短窗口，据称几乎消除总预填充工作量。
50%待验证该架构的滑动窗口为 128 token，窗口层的 KV 缓存到 128 个位置后不再增长，无论上下文多长。
50%待验证对于该架构，每 token 缓存字节数不是常数；仅窗口层的等效字节/token 在上下文为 8,192 时约为 688.0，131,072 时约为 43.0，1,048,576 时约为 5.4。
50%待验证Muse Spark Open 支持 100 万 token 的上下文窗口，依靠混合注意力架构实现，在层间交替使用滑动窗口注意力和全注意力。
50%待验证无限上下文的实现通常依赖于检索增强生成（RAG）或滑动窗口注意力机制的变体。
50%待验证滑动窗口注意力是Transformer架构中的一种局部注意力变体，每个token只关注其前后固定长度窗口内的token，将注意力计算复杂度从O(n²)降到O(n·w)。
50%待验证Spark X 2.5共有36层，采用重复的'4层一组'结构，每组包含三个只关注最近512个Token的滑动窗口层和一个读取整篇文本的全局层
50%待验证业界改善长上下文注意力衰减的方案包括稀疏注意力、滑动窗口注意力和RoPE位置编码外推，但目前没有任何方案能完全消除这一根本性限制
50%待验证滑动窗口注意力的KV Cache大小恒定，实现O(1)的显存占用而非O(n)
50%待验证滑动窗口注意力（如Mistral采用的方案）通过限制每个token只关注固定窗口内的历史，将复杂度从O(n²)降至O(n·w)
50%