稀疏注意力模式对比
上下文一长，注意力就开始「少看几眼」：滑窗无脑只看最近 w 个，DSA 用索引器挑 top-k，MoBA 门控挑块，NSA 压缩+选择并用。拧查询位置、切五种策略，看每种策略对这个查询实际点亮哪些 token、两笔账差多少；再把「答案：42」放到序列最开头，看滑窗当场失忆、索引策略稳稳召回。
纯前端确定性模拟：索引器/门控分数为预设相关度表（真实系统是学出来的轻量小网络，页面明示），两笔账按访问格数计（账一 = 每查询点亮格数，账二 = 64 查询之和）；文章参数照抄：w=8192 → 1/122、k=2048 → 1/488（1M 打分对数），零 API、零随机。
切策略（两轴框架：怎么挑 × 看什么）
滑窗：只看最近 w 个 token，更早的一概不看——简单可预测，代价是窗外彻底失忆。它是所有动态路线的对照组。〔怎么挑：固定（只看最近 w） ｜ 看什么：原始 token〕
这个查询实际看谁
查询 #56 · 点亮 16/64 格相关度分数为预设演示口径（真实索引器/门控是学出来的轻量小网络）：#0 号「答案：42」分数最高，7 / 20 / 33 / 45 号是中段锚点，其余为装饰分
滑窗只看最近 16 格；演示 64 格缩影，文章口径 w=8,192（1M 下 1/122）
只有 top-k 索引（DSA）吃这个参数——切过去拧它，看两笔账怎么随 k 涨
两笔账（按访问格数计）
滑窗口径：账一 = 该查询点亮格数（「看」的成本）；账二 = 64 个查询各自访问格数之和（打分对数，全注意力 64²=4096）。 「挑」的成本（索引器/门控打分一遍全历史）演示不计时——IndexShare 每 4 层共享一次点名，可再省为 1/4。
文章口径（1M token 打分对数）：全注意力 1 万亿 对 · 滑窗 w=8,192 → 82 亿（1/122）· top-k k=2,048 → 20.5 亿（1/488）
远处的答案：各策略的召回差异
预设场景：把关键 token「答案：42」放在序列最开头（#0）， 查询问「答案是多少？」并停在尾部。滑窗看不见它 → 答错；索引 / 门控 / 压缩选择看得到 → 答对——这就是「少看几眼」各流派召回能力的分水岭。