相似任务GPU分配技术实现大模型推理速度提升14%突破

发布时间：2026-07-17 05:19:11 来源：安智兰德资讯网 作者：探索

这项由韩国科学技术院（KAIST）与微软研究院（北京、相似现雷德蒙德）联合开展的任务研究，于2026年7月1日以预印本形式发布，配技论文编号为arXiv:2607.00466，术实速度有兴趣深入了解的模型读者可以通过该编号查询完整论文。研究的推理提升突破核心目标是解决一个听起来简单、实则颇为棘手的相似现问题：当你向ChatGPT或类似的AI助手发问时，背后服务器如何把你的任务请求"交给"哪台机器来生成回答，才能让你等待的配技时间尽可能短？

现代大型AI模型已经越来越多地采用一种叫做"专家混合"的架构——不妨把它理解成一个大公司里有很多不同部门的专家，每次回答问题时只需要调动其中几位专家，术实速度而不是模型让全公司所有人都出马。这样做的推理提升突破好处是节省计算资源，但研究团队发现，相似现这种架构在实际运行时隐藏着一个被人忽视的任务"堵点"：哪几位专家被同时叫来开会，对整体速度的配技影响远远大于同时处理多少个请求。正因为此，仅仅把请求平均分配给各台服务器是不够的，还需要考虑"让有相似需求的请求尽量坐在同一张桌子上"。

研究团队为这个问题设计了一套完整的解决方案，命名为ELDR（专家感知解码路由）。经过在最多40块GPU组成的实际服务器集群上测试，这套方案在三种不同的主流大模型和两种不同的用户请求场景下，都能稳定地把用户等待每个词生成的时间（即TPOT，每输出词耗时）中位值压缩5.9%到13.9%，而生成的答案内容与原来完全一致，没有任何精度损失。

一、为什么"专家混合"模型的服务器调度是个难题

要理解这项研究解决的问题，先得了解现代AI大模型的一个重要运作方式。当你向AI发出一个请求时，背后的服务器需要完成两个性质截然不同的工作阶段。第一个阶段叫做"预填充"：服务器把你输入的整段提示词一口气读完并处理，这个过程类似于厨师把菜谱完整读一遍，速度快但需要很强的计算能力。第二个阶段叫做"解码"：服务器一个词一个词地生成回答，就像厨师按照菜谱一步步烹饪，每步都要等上一步完成，速度慢、对延迟非常敏感。

过去，人们发现把这两个阶段分开在不同服务器上运行更好，这种架构叫做"预填充-解码分离"（PD分离）。道理很简单：如果厨师既要快速阅读菜谱又要慢慢炒菜，这两件事互相打扰。分开之后，一组服务器专门负责读菜谱，另一组专门负责炒菜，效率更高。但分离之后，就出现了一个新问题：每来一个请求，系统需要决定把它送给哪台"炒菜"服务器。这个决策就叫做"路由"。

现有的路由策略只做一件事：让各台解码服务器的请求数量尽量均等，就像饭店里服务员平均分配给每张餐桌的顾客数量。对于普通的"密集型"模型，这完全够用，因为每台服务器做的工作性质相同。但对于"专家混合"（MoE）模型，这个策略就显得不够精细了。

"专家混合"模型的核心机制是：对于每一个输入的词，模型的"门控网络"会从所有专家中挑选少数几位（比如128位专家中挑8位）来处理。这个"挑选"的过程虽然让模型更高效，却在解码阶段制造了一个微妙的麻烦。解码时，服务器的速度瓶颈不在于计算量，而在于从显存中读取权重数据的速度——就像读书的速度不取决于你脑子有多快，而取决于你翻页的速度。每一步解码，服务器需要把当前批次所有请求激活的专家权重都从显存中读出来。如果这批请求激活的专家各不相同，服务器就要读很多不同的"书页"；如果这批请求激活的专家高度重叠，很多"书页"只需要读一次就能为多个请求服务。

研究团队实测了这一效应。在Qwen3-30B-A3B模型上，当一个批次激活的专家从16个增加到128个时，MoE层的延迟增加了4.7倍；而在专家数量固定的情况下，批次大小从32增加到128，延迟几乎没有变化。这个发现揭示了一个被以往路由策略完全忽视的规律：决定解码速度的，是同一批次里被激活的专家种类有多少，而不是批次里有多少请求。

