Szybki start z vLLM: Wydajna obsługa LLM – w 2026 roku

vLLM to wysokiej wydajności, oszczędny pamięciowo silnik inferencji i serwowania modeli językowych (LLM) rozwijany przez Sky Computing Lab na Uniwersytecie Kalifornii w Berkeley.

Dzięki rewolucyjnemu algorytmowi PagedAttention, vLLM osiąga przepustowość wyższą o 14–24 razy w porównaniu z tradycyjnymi metodami serwowania, co czyni go wyborem numer jeden dla wdrożeń produkcyjnych LLM. Aby dowiedzieć się, jak vLLM plasuje się w porównaniu z Ollama, Docker Model Runner, LocalAI oraz dostawcami chmury – w tym z uwzględnieniem kosztów i kompromisów infrastrukturalnych – zobacz Serwowanie LLM: Lokalne, Self-Hosted i Infrastruktura Chmurowa w Porównaniu.

Czym jest vLLM?

vLLM (virtual LLM) to biblioteka open-source do szybkiej inferencji i serwowania LLM, która szybko stała się standardem branżowym dla wdrożeń produkcyjnych. Wydana w 2023 roku, wprowadziła PagedAttention, przełomową technikę zarządzania pamięcią, która radykalnie poprawia efektywność serwowania.

Kluczowe funkcje

Wysoka wydajność: vLLM oferuje przepustowość wyższą o 14–24 razy w porównaniu z HuggingFace Transformers przy użyciu tego samego sprzętu. Ta ogromna poprawa wynika z ciągłego batchingu (continuous batching), zoptymalizowanych jąder CUDA oraz algorytmu PagedAttention, który eliminuje fragmetację pamięci.

Kompatybilność z API OpenAI: vLLM zawiera wbudowany serwer API w pełni kompatybilny z formatem OpenAI. Pozwala to na płynną migrację z OpenAI do infrastruktury self-hosted bez zmiany kodu aplikacji. Wystarczy skierować klienta API na endpoint vLLM, a zadziała to transparentnie.

Algorytm PagedAttention: Kluczową innowacją stojącą za wydajnością vLLM jest PagedAttention, który stosuje koncepcję paginacji pamięci wirtualnej do mechanizmów uwzględniania (attention). Zamiast alokować ciągłe bloki pamięci dla cache’ów KV (co prowadzi do fragmentacji), PagedAttention dzieli pamięć na bloki o stałym rozmiarze, które mogą być alokowane na żądanie. Zmniejsza to marnowanie pamięci nawet o 4 razy i umożliwia znacznie większe rozmiary batchy.

Continuous Batching: W przeciwieństwie do statycznego batchingu, gdzie czeka się na zakończenie wszystkich sekwencji, vLLM używa ciągłego (scrolling) batchingu. W momencie, gdy jedna sekwencja się kończy, do batcha może zostać dodana nowa. Maksymalizuje to wykorzystanie GPU i minimalizuje opóźnienia dla nadchodzących żądań.

Wsparcie wielu GPU: vLLM obsługuje równoległość tensorową (tensor parallelism) i pipeline’ową (pipeline parallelism) do dystrybucji dużych modeli na wielu GPU. Może efektywnie serwować modele, które nie mieszczą się w pamięci pojedynczego GPU, obsługując konfiguracje od 2 do 8+ GPU.

Szerokie wsparcie modeli: Kompatybilny z popularnymi architekturami modeli, w tym LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma i wieloma innymi. Obsługuje zarówno modele dostrojone instrukcyjnie, jak i bazowe modele z HuggingFace Hub.

Kiedy używać vLLM

vLLM świetnie sprawdza się w konkretnych scenariuszach, w których jego mocne strony świecą najjaśniej:

Usługi API produkcyjne: Gdy potrzebujesz serwować LLM wielu użytkownikom jednoczesnym poprzez API, wysoka przepustowość i efektywne batching w vLLM czynią go najlepszym wyborem. Firmy uruchamiające czatboty, asystentów kodu lub usługi generowania treści zyskują dzięki jego zdolności do obsługi setek żądań na sekundę.

