Quantization-Aware Safety Drift: Why INT4 Breaks Your Aligned Model

Alignment is a thin layer, and quantization sands it

Pretraining moves weights across an enormous distribution. Alignment — whether you did DPO, RLHF, or something constitutional — moves them comparatively little. The behavior you care about ("refuse this, comply with that, hedge here") often rides on a relatively small set of directions in weight space, laid down late in training with modest-magnitude updates.

There's a growing body of interpretability work suggesting refusal behavior in aligned models is surprisingly shallow — mediated by a small number of directions, and heavily dependent on the first few generated tokens. Whether or not you buy the strongest version of that claim, the practical consequence is the same: the alignment signal is fine-grained relative to the coarse structure inherited from pretraining.

Now quantize. Post-training quantization replaces high-precision weights with a small set of discrete levels. INT8 is usually gentle. INT4 is not — you are representing each weight with sixteen possible values. The rounding error you introduce is not uniform across the network; it lands hardest on exactly the kind of fine, low-magnitude structure that alignment relied on. You didn't retrain the model. You blurred it. And you blurred the thinnest, most recently-written layer of it hardest.

The result is a model that still reasons about as well as it did — because reasoning capacity is distributed and redundant — but refuses less reliably, because refusal was concentrated and brittle.

Why your quantization validation misses it entirely

Here's the trap. The standard quantization QA checklist is a capability checklist:

• Perplexity delta within tolerance
• MMLU / ARC / HellaSwag within a point or two
• A few golden prompts that "look right"
• Latency and memory hit the target

Every one of those can pass while safety regresses. Capability is measured on the model's competence; safety is a property of its restraint. Compression preserves competence far better than it preserves restraint, because competence is over-parameterized and restraint is not. So the exact metrics you're using to bless the quantized build are the metrics least sensitive to the thing that broke.

This is the core mistake, and it's structural, not sloppy: capability preservation is not safety preservation, and no capability benchmark will tell you the difference.

What the drift actually looks like

Across open-weight small models, the failure modes I see after aggressive quantization cluster into a few recognizable patterns:

• Refusal softening. Prompts that got a clean refusal at FP16 get a hedge, a partial comply, or a "I shouldn't, but here's the general idea" at INT4.
• Multi-turn collapse. Single-turn refusals survive; the model folds two or three turns into an escalation it would have blocked at full precision. (Multi-turn is where most alignment dies anyway — quantization just lowers the water further.)
• Category-specific holes. Drift is not uniform across harm categories. A model can hold on category A and fall apart on category B after the same quantization pass, and which categories go is not obvious in advance.
• Method dependence. GPTQ, AWQ, and NF4-style quantization don't degrade identically. Two INT4 builds of the same model, produced by different quantizers, can have different safety profiles.

That last point matters operationally: "we quantized to 4-bit" is not a spec. The method is part of the spec, because the method determines which structure survives.

How to actually measure it

The fix is not complicated. It's just work that most pipelines skip:

1. Re-run your full adversarial safety battery on the quantized artifact — not the FP16 model, the exact bytes you're shipping. If your safety eval only ever ran pre-quantization, you have never evaluated the model you deploy.
2. Evaluate per bit-width and per method. Treat FP16, INT8, and each INT4 variant as separate models with separate safety verdicts. Because they are.
3. Include multi-turn escalation, not just single-turn probes. Drift shows up in the second and third turn long before it shows up in the first.
4. Diff, don't just score. The useful number isn't "the INT4 model's safety score." It's the delta between the aligned model and its quantized descendant, per category. That delta is the drift.
5. Gate on it. A quantized build that regresses on any critical category should not ship on the strength of its perplexity number.

None of this requires retraining. It requires treating the quantized artifact as a first-class object of evaluation instead of a deployment afterthought.

The uncomfortable version

Most teams have never measured safety drift under quantization because their org chart doesn't have a seat for it. Alignment lives with the training team. Quantization lives with the deployment/infra team. The safety eval ran on the training team's artifact and never followed the model across the handoff. The drift happens precisely in the gap between two teams who each assume the other owned it.

That gap is the whole problem, and it's why quantization-aware safety detection is a discipline, not a checkbox. You are not asking "is this model aligned?" You are asking "did alignment survive the specific compression I'm about to ship?" — and answering it requires re-evaluating at every point on the base → fine-tuned → quantized path.

That last framing is the thesis I keep coming back to, and I've written it up in full in From Base to Fine-Tuned to Quantized: A Lifecycle View of Model Integrity. If you only take one thing from this piece: the model you evaluated and the model you shipped diverge at the quantization step, and nobody is watching that divergence unless you decide to.

Measuring safety drift across bit-widths and quantization methods is exactly what SichGate automates — your users shouldn't be your first red team, and your INT4 build shouldn't be its own first safety test.