vLLM Quickstart: Högpresterande LLM-server – 2026

vLLM är en höggenomströmningsbar, minneseffektiv inferens- och servermotor för stora språkmodeller (LLM) utvecklad av UC Berkeley’s Sky Computing Lab.

Med sin revoluerande PagedAttention-algoritm uppnår vLLM 14-24 gånger högre genomströmning än traditionella servermetoder, vilket gör det till det förutsägbara valet för produktionsdistribution av LLM.

Vad är vLLM?

vLLM (virtuell LLM) är en öppen källkodsbibliotek för snabb LLM-inferens och server som snabbt har blivit industristandarden för produktionsdistribution. Utgivet 2023 introducerade det PagedAttention, en revolutionerande minneshanteringsmetod som dramatiskt förbättrar servereffektiviteten.

Viktiga funktioner

Hög genomströmningseffektivitet: vLLM levererar 14-24 gånger högre genomströmning jämfört med HuggingFace Transformers med samma hårdvara. Den stora prestandavinsten kommer från kontinuerlig batchning, optimerade CUDA-kärnor och PagedAttention-algoritmen som eliminerar minnesfragmentering.

OpenAI API-kompatibilitet: vLLM innehåller en inbyggd API-server som är helt kompatibel med OpenAI:s format. Detta möjliggör en sömlös migration från OpenAI till självvärd infrastruktur utan att behöva ändra applikationskod. Enkelt peka din API-klient till vLLM:s endpoint och det fungerar transparent.

PagedAttention-algoritm: Den centrala innovationen bakom vLLM:s prestanda är PagedAttention, som tillämpar konceptet av virtuell minnespaging på uppmärksamhetsmekanismer. Istället för att tilldela kontinuerliga minnesblock för KV-cache (vilket leder till fragmentering), delar PagedAttention minnet i fasta storleksblock som kan tilldelas efter behov. Detta minskar minnesförluster upp till 4 gånger och möjliggör mycket större batchstorlekar.

Kontinuerlig batchning: Skiljer sig från statisk batchning där du väntar på att alla sekvenser ska slutföras, använder vLLM kontinuerlig (rollande) batchning. När en sekvens är klar kan en ny läggas till batchen. Detta maximiserar GPU-användning och minskar latens för inkommande förfrågningar.

Stöd för flera GPU:er: vLLM stöder tensorparallellitet och pipelineparallellitet för att distribuera stora modeller över flera GPU:er. Den kan effektivt servera modeller som inte får plats i en enskild GPU:s minne, stödjer konfigurationer från 2 till 8+ GPU:er.

Brett modellstöd: Kompatibel med populära modellarkitekturer inklusive LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma och många andra. Stöder både instruktionstunade och basmodeller från HuggingFace Hub.

När att använda vLLM

vLLM är utmärkt i specifika scenarier där dess styrkor skenar:

Produktions-API-tjänster: När du behöver servera en LLM till många samtidiga användare via API, gör vLLM:s höga genomströmning och effektiva batchningar det bästa valet. Företag som kör chatbotar, kodassistenters eller innehållsgenererande tjänster fördelar sig av dess förmåga att hantera hundratals förfrågningar per sekund.

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

Kostnadsminimering: När GPU-kostnader är en oro, ger vLLM:s överlägsna genomströmning möjlighet att servera samma trafik med färre GPU:er, vilket direkt minskar infrastrukturkostnader. Den 4 gånger större minneseffektiviteten från PagedAttention gör det också möjligt att använda mindre, billigare GPU-instanser.

Kubernetes-distributioner: vLLM:s statlösa design och containervänliga arkitektur gör det idealiskt för Kubernetes-kluster. Den konsekventa prestandan under belastning och enkel resurshantering integrerar väl med molnstandardiserad infrastruktur.

När inte att använda vLLM: För lokal utveckling, experiment eller enskilda användarfall, ger verktyg som Ollama bättre användarupplevelse med enklare installation. vLLM:s komplexitet motiveras när du behöver dess prestandaavancer för produktionsarbetsbelastningar.

Hur att installera vLLM

Förutsättningar

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

• GPU: NVIDIA GPU med beräkningskapacitet 7.0+ (V100, T4, A10, A100, H100, RTX 20/30/40 serie)
• CUDA: Version 11.8 eller högre
• Python: 3.8 till 3.11
• VRAM: Minst 16 GB för 7B-modeller, 24 GB+ för 13B, 40 GB+ 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:

# 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 distributionsmetoden, särskilt för produktionsanvändning:

