RepetitionCurse: Measuring and Understanding Router Imbalance in Mixture-of-Experts LLMs under DoS Stress

Mixture-of-Experts architectures have become the standard for efficient LLM scaling, typically employing expert parallelism to distribute experts across devices. However, the absence of explicit load balancing constraints during inference allows adversarial inputs to trigger severe routing concentration. We demonstrate that out-of-distribution prompts can manipulate the routing mechanism such that all tokens are routed to the same set of top-k experts, which creates computational bottlenecks on certain devices while forcing others to idle. This converts an efficiency mechanism into a denial-of-service attack vector, leading to violations of service-level agreements for time-to-first-token (TTFT). We propose RepetitionCurse, a black-box strategy to exploit this vulnerability. By identifying a universal flaw in MoE router behavior, RepetitionCurse constructs attack prompts using simple repetitive token patterns in a model-agnostic manner. On widely deployed MoE models hosted on 8-GPU clusters, our method increases TTFT by 20% to 148%, significantly degrading service quality.

Large AI chat services often speed up their models by splitting work across many computer chips. Ideally, each chip gets a fair share of the work, so users receive quick responses. We find that this balance can break in a surprising way: certain unusual, highly repetitive inputs can make the system send most of the work to only a few chips, while the others sit idle and wait. This turns a design meant to improve efficiency into a reliability problem, because one overloaded chip can slow down the whole response. We introduce RepetitionCurse, a simple method for testing whether this weakness exists in AI systems that use this kind of split-work design. Across many popular models and multi-chip deployments, we find that the issue is widespread and can substantially increase the time users wait before seeing the first response. These results show that faster AI serving systems also need stronger safeguards to keep their workload balanced during real use.