vLLM Snabbstart: Högpresterande LLM-serverning

vLLM är en högpresterande, minneseffektiv inferens- och servermotor för stora språkmodeller (LLMs) utvecklad av Sky Computing Lab vid UC Berkeley.

Med sin revolutionerande 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:er.

Vad är vLLM?

vLLM (virtual LLM) är en öppen källkodslösning för snabb inferens och serverning av LLM:er som snabbt har blivit standarden inom branschen för produktionsdistribution. Utgivet år 2023 introducerade det PagedAttention, en brytande minneshanteringsmetod som drastiskt förbättrar servereffektiviteten.

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 eliminierar minnesfragmentering.

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

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 allokerar kontinuerliga minnesblock för KV-cache (vilket leder till fragmentering), delar PagedAttention minnet i fasta storleksblock som kan allokeras 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 slutförs kan en ny läggas till i batchen. Detta maximiserar GPU-användning och minskar latens för inkommande begäranden.

Stöd för flera GPU:er: vLLM stöder tensorparallellism och pipelineparallellism för att distribuera stora modeller över flera GPU:er. Det kan effektivt servera modeller som inte får plats i en enda 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 grundläggande modeller från HuggingFace Hub.

När ska du använda vLLM

vLLM har sina styrkor i vissa scenarier där det är optimalt:

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

Högkonkurrensarbete: Om din applikation har många samtidiga användare som gör begäranden, gör vLLM:s 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 bekymmer, 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 bättre 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 enkla resurshantering passar väl med molnstandardinfrastruktur.

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 inställning. vLLM:s komplexitet motiveras när du behöver dess prestandavantager för produktionsarbete.

Hur man installerar vLLM

Förutsättningar

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

• GPU: NVIDIA GPU med beräkningskraft 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 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 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ällkoden

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

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 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 att ladda ner modellen från HuggingFace Hub (om den inte är cachelagrad) 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ör API-begäranden

När servern körs kan du göra begäranden 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 tensorparallellism
    --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 på.
• --dtype: Datatyp för vikter (float16, bfloat16 eller float32). FP16 är vanligtvis optimal.
• --max-num-seqs: Maximalt antal sekvenser som ska bearbetas i en batch.

vLLM vs Ollama jämförelse

Såväl vLLM som Ollama är populära alternativ för lokal LLM-verktyg, men de riktar sig till olika användningsscenarier. Att 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ändarfall. Dess PagedAttention och kontinuerlig batchbearbetning möjliggör att servera hundratals samtidiga begäranden effektivt. Testresultat 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ögkonkurrens.

Ollama optimerar för enskilda användare med fokus på låg latens för enskilda begäranden. Även om den inte matchar vLLM:s flera användarprestanda, ger den utmärkt prestanda för utveckling och personlig användning med snabbare kalla starttider och lägre resurser vid inaktivitet.

Enkelhet att använda

Ollama vinner tydligt på 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 modellangivelse. 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 maximal prestanda ur din hårdvara.

API och integration

vLLM tillhandahåller OpenAI-kompatibla REST-APIS som standard, vilket gör det till en drop-in ersättning för OpenAI:s API i befintliga program. 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 är funktionellt, är det inte OpenAI-kompatibelt, vilket kräver kodändringar när det integreras med program som förväntar sig OpenAI:s format. Dock finns det gemenskapsprojekt som Ollama-OpenAI-adapter som fyller detta gap.

Minneshantering

vLLM:s PagedAttention-algoritm ger överlägsen minneseffektivitet för samtidiga begäranden. 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 automatiskt modellladdning/avläggning 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 tensorparallellism och pipelineparallellism, som effektivt distribuerar modeller över 2-8+ GPU:er. Detta är avgörande för att servera stora modeller som inte får plats i en enda GPU.

Ollama har begränsat stöd för flera GPU:er, 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 molninstallationer
• Du kör i Kubernetes eller containerorchestrering
• Du behöver OpenAI API-kompatibilitet för befintliga program
• Du serverar stora modeller som kräver flera GPU:er
• Prestanda och genomströmning är avgörande krav

Välj Ollama när:

• Du utvecklar lokalt och experimenterar
• Du har enskilda användare som interagerar (personliga assistenter, chattrobotar)
• Du gör snabba prototyper 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 upprätthå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 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 tillhandahåller 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 containerisera med Docker, snarare än en 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 Dockers 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örutfyllda Docker-bilder:

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

Prestandakarakteristika

vLLM levererar överlägsen genomströmning för flera användarfall på grund av PagedAttention och kontinuerlig batchbearbetning. För produktions-API-tjänster som hanterar hundratals begäranden 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. Den är lämplig för lokal utveckling, testning och moderata arbetsbelastningar, men implementerar inte de avancerade optimeringar som gör att vLLM utmärker sig vid skala.

Modellstöd

Docker Model Runner tillhandahåller en kuraterad 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 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 produktionsmiljöer vid företag som Anthropic, Replicate och många andra som serverar miljarder token per dag. Dess prestandakarakteristika och stabilitet under tung belastning gör det till det etablerade standarden för produktionsservering av LLM:er.

