大模型推理里最反直觉的难题，就是路由问题。这事儿直接催生了各种稀疏注意力机制，从SWA到NSA再到DSA，全是为了收拾它留下的烂摊子。
路由这活儿到底难在哪
先搭个场景。你有一堆计算节点，还有一堆用户请求。节点就是干活的工人，请求就是排队进来的任务。
最朴素的搞法是纯负载均衡。请求1扔给节点1，请求2来了节点1正忙着就扔给节点2，请求3来了前俩都忙着就扔给节点3。雨露均沾，谁也不闲着。这套路要是模型不依赖KV缓存，简直完美。但问题就在于，模型它偏偏就依赖这个。
KV缓存是啥？就是模型在处理你这段话时记下来的“小抄”。你问“上海有啥好吃的”，模型得记住你问了上海，后面回答时才不会扯到北京烤鸭去。这小抄存在节点1上。结果你请求2被扔到了节点2，节点2没你之前的小抄，只能把你刚说过的话重新处理一遍，重新做一遍预填充。同样一批token，换个节点就得重新算一遍，资源就这么白白浪费了。
那就走另一个极端，纯缓存感知路由。请求1去了节点1，小抄存节点1上。请求2来了，一看小抄在节点1，直接也扔节点1。请求3、请求4全都堆节点1上。这就好比全公司就一个人干活，其他人都闲着。节点1忙到冒烟，解码阶段的请求排成长队，用户那边转圈圈转得怀疑人生。完美个啥，这系统照样崩。
俩极端方案往那一摆，就是个经典死局。负载均衡不认小抄，缓存感知不讲公平。这俩诉求天生犯冲，至少在这俩极端操作下完全对着干。
这不就是团队协作里的传话游戏
像啥呢？特别像一个不太正常的工程团队。手里接着工单i+1，你是把它派给手里正捏着工单i上下文的老王，还是扔给一个完全没背景的新人？
老王熟啊，看一眼就知道咋回事，但他正忙着工单i，手里的活儿没撂下。新人倒是有空，接单就能开干，但你得给他从头讲一遍背景，等他搞清楚黄花菜都凉了。
前者是缓存感知的极端，后者是负载均衡的极端。现实里你肯定是两头兼顾。有些活给老王，因为他顺手；有些活给新人，因为老王实在忙不过来。这平衡怎么拿捏，就是路由算法天天烧脑的事儿。
所以路由器的算盘长这样。它得给每个节点算一笔总账：预估排队时间加上未缓存token数量除以预填充速度。哪个节点算出来的总数最小，请求就往哪儿扔。
这事儿的拧巴之处在于，它本质上是个补丁。因为KV缓存只能待在当初算出来的那个节点上，整个集群里没一个共享的KV仓库，大家没法互通有无。
共享KV池子也救不了场
肯定有人拍桌子说不对，Mooncake那套方案不早就搞出来了？共享KV池这概念都能当古董了。
但问题是，道理我都懂，实操全是坑。
头一关，你没法搞个远程或分布式的KV池子。解码阶段对显存带宽的要求变态高，整个计算过程被显存读写卡得死死的。你要做解码，就必须让当前节点把KV块的每一个字节都拽到自己的显存里来。远程拽数据那点带宽，跟显存内部读取比，慢得跟牛车似的。这笔传输成本，你必须硬扛。
第二关，就算有个全局池子，它也只能尽量把KV数据往目标节点传，根本保证不了百分百送到。一来缓存会被踢出去，二来大规模集群里数据传半天是家常便饭。传到一半卡住了，请求还在那干等着，不如本地重新算一遍来得痛快。
就算把话说满，传输永远成功，缓存从不被踢，你照样得面对那个灵魂拷问：到底是等数据传过来划算，还是干脆本地重新算一遍预填充更快？这个账你永远得算。
那你搞个全局KV池子到底图啥呢？就为了记一下每个KV块散落在哪个角落里，然后做个成本对比？又没法直接把KV块从池子里抽出来用，这不是脱裤子放屁么？
这问题是不是只能等网络带宽追上显存带宽那天才能解决？那不就是个死题么。
稀疏注意力就是被路由逼出来的
要是上面俩问题的答案都是肯定的，那出路就只剩一条——把每个请求需要的KV块数量压到最低。这就是各路开源实验室抢着秀新型稀疏注意力的直接原因。
稀疏注意力说白了就是，不去看全量的KV缓存，只挑最关键的一部分出来用。本来要拽100个KV块，现在只用拽20个，传输量直接打八折。那路由压力不就小了？排队时间不就短了？
但注意，这是个被逼出来的妥协方案。它解决不了根本矛盾，只是让矛盾别那么尖锐。好比高峰期地铁太挤，你不是去加车厢，而是规定每人只能带一个小包上车。人还是那么多人，但占的地方小了，勉强能塞进去。
然后就有趣了。你拼命压缩每个请求要带的行李，但你怎么知道该压缩哪些？哪些KV块重要哪些可以扔掉？这就又绕回路由那个老坑了。你依然得做个决策，只不过决策的颗粒度从“去哪个节点”变成了“看哪些KV块”。逻辑链条一模一样。
所以每出一种新稀疏注意力，本质上都是对路由问题的一次逃跑。跑得了和尚跑不了庙，庙里供的还是那尊路由佛。
连LSTM都来凑热闹了
有意思的是，这边厢被路由搞得焦头烂额，那边厢有人翻出了老黄历。Raj Dabre直接怼了一句：醒醒吧，又有人把LSTM重新发明了一遍。
说的就是那个State-Prediction Separation Transformer。把Transformer的隐藏状态拆成两份，一份专门管状态记忆，一份专门管预测下一个词。听着挺新鲜是吧？但搞过深度学习的都知道，LSTM那套门控机制，输入门遗忘门输出门，核心思想就是把长期记忆和短期工作记忆分开处理。兜兜转转一大圈，又走回老路上去了。
这背后折射出来的味道是，Transformer架构在处理长序列时，状态管理和预测输出确实有内在冲突。KV缓存问题只是这个冲突在工程层面的一个爆发点。而路由问题，又是KV缓存问题在分布式系统层面的一个爆发点。层层传导，最后炸在稀疏注意力头上。
大家都在同一个迷宫里转悠，只不过有的人在修墙，有的人在拆墙，有的人在墙上画门假装有出路。
Goodfire那套操作透露的信息
再说说Goodfire搞的事儿。他们在GLM 5.2上复现J-space，训练奖励模型，用强化学习减少幻觉，还拿模型做癌症预测。Silico平台把这事儿包装成产品化了。
这里面有个潜台词。如果你真的能精准定位和修改模型内部的特定知识回路，那路由问题是不是有另一种解法？比如你根本不需要把完整的KV缓存传来传去，只需要传递一个高度压缩的“知识指针”，接收节点自己就能把缺失的上下文重建出来。
这思路跟稀疏注意力完全是两码事。稀疏注意力是尽量少带行李，Goodfire这个方向是压根不带行李，只带个地图，到了地方现买现做。显然更激进，但也更远水解不了近渴。
递归自我提升又是什么鬼
Zhengyao Jiang放出的那个递归自我提升实验，让AI自己研究怎么改进自己，搞了八天，效果干翻了人类工程师调了两年的参数。
这玩意儿跟路由有啥关系？关系大了。如果AI能自我改进推理效率，它自己会不会找到比所有人工设计的稀疏注意力都更优的解？甚至直接绕开路由问题？它会不会自己设计一套全新的KV缓存管理策略，让节点间协同得跟一个人似的？
细思极恐的是，AI改进自己时，它也得面对路由问题。它改进自己所用的计算资源，本身也面临调度和路由。这就套娃了。一个被路由问题困扰的系统，在尝试改进自己以解决路由问题。这画面太美不敢看。
中国学术圈那股清流
最后说句题外话。有篇arXiv论文结尾作者写想娶高中甜心。这事儿在中文技术圈里透着一股子人味儿。
跟前面那些冷冰冰的技术死局一对比，反差强烈。那边是系统瓶颈、网络带宽、显存速度，这边是高中校园、初恋、结婚愿望。技术再复杂，最后落款的还是个人的情感。
路由问题也许真有彻底解决的那天，到时候回头看今天的SWA、NSA、DSA，全是技术演进路上的临时工棚。但那个想娶高中甜心的作者，他的愿望哪怕没实现，也比任何稀疏注意力机制都更让人记住。
所以别被路由困住。它是个难题，但不是全部。
说到底，KV缓存的路由困境是分布式系统里资源调度与状态依赖这对永恒矛盾的又一个马甲。优化手段层出不穷，但问题本身不会消失。搞技术嘛，就是不断用一个新补丁覆盖旧补丁的过程，永远在路上。
只是别哪天发现自己也成了补丁的一部分就好。