全注意力机制是一切大模型的基础也是长文本场景下成本最高的部分。最近 Kimi 团队围绕线性注意力提出了 Kimi Linear 方案核心就是解决全注意力“越用越贵”的问题。这篇作为“核心原理”系列的第一篇先把全注意力为什么贵这件事讲透从计算复杂度、KV Cache、生成阶段的重复开销三个角度拆解再看 Kimi Linear 想动手术的位置在哪里。如果你在纠结“为什么模型处理长文本时每生成一个新 token 都越来越慢”或者想理解线性注意力到底优化了什么这篇文章可以直接往下看。本文不涉及具体部署命令重点做原理拆解和成本量化适合算法工程师、LLM 应用开发者以及对推理优化感兴趣的技术读者。1. 核心原理速览维度说明主题标准全注意力机制的计算开销来源核心复杂度序列长度 N 下注意力矩阵计算与显存均为 O(N²)关键瓶颈QK^T 矩阵、Softmax 归一化、KV Cache 重复读取生成阶段特点每个新 token 都要与全部历史 token 计算注意力典型影响长上下文下推理时延增长、显存占用上升优化方向FlashAttention、稀疏注意力、线性注意力、Kimi Linear适合读者想理解 LLM 长文本成本来源的开发者与算法工程师前置知识熟悉 Transformer 基础结构、了解 QKV 概念这里说明一下本文讨论的是全注意力机制在推理阶段尤其是自回归生成阶段的成本模型。Kimi Linear 的具体实现细节目前以官方技术报告为准本文只从公开原理层面说明它要解决的问题不虚构参数。2. 直观理解为什么叫“重翻百万页记录”把大模型生成文本想象成一个非常认真的抄写员。它在写当前这句话时每写一个词都要把之前所有写过的内容重新看一遍确认这个词和前面每个词的关系。这个“重新看”的动作就是全注意力。如果文章只有一句话重新看一遍很快如果文章有一百万字那么每写一个新词就要翻一百万字的历史记录。而且麻烦的是不是只看一遍而是每个词都要翻一遍。所以生成第 10 个词时它翻 9 条记录生成第 100 个词时它翻 99 条记录生成第 10000 个词时它翻 9999 条记录。整个过程累加出来就是 O(N²) 的开销。这个比喻基本准确。在实际实现中“翻记录”并不是真的重新读一遍原始文本而是读取缓存下来的 K 矩阵和 V 矩阵。K 和 V 分别代表历史 token 的“检索键”和“内容值”它们在推理时被缓存在显存里统称 KV Cache。每个新 token 的 Q 向量要跟所有历史 K 向量做点积再把结果和所有 V 向量加权求和。也就是说即使没有重新计算前面的隐藏层状态注意力层的开销依然随上下文长度线性增长而这个线性增长发生在每个生成步骤里最终形成 O(N²) 的总成本。3. 从公式看成本全注意力的时间复杂度标准注意力公式为Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V其中 Q、K、V 的形状都是 (N, d)N 是序列长度d 是每个头的维度。这里有一个非常关键的操作QK^T。QK^T 的矩阵乘法是把 Q 的每一行和 K 的每一行做点积得到一个形状为 (N, N) 的注意力分数矩阵。这个矩阵就是所有 token 两两之间的关联程度。问题在于它的规模是 N²。如果 N 是 1000矩阵是 100 万个数如果 N 是 10 万矩阵是 100 亿个数如果 N 是 100 万矩阵就是一万亿个数。这个增长速度非常夸张远快于显存和算力本身的增长。下面用一段 Python 代码模拟注意力矩阵的显存占用import math def attention_matrix_bytes(seq_len, head_dim, dtype_bytes2): # QK^T 矩阵元素个数为 seq_len * seq_len elements seq_len * seq_len # 显存占用还要乘以每个元素占用的字节数 memory elements * dtype_bytes return memory for n in [1000, 10000, 100000, 1000000]: mem attention_matrix_bytes(n, 128) print(f序列长度 {n:9,} - 注意力矩阵显存占用 {mem / 1e9:.2f} GB (fp16))输出大致为序列长度 1,000 - 注意力矩阵显存占用 0.002 GB 序列长度 10,000 - 注意力矩阵显存占用 0.20 GB 序列长度 100,000 - 注意力矩阵显存占用 20.00 GB 序列长度 1,000,000 - 注意力矩阵显存占用 2000.00 GB这只是单个注意力头的 QK^T 矩阵。实际模型有多个头、多层还要再乘以头数和层数。所以当上下文来到十万甚至百万 token 这个量级全注意力在显存和时间上的开销都会变得不可接受。4. 训练阶段 vs 推理阶段成本的两种形态全注意力的昂贵在训练和推理阶段表现不一样不能混在一起谈。训练阶段是并行计算整个序列的。也就是说模型一次读入所有 token一次性算出所有 token 两两之间的注意力分数。此时成本主要体现在显存上N² 的注意力矩阵必须被实例化或者通过 FlashAttention 这样的内核融合技术避免完整实例化同时反向传播还要保存中间结果。因此训练长序列模型的最大瓶颈是显存。推理阶段又分为两个子阶段预填充阶段Prefill模型拿到用户输入的一整段文本并行计算所有输入 token 的注意力。此刻成本形态和训练类似但不需要反向传播压力比训练小很多。自回归生成阶段Decode模型逐 token 生成输出。每生成一个 token都要让这个新 token 的 Q 和所有历史 token 的 K、V 做注意力计算。这里的问题不在于单次计算量有多大而在于它被重复执行 N 次。序列越长单次需要读取的 KV Cache 就越大计算延迟随之增加。很多人在实际使用长文本模型时感觉到“越到后面越慢”就是第二个阶段的问题。它并不是心理作用而是每一次生成新 token 都需要访问越来越大的 KV Cache。5. 生成阶段的真实瓶颈KV Cache 的重复读取继续前面抄写员的比喻。“重翻百万页记录”在工程上的真实形态是每一层、每一步都要读取完整的 KV Cache。假设一个模型有 32 层、40 个注意力头、每个头维度 128上下文长度为 100 万 token使用 fp16 存储KV Cache 的大小可以估算def kv_cache_bytes(layers, num_heads, head_dim, seq_len, dtype_bytes2): # K 和 V 各一份 per_layer 2 * num_heads * head_dim * seq_len * dtype_bytes return per_layer * layers layers 32 num_heads 40 head_dim 128 seq_len 1000000 total kv_cache_bytes(layers, num_heads, head_dim, seq_len) print(f总 KV Cache 大小: {total / 1e12:.2f} TB) print(f平均每层: {total / layers / 1e9:.2f} GB)这个量级已经远超单张显卡的显存容量。就算不考虑显存放不放得下在生成每个新 token 时要把这么大体量的 K、V 数据从 HBM 里读取出来做矩阵乘这个内存访问开销本身就会成为延迟的主要来源。换句话说全注意力在生成长文时的瓶颈不只是“计算量大”还有“每个 token 都要把所有历史数据重新读一遍”的访存开销。这也是为什么很多长文本优化方案都在做 KV Cache 压缩、剪枝、滑动窗口、或把注意力变成线性形式本质上都是在减少生成阶段需要重复读取的数据量。6. 已有优化路线FlashAttention、稀疏注意力、线性注意力在讨论 Kimi Linear 之前有必要把既有的注意力优化路线梳理一遍。它们解决问题的角度各不相同。FlashAttention 属于“把计算重排”的路线。它不改变注意力的数学定义而是通过分块计算、内核融合避免把完整的 N×N 注意力矩阵写入全局显存。这样可以在同样显存下处理更长的序列同时减少显存读写训练速度也能提升。但 FlashAttention 并没有把复杂度从 O(N²) 变成 O(N)它只是把 N² 的显存压力通过分块技术缓解了一部分计算量依然是 N²。稀疏注意力属于“减少计算范围”的路线。它假设不是所有 token 都同等重要用一个固定模式限制每个 token 只能关注部分历史 token。典型做法有滑动窗口注意力、全局锚点 token 加局部窗口等。好处是复杂度可以降为 O(N)坏处是模型的表达能力受限某些需要跨长距离关联信息的任务可能效果下降。线性注意力属于“改变计算顺序”的路线。传统注意力必须先算 QK^T 得到 N×N 的注意力矩阵再和 V 相乘。线性注意力通过矩阵乘法的结合律调整计算顺序把对 N² 矩阵的需求变成 N 量级。它维护一个全局的状态矩阵基于这个状态逐步更新结果。理论复杂度 O(N)但早期线性注意力在效果上往往不如标准注意力。Kimi Linear 本质上属于线性注意力路线的探索。它要解决的核心问题就是如何让线性注意力既保持标准注意力的表达能力和实际效果又把生成阶段的成本降下来。7. Kimi Linear 要解决什么Kimi Linear 这个名字本身已经说明了方向用线性复杂度的注意力替代二次复杂度的全注意力。结合上面分析它想解决的是全注意力在超长上下文下的两个核心问题第一生成阶段的 KV Cache 过大。如果注意力计算方式改为线性就不再需要缓存完整的 K 和 V 矩阵而是维护一个固定大小的状态。这个状态大小可以做到与序列长度无关或弱相关显存占用从 O(N) 降到 O(1) 或 O(log N) 级别。第二每生成一个新 token 就要重读全部历史记录的访存问题。线性注意力把历史信息压缩成一个固定大小的状态生成新 token 时只需要读取这个状态而不需要读取全部历史 K、V。时间开销从 O(N) 降到 O(1)。但是这里要提醒一下线性注意力不是没有代价。传统全注意力的每一个 token 都可以直接访问所有历史 token 的精确向量信息检索能力很强。线性注意力把历史信息压缩成固定大小状态后信息存储容量受限这可能导致模型在需要精确回忆某些细节的任务上表现下降。Kimi Linear 的技术核心大概率就是在解决表达能力和复杂度之间的平衡问题。具体实现细节需要以 Kimi 团队发布的技术报告为准。但从原理层面可以确定的是如果线性注意力能够在长文本任务上达到接近全注意力的效果那么它对超长上下文的推理成本改善会是数量级的。8. 如何量化观察复杂度模拟与实测建议原理讲完了接下来给出一个可操作的量化思路。虽然这里不涉及具体模型部署但你可以用下面方法观察项目里的注意力成本。8.1 FLOPs 理论估算全注意力的计算量可以用公式快速估算。单层单头的 QK^T 计算量约为 2 × N² × d乘以 V 的计算量也有类似量级。写一个简单模拟import math def attention_flops(seq_len, head_dim, layers, num_heads): # 单头 QK^T: 2 * N * N * d # 单头 attn V: 2 * N * N * d per_head_flops 2 * seq_len * seq_len * head_dim * 2 total_layers layers * num_heads * per_head_flops return total_layers for n in [10000, 50000, 100000, 500000]: flops attention_flops(n, 128, 32, 40) print(fseq_len{n:7,} - 注意力总计算量约 {flops / 1e15:.2f} PFLOPS)这个数量级可以让你直观理解为什么长序列下全注意力很难跑起来。实际部署时真实的计算时间还取决于硬件算力和内存带宽但这个理论值能帮助判断瓶颈在哪个环节。8.2 实测观察指标如果你已经在本地或服务器上跑某个 Transformer 模型建议观察以下指标每生成一个 token 的耗时decode time per tokenKV Cache 占用多少显存模型整体显存占用随上下文长度的增长曲线长文本输入时预填充阶段和生成阶段的耗时分布# 观察显存占用每秒刷新一次 nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv -l 1如果发现显存占用随输入长度线性上升而生成耗时也明显上升说明瓶颈在 KV Cache 访存和注意力计算。此时再去考虑切换到稀疏注意力或线性注意力方案才有依据。8.3 对比测试方法要验证某个优化方案是否有用最直接的方式是设置两个实验组一组使用标准全注意力另一组使用优化后的注意力如线性注意力、稀疏注意力。固定相同模型结构、相同输入数据、相同 batch size分别测量峰值显存每秒生成的 token 数相同 prompt 下的输出质量长文本场景的任务准确率这里要特别强调不能只看速度还要看质量。很多线性注意力方案在短文本上速度提升不明显在长文本上才能体现优势但文本质量可能有所下降。所以测试时文本长度要覆盖短、中、长三档不要只看某一档。9. 常见误区与排查思路全注意力昂贵这个结论本身很清晰但实际工程里有一些常见误区值得澄清。误区实际情况建议长文本慢是因为模型参数量大参数量不变时注意力开销随序列长度平方增长是核心因素先看长度再谈参数量FlashAttention 把复杂度变成了 O(N)FlashAttention 只是减少了显存读写和内存占用计算量仍是 O(N²)超长上下文仅靠 FlashAttention 不够稀疏注意力一定比全注意力好固定稀疏模式可能丢失关键远距离信息根据任务类型评估效果线性注意力一定能无损替代全注意力信息压缩会带来表达上限质量和速度需要平衡验证具体任务指标显存不够就加个显卡多卡还要考虑通信开销KV Cache 分发也有成本先评估优化注意力本身如果你在自己的项目里遇到“长文本推理越来越慢”的问题排查顺序建议是确认序列长度是否是主要变量把长度减半看耗时是否明显下降。确认是预填充阶段慢还是生成阶段慢分别统计两个阶段的耗时。确认 KV Cache 是否被完整加载用 profiler 看 attention 算子的耗时占比。确认是否已经启用 FlashAttention 或类似内核融合优化很多框架默认不开启需要显式设置。确认是否有不必要的中间张量被保存推理模式下关闭梯度、关闭中间状态保存。10. 最佳实践与使用建议针对全注意力成本问题下面给出几条工程建议。第一短文本场景不要盲目换线性注意力。如果上下文长度只有几千 token全注意力的计算开销并不高换成线性注意力反而可能因为表达能力下降而影响效果。优化手段要匹配实际瓶颈。第二长文本场景先量化再优化。不要凭感觉判断“慢是因为注意力”。先用 profiler 和 nvidia-smi 定位瓶颈确认注意力算子确实占用主要耗时后再考虑稀疏化或线性化。第三关注生成阶段多于预填充阶段。对于对话、写作、代码生成等交互式应用用户感受到的延迟主要来自逐 token 生成。预填充阶段虽然计算量大但只跑一次生成阶段则要跑 N 次优化价值更高。第四注意输出质量的回归测试。任何注意力优化方案都可能改变模型行为。建议准备一套覆盖摘要、推理、代码、多轮对话等任务的小型评测集在切换注意力实现后跑一遍对比防止“速度上去了效果下来了”。第五结合上下文工程来降低实际序列长度。不是所有场景都需要模型处理百万 token。检索增强、分块摘要、滑动上下文等方案都能显著降低注意力开销而且效果稳定、风险低。注意力层面的优化可以作为进一步的性能手段而不是唯一解法。11. 总结与下一步这篇文章把全注意力贵在哪里讲清楚了核心是 O(N²) 的注意力矩阵计算加上生成阶段每个 token 都要反复读取 KV Cache二者叠加导致长文本推理的时间和显存开销随长度急剧增长。Kimi Linear 瞄准的正是这两个瓶颈通过线性注意力的方式把复杂度从 N² 拉低到接近线性。读完这篇你应该先做一件事用文中的公式估算一下你实际场景里的注意力开销再判断瓶颈到底在计算量还是访存。不要急着换模型用数据说话。下一篇“核心原理 02”可以继续拆解 Kimi Linear 的技术细节它是如何压缩历史信息的、状态是怎么维护的、跟现有线性注意力有什么差异。如果你在实践里遇到了长文本推理延迟和显存问题建议先收藏本文后面排查时可以对着复杂度模型逐项定位。