# LFM2.5 QAD: a quantized release produced by training, not just conversion

The QAD release makes training provenance part of quantized-checkpoint identity rather than treating the quantization label as a complete description.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-19
Original announcement: https://www.liquid.ai/blog/qad
Canonical URL: https://retrivium.ai/retrospectives/lfm25-qad-training-versus-conversion/

The QAD release makes training provenance part of quantized-checkpoint identity rather than treating the quantization label as a complete description. Two artifacts can use the same storage format while differing in how their weights were obtained, so a generic format comparison does not automatically evaluate this release.

## The artifact changed, not only its container

The [QAD announcement](https://www.liquid.ai/blog/qad) follows earlier [family deployment work](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact-model work](https://www.liquid.ai/blog/lfm2-5-230m). Its distinguishing feature is a trained quantized student. That is a different intervention from converting fixed weights after training. The shared file format describes representation, but does not explain the optimization history responsible for the values stored inside it.

## A format name cannot carry the quality claim

An application that records only a quantization label cannot distinguish two checkpoints with different training provenance. If outputs improve, the result may belong to the trained artifact rather than to a newly discovered property of the format. If they worsen on a specialized task, the same distinction prevents a broad conclusion that the format is universally unsuitable.

A useful release record therefore connects the source model, artifact revision, training method and runtime interpretation. Missing any one of these can turn a reproducible replacement into an ambiguous comparison between several changes.

## Teacher recovery is a bounded comparison

A reported recovery toward a teacher baseline concerns the evaluated tasks and aggregation. It does not certify every downstream extraction or tool-use requirement. Consider a workflow whose critical output is an exact technical identifier. A broad quality average can remain strong while that narrow behavior changes. The acceptance fixture must represent the consequence that actually matters to the application.

This is a reason to inspect errors, not to dismiss aggregate evaluation. Different levels of evidence answer different questions and should remain visible together.

## Migration should preserve an explainable baseline

Keep the previous artifact and exact test inputs while introducing the trained checkpoint. Compare strict outputs separately from open-ended prose. If the runtime or template also changes, record a separate comparison so a parser difference does not become a training claim. A successful file load establishes only that the execution path accepts the representation, not that the application contract survives.

## The durable lesson of the release

Quantization is not always the final mechanical step applied to a finished model. A public trained artifact makes that distinction operationally relevant: provenance belongs beside precision in the inventory. The release creates a new candidate for deployment, but its value has to be established under the actual task. This avoids both overclaiming universal teacher equivalence and overlooking a meaningful training change because two filenames carry the same familiar quantization suffix.

Further analysis: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/); [GPU hosting for multimodal models: count more than text](/journal/multimodal-gpu-hosting/).