二、专家的选择其实是有规律可循的

发现了问题之后，研究团队进一步追问：不同请求激活的专家，是随机的吗？如果是随机的，那把相似请求聚集在一起也没有意义。但如果专家的选择有某种内在规律，那就大有文章可做了。

答案是：专家的选择高度依赖请求的"类型"，有非常清晰的规律。研究团队在三个主流MoE模型（Qwen3-30B-A3B、GPT-OSS-120B、Gemma-4-26B-A4B）上做了系统测试，把请求按照任务类型（代码、数学、医疗、法律）和语言类型（英语、中文、俄语、法语）分组，观察不同组的请求倾向于激活哪些专家。

结果非常清晰：代码类请求有自己偏好的一批专家，数学类请求有另一批，医疗和法律类各有各的偏爱。同样，英语请求、中文请求、俄语请求激活的专家区域也是各自不同的。这就好像公司里不同部门的员工开会，销售部每次都叫财务和市场，技术部每次都叫工程师和测试员，两个部门几乎不会叫同一批人。

更有价值的发现是：同一类型的请求在解码阶段激活的专家比混合类型的请求少17%到21%（任务维度）或3%到10%（语言维度）。换句话说，把相似请求放在同一台服务器上，每一步解码需要读取的"书页"数量会显著减少，速度自然就快了。

但问题是，路由决策发生在解码开始之前——那时候还没有产生任何输出词，怎么知道这个请求会激活哪些专家呢？关键突破在这里：预填充阶段和解码阶段走的是同一套门控网络，因此在预填充时激活的专家和解码时激活的专家高度相关。研究团队测量了这个相关性，在三个模型上的Pearson相关系数分别为0.90、0.70和0.92。这意味着，只要看完预填充阶段留下的专家激活记录，就能很好地预测这个请求在解码时会用哪些专家——路由决策所需的信息恰好在路由必须做出的那一刻已经准备就绪了。

三、如何把专家激活信息浓缩成一个可以比较的"指纹"

知道了专家激活有规律，且预填充信息可以预测解码行为，下一步就是设计一种方法，把每个请求的预填充专家激活情况压缩成一个紧凑的"指纹"，使得指纹相似的请求在解码时激活的专家也高度重叠。研究团队把这个指纹称为"专家签名"。

设计签名的核心挑战在于：如何让签名的距离真正反映解码时专家重叠的程度？原始数据是每一层网络中每个专家被多少个预填充词激活的计数，但直接用这些原始计数有两个问题。第一，有少数"通才专家"几乎对所有请求都会被激活，它们在计数上占主导地位，但对区分不同类型的请求毫无帮助，反而会干扰比较。第二，模型有很多层网络，每层都产生专家激活数据，但不同层对区分请求类型的贡献大相径庭，把所有层都纳入只会引入噪音。

针对第一个问题，研究团队借用了信息检索领域的一个经典技巧——逆文档频率（IDF）加权。道理很直白：一个在几乎所有请求中都出现的专家，就像一个在所有文章里都出现的常用词（比如"的"、"是"），它携带的区分信息量很少，应该降低权重；而一个只在特定类型请求中出现的专家，就像一个罕见的专业词汇，携带的信息量很大，应该提高权重。经过IDF加权之后，签名更能捕捉到请求之间的真正差异。

针对第二个问题，研究团队设计了一个贪心层选择算法：从空的层集合开始，每次加入一层，看哪一层的加入能最大程度提升签名与实际解码专家激活之间的相关性（用Spearman秩相关系数衡量），如此反复，直到相关性不再提升为止。实验发现，每个模型和任务组合都存在一个最优的层数，超过这个数量之后加入的层反而会稀释签名的质量。

研究团队还系统比较了六种不同的签名构建方式：直接用激活计数、用IDF加权的激活计数、用计数的平方根、用门控网络的softmax概率输出、用门控网络的原始分数输出、以及用二值化的激活指示符。结果显示，IDF加权的离散激活计数效果最好，平均相关性为0.76，明显优于基于门控概率的连续签名（0.62）。原因在于：解码时实际起作用的是被离散地选中进入top-k的专家，而门控概率会把质量分配给那些根本不会被选中的专家，造成信息的稀释和误导。

