REFUSALMAP01
Evaluation / Field guide

Are small abliterated models worth using? Test the workload first

There is no established universal 30B-parameter cutoff below which abliteration becomes unhelpful. Decide using the exact checkpoint, task quality, serving cost and latency requirements of your application.

Why parameter count is an incomplete shortcut

Parameter count does not specify the training data, architecture, instruction tuning or intervention quality. It also does not tell you how a model handles your output contract. A size threshold is attractive because it is simple, but a useful recommendation requires comparisons across actual artifacts and workloads.

Choose a task that matters

A small model may be evaluated for classification, short extraction or a tightly constrained transformation. More open-ended reasoning is another workload with different requirements. Define an acceptance rule before testing: for example, correct labels on a held-out set and valid JSON for every accepted response. Treat that rule as an application choice, not a general scientific threshold. The 40-prompt diagnostic set includes constrained tasks you can score directly.

Measure failure cost alongside speed

A fast response that needs a retry can be slower and more expensive overall. Record first-pass success, retry rate and successful requests per unit of cost. Count the latency of the full workflow, including validation. If a larger model requires fewer retries, compare the actual completed-task cost rather than price per token alone.

Test the edited and original checkpoints

When both are available, hold precision and serving settings constant. Measure whether the intervention changes refusal behavior and whether it changes task quality. A model that already answers your benign workload may offer little practical gain from reduced refusal, while an application with over-refusal problems may have a different trade-off. Use the four-condition matrix if the available artifacts use different precision.

Report a local conclusion

A defensible conclusion names the artifact, precision, workload and date: this configuration met this application's requirements in this test. Avoid turning it into “small models are always worse” or “abliteration never costs quality.” Those broader claims need evidence across a wider range of models than one deployment. The capability guide explains which task families deserve separate results.

Evaluation reference
Decision factorUseful measurement
QualityHeld-out task success
ReliabilityValid first-pass responses
SpeedEnd-to-end p50 and p95 latency
CostCost per successful task
BehaviorRefusal and partial-refusal labels

Sources & provenance

    Published 2 November 2026. See our editorial method for source and measurement standards.