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.

80%+

GPU utilization with continuous batching

5-10x

Cost reduction vs naive serving

50%

Memory reduction from INT8 quantization

2-3x

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

vLLM's continuous batching implementation achieves 23x higher throughput than HuggingFace Transformers naive serving on the same hardware. The improvement is largest when request output lengths vary significantly.

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

Optimal batch size depends on model size, GPU memory, and target latency. For a LLaMA-70B on 4x H100s, batch sizes of 32-64 typically maximize throughput while maintaining acceptable latency. Larger batches increase throughput but also increase tail latency.

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

PagedAttention enables prefix caching — sharing KV cache pages across requests with identical prefixes (system prompts, few-shot examples). For applications with long shared prefixes, this can reduce computation by 30-50%.

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

FormatMemory vs FP16Quality LossThroughput GainHardware SupportBest For
FP16BaselineNoneBaselineAll modern GPUsQuality-critical applications
BF16Same as FP16MinimalSame as FP16A100, H100, newerTraining and inference
INT8 (W8A8)-50%<1%1.5-2xA100, H100Production serving
INT4 (GPTQ)-75%1-3%2-3xAll CUDA GPUsMemory-constrained serving
FP8-50%<0.5%1.5-2xH100, H200High-throughput production
INT4 (AWQ)-75%<2%2-3xAll CUDA GPUsEdge 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

Quality impact varies significantly by model and task. Code generation and mathematical reasoning tasks are more sensitive to quantization than general text generation. Always benchmark your specific use case before deploying quantized models in production.

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

The draft model should be from the same model family as the target model for best acceptance rates. LLaMA-7B as a draft for LLaMA-70B achieves 70-80% acceptance rates. Mismatched architectures typically achieve 50-60%.

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

StreamingDetokenizerMetrics

Token Sampler

Temperature, top-p, speculative verification

SamplerSpec VerifyLogit Processor

GPU Compute

Flash Attention, fused kernels, tensor parallelism

Flash Attention 2Fused KernelsTensor Parallel

Quantized Model Weights

INT8/FP8 weights, activation quantization

W8A8 KernelsFP8 ComputeDequant Fuse

PagedAttention KV Cache

Virtual memory KV management, prefix caching

Block ManagerPrefix CacheEviction Policy

Continuous Batcher

Iteration-level scheduling, dynamic batch assembly

Iteration SchedulerBatch AssemblerSequence Manager

Request Queue

Priority scheduling, rate limiting, request deduplication

Priority QueueRate LimiterRequest Dedup
Stack layers — top to bottom: highest to lowest abstraction

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

FrameworkThroughputLatencyQuantizationMulti-GPUProduction-ReadyBest For
vLLMExcellentGoodINT4/INT8/FP8Tensor + PipelineYesGeneral LLM serving
TensorRT-LLMBestBestINT4/INT8/FP8Tensor + PipelineYesNVIDIA-only max throughput
TGI (HuggingFace)GoodGoodINT4/INT8Tensor ParallelYesHuggingFace ecosystem
Triton Inference ServerGoodGoodVia backendsYesYesMulti-model serving
OllamaBasicGoodGGUF (INT4)LimitedDev/TestLocal 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.

100,000 req/day
1,00010,000,000
1,000 tokens
2004,000
5 $
0.530
4 x
210

Estimated results

$15,000

Current monthly cost

$3,750

Optimized monthly cost

$11,250

Monthly savings

$135,000

Annual savings

1.3 mo

Break-even (months)

3B

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

Allocate 90% of GPU memory to the KV cache (vLLM default). Reserve 10% for model weights overhead and activations. For a 70B model on 4x H100 80GB (320GB total), approximately 140GB is used for weights, leaving 180GB for KV cache — enough for 200+ concurrent sequences at 4K context.

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

Maximizing throughput (large batches) increases tail latency. For interactive applications, set a maximum batch size that keeps p99 latency under your SLA. For batch processing workloads, maximize batch size for lowest cost per token.

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.