最终，每个请求的签名就是：在最优层子集上，经过IDF加权的专家激活计数拼接在一起，再做L2归一化（除以向量的长度，使比较只反映激活模式的形状而非请求长度）。

四、离线准备：给每台解码服务器划定"专属领域"

有了签名，下一步是决定如何把签名空间划分给不同的解码服务器，使得每台服务器负责的请求在专家使用上尽可能集中。研究团队采用了K均值聚类算法：把一批校准请求的签名聚成K个组（K等于解码服务器的数量），每组对应一台服务器，每台服务器有一个"中心点"代表其专属领域。

但普通的K均值聚类有一个缺陷：它只追求组内签名尽可能接近中心点，不管每组的大小是否均衡。在实际的用户流量中，某些类型的请求（比如英语）远远多于其他类型，这会导致聚类结果严重不均衡——大部分服务器被分配给密集的主流请求区域，几台服务器被分配给稀疏的边缘区域，造成运行时的负载失衡。

解决方案是引入"匈牙利均衡K均值"：在聚类时加入一个硬性约束，要求每组的大小不能超过总量的K分之一。具体实现上，每次分配请求到组时，不是让每个请求各自找最近的中心点，而是用匈牙利算法（一种全局最优分配算法）找到一个全局最优的分配方案，既最小化总距离又满足均衡约束。这样得到的聚类结果，每台服务器在校准数据上承担的流量大致相等，从根本上避免了结构性的负载不均衡。

研究团队把校准签名投影到二维空间并可视化，发现代码、数学、医疗、法律任务确实分布在不同区域，英文、中文、俄文、法文请求也各占一片。均衡K均值的中心点均匀覆盖了这些不同区域，而非扎堆在最密集的主流区域，这正是均衡约束带来的好处。

五、在线路由：在本地专家偏好和实时负载之间找平衡

离线准备好了每台解码服务器的"中心点"之后，每当一个新请求完成预填充，系统就需要实时决定把它送去哪台解码服务器。

最简单的想法是：计算请求签名与所有K个中心点的余弦相似度，直接送去相似度最高的那台服务器。但这会产生一个实际问题：如果某类请求在短时间内集中到来（这在真实流量中很常见），它们都会被送去同一台服务器，造成瞬时的过载，而其他服务器却闲置着。

研究团队设计的在线路由规则叫做"局部性带宽路由"：首先找到相似度最高的中心点，记其相似度为s；然后把所有相似度不低于s减去一个阈值τ的服务器都纳入候选集合（这个候选集合就是"局部性带宽"）；最后在候选集合中选择当前正在处理的请求数最少的那台服务器。

这个机制有一个自然的自适应性：如果请求的签名与某个中心点高度匹配、与其他中心点相差甚远，那么候选集合很小（只有一两台），局部性得到严格保障；如果请求的签名处于几个中心点的交界地带，候选集合较大，负载均衡的权重更高。参数τ在0到1之间调节，τ=0意味着严格top-1路由，τ=1意味着完全按最短队列路由，研究团队通过实验确定τ=0.1是最优点。

实测结果验证了这个设计的必要性：纯top-1路由（τ=0）在六种测试场景中有四种出现了尾部延迟回退，最严重的比轮询路由差7.9%；加入τ=0.1的带宽之后，所有场景的尾部延迟回退都消失了，中位数延迟进一步改善5.2%到12.7%。

六、处理前缀缓存的特殊情况

现代AI服务系统普遍使用一种叫做"前缀缓存"的技术：如果两个请求的提示词前面部分完全一样，第二个请求可以直接复用第一个请求已经计算好的中间结果（KV缓存），跳过这部分的预填充，大大节省时间。这在有大量相似前缀的场景下（比如系统提示词相同的聊天场景）效果显著。

但前缀缓存对专家签名造成了一个麻烦：如果某个请求的前缀命中缓存，那么这部分前缀的专家激活信息根本就没有被重新计算，签名因此是不完整的。而恰恰是那些"前缀命中"的请求，签名信息最容易残缺，导致路由决策失准。

