2026-06-30 · 🏗️ 基建← 本期
KernelFlume: Elastic Core-Attention Scaling for Agentic Long-Context Decoding
一边是显存告急,一边是算力闲置,长上下文 agent 的推理常卡在这种别扭的失衡里。对话拉得越长,模型要记住的前文越多,可你能加的最小单位,往往是一整张又装满完整模型权重的卡。缺的明明只是放缓存的地方,付的却是复制一整套权重的钱。
问题的根子在一种叫 KV 缓存的东西。可以把它想成模型一边对话一边记的草稿本:每多读一个词,就往本子上多记一笔,方便后面回头查。麻烦是这本草稿随上下文线性变厚,agent 一聊上万字,草稿本就把显存撑满了。而真正做矩阵运算的那部分权重,从头到尾大小固定、一个字节都不会变。两件事的胃口完全不同步,却被绑在同一张卡上一起伸缩。
传统扩容对此几乎没有招。想给注意力多挤点空间,标准做法是再起一个完整副本,把固定不变的权重也跟着复制一遍,等于为了多放几张草稿纸而重买一台打印机。一篇新的 arXiv 论文 KernelFlume 换了个拆法:既然两件事胃口不同,就让它们各走各的。
它把推理节点分成两类。一类只管权重计算,扛着 Projection 和 FFN 这些固定的矩阵核,也就是模型里那批永远不变的参数;另一类索性不带任何权重,专门持有 KV 分区、只做注意力这一摊事。算力和缓存第一次被解耦成两种可以分别采购的资源。
拆开容易,难的是拆开之后两边怎么对话还不拖慢生成。KernelFlume 让两类节点经 UCX 端点通信,那是一套高速的节点间传输通道,并刻意把这步安排在 CUDA Graph 捕获之外——CUDA Graph 是把一长串 GPU 操作预先录下来反复重放、省掉每次调度开销的技巧,通信若塞进录制里就会把路由僵住。更关键的是路由更新压在 token 边界内完成,也就是挤在模型吐出一个词到下一个词的那点间隙里,对外不再多加延迟。
这么一拆,注意力容量就能按每个请求当下的状态单独弹性伸缩:哪个对话的草稿本快爆了,就单给它那一路加注意力节点,不必再陪着复制一整套模型权重。这意味着显存和算力能各自花在刀刃上,而不是为了补一种资源被迫成倍买下另一种。
放回行业里看,这是分离式推理这条路往前又走了一步。这一两年业界已经习惯把读输入的预填充和逐字生成的解码拆到不同卡上各自调度,KernelFlume 再往里切一刀,把注意力从权重计算里单独拎出来,当成一档可以独立扩缩的资源。方向是一致的:让推理资源越分越细,谁紧缺补谁,而不是一刀切地整机复制。
边界也得说清楚。KernelFlume 目前是一篇 arXiv 论文,不是能直接拉来用的产品,动态负载下的效果也只在 Llama-3.1-8B 这一个并不算大的模型上验证过。模型再大几倍,注意力节点和权重节点之间频繁的通信会不会反过来成为新的瓶颈,论文还没给出答案。对正被 KV 缓存逼着不断加卡的 agent 推理团队,它给的是一个值得盯的拆分思路,而这种拆分在更大规模上到底是赚是亏,还要等更重的实测来称。