vLLM Snabbstart: Högpresterande LLM-serving – 2026

vLLM är en högflödes- och minneseffektiv inferens- och serveringmotor för stora språkmotorer (LLM) som utvecklats av UC Berkeleys Sky Computing Lab.

Med sin revolutionerande PagedAttention-algoritm uppnår vLLM 14–24 gånger högre flöde än traditionella serveringsmetoder, vilket gör den till valet för LLM-deployment i produktion. För att se hur vLLM passar in bland Ollama, Docker Model Runner, LocalAI och molntillhandahållare – inklusive kostnads- och infrastrukturavvägningar – se LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

Vad är vLLM?

vLLM (virtual LLM) är en öppen källkod-bibliotek för snabb LLM-inferens och servering som snabbt blivit industristandarden för produktionsdeployment. Släppt 2023 introducerade den PagedAttention, en banbrytande teknik för minneshantering som kraftigt förbättrar serveringseffektiviteten.

Nyckelfunktioner

Hög flödesprestanda: vLLM levererar 14–24 gånger högre flöde jämfört med HuggingFace Transformers med samma hårdvara. Denna enorma prestandavinst kommer från kontinuerlig batchbearbetning, optimerade CUDA-kärl och PagedAttention-algoritmen som eliminerar minnesfragmentering.

OpenAI API-kompatibilitet: vLLM inkluderar en inbyggd API-server som är fullt kompatibel med OpenAI:s format. Detta möjliggör en smidig migration från OpenAI till egenhostad infrastruktur utan att ändra applikationskoden. Peck bara din API-klient mot vLLM:s endpoint och det fungerar transparent.

PagedAttention-algoritm: Den kärninnovation som ligger bakom vLLM:s prestanda är PagedAttention, som tillämpar konceptet av virtuellt minnespaggning på uppmärksamhetsmekanismer. Istället för att allokera kontinuerliga minnesblock för KV-cacher (vilket leder till fragmentering), delar PagedAttention upp minnet i block med fast storlek som kan allokeras efter behov. Detta minskar minnesavfall med upp till 4x och möjliggör betydligt större batchstorlekar.

Kontinuerlig batchbearbetning: Till skillnad från statisk batchbearbetning där du väntar på att alla sekvenser ska slutföras, använder vLLM kontinuerlig (rullande) batchbearbetning. Så snart en sekvens är klar kan en ny läggas till i batchen. Detta maximerar GPU-användningen och minimerar latensen för inkommande förfrågningar.

Multi-GPU-stöd: vLLM stöder tensorparallelism och pipeline-parallelism för att distribuera stora modeller över flera GPU:er. Den kan effektivt serva modeller som inte får plats i en enda GPUs minne, och stöder konfigurationer från 2 till 8+ GPU:er.

Brett modellsupport: Kompatibel med populära modelarkitekturer inklusive LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma och många fler. Stöder både instruktionsjusterade och basmodeller från HuggingFace Hub.

När ska man använda vLLM

vLLM utmärker sig i specifika scenarier där dess styrkor lyser fram:

Produktions-API-tjänster: När du behöver serva en LLM till många samtidiga användare via API, är vLLM:s höga flöde och effektiva batchbearbetning det bästa valet. Företag som kör chattbotar, kodassistenter eller innehållsgenereringstjänster gynnas av dess förmåga att hantera hundratal förfrågningar per sekund.

Högkonkurrenta arbetsbelastningar: Om din applikation har många samtidiga användare som gör förfrågningar, möjliggör vLLM:s kontinuerliga batchbearbetning och PagedAttention att serva fler användare med samma hårdvara jämfört med alternativ.

Kostnadsoptimering: När GPU-kostnader är en prioritet, innebär vLLM:s överlägsna flöde att du kan serva samma trafik med färre GPU:er, vilket direkt minskar infrastrukturskostnaderna. Den 4x minneseffektivitet som PagedAttention ger möjliggör också användning av mindre, billigare GPU-instanser.

Kubernetes-deployment: vLLM:s stateless-design och containervänliga arkitektur gör den idealisk för Kubernetes-kluster. Dess konsekenta prestanda under last och enkel resurshantering integrerar väl med molnnativa infrastrukturer.

När INTE använda vLLM: För lokal utveckling, experiment eller scenarier med en användare, ger verktyg som Ollama eller llama.cpp bättre användarupplevelse med enklare installation. vLLM:s komplexitet är motiverad när du behöver dess prestandafördelar för produktionsarbetsbelastningar.

