Low-bit inference is becoming a qualified deployment layer
FP8, FP4, INT4 and quantized KV caches are moving from specialist tricks into mainstream serving stacks. The winning practice is not choosing the smallest number of bits; it is qualifying one exact model, tensor map, scale rule, kernel, device and workload as a controlled release.
What is happening?
Quantization stores or computes some model tensors with fewer bits. That can reduce memory, bandwidth, energy and sometimes latency, but it can also introduce rounding, clipping, scale and kernel errors. A four-bit checkpoint is not automatically faster than an eight-bit or BF16 checkpoint: the runtime may dequantize it, fall back to slow kernels or lose batching efficiency. The safe approach keeps a high-precision baseline, profiles which tensors are sensitive, selects formats supported by the target hardware, calibrates or retrains where needed, validates real tasks and only releases the exact model-format-kernel combination that passes quality and service objectives.
Why this trend is moving
- 01Next-generation accelerators expose native FP8, microscaling and FP4 execution paths rather than treating low precision as storage-only compression.
- 02Long-context and high-concurrency workloads make model weights only one part of the memory budget; activations and KV cache increasingly determine capacity.
- 03Frameworks now support several incompatible formats whose real speed depends on exact hardware, packing, kernels and sequence shapes.
- 04Post-training methods such as GPTQ, AWQ, SmoothQuant, rotations and mixed precision can preserve more quality than naive rounding.
- 05Quantization-aware training is becoming practical when post-training compression cannot recover sensitive layers or tasks.
- 06Edge, laptop and CPU deployments need weight-only INT4 or lower-bit formats to fit useful models within local memory.
- 07Model cards and repositories increasingly distribute pre-quantized variants, making provenance, converter version and kernel compatibility release concerns.
What this means in practice
- Precision is a release property of the complete serving stack, not only a field in a checkpoint.
- Weight, activation, embedding, expert, attention and KV-cache tensors may need different bit widths and scale rules.
- Post-training quantization should be tested first, while quantization-aware training is reserved for quality gaps that matter.
- Hardware-native kernels and packing layouts decide whether memory reduction becomes real latency or throughput improvement.
- Calibration data must represent production token lengths, languages, modalities, tools and outlier behavior.
- Quality acceptance must include task success, calibration, long-context behavior, safety and subgroup slices—not perplexity alone.
- Every quantized release needs a reproducible recipe, compatibility matrix, fallback precision and rollback artifact.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A controlled low-bit deployment begins with a frozen BF16 or FP16 reference release, production workload traces and measurable SLOs. Engineers profile layer sensitivity, activation outliers, attention behavior, expert routing and KV-cache growth before selecting candidate formats. The quantization plan assigns precision, granularity, scale type, group size, clipping and protected modules per tensor class. Calibration or quantization-aware training produces versioned scales and transformed weights. Export tooling packs the model for one runtime and hardware target, while a kernel-coverage audit identifies dequantization and fallback paths. Serving tests measure memory, TTFT, inter-token latency, goodput, energy and quality across prompt lengths, batch sizes and cache states. A release gate compares the candidate with the high-precision baseline, signs the model recipe and canaries the artifact with telemetry for drift, kernel fallback and automatic rollback.
How inference behaves
Quantization maps high-precision values into a smaller representable set using scales, zero points, codebooks or floating-point exponents. Weight-only schemes keep activations in BF16 or FP16, while W8A8, W4A8, FP8 and FP4 schemes reduce both storage and arithmetic precision. Per-tensor scaling is simple but sensitive to outliers; per-channel, per-group, per-row and per-block scaling preserve more local range at the cost of metadata and kernel complexity. Post-training quantization estimates parameters after training, using calibration data or weight statistics. GPTQ minimizes layer reconstruction error with approximate second-order information, AWQ protects activation-salient channels, SmoothQuant migrates activation difficulty into weights, and rotation methods reduce outliers. QAT simulates rounding during training so the model adapts. At runtime, packed weights, activation quantization, accumulation precision, dequantization, fused kernels and cache format jointly determine accuracy and speed.
What the tests can miss
A credible evaluation pins the tokenizer, prompts, sampling, adapters, serving engine, kernels, driver and device. It reports model bytes, peak device memory, active-sequence capacity, TTFT, inter-token latency, throughput, SLO-qualified goodput, energy, kernel coverage, fallback operations, quantization error, calibration stability, task quality, safety behavior and cost per accepted task. Tests should include short and long prompts, rare languages, code, math, tool use, multimodal inputs, adversarial formatting, long generation, repeated prefixes and high concurrency. Every low-bit candidate should be compared with the same high-precision baseline and with a higher-bit fallback under identical traffic.
What deployment involves
Start with a hardware-native FP8 or INT8 candidate when the target accelerator supports it, then test weight-only INT4 for memory-bound models. Quantize embeddings, first and last layers, routers, vision towers and attention components only after sensitivity evidence supports it. Add FP8 or FP4 KV cache separately because long-context behavior can differ from weight quantization. Package the recipe, scales, calibration fingerprint, model revision, runtime version and hardware capability into the release manifest. Canary by workload class, monitor fallback kernels and quality proxies, and retain a warm higher-precision rollback path.
Where the risks sit
Quantized artifacts inherit normal model supply-chain risks and add conversion risks. A malicious or incorrect converter can alter scales, protected layers, packing order or metadata while preserving plausible file names. Pin source checkpoints, quantizer versions, calibration digests, runtime kernels and target hardware. Sign manifests and verify tensor shapes, dtypes, scale ranges and selected exclusions before loading. Do not use sensitive production prompts as calibration data without retention and access controls. Quantization does not remove prompt injection, unsafe output or privacy risk, and lower precision can change refusal, confidence and edge-case behavior.
What it really costs
Complete cost includes calibration, retraining, conversion, storage, loading, accelerator memory, host memory, kernel engineering, quality evaluation, observability, fallback capacity and rollback operations. Smaller checkpoints reduce storage and transfer but may add dequantization overhead or slow unsupported kernels. FP4 can increase capacity on native hardware while requiring more careful qualification than FP8. Weight-only INT4 can be attractive on memory-bound devices but may not improve compute-bound prefill. Compare configurations using cost per accepted SLO-compliant task, not nominal bits per weight.
What the evidence supports
The evidence supports broad adoption but rejects one universal best format. TensorRT-LLM now documents FP8, FP4, AWQ, GPTQ and quantized KV-cache recipes; torchao exposes stable and prototype paths spanning float8, int8, int4, MXFP4 and NVFP4; vLLM publishes a hardware compatibility matrix across several quantization backends; OpenVINO, AMD Quark, Microsoft Olive and Hugging Face expose parallel compression workflows. Research from LLM.int8, GPTQ, SmoothQuant, AWQ, OmniQuant, QuaRot, SpinQuant, KIVI, KVQuant and QServe shows that outliers, tensor granularity, calibration and kernel design determine the quality-performance result. The evidence supports low-bit inference as a production qualification discipline, not a promise that every model can be reduced to the same precision without consequences.
How it works in practice
Low-bit inference is a co-designed numerical and systems release. The correct unit of qualification is the exact model, tensor precision map, quantization recipe, packing format, kernel set, device and workload—not the headline bit width.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 1
Freeze the reference release
Pin the high-precision model, tokenizer, adapters, sampling, engine, hardware and quality suite that define acceptable behavior.
- 2
Profile workload and tensor sensitivity
Measure memory, bandwidth, outliers, layer error, prompt lengths, batch shapes, KV growth and task-specific failures before choosing a format.
- 3
Design the precision map
Assign weight, activation, embedding, router, attention and cache formats with granularity, group size, scales, clipping and protected modules.
- 4
Calibrate or adapt
Run representative calibration, reconstruction, rotation, smoothing or QAT and record every data and algorithm dependency.
- 5
Export for one runtime target
Pack weights and scales for the intended engine, kernel family, compute capability and device topology.
- 6
Audit kernel coverage
Detect dequantization, unsupported operators, mixed-precision fallbacks, alignment losses and graph breaks that erase theoretical gains.
- 7
Qualify quality and service objectives
Compare real task success, safety, long-context behavior, TTFT, token cadence, goodput, capacity, energy and complete cost.
- 8
Canary, observe and roll back
Release by workload class, monitor precision and fallback telemetry, verify artifacts and preserve an immediate higher-precision path.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
Effective model-memory ratio
memory ratio = quantized tensor bytes + scale and metadata bytes ÷ reference tensor bytes Headline bit width overstates savings when scales, zero points, padding, protected layers and duplicate formats are ignored.
- INT4 weights with group scales occupy more than exactly one quarter of FP16.
- Keeping embeddings and output heads in BF16 raises the complete model ratio.
Accepted-task goodput
accepted goodput = completed tasks inside latency and quality limits ÷ wall-clock time A faster token stream is not a production gain if quality failures or retries increase.
- Track accepted coding tasks, not only generated tokens.
- Measure long-context retrieval and tool success separately from short chat.
Complete low-bit savings
net savings = baseline serving cost − (quantized serving + calibration + qualification + fallback + incident cost) Conversion and operational costs matter, especially when several hardware-specific artifacts must be maintained.
- A small fleet may not recover an expensive QAT and kernel program.
- A high-volume service can justify separate FP8 and INT4 qualified releases.
Bit width alone does not identify the model you are serving
Two files described as four-bit models can use different integer or floating-point formats, group sizes, scale precision, zero-point rules, clipping, protected layers and packing layouts. One runtime may execute native low-bit matrix multiplication; another may unpack or dequantize to a higher precision before computing. The visible label therefore says little about latency, quality or compatibility by itself.
The release identity should include the source model revision, tokenizer, adapter set, quantizer and version, recipe, calibration fingerprint, tensor precision map, scale metadata, packing format, runtime, kernel build, device capability and sampling configuration. Changing any of these can change outputs or performance.
This is why pre-quantized community checkpoints require the same supply-chain discipline as compiled binaries. The artifact must be reproducible and tied to the hardware and runtime that qualified it.
- Record per-module precision, not only a global format.
- Pin converter, runtime and kernel versions.
- Verify tensor names, shapes, dtypes and scale ranges.
- Treat repacking as a new release.
Weights, activations and KV cache fail differently
Weight-only quantization primarily reduces model storage and memory bandwidth. Activations remain higher precision, which often protects quality but limits arithmetic savings. Weight-and-activation formats can use native low-bit tensor cores and reduce more traffic, yet activation outliers make them harder to qualify.
Embeddings, first and last layers, normalization, output heads, attention projections, mixture-of-experts routers and small modules may be disproportionately sensitive. A mixed-precision map can keep these components in BF16, FP16, FP8 or INT8 while compressing the bulk of linear weights more aggressively.
KV-cache quantization is a separate decision. It increases concurrent context capacity and reduces transfer cost, but errors accumulate across layers and long token histories. The correct cache format may differ between short chat, retrieval-heavy workloads and very long generation.
- Profile each tensor class separately.
- Do not infer KV-cache safety from weight-only results.
- Protect sensitive modules with measured evidence.
- Test every supported context length.
Integer, floating-point and microscaling formats trade range for precision
INT8 and INT4 use discrete integer levels plus scales and sometimes zero points. They can be symmetric or asymmetric and use per-tensor, per-channel or groupwise parameters. Smaller groups usually preserve more local detail but add metadata and can reduce kernel efficiency.
FP8 formats retain sign, exponent and mantissa, giving wider dynamic range than an integer with similar storage. FP4 and microscaling formats use very small elements with block-level shared exponents or multiple scale levels. These formats depend strongly on native hardware and precise scale handling.
Accumulation precision remains important. A system may multiply low-bit operands while accumulating in FP16, BF16 or FP32. The format of weights, activations, scales, accumulators and outputs should all be explicit.
- Specify element format and scale format.
- Report granularity and group size.
- Record accumulator and output precision.
- Do not compare nominal bit widths without metadata overhead.
Calibration must resemble production, not a convenient benchmark
Post-training quantization is attractive because it avoids full retraining. Simple round-to-nearest can work for tolerant models and higher bit widths. GPTQ, AWQ, SmoothQuant, OmniQuant, rotations and related methods use weight statistics, activations or reconstruction objectives to preserve more quality.
Calibration data determine which ranges and outliers the quantizer sees. A small English text sample may not represent code, math, rare languages, multimodal tokens, tool schemas, long prompts or production system messages. The sample should cover the token and activation distribution that matters, while remaining isolated from protected evaluation sets.
Calibration is also a governance artifact. Record dataset identity, selection logic, preprocessing, sample count, sequence lengths and random seeds so the scales can be regenerated.
- Match languages, modalities and prompt shapes.
- Keep evaluation sets out of calibration.
- Fingerprint calibration inputs and preprocessing.
- Evaluate sensitivity to alternate calibration samples.
Quantization-aware training is a repair tool, not a default ritual
QAT inserts fake quantization during training so the model learns to operate with rounding and clipping. It can recover quality when low-bit activations, embeddings or sensitive layers fail under post-training methods. It can also combine with LoRA or other parameter-efficient updates.
QAT adds data, optimization and reproducibility risk. A successful training loss does not prove that the final packed runtime kernel matches the fake-quantized numerics. Conversion and serving must still be tested end to end.
Use QAT when a measured quality gap justifies it. Preserve the PTQ baseline, training data rights, optimizer state, fake-quant configuration and final conversion recipe.
- Start with PTQ and a clear failure budget.
- Verify fake quantization against real kernels.
- Keep training and conversion manifests.
- Retest safety and calibration after adaptation.
A smaller checkpoint can be slower when kernels do not match
Quantized inference only accelerates when the device and runtime execute efficient low-bit kernels for the actual matrix shapes. Packing, alignment, batch size, sequence length, fused operations, graph compilation and expert layout all affect the result. A runtime may silently dequantize unsupported layers or switch to a generic kernel.
Weight-only methods often help decode because generation repeatedly streams weights. Prefill can remain compute-heavy, especially at large batches, so a weight-only format may provide less benefit. FP8 or FP4 weight-and-activation paths can accelerate more arithmetic when hardware support is native.
Kernel coverage should be measured, not assumed. Trace operator dispatch, fallback count, graph breaks, dequantization time and achieved bandwidth. Benchmark cold loading, steady state, small batches and peak concurrency.
- Audit every operator and MoE path.
- Track fallback and dequantization telemetry.
- Benchmark representative matrix shapes.
- Pin compiler, driver and kernel builds.
Long context turns cache precision into a capacity decision
KV cache grows with active tokens, layers, heads and cache element size. Reducing cache precision can increase concurrency or context length without changing weight format. It can also reduce the bandwidth cost of cache transfer in disaggregated serving.
Cache errors interact with attention, position, retrieval and generation length. A format that preserves short-answer quality may degrade long-context retrieval, copying, code continuation or multilingual generation. Per-channel or asymmetric designs can improve accuracy but require compatible kernels and scale storage.
Cache policies must include eviction, prefix reuse, tenant isolation and cache-format identity. Reusing cache blocks produced under a different model, adapter, tokenizer, rope scaling or quantization recipe can produce incorrect output.
- Measure cache bytes per token and active capacity.
- Evaluate long-context tasks at several depths.
- Include cache format in reuse keys.
- Canary cache quantization independently from weights.
Perplexity is not enough for a production decision
Aggregate perplexity can miss failures in code syntax, arithmetic, JSON generation, tool selection, refusal behavior, rare languages and long-context evidence use. Quantization may preserve average accuracy while changing confidence margins or increasing instability on specific prompts.
Acceptance should combine model-level metrics with application outcomes. Compare exact task success, structured-output validity, safety decisions, hallucination rate, calibration, subgroup performance and consistency across seeds. Use paired tests against the same high-precision outputs where appropriate, but retain human or authoritative ground truth.
Define tolerances before seeing results. A memory-saving candidate should not be accepted because its losses seem small after the fact.
- Set task-specific quality budgets in advance.
- Slice by language, modality and context length.
- Retest safety and structured outputs.
- Use authoritative outcomes for application tasks.
Low-bit releases need observability and rollback
A quantized model is not a one-time conversion. New runtime versions, kernels, drivers, adapters, rope settings or model revisions can change numerical behavior and performance. Each combination needs canary evidence before broad rollout.
Production telemetry should record release identity, tensor format map, fallback kernels, memory, cache occupancy, TTFT, token cadence, retries and task-quality proxies. Sudden fallback rates or latency changes can indicate that an optimized path stopped executing.
Keep the high-precision or higher-bit release available for rollback and difficult workloads. Routing can send sensitive tasks, very long contexts or unsupported hardware to the safer artifact while low-bit candidates handle qualified traffic.
- Canary by workload and hardware class.
- Alert on kernel fallback and memory drift.
- Preserve a warm rollback artifact.
- Requalify after model, adapter or runtime changes.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Complete model footprint | Weights, scales, zero points, metadata and retained high-precision modules | Nominal bit width understates the deployable artifact. |
| Peak device memory | Weights, activations, workspace, graphs and KV cache at representative concurrency | Determines fit and headroom. |
| Active-token capacity | Maximum concurrent cached tokens within the memory and stability limit | Shows the benefit of weight and cache precision together. |
| Time to first token | Queue plus prefill latency by input length and batch | Weight-only quantization may help decode more than prefill. |
| Inter-token latency | Streaming token cadence at p50, p95 and p99 | Captures the user-visible decode path. |
| SLO-qualified goodput | Accepted tasks completed inside latency and quality budgets per second | Combines performance with correctness. |
| Kernel coverage | Share of eligible operations using intended low-bit fused kernels | Detects silent fallback. |
| Fallback overhead | Count and time of dequantization, graph breaks and high-precision operators | Explains why a smaller model may not be faster. |
| Task-quality delta | Difference from the pinned high-precision baseline on authoritative tasks | Measures application impact. |
| Long-context retention | Retrieval, copying and reasoning accuracy across context depths | Qualifies quantized KV cache. |
| Calibration robustness | Variation across calibration samples, seeds and domains | Reveals overfitting to a convenient sample. |
| Safety and calibration drift | Refusal, risk classification and confidence changes | Low precision can alter boundary cases. |
| Energy per accepted task | Measured device and host energy divided by accepted completions | Avoids equating lower bits with lower energy. |
| Complete cost per accepted task | Serving, qualification, fallback and operational cost divided by accepted work | Supports an economic release decision. |
Four sensible deployment patterns
Native FP8 datacenter serving
- Where it fits
- Hopper, Blackwell, MI350-class or other hardware with qualified FP8 kernels
- What you take on
- Broad arithmetic acceleration with lower compression than four-bit formats.
Weight-only INT4 serving
- Where it fits
- Memory-bound decode on GPUs, CPUs and constrained local devices
- What you take on
- Strong footprint reduction but limited activation and prefill acceleration.
Mixed FP4 or MXFP4 serving
- Where it fits
- Next-generation hardware with native block-scaled four-bit execution
- What you take on
- Highest capacity potential with tighter calibration and kernel requirements.
Tiered precision routing
- Where it fits
- Services spanning several hardware classes or risk levels
- What you take on
- More artifacts and routing complexity, but safer fallback for sensitive workloads.
Where projects usually go wrong
Bit width treated as the release identity
What you see: Two incompatible artifacts are both called INT4 or FP4
What to do: Record full tensor map, scale, packing, runtime and hardware identity.
Unsupported kernel path
What you see: The checkpoint is smaller but latency is unchanged or worse
What to do: Trace operator dispatch and fail qualification on excessive fallback.
Unrepresentative calibration
What you see: Benchmark text passes while production code, languages or long prompts fail
What to do: Calibrate on a governed production-like distribution.
Evaluation contamination
What you see: Calibration includes protected benchmark examples
What to do: Separate calibration, tuning and final holdouts with lineage checks.
Over-quantized sensitive modules
What you see: Embeddings, routers or output heads cause disproportionate degradation
What to do: Use layer sensitivity and mixed precision.
KV cache assumed safe
What you see: Short prompts pass but long-context retrieval collapses
What to do: Qualify cache precision independently across context depths.
QAT-runtime mismatch
What you see: Fake-quantized training looks good but exported kernels regress
What to do: Compare converted artifacts with the exact serving runtime.
Hidden high-precision copies
What you see: Memory savings disappear because duplicate weights or fallback buffers remain
What to do: Measure resident memory and artifact contents, not file labels.
Unsafe community checkpoint
What you see: Unknown scales, recipes or converter versions cannot be reproduced
What to do: Require signed provenance or regenerate from a trusted source model.
Quality judged by perplexity alone
What you see: Structured output, tools, code or safety behavior regress
What to do: Use application and subgroup acceptance suites.
No rollback capacity
What you see: A precision regression affects all traffic after rollout
What to do: Keep a warm higher-precision artifact and reversible routing.
Hardware drift
What you see: Driver, compiler or device changes alter kernels and outputs
What to do: Bind qualification to a compatibility matrix and re-canary changes.
A checklist you can actually use
- Freeze the source model, tokenizer, adapters and sampling baseline.
- Define latency, capacity, quality, safety and cost budgets.
- Measure the production prompt and generation distribution.
- Profile weight, activation and KV-cache memory separately.
- Identify sensitive layers and tensor classes.
- Select candidate formats supported by the target device.
- Specify scale type, granularity, group size and zero-point rules.
- Choose protected modules and fallback precision.
- Govern calibration data and keep final holdouts separate.
- Fingerprint calibration preprocessing, samples and random seeds.
- Compare simple rounding with AWQ, GPTQ, smoothing or rotations.
- Use QAT only for a measured quality gap.
- Verify packed weights and scale metadata after export.
- Pin runtime, compiler, driver and kernel versions.
- Audit low-bit kernel coverage and dequantization fallbacks.
- Measure cold load, steady state and peak concurrency.
- Report TTFT, inter-token latency and SLO-qualified goodput.
- Measure active-token capacity and cache bytes per token.
- Test short, long and adversarial context workloads.
- Evaluate task success, structured outputs and safety slices.
- Measure calibration and subgroup drift.
- Sign the recipe, source model and release manifest.
- Canary by hardware and workload class.
- Alert on fallback, memory and quality-proxy changes.
- Retain and test a higher-precision rollback path.
Terms worth knowing
- Quantization
- Mapping values to a smaller set of representable numbers for storage or computation.
- PTQ
- Post-training quantization applied after model training, often using calibration or weight statistics.
- QAT
- Quantization-aware training that simulates low-bit rounding during optimization.
- Weight-only quantization
- Compression of model weights while activations remain at higher precision.
- W8A8
- A scheme using eight-bit weights and eight-bit activations.
- Group size
- Number of values that share one scale and optional zero point.
- Per-channel scaling
- Separate quantization parameters for individual output or input channels.
- Block scaling
- Shared scale or exponent for a small block of values, used by microscaling formats.
- Zero point
- Integer offset representing real zero in an asymmetric quantization mapping.
- Calibration set
- Representative data used to estimate ranges, scales or reconstruction parameters.
- Outlier
- A value whose magnitude can dominate the quantization range and increase error elsewhere.
- Dequantization
- Conversion of low-bit values back to a higher-precision representation for computation.
- Kernel fallback
- Execution through a generic or higher-precision path when the intended optimized kernel is unavailable.
- KV-cache quantization
- Lower-precision storage or computation for attention keys and values from prior tokens.
- Mixed precision
- Use of different numeric formats across tensors, layers or operations in one model.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 NVIDIA TensorRT quantization schemesdocs.nvidia.com
- 02 NVIDIA TensorRT-LLM quantizationnvidia.github.io
- 03 NVIDIA TensorRT-LLM precisionnvidia.github.io
- 04 NVIDIA TensorRT-LLM KV cachenvidia.github.io
- 05 NVIDIA TensorRT-LLM memory usagenvidia.github.io
- 06 NVIDIA TensorRT-LLM performance tuningnvidia.github.io
- 07 NVIDIA Model Optimizer documentationnvidia.github.io
- 08 NVIDIA Model Optimizer post-training quantizationnvidia.github.io
- 09 NVIDIA Model Optimizer LLM PTQ examplegithub.com
- 10 NVIDIA Blackwell architecturenvidia.com
- 11 NVIDIA Transformer Enginedocs.nvidia.com
- 12 NVIDIA CUDA Math API FP8 typesdocs.nvidia.com
- 13 PyTorch torchao documentationdocs.pytorch.org
- 14 PyTorch torchao quantization overviewdocs.pytorch.org
- 15 PyTorch torchao quantized inferencedocs.pytorch.org
- 16 PyTorch torchao quantization-aware trainingdocs.pytorch.org
- 17 PyTorch torchao quantization APIdocs.pytorch.org
- 18 PyTorch torchao quantized trainingdocs.pytorch.org
- 19 vLLM quantization overviewdocs.vllm.ai
- 20 vLLM FP8 quantizationdocs.vllm.ai
- 21 vLLM AWQ quantizationdocs.vllm.ai
- 22 vLLM GPTQModel quantizationdocs.vllm.ai
- 23 vLLM bitsandbytes quantizationdocs.vllm.ai
- 24 vLLM compressed-tensors quantizationdocs.vllm.ai
- 25 vLLM quantized KV cachedocs.vllm.ai
- 26 Hugging Face Transformers quantizationhuggingface.co
- 27 Hugging Face quantization conceptshuggingface.co
- 28 Hugging Face bitsandbyteshuggingface.co
- 29 Hugging Face AWQhuggingface.co
- 30 Hugging Face GPTQhuggingface.co
- 31 Hugging Face HQQhuggingface.co
- 32 Hugging Face AQLMhuggingface.co
- 33 Hugging Face SpQRhuggingface.co
- 34 Hugging Face bitsandbytes documentationhuggingface.co
- 35 Intel OpenVINO 4-bit weight quantizationdocs.openvino.ai
- 36 Intel OpenVINO weight compressiondocs.openvino.ai
- 37 Intel Neural Network Compression Frameworkgithub.com
- 38 Intel Neural Compressor weight-only quantizationgithub.com
- 39 AMD Quark documentationquark.docs.amd.com
- 40 AMD Quark examplesgithub.com
- 41 Microsoft Olive quantizationmicrosoft.github.io
- 42 Microsoft Olive quantize commandmicrosoft.github.io
- 43 ONNX Runtime quantizationonnxruntime.ai
- 44 Google AQT repositorygithub.com
- 45 Open Compute Project Microscaling Formats specificationopencompute.org
- 46 GGUF specificationgithub.com
- 47 llama.cpp quantization toolsgithub.com
- 48 AutoGPTQ repositorygithub.com
- 49 AutoAWQ repositorygithub.com
- 50 Marlin repositorygithub.com
- 51 LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scalearxiv.org
- 52 GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformersarxiv.org
- 53 SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Modelsarxiv.org
- 54 ZeroQuant: Efficient and Affordable Post-Training Quantization for Large-Scale Transformersarxiv.org
- 55 QLoRA: Efficient Finetuning of Quantized LLMsarxiv.org
- 56 AWQ: Activation-aware Weight Quantization for LLM Compression and Accelerationarxiv.org
- 57 OmniQuant: Omnidirectionally Calibrated Quantization for Large Language Modelsarxiv.org
- 58 SpQR: A Sparse-Quantized Representation for Near-Lossless LLM Weight Compressionarxiv.org
- 59 QuIP: 2-Bit Quantization of Large Language Models With Guaranteesarxiv.org
- 60 QuIP#: Even Better LLM Quantization with Hadamard Incoherence and Lattice Codebooksarxiv.org
- 61 AQLM: Extreme Compression of Large Language Models via Additive Quantizationarxiv.org
- 62 HQQ: Half-Quadratic Quantization of Large Machine Learning Modelsarxiv.org
- 63 KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cachearxiv.org
- 64 KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantizationarxiv.org
- 65 Atom: Low-bit Quantization for Efficient and Accurate LLM Servingarxiv.org
- 66 QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Servingarxiv.org
- 67 QuaRot: Outlier-Free 4-Bit Inference in Rotated LLMsarxiv.org
- 68 SpinQuant: LLM Quantization with Learned Rotationsarxiv.org
- 69 FLUTE: Flexible Lookup Table Engine for Quantized LLM Inferencearxiv.org
- 70 BitNet: Scaling 1-bit Transformers for Large Language Modelsarxiv.org
- 71 The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bitsarxiv.org
- 72 FP8 Formats for Deep Learningarxiv.org
- 73 Post Training Quantization of Large Language Models with Microscaling Formatsarxiv.org
- 74 Optimizing Large Language Model Training Using FP4 Quantizationarxiv.org
- 75 FireQ: Fast INT4-FP8 Kernel and RoPE-aware Quantization for LLM Inference Accelerationarxiv.org
- 76 SharQ: Bridging Activation Sparsity and FP4 Quantization for LLM Inferencearxiv.org
- 77 DeepSeek-V3 Technical Reportarxiv.org
- 78 QServe repositorygithub.com
- 79 LLM Compressor documentationdocs.vllm.ai
- 80 compressed-tensors repositorygithub.com