vLLM Snabbstart: Högpresterande LLM-server - 2026

vLLM är en höggenomströmnings, minneseffektiv inferens- och serveringsmotor för stora språkmodeller (LLMs) 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 serveringsmetoder, vilket gör det till det bästa valet för produktionsdistribution av LLMs. För att se hur vLLM passar in bland Ollama, Docker Model Runner, LocalAI och molntillhandtagare – inklusive kostnader och infrastrukturtradeff – se LLM Hosting: Lokalt, självvärd och molninfrastruktur jämförd.

Vad är vLLM?

vLLM (virtuell LLM) är en öppen källkodslösning för snabb LLM-inferens och servering som snabbt har blivit industrinormen för produktionsdistributioner. Utgivet år 2023 introducerade det PagedAttention, en revolutionerande minneshanteringsmetod som drastiskt förbättrar servereffektivitet.

Viktiga funktioner

Hög genomströmning: 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 batchbearbetning, optimerade CUDA-kärnor och PagedAttention-algoritmen som eliminerar minnesfragmentering.

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

PagedAttention-algoritm: Den centrala innovationen bakom vLLM:s prestanda är PagedAttention, som tillämpar konceptet 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 minnesbruk upp till 4 gånger och möjliggör mycket större batchstorlekar.

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

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 passar i en enskild GPU:s minne, med konfigurationer från 2 till 8+ GPU:er.

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

När att använda vLLM

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

Produktions-API-tjänster: När du behöver servera en LLM till många samtidiga användare via API, gör vLLMs höga genomströmning och effektiva batchbearbetning det bästa valet. Företag som kör chattrobotar, kodassistent eller innehållsgenereringstjänster får nytta av dess förmåga att hantera hundratals begäran per sekund.

Högkonkurrensarbete: Om din applikation har många samtidiga användare som gör begäran, gör vLLMs kontinuerliga batchbearbetning och PagedAttention att servera fler användare med samma hårdvara jämfört med alternativ.

Kostnadsminimering: När GPU-kostnader är en oro, ger vLLMs utmärkta 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: vLLMs statiska design och containervänliga arkitektur gör det idealiskt för Kubernetes-kluster. Den konsekventa prestandan under belastning och enkel resurshantering integrerar bra med molnnyttiga infrastrukturer.

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

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 installationen
python -c "import vllm; print(vllm.__version__)"

För system med olika CUDA-versioner, installera lämplig 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 tillförlitliga distributionsmetoden, särskilt för produktionsmiljöer:

# 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ällkod

För de senaste funktionerna eller anpassade ändringar, 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:

# 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 att ladda ner modellen från HuggingFace Hub (om den inte är cachelagrad) och starta servern. Du kommer att se utskrift 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ör API-begäran

När servern är igång kan du göra begäran 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 Completion 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 sparar minne för större batchar.
• --tensor-parallel-size: Antal GPU:er som modellen ska delas över.
• --dtype: Datatyp för vikter (float16, bfloat16 eller float32). FP16 är vanligtvis optimalt.
• --max-num-seqs: Maximalt antal sekvenser som ska bearbetas i en batch.

Jämförelse mellan vLLM och Ollama

Både vLLM och Ollama är populära val för lokal LLM-värd, men de riktar sig till olika användningsscenarier. Att förstå när att använda varje verktyg kan betydligt påverka din projekts framgång.

Prestanda och genomströmning

vLLM är utformad för maximal genomströmning i flera användarscenarier. Dess PagedAttention och kontinuerlig batchbearbetning möjliggör att servera hundratals samtidiga begäran 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 vid hög koncurrents.

Ollama optimerar för enskild användare interaktivt användning med fokus på låg latens för enskilda begäran. Även om det inte matchar vLLMs flera användare genomströmning, ger det utmärkt prestanda för utveckling och personlig användning med snabbare kalla starttider och lägre inaktiv resurshantering.

Enkelhet att använda

Ollama vinner tydligt i enkelhet. Installationen är en enda kommando (curl | sh), och att köra modeller är lika enkelt 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 modellspecifikation. Lärkurvan är brantare, men du får finkontrollerad kontroll över prestandaoptimering. Denna komplexitet är motiverad för produktionsdistributioner där du behöver pressa maximal prestanda ur din hårdvara.

