🤖 machine learning

A Paired Testing Protocol for Batch-Conditioned Refusal Robustness in LLM Serving

This paper proposes a paired testing protocol demonstrating that language model batch conditions significantly impact refusal robustness, revealing that while safety-label flips are more frequent than capability-label flips, they are largely attributable to output instability and can be effectively mitigated through batch-invariant kernel implementations.

Original authors: Sahil Kadadekar

Published 2026-05-28

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Sahil Kadadekar

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a very strict, safety-conscious librarian (the AI model). You want to make sure this librarian always refuses to hand out dangerous books (safety refusals) but happily hands out helpful ones (capabilities).

Usually, when we test this librarian, we ask them questions one by one in a quiet room. But in the real world, the librarian works in a busy library where they have to handle many requests at once, often shuffling them into groups (batches) to work faster.

This paper asks a simple but tricky question: Does the way the librarian groups these requests change their answer? Does asking a question while standing next to a row of other people make the librarian suddenly decide to hand out a dangerous book when they wouldn't have alone?

Here is the story of the research, broken down into four simple experiments:

1. The "Busy Room" Test (Study A)

The researchers started by testing the librarian in two ways: alone, and in a group.

The Finding: They found that the librarian did change their mind sometimes when working in a group. Specifically, they were slightly more likely to accidentally drop their guard on "dangerous" questions than on "helpful" ones.
The Catch: When they looked closer, they realized many of these "changes" were just the librarian rephrasing their answer slightly, not actually changing their core decision. After a human expert carefully reviewed the messy data, the number of real mistakes dropped from a noticeable amount to a very tiny, rare event (about 1 in 600 requests).
The Analogy: It's like a security guard who usually stops a suspicious person. In a crowd, they might hesitate for a split second or say "Stop!" in a different voice, but they still stop them. However, very rarely, they might actually let someone through who they shouldn't have.

2. The "Many Librarians" Test (Study B)

The researchers then asked: "Is this a problem for every librarian, or just this specific one?" They tested 15 different AI models.

The Finding: The "dangerous mistake" pattern didn't happen for everyone. Some models were very steady; others were a bit wobbly.
The Surprise: It didn't matter if a model was trained to be "super safe" or "super helpful." The only thing that predicted who would make mistakes was instability. If a model's answers were already shaky and changed easily when the group size changed, that model was more likely to make a safety mistake.
The Analogy: It's not that "all librarians are bad at crowds." It's that "if a librarian is already jumpy and changes their mind easily, putting them in a crowd makes them more likely to drop the ball."

3. The "Mixed Crowd" Test (Study C)

Next, they wondered: "Does it matter who is in the group with the librarian?" If the librarian is handling a dangerous request while also handling a request about math, does the math request cause the danger?

The Finding: They didn't find a big, general rule that "mixing crowds causes safety failures."
The Caveat: However, when the few mistakes did happen, they almost always leaned toward being unsafe.
The Analogy: It's like a chef cooking in a busy kitchen. Mixing a spicy dish with a sweet one doesn't usually ruin the food. But if the chef does mess up, it's more likely to be a safety issue (like burning the food) than a taste issue.

4. The "Magic Switch" Test (Study D)

Finally, the researchers wanted to know why this was happening. They suspected it was a specific part of the computer's "engine" (the kernel) that got confused when handling groups.

The Finding: They turned on a special "batch-invariant" mode (a setting that forces the computer to ignore the group effects).
The Result: When they used this mode, all the mistakes disappeared. The 22 errors they saw in the normal mode became 0 errors in the special mode.
The Analogy: It's like finding out the librarian was tripping over a loose rug in the hallway. Once they taped down the rug (the special setting), the librarian stopped tripping completely.

The Big Takeaway

The paper concludes that batching (grouping requests) is not a universal disaster, but it is a hidden variable that safety testers cannot ignore.

Don't Panic: It doesn't mean AI is unsafe in groups. The mistakes are rare and specific to certain models.
Do Check: You cannot assume a model is safe just because it passed a test in "solo mode." You must test it in the exact "group mode" it will use in the real world.
The Rule: If you are deploying an AI, you need to run your safety tests with the same "group settings" and computer engines you will use in production. If you do that, you can catch the rare moments where the AI might slip up.

In short: The AI isn't broken, but the way we test it needs to be more realistic. We need to test the AI in the "crowd" to make sure it doesn't lose its cool.

Technical Summary: A Paired Testing Protocol for Batch-Conditioned Refusal Robustness in LLM Serving

1. Problem Statement

Current safety evaluations for Large Language Models (LLMs) typically treat serving configurations (e.g., batch size, scheduling policies) as fixed background infrastructure. This paper challenges that convention, positing that batch condition is an untested treatment variable. When a prompt is evaluated alone versus in a synchronized batch or within a continuous-batching scheduler, the resulting refusal decision may shift.

The core question is not whether batching is generally unsafe, but whether paired testing can detect movement in refusal boundaries when the same prompt is evaluated under different batch conditions, while controlling for ordinary output variation and benign capability changes. The authors argue that batch size and scheduling are treatment variables that must be tested directly or explicitly ruled out when the outcome of interest is a boundary event like refusal versus compliance.

