# Mistral Small 4 NVFP4 vs original checkpoint: test task quality

Evaluate Mistral Small 4 NVFP4 against its original checkpoint through artifact provenance, matched reasoning settings and bounded text and code checks.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/mistral-small4-nvfp4-checkpoint-choice/
Language: en

Mistral Small 4 has an official NVFP4 artifact derived from the original checkpoint. Choosing it requires distinguishing weight-format provenance, runtime compatibility and task quality rather than treating a low-bit label as a complete deployment result.

## Read the artifact provenance

The [NVFP4 card](https://huggingface.co/mistralai/Mistral-Small-4-119B-2603-NVFP4/raw/main/README.md) identifies a post-training activation-quantized version of the parent model and describes creation using llm-compressor. The [original card](https://huggingface.co/mistralai/Mistral-Small-4-119B-2603/raw/main/README.md) establishes the parent checkpoint and its instruction and reasoning behavior.

The [release announcement](https://mistral.ai/news/mistral-small-4/) provides family context. Its general performance statements should not be used as measurements of a particular quantized artifact on a private server. An official relationship between artifacts does not remove the need to check the selected runtime.

## Separate format support from successful loading

A model file can describe a quantization method that a runtime cannot execute on a particular device. That is a compatibility outcome, not evidence of poorer answers. Conversely, successful loading does not establish that every task remains acceptable.

Keep the quantization configuration with the weight files. Converting or replacing an artifact while retaining the same display name can conceal a materially different comparison.

## Use a small quality acceptance set

| Fixture | Protected requirement |
| --- | --- |
| Short notice rewrite | Fixed facts and limitations remain unchanged |
| Checked constraint problem | Final proposal satisfies every condition |
| Boundary-sensitive function | Existing valid cases remain correct |
| Multi-file change | Callers match the changed implementation |
| Tool continuation | Final answer uses the actual supplied observation |

These fixtures are proposed tests, not measured results. Their value comes from independent acceptance rules that can distinguish a changed response from a degraded one.

## Match the parent model conditions

Small 4 supports none and high reasoning conditions. Keep the chosen condition and output allowance explicit for both artifacts. A comparison using different effort or truncating one answer can mistake generation-policy differences for quantization effects.

Inspect completed answers and actual code checks. Two different valid implementations should both pass. Similar wording should not conceal a wrong edge case. Keep incomplete delivery separate from a completed but invalid answer.

## Preserve an artifact acceptance record

Store parent and quantized repository revisions, conversion provenance, runtime, generation settings and fixture outcomes. State whether each artifact loaded through a documented path before interpreting its quality results.

The conclusion can accept NVFP4 for the checked workload or identify a specific regression needing investigation. It cannot establish universal losslessness, guaranteed device support or a fixed speed gain from the format name. Keep the scope at the downloaded artifacts and the text or code behavior actually verified, rather than extending it to unrelated hosted products.

## Related reading

- [LLM quantization: checking quality before choosing a GPU](/journal/quantization-quality/)
- [Validate ModelOpt quantized checkpoint scales and export provenance](/journal/modelopt-quantized-checkpoint-provenance/)