注意力的计算量为什么随长度平方涨？一笔平方账

一场二十人的会，两两握手的次数接近两百；人数翻倍，握手次数直逼八百——注意力的计算开销就是这么涨的。Kimi、秘塔AI搜索能处理超长文档，背后都在和这笔平方账搏斗，本文把账摊开算。

握手笔账：平方从哪来

注意力是怎么算 QKV 的那篇讲过，第二步要拿每个字的 Query 与所有字的 Key 两两打分。序列长度为 n，打分次数就是 n 乘 n，平方级。长度翻倍，打分变四倍；长度十倍，计算一百倍。这笔账只算了打分，还没算加权求和的部分，所以实际账单只会更厚。平方并非模型设计失误，它是「每个字都要顾全所有字」这个需求的直接代价——想理解全文，就得付得起全文的两两对账。

长文本的账单：从一千到十万字

一千字的短文，账单不大，感受不到；十万字的技术合同，打分量涨到一万字时的一百倍量级，显存和时间双双吃紧。前缀缓存是怎么命中的讲的复用技巧，省的是重复开头那部分；多查询注意力是怎么省缓存的省的是显存占用；而平方账本身压不下去，只能绕。这就是为什么长文本服务要么分段处理、要么外挂检索，要么先把输入压缩变短再进模型。EOS 是怎么判定的讲的停止机制，也在为截断长输出把关。

平方账速查表

• 长度翻倍，打分计算变为四倍
• 长度十倍，打分计算变为一百倍
• 常见缓解：前缀缓存复用、KV 共享、分段与检索
• 评估长文本成本前，先按这张表把倍数心算一遍

省钱的思路：从平方往回降

研究界降低账单的路子大致三类：换注意力结构，让每个字只看一部分邻居，打分从全表缩到局部；压缩序列，先浓缩再计算，长度小了平方自然小；缓存复用，重复的部分不重算。注意力掩码是什么那篇说明遮罩本身不省算力，只是砍掉无效计算；logits 是什么那篇讲的输出环节随序列长度线性增长，不是大头。各家产品的长文本能力差异，多半就在这几条路上走了多远，宣传页的窗口数字要结合速度与价格一起看。

关于平方复杂度的三个常问问题

• 为什么上下文越长回答越慢？：打分次数按长度平方涨，还叠加每步都在膨胀的键值缓存读取，双重开销，长文本的慢是结构性的，不是网络卡。
• 窗口标很大就真能用满吗？：能装下与算得起是两回事，占满窗口后速度与成本都会明显上升，实际业务常把输入控制在窗口的一部分。
• 平方账能彻底消灭吗？：稀疏或线性注意力能降到接近线性，但表达力与实现复杂度各有取舍，以官方技术报告为准，别只看宣传数字。

算成本先算平方账：长度一动，账单按平方跳，绕路往往比硬扛划算。换个角度理解这笔账：平方项来自每个字都要和所有字握手一次，字数翻倍，握手次数变四倍，而每次握手的分摊成本在工程上还有常量优化空间，所以业界更关心怎么减少握手指数的量级，而不只是抠常数。缓存那类优化动的是握手结果的复用，本质上没有减少必须的握手次数，省的是重复劳动。真要数量级地降，得改结构或改输入长度，这也是长文本方案几乎都在和平方项较劲的原因。放到产品侧看，这就是长文档问答、整本代码库分析这类功能成本居高不下的根源，也是厂商宣传长窗口时必谈推理优化的原因。