2. Methodology: A Four-Study Synthesis

The paper synthesizes four artifact-backed studies into a cohesive testing protocol. The methodology moves from local discovery to cross-model generalization, composition analysis, and mechanism ablation.

Study A: Initial Local Perturbation

Design: A local paired perturbation test involving 31,410 scored rows across three instruction-tuned models (1B–3B parameters).
Conditions: Four phases were tested: synchronized-dispatch batch-size perturbation, neighbor-condition perturbation, quantization-by-concurrency, and explicit "true-batching."
Controls: The study pairs safety prompts (harmful/jailbreak) with capability controls (MMLU, ARC-Challenge) to distinguish safety-specific instability from generic output churn.
Correction: A scorer-corrected audit and manual adjudication of 63 candidate rows were performed to filter automated scoring artifacts (e.g., refusal rephrasing) from genuine behavioral flips.

Study B: Cross-Model Generalization

Design: An extension to 127,224 records across 15 distinct models.
Objective: To determine if the initial safety-over-capability asymmetry is a universal law or model-specific, and to test if alignment type or output instability predicts fragility.
Metrics: Analysis of safety-to-capability flip ratios, ANOVA on alignment types, and correlation of output instability with fragility.

Study C: Continuous-Batch Composition

Design: A test of whether multi-tenant co-residence in continuous batching (vLLM FP16) creates a separate safety channel.
Scope: 14,250 records across five batch-composition conditions, including temporal-overlap sweeps and reverse-direction tests.
Goal: To detect aggregate safety effects arising specifically from the presence of other requests in the same batch.

Study D: Batch-Invariant Kernel Ablation

Design: A targeted mechanism check on 55 score-flip candidates identified in Study A.
Execution: Rows were re-run on the same H100 serving stack using standard vLLM versus vLLM with BATCH_INVARIANT=1 enabled.
Goal: To determine if observed flips depend on the specific non-invariant execution path of the serving kernel.

3. Key Results

Quantitative Findings

Local Discovery (Study A): Initial automated scoring showed safety labels changing more often than capability labels (0.51% vs. 0.14%). However, after manual adjudication of 63 candidates, only 17 genuine behavioral flips were confirmed, resulting in a corrected full-set rate of approximately 0.16%.
Cross-Model Generalization (Study B):
- No Universal Skew: The combined safety-to-capability ratio across 15 models was near parity (0.94×), refuting a universal safety-over-capability law.
- Predictors: Alignment type showed no detectable association with fragility ( $p=0.942$ ). Conversely, output instability was the strongest predictor of batch fragility ( $r=0.909$ ).
- Directionality: Flips were not universally unsafe; the extension found a net safe direction (159 compliance-to-refusal vs. 81 refusal-to-compliance), indicating directionality is model-set dependent.
Composition (Study C): No aggregate composition effect was detected at a 4.7 percentage-point sensitivity. While rare flips leaned unsafe (28/31 cases, 90.3%), the low verification rate of actual co-batch presence (22.1%) prevents this from being a basis for routing decisions.
Mechanism Ablation (Study D):
- Standard vLLM: Reproduced 22/55 label flips on the candidate set.
- Batch-Invariant Kernel: Enabled VLLM_BATCH_INVARIANT=1 reduced flips to 0/55.
- This confirms that for the tested stack, the observed instability is tied to the non-invariant execution path.

Qualitative Synthesis

The evidence chain narrows the initial positive signal into a bounded claim: batch-conditioned refusal flips exist but are low-rate, model-specific, and stack-dependent. They are not a universal safety law, nor are they predicted by alignment categories.

4. Contributions

The paper makes four specific testing contributions:

Paired Protocol: A protocol for batch-conditioned refusal testing that compares safety and capability labels under matched serving conditions, incorporating scorer-corrected adjudication.
Generalization Test: Evidence that output instability predicts fragility more strongly than alignment type, and that aggregate safety-over-capability skew does not generalize across models.
Composition Test: A demonstration that continuous-batch composition does not create a large aggregate safety effect at current sensitivity, despite rare directional flips.
Mechanism Ablation: Proof that current score-flip candidates disappear when executed under a batch-invariant kernel path, validating the need for exact-stack testing.

5. Significance and Claims

The paper's significance lies in establishing a testing contract for deployment safety that moves beyond "fixed background" assumptions.

Thesis: Batch-conditioned refusal flips are real but rare and specific. The correct response is not a prohibition on batching, but an exact-stack validation requirement.
Operational Recommendation: Safety evaluations must be re-run at the specific served batch setting and kernel path used in deployment.
- Evaluate refusal at the served batch setting.
- Pair safety prompts with capability controls to filter generic churn.
- Report low-rate directional flips separately from aggregate null effects.
- Do not infer batch robustness from alignment type, architecture family, or composition heuristics.

The authors explicitly state they do not claim to have discovered batch-dependent nondeterminism (which is known), nor do they claim deployment optimization is generally safety-neutral. Their contribution is the specific empirical finding that batching must be evaluated as a safety failure mode with a paired design, and that initial positive signals must be corrected for adjudication and generalization to avoid over-claiming sparse-flip results.