Hur man installerar vLLM

Förutsättningar

Innan du installerar vLLM, se till att ditt system uppfyller dessa krav:

• GPU: NVIDIA GPU med beräkningsförmåga 7.0+ (V100, T4, A10, A100, H100, RTX 20/30/40-serier)
• CUDA: Version 11.8 eller högre
• Python: 3.8 till 3.11
• VRAM: Minst 16GB för 7B-modeller, 24GB+ för 13B, 40GB+ för större modeller
• Drivrutin: NVIDIA-drivrutin 450.80.02 eller nyare

Installation via pip

Den enklaste installationsmetoden är att använda pip. Detta fungerar på system med CUDA 11.8 eller nyare:

# Skapa en virtuell miljö (rekommenderas)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Installera vLLM
pip install vllm

# Verifiera installation
python -c "import vllm; print(vllm.__version__)"

För system med olika CUDA-versioner, installera den lämpliga wheel-filen:

# För CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# För CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Installation med Docker

Docker ger den mest pålitliga deploymentsmetoden, särskilt för produktion:

# Dra den officiella vLLM-avbildningen
docker pull vllm/vllm-openai:latest

# Kör vLLM med GPU-stöd
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

Flaggan --ipc=host är viktig för multi-GPU-uppsättningar eftersom den möjliggör korrekt processkommunikation.

Bygg från källkod

För de senaste funktionerna eller anpassade modifieringar, bygg från källkod:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

vLLM Snabbstartsguide

Kör din första modell

Starta vLLM med en modell via kommandoradsgränssnittet:

# Hämta och serva Mistral-7B med OpenAI-kompatibelt API
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM kommer automatiskt att hämta modellen från HuggingFace Hub (om den inte är cachad) och starta servern. Du kommer att se utdata som indikerar att servern är redo:

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

Göra API-förfrågningar

När servern körs kan du göra förfrågningar med OpenAI Python-klienten eller curl:

Använd curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Förklara vad vLLM är i en mening:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Använd OpenAI Python-klienten:

from openai import OpenAI

# Peck till din vLLM-server
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM kräver inte autentisering som standard
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Förklara vad vLLM är i en mening:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

Chat Completions API:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Du är en hjälpsam assistent."},
        {"role": "user", "content": "Vad är PagedAttention?"}
    ],
    max_tokens=200
)

print(response.choices[0].message.content)

Avancerad konfiguration

vLLM erbjuder många parametrar för att optimera prestanda:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Använd 95% av GPU-minnet
    --max-model-len 8192 \            # Maximal sekvenslängd
    --tensor-parallel-size 2 \        # Använd 2 GPU:er med tensorparallelism
    --dtype float16 \                 # Använd FP16-precision
    --max-num-seqs 256                # Maximal batchstorlek

Förklaring av viktiga parametrar:

• --gpu-memory-utilization: Hur mycket GPU-minne som ska användas (0.90 = 90%). Högre värden möjliggör större batchar men lämnar mindre marginal för minnespikar.
• --max-model-len: Maximal kontextlängd. Att minska detta sparar minne för större batchar.
• --tensor-parallel-size: Antal GPU:er att dela modellen över.
• --dtype: Datatyp för vikter (float16, bfloat16 eller float32). FP16 är oftast optimalt.
• --max-num-seqs: Maximalt antal sekvenser att bearbeta i en batch.

Jämförelse vLLM vs Ollama

Både vLLM och Ollama är populära val för lokal LLM-hostning, men de riktar sig mot olika användningsfall. Att förstå när man ska använda varje verktyg kan kraftigt påverka ditt projekt framgång.

Prestanda och flöde

vLLM är designat för maximalt flöde i multi-användarscenarier. Dess PagedAttention och kontinuerlig batchbearbetning möjliggör servning av hundratal samtidiga förfrågningar effektivt. Benchmark visar att vLLM uppnår 14–24 gånger högre flöde än standardimplementeringar och 2–4 gånger högre än Ollama under hög konkurrens.

Ollama optimerar för enkel användares interaktiva användning med fokus på låg latens för individuella förfrågningar. Medan det inte matchar vLLM:s multi-användarflöde, ger det utmärkt prestanda för utveckling och personlig användning med snabbare kallstartstider och lägre resursförbrukning i viloläge.

Användarvänlighet

Ollama vinner entydigt på enkelhet. Installationen är ett enda kommando (curl | sh), och att köra modeller är så enkelt som ollama run llama2. Den inkluderar en modellbibliotek med kvantiserade versioner optimerade för olika hårdvarupfiler. Användarupplevelsen liknar Docker – dra, kör och kör.

vLLM kräver mer uppstart: Python-miljöhantering, CUDA-installation, förståelse av serveringsparametrar och manuell modelspecifikation. Lärkurvan är brantare, men du får finjusterad kontroll över prestandaoptimering. Denna komplexitet är motiverad för produktionsdeployment där du behöver pressa ut maximal prestanda från din hårdvara.

API och integration

vLLM tillhandahåller OpenAI-kompatibla REST-API:er direkt, vilket gör den till en drop-in-ersättning för OpenAI:s API i befintliga applikationer. Detta är avgörande för att migrera produktionstjänster från molntillhandahållare till egenhostad infrastruktur utan kodändringar.

Ollama erbjuder en enklare REST-API och en dedikerad Python/JavaScript-bibliotek. Även om det fungerar, är det inte OpenAI-kompatibelt, vilket kräver kodändringar när det integreras med applikationer som förväntar sig OpenAI:s format. Men gemenskapprojekt som Ollama-OpenAI-adapter fyller denna lucka.

Minneshantering

vLLM:s PagedAttention-algoritm ger överlägsen minneseffektivitet för samtidiga förfrågningar. Den kan serva 2–4 gånger fler samtidiga användare med samma VRAM jämfört med naiva implementeringar. Detta översätts direkt till kostnadsbesparingar i produktionsdeployment.

Ollama använder enklare minneshantering lämplig för enkel användare-scenarier. Den hanterar automatiskt modelllastning/avlastning baserat på aktivitet, vilket är bekvämt för utveckling men inte optimalt för högkonkurrenta produktionsanvändning.

Multi-GPU-stöd

vLLM utmärker sig med inbyggd tensorparallelism och pipeline-parallelism, vilket effektivt distribuerar modeller över 2–8+ GPU:er. Detta är avgörande för att serva stora modeller som 70B-parameter LLM som inte får plats i en enda GPU.

Ollama har för närvarande begränsat multi-GPU-stöd, vilket fungerar bäst med en enda GPU. Detta gör den mindre lämplig för mycket stora modeller som kräver distribuerad inferens.

Användningsfallrekommendationer

Välj vLLM när:

• Du servar produktions-API:er med många samtidiga användare
• Du optimerar kostnad per förfrågan i molndeployment
• Du kör i Kubernetes eller containerorchestreringsplattformar
• Du behöver OpenAI API-kompatibilitet för befintliga applikationer
• Du servar stora modeller som kräver multi-GPU-stöd
• Prestanda och flöde är kritiska krav

Välj Ollama när:

• Lokal utveckling och experiment
• Enkelt användares interaktiva användning (personliga assistenter, chattbotar)
• Snabb prototypning och modellutvärdering
• Lära sig om LLM utan infrastrukturkomplexitet
• Kör på personliga arbetsstationer eller bärbara datorer
• Enkelhet och användarvänlighet är prioriterade

Många team använder båda: Ollama för utveckling och experiment, sedan vLLM för produktionsdeployment. Denna kombination ger utvecklareffektivitet samtidigt som den upprätthåller produktionsprestanda.

Jämförelse vLLM vs Docker Model Runner

Docker introducerade nyligen Model Runner (tidigare GenAI Stack) som deras officiella lösning för lokal AI-modelldeployment. Hur jämför den sig med vLLM?

Arkitekturfilosofi

Docker Model Runner siktar på att vara “Docker för AI” – ett enkelt, standardiserat sätt att köra AI-modeller lokalt med samma enkelhet som att köra containerar. Den abstraherar bort komplexitet och tillhandahåller ett konsekvent gränssnitt över olika modeller och ramverk.

vLLM är en specialiserad inferensmotor fokuserad uteslutande på LLM-servning med maximal prestanda. Det är ett verktyg på lägre nivå som du containerar med Docker, snarare än en komplett plattform.

Uppstart och kom igång

Docker Model Runner installation är enkel för Docker-användare:

docker model pull llama3:8b
docker model run llama3:8b

Denna likhet med Docker:s bildarbetsflöde gör det omedelbart bekant för utvecklare som redan använder containerar.

vLLM kräver mer initial uppstart (Python, CUDA, beroenden) eller att använda förbyggda Docker-bilder:

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-namn>

Prestandakaraktäristik

vLLM levererar överlägsna flöde för multi-användarscenarier på grund av PagedAttention och kontinuerlig batchbearbetning. För produktions-API-tjänster som hanterar hundratal förfrågningar per sekund, ger vLLM:s optimeringar 2–5 gånger bättre flöde än generella serveringsapproacher.

Docker Model Runner fokuserar på användarvänlighet snarare än maximal prestanda. Den är lämplig för lokal utveckling, testning och måttliga arbetsbelastningar, men implementerar inte de avancerade optimeringarna som gör vLLM exceptionell i skala.

Modellsupport

Docker Model Runner tillhandahåller en kuraterad modellbibliotek med enkommandosåtkomst till populära modeller. Den stöder flera ramverk (inte bara LLM) inklusive Stable Diffusion, Whisper och andra AI-modeller, vilket gör den mångsidigare för olika AI-arbetsbelastningar.

vLLM specialiserar sig på LLM-inferens med djup stöd för transformer-baserade språkmotorer. Den stöder alla HuggingFace-kompatibla LLM men sträcker sig inte till andra AI-modelltyper som bildgenerering eller taligenkänning.

Produktionsdeployment

vLLM är fälttestad i produktion hos företag som Anthropic, Replicate och många andra som servar miljarder tokens dagligen. Dess prestandakaraktäristik och stabilitet under tung last gör den till den de facto-standard för produktions LLM-servning.

Docker Model Runner är nyare och positionerar sig mer för utveckling och lokala testscenarier. Även om den kan serva produktionstrafik, saknar den den bevisade meritlistan och prestandaoptimeringarna som produktionsdeployment kräver.

Integrationsekosystem

vLLM integrerar med produktionsinfrastrukturverktyg: Kubernetes-operatörer, Prometheus-metrik, Ray för distribuerad servning och omfattande OpenAI API-kompatibilitet för befintliga applikationer.

Docker Model Runner integrerar naturligt i Dockers ekosystem och Docker Desktop. För team som redan är standardiserade på Docker, ger denna integration en sammanhållen upplevelse men färre specialiserade LLM-servningsfunktioner.

När använda varje

Använd vLLM för:

• Produktions LLM API-tjänster
• Högflödes, multi-användare deployment
• Kostnadskänsliga molndeployment som behöver maximal effektivitet
• Kubernetes och molnnativa miljöer
• När du behöver bevisad skalbarhet och prestanda

Använd Docker Model Runner för:

• Lokal utveckling och testning
• Kör olika AI-modelltyper (inte bara LLM)
• Team starkt investerade i Docker-ekosystemet
• Snabba experiment utan infrastrukturuppstart
• Lära och utbildningsändamål

Hybridapproach: Många team utvecklar med Docker Model Runner lokalt för bekvämlighet, sedan deployar med vLLM i produktion för prestanda. Docker Model Runner-bilder kan också användas för att köra vLLM-containerar, vilket kombinerar båda approacherna.

Bästa praxis för produktionsdeployment

Docker-deployment

Skapa en produktionsredo Docker Compose-konfiguration:

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Kubernetes-deployment

Deploya vLLM på Kubernetes för produktionskala:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

Overvakning och observabilitet

vLLM exponerar Prometheus-metrik för övervakning:

import requests

# Hämta metrik
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Viktiga metrik att övervaka:

• vllm:num_requests_running - Aktiva förfrågningar
• vllm:gpu_cache_usage_perc - KV-cacheförbrukning
• vllm:time_to_first_token - Latensmetrik
• vllm:time_per_output_token - Genereringshastighet

Prestandajustering

Optimera GPU-minnesförbrukning: Börja med --gpu-memory-utilization 0.90 och justera baserat på observerat beteende. Högre värden möjliggör större batchar men riskerar OOM-fel under trafikpikar.

Justera max sekvenslängd: Om ditt användningsfall inte behöver full kontextlängd, minska --max-model-len. Detta frigör minne för större batchar. Om du bara behöver 4K kontext, sätt --max-model-len 4096 istället för modellens maximum (ofta 8K–32K).

Välj lämplig kvantisering: För modeller som stöder det, använd kvantiserade versioner (8-bit, 4-bit) för att minska minne och öka flöde:

--quantization awq  # För AWQ-kvantiserade modeller
--quantization gptq # För GPTQ-kvantiserade modeller

Aktivera prefixcaching: För applikationer med upprepade promptar (som chattbotar med systemmeddelanden), aktivera prefixcaching:

--enable-prefix-caching

Detta cacher KV-värden för vanliga prefix, vilket minskar beräkning för förfrågningar som delar samma promptprefix.

felsökning av vanliga problem

Out of Memory-fel

Symtom: Servern kraschar med CUDA out of memory-fel.

Lösningar:

• Minska --gpu-memory-utilization till 0.85 eller 0.80
• Minska --max-model-len om ditt användningsfall tillåter
• Minska --max-num-seqs för att minska batchstorlek
• Använd en kvantiserad modellversion
• Aktivera tensorparallelism för att distribuera över fler GPU:er

Lågt flöde

Symtom: Servern hanterar färre förfrågningar än förväntat.

Lösningar:

• Öka --max-num-seqs för att tillåta större batchar
• Öka --gpu-memory-utilization om du har utrymme kvar
• Kontrollera om CPU:n är flaskhalsen med htop – överväg snabbare CPU:er
• Verifiera GPU-användning med nvidia-smi – bör vara 95%+
• Aktivera FP16 om du använder FP32: --dtype float16

Lång första tokens tid

Symtom: Hög latens innan generationen börjar.

Lösningar:

• Använd mindre modeller för latenskritiska applikationer
• Aktivera prefixcaching för upprepade promptar
• Minska --max-num-seqs för att prioritera latens över flöde
• Överväg spekulativ dekodning för modeller som stöder det
• Optimera tensorparallelism-konfiguration

Modelllastningsfel

Symtom: Servern startar inte, kan inte lasta modellen.

Lösningar:

• Verifiera att modellnamnet matchar HuggingFace-formatet exakt
• Kontrollera nätverksanslutning till HuggingFace Hub
• Se till att det finns tillräckligt med diskutrymme i ~/.cache/huggingface
• För gated-modeller, sätt HF_TOKEN miljövariabel
• Försök att hämta manuellt med huggingface-cli download <model>

Avancerade funktioner

Spekulativ dekodning

vLLM stöder spekulativ dekodning, där en mindre utkastmodell föreslår tokens som en större målmodell verifierar. Detta kan påskynda generationen med 1,5–2x:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

LoRA-adapter

Serva flera LoRA-adapter ovanpå en basmodell utan att lasta flera fullständiga modeller:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Sedan specificera vilken adapter som ska användas per förfrågan:

response = client.completions.create(
    model="sql-lora",  # Använd SQL-adaptern
    prompt="Konvertera detta till SQL: Visa alla användare skapade denna månad"
)

Multi-LoRA-servning

vLLM:s multi-LoRA-servning möjliggör hosting av dussintals finjusterade adapter med minimal minnesöverlast. Detta är idealiskt för att serva kundspecifika eller uppgiftsspecifika modellvarianter:

# Förfrågan med specifik LoRA-adapter
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Skriv SQL-fråga"}],
    extra_body={"lora_name": "sql-lora"}
)

Prefixcaching

Aktivera automatisk prefixcaching för att undvika omberäkning av KV-cach för upprepade promptprefix:

--enable-prefix-caching

Detta är särskilt effektivt för:

• Chattbotar med fasta systempromptar
• RAG-applikationer med konsekventa kontextmallar
• Few-shot-lärande-promptar upprepade över förfrågningar

Prefixcaching kan minska time-to-first-token med 50–80% för förfrågningar som delar promptprefix.

Integreringsexempel

LangChain-integration

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Förklara PagedAttention i enkla termer")
print(response)

LlamaIndex-integration

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("Vad är vLLM?")
print(response)

FastAPI-applikation

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Prestandabenchmarks

Reallivets prestandadata hjälper till att illustrera vLLM:s fördelar:

Flödesjämförelse (Mistral-7B på A100 GPU):

• vLLM: ~3 500 tokens/sekund med 64 samtidiga användare
• HuggingFace Transformers: ~250 tokens/sekund med samma konkurrens
• Ollama: ~1 200 tokens/sekund med samma konkurrens
• Resultat: vLLM tillhandahåller 14x förbättring jämfört med grundläggande implementationer

Minneseffektivitet (LLaMA-2-13B):

• Standardimplementering: 24GB VRAM, 32 samtidiga sekvenser
• vLLM med PagedAttention: 24GB VRAM, 128 samtidiga sekvenser
• Resultat: 4x fler samtidiga förfrågningar med samma minne

Latens under last (Mixtral-8x7B på 2xA100):

• vLLM: P50 latens 180ms, P99 latens 420ms vid 100 req/s
• Standard servning: P50 latens 650ms, P99 latens 3 200ms vid 100 req/s
• Resultat: vLLM upprätthåller konsekvent latens under hög last

Dessa benchmarks visar varför vLLM blivit den de facto-standard för produktions LLM-servning där prestanda är viktig.

Kostnadsanalys

Förståelse av kostnadspåverkan när du väljer vLLM:

Scenari: Serva 1M förfrågningar/dag

Med standard servning:

• Krav: 8x A100 GPU:er (80GB)
• AWS-kostnad: ~$32/timme × 24 × 30 = $23 040/månad
• Kostnad per 1M tokens: ~$0,75

Med vLLM:

• Krav: 2x A100 GPU:er (80GB)
• AWS-kostnad: ~$8/timme × 24 × 30 = $5 760/månad
• Kostnad per 1M tokens: ~$0,19
• Sparing: $17 280/månad (75% minskning)

Denna kostnadsfördel växer med skala. Organisationer som servar miljarder tokens månatligt sparar hundratusentals dollar genom att använda vLLM:s optimerade servning istället för naiva implementationer.

Säkerhetsöverväganden

Autentisering

vLLM inkluderar inte autentisering som standard. För produktion, implementera autentisering på nivå av omvända proxy:

# Nginx-konfiguration
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Eller använd API-gatewayar som Kong, Traefik eller AWS API Gateway för företagsskalig autentisering och hastighetsbegränsning.

Nätverksisolering

Kör vLLM i privata nätverk, inte direkt exponerat mot internet:

# Kubernetes NetworkPolicy-exempel
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

Hastighetsbegränsning

Implementera hastighetsbegränsning för att förhindra missbruk:

# Exempel med Redis för hastighetsbegränsning
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # 60 sekunder fönster
    
    if requests > 60:  # 60 förfrågningar per minut
        raise HTTPException(status_code=429, detail="Hastighetsbegränsning överskred")
    
    return await call_next(request)

Modelltillgångskontroll

För multi-tenant deployment, kontrollera vilka användare som kan komma åt vilka modeller:

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Alla modeller
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

Migreringsguide

Från OpenAI till vLLM

Migration från OpenAI till egenhostad vLLM är enkel tack vare API-kompatibilitet:

Före (OpenAI):

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Hej"}]
)

Efter (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Om du lagt till autentisering
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hej"}]
)

Endast två ändringar behövs: uppdatera base_url och model-namn. All annan kod förblir identisk.

Från Ollama till vLLM

Ollama använder ett annat API-format. Här är konverteringen:

Ollama API:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': 'Varför är himlen blå?'
    })

vLLM-ekvivalent:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Varför är himlen blå?"
)

Du behöver uppdatera API-förfrågningar genom hela din kodbas, men OpenAI-klientbiblioteken ger bättre felhantering och funktioner.

Från HuggingFace Transformers till vLLM

Direkt Python-användningsmigration:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("Hello", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Hello", sampling_params)
result = outputs[0].outputs[0].text

vLLM:s Python-API är enklare och mycket snabbare för batchinferens.

Framtiden för vLLM

vLLM fortsätter snabb utveckling med spännande funktioner på väglistan:

Disaggregerad servning: Att separera prefyll (promptbearbetning) och dekod (tokengeneration) till olika GPU:er för att optimera resursanvändning. Prefyll är beräkningsbegränsat medan dekod är minnesbegränsat, så att köra dem på specialiserad hårdvara förbättrar effektiviteten.

Multi-nod inferens: Att distribuera mycket stora modeller (100B+ parametrar) över flera maskiner, vilket möjliggör servning av modeller som är för stora för enskilda nod-uppsättningar.

Förbättrad kvantisering: Stöd för nya kvantiseringsformat som GGUF (används av llama.cpp) och förbättrad AWQ/GPTQ-integration för bättre prestanda med kvantiserade modeller.

Förbättringar av spekulativ dekodning: Effektivare utkastmodeller och adaptiva spekulationstrategier för att uppnå högre hastighetsökningar utan noggrannhetsförlust.

Uppmärksamhetsoptimeringar: FlashAttention 3, ringattention för extremt långa kontexter (100K+ tokens) och andra banbrytande uppmärksamhetsmekanismer.

Bättre modellsäckning: Att utöka stödet för multimodala modeller (vision-språkmotorer), ljudmodeller och specialiserade arkitekturer när de dyker upp.

vLLM-projektet upprätthåller aktiv utveckling med bidrag från UC Berkeley, Anyscale och den bredare öppen källkod-gemenskapen. När LLM-deployment blir mer kritisk för produktionsystem fortsätter vLLM:s roll som prestandastandard att växa.

För en bredare jämförelse av vLLM med annan lokal och moln-LLM-infrastruktur, se vår LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

Användbara länkar

Relaterade artiklar på denna sida

• Local LLM Hosting: Complete 2026 Guide - Ollama, vLLM, LocalAI, Jan, LM Studio & More - Omfattande jämförelse av 12+ lokala LLM-hostningsverktyg inklusive detaljerad vLLM-analys alongside Ollama, LocalAI, Jan, LM Studio och andra. Täcker API-mognad, verktygssammanfattning, GGUF-kompatibilitet och prestandabenchmarks för att hjälpa dig välja rätt lösning.

• Ollama Cheatsheet - Komplett Ollama-kommandoreferens och cheatsheet som täcker installation, modellhantering, API-användning och bästa praxis för lokal LLM-deployment. Essentiellt för utvecklare som använder Ollama alongside eller istället för vLLM.

• llama.cpp Quickstart with CLI and Server - Lättvikts C/C++-inferens för GGUF-modeller med llama-cli och OpenAI-kompatibel llama-server. Idealisk när du behöver finjusterad kontroll, offline-deployment eller en minimal stack utan Python.

• Docker Model Runner vs Ollama: Which to Choose? - Djupgående jämförelse av Dockers Model Runner och Ollama för lokal LLM-deployment, analyserar prestanda, GPU-stöd, API-kompatibilitet och användningsfall. Hjälper förstå konkurrensmiljön som vLLM opererar i.

• Docker Model Runner Cheatsheet: Commands & Examples - Praktisk Docker Model Runner-cheatsheet med kommandon och exempel för AI-modelldeployment. Användbar för team som jämför Dockers approach med vLLM:s specialiserade LLM-servningskapaciteter.

Externa resurser och dokumentation

• vLLM GitHub Repository - Officiell vLLM-repository med källkod, omfattande dokumentation, installationsguider och aktiv gemenskapdiskussion. Essentiell resurs för att hålla sig uppdaterad med senaste funktioner och felsöka problem.

• vLLM Documentation - Officiell dokumentation som täcker alla aspekter av vLLM från grundläggande uppstart till avancerad konfiguration. Inkluderar API-referenser, prestandajusteringsguider och deploymentsbästa praxis.

• PagedAttention Paper - Akademisk papper som introducerar PagedAttention-algoritmen som driver vLLM:s effektivitet. Essentiell läsning för att förstå de tekniska innovationerna bakom vLLM:s prestandafördelar.

• vLLM Blog - Officiell vLLM-blogg som innehåller släppannonser, prestandabenchmarks, tekniska djupdykningar och gemenskapfallstudier från produktionsdeployment.

• HuggingFace Model Hub - Omfattande repository av öppen källkod-LLM som fungerar med vLLM. Sök efter modeller efter storlek, uppgift, licens och prestandakaraktäristik för att hitta rätt modell för ditt användningsfall.

• Ray Serve Documentation - Ray Serve-ramverksdokumentation för att bygga skalbara, distribuerade vLLM-deployment. Ray tillhandahåller avancerade funktioner som autoscaling, multi-modell-servning och resurshantering för produktionsystem.

• NVIDIA TensorRT-LLM - NVIDIA:s TensorRT-LLM för högoptimerad inferens på NVIDIA GPU:er. Alternativ till vLLM med olika optimeringsstrategier, användbar för jämförelse och förståelse av inferensoptimeringslandskapet.

• OpenAI API Reference - Officiell OpenAI API-dokumentation som vLLM:s API är kompatibelt med. Referera till detta när du bygger applikationer som behöver fungera med både OpenAI och egenhostade vLLM-endpunkter utbytbar.