一个直观的解决办法是把每个请求的完整签名缓存起来，以后相同请求来了直接复用。但这只能处理完整相同的请求，对于部分命中（前面若干块缓存命中、后面需要重新计算）的情况完全无效，而部分命中在实际中非常常见。

ELDR的解决方案是：把签名缓存的粒度降低到与KV缓存一致的"块"级别。KV缓存是按固定大小的块来管理的，每个块存储若干个词的中间状态。ELDR为每个KV缓存块都维护一个对应的签名块：这个块里每个词激活的专家信息。当一个请求的某些块命中前缀缓存时，对应的签名块直接从签名缓存中读取；未命中的块在这次预填充时即时计算。最终，把所有块的签名加起来，就得到完整的请求签名，效果等同于对完整提示词做了一次完整的专家激活统计。

签名缓存与KV缓存共享相同的块索引，一个块被逐出时，对应的签名块也同时释放，不需要额外的管理逻辑。整个签名缓存的存储开销非常小：对于所有测试的模型，签名缓存的大小不超过KV缓存的0.24%。实验验证显示，打开前缀缓存之后，TPOT（每词延迟）的改善效果与不开缓存时几乎完全相同，说明两种优化的收益可以完全叠加。

七、实际测试：在真实服务器集群上的全面评估

研究团队在一个由5台服务器组成的集群上进行了系统评估，每台服务器配备8块AMD MI300X GPU，GPU间通过400Gbps InfiniBand高速网络互联，总共40块GPU。所有实验在vLLM推理框架上运行。

测试对象是三个主流MoE模型：Qwen3-30B-A3B（128个专家，每次激活8个）、GPT-OSS-120B（128个专家，每次激活4个）、Gemma-4-26B-A4B（128个专家，每次激活8个）。另外还测试了一个更大的模型Qwen3-235B-A22B，用于验证在更复杂的分布式部署场景下的效果。

测试场景分为两类。"任务"场景包含近1.2万条涵盖代码、数学、医疗、法律四类任务的请求，各类任务数量有一定差异，最大类与最小类之比约为1.41，对负载均衡构成一定挑战。"语言"场景包含1.4万条来自WildChat数据集的多语言请求，英语和中文合计占约75%，语言分布极度不均衡，对负载均衡的挑战更大。

对比的基线路由策略包括四种纯负载均衡方法（随机路由、轮询路由、最短队列路由JSQ、两选一随机路由P2C），以及一种"预知领域标签"的局部性路由基线（Domain，相当于作弊版：假设系统事先知道每个请求的任务类别或语言，按类别分配服务器）。

主要实验配置是8台预填充服务器加16台解码服务器（8P16D），在每秒20到100个请求的不同负载下测试，每个负载运行120秒（加30秒预热）。

在任务场景下，ELDR在三个模型上的中位TPOT比最好的负载均衡基线改善7.0%到13.9%，尾部（P99）TPOT改善3.4%到6.0%。Domain基线在这里表现也不错，毕竟任务类别标签与专家激活区域对应得比较好，Domain本身比负载均衡基线改善6.8%到9.7%；但ELDR仍然比Domain更好1.4%到6.9%（中位）和1.6%到4.5%（尾部），因为ELDR的K=16个签名簇比Domain的4个任务类别更细粒度，能捕捉同一任务类别内的专家差异，而且τ带宽允许跨簇的负载平衡。

在语言场景下，由于英语和中文占据了约75%的流量，Domain策略严重过载了被分配到这两种语言的服务器，尾部延迟反而比轮询路由差了最多6.1%，在中位数延迟上也只与轮询路由持平。ELDR则在中位TPOT上比最好的负载均衡基线改善5.9%到10.0%，并在同等或更好的尾部延迟下实现这一改善，比Domain改善5.7%到9.1%（中位）和7.0%到9.5%（尾部）。

运行开销方面，ELDR每个请求增加的额外处理时间约为0.86毫秒，占典型的69毫秒首词等待时间的1.2%，几乎可以忽略不计。签名缓存的显存占用约为KV缓存的0.24%，每个请求携带的签名数据约12KB，与动辄数MB的KV状态传输相比微不足道。

八、系统扩展性与大模型场景验证

