↓ Skip to main content
Le Site de François
  1. Index/

Quantization

Ai Quantization Fp8 Int8 Inference Llm Gpu Nim Vllm

Quantization is the process of representing a model’s weights and/or activations with fewer bits than full FP32 training precision—commonly FP16, BF16, FP8, INT8, or INT4 (GPTQ, AWQ, GGUF-style formats). The objective is lower GPU memory (larger models or more concurrent sessions per card), higher throughput, and sometimes faster kernels on hardware with native low-precision units, at the cost of possible quality degradation if pushed too aggressively. Quantization can be applied post-training (calibration on a sample dataset) or during training (quantization-aware training). For inference, serving engines vLLM and NIM load quantized checkpoints and dispatch to vendor libraries (TensorRT-LLM, CUTLASS, etc.) that implement fused low-precision matmuls.

Architecturally, quantization changes the memory/compute balance on the accelerator, not the role of the CPU. Weights shrink (e.g. 70B FP16 → much less VRAM with INT4), so models that could not fit on one GPU may serve without tensor parallel sharding; decode may become more compute-bound on tensor cores supporting FP8. A CPU fallback for INT4 LLMs is generally impractical at useful speeds. Different schemes matter: weight-only vs activation quantization, per-channel scales, and dynamic vs static scales affect accuracy on reasoning and code tasks. Quantized models are not interchangeable binaries—each format requires matching runtime support in CUDA/ROCm stacks and the serving engine.

Red Hat documents quantized inference on OpenShift AI and RHEL GPU nodes: validated driver stacks, container images with vLLM or NVIDIA NIM, and capacity guidance (how many users per GPU at FP8 vs FP16). Red Hat does not define a proprietary quant format; customers use Hugging Face–published AWQ/GPTQ models or vendor NIMs with pre-quantized artifacts. Platform teams treat quantization as a release and test decision—benchmark perplexity and task accuracy after quant—within the same GitOps and model-promotion workflows as full-precision deployments.

Related

Inference

Ai Inference Serving Llm Vllm Nim Production Mlops
Inference is the operational phase of machine learning where a trained model is applied to new inputs to produce outputs: next tokens in an LLM, bounding boxes in vision, embeddings for search, or scores in tabular models. Its objective is reliable serving at scale—honoring latency targets (time to first token, p99 completion time), throughput (requests or tokens per second), availability, and cost per query—rather than improving weights. In generative AI, inference splits into prefill (processing the prompt in one or few forward passes) and decode (autoregressive generation of each output token), each with different bottlenecks. Production inference adds API gateways, auth, rate limiting, observability, model versioning, A/B tests, and guardrails; the model file is read-mostly while KV cache and batch state are ephemeral per session.

vLLM

Ai Vllm Inference Llm Gpu Serving Kubernetes Pagedattention
vLLM is an open-source library and serving stack for large language model (LLM) inference. Its objective is to turn a trained model into a production service that sustains many concurrent users with low latency and high tokens per second per GPU. vLLM targets the inference phase (prefill + decode), not training: it loads weights onto accelerators, batches incoming prompts, schedules decode steps, and streams completions back to clients over HTTP/gRPC (often via an OpenAI-compatible API). It has become a de facto engine behind many private and cloud AI gateways because it ships integrations for Hugging Face models, LoRA adapters, tensor parallelism, pipeline parallelism, speculative decoding, and quantization (GPTQ, AWQ, FP8).

Decode

Ai Decode Inference Llm Kv-Cache Vllm Throughput Latency
Decode is the second stage of LLM inference: after prefill has stored keys and values for the prompt, the model generates one new token per forward pass, appends it to the sequence, extends the KV cache, and repeats until a stop condition (EOS token, max length, or API limit). Its objective is fluent continuation—answer text, code, or tool-call JSON—at acceptable inter-token latency and cluster throughput (tokens per second across many concurrent sessions). Decode drives the “typing” experience in chat UIs; prefill drives how long users wait before the first character appears.