Introduction
LLM inference at production scale demands a layered optimization strategy. Naive serving frameworks leave 70-80% of GPU capacity idle. By combining continuous batching, PagedAttention KV cache management, quantization, and speculative decoding, teams can reduce cost-per-token by 5-10x while simultaneously improving latency.
A typical naive implementation — one request per GPU at a time — achieves 15-25% GPU utilization. The GPU spends most of its time waiting for memory transfers and sequential token generation rather than performing parallel matrix multiplications. At $2-4/hour for an H100, this translates directly to wasted capital.
Modern inference optimization addresses this through four complementary techniques: continuous batching to maximize GPU occupancy, PagedAttention to eliminate KV cache fragmentation, quantization to reduce memory footprint, and speculative decoding to reduce per-token latency. Together, these techniques can reduce cost-per-token by 5-10x compared to naive implementations.
GPU utilization with continuous batching
Cost reduction vs naive serving
Memory reduction from INT8 quantization
Latency reduction from speculative decoding
Continuous batching
Traditional static batching waits for a batch of requests to arrive, processes them together, and returns all results before accepting new requests. This approach fails for LLMs because requests have variable output lengths — a short response finishes while others are still generating, leaving GPU capacity idle.
Continuous batching (also called iteration-level scheduling) solves this by inserting new requests into the batch at each token generation step. When a sequence completes, its slot is immediately filled with a waiting request. This keeps the GPU fully occupied regardless of output length variance.
Continuous batching impact
The key implementation detail is the iteration-level scheduler. At each forward pass, the scheduler decides which sequences to include in the batch, respecting memory constraints and priority policies. Sequences that have finished generation are evicted and replaced with queued requests.
Batch size tuning
PagedAttention
The KV cache stores key and value tensors for all previously generated tokens, enabling efficient attention computation without recomputing past context. In naive implementations, each sequence is allocated a contiguous block of GPU memory for its maximum possible KV cache size. This causes severe memory fragmentation — memory is reserved but unused.
PagedAttention, introduced in the vLLM paper, applies virtual memory concepts from operating systems to KV cache management. Memory is divided into fixed-size pages (typically 16 tokens per page), and sequences are allocated pages on demand. Non-contiguous physical pages are mapped to contiguous logical addresses via a block table.
The result is near-zero memory waste. Traditional systems waste 60-80% of KV cache memory to fragmentation and over-reservation. PagedAttention reduces this to under 4%, enabling significantly larger batch sizes on the same hardware.
Prefix caching
Quantization strategies
Quantization reduces the numerical precision of model weights and activations, decreasing memory footprint and increasing throughput. The tradeoff is potential quality degradation, though modern quantization techniques minimize this impact.
Quantization format comparison
| Format | Memory vs FP16 | Quality Loss | Throughput Gain | Hardware Support | Best For |
|---|---|---|---|---|---|
| FP16 | Baseline | None | Baseline | All modern GPUs | Quality-critical applications |
| BF16 | Same as FP16 | Minimal | Same as FP16 | A100, H100, newer | Training and inference |
| INT8 (W8A8) | -50% | <1% | 1.5-2x | A100, H100 | Production serving |
| INT4 (GPTQ) | -75% | 1-3% | 2-3x | All CUDA GPUs | Memory-constrained serving |
| FP8 | -50% | <0.5% | 1.5-2x | H100, H200 | High-throughput production |
| INT4 (AWQ) | -75% | <2% | 2-3x | All CUDA GPUs | Edge and consumer GPUs |
For production serving, INT8 quantization (specifically W8A8 — 8-bit weights and activations) is the recommended starting point. It halves memory requirements with minimal quality impact, enabling larger batch sizes and higher throughput. FP8 on H100 hardware offers similar memory savings with even lower quality impact.
Quantization and model quality
Speculative decoding
Autoregressive generation is inherently sequential — each token requires a full forward pass through the model. For large models, this creates a latency floor that cannot be reduced by adding more GPUs. Speculative decoding breaks this constraint by using a small draft model to propose multiple tokens simultaneously, then verifying them in parallel with the target model.
The draft model (typically 1-7B parameters) generates a sequence of candidate tokens. The target model then verifies all candidates in a single forward pass using parallel attention. Accepted tokens are kept; rejected tokens cause the sequence to revert to the last accepted position.
In practice, speculative decoding achieves 2-3x latency reduction for tasks where the draft model has high acceptance rates (typically 70-85%). Tasks with predictable outputs (code completion, structured generation) benefit most.
Draft model selection
Inference stack architecture
A production inference stack integrates all optimization techniques into a coherent serving pipeline. Each layer addresses a specific bottleneck in the serving process.
Inference Optimization Stack
Response
Streaming output, detokenization, metrics
Token Sampler
Temperature, top-p, speculative verification
GPU Compute
Flash Attention, fused kernels, tensor parallelism
Quantized Model Weights
INT8/FP8 weights, activation quantization
PagedAttention KV Cache
Virtual memory KV management, prefix caching
Continuous Batcher
Iteration-level scheduling, dynamic batch assembly
Request Queue
Priority scheduling, rate limiting, request deduplication
Framework comparison
Choosing the right serving framework is one of the highest-impact infrastructure decisions. Each framework makes different tradeoffs between throughput, latency, ease of deployment, and operational complexity.
Inference serving frameworks
| Framework | Throughput | Latency | Quantization | Multi-GPU | Production-Ready | Best For |
|---|---|---|---|---|---|---|
| vLLM | Excellent | Good | INT4/INT8/FP8 | Tensor + Pipeline | Yes | General LLM serving |
| TensorRT-LLM | Best | Best | INT4/INT8/FP8 | Tensor + Pipeline | Yes | NVIDIA-only max throughput |
| TGI (HuggingFace) | Good | Good | INT4/INT8 | Tensor Parallel | Yes | HuggingFace ecosystem |
| Triton Inference Server | Good | Good | Via backends | Yes | Yes | Multi-model serving |
| Ollama | Basic | Good | GGUF (INT4) | Limited | Dev/Test | Local development |
For most production deployments, vLLM is the recommended starting point. It implements all major optimizations (continuous batching, PagedAttention, speculative decoding), has an active open-source community, and provides an OpenAI-compatible API. TensorRT-LLM offers higher peak throughput on NVIDIA hardware but requires more operational expertise.
Optimization ROI calculator
Estimate the financial impact of inference optimization for your workload. Adjust the sliders to match your current usage and cost profile.
Inference Optimization ROI
Calculate monthly and annual savings from optimizing your LLM inference stack.
Estimated results
Current monthly cost
Optimized monthly cost
Monthly savings
Annual savings
Break-even (months)
Monthly tokens
Production configuration guide
Translating optimization techniques into production configuration requires understanding the interaction between batch size, KV cache allocation, and GPU memory. The following guidelines apply to vLLM deployments on H100 hardware.
Memory allocation strategy
Tensor parallelism should match the number of GPUs per node. For a 70B model, 4-way tensor parallelism across 4 H100s is optimal. Pipeline parallelism adds latency and should only be used when the model does not fit within a single node's GPU memory.
Enable prefix caching for applications with shared system prompts. For a 2,000-token system prompt, prefix caching eliminates 2,000 tokens of computation per request — a 50-80% reduction for short user messages.
Latency vs throughput tradeoff
Frequently asked questions
What is continuous batching and why does it matter?
Continuous batching (iteration-level scheduling) inserts new requests into the active batch at each token generation step, rather than waiting for all requests in a batch to complete. This eliminates GPU idle time caused by variable output lengths and improves utilization from 20% to 80%+. It is the single highest-impact optimization for LLM serving throughput.
What is PagedAttention?
PagedAttention is a memory management technique that applies virtual memory concepts to KV cache storage. Instead of allocating contiguous memory blocks for each sequence, it uses fixed-size pages allocated on demand. This eliminates memory fragmentation and over-reservation, reducing wasted KV cache memory from 60-80% to under 4%.
How much does quantization hurt LLM quality?
INT8 quantization (W8A8) typically causes less than 1% quality degradation on standard benchmarks for most models. INT4 quantization (GPTQ, AWQ) causes 1-3% degradation. The impact varies by task — mathematical reasoning and code generation are more sensitive than general text generation. Always benchmark your specific use case.
What is the best LLM serving framework?
vLLM is the recommended starting point for most production deployments. It implements continuous batching, PagedAttention, speculative decoding, and quantization, with an OpenAI-compatible API and active community support. TensorRT-LLM offers higher peak throughput on NVIDIA hardware but requires more operational expertise and NVIDIA-specific tooling.