研究团队还验证了ELDR在不同规模下的表现。随着解码服务器数量从8台增加到16台再增加到24台，ELDR对轮询路由的中位TPOT改善从8.0%增加到9.8%再增加到10.2%。这个趋势完全符合预期：更多的解码服务器意味着每台服务器承担更窄的签名区域，对应更小的专家激活集合，带来更大的延迟节省。

在最大规模的测试中，研究团队把ELDR应用于Qwen3-235B-A22B这个有2350亿参数的巨型模型，使用40块GPU（跨越全部5台服务器），每台解码实例采用4路张量并行加4路专家并行。在这种配置下，单纯的请求聚类还不够，还需要处理专家并行带来的额外负载不均衡——即便同一台服务器内，如果某些专家热度过高，承担这些专家的GPU也会成为瓶颈。研究团队针对每个签名簇的预期专家激活模式，为每台解码服务器单独优化了专家到GPU的分配方案，让每台服务器内各GPU的负载尽可能均衡。最终，在24到56个请求每秒的负载下，ELDR将中位TPOT改善2.7%到4.3%，尾部TPOT改善0.6%到2.0%，证明方案能在大规模分布式场景下依然有效。

说到底，这项研究做的事情用一句话概括就是：当AI服务器在分配"谁来生成这段回答"时，不能只看哪台服务器比较空闲，还要看哪台服务器当前的"工作伙伴"与这个请求最相似。请求相似，激活的专家相似，大家共用同一批"书页"，每步生成的等待时间自然缩短。

归根结底，ELDR的巧妙之处在于它完全不改动模型本身，不改变任何专家选择的决策，不影响输出内容，只是在"把请求送到哪里"这个决策上多考虑了一个维度。而这个额外维度所需的信息，恰好在系统必须做出决策的那一刻——预填充刚结束、解码尚未开始的瞬间——已经唾手可得。

这项研究提出了一些值得继续探索的问题：当用户请求的类型随时间发生漂移（比如某个热点事件突然涌来大量相关请求），如何快速更新签名簇的划分？在请求类型更加多样、边界更加模糊的真实互联网流量下，专家签名的预测质量会如何变化？这些都是未来可以深入研究的方向，感兴趣的读者可以通过论文编号arXiv:2607.00466查阅完整内容。

Q&A

Q1：专家混合模型（MoE）和普通大模型有什么区别，为什么路由策略对它特别重要？

A：普通大模型处理每个词时会调用全部神经网络参数，而专家混合模型只调用其中一小部分专家——比如128个专家里只选8个。这在节省计算量的同时产生了一个副作用：解码时服务器需要把当前批次所有被选中的专家权重都从显存读出来，读取的种类越多、速度越慢。ELDR研究发现，激活专家的数量从16个增加到128个会让延迟增加4.7倍，因此把激活专家相似的请求放在同一台服务器上至关重要。

Q2：ELDR的专家签名缓存和普通的前缀KV缓存有什么不同，为什么要分开处理？

A：KV缓存存储的是模型中间层的注意力键值状态，用来跳过重复前缀的计算；专家签名缓存存储的是每个KV块对应的专家激活统计，用来恢复被缓存跳过部分的专家信息。两者在块粒度上完全对齐、共享相同的块索引，但服务于不同目的。没有签名缓存时，前缀命中的请求签名是残缺的，路由会失准；有了签名缓存，把缓存块的签名加上新计算块的签名，就能重建完整的路由所需信息，额外存储开销不超过KV缓存的0.24%。

Q3：ELDR的局部性带宽路由里的参数τ是怎么确定的，调大调小各有什么影响？

A：τ控制候选服务器的范围宽窄。τ=0时只送去相似度最高的那台服务器，局部性最强但遇到突发流量会过载，实测有四种场景尾部延迟变差。τ=0.1时引入少量灵活性，所有场景的尾部延迟回退消除，中位延迟改善5.2%至12.7%。τ继续增大，可以进入候选的服务器越来越多，越来越接近纯最短队列路由，局部性收益逐渐稀释，中位延迟改善开始缩水。研究团队通过在六个模型-数据集组合上系统扫描，确定τ=0.1为最优平衡点。

相关文章