🤡 如何让任何稀疏注意力/KV压缩看起来更好？🤡

原文：https://x.com/p_nawrot/status/2089315591010079034 我过去几年一直在研究高效注意力和KV缓存压缩。我读过很多论文，深入挖掘了方法的参考或官方实现，并检查了附录——我认为我学到了一些东西。其中之一肯定是“如何让事物看起来更好，即使它们并不好。” 我也有罪，但每天都在努力变得更好。 1. 对于单次检索，确保没有干扰项且上下文无用 压缩/稀疏度的三个最配合的设置是： - 带有单个OOD键值对的干草堆中的针，上下文由重复句子或无关背景文本构成。 - 多年前的受污染基准测试，模型甚至不再查看上下文。 - 少样本上下文学习，其中额外样本无用且不会提高0-shot以上的准确性。 通过1）合成任务，2）真实数据QA，和3）上下文学习，你得到了一种广泛覆盖的表象，而没有测试其中任何一项多样性的不便。这些设置中的大多数任务应该能在滑动窗口注意力下通过，因此你的方法是否有效并不那么重要。将其与SWA结合，你应该可以报告5-10倍的压缩或稀疏度。 2. 永远不要孤立你的贡献 短上下文：密集模型的性能大部分由局部窗口+注意力汇点+检索与问题大体n-gram匹配的答案句子的能力恢复。剩下的部分要困难得多，但既不相关也不是本文的主题。假设先前的工作开发了算法X，其实现单独保留了256个令牌的局部窗口。你发现在匹配设置中你的方法与X相当，但在窗口大小为512时更好更稳定——继续前进，不要回头。对块大小做同样的事情。较小的块可以提供更细粒度和更精确的检索，因此保留它们旧的块大小，让你的更小。忽略由于不规则内存访问等原因可能导致变慢的事实。那些是历史决定；尊重它们。🤡 写道：“我们使用了作者推荐的超参数。”，然后花数周调整你的方法。同样的技巧适用于速度。LLMs现在可以很好地编写Triton。保持基线算法完全按照2023年编写的方式，然后为你的方法请求LLM编写自定义Triton内核。额外聪明的是，如果通过使用更高效的实现，你可以隐藏你的方法做了更多工作。你只是在优化你的方法，不是吗？提示是锦上添花。将问题移到上下文之前，以便模型知道过滤什么，然后将结果呈现为无损压缩。调整后永远不要共享提示。不要调整基线以拒绝你的论文；调整你的直到被接受。 3. 使用聚合指标来隐藏你的方法不工作的区域 RULER有13个任务：6个NIAH任务满足第一点。2个QA任务使用多年前的数据集。VT也有大量无关上下文。明确地说：这不是对RULER的批评；在我看来它仍然非常有用。这只是潜在不当使用的一个例子。只报告聚合；也许在最后的限制部分简要提及你的方法在NIAH-MK3上退化，这实际上压力测试无损压缩。 4. 享受饱和任务 想象在两个任务上评估：一周前最近的数学考试/奥林匹克竞赛，尚未进入训练数据。一个基准测试，最近的一系列开放模型——1B、10B和100B——都得分80%。在前一个任务中，在压缩有机会造成任何损害之前，1B和10B模型已经得分0%；100B模型从50%开始，其性能随着压缩增加而单调下降。在后者中，所有模型大小都容忍大量压缩，100B模型比1B和10B模型容忍更多。不要问更大的模型是否只是利用其额外的参数和隐藏状态能力在不需要解决更难问题的情况下吸收压缩。这肯定不是正在发生的事情。 额外AIME有30个样本。你做了4个种子。你的方法得分80，基线得分79——加粗你的80并说它超过了基线。统计学不存在。为你的效率方法超过基线并设置新的SOTA加分。🤡🤡 选择一个基线，用你的方法优化它，并绘制一个美丽的质量-效率曲线与原始实现。然后停止。不要问是否一个更简单的路径——一个更小的密集模型、KV缓存量化或卸载、或更好的系统配置——达到更好的操作点。改进你的基线基本上与改进前沿相同。