Docker Model Runner är nyare och positionerar sig mer för utveckling och lokala testscenarier. Även om det kan servera produktionstrafik, saknar det den etablerade spåren 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 program.

Docker Model Runner integrerar naturligt med Dockers 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ömning, flera användardistributioner
• Kostnadssensitiva molninstallationer som behöver maximal effektivitet
• Kubernetes och molnstandardmiljöer
• När du behöver etablerad 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 är starkt investerade 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 produktionsmiljöer för prestanda. Docker Model Runner-bilder kan också användas för att köra vLLM-behållare, kombinerar båda metoderna.

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 insikt

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äranden
• 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å observerat beteende. Högre värden tillåter större batchar men riskerar OOM-fel under trafikspikar.

Justera maximal sekvenslängd: Om din användning 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-kvaniserade modeller
--quantization gptq # För GPTQ-kvaniserade modeller

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

--enable-prefix-caching

Detta cachar KV-värdena för vanliga prefix, vilket minskar beräkning för begäranden 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ändning tillåter det
• Lägg ned --max-num-seqs för att minska batchstorleken
• Använd en kvantiseringad modellversion
• Aktivera tensorparallellism för att distribuera över fler GPU:er

Låg genomströmning

Symtom: Servern hanterar färre begäranden ä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 marginal
• Kontrollera om CPU är fläskbottnek 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 före genereringen börjar.

Lösningar:

• Använd mindre modeller för latenskritiska tillämpningar
• Aktivera prefixcachning för upprepade prompter
• Minska --max-num-seqs för att prioritera latens över genomströmning
• Överväg spekulativ dekodning för stödda modeller
• Optimera tensorparallellismkonfigurationen

Modellladdningsfel

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 skyddade 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å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 som ska användas 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

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:

# 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 systemprompter
• RAG-applikationer med konsistenta kontextmallar
• Fåshot learning-prompter som upprepas över begäranden

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

Prestandaundersökningar

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

Genomströmningsskillnader (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 begäranden 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 upprätthåller konsekvent latens under hög belastning

Dessa undersökningar visar varför vLLM har blivit den etablerade standarden för produktionsservering av LLM:er där prestanda spelar en roll.

Kostnadsanalys

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

Scenario: Servera 1 miljon begäranden/dag

Med standardservering:

• Krävs: 8x A100 GPU:er (80 GB)
• AWS-kostnad: ~$32/timme × 24 × 30 = $23 040/månad
• Kostnad per 1 miljon 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 1 miljon token: ~$0,19
• Sparingar: $17 280/månad (75% minskning)

Den här kostnadsfördelen växer med skalan. Organisationer som serverar miljarder token per månad sparar hundratusentals 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 produktionsmiljöer, 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 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

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 sekunders fönster
    
    if requests > 60:  # 60 begäranden per minut
        raise HTTPException(status_code=429, detail="Hastighetsbegränsning överskriden")
    
    return await call_next(request)

Modellåtkomstkontroll

För flera hyresgästerdistributioner, 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 har 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-namnet. 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-begäranden genom hela din kodbase, men OpenAI-klientbiblioteken ger bättre felhantering och funktioner.

Från HuggingFace Transformers till vLLM

Direkt Python-användning:

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:

Avkopplad servering: Separera förberedelse (promptbearbetning) och dekodning (tokengenerering) till olika GPU:er för att optimera resurshantering. Förberedelse är beräkningsbegränsad medan dekodning är minnesbegränsad, så att köra dem på specialiserad hårdvara förbättrar effektiviteten.

Multi-node inferens: Distribuera mycket stora modeller (100B+ parametrar) över flera maskiner, vilket möjliggör servering av modeller som är för stora för enskilda maskiner.

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

Förbättrad spekulativ dekodning: Mer effektiva draftmodeller och anpassade spekulationsstrategier 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 dyker upp.

vLLM-projektet upprätthåller aktiv utveckling med bidrag från UC Berkeley, Anyscale och den bredare öppna källkodskommuniteten. Medan LLM-distribution blir allt viktigare 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 2025-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 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: Vilket ska man välja? – In-depth jämförelse av Docker:s 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 marknaden 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 Docks 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 installation till avancerad konfiguration. Inkluderar API-referenser, prestandaoptimeringsguide 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 prestandefördelar.

• vLLM Blogg – Officiell vLLM-blogg med information om frisläppningar, prestandabenchmark, tekniska djupdyk och gemenskapsfallstudier från produktionsdistributioner.

• HuggingFace Modellhub – Omfattande arkiv 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 ditt användningsfall.

• Ray Serve Dokumentation – Ray Serve ramverk för att bygga skalerbara, distribuerade vLLM-distributioner. Ray tillhandahåller avancerade funktioner som autoskalning, flermodellserver 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ändbart för jämförelse och förståelse av inferensoptimeringslandskapet.

• OpenAI API Referens – Officiell OpenAI API-dokumentation som vLLMs 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.