如果你的工作恰好围绕长文档分析、代码仓库问答、大模型对话系统展开那么你可能已经注意到一个反直觉的现象上下文窗口越大的模型虽然能“读”进更多资料但生成速度往往更慢API 计费也更贵。很多人把这归因于模型变笨了或者纯粹是厂商定价策略的问题。但真正的根源藏在 Transformer 最基础的全注意力Full Attention机制里。这个机制最直白的特点就是模型每生成一个新词都需要把此前所有 Token 的记录从头到尾重新“翻”一遍。上下文如果有几十万甚至一百万个 Token那每蹦出一个新字背后就是几十万次相似度打分和加权计算。你可以把它想象成写一句话就要重读一遍整本书——这就是标题里的“每个新词都要重翻百万页记录”。Kimi Linear 这个名字恰恰是在对这种昂贵的“重翻”做手术。但想真正理解它要解决什么问题必须先弄懂三件事全注意力为什么这么贵贵在计算、存储、带宽哪一个环节线性注意力改变了什么又付出了什么代价这篇文章既不堆公式也不做产品宣传而是用算账、仿真和类比的方式把全注意力的成本结构拆开给你看最后再聊聊 Kimi Linear 这类线性注意力方案背后的技术意图以及它对开发者的实际影响。1. 这篇文章真正要解决的问题先下一个明确判断全注意力机制最大的问题不是精度不够而是复杂度过高——它的计算量随上下文长度呈平方级增长内存和带宽占用则随上下文长度线性增长。这两个“增长”叠加在一起直接决定了长上下文推理的“贵”和“慢”。很多开发者在选择大模型时只看上下文窗口的数字支持 128K、1M或者 10M就认为“能装下这么多内容效果一定不错”。但实际使用时往往发现有落差。例如把一个 10 万字的技术文档丢给模型做问答前面几轮交互还能接受到第 5 轮、第 10 轮输出速度明显下降甚至出现超时。这背后的原因之一就是随着对话轮数增加输入 Token 数量不断累积KV Cache 持续膨胀模型每次生成一个新 Token都需要把这个膨胀后的历史记录重新读一遍。这里真正影响用户体验的不是“模型记住了多少”而是“模型每次生成时翻了多少旧账”。因此这篇文章要解决三个具体问题让你建立一张成本地图全注意力的开销同时发生在计算、存储、内存带宽三个维度后两者往往被忽略。让你学会独立估算大模型推理的成本而不是只听厂商宣传。让你理解线性注意力方案在做哪一类创新它不是在原架构上打补丁而是把注意力计算本身的复杂度结构改掉。除了技术原理文中还会给出可运行的 Python 仿真代码。你可以用这些脚本在本地估算一个长上下文模型大概占多少显存、生成一个 Token 需要多少计算量以及它的带宽瓶颈在哪里。看完之后你再看任何长上下文大模型的性能指标都能迅速判断出谁的架构更适合你的业务。2. 全注意力机制为什么它“记得一切”2.1 从词到向量Token 与 Embedding要理解全注意力的成本得先理解它做什么。大模型处理文本并不是把文字当成字符串而是先把文本切成一个又一个 Token再把每个 Token 映射成高维向量。这个过程叫做 Embedding。比如“Kimi Linear 核心原理”这句话会被切成若干个 Token每个 Token 对应一个向量向量里包含了这个 Token 的语义信息。但是孤立地看每个 Token 是不够的。同一个词在不同上下文里含义完全不同。“苹果”可能指水果也可能指公司“线性”可能指数学概念也可能指注意力架构。Attention 机制要解决的核心问题就是让每一个 Token 都能从整个序列的其他 Token 中按相关度提取信息从而获得“看到上下文”的能力。全注意力机制对这个问题的回答非常彻底它让每个 Token 都与序列里的所有 Token 发生交互一个不漏。这种交互不是简单的拼接也不是预先固定好的规则而是动态计算的——每来一个新 Token都要重新评估它与所有历史 Token 的关联强弱。2.2 Q、K、V像图书馆的索引系统在全注意力机制中每个 Token 会生成三个角色不同的向量QueryQ可以理解为当前 Token 发出的“查询请求”。它代表“我现在想知道什么”。KeyK可以理解为每个历史 Token 的“索引标签”。它决定“我有哪些内容可以被查询”。ValueV可以理解为每个历史 Token 的“正文内容”。一旦查询命中这部分内容就会被取出。注意力计算的流程是这样的先让当前 Token 的 Q与所有历史 Token 的 K 做点积得到一组相似度分数然后把这组分数经过 softmax 归一化变成权重最后用这些权重对所有历史 Token 的 V 做加权求和。求和的结果就是当前 Token 在全局上下文下的新表示。这个流程很像是你在一个巨大的图书馆里找资料你带着一个查询问题挨个翻阅索引卡找到匹配的条目然后把对应书架上的内容抄下来最后按照相关程度综合成一份答案。索引越多、书架越满翻找和抄写的时间就越长。2.3 注意力的“重翻”属性每次都是全新计算现在到了最关键的部分为什么说“每个新词都要重翻百万页记录”因为公式里没有任何依赖前一步“结论”的地方。每当一个新的 Token 进来它都要生成自己的 Q然后拿着这个 Q 去和所有历史 Token 的 K 做点积再对所有 V 做加权求和。这一步无论之前已经生成过多少个 Token都无法跳过或复用为一个“最终答案”。历史 Token 的 K 和 V 会被缓存下来所以不需要重新计算这就是 KV Cache 的由来。但相似度分数、softmax 权重、加权求和的结果每一步都要重新计算一遍。原因很简单下一个 Token 的 Q 和上一个 Token 的 Q 完全不同关注点完全不一样。同一段历史在不同的问题下应该被赋予不同的权重。这也是“全注意力”名字里“全”字的含义。它要求模型在每一次生成时都对全局做完整的加权扫描而不能只依赖一个固定的记忆摘要。这样做的优势是信息无损、理论上限高代价则是每一步都要承担与全部历史长度成正比的扫描开销。3. 新词重翻百万页全注意力的三大成本清单3.1 计算成本相似度矩阵本身是平方级标准注意力计算的第一步是把当前序列里每个 Token 的 Q和所有 Token 的 K 做点积得到一个形状为 n×n 的相似度矩阵。这里的 n 是序列长度也就是上下文里的 Token 总数。这个 n×n 矩阵里面每个元素都是一次点积运算。所以光构造这个相似度矩阵就需要 n² 次运算。上下文长度翻十倍这个矩阵的元素数量就会翻一百倍。不过要说明的是训练阶段和推理阶段对这个矩阵的构造方式不同。训练阶段模型一次读入整段序列Q 和 K 都是同时算出来的所以一次前向就要构造 n×n 矩阵更新所有参数。这就是为什么长序列训练极其依赖加速卡而且显存很容易被中间结果打满。推理阶段模型是逐 Token 生成输出的。每生成一个新 Token不需要一次性构建完整的 n×n 矩阵但需要让当前 Q 和全部历史 K 做点积也就是一次 O(n) 的操作。如果最终输出 m 个 Token那么总计算量大约是 O(n×m)。当输入 1M Token输出 1 万 Token 时这个乘积就是 1M×10K等于 100 亿次点积运算。这个数字已经非常惊人了。3.2 存储成本KV Cache 是长上下文的“显存黑洞”为了让推理时不必重新计算历史 Token 的 K 和 V推理系统会把每个历史 Token 的 K、V 向量缓存下来这就是 KV Cache。KV Cache 的规模可以用一个公式估算KV 缓存大小 2K 和 V 两组 × KV 头数 × 每头维度 × 层数 × 上下文长度 × 每元素字节数这个公式直观地告诉我们KV Cache 的大小与上下文长度成正比。上下文越长显存占用越大。以当前主流的 GQA分组查询注意力配置为例假设模型有 32 层、8 个 KV 头、每个头维度为 128用 2 字节的 bf16 精度存储那么每个 Token 每层需要缓存 2 × 8 × 128 × 2 4096 字节也就是 4 KB32 层下来每个 Token 需要 128 KB。这么算的话100 万 Token 的上下文KV Cache 大约是 128 GB。单独的 H100、A100 80GB 都装不下更别说做并发推理了。就算只在 131K 上下文下KV Cache 也达到了大约 16 GB。这个数字直接决定了推理时的显存容量、请求并发数以及你能不能让模型在足够长的上下文下运行。3.3 带宽成本真正的瓶颈往往不是算力而是数据搬运很多人以为大模型推理慢是 GPU 算力不够。在短上下文场景下算力确实是主要矛盾。但在长上下文场景下真正的瓶颈往往变成了内存带宽。原因是这样的每生成一个 Token系统都要把模型参数从显存读到计算单元里这一步不可避免。但除此之外如果上下文很长KV Cache 也很大系统还要把全部的 KV Cache 从头到尾读一遍才能完成注意力计算。这等于说模型每生成一个字就要把几十 GB、甚至上百 GB 的历史数据搬出来“过一遍”。举一个具体例子如果 KV Cache 有 16 GBGPU 的显存带宽是 3.35 TB/sH100 的 HBM3 规格那么光是读完这批 KV Cache就需要大约 4.8 毫秒。如果 KV Cache 涨到 128 GB这个时间就变成约 38 毫秒。再加上矩阵运算、激活函数、模型参数读取一个 Token 的生成时间很容易达到几十毫秒甚至上百毫秒。这样一算你就会明白为什么长上下文模型在生成时有一种“一个字一个字往外蹦”的感觉。不是模型“思考”变慢了而是它每一步都背着沉重的 KV Cache 包袱在显存带宽这个瓶颈上反复排队。4. 数量级仿真用 Python 亲手算算贵在哪概念讲完最好用代码实际验证一下。下面的 Python 脚本不依赖任何大模型框架只需要安装 NumPy就能模拟全注意力的成本变化趋势。4.1 估算单 Token 生成时的注意力计算量# full_attention_cost.py # 估算全注意力机制中每生成 1 个新 Token 所需的注意力计算量 def attention_flops_per_token(context_len, num_heads32, head_dim128): 单个新 Token 的注意力计算量近似 1. Q 与全部历史 K 做点积2 * context_len * head_dim 2. 权重与全部历史 V 加权求和2 * context_len * head_dim 主项是两处乘加忽略 softmax 等边际开销。 返回单位FLOPs qk 2 * context_len * head_dim weighted_sum 2 * context_len * head_dim return (qk weighted_sum) * num_heads for n in [1024, 8192, 65536, 131072, 1000000]: flops attention_flops_per_token(n) print(f上下文 {n:10,} token每生成 1 个 token 约 {flops/1e9:.1f} GFLOPs)运行这段脚本你会得到类似下面的输出上下文 1,024 token每生成 1 个 token 约 0.1 GFLOPs 上下文 8,192 token每生成 1 个 token 约 1.1 GFLOPs 上下文 65,536 token每生成 1 个 token 约 8.6 GFLOPs 上下文 131,072 token每生成 1 个 token 约 17.2 GFLOPs 上下文 1,000,000 token每生成 1 个 token 约 134.2 GFLOPs可以看到上下文从 1K 涨到 1M单个 Token 的注意力计算量增长了一千倍。这还只是注意力本身不含 MLP、LayerNorm、嵌入投影等模块。如果把全模型考虑进去单 Token 的计算量还会更高但注意力的主导性已经非常明显。4.2 估算 KV Cache 内存占用# kv_cache_size.py # 估算 KV Cache 占用的显存大小 def kv_cache_bytes(context_len, num_layers32, num_kv_heads8, head_dim128, dtype_bytes2): 每层每 Token 需缓存 K、V 两组 2 * num_kv_heads * head_dim * dtype_bytes per_layer_per_token 2 * num_kv_heads * head_dim * dtype_bytes total per_layer_per_token * num_layers * context_len return total for n in [8192, 65536, 131072, 1048576]: b kv_cache_bytes(n) print(f上下文 {n:9,} tokenKV Cache 约 {b/1024**3:.2f} GB)输出上下文 8,192 tokenKV Cache 约 1.00 GB 上下文 65,536 tokenKV Cache 约 8.00 GB 上下文 131,072 tokenKV Cache 约 16.00 GB 上下文 1,048,576 tokenKV Cache 约 128.00 GB当上下文达到 100 万 Token 时KV Cache 已经超过单张 H100 80GB 的显存容量。这就是为什么并不是所有号称“百万上下文”的模型都能在消费级硬件或单卡环境下流畅运行的核心原因。4.3 带宽瓶颈估算继续用上面得到的内存数据和 GPU 带宽做估算# bandwidth_estimate.py # 估算读取 KV Cache 所需的时间 def read_kv_cache_time_us(kv_cache_gb, bandwidth_tb_per_s3.35): return kv_cache_gb / bandwidth_tb_per_s * 1000 for gb in [1, 8, 16, 128]: us read_kv_cache_time_us(gb) print(fKV Cache {gb:3} GB读取耗时约 {us:.1f} ms)输出KV Cache 1 GB读取耗时约 0.3 ms KV Cache 8 GB读取耗时约 2.4 ms KV Cache 16 GB读取耗时约 4.8 ms KV Cache 128 GB读取耗时约 38.2 ms这里使用的是 H100 的理论带宽。实际工程中还要考虑碎片化、内存控制器开销、并发访问冲突等因素实际耗时可能比理论值更高。38 毫秒只够读一次数据而模型生成 1000 个 Token就需要执行 1000 次这样的“读全量 KV Cache”动作总耗时直接叠加。4.4 用最小示例感受线性注意力的状态更新为了对比我们再看一个极简线性注意力状态更新示例。它演示了线性注意力是如何用固定大小的状态去近似不断增长的历史# linear_attention_demo.py # 极简线性注意力状态更新概念演示 import numpy as np def linear_attention_step(q, k, v, S, z, philambda x: x): 不保存全部历史 K/V而是累积两个状态 S phi(k) * v^T z phi(k) S S np.outer(phi(k), v) z z phi(k) out (S phi(q)) / (z phi(q) 1e-6) return out, S, z # 假设隐藏维度为 4每个向量都是 4 维 d 4 S np.zeros((d, d)) z np.zeros(d) # 模拟逐步读取历史 Token并更新状态 for t in range(5): q np.random.randn(d) k np.random.randn(d) v np.random.randn(d) out, S, z linear_attention_step(q, k, v, S, z) print(f第 {t1} 步状态 S 形状{S.shape}输出形状{out.shape})这段代码最大的意义在于S 和 z 的形状固定不会因为历史 Token 数量增加而变大。也就是说无论读了 1K 还是 1M Token状态更新所需的存储和计算都保持在一个固定量级。这正是线性注意力对抗长上下文的武器。5. 线性注意力的基本思路从翻书到整理笔记5.1 换一种方式看待注意力计算全注意力之所以贵是因为它要在每一步生成时从原始历史里重新提取信息。如果把历史比作一座图书馆全注意力相当于每次写新句子都要把整座图书馆重新翻一遍。线性注意力的核心想法是把“重新翻书”变成“维护笔记”。具体做法是不再保存所有历史 Token 的 K 和 V 用于反复扫描而是在读取每一个 Token 时把它的信息以某种形式“累加”到一个固定大小的状态里。后续生成新 Token 时只需要查这份固定大小的状态而不是翻遍整个历史。本质上这是利用了矩阵乘法的结合律。全注意力计算的是(Q × K^T) × V需要先构造 Q 和 K 的相似度矩阵而线性注意力把它改写成Q × (K^T × V)其中K^T × V是对历史信息的一次预汇总可以提前算好并随着新 Token 的到达增量更新。核心区别在于全注意力保留了一切线性注意力选择压缩。压缩意味着信息丢失但也带来了一个关键优势——状态大小不随上下文长度增长。5.2 从“无损回顾”到“有损摘要”这里有一个绕不开的权衡。全注意力是“无损回顾”。它每一步都能让当前 Token 与任意一个历史 Token 做精确的相似度比较信息没有压缩理论上限更高。线性注意力则类似“有损摘要”。它把整段历史压缩成一个固定大小的状态。这个状态有多大决定了它能记住多少细节。如果状态太小早期的关键信息可能会被后续 Token 覆盖或者被噪声淹没。所以现代线性注意力模型通常不是“纯线性”而是会在不同层、不同模块之间做混合。比如某些层保留全注意力用于精确检索某些层使用线性或稀疏注意力用于长距离信息传递。这种混合架构既能控制成本又能尽量保留全注意力的能力上限。5.3 线性注意力的三条技术路线当前线性注意力方向的实现大致可以分为三类技术路线代表思路核心特点主要代价核函数近似Linear Transformer、Performer用核函数替换 softmax把QK^T拆成两个独立函数的点积核函数表达能力有限需要调参状态空间模型S4、Mamba用线性状态空间方程建模序列状态固定大小 全注意力为什么贵？KV Cache与线性注意力技术解析
如果你的工作恰好围绕长文档分析、代码仓库问答、大模型对话系统展开那么你可能已经注意到一个反直觉的现象上下文窗口越大的模型虽然能“读”进更多资料但生成速度往往更慢API 计费也更贵。很多人把这归因于模型变笨了或者纯粹是厂商定价策略的问题。但真正的根源藏在 Transformer 最基础的全注意力Full Attention机制里。这个机制最直白的特点就是模型每生成一个新词都需要把此前所有 Token 的记录从头到尾重新“翻”一遍。上下文如果有几十万甚至一百万个 Token那每蹦出一个新字背后就是几十万次相似度打分和加权计算。你可以把它想象成写一句话就要重读一遍整本书——这就是标题里的“每个新词都要重翻百万页记录”。Kimi Linear 这个名字恰恰是在对这种昂贵的“重翻”做手术。但想真正理解它要解决什么问题必须先弄懂三件事全注意力为什么这么贵贵在计算、存储、带宽哪一个环节线性注意力改变了什么又付出了什么代价这篇文章既不堆公式也不做产品宣传而是用算账、仿真和类比的方式把全注意力的成本结构拆开给你看最后再聊聊 Kimi Linear 这类线性注意力方案背后的技术意图以及它对开发者的实际影响。1. 这篇文章真正要解决的问题先下一个明确判断全注意力机制最大的问题不是精度不够而是复杂度过高——它的计算量随上下文长度呈平方级增长内存和带宽占用则随上下文长度线性增长。这两个“增长”叠加在一起直接决定了长上下文推理的“贵”和“慢”。很多开发者在选择大模型时只看上下文窗口的数字支持 128K、1M或者 10M就认为“能装下这么多内容效果一定不错”。但实际使用时往往发现有落差。例如把一个 10 万字的技术文档丢给模型做问答前面几轮交互还能接受到第 5 轮、第 10 轮输出速度明显下降甚至出现超时。这背后的原因之一就是随着对话轮数增加输入 Token 数量不断累积KV Cache 持续膨胀模型每次生成一个新 Token都需要把这个膨胀后的历史记录重新读一遍。这里真正影响用户体验的不是“模型记住了多少”而是“模型每次生成时翻了多少旧账”。因此这篇文章要解决三个具体问题让你建立一张成本地图全注意力的开销同时发生在计算、存储、内存带宽三个维度后两者往往被忽略。让你学会独立估算大模型推理的成本而不是只听厂商宣传。让你理解线性注意力方案在做哪一类创新它不是在原架构上打补丁而是把注意力计算本身的复杂度结构改掉。除了技术原理文中还会给出可运行的 Python 仿真代码。你可以用这些脚本在本地估算一个长上下文模型大概占多少显存、生成一个 Token 需要多少计算量以及它的带宽瓶颈在哪里。看完之后你再看任何长上下文大模型的性能指标都能迅速判断出谁的架构更适合你的业务。2. 全注意力机制为什么它“记得一切”2.1 从词到向量Token 与 Embedding要理解全注意力的成本得先理解它做什么。大模型处理文本并不是把文字当成字符串而是先把文本切成一个又一个 Token再把每个 Token 映射成高维向量。这个过程叫做 Embedding。比如“Kimi Linear 核心原理”这句话会被切成若干个 Token每个 Token 对应一个向量向量里包含了这个 Token 的语义信息。但是孤立地看每个 Token 是不够的。同一个词在不同上下文里含义完全不同。“苹果”可能指水果也可能指公司“线性”可能指数学概念也可能指注意力架构。Attention 机制要解决的核心问题就是让每一个 Token 都能从整个序列的其他 Token 中按相关度提取信息从而获得“看到上下文”的能力。全注意力机制对这个问题的回答非常彻底它让每个 Token 都与序列里的所有 Token 发生交互一个不漏。这种交互不是简单的拼接也不是预先固定好的规则而是动态计算的——每来一个新 Token都要重新评估它与所有历史 Token 的关联强弱。2.2 Q、K、V像图书馆的索引系统在全注意力机制中每个 Token 会生成三个角色不同的向量QueryQ可以理解为当前 Token 发出的“查询请求”。它代表“我现在想知道什么”。KeyK可以理解为每个历史 Token 的“索引标签”。它决定“我有哪些内容可以被查询”。ValueV可以理解为每个历史 Token 的“正文内容”。一旦查询命中这部分内容就会被取出。注意力计算的流程是这样的先让当前 Token 的 Q与所有历史 Token 的 K 做点积得到一组相似度分数然后把这组分数经过 softmax 归一化变成权重最后用这些权重对所有历史 Token 的 V 做加权求和。求和的结果就是当前 Token 在全局上下文下的新表示。这个流程很像是你在一个巨大的图书馆里找资料你带着一个查询问题挨个翻阅索引卡找到匹配的条目然后把对应书架上的内容抄下来最后按照相关程度综合成一份答案。索引越多、书架越满翻找和抄写的时间就越长。2.3 注意力的“重翻”属性每次都是全新计算现在到了最关键的部分为什么说“每个新词都要重翻百万页记录”因为公式里没有任何依赖前一步“结论”的地方。每当一个新的 Token 进来它都要生成自己的 Q然后拿着这个 Q 去和所有历史 Token 的 K 做点积再对所有 V 做加权求和。这一步无论之前已经生成过多少个 Token都无法跳过或复用为一个“最终答案”。历史 Token 的 K 和 V 会被缓存下来所以不需要重新计算这就是 KV Cache 的由来。但相似度分数、softmax 权重、加权求和的结果每一步都要重新计算一遍。原因很简单下一个 Token 的 Q 和上一个 Token 的 Q 完全不同关注点完全不一样。同一段历史在不同的问题下应该被赋予不同的权重。这也是“全注意力”名字里“全”字的含义。它要求模型在每一次生成时都对全局做完整的加权扫描而不能只依赖一个固定的记忆摘要。这样做的优势是信息无损、理论上限高代价则是每一步都要承担与全部历史长度成正比的扫描开销。3. 新词重翻百万页全注意力的三大成本清单3.1 计算成本相似度矩阵本身是平方级标准注意力计算的第一步是把当前序列里每个 Token 的 Q和所有 Token 的 K 做点积得到一个形状为 n×n 的相似度矩阵。这里的 n 是序列长度也就是上下文里的 Token 总数。这个 n×n 矩阵里面每个元素都是一次点积运算。所以光构造这个相似度矩阵就需要 n² 次运算。上下文长度翻十倍这个矩阵的元素数量就会翻一百倍。不过要说明的是训练阶段和推理阶段对这个矩阵的构造方式不同。训练阶段模型一次读入整段序列Q 和 K 都是同时算出来的所以一次前向就要构造 n×n 矩阵更新所有参数。这就是为什么长序列训练极其依赖加速卡而且显存很容易被中间结果打满。推理阶段模型是逐 Token 生成输出的。每生成一个新 Token不需要一次性构建完整的 n×n 矩阵但需要让当前 Q 和全部历史 K 做点积也就是一次 O(n) 的操作。如果最终输出 m 个 Token那么总计算量大约是 O(n×m)。当输入 1M Token输出 1 万 Token 时这个乘积就是 1M×10K等于 100 亿次点积运算。这个数字已经非常惊人了。3.2 存储成本KV Cache 是长上下文的“显存黑洞”为了让推理时不必重新计算历史 Token 的 K 和 V推理系统会把每个历史 Token 的 K、V 向量缓存下来这就是 KV Cache。KV Cache 的规模可以用一个公式估算KV 缓存大小 2K 和 V 两组 × KV 头数 × 每头维度 × 层数 × 上下文长度 × 每元素字节数这个公式直观地告诉我们KV Cache 的大小与上下文长度成正比。上下文越长显存占用越大。以当前主流的 GQA分组查询注意力配置为例假设模型有 32 层、8 个 KV 头、每个头维度为 128用 2 字节的 bf16 精度存储那么每个 Token 每层需要缓存 2 × 8 × 128 × 2 4096 字节也就是 4 KB32 层下来每个 Token 需要 128 KB。这么算的话100 万 Token 的上下文KV Cache 大约是 128 GB。单独的 H100、A100 80GB 都装不下更别说做并发推理了。就算只在 131K 上下文下KV Cache 也达到了大约 16 GB。这个数字直接决定了推理时的显存容量、请求并发数以及你能不能让模型在足够长的上下文下运行。3.3 带宽成本真正的瓶颈往往不是算力而是数据搬运很多人以为大模型推理慢是 GPU 算力不够。在短上下文场景下算力确实是主要矛盾。但在长上下文场景下真正的瓶颈往往变成了内存带宽。原因是这样的每生成一个 Token系统都要把模型参数从显存读到计算单元里这一步不可避免。但除此之外如果上下文很长KV Cache 也很大系统还要把全部的 KV Cache 从头到尾读一遍才能完成注意力计算。这等于说模型每生成一个字就要把几十 GB、甚至上百 GB 的历史数据搬出来“过一遍”。举一个具体例子如果 KV Cache 有 16 GBGPU 的显存带宽是 3.35 TB/sH100 的 HBM3 规格那么光是读完这批 KV Cache就需要大约 4.8 毫秒。如果 KV Cache 涨到 128 GB这个时间就变成约 38 毫秒。再加上矩阵运算、激活函数、模型参数读取一个 Token 的生成时间很容易达到几十毫秒甚至上百毫秒。这样一算你就会明白为什么长上下文模型在生成时有一种“一个字一个字往外蹦”的感觉。不是模型“思考”变慢了而是它每一步都背着沉重的 KV Cache 包袱在显存带宽这个瓶颈上反复排队。4. 数量级仿真用 Python 亲手算算贵在哪概念讲完最好用代码实际验证一下。下面的 Python 脚本不依赖任何大模型框架只需要安装 NumPy就能模拟全注意力的成本变化趋势。4.1 估算单 Token 生成时的注意力计算量# full_attention_cost.py # 估算全注意力机制中每生成 1 个新 Token 所需的注意力计算量 def attention_flops_per_token(context_len, num_heads32, head_dim128): 单个新 Token 的注意力计算量近似 1. Q 与全部历史 K 做点积2 * context_len * head_dim 2. 权重与全部历史 V 加权求和2 * context_len * head_dim 主项是两处乘加忽略 softmax 等边际开销。 返回单位FLOPs qk 2 * context_len * head_dim weighted_sum 2 * context_len * head_dim return (qk weighted_sum) * num_heads for n in [1024, 8192, 65536, 131072, 1000000]: flops attention_flops_per_token(n) print(f上下文 {n:10,} token每生成 1 个 token 约 {flops/1e9:.1f} GFLOPs)运行这段脚本你会得到类似下面的输出上下文 1,024 token每生成 1 个 token 约 0.1 GFLOPs 上下文 8,192 token每生成 1 个 token 约 1.1 GFLOPs 上下文 65,536 token每生成 1 个 token 约 8.6 GFLOPs 上下文 131,072 token每生成 1 个 token 约 17.2 GFLOPs 上下文 1,000,000 token每生成 1 个 token 约 134.2 GFLOPs可以看到上下文从 1K 涨到 1M单个 Token 的注意力计算量增长了一千倍。这还只是注意力本身不含 MLP、LayerNorm、嵌入投影等模块。如果把全模型考虑进去单 Token 的计算量还会更高但注意力的主导性已经非常明显。4.2 估算 KV Cache 内存占用# kv_cache_size.py # 估算 KV Cache 占用的显存大小 def kv_cache_bytes(context_len, num_layers32, num_kv_heads8, head_dim128, dtype_bytes2): 每层每 Token 需缓存 K、V 两组 2 * num_kv_heads * head_dim * dtype_bytes per_layer_per_token 2 * num_kv_heads * head_dim * dtype_bytes total per_layer_per_token * num_layers * context_len return total for n in [8192, 65536, 131072, 1048576]: b kv_cache_bytes(n) print(f上下文 {n:9,} tokenKV Cache 约 {b/1024**3:.2f} GB)输出上下文 8,192 tokenKV Cache 约 1.00 GB 上下文 65,536 tokenKV Cache 约 8.00 GB 上下文 131,072 tokenKV Cache 约 16.00 GB 上下文 1,048,576 tokenKV Cache 约 128.00 GB当上下文达到 100 万 Token 时KV Cache 已经超过单张 H100 80GB 的显存容量。这就是为什么并不是所有号称“百万上下文”的模型都能在消费级硬件或单卡环境下流畅运行的核心原因。4.3 带宽瓶颈估算继续用上面得到的内存数据和 GPU 带宽做估算# bandwidth_estimate.py # 估算读取 KV Cache 所需的时间 def read_kv_cache_time_us(kv_cache_gb, bandwidth_tb_per_s3.35): return kv_cache_gb / bandwidth_tb_per_s * 1000 for gb in [1, 8, 16, 128]: us read_kv_cache_time_us(gb) print(fKV Cache {gb:3} GB读取耗时约 {us:.1f} ms)输出KV Cache 1 GB读取耗时约 0.3 ms KV Cache 8 GB读取耗时约 2.4 ms KV Cache 16 GB读取耗时约 4.8 ms KV Cache 128 GB读取耗时约 38.2 ms这里使用的是 H100 的理论带宽。实际工程中还要考虑碎片化、内存控制器开销、并发访问冲突等因素实际耗时可能比理论值更高。38 毫秒只够读一次数据而模型生成 1000 个 Token就需要执行 1000 次这样的“读全量 KV Cache”动作总耗时直接叠加。4.4 用最小示例感受线性注意力的状态更新为了对比我们再看一个极简线性注意力状态更新示例。它演示了线性注意力是如何用固定大小的状态去近似不断增长的历史# linear_attention_demo.py # 极简线性注意力状态更新概念演示 import numpy as np def linear_attention_step(q, k, v, S, z, philambda x: x): 不保存全部历史 K/V而是累积两个状态 S phi(k) * v^T z phi(k) S S np.outer(phi(k), v) z z phi(k) out (S phi(q)) / (z phi(q) 1e-6) return out, S, z # 假设隐藏维度为 4每个向量都是 4 维 d 4 S np.zeros((d, d)) z np.zeros(d) # 模拟逐步读取历史 Token并更新状态 for t in range(5): q np.random.randn(d) k np.random.randn(d) v np.random.randn(d) out, S, z linear_attention_step(q, k, v, S, z) print(f第 {t1} 步状态 S 形状{S.shape}输出形状{out.shape})这段代码最大的意义在于S 和 z 的形状固定不会因为历史 Token 数量增加而变大。也就是说无论读了 1K 还是 1M Token状态更新所需的存储和计算都保持在一个固定量级。这正是线性注意力对抗长上下文的武器。5. 线性注意力的基本思路从翻书到整理笔记5.1 换一种方式看待注意力计算全注意力之所以贵是因为它要在每一步生成时从原始历史里重新提取信息。如果把历史比作一座图书馆全注意力相当于每次写新句子都要把整座图书馆重新翻一遍。线性注意力的核心想法是把“重新翻书”变成“维护笔记”。具体做法是不再保存所有历史 Token 的 K 和 V 用于反复扫描而是在读取每一个 Token 时把它的信息以某种形式“累加”到一个固定大小的状态里。后续生成新 Token 时只需要查这份固定大小的状态而不是翻遍整个历史。本质上这是利用了矩阵乘法的结合律。全注意力计算的是(Q × K^T) × V需要先构造 Q 和 K 的相似度矩阵而线性注意力把它改写成Q × (K^T × V)其中K^T × V是对历史信息的一次预汇总可以提前算好并随着新 Token 的到达增量更新。核心区别在于全注意力保留了一切线性注意力选择压缩。压缩意味着信息丢失但也带来了一个关键优势——状态大小不随上下文长度增长。5.2 从“无损回顾”到“有损摘要”这里有一个绕不开的权衡。全注意力是“无损回顾”。它每一步都能让当前 Token 与任意一个历史 Token 做精确的相似度比较信息没有压缩理论上限更高。线性注意力则类似“有损摘要”。它把整段历史压缩成一个固定大小的状态。这个状态有多大决定了它能记住多少细节。如果状态太小早期的关键信息可能会被后续 Token 覆盖或者被噪声淹没。所以现代线性注意力模型通常不是“纯线性”而是会在不同层、不同模块之间做混合。比如某些层保留全注意力用于精确检索某些层使用线性或稀疏注意力用于长距离信息传递。这种混合架构既能控制成本又能尽量保留全注意力的能力上限。5.3 线性注意力的三条技术路线当前线性注意力方向的实现大致可以分为三类技术路线代表思路核心特点主要代价核函数近似Linear Transformer、Performer用核函数替换 softmax把QK^T拆成两个独立函数的点积核函数表达能力有限需要调参状态空间模型S4、Mamba用线性状态空间方程建模序列状态固定大小