Obciążenia o wysokiej konkurencyjności: Jeśli Twoja aplikacja ma wielu jednoczesnych użytkowników wysyłających żądania, continuous batching i PagedAttention w vLLM pozwalają na obsłużenie większej liczby użytkowników na tym samym sprzęcie w porównaniu z alternatywami.

Optymalizacja kosztów: Gdy koszty GPU są istotne, wyższa przepustowość vLLM oznacza, że można obsłużyć ten sam ruch mniejszą liczbą GPU, bezpośrednio obniżając koszty infrastruktury. 4-krotna efektywność pamięci z PagedAttention pozwala również na używanie mniejszych, tańszych instancji GPU.

Wdrożenia na Kubernetes: Bezstanowe (stateless) projektowanie vLLM i architekturę przyjazną kontenerom czyni go idealnym dla klastrów Kubernetes. Jego spójna wydajność pod obciążeniem i proste zarządzanie zasobami dobrze integrują się z infrastrukturą chmur natywnych.

Kiedy NIE używać vLLM: Do lokalnego rozwoju, eksperymentów lub scenariuszy pojedynczego użytkownika, narzędzia takie jak Ollama lub llama.cpp zapewniają lepsze doświadczenie użytkownika dzięki prostszemu setupie. Złożoność vLLM jest uzasadniona, gdy potrzebujesz jego korzyści wydajnościowych dla obciążeń produkcyjnych.

Jak zainstalować vLLM

Wymagania wstępne

Przed instalacją vLLM upewnij się, że Twój system spełnia te wymagania:

• GPU: Karta NVIDIA z możliwością obliczeniową 7.0+ (V100, T4, A10, A100, H100, seria RTX 20/30/40)
• CUDA: Wersja 11.8 lub nowsza
• Python: 3.8 do 3.11
• VRAM: Minimum 16GB dla modeli 7B, 24GB+ dla 13B, 40GB+ dla większych modeli
• Sterownik: Sterownik NVIDIA 450.80.02 lub nowszy

Instalacja przez pip

Najprostsza metoda instalacji to użycie pip. Działa to na systemach z CUDA 11.8 lub nowszym:

# Utwórz wirtualne środowisko (zalecane)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Zainstaluj vLLM
pip install vllm

# Zweryfikuj instalację
python -c "import vllm; print(vllm.__version__)"

Dla systemów z innymi wersjami CUDA, zainstaluj odpowiedni wheel:

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

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

Instalacja z Dockerem

Docker zapewnia najpewniejszą metodę wdrożenia, szczególnie w produkcji:

# Pobierz oficjalny obraz vLLM
docker pull vllm/vllm-openai:latest

# Uruchom vLLM z obsługą GPU
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

Flaga --ipc=host jest ważna dla konfiguracji wielu GPU, ponieważ umożliwia odpowiednią komunikację między procesami.

Budowanie ze źródła

Dla najnowszych funkcji lub modyfikacji custom, zbuduj ze źródła:

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

Szybki start z vLLM

Uruchamianie pierwszego modelu

Uruchom vLLM z modelem, używając interfejsu wiersza poleceń:

# Pobierz i serwuj Mistral-7B z kompatybilnym z OpenAI API
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM automatycznie pobierze model z HuggingFace Hub (jeśli nie jest w cache) i uruchomi serwer. Zobaczą się komunikaty wskazujące, że serwer jest gotowy:

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

Wykonywanie żądań API

Gdy serwer działa, możesz wysyłać żądania, używając klienta Python OpenAI lub curl:

Użycie curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Explain what vLLM is in one sentence:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Użycie Klienta Python OpenAI:

from openai import OpenAI

# Wskaż do swojego serwera vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM domyślnie nie wymaga autoryzacji
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Explain what vLLM is in one sentence:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API Chat Completions:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is PagedAttention?"}
    ],
    max_tokens=200
)

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

Zaawansowana konfiguracja

