> ## Documentation Index > Fetch the complete documentation index at: https://runinfra.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Lossless first > RunInfra does not quantize your model by default. Quantization trades output quality for speed and memory, so it runs only when something specific earns it, and the plan states the decision either way. Quantization makes a model smaller and usually faster by giving up some of its precision. That is a trade, not a free win, so RunInfra treats it as one. A run starts from the assumption that you want the model you asked for, at full precision, served as fast as full precision can be served.

## Ask for it when you want it Say so directly: ```text theme={"dark"} Search for a 4-bit variant of this model ``` ```text theme={"dark"} Quantize this to FP8 and show me the quality delta ``` Or give the run a hardware target it has to fit, and let the arithmetic earn it: ```text theme={"dark"} This has to run on a 24GB card ``` Asking does not skip the accuracy check. A quantized candidate is measured first and promoted only if its quality gate passes. ## What runs instead Excluding quantization does not exclude optimization. Everything that changes how the model is served, rather than what the model is, still runs: * Serving engine and runtime selection * Batching, prefill scheduling, prefix caching, and memory headroom tuning * Lossless FP16 KV cache tuning * GPU selection and placement * Speculative decoding, which is output-identical when its equivalence check passes These are the levers that cost you nothing in output quality, and they are searched first. ## The plan says which way it went You never have to infer what happened. Exactly one of two lines appears in the plan you read before accepting it. When quantization **is** in the plan, the lane carries a **Quantization basis** line naming the condition that permitted it: ```text theme={"dark"} Quantization was applied because it was explicitly requested for this run. It is not applied by default: it trades model quality for speed and memory. ``` For a hardware fit it names the numbers that failed instead: the estimated base-precision weight footprint, the VRAM actually needed once serving headroom is included, and the GPU that cannot serve it. When quantization is **not** in the plan, the caveats say so and tell you how to change it: ```text theme={"dark"} Quantization not attempted: it trades model quality for speed and was not requested. Ask for quantization, or set a hardware target it must fit, to enable it. ``` A silently applied lossy technique is as dishonest as a silently missing one, which is why both halves of the decision are written down. ## The same rule covers the rest **Lossy KV cache compression** changes attention arithmetic, so compressed KV dtypes are output-affecting and default to off under this same policy. When they are excluded the run says so, and it says that lossless FP16 KV tuning still runs. The KV lane is never skipped, only its lossy half. **Non-LLM runs** apply the rule per technique family. Every technique declares whether it is lossless by construction or requires measured quality, and a family counts as output-changing when any of its members does. Output-changing families are excluded from the default plan, and the plan's adjustments section names every family it excluded, so a new technique cannot quietly join the default plan. When a family is permitted, its lane states why it is running, and each candidate still has to pass its own measured quality gate in that modality's own vocabulary. Where no score was recorded, the run says not measured rather than assuming a pass. ## Related How candidates are searched and ranked. The quality verdict every run carries. Named public benchmarks against a settled winner. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.