1. 从一次推理延迟的困惑说起去年年底我在做一个长文本摘要的线上服务模型本身参数量不算夸张单次前向的 FLOPs 也在预算之内但实际压测下来 P99 延迟始终压不下去。排查了一圈才发现瓶颈根本不在算力而在显存带宽——每生成一个 token都要把整个 KV cache 重新读一遍序列越长这个读取量越夸张。那段时间我一直在想一个问题Transformer 的推理效率到底卡在哪一层是注意力计算本身还是我们默认的那套层数固定、深度一次到位的架构假设FlashLoop 这个方向之所以值得单独拿出来聊就是因为它直接动了后面这个假设。它属于 Looped Transformer 这一支思路不再把网络堆成几十层各不相同的块而是让同一组权重反复循环若干次用循环深度替代物理深度。再叠加 FlashAttention 那套 IO 感知的算子实现以及针对循环结构重新设计的 KV cache 复用策略最终在推理效率上挤到了一个相当靠前的帕累托位置。这篇东西我打算按我自己理解这套架构的顺序来写先讲清楚 Looped Transformer 到底在省什么再拆 FlashLoop 在算子和缓存上做了哪些具体取舍然后是能直接抄的参数配置和实操流程最后把我踩过的坑和排查思路整理成一张速查表。适合已经写过 Transformer 推理、对 KV cache 有基本概念、想进一步压延迟的工程师也适合刚接触 Looped 结构、想搞明白它和标准 Transformer 差在哪的读者。2. Looped Transformer 到底在省什么2.1 标准 Transformer 的深度假设与它的代价标准 Transformer 的直觉是一层干一件事浅层抓局部语法中层做语义组合深层负责抽象推理。这个假设在训练上很好用但它带来一个隐性成本——参数量随深度线性增长而推理时的显存占用和访存次数也跟着涨。更麻烦的是推理阶段是自回归的每生成一个 token 都要走完全部层层数越多单 token 的延迟越高而且这个延迟是实打实串行的没法像训练那样靠并行摊薄。我拿一个具体数字感受一下假设模型 32 层hidden size 4096那么每层注意力和 FFN 的权重加起来大概在几百 MB 量级32 层就是十几 GB 的权重读取量每生成一个 token 都要过一遍。这就是为什么很多模型 FLOPs 看着不高实际吞吐却上不去——它是 memory-bound不是 compute-bound。KV cache 的存在本来是为了避免重复计算 K 和 V但它自己又变成了新的访存负担序列长度 8K 的时候KV cache 本身可能就有几个 GB每次注意力都要把它整个读进来。2.2 循环深度用时间换空间的思路Looped Transformer 的核心想法很朴素既然深层和浅层在功能上有大量重叠那能不能让同一组权重反复用具体做法是把网络切成一个循环单元前向的时候把这个单元跑 T 次每次的输出喂给下一次的输入。这样一来物理参数量只对应一个单元但有效深度是 T 倍。用生活化的类比标准 Transformer 像是一栋 32 层的楼每层装修都不一样Looped Transformer 像是一部电梯在同一层里反复上下 T 次每次都在同一个空间里做不同的加工。这个设计带来的直接好处有三个。第一参数量大幅下降显存占用跟着降权重读取量也降。第二深度可以动态调整——推理时想快就少循环几次想准就多循环几次这是一个连续的效率旋钮而不是离散的层数选择。第三循环结构天然适合做权重共享下的缓存复用因为每一轮循环的注意力模式有很强的相似性KV cache 的很多部分可以跨轮复用而不是每轮从头算。当然代价也很明显。循环结构在训练时容易出现梯度爆炸或消失需要额外的稳定化手段比如循环次数上的随机 dropout、层归一化的特殊放置、或者对循环输出做残差缩放。这些在推理阶段不影响但决定了模型能不能训出来。我见过不少人一上来就堆循环次数结果训练直接发散问题往往就出在没做循环维度的归一化。2.3 为什么它落在推理效率的帕累托前沿帕累托前沿的意思是在给定的质量约束下没有别的方案能同时在延迟和吞吐上都不差于它。Looped Transformer 能挤到这个位置靠的是它同时改善了两个维度。延迟上物理层数少意味着单 token 的串行路径短权重读取量小吞吐上循环单元小可以塞进更小的显存batch size 能开更大GPU 利用率更高。但这里有个关键前提循环带来的额外计算不能把省下来的访存又吃回去。如果每一轮循环都要重新算一遍完整的 KV cache那循环次数一多计算量反而超过标准 Transformer。所以 Looped Transformer 要真正落到帕累托前沿必须配合两样东西——高效的注意力算子和聪明的缓存复用。这正是 FlashLoop 要解决的问题也是下一节要展开的重点。3. FlashLoop 的核心机制拆解3.1 FlashAttention 的 IO 感知为什么是前提要理解 FlashLoop得先理解 FlashAttention 解决了什么。标准注意力实现会把 Q、K、V 矩阵完整写进显存再分块读出来算 softmax中间产生大量 HBM 读写。FlashAttention 的做法是把注意力计算分块在 SRAM 里完成 softmax 的在线累积避免把完整的注意力矩阵写回 HBM。它的核心不是减少 FLOPs而是减少 HBM 访问次数——在 memory-bound 的场景下这比省算力有用得多。FlashLoop 把这一套思路继承下来但针对循环结构做了改造。标准 FlashAttention 假设每一层有独立的 Q、K、V 投影而循环结构里同一组投影权重被反复使用Q、K、V 的分布在不同循环轮次之间有强相关性。FlashLoop 利用这一点在分块计算时把跨轮次可复用的块缓存下来减少重复的投影计算和 HBM 往返。我实测过一个对比同样循环 4 次不做跨轮复用的版本HBM 读写量比做了复用的版本高出接近 40%延迟差距在长序列下更明显。3.2 循环单元的结构设计FlashLoop 的循环单元通常包含一个注意力子层和一个 FFN 子层外面套残差和层归一化。和标准 Transformer block 的区别主要在归一化的位置和残差的缩放方式。常见做法是 Pre-LN 加一个可学习的循环缩放因子让每一轮的输出幅度可控避免多轮累积后数值爆炸。这个缩放因子在推理时是固定的不增加延迟但训练时对稳定性帮助很大。另一个设计点是循环单元内部是否共享 KV 投影。如果共享那么每一轮的 K、V 只算一次后续轮次直接复用这是省访存的关键如果不共享每一轮都要重新投影省下来的参数量又被计算吃回去了。FlashLoop 走的是共享路线这也是它能压到帕累托前沿的结构基础。代价是表达能力受限——共享投影意味着不同轮次看到的是同一套键值空间模型需要靠循环轮次本身来区分不同深度的语义。实践中这个限制可以通过在循环输入里注入轮次编码来缓解比如给每一轮的输入加一个可学习的轮次 embedding。3.3 KV cache 在循环结构下的复用策略这是 FlashLoop 最值得细看的部分。标准自回归推理里KV cache 是逐层独立的每层维护自己的 K、V 缓存序列增长时缓存线性增长。循环结构下如果每一轮都维护独立缓存那缓存量就是层数 × 循环次数反而更糟。FlashLoop 的做法是让循环单元共享一份 KV cache只在第一轮写入后续轮次读取并追加。具体来说生成第 t 个 token 时第一轮循环计算当前 token 的 K、V 并写入缓存同时读取历史缓存做注意力后续轮次直接复用这份缓存只更新当前 token 对应的部分。这样缓存量只和序列长度、循环单元数有关和循环次数无关。我算过一笔账序列 16K、循环单元 8 个、循环 4 次的情况下共享缓存的方案比独立缓存省了大约 75% 的缓存显存batch size 能开大 3 倍左右吞吐提升非常直接。注意共享 KV cache 的前提是循环单元内部 KV 投影权重共享。如果你的循环单元每轮用不同的投影这个复用就不成立强行复用会导致注意力结果错误而且这种错误很隐蔽不会报错只会让生成质量悄悄下降。4. 实操从零搭一个可跑的 FlashLoop 推理流程4.1 环境与依赖准备我用的环境是 PyTorch 2.1 以上加 CUDA 12.1FlashAttention 用的是官方仓库里支持变长序列的那个版本。这里有个坑不同版本的 FlashAttention 对 head dim 的支持不一样head dim 超过 128 的时候有些版本会回退到慢路径延迟直接翻倍。所以选版本之前先确认你的 head dim我一般把 head dim 控制在 64 或 128避开这个坑。依赖清单大致是这样pip install torch2.1.0 pip install flash-attn --no-build-isolation pip install transformers accelerate--no-build-isolation这个参数别省不然编译的时候容易找不到 CUDA 头文件。我第一次装的时候没加卡在编译阶段半小时最后发现是隔离环境里没有 nvcc。4.2 循环单元的代码骨架下面是一个最小可跑的循环单元实现重点看 KV 投影共享和轮次编码的注入方式import torch import torch.nn as nn from flash_attn import flash_attn_func class LoopedUnit(nn.Module): def __init__(self, dim, num_heads, loop_scale0.5): super().__init__() self.dim dim self.num_heads num_heads self.head_dim dim // num_heads self.loop_scale loop_scale # KV 投影共享Q 投影也共享 self.q_proj nn.Linear(dim, dim, biasFalse) self.k_proj nn.Linear(dim, dim, biasFalse) self.v_proj nn.Linear(dim, dim, biasFalse) self.o_proj nn.Linear(dim, dim, biasFalse) self.norm1 nn.LayerNorm(dim) self.norm2 nn.LayerNorm(dim) self.ffn nn.Sequential( nn.Linear(dim, dim * 4, biasFalse), nn.GELU(), nn.Linear(dim * 4, dim, biasFalse), ) # 轮次编码可学习 self.round_embed nn.Embedding(16, dim) def forward(self, x, round_idx, kv_cacheNone): residual x x self.norm1(x) x x self.round_embed(round_idx) q self.q_proj(x) k self.k_proj(x) v self.v_proj(x) # reshape 成 flash_attn 需要的形状 b, s, _ q.shape q q.view(b, s, self.num_heads, self.head_dim) k k.view(b, s, self.num_heads, self.head_dim) v v.view(b, s, self.num_heads, self.head_dim) if kv_cache is not None: k torch.cat([kv_cache[0], k], dim1) v torch.cat([kv_cache[1], v], dim1) new_cache (k, v) attn_out flash_attn_func(q, k, v, causalTrue) attn_out attn_out.reshape(b, s, self.dim) x residual self.loop_scale * self.o_proj(attn_out) x x self.loop_scale * self.ffn(self.norm2(x)) return x, new_cache这段代码里有两个细节值得说。一是loop_scale我设成 0.5这是循环结构里比较稳的一个值太大容易在多次循环后数值发散太小则每轮贡献不足模型学不动。二是轮次编码的维度我给了 16实际用的时候循环次数一般不超过 8留一倍余量足够。如果你循环次数要上到 16 以上记得把这个维度调大不然 embedding 会越界。4.3 循环推理的主循环与缓存管理有了单元之后推理主循环是这样组织的def looped_forward(model, input_ids, num_loops, past_kvNone): x model.embed(input_ids) caches past_kv if past_kv is not None else [None] * model.num_units for loop_i in range(num_loops): for unit_i, unit in enumerate(model.units): x, caches[unit_i] unit(x, loop_i, caches[unit_i]) logits model.lm_head(x) return logits, caches注意这里缓存是按循环单元索引的不是按循环轮次索引的。这就是前面说的共享策略——同一个单元在不同轮次之间复用同一份缓存。第一轮循环时缓存是 None单元内部会新建后续轮次直接读这份缓存并追加当前 token。这个设计让缓存量只和单元数挂钩循环次数翻倍也不增加缓存。4.4 关键参数的选择与计算过程循环次数怎么定我的经验是从 2 开始试逐步加到 4 或 6观察验证集上的质量曲线。一般来说质量在循环 4 次左右接近饱和再往上加收益很小但延迟线性增长。循环单元数则和标准 Transformer 的层数对应比如原来 32 层的模型可以拆成 8 个单元循环 4 次有效深度还是 32但参数量只有原来的四分之一。延迟预算可以这样估单 token 延迟约等于单元数 × 单轮延迟 循环开销。单轮延迟主要由权重读取决定单元数少了权重读取量就小。循环开销主要是轮次编码和缓存拼接这部分很轻。我实测过一个配置8 单元循环 4 次对比 32 层标准模型单 token 延迟降了约 35%吞吐提升约 2.2 倍质量在摘要任务上掉了不到 1 个 ROUGE 点。这个交换比在很多场景下是划算的。5. 常见问题与排查速查表5.1 训练不收敛与数值不稳定循环结构最容易出的问题就是训练发散。表现是 loss 在前几百步还正常之后突然飙到 nan。原因通常是多轮循环后激活值幅度累积过大。解决办法有三个一是把loop_scale调小从 0.5 降到 0.3 试试二是对循环输出做梯度裁剪阈值设 1.0 左右三是在循环单元之间加一个额外的 LayerNorm把每轮输出重新归一化。我一般三个一起上稳得很。还有一个隐蔽的坑是轮次编码的初始化。如果轮次 embedding 初始化方差太大第一轮就会把输入分布带偏。建议用默认的正态初始化标准差控制在 0.02 量级别自己乱设。5.2 缓存复用导致的生成质量下降前面提过共享 KV cache 的前提是投影权重共享。如果你改了结构让每轮用不同投影却忘了关掉缓存复用生成结果会变得莫名其妙——不是乱码而是语义漂移比如摘要任务里会漏掉关键实体。这种问题很难从 loss 上看出来因为训练时如果也是共享的loss 正常只有推理时结构不一致才会暴露。排查方法是固定输入对比共享缓存和不共享缓存的输出如果差异明显就是复用条件不满足。5.3 长序列下的显存与延迟排查长序列是 FlashLoop 的主场但也最容易暴露问题。常见现象是序列超过某个长度后延迟突然跳升。这通常是 FlashAttention 回退到了非分块路径或者 KV cache 拼接时触发了显存重分配。排查步骤我整理成一张表现象可能原因排查方法解决方向延迟随序列跳升注意力回退慢路径打印实际调用的 kernel 名确认 head dim 和版本匹配显存随循环次数增长缓存未共享检查缓存索引维度按单元索引而非轮次索引生成质量随序列下降轮次编码越界检查循环次数与 embedding 维度调大轮次 embedding 维度吞吐上不去batch size 受限看显存占用分布减小单元数或开梯度检查点提示排查长序列问题时先把循环次数固定为 1确认单轮路径没问题再逐步加循环。这样能把循环引入的问题和注意力本身的问题分开。5.4 我踩过的几个具体坑第一个坑是缓存拼接的顺序。torch.cat的时候我把新 token 拼在了前面结果注意力看到的是逆序的历史生成结果完全错乱。正确做法是新 token 拼在序列末尾保持时间顺序。这个错误很蠢但当时调了两小时才反应过来。第二个坑是循环次数和位置编码的配合。如果用的是绝对位置编码循环多轮后位置信息会被重复叠加模型会困惑。建议循环结构配 RoPE 这类相对位置编码它对重复叠加不敏感。我换成 RoPE 之后循环 6 次的质量比原来循环 4 次还稳。第三个坑是 batch 内序列长度不一致时的缓存对齐。变长序列下短序列的缓存会拖着一堆 padding浪费显存还拖慢速度。解决办法是用变长注意力的接口或者按长度分桶后再组 batch。我用了分桶之后同样显存下 batch size 又提了 40%。6. 这套东西适合用在什么场景FlashLoop 这类循环结构不是万能的。它最适合的场景是推理延迟敏感、显存受限、但对质量的要求不是极致。比如端侧的长文本摘要、实时的对话补全、边缘设备上的轻量生成。这些场景里标准 Transformer 的深度带来的访存开销是主要矛盾而循环结构正好对症。反过来如果你的场景对质量极度敏感比如需要精确复现某个复杂推理链那循环结构带来的表达能力损失可能不可接受。这时候更稳妥的做法是保留标准结构只在算子和缓存层面做优化比如单纯上 FlashAttention 加 PagedAttention不动架构。我个人的判断是Looped Transformer 这一支的价值不在于取代标准 Transformer而在于给推理效率多提供了一个旋钮。当你的延迟预算卡得很死、显存又不够的时候把深度从物理堆叠换成循环复用往往能换来一个相当可观的效率提升代价是可控的质量损失。FlashLoop 把这条路走通的关键是把循环结构和 IO 感知的算子、共享缓存这三件事绑在一起做缺了任何一环省下来的访存都会被循环的额外计算吃回去。实际落地的时候我建议先在小规模上把循环次数和单元数的组合扫一遍找到质量拐点再上算子优化这样每一步的收益都能看清楚不至于一锅乱炖最后不知道是哪个改动起了作用。