API och integration

vLLM tillhandahåller OpenAI-kompatibla REST-APIS direkt, vilket gör det till ett 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 molntillhandtagare till självvärd infrastruktur utan kodändringar.

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

Minneshantering

vLLMs PagedAttention-algoritm ger överlägsen minneseffektivitet för samtidiga begäran. 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ändarscenarier. Den hanterar automatiskt modellens laddning/avladdning baserat på aktivitet, vilket är bekvämt för utveckling men inte optimalt för högkonkurrens 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 passar i en enskild GPU.

Ollama har begränsat stöd för flera GPU:er, och 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 begäran i molndistributioner
• Du kör i Kubernetes eller containerorchestration-plattformar
• 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 en enskild användare interaktivt (personliga assistenter, chattrobotar)
• Du gör snabb prototypning och modellbedömning
• Du lär dig om LLM:er utan infrastrukturkomplexitet
• Du kör på personliga datorer 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.

vLLM vs 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 strävar efter 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 som fokuserar endast på LLM-servering med maximal prestanda. Det är ett lägre nivåverktyg som du behåller med Docker, snarare än en komplett plattform.

Installation och komma 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 Docks bildarbete gör det omedelbart bekant för utvecklare som redan använder behållare.

vLLM kräver mer initial konfiguration (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-name>

Prestandakaraktäristik

vLLM levererar överlägsen genomströmning för flera användarscenarier tack vare PagedAttention och kontinuerlig batchbearbetning. För produktions-API-tjänster som hanterar hundratals begäran per sekund, ger vLLMs optimeringar 2-5 gånger bättre genomströmning än generiska serveringsmetoder.

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 curaterad modellbibliotek 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 i LLM-inferens med djup stöd för transformerbaserade språkmodeller. Den stöder alla HuggingFace-kompatibla LLM:er men inte till andra AI-modelltyper som bildgenerering eller talsyntes.

Produktionsdistribution

vLLM är testad i produktion vid företag som Anthropic, Replicate och många andra som serverar miljarder token dagligen. Dens prestandakaraktäristik och stabilitet vid hög 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 lokala testscenarier. Även om det kan servera produktions trafik, saknar det den beprövade historiken och prestandaoptimeringar som produktionsdistributioner kräver.

Integrationsekosystem

vLLM integrerar med produktionsinfrastrukturverktyg: Kubernetes-operatörer, 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-serveringsfunktioner.

När att använda varje

Använd vLLM för:

• Produktions LLM API-tjänster
• Höggenomströmning, flera användar distributioner
• Kostnadssänkta molndistributioner som behöver maximal effektivitet
• Kubernetes och molnnyttiga miljöer
• När du behöver beprövad skalbarhet 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 investerats i Docker-ekosystemet
• Snabb experimentering utan infrastrukturinställning
• 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, kombinera båda tillvägagångssätt.

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 produktionsnivå:

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 observabilitet

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 begäran
• vllm:gpu_cache_usage_perc - KV-cacheanvändning
• vllm:time_to_first_token - Latensmått
• vllm:time_per_output_token - Genereringshastighet

Prestandaoptimering

Optimera GPU-minnesanvändning: Starta med --gpu-memory-utilization 0.90 och justera beroende 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ändningsscenariot 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, ställ in --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 kvantisering (8-bit, 4-bit) för att minska minne och öka genomströmning:

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

Aktivera prefixcachning: För tillämpningar med upprepade promptar (som chattrobotar med systemmeddelanden), aktivera prefixcachning:

--enable-prefix-caching

Detta cachelagrar KV-värdena för vanliga prefix, vilket minskar beräkningen för begäran som delar samma promptprefix.

Felsökning av vanliga problem

Minnesbristfel

Symtom: Servern kraschar med CUDA-minnesbristfel.

Lösningar:

• Minska --gpu-memory-utilization till 0.85 eller 0.80
• Minska --max-model-len om din användningsscenariot tillåter det
• Lägg ner --max-num-seqs för att minska batchstorleken
• Använd en kvantisering av modellen
• Aktivera tensorparallellitet för att distribuera över fler GPU:er

Låg genomströmning

Symtom: Servern hanterar färre begäran ä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 marginal
• Kontrollera om CPU är halsvänd 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 generering börjar.

Lösningar:

• Använd mindre modeller för latenskritiska tillämpningar
• 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 tensorparallellitetskonfiguration

Modelllastningsfel

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 hårddiskutrymme i ~/.cache/huggingface
• För skyddade modeller, ställ in HF_TOKEN miljövariabeln
• 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ålmodell 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å en grundmodell 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 du vill använda per begäran:

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

vLLMs multi-LoRA-servering möjliggör att värd flera finetunerade adapter med minimal minnesöverbelastning. Detta är idealiskt för att servera kundspecifika eller uppgiftsspecifika modellvarianter:

# Begäran 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 omberäkning av KV-cache för upprepade promptprefix:

--enable-prefix-caching

Detta är särskilt effektivt för:

• Chattrobotar med fasta systempromptar
• RAG-applikationer med konsistenta kontextmallar
• Few-shot learning promptar som upprepas över begäran

Prefixcachning kan minska tiden till första token med 50-80% för begäran 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}

