LLM Inference Optimization with vLLM and PagedAttention

We design and deploy artificial intelligence systems: from prototype to production-ready solutions. Our team combines expertise in machine learning, data engineering and MLOps to make AI work not in the lab, but in real business.
Showing 1 of 1All 1566 services
LLM Inference Optimization with vLLM and PagedAttention
Medium
~3-5 days
Frequently Asked Questions

AI Development Areas

AI Solution Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1317
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1226
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    925
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1156
  • image_logo-advance_0.webp
    B2B Advance company logo design
    620
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    894

Optimizing LLM Inference with vLLM

vLLM is the leading open-source engine for high-performance LLM inference and the production standard. Its core innovation is PagedAttention — a KV-cache management mechanism modeled on OS virtual memory. PagedAttention eliminates memory fragmentation and increases throughput 15–24× over a naive HuggingFace implementation. We use vLLM as the foundation for all production LLM inference deployments. In our practice, vLLM processes hundreds of concurrent requests per second on existing hardware. One of our clients reduced monthly inference costs by 3× after migrating to vLLM with AWQ quantization. If you run LLMs in production and face high latency or inefficient GPU use, vLLM resolves these at the architecture level. We deliver vLLM deployment and optimization turnkey — including server setup, quantization, speculative decoding, and load testing. Contact us to evaluate your infrastructure and get a realistic optimization plan.

Why Standard HuggingFace Transformers Are Insufficient

HF transformers are good for experiments, bad for production:

  • Each request is processed independently — no batching of requests
  • The KV cache is stored entirely for each sequence — VRAM is used inefficiently
  • No prefill/decode separation
  • Throughput: ~10–50 tokens/sec per request

vLLM on the same GPUs: 500–2000 tokens/sec via concurrent batching.

Basic vLLM deployment

# Installation
pip install vllm

# Launch server (OpenAI-compatible API)
python -m vllm.entrypoints.openai.api_server \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --tensor-parallel-size 1 \       # single GPU
  --max-model-len 8192 \
  --max-num-seqs 256 \             # maximum concurrent batch
  --gpu-memory-utilization 0.90 \  # 90% VRAM for model
  --host 0.0.0.0 \
  --port 8000
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="none")

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.3",
    messages=[{"role": "user", "content": "Explain transformer attention"}],
    max_tokens=500,
    temperature=0.7
)

PagedAttention: How it works

Standard KV cache: a contiguous VRAM block is allocated for each sequence at maximum length. Fragmentation wastes up to 60% of memory between sequences.

PagedAttention divides the KV cache into fixed-size pages (usually 16 tokens). Pages are allocated on demand and can be non-contiguous. Prefix sharing: sequences with a common prefix (system prompt) share the same KV-cache pages. This saves VRAM when many requests use identical system prompts.

How Continuous Batching Increases Throughput

Continuous batching allows the server to start processing a new request without waiting for previous ones to finish. vLLM implements this at the KV-cache level. It dynamically adds and removes sequences from the current forward pass. Unlike static batching (where requests accumulate in a buffer), continuous batching minimizes GPU idle time. The throughput gain is up to 50% compared to static batching alone.

Tensor Parallelism for Large Models

# LLaMA-70B on 4xA100 80GB
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-70b-instruct \
  --tensor-parallel-size 4 \       # shard across 4 GPUs
  --dtype bfloat16 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.95

Tensor parallelism splits attention heads and FFN matrices across GPUs. For the 70B model: 4xA100 80GB = sufficient for BF16.

Quantization to save VRAM

# AWQ quantization (best quality among 4-bit methods)
python -m vllm.entrypoints.openai.api_server \
  --model TheBloke/Mistral-7B-Instruct-v0.3-AWQ \
  --quantization awq \
  --dtype auto

# GPTQ
python -m vllm.entrypoints.openai.api_server \
  --model TheBloke/Llama-2-13B-GPTQ \
  --quantization gptq

# FP8 (for H100)
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-8b \
  --quantization fp8

Result: 7B model in AWQ 4-bit takes up ~4 GB of VRAM instead of ~14 GB in BF16.

Speculative Decoding

A small model (draft) generates several tokens. A larger model (target) verifies them in parallel. On a match, all tokens are accepted as a single forward pass.

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-70b-instruct \
  --speculative-model meta-llama/Llama-3-8b-instruct \
  --num-speculative-tokens 5 \
  --tensor-parallel-size 4

Gain: 1.5–2.5× speedup for typical texts with less than 1% quality change.

Optimization Method Comparison

Method Typical throughput gain Latency impact VRAM requirement
PagedAttention + continuous batching 10–20× Reduced No extra cost
Tensor parallelism (4 GPU) 3–4× Reduced ~70% of single GPU
AWQ 4-bit quantization 1.5–2× Minimal change 60–70% reduction
Speculative decoding 1.5–2.5× Reduced Extra VRAM for draft model

Performance tuning

# Parameters for maximum throughput (not latency)
VLLM_CONFIG = {
    "max_num_seqs": 512,            # more concurrent requests
    "max_num_batched_tokens": 32768, # tokens in one forward pass
    "block_size": 32,               # KV-cache page size
    "swap_space": 4,                # GB for CPU offload on VRAM OOM
}

# Parameters for minimum latency (not throughput)
VLLM_CONFIG_LATENCY = {
    "max_num_seqs": 32,
    "max_num_batched_tokens": 4096,
    "disable_async_output_proc": False,
}

Performance benchmark

On one A100 80GB, Mistral-7B-Instruct, 500-token responses:

Implementation Throughput (req/s) P99 Latency
HF transformers (batch=1) 1.2 8.5s
HF transformers (batch=16) 4.1 22s
vLLM (256 concurrent) 28.5 12s
vLLM + AWQ 4-bit 52.3 7s

What Is Included in Our vLLM Optimization Service

Our inference optimization service covers the complete delivery:

  • Audit of your current inference infrastructure and pipeline
  • vLLM configuration for your specific model and load profile
  • Server deployment with continuous batching, tensor parallelism, and quantization
  • Latency P99 and throughput testing (up to 2,000 tokens/sec)
  • Operations documentation and parameter tuning guide
  • Team training on monitoring, logging, and model updates
  • Technical support during launch included

Our team has 5+ years of MLOps experience across dozens of production LLM systems. We guarantee stable operation under load. Contact us to discuss your workload and get a concrete optimization plan.