港科大新发现：MoE路由很脆弱！重复token输入阻塞负载均衡 | ICML'26

MoE大模型正在成为高效推理的主流路线。

它把一个大模型拆成很多「专家」，每个token只激活其中一小部分。这样一来，模型总参数可以很大，但每次推理的实际计算量不会爆炸。对服务商来说，这几乎是一个甜蜜的工程答案：更大模型，更低成本，更高吞吐。

但这篇来自ICML 2026的工作发现，MoE模型最重要的组件之一——专家路由里，藏着一个新的系统级风险。

来自港科大的研究团队提出了RepetitionCurse，这是一种针对MoE大模型服务的黑盒压力测试方法。

它不需要模型权重，不需要梯度，也不需要知道后端专家如何部署，只利用高度重复的输入模式，就能诱导专家路由把大量token路由到同一小批专家上。

论文链接：https://arxiv.org/abs/2512.23995

结果某些GPU被打成straggler，其他GPU空等同步，最终拖慢time-to-first-token（TTFT），也就是用户看到第一个token的时间。

实验显示，在常见8-GPU EP部署上，RepetitionCurse可让MoE模型的TTFT增加20%到148%。

攻击原理

MoE的router，本质上像一个分诊台。

每个token来了之后，router会判断它该交给哪些专家处理。

正常文本有丰富语义，token的隐藏表示比较分散，router通常会把它们分给不同专家，这也是MoE模型训练时非常注重的专家负载均衡。

而RepetitionCurse利用的是另一个极端：当输入里出现高度重复的token模式时，连续token的表示会变得非常相似。

对router来说，这些token像一群「长得几乎一样的客人」，于是被反复送进同一批专家。

正常输入下，3个GPU负载接近33%/34%/33%；RepetitionCurse输入下，负载可能变成98%/1%/1%，一个GPU变成straggler，其他GPU必须停下等待。

问题从这里开始变得系统化。

在实际部署中，MoE模型通常使用Expert Parallelism，也就是把不同的完整专家放到不同GPU上。正常情况下，这能分摊计算压力；但如果大量token都被路由到同一GPU上的专家，那张GPU就会成为瓶颈，而其他GPU即使没干多少活，也必须等它完成之后才能继续同步，导致系统出现单点拥堵。

Mixtral-8x7B上，正常输入的专家负载分布较均匀；RepetitionCurse 会让大量token在多个层上集中到少数专家，热力图出现明显高亮块。

论文把这种现象称为routing collapse。攻击输入让router的选择从「分散派单」变成「固定派单」，最终把MoE的并行优势反过来变成系统短板。研究团队指出，RepetitionCurse可以在黑盒场景下工作，不依赖模型参数，也不依赖后端routing细节。它的目标也不是控制输出内容，而是拖慢prefill阶段，从而放大TTFT。

过去MoE模型的安全问题通常只在模型输出层被考虑，例如「让模型生成很长」「让模型无限思考」「让Agent调很多工具」，研究人员指出它们在服务系统层也可能有可被利用的安全漏洞，即便输出只生成1个token，也可能通过破坏每个输入token的计算效率，让服务变慢。

攻击效果

对用户来说，大模型卡不卡，最直观的指标就是TTFT。

TTFT指从请求到达，到第一个token返回之间的时间。它是聊天机器人、Copilot、搜索问答、Agent服务里非常关键的体验指标。用户不一定知道后端用了多少GPU，但一定能感觉到「怎么还不开始说话」。

论文用一个简单指标衡量延迟放大：

如果这个值是2.48，就意味着攻击输入下，第一个token的返回时间是正常输入的2.48倍。

研究团队在vLLM上部署目标模型，使用ShareGPT中2048条用户请求进行测试。结果很直接：EP size越大，RepetitionCurse越容易把并行系统「拧成单线程」。

在Mixtral系列上，8-GPU部署下TTFT最高增加148%。在更稀疏的Qwen3-30B-A3B系列上，当EP size扩到32时，TTFT最高增加115%。

在常见8-GPU设置下，RepetitionCurse还会把原本P99的SLA保证拉低到P98.6到P86.4，意味着服务违约率从1%上升到最高13.6%。

不同MoE模型在不同EP size下的TTFT LAR。

更麻烦的是，LLM服务不是一个请求一个请求孤立执行的。为了吞吐，服务系统会把多个请求打包成batch。这意味着攻击请求可以「搭车」影响正常请求。

论文分析了两种场景。

第一种是mixed-user batches：攻击请求和正常用户请求进入同一个batch。此时，正常用户明明没有发送异常输入，也会一起等待被拖慢的batch完成。

第二种是attack-only batches：某段时间里只有攻击请求进入系统。即便正常用户没有和攻击请求同batch，攻击请求也会占用prefill能力，导致后续正常请求排队更久。

攻击请求不仅增加同batch用户的TTFT，还会让后续batch的排队时间上升，影响沿服务队列传播。

RepetitionCurse不需要让后端GPU全部满载。它只需要制造一个足够慢的straggler，就能让同步机制把其他GPU一起拖住。

机制解释

研究人员除了发现「重复输入会造成路由失衡」，还进一步发现MoE模型里存在一批脆弱专家。

这些专家像路由空间里的「吸引子」。当某些重复token出现时，它们会被异常稳定地吸过去。换句话说，系统并不是随机坏掉，而是有一批专家天然更容易成为攻击流量的落点。

为了刻画这一点，研究团队对词表进行了扫描：对于每个expert，统计有多少token在构造RepetitionCurse输入后，会让该expert接收到超过90%的prompt token。这个数量越大，说明该expert越像一个attractor，也就是越脆弱。

论文还用一个有效专家数指标来描述每层里真正承担「吸引作用」的专家数量：

其中是第l层被路由到专家e的token数量百分比。直观理解，越小，说明触发token越集中到少数专家上；如果它接近top-k，就意味着一整层里真正容易被吸引的专家数，几乎只剩router每次会选的那几个。

每个格子表示某个expert对应的trigger token数量。颜色越深，说明该expert越容易吸引重复token。右侧的exp(H)展示每层有效吸引专家数。

上图呈现出一个很有意思的层级规律：早期层和最后几层的脆弱性分布更广，trigger tokens相对分散；中间层则明显更稀疏，脆弱性集中到少数专家上。这个现象在Qwen3-30B-A3B上尤其明显，其中间层的有效专家数长期接近top-k。

这让RepetitionCurse的机制变得更清楚：重复token先压缩隐藏表示的多样性，router再把这些相似表示稳定地分到固定top-k专家；如果这些专家刚好部署在同一张或少数几张GPU上，系统层面的straggler就出现了。

这个发现也解释了为什么一些看似合理的防御只能缓解，不能根治。

第一种防御是脆弱性感知的Expert-GPU映射。既然有脆弱专家，那就先找出它们，再尽量把这些专家分散到不同GPU上。这样即使攻击输入激活了它们，计算也会被分摊到不同设备上。论文模拟结果显示，这种方法在中等专家数、top-k足够大的模型上有效。例如DeepSeek-V2-Lite在EP size = 16时，bottleneck coverage下降了36.7%。但在高EPsize或top-k很小的模型上，它会很快失效。

实线为默认Expert-GPU映射下的bottleneckcoverage，虚线为脆弱性感知映射后的结果。部分模型有明显下降，但高EP或小top-k场景下防御效果有限。

第二种防御是PPL过滤。RepetitionCurse输入高度重复，确实往往具有极低perplexity。

但问题在于，代码补全、结构化文本也可能有低PPL。阈值太紧会误伤正常开发者请求；额外部署一个PPL evaluator又会增加GPU显存、网络跳转和请求延迟，反而违背保护SLA的初衷。

论文的PPL实验也显示，代码文本的PPL明显低于自然文本，和攻击输入之间存在误判风险。

第三种防御是动态EPLB，也就是根据实际路由统计周期性调整专家到GPU的映射。但论文发现，正常流量里最常被激活的专家，并不一定是RepetitionCurse会攻击的脆弱专家。

即使EPLB在第二轮观察到混合攻击流量后重新调整映射，bottleneck score也只是小幅下降；在Llama-4-Scout这类模型中，攻击可以把token压到单个专家上，映射策略几乎无处施展。

所以，这篇论文最后指向的不是某个小修小补，而是一个更底层的问题：MoE训练阶段有负载均衡约束，但推理阶段缺乏同等强度的约束。当MoE成为工业部署的基础设施，router就不只是模型结构的一部分，也成了资源调度器的一部分。

而资源调度器一旦被输入分布带偏，模型层面的轻微路由偏置，就会被多GPU并行系统放大成服务层面的延迟风险。

对服务提供商来说，这项工作给出的启示包括：谨慎选择过高EPsize，监控per-expert和per-GPU的实时负载，识别并分散脆弱专家，对极端低熵请求进行隔离或降级，并探索真正的inference-time load balancing。

MoE仍然是大模型高效扩展的重要路线。但RepetitionCurse提醒我们：专家越多，并不意味着系统越稳。下一代MoEserving系统需要解决的，也许不只是「如何让专家更聪明」，还有一个更工程、更现实的问题：如何让专家们真正地做到均衡。

参考资料：

https://arxiv.org/abs/2512.23995

文章来自于微信公众号 “新智元”，作者 “新智元”