Prestandabenchmarker

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

Genomströmning jämförelse (Mistral-7B på A100 GPU):

• vLLM: ~3 500 token/sekund med 64 samtidiga användare
• HuggingFace Transformers: ~250 token/sekund med samma koncurrents
• Ollama: ~1 200 token/sekund med samma koncurrents
• Resultat: vLLM ger 14 gånger förbättring över 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 begäran 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 benchmarker visar varför vLLM har blivit den etablerade standarden för produktionsservering av LLM:er där prestanda spelar en roll.

Kostnadsanalys

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

Scenario: Servera 1M begäran/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 hundratusentals dollar genom att använda vLLMs 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 hastighetsbegränsning.

Nätverksisolation

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

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 begäran per minut
        raise HTTPException(status_code=429, detail="Hastighetsbegränsning överskriden")
    
    return await call_next(request)

Modellåtkomstkontroll

För flera hyresgästersdistributioner, 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

Att migrera från OpenAI till självvärd vLLM är enkelt 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 lade 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 kommer behöva uppdatera API-begäran genom hela din kodbas, men OpenAI-klientbiblioteken tillhandahåller 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

vLLMs 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:

Disaggregated Serving: Separera prefill (promptbearbetning) och decode (tokengenerering) på 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-Node Inference: Distribuera mycket stora modeller (100B+ parametrar) över flera maskiner, vilket möjliggör servering av modeller som för stor för enskilda maskinuppsättningar.

Enhanced Quantization: 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 kvantisering.

Speculative Decoding Improvements: Mer effektiva draftmodeller och adaptiva spekulationsstrategier för att uppnå högre hastighetsförbättringar utan att förlora noggrannhet.

Attention Optimizations: FlashAttention 3, ring attention för extremt långa kontexter (100K+ token) och andra cuttingedge attentionmekanismer.

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

vLLM-projektet håller på med aktiv utveckling med bidrag från UC Berkeley, Anyscale och den bredare öppna källkodscommunityn. Medan LLM-distribution blir allt mer kritisk till produktionsystem, fortsätter vLLMs roll som prestandastandard att växa. För en bredare jämförelse av vLLM med andra lokala och moln LLM-infrastrukturer, se vår LLM Hosting: Lokalt, självvärd och molninfrastruktur jämförd.

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 – Utdragsvis 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 prestandabenchmarkar för att kunna välja rätt lösning.

• Ollama Cheat Sheet – 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: Vilken 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 Cheat Sheet: Kommandon & Exempel – Praktisk Docker Model Runner cheat sheet med kommandon och exempel för AI-modelldistribution. Något som är användbart för team som jämför Dockers metod med vLLMs specialiserade LLM-serverförmåga.

Externa resurser och dokumentation

• vLLM GitHub-repo – Officiell vLLM-repo med källkod, omfattande dokumentation, installationsguide 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, prestandaoptimeringsguider 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överlägsenhet.

• vLLM Blogg – Officiell vLLM blogg med utgivningsannonser, prestandabenchmarkar, tekniska djupdykningar och gemenskapsfallstudier från produktionsdistributioner.

• HuggingFace Modellhub – Omfattande databas av öppen källkod LLM som fungerar med vLLM. Sök efter modeller efter storlek, uppgift, licens och prestandakarakteristika 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 erbjuder 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 andra 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.