vLLM oferuje liczne parametry do optymalizacji wydajności:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Użyj 95% pamięci GPU
    --max-model-len 8192 \            # Maksymalna długość sekwencji
    --tensor-parallel-size 2 \        # Użyj 2 GPU z równoległością tensorową
    --dtype float16 \                 # Użyj precyzji FP16
    --max-num-seqs 256                # Maksymalny rozmiar batcha

Wyjaśnienie kluczowych parametrów:

• --gpu-memory-utilization: Ile pamięci GPU użyć (0.90 = 90%). Wyższe wartości pozwalają na większe batchy, ale pozostawiają mniej marginesu na szczyty zużycia pamięci.
• --max-model-len: Maksymalna długość kontekstu. Zmniejszenie tego oszczędza pamięć na większe batchy.
• --tensor-parallel-size: Liczba GPU, na których podzielić model.
• --dtype: Typ danych dla wag (float16, bfloat16 lub float32). FP16 jest zwykle optymalne.
• --max-num-seqs: Maksymalna liczba sekwencji do przetwarzania w batchu.

vLLM vs Ollama

vLLM jest zaprojektowany do wysokiej przepustowości, wieloużytkownikowego serwowania produkcyjnego z continuous batchingiem, PagedAttention i obsługą wielu GPU. Ollama optymalizuje szybki lokalny setup, wygodę dla pojedynczego użytkownika i proste zarządzanie modelami.

Dla szczegółowego przewodnika decyzyjnego obejmującego sygnały migracji, kroki planowania, konfigurację Docker Compose i praktyczną checklistę, zobacz Z Ollama do vLLM: Kiedy migrować swój lokalny serwer LLM.

vLLM vs Docker Model Runner

Docker niedawno wprowadził Model Runner (dawniej GenAI Stack) jako swoje oficjalne rozwiązanie do lokalnego wdrażania modeli AI. Jak porównuje się to z vLLM?

Filozofia architektury

Docker Model Runner dąży do bycia „Dockerem dla AI” – prostym, standaryzowanym sposobem uruchamiania modeli AI lokalnie z tą samą łatwością co uruchamianie kontenerów. Abstrahuje złożoność i zapewnia spójny interfejs między różnymi modelami i frameworkami.

vLLM to wyspecjalizowany silnik inferencji skupiony wyłącznie na serwowaniu LLM z maksymalną wydajnością. To narzędże niskopoziomowe, które konteneryzujesz z Dockerem, a nie kompletna platforma.

Setup i rozpoczęcie pracy

Instalacja Docker Model Runner jest prosta dla użytkowników Docker:

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

Ta podobność do workflow obrazów Docker czyni go natychmiast znajomym dla deweloperów już używających kontenerów.

vLLM wymaga więcej początkowego setupu (Python, CUDA, zależności) lub użycia gotowych obrazów Docker:

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

Charakterystyka wydajności

vLLM oferuje wyższą przepustowość w scenariuszach wieloużytkownikowych dzięki PagedAttention i continuous batching. Dla usług API produkcyjnych obsługujących setki żądań na sekundę, optymalizacje vLLM zapewniają 2–5 razy lepszą przepustowość niż ogólne podejścia serwowania.

Docker Model Runner koncentruje się na łatwości użycia, a nie maksymalnej wydajności. Jest odpowiedni do lokalnego rozwoju, testów i umiarkowanych obciążeń, ale nie implementuje zaawansowanych optymalizacji, które sprawiają, że vLLM wyróżnia się przy skalowaniu.

Wsparcie modeli

Docker Model Runner oferuje wyselekcjonowaną bibliotekę modeli z dostępem w jednym poleceniu do popularnych modeli. Obsługuje wiele frameworków (nie tylko LLM), w tym Stable Diffusion, Whisper i inne modele AI, co czyni go bardziej wszechstronnym dla różnych obciążeń AI.

vLLM specjalizuje się w inferencji LLM z głębokim wsparciem dla modeli językowych opartych na transformatorach. Obsługuje dowolny kompatybilny z HuggingFace LLM, ale nie rozszerza się na inne typy modeli AI, takie jak generowanie obrazów czy rozpoznawanie mowy.

Wdrożenie produkcyjne

vLLM jest sprawdzony w produkcji w firmach takich jak Anthropic, Replicate i wielu innych, serwujących miliardy tokenów dziennie. Jego charakterystyki wydajności i stabilność pod ciężkim obciążeniem czynią go faktycznym standardem dla produkcyjnego serwowania LLM.

Docker Model Runner jest nowszy i pozycjonuje się bardziej dla scenariuszy rozwojowych i lokalnych testów. Choć mógłby serwować ruch produkcyjny, brakuje mu sprawdzonego śladu i optymalizacji wydajności wymaganych do wdrożeń produkcyjnych.

Ekosystem integracji

vLLM integruje się z narzędziami infrastruktury produkcyjnej: operatorami Kubernetes, metrykami Prometheus, Ray do rozdzielonego serwowania i rozległą kompatybilnością z API OpenAI dla istniejących aplikacji.

Docker Model Runner naturalnie integruje się z ekosystemem Docker i Docker Desktop. Dla zespołów już zstandaryzowanych na Docker, ta integracja zapewnia spójne doświadczenie, ale mniej wyspecjalizowanych funkcji serwowania LLM.

Kiedy używać którego

Użyj vLLM do:

• Produkcyjnych usług API LLM
• Wdrożeń o wysokiej przepustowości i wielu użytkownikach
• Wrażliwych kosztowo wdrożeń chmurowych wymagających maksymalnej efektywności
• Środowisk Kubernetes i chmury natywnej
• Gdy potrzebujesz sprawdzonej skalowalności i wydajności

Użyj Docker Model Runner do:

• Lokalnego rozwoju i testów
• Uruchamiania różnych typów modeli AI (nie tylko LLM)
• Zespołów mocno zainwestowanych w ekosystem Docker
• Szybkich eksperymentów bez setupu infrastrukturalnego
• Celów edukacyjnych i naukowych

Podejście hybrydowe: Wiele zespołów rozwija lokalnie z Docker Model Runner dla wygody, a wdraża z vLLM w produkcji dla wydajności. Obrazy Docker Model Runner mogą również być używane do uruchamiania kontenerów vLLM, łącząc oba podejścia.

Najlepsze praktyki wdrożenia produkcyjnego

Wdrożenie Docker

Utwórz gotową do produkcji konfigurację Docker Compose:

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]

Wdrożenie Kubernetes

Wdrażaj vLLM na Kubernetes dla skali produkcyjnej:

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

Monitoring i obserwowalność

vLLM udostępnia metryki Prometheus do monitoringu:

import requests

# Pobierz metryki
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Kluczowe metryki do monitoringu:

• vllm:num_requests_running - Aktywne żądania
• vllm:gpu_cache_usage_perc - Wykorzystanie cache’a KV
• vllm:time_to_first_token - Metryka opóźnienia
• vllm:time_per_output_token - Prędkość generowania

Dostrojenie wydajności

Optymalizacja wykorzystania pamięci GPU: Zacznij od --gpu-memory-utilization 0.90 i dostosowuj na podstawie obserwowanego zachowania. Wyższe wartości pozwalają na większe batchy, ale ryzykują błędy OOM (Out of Memory) podczas szczytów ruchu.

Dostrojenie maksymalnej długości sekwencji: Jeśli Twój przypadek użycia nie wymaga pełnej długości kontekstu, zmniejsz --max-model-len. To uwolni pamięć na większe batchy. Na przykład, jeśli potrzebujesz tylko kontekstu 4K, ustaw --max-model-len 4096 zamiast używać maksimum modelu (często 8K–32K).

Wybór odpowiedniej kwantyzacji: Dla modeli, które to wspierają, użyj wersji skwantyzowanych (8-bit, 4-bit), aby zmniejszyć pamięć i zwiększyć przepustowość:

--quantization awq  # Dla modeli skwantyzowanych AWQ
--quantization gptq # Dla modeli skwantyzowanych GPTQ

Włączenie Prefix Caching: Dla aplikacji ze powtarzającymi się promptami (jak czatboty z komunikatami systemowymi), włącz prefix caching:

--enable-prefix-caching

To cache’uje wartości KV dla wspólnych prefiksów, zmniejszając obliczenia dla żądań dzielących ten sam prefiks promptu.

Rozwiązywanie typowych problemów

Błędy niedoboru pamięci

Objawy: Serwer crashuje z błędami CUDA out of memory.

Rozwiązania:

• Zmniejsz --gpu-memory-utilization do 0.85 lub 0.80
• Zmniejsz --max-model-len, jeśli Twój przypadek użycia na to pozwala
• Obniż --max-num-seqs, aby zmniejszyć rozmiar batcha
• Użyj wersji skwantyzowanej modelu
• Włącz równoległość tensorową, aby rozproszyć na więcej GPU

Na pojedynczej karcie 16 GB większość tych błędów OOM wynika z budżetu cache’a KV, a nie tylko z wag — Cache KV na GPU 16 GB omawia dokładny wzór, dtype FP8 dla cache’a KV oraz kompromisy prefix-caching za --max-model-len i --max-num-seqs, zanim sięgniesz po mniejszy model.

Niska przepustowość

Objawy: Serwer obsługuje mniej żądań, niż oczekiwano.

Rozwiązania:

• Zwiększ --max-num-seqs, aby pozwolić na większe batchy
• Podnieś --gpu-memory-utilization, jeśli masz zapas
• Sprawdź, czy CPU jest wąskim gardłem z htop – rozważ szybsze CPU
• Zweryfikuj wykorzystanie GPU z nvidia-smi – powinno wynosić 95%+
• Włącz FP16, jeśli używasz FP32: --dtype float16

Powolny czas do pierwszego tokenu

Objawy: Wysokie opóźnienie przed rozpoczęciem generowania.

Rozwiązania:

• Używaj mniejszych modeli dla aplikacji wrażliwych na opóźnienia
• Włącz prefix caching dla powtarzających się promptów
• Zmniejsz --max-num-seqs, aby priorytetyzować opóźnienia nad przepustowością
• Rozważ dekodowanie spekulatywne dla wspieranych modeli
• Optymalizuj konfigurację równoległości tensorowej

Błędy ładowania modelu

Objawy: Serwer nie może się uruchomić, nie może załadować modelu.

Rozwiązania:

• Zweryfikuj, czy nazwa modelu dokładnie odpowiada formatowi HuggingFace
• Sprawdź połączenie sieciowe z HuggingFace Hub
• Upewnij się, że jest wystarczająco miejsca na dysku w ~/.cache/huggingface
• Dla modeli gated, ustaw zmienną środowiskową HF_TOKEN
• Spróbuj pobierać ręcznie z huggingface-cli download <model>

Zaawansowane funkcje

Dekodowanie spekulatywne

vLLM obsługuje dekodowanie spekulatywne, w którym mniejszy model draft proponuje tokeny, które większy model docelowy weryfikuje. To może przyspieszyć generowanie o 1,5–2x. Dla kompleksowego przewodnika po metodach dekodowania spekulatywnego – modele draft, EAGLE-3, P-EAGLE i n-gram – zobacz Dekodowanie spekulatywne: Szybsza inferencja bez utraty jakości.

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

Adaptery LoRA

Serwuj wiele adapterów LoRA na wierzchu modelu bazowego bez ładowania wielu pełnych modeli:

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

Następnie określ, który adapter użyć dla każdego żądania:

response = client.completions.create(
    model="sql-lora",  # Użyj adaptera SQL
    prompt="Convert this to SQL: Show me all users created this month"
)

Wielokrotne serwowanie LoRA

Wielokrotne serwowanie LoRA w vLLM pozwala na hostowanie dziesiątek dostrojonych adapterów z minimalnym obciążeniem pamięci. Jest to idealne dla serwowania wariantów modeli specyficznych dla klienta lub zadania:

# Żądanie z konkretnym adapterem LoRA
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Write SQL query"}],
    extra_body={"lora_name": "sql-lora"}
)

Prefix Caching

Włącz automatyczny prefix caching, aby uniknąć ponownego obliczania cache’a KV dla powtarzających się prefiksów promptów:

--enable-prefix-caching

Jest to szczególnie skuteczne dla:

• Czatbotów z fikselnymi promptami systemowymi
• Aplikacji RAG ze spójnymi szablonami kontekstu
• Promptów few-shot learning powtarzanych między żądaniami

Prefix caching może zmniejszyć czas do pierwszego tokenu o 50–80% dla żądań dzielących prefiksy promptów.

Przykłady integracji

Integracja LangChain

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("Explain PagedAttention in simple terms")
print(response)

Integracja LlamaIndex

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("What is vLLM?")
print(response)

Aplikacja FastAPI

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}

Benchmarki wydajności

Dane o wydajności ze świata rzeczywistego pomagają zilustrować zalety vLLM:

Porównanie przepustowości (Mistral-7B na GPU A100):

• vLLM: ~3500 tokenów/sekundę z 64 równoczesnymi użytkownikami
• HuggingFace Transformers: ~250 tokenów/sekundę z tym samym równoległym dostępem
• Ollama: ~1200 tokenów/sekundę z tym samym równoległym dostępem
• Wynik: vLLM zapewnia 14-krotną poprawę w porównaniu z podstawowymi implementacjami

Efektywność pamięci (LLaMA-2-13B):

• Standardowa implementacja: 24GB VRAM, 32 równoczesne sekwencje
• vLLM z PagedAttention: 24GB VRAM, 128 równoczesnych sekwencji
• Wynik: 4x więcej równoczesnych żądań przy tej samej pamięci

Opóźnienia pod obciążeniem (Mixtral-8x7B na 2xA100):

• vLLM: P50 opóźnienie 180ms, P99 opóźnienie 420ms przy 100 req/s
• Standardowe serwowanie: P50 opóźnienie 650ms, P99 opóźnienie 3200ms przy 100 req/s
• Wynik: vLLM utrzymuje spójne opóźnienia pod wysokim obciążeniem

Te benchmarki pokazują, dlaczego vLLM stało się faktycznym standardem dla produkcyjnego serwowania LLM, gdzie liczy się wydajność.

Analiza kosztów

Zrozumienie implikacji kosztowych wyboru vLLM:

Scenariusz: Serwowanie 1 mln żądań/dzień

Z standardowym serwowaniem:

• Wymagane: 8x GPU A100 (80GB)
• Koszt AWS: ~32 USD/h × 24 × 30 = 23 040 USD/miesiąc
• Koszt za 1 mln tokenów: ~0,75 USD

Z vLLM:

• Wymagane: 2x GPU A100 (80GB)
• Koszt AWS: ~8 USD/h × 24 × 30 = 5760 USD/miesiąc
• Koszt za 1 mln tokenów: ~0,19 USD
• Oszczędność: 17 280 USD/miesiąc (75% redukcji)

Ta przewaga kosztowa rośnie ze skalą. Organizacje serwujące miliardy tokenów miesięcznie oszczędzają setki tysięcy dolarów, używając zoptymalizowanego serwowania vLLM zamiast naiwnych implementacji.

Rozważania bezpieczeństwa

Autoryzacja

vLLM domyślnie nie zawiera autoryzacji. W produkcji wdrażaj autoryzację na poziomie reverse proxy:

# Konfiguracja Nginx
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;
}

Albo użyj bramek API takich jak Kong, Traefik lub AWS API Gateway dla autoryzacji klasy enterprise i limitowania ruchu.

Izolacja sieciowa

Uruchamiaj vLLM w sieciach prywatnych, nie bezpośrednio wystawiaj go na internet:

# Przykład NetworkPolicy Kubernetes
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

Limitowanie ruchu

Wdrażaj limitowanie ruchu, aby zapobiec nadużyciom:

# Przykład użycia Redis do limitowania ruchu
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)  # Okno 60 sekund
    
    if requests > 60:  # 60 żądań na minutę
        raise HTTPException(status_code=429, detail="Rate limit exceeded")
    
    return await call_next(request)

Kontrola dostępu do modeli

Dla wdrożeń wielo-najemcy, kontroluj, którzy użytkownicy mogą uzyskać dostęp do których modeli:

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": ["*"]  # Wszystkie modele
}

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

Przewodnik migracji

Z OpenAI do vLLM

Migracja z OpenAI do self-hosted vLLM jest prosta dzięki kompatybilności API:

Przed (OpenAI):

from openai import OpenAI

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

Po (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Jeśli dodałeś autoryzację
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hello"}]
)

Wystarczy dwie zmiany: zaktualizowanie base_url i nazwy model. Cała reszta kodu pozostaje identyczna.

Z Ollama do vLLM

Ollama używa innego formatu API. Podstawowa zmiana po stronie klienta to przełączenie z endpointu REST Ollama na kompatybilne z OpenAI API vLLM:

API Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Why is the sky blue?'})

Ekwiwalent vLLM:

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="Why is the sky blue?"
)

Dla wnikliwego przewodnika migracyjnego obejmującego wybór modelu, szablony czatu, stopniową migrację i praktyczną checklistę, zobacz Z Ollama do vLLM: Kiedy migrować swój lokalny serwer LLM.

Z HuggingFace Transformers do vLLM

Migracja bezpośredniego użycia Python:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

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

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

vLLM:

from vllm import LLM, SamplingParams

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

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

API Python vLLM jest prostsze i znacznie szybsze dla inferencji batchowej.

Przyszłość vLLM

vLLM nadal rozwija się w szybkim tempie z ekscytującymi funkcjami na roadmapie:

Rozdzielone Serwowanie: Oddzielanie prefill (przetwarzanie promptu) i decode (generowanie tokenów) na różnych GPU, aby zoptymalizować wykorzystanie zasobów. Prefill jest ograniczone obliczeniowo, podczas gdy decode jest ograniczone pamięciowo, więc ich uruchamianie na wyspecjalizowanym sprzęcie poprawia efektywność.

Inferencja wielowęzłowa: Rozdzielanie bardzo dużych modeli (100B+ parametrów) na wielu maszynach, umożliwiając serwowanie modeli zbyt dużych dla konfiguracji jednowedługowej.

Rozszerzona kwantyzacja: Wsparcie dla nowych formatów kwantyzacji, takich jak GGUF (używany przez llama.cpp) oraz ulepszona integracja AWQ/GPTQ dla lepszej wydajności z modelami skwantyzowanymi.

Poprawki dekodowania spekulatywnego: Bardziej efektywne modele draft i adaptacyjne strategie spekulacji, aby osiągnąć większe przyspieszenia bez utraty dokładności.

Optymalizacje attention: FlashAttention 3, ring attention dla ekstremalnie długich kontekstów (100K+ tokenów) i inne zaawansowane mechanizmy uwzględniania.

Lepsze pokrycie modeli: Rozszerzanie wsparcia na modele multimodalne (modele językowo-wizualne), modele audio i specjalne architektury, wraz z ich pojawianiem się.

Projekt vLLM utrzymuje aktywny rozwój z wkładami z UC Berkeley, Anyscale i szerszej społeczności open-source. W miarę jak wdrażanie LLM staje się ważniejsze dla systemów produkcyjnych, rola vLLM jako standardu wydajności nadal rośnie. Dla szerszego porównania vLLM z inną lokalną i chmurową infrastrukturą LLM, sprawdź nasz artykuł Serwowanie LLM: Lokalne, Self-Hosted i Infrastruktura Chmurowa w Porównaniu.

Przydatne linki

Powiązane artykuły na tej stronie

• Lokalne Serwowanie LLM: Kompletny Przewodnik 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio i inne - Kompleksowe porównanie 12+ lokalnych narzędzi do serwowania LLM, w tym szczegółowa analiza vLLM obok Ollama, LocalAI, Jan, LM Studio i innych. Pokrywa dojrzałość API, wsparcie wywoływania narzędzi, kompatybilność GGUF i benchmarki wydajności, aby pomóc w wyborze odpowiedniego rozwiązania.

• Ściągawka Ollama - Kompletny referencje poleceń i ściągawka Ollama obejmująca instalację, zarządzanie modelami, użycie API i najlepsze praktyki dla lokalnego wdrożenia LLM. Niezbędne dla deweloperów używających Ollama obok lub zamiast vLLM.

• Szybki start z llama.cpp z CLI i Serwerem - Lekka inferencja C/C++ dla modeli GGUF z llama-cli i kompatybilnym z OpenAI llama-server. Idealny, gdy potrzebujesz precyzyjnej kontroli, wdrożenia offline lub minimalnego stosu bez Pythona.

• Docker Model Runner vs Ollama: Którego wybrać? - Głębokie porównanie Docker Model Runner i Ollama dla lokalnego wdrożenia LLM, analizujące wydajność, wsparcie GPU, kompatybilność API i przypadki użycia. Pomaga zrozumieć krajobraz konkurencyjny, w którym działa vLLM.

• Ściągawka Docker Model Runner: Polecenia i przykłady - Praktyczna ściągawka Docker Model Runner z poleceniami i przykładami do wdrażania modeli AI. Przydatna dla zespołów porównujących podejście Docker z wyspecjalizowanymi funkcjami serwowania LLM w vLLM.

Zewnętrzne zasoby i dokumentacja

• Repozytorium vLLM GitHub - Oficjalne repozytorium vLLM z kodem źródłowym, kompleksową dokumentacją, przewodnikami instalacji i aktywnymi dyskusjami społeczności. Niezbędne źródło, aby być na bieżąco z najnowszymi funkcjami i rozwiązywaniem problemów.

• Dokumentacja vLLM - Oficjalna dokumentacja pokrywająca wszystkie aspekty vLLM od podstawowego setupu po zaawansowaną konfigurację. Zawiera referencje API, przewodniki po dostosowywaniu wydajności i najlepsze praktyki wdrożenia.

• Artykuł PagedAttention - Artykuł akademicki wprowadzający algorytm PagedAttention, który napędza efektywność vLLM. Niezbędne czytanie, aby zrozumieć innowacje techniczne stojące za korzyściami wydajnościowymi vLLM.

• Blog vLLM - Oficjalny blog vLLM z ogłoszeniami o wydaniach, benchmarkami wydajności, technicznymi analizami i studiami przypadków społeczności z wdrożeń produkcyjnych.

• HuggingFace Model Hub - Kompleksowe repozytorium open-source’owych LLM działających z vLLM. Szukaj modeli według rozmiaru, zadania, licencji i charakterystyk wydajności, aby znaleźć odpowiedni model dla Twojego przypadku użycia.

• Dokumentacja Ray Serve - Dokumentacja frameworku Ray Serve do budowy skalowalnych, rozproszonych wdrożeń vLLM. Ray oferuje zaawansowane funkcje takie jak autoskalowanie, wielomodelowe serwowanie i zarządzanie zasobami dla systemów produkcyjnych.

• NVIDIA TensorRT-LLM - NVIDIA TensorRT-LLM do高度 zoptymalizowanej inferencji na GPU NVIDIA. Alternatywa dla vLLM z różnymi strategiami optymalizacji, przydatna do porównania i zrozumienia krajobrazu optymalizacji inferencji.

• Referencja API OpenAI - Oficjalna dokumentacja API OpenAI, z którą kompatybilne jest API vLLM. Odwołuj się do niej przy budowaniu aplikacji, które muszą działać zarówno z OpenAI, jak i self-hosted endpointami vLLM zamiennie.