# Hämta den officiella vLLM-bilden
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 flera GPU-konfigurationer eftersom den möjliggör korrekt interprocesskommunikation.

Bygg från källkoden

För de senaste funktionerna eller anpassningar, bygg från källkoden:

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

Snabbstartsguide för vLLM

Kör din första modell

Starta vLLM med en modell med kommandoradsgränssnittet:

# Ladda ner och servera Mistral-7B med OpenAI-kompatibel API
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM kommer automatiskt ladda ner modellen från HuggingFace Hub (om den inte är cachelagrad) och starta servern. Du kommer se utskrift som visar 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ör 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-klient:

from openai import OpenAI

# Peka 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 tensorparallellitet
    --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 tillåter större batchar men lämnar mindre marginal för minnesstigning.
• --max-model-len: Maximal kontextlängd. Att minska detta sparer 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 vanligtvis optimal.
• --max-num-seqs: Maximalt antal sekvenser att bearbeta i en batch.

Jämförelse mellan vLLM och Ollama

Såväl vLLM som Ollama är populära alternativ för lokal LLM-värd, men de riktar sig till olika användningsscenarier. Förstå när att använda varje verktyg kan betydligt påverka din projektens framgång.

Prestanda och genomströmning

vLLM är utformad för maximal genomströmning i flera användarscenarier. Dess PagedAttention och kontinuerlig batchning möjliggör att servera hundratals samtidiga förfrågningar effektivt. Benchmarks visar att vLLM uppnår 14-24 gånger högre genomströmning än standardimplementeringar och 2-4 gånger högre än Ollama under hög koncurrent.

Ollama optimerar för enskild användare interaktivt användning med fokus på låg latens för enskilda förfrågningar. Även om det inte matchar vLLM:s flera användar genomströmning, ger det utmärkt prestanda för utveckling och personlig användning med snabbare kallstartstider och lägre ideliga resurshantering.

Enkelhet att använda

Ollama vinner tydligt på enkelhet. Installationen är en enda kommando (curl | sh), och körning av modeller är lika enkel som ollama run llama2. Den innehåller en modellbibliotek med kvantiserade versioner optimerade för olika hårdvaruprofiler. Användarupplevelsen liknar Docker – ladda ner, kör och gå.

vLLM kräver mer konfiguration: Python-miljöhantering, CUDA-installation, förståelse för serverparametrar och manuell modellspecificering. Lärkurvan är stigande, men du får finkontrollerad kontroll över prestandaoptimering. Den här komplexiteten är motiverad för produktionsdistributioner 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 som standard, vilket gör det till en drop-in ersättning för OpenAI:s API i befintliga applikationer. Detta är avgörande för att migrera produktions tjänster från molnleverantörer till självvärd infrastruktur utan kodändringar.

Ollama tillhandahåller en enklare REST-API och en dedikerad Python/JavaScript-bibliotek. Även om det fungerar, är det inte OpenAI-kompatibelt, vilket kräver kodändringar vid integration med applikationer som förväntar sig OpenAI:s format. Dock finns communityprojekt som Ollama-OpenAI-adapter som fyller detta gap.

Minneshantering

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

Ollama använder enklare minneshantering som är lämplig för enskilda användarfall. Den hanterar modellens laddning/avläsning automatiskt beroende på aktivitet, vilket är bekvämt för utveckling men inte optimalt för högkoncurrent produktionsanvändning.

Stöd för flera GPU:er

vLLM utmärker sig med inbyggd tensorparallellitet och pipelineparallellitet, som effektivt distribuerar modeller över 2-8+ GPU:er. Detta är avgörande för att servera stora modeller som 70B parameter LLM:er som inte får plats i en enskild GPU.

Ollama har begränsat stöd för flera GPU:er, främst fungerar bäst med en enda GPU. Detta gör det mindre lämpligt för mycket stora modeller som kräver distribuerad inferens.

Rekommendationer för användning

Välj vLLM när:

• Du serverar produktions-API:er med många samtidiga användare
• Du optimerar kostnad per förfrågan i moln distributioner
• Du kör i Kubernetes eller containerorchestratorplattformar
• Du behöver OpenAI API-kompatibilitet för befintliga applikationer
• Du serverar stora modeller som kräver flera GPU-stöd
• Prestanda och genomströmning är kritiska krav

Välj Ollama när:

• Du gör lokal utveckling och experiment
• Du använder enskilda användare interaktivt (personliga assistenter, chatbotar)
• Du gör snabb prototyper och modellbedömning
• Du lär dig om LLM:er utan infrastrukturkomplexitet
• Du kör på personliga arbetsstationer eller laptopar
• Enkelhet och enkelhet är prioriteringar

Många team använder båda: Ollama för utveckling och experiment, sedan vLLM för produktionsdistribution. Detta kombination ger utvecklare produktivitet samtidigt som produktionsprestanda behålls.

Jämförelse mellan vLLM och Docker Model Runner

Docker har nyligen introducerat Model Runner (tidigare GenAI Stack) som deras officiella lösning för lokal AI-modelldistribution. Hur jämförs det med vLLM?

Arkitekturfilosofi

Docker Model Runner syftar till att vara “Docker för AI” – en enkel, standardiserad sätt att köra AI-modeller lokalt med samma enkelhet som att köra behållare. Den abstraherar bort komplexitet och ger en konsekvent gränssnitt över olika modeller och ramverk.

vLLM är en specialiserad inferensmotor fokuserad endast på LLM-servering med maximal prestanda. Det är ett lägre nivåverktyg som du behåller i Docker, snarare än ett komplett plattform.

Setup och start

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

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

Den här likheten med Docks imagearbetsflöde gör det omedelbart bekant för utvecklare som redan använder behållare.

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

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

Prestandakarakteristika

vLLM levererar överlägsen genomströmning för flera användarfall tack vare PagedAttention och kontinuerlig batchning. För produktions-API-tjänster som hanterar hundratals förfrågningar per sekund, ger vLLM:s optimeringar 2-5 gånger bättre genomströmning än generiska servermetoder.

Docker Model Runner fokuserar på enkelhet snarare än maximal prestanda. Det är lämpligt för lokal utveckling, testning och måttliga arbetsbelastningar, men implementerar inte de avancerade optimeringarna som gör att vLLM utmärker sig vid skala.

Modellstöd

Docker Model Runner tillhandahåller en urvalmodellbibliotek med enkommandotillgång till populära modeller. Den stöder flera ramverk (inte bara LLM:er) inklusive Stable Diffusion, Whisper och andra AI-modeller, vilket gör den mer mångsidig för olika AI-arbetsbelastningar.

vLLM specialiserar sig på LLM-inferens med djup stöd för transformerbaserade språkmodeller. Den stöder alla HuggingFace-kompatibla LLM:er men inte utökar till andra AI-modelltyper som bildgenerering eller talsyntes.

Produktionsdistribution

vLLM har testats i produktion vid företag som Anthropic, Replicate och många andra som serverar miljarder token dagligen. Dess prestandakarakteristika och stabilitet vid tung belastning gör det till den etablerade standarden för produktionsdistribution av LLM:er.

Docker Model Runner är nyare och positionerar sig mer för utveckling och lokalt testscenario. Även om det kan servera produktionstrafik, saknar det den beprövade historiken och prestandaoptimeringarna som produktionsdistributioner kräver.

Integrationsekosystem

vLLM integrerar med produktionsinfrastrukturverktyg: Kubernetes operatorer, Prometheus-mått, Ray för distribuerad servering och omfattande OpenAI API-kompatibilitet för befintliga applikationer.

Docker Model Runner integrerar naturligt med Docks ekosystem och Docker Desktop. För team som redan standardiserats på Docker, ger denna integration en sammanhängande upplevelse men färre specialiserade LLM-serverfunktioner.

När att använda varje

Använd vLLM för:

• Produktions-API-tjänster för LLM
• Höggenomströmningsbara, flera användar distributioner
• Kostnadssänkta moln distributioner som behöver maximal effektivitet
• Kubernetes och molnstandardiserade miljöer
• När du behöver beprövad skalan och prestanda

Använd Docker Model Runner för:

• Lokal utveckling och testning
• Kör olika AI-modelltyper (inte bara LLM:er)
• Team som starkt investerat i Docker-ekosystemet
• Snabb experimentering utan infrastrukturkonfiguration
• Lärande och pedagogiska syften

Hybridansats: Många team utvecklar med Docker Model Runner lokalt för bekvämlighet, sedan distribuerar med vLLM i produktion för prestanda. Docker Model Runner-bilder kan också användas för att köra vLLM-behållare, kombinerar båda tillvägagångssätten.

Bästa praxis för produktionsdistribution

Docker-distribution

Skapa en produktionsklar 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-distribution

Distribuera vLLM på Kubernetes för produktionsstora:

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

Övervakning och insikter

vLLM exponerar Prometheus-mått för övervakning:

import requests

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

Viktiga mått att övervaka:

• vllm:num_requests_running - Aktiva förfrågningar
• vllm:gpu_cache_usage_perc - KV-cacheanvändning
• vllm:time_to_first_token - Latensmått
• vllm:time_per_output_token - Genereringshastighet

Prestandatuning

Optimera GPU-minnesanvändning: Starta med --gpu-memory-utilization 0.90 och justera baserat på observerad beteende. Högre värden tillåter större batchar men riskerar OOM-fel under trafikspikar.

Justera maximal sekvenslängd: Om din användningsscenarie inte kräver full kontextlängd, minska --max-model-len. Detta frigör minne för större batchar. Till exempel, om du bara behöver 4K kontext, sätt --max-model-len 4096 istället för att använda modellens maximala (ofta 8K-32K).

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

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

Aktivera prefixcachning: För applikationer med upprepade promptar (som chatbotar med systemmeddelanden), aktivera prefixcachning:

--enable-prefix-caching

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

Felsökning vanliga problem

Minnesfel

Symtom: Servern kraschar med CUDA minnesfel.

Lösningar:

• Minska --gpu-memory-utilization till 0.85 eller 0.80
• Minska --max-model-len om din användningsscenarie tillåter det
• Lägg ned --max-num-seqs för att minska batchstorlek
• Använd en kvantiseringad modellversion
• Aktivera tensorparallellitet för att distribuera över fler GPU:er

Låg genomströmning

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
• Höj --gpu-memory-utilization om du har utrymme
• Kontrollera om CPU är begränsad 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 tokenstid

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

Lösningar:

• Använd mindre modeller för latenskritiska applikationer
• Aktivera prefixcachning för upprepade promptar
• Minska --max-num-seqs för att prioritera latens över genomströmning
• Överväg spekulative dekodning för stödda modeller
• Optimera tensorparallellitet konfiguration

Modellbelastningsfel

Symtom: Servern kan inte starta, kan inte ladda modellen.

Lösningar:

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

Avancerade funktioner

Spekulativ dekodning

vLLM stöder spekulativ dekodning, där en mindre draftmodell föreslår token som en större målmall verifierar. Detta kan accelerera genereringen med 1,5-2 gånger:

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

Servera flera LoRA-adapter på toppen av en basmodell utan att ladda flera fulla 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 specifiera vilken adapter att använda per förfrågan:

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

Multi-LoRA-servering

vLLM:s multi-LoRA-servering möjliggör att värd flera finjusterade adapter med minimal minnesöverbelastning. Detta är idealiskt för att servera 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"}
)

Prefixcachning

Aktivera automatisk prefixcachning för att undvika återberäkning av KV-cache för upprepade promptprefix:

--enable-prefix-caching

Detta är särskilt effektivt för:

• Chatbotar med fasta systempromptar
• RAG-applikationer med konsekventa kontextmallar
• Fåshot learning promptar som upprepas över förfrågningar

Prefixcachning kan minska tid till första token med 50-80% för förfrågningar som delar promptprefix.

Integrationsexempel

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 enkelt")
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}

Prestandabenchmärkningar

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

Genomströmningsskillnad (Mistral-7B på A100 GPU):

• vLLM: ~3 500 token/sekund med 64 samtidiga användare
• HuggingFace Transformers: ~250 token/sekund med samma koncurrent
• Ollama: ~1 200 token/sekund med samma koncurrent
• Resultat: vLLM ger 14 gånger förbättring jämfört med grundläggande implementeringar

Minneseffektivitet (LLaMA-2-13B):

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

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

• vLLM: P50-latens 180 ms, P99-latens 420 ms vid 100 req/s
• Standardservering: P50-latens 650 ms, P99-latens 3 200 ms vid 100 req/s
• Resultat: vLLM behåller konsekvent latens under hög belastning

Dessa benchmärkningar visar varför vLLM har blivit den etablerade standarden för produktionsservering av LLM där prestanda är avgörande.

Kostnadsanalys

Förstå kostnadsaspekterna av att välja vLLM:

Scenario: Servera 1M förfrågningar/dag

Med standardservering:

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

Med vLLM:

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

Denna kostnadsfördel växer med skala. Organisationer som serverar miljarder token per månad sparar hundratals tusen dollar genom att använda vLLM:s optimerade servering istället för naiva implementeringar.

Säkerhetsaspekter

Autentisering

vLLM innehåller inte autentisering som standard. För produktionsanvändning, implementera autentisering på omvänd proxy-nivå:

# 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-gateways som Kong, Traefik eller AWS API Gateway för företagsnivå autentisering och ratelimiting.

Nätverksisolation

Kör vLLM i privata nätverk, inte direkt exponerat till 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

Ratelimiting

Implementera ratelimiting för att förhindra missbruk:

# Exempel med Redis för ratelimiting
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 sekunders fönster
    
    if requests > 60:  # 60 förfrågningar per minut
        raise HTTPException(status_code=429, detail="Rate limit exceeded")
    
    return await call_next(request)

Modellåtkomstkontroll

För flera hyresgästers distributioner, kontrollera vilka användare som får åtkomst till 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

Migrera från OpenAI till självvärd 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 läggt 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 måste uppdatera API-anropen genom hela din kodbas, men OpenAI-klientbiblioteken ger bättre felhantering och funktioner.

Från HuggingFace Transformers till vLLM

Direkt Python-användning migrering:

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("Hej", 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("Hej", 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ägen:

Delade servering: Att separera prefill (promptbearbetning) och decode (tokengenerering) till olika GPU:er för att optimera resurshantering. Prefill är beräkningsbegränsad medan decode är minnesbegränsad, så att köras 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 servering av modeller som är för stora för enskilda nodkonfigurationer.

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

Spekulativ dekodning förbättringar: Mer effektiva draftmodeller och anpassade spekulativa strategier för att uppnå högre hastighetsförbättringar utan att förlora noggrannhet.

Uppmärksamhetsoptimeringar: FlashAttention 3, ringuppmärksamhet för extremt långa kontexter (100K+ token) och andra avancerade uppmärksamhetsmekanismer.

Bättre modellomfattning: Utvidga stöd till multimodella modeller (bild-språkmodeller), ljudmodeller och specialiserade arkitekturer som de kommer.

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

Några användbara länkar

Relaterade artiklar på den här sidan

• Lokalt LLM-värd: Komplett 2026-guide – Ollama, vLLM, LocalAI, Jan, LM Studio & Mer – Omfattande jämförelse av 12+ lokala LLM-värdverktyg inklusive detaljerad analys av vLLM tillsammans med Ollama, LocalAI, Jan, LM Studio och andra. Omfattar API-mognad, stöd för verktygsanrop, GGUF-kompatibilitet och prestandabenchmark för att hjälpa till att välja rätt lösning.

• Ollama CheatSheet – Komplett Ollama kommandoreferens och cheat sheet som täcker installation, modellhantering, API-användning och bästa praxis för lokal LLM-distribution. Nödvändigt för utvecklare som använder Ollama tillsammans med eller istället för vLLM.

• Docker Model Runner vs Ollama: Vilket ska man välja? – In-depth jämförelse av Dockers Model Runner och Ollama för lokal LLM-distribution, analyserar prestanda, GPU-stöd, API-kompatibilitet och användningsfall. Hjälper till att förstå den konkurrenskraftiga landskaps som vLLM opererar i.

• Docker Model Runner CheatSheet: Kommandon & Exempel – Praktisk Docker Model Runner cheat sheet med kommandon och exempel för AI-modelldistribution. Användbart för team som jämför Dockers metod med vLLMs specialiserade LLM-serverfunktioner.

Externa resurser och dokumentation

• vLLM GitHub-repo – Officiell vLLM-repo med källkod, omfattande dokumentation, installationsguider och aktiva gemenskapsdiskussioner. Nödvändigt resurs för att hålla sig uppdaterad med de senaste funktionerna och felsöka problem.

• vLLM Dokumentation – Officiell dokumentation som täcker alla aspekter av vLLM från grundläggande konfiguration till avancerad inställning. Inkluderar API-referenser, prestandatuningsguider och distributionsbästa praxis.

• PagedAttention Paper – Akademiskt papper som introducerar PagedAttention-algoritmen som driver vLLMs effektivitet. Nödvändigt läsning för att förstå de tekniska innovationerna bakom vLLMs prestanda.

• vLLM Blog – Officiell vLLM-blogg med utgivningsannonser, prestandabenchmark, tekniska djupdyk och gemenskapsfallstudier från produktionsdistributioner.

• HuggingFace Model Hub – Omfattande databas av öppen källkod LLM som fungerar med vLLM. Sök efter modeller efter storlek, uppgift, licens och prestandaegenskaper för att hitta rätt modell för din användningssituation.

• Ray Serve Dokumentation – Ray Serve ramverk dokumentation för att bygga skalbara, distribuerade vLLM-distributioner. Ray tillhandahåller avancerade funktioner som autoskalning, flermodellservering och resurshantering för produktionsystem.

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

• OpenAI API Referens – Officiell OpenAI API-dokumentation som vLLM:s API är kompatibel med. Referera till detta när du bygger appar som behöver fungera med både OpenAI och självvärdade vLLM-slutpunkter.