Restore MoE refusal safety with full-expert response starts — SafeStart warm start — What does it mean?

The news. On November 4, 2026, researchers at the University of Southern California and Intel Labs posted SafeStart on arXiv. They found that serving an MoE model with fewer active experts per token made decoding faster but, on some models, made the model easier to push into harmful answers. Their fix is a patch for vLLM 0.11.0 that uses all experts at the start of every response. Read the paper →

Picture a kitchen with four cooks working on every dish. At quiet hours the cooks spend much of their time waiting for ingredients to be fetched, so the manager sends one cook home and lets three handle every dish. Service gets faster and the food still tastes right on most tests. But the paper finds that much of the lost willingness to say "we cannot make that" begins while the order is being taken, and that is where the thinner crew does its damage. SafeStart keeps all four cooks for taking the order and the opening of the first dish, and sends the fourth cook home only after that.

In an MoE layer, a router picks the top-k experts for each token. Active expert reduction keeps only k' of them, so Qwen1.5-MoE goes from 4 experts to 3 per decode token. It is faster because at small batch sizes each routed expert handles very few tokens per step, so layer time follows how many expert weights the GPU reads from memory, not how much arithmetic it does. The paper measures a 15 to 28% decode speedup at batch size 8 on all six timed models when about two thirds of the experts are kept, and at most 5% at batch size 128 on four of them, because a large batch touches almost every expert anyway.

The cost shows up in refusals. The authors measure attack success rate (ASR) on 472 prompts, using Llama Guard 3 as the judge, inside a refusal-suppression jailbreak template. On the three of nine models where the rise is significant, truncation raises ASR by 18.4 points on Qwen1.5-MoE, 9.5 on OLMoE and 6.6 on DeepSeek-V2-Lite, while MMLU accuracy drops by less than two points. An accuracy check alone would not have flagged any of these models.

The damage is made in the prompt pass and the first output token. On Qwen1.5-MoE, 92 of the 101 responses that truncation turns harmful already differ from the original model's response at the first generated token. Truncating only the prompt and that first token, then continuing with the original model, reproduces 91% of the ASR increase on Qwen1.5 and 62% on OLMoE. The paper also finds a mechanism: truncation moves the hidden state of the final prompt token along the refusal direction toward the harmless side, and restoring its original position along that direction removes 97% of the first-token increase on Qwen1.5 and 71% on OLMoE.

SafeStart turns that finding into a rule: run all k experts for prefill and for the forward passes that produce the first N = 8 generated tokens, and use the reduced budget for every later token. The paper implements it in about 160 lines of Python and Triton without changing vLLM's source. A fused Triton kernel replaces, for marked tokens only, the expert slots outside the reduced budget with a sentinel expert of weight zero, and vLLM's expert map sends that sentinel to -1 so the grouped matrix multiply skips its weights. The rule depends on the output position rather than on whether a step is prefill or decode, so it stays correct when vLLM recomputes tokens after a preemption or a prefix-cache hit.

What does the warm start cost? Time to first token stays within 1% of the original model at batch size 8, because SafeStart gives up truncation's prefill saving. It keeps 85 to 101% of truncation's decode speedup at batch size 8 and 88 to 104% at batch size 32 (values above 100% are within timing noise). It works because the expensive part of a response is the long tail: with N = 8, 95.6% of the generated tokens on Qwen1.5 still run with the reduced budget.

Here is the arithmetic for one request on a 4-expert model that is truncated to 3, with the response length set to 200 tokens (illustrative). Reading all 4 routed experts per token per layer for 200 tokens costs 800 expert reads. Plain truncation costs 200 x 3 = 600, a saving of 200. SafeStart reads 8 x 4 = 32 for the opening plus 192 x 3 = 576 for the rest, which is 608. That is 192 of truncation's 200 saved reads, or 96% of the saving, while the prompt and the first eight generated tokens used the full expert budget. At 1,000 tokens the share rises to 99.2%, since the fixed 8-token opening is spread over a longer response. Expert reads are a proxy here, not the measured speedup, which the paper reports separately above.

The paper tests refusal on a refusal-suppression template and on three of nine models that showed a significant rise, so it does not show that every MoE model or every attack behaves this way. The general lesson holds regardless: when a serving optimization changes the model's computation, measure behavior by phase, and spend full compute where the behavior is decided. A budget that follows output position can be cheaper and safer than one that follows batch size alone, and a speed gain should be judged together with that safety measurement.

Goes deeper in: LLM Internals → KV Cache → Prefill vs Decode