文章摘要
港科大团队在ICML 2026上揭示MoE模型新安全风险。其提出的RepetitionCurse黑盒测试方法，构造重复文本可使路由将输入token集中到少数专家模块，导致GPU性能滞后、拖慢TTFT，最高提升148%，还会破坏SLA。现有防御方案有局限，研究为服务提供商指明优化方向，也提醒行业要解决专家负载均衡问题。

混合专家模型（MoE）已经成为当前大模型实现高效推理的主流技术路线。这类模型将单一超大模型拆分为多个独立的「专家模块」，在推理过程中仅激活其中一小部分专家来处理每个输入token，既可以拥有庞大的总参数量，又能控制单步推理的计算开销，对于服务提供商而言，这是兼顾模型性能与部署成本的理想方案。

不过，来自港科大的研究团队在国际机器学习大会（ICML 2026）上发表的一项工作揭示了MoE模型的一个全新系统级安全风险——专家路由模块存在被利用的漏洞。

该团队提出了一种名为RepetitionCurse的黑盒压力测试方法，无需获取模型权重、梯度信息，也不需要了解后端专家的具体部署方式，仅通过构造高度重复的输入文本，就能诱导专家路由将大量输入token集中路由到少数几个专家模块上。

这种攻击会导致部分GPU设备成为性能滞后节点（straggler），其他GPU设备不得不等待其完成计算才能进行同步，最终拖慢从请求发起至返回第一个token的时间（TTFT）。实验数据显示，在常见的8-GPU专家并行部署场景中，RepetitionCurse可使MoE模型的TTFT提升20%至148%。

RepetitionCurse攻击原理

MoE的路由模块本质上相当于模型的「分诊台」，每个输入token都会经过路由判断，被分配到对应的专家模块进行处理。在正常的自然文本输入中，不同token的语义特征差异较大，隐藏表示较为分散，路由模块通常会将它们均匀分配到不同专家，这也是MoE模型训练阶段重点优化的负载均衡目标。

而RepetitionCurse恰恰利用了路由分配的另一个极端场景：当输入文本出现高度重复的token序列时，连续token的隐藏表示会变得高度相似，对于路由模块而言，这些token就像是「长得几乎一模一样的访客」，因此会被反复分配到同一批专家模块中。

这种路由崩溃（routing collapse）会彻底打破系统的并行优势。在实际部署中，MoE模型通常采用专家并行（Expert Parallelism）策略，将不同的专家模块部署到不同的GPU设备上，正常情况下可以充分分摊计算压力。但如果大量token被集中路由到同一GPU上的专家模块，该GPU就会成为性能瓶颈，其他即使负载极低的GPU也必须等待其完成计算，最终导致整个系统出现单点拥堵。

攻击带来的性能影响

对于大模型服务而言，TTFT是用户感知最直观的性能指标，指从请求到达服务器到返回第一个token的耗时，直接影响聊天机器人、代码补全、智能问答等场景的用户体验。研究团队使用延迟放大比率（LAR）来衡量攻击对TTFT的影响，当该数值为2.48时，代表攻击场景下的TTFT是正常场景的2.48倍。

研究团队在vLLM框架上部署了多款MoE模型，使用公开的真实用户请求数据集进行测试，结果显示专家并行规模（EP size）越大，RepetitionCurse越容易将多GPU并行系统退化为单线程运行。在多款主流MoE模型的测试中，8-GPU部署场景下TTFT最高提升148%，当EP size扩大到32时，部分稀疏模型的TTFT提升幅度也达到了115%。

此外，攻击还会破坏服务的等级协议（SLA）：在常见的8-GPU设置下，RepetitionCurse会将原本P99的服务稳定性拉低至P98.6到P86.4，意味着服务违约率从1%上升至最高13.6%。

更值得注意的是，大模型服务通常会将多个请求打包为batch以提升吞吐效率，这使得攻击请求可以「搭车」影响正常用户的请求。研究团队分析了两种典型攻击场景：一是混合请求batch，攻击请求与正常用户请求进入同一个batch，此时即使正常用户没有发送异常输入，也会被拖慢整个batch的处理速度；二是纯攻击请求batch，当系统在某段时间内仅处理攻击请求时，会占用大量预填充（prefill）资源，导致后续正常请求的排队时间大幅增加。

攻击机制与模型脆弱性

研究团队在分析中还发现，MoE模型中存在一批「脆弱专家」，这些专家相当于路由空间中的「吸引子」，当出现重复token时，会被异常稳定地分配到这些专家模块上，而非随机出现路由失衡。

为了量化专家的脆弱程度，研究团队对词表进行了扫描：针对每个专家模块，统计在构造RepetitionCurse输入后，有多少比例的输入token会被路由到该专家模块，当该比例超过90%时，该专家就被视为一个「吸引子」，其数量越多代表该模型越容易被攻击。此外，研究团队还提出了有效专家数指标，用于描述每层中真正承担路由分配作用的专家数量：该数值越小，代表触发攻击的token越集中到少数专家上，当该数值接近路由选择的top-k数量时，意味着该层的路由分配已经高度集中。

通过实验分析，研究团队还发现了一个有趣的层级规律：模型的早期层和最后几层的脆弱专家分布相对广泛，触发token较为分散；而中间层的脆弱性则高度集中在少数专家上，这一现象在部分主流稀疏模型中尤为明显，其中间层的有效专家数长期接近top-k数值。这也清晰解释了RepetitionCurse的完整攻击流程：重复token先压缩了隐藏表示的多样性，路由模块将相似的隐藏表示稳定分配到固定的top-k专家模块，如果这些专家恰好部署在同一台或少数几台GPU上，就会触发系统级的性能滞后问题。

现有防御的局限与行业启示

现有的几种防御方案仅能缓解攻击影响，无法从根本上解决问题。第一种是脆弱性感知的专家-GPU映射策略，即先识别出脆弱专家，再将它们分散部署到不同的GPU设备上，这样即使攻击触发了这些专家，计算压力也会被分摊到多个设备。实验显示，该方法在中等专家数量、top-k数值较大的模型上有一定效果，但在高EP size或top-k数值很小的模型上，该方法很快就会失效。

第二种防御方案是基于困惑度（PPL）的过滤，由于RepetitionCurse的输入高度重复，通常具有极低的困惑度。但这种方法存在明显缺陷：代码补全、结构化文本等正常输入也可能拥有较低的PPL，设置过严的阈值会误伤正常的开发者请求；而额外部署PPL评估模块又会增加GPU显存占用、网络跳转和请求延迟，违背了保障SLA的初衷。

第三种防御是动态专家负载均衡（EPLB），即根据实际的路由统计结果周期性调整专家到GPU的映射关系。但研究发现，正常流量中最常被激活的专家，并不一定是RepetitionCurse会攻击的脆弱专家，即使EPLB在第二轮观察到混合攻击流量后重新调整映射，瓶颈分数也仅会小幅下降；在部分模型中，攻击甚至可以将token完全集中到单个专家模块上，该策略几乎无法发挥作用。

这项研究最终指向了MoE模型部署的一个底层问题：训练阶段虽然有严格的负载均衡约束，但推理阶段却缺乏同等强度的调度机制。当MoE成为工业级部署的基础设施时，路由模块已经不仅仅是模型结构的一部分，更是系统的资源调度器。一旦路由模块被输入分布带偏，模型层面的轻微路由偏差，就会被多GPU并行系统放大为严重的服务延迟风险。

对于大模型服务提供商而言，这项工作给出了明确的优化方向：谨慎选择过高的EP size，实时监控每个专家和每个GPU的负载情况，识别并分散脆弱专家，对极端低熵的重复输入请求进行隔离或降级处理，并探索真正适配推理阶段的负载均衡机制。

尽管存在这样的安全风险，MoE依然是大模型高效扩展的核心技术路线。RepetitionCurse提醒行业：专家数量的增加并不代表系统稳定性的提升，下一代MoE服务系统需要解决的不仅是「如何让专家更智能」，更是一个更贴近工程实践的现实问题：如何让所有专家真正实现负载均衡。

以上内容不代表本平台立场，仅供读者参考