Szybki start z vLLM: wydajne wdrażanie modeli LLM – rok 2026

vLLM to silnik wnioskowania i serwowania o wysokim przepustowości i efektywnym wykorzystaniu pamięci dla dużych modeli językowych (LLM), opracowany przez Sky Computing Lab z UC Berkeley.

Dzięki rewolucyjnemu algorytmowi PagedAttention, vLLM osiąga przepustowość 14-24 razy wyższą niż tradycyjne metody serwowania, co czyni go najlepszym wyborem do wdrożeń produkcyjnych LLM. Aby zobaczyć, jak vLLM wpasowuje się w kontekście Ollama, Docker Model Runner, LocalAI i dostawców chmurowych – w tym koszty i kompromisy infrastrukturalne – zobacz Hostowanie LLM: Infrastruktura Lokalna, Samodzielnie Hostowana i Chmurowa – Porównanie.

Czym jest vLLM?

vLLM (virtual LLM) to otwartokodowa biblioteka do szybkiego wnioskowania i serwowania LLM, która szybko stała się standardem branżowym dla wdrożeń produkcyjnych. Wprowadzona w 2023 roku, zaprezentowała PagedAttention, przełomową technikę zarządzania pamięcią, która drastycznie poprawia efektywność serwowania.

Kluczowe Cechy

Wysoka Przepustowość: vLLM oferuje przepustowość 14-24 razy wyższą w porównaniu do HuggingFace Transformers przy tym samym sprzęcie. Ten ogromny wzrost wydajności wynika z ciągłego batching, zoptymalizowanych rdzeni CUDA oraz algorytmu PagedAttention, który eliminuje fragmentację pamięci.

Kompatybilność z API OpenAI: vLLM zawiera wbudowany serwer API w pełni kompatybilny z formatem OpenAI. Pozwala to na bezproblemową migrację z OpenAI na infrastrukturę samodzielnie hostowaną bez zmiany kodu aplikacji. Wystarczy skierować klienta API do punktu końcowego vLLM, a wszystko zadziała transparentnie.

Algorytm PagedAttention: Kluczową innowacją stojącą za wydajnością vLLM jest PagedAttention, który stosuje koncepcję stronicowania pamięci wirtualnej do mechanizmów uwagi. Zamiast przydzielania ciągłych bloków pamięci dla pamięci podręcznej KV (co prowadzi do fragmentacji), PagedAttention dzieli pamięć na bloki o stałym rozmiarze, które mogą być przydzielane na żądanie. Redukuje to marnowanie pamięci do 4 razy i umożliwia znacznie większe rozmiary wsadowe.

Ciągłe Batching (Continuous Batching): W przeciwieństwie do statycznego batching, gdzie musisz czekać, aż wszystkie sekwencje się zakończą, vLLM stosuje ciągłe (ruchome) batching. Gdy jedna sekwencja się zakończy, nowa może być dodana do wsadu. Maksymalizuje to wykorzystanie GPU i minimalizuje opóźnienia dla nadchodzących żądań.

Wsparcie dla Wielu GPU: vLLM obsługuje równoległość tensorową i potokową do dystrybucji dużych modeli między wiele 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 Modełów: 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 z HuggingFace Hub.

Kiedy Korzystać z vLLM

vLLM błyszczy w specyficznych scenariuszach, gdzie jego mocne strony są najbardziej widoczne:

Produkcjowe Usługi API: Gdy musisz serwować LLM wielu współbieżnym użytkownikom przez API, wysoka przepustowość vLLM i efektywne batching czynią go najlepszym wyborem. Firmy uruchamiające czatboty, asystentów kodu lub usługi generowania treści korzystają z jego zdolności do obsługi setek żądań na sekundę.

Obciążenia o Wysokiej Współbieżności: Jeśli Twoja aplikacja ma wielu użytkowników jednocześnie wysyłających żądania, ciągłe batching i PagedAttention w vLLM pozwalają na obsługę większej liczby użytkowników przy tym samym sprzęcie w porównaniu do alternatyw.

Optymalizacja Kosztów: Gdy koszty GPU są istotne, wyższa przepustowość vLLM oznacza, że możesz serwować ten sam ruch przy użyciu mniejszej liczby GPU, co bezpośrednio obniża koszty infrastruktury. Czterokrotna efektywność pamięci dzięki PagedAttention pozwala również na używanie mniejszych, tańszych instancji GPU.

Wdrożenia Kubernetes: Bezstanowa architektura vLLM i przyjazna kontenerom budowa czynią go idealnym dla klastrów Kubernetes. Jego spójna wydajność pod obciążeniem i proste zarządzanie zasobami dobrze integrują się z infrastrukturą chmurową.

Kiedy NIE Korzystać z vLLM: Do lokalnego rozwoju, eksperymentowania lub scenariuszy jednowyżycikowych, narzędzia takie jak Ollama lub llama.cpp oferują lepsze doświadczenie użytkownika przy prostszym setupie. Skomplikowanie vLLM jest uzasadnione, gdy potrzebujesz jego zalet wydajnościowych dla obciążeń produkcyjnych.

Jak Zainstalować vLLM

Wymagania Wstępne

Przed zainstalowaniem 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, RTX 20/30/40 series)
• CUDA: Wersja 11.8 lub wyższa
• 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 poprzez 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 najbardziej niezawodną metodę wdrożenia, szczególnie w produkcji:

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

# Uruchom vLLM ze wsparciem 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 wielo-GPU, ponieważ umożliwia prawidłową komunikację międzyprocesową.

Budowanie ze Źródeł

Dla najnowszych funkcji lub niestandardowych modyfikacji, zbuduj ze źródeł:

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

Szybki Start z vLLM

Uruchomienie Pierwszego Modelu

Uruchom vLLM z modelem używając interfejsu linii komend:

# Pobierz i serwuj Mistral-7B z API kompatybilnym z OpenAI
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 pamięci podręcznej) i uruchomi serwer. Zobaczysz komunikat, ż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

Wysyłanie Żądań API

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

Używając 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żywając Klienta Python OpenAI:

from openai import OpenAI

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

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 wsadu

Wyjaśnienie Kluczowych Parametrów:

• --gpu-memory-utilization: Ile pamięci GPU ma być używane (0.90 = 90%). Wyższe wartości pozwalają na większe wsady, ale pozostawiają mniej marginesu na skoki zużycia pamięci.
• --max-model-len: Maksymalna długość kontekstu. Zmniejszenie tego zapisuje pamięć dla większych wsadów.
• --tensor-parallel-size: Liczba GPU, na które model ma być podzielony.
• --dtype: Typ danych dla wag (float16, bfloat16 lub float32). FP16 jest zazwyczaj optymalne.
• --max-num-seqs: Maksymalna liczba sekwencji do przetworzenia w jednym wsadzie.

vLLM kontra Ollama

vLLM jest zaprojektowany do wysokoprzepustowego, wieloużytkownika serwowania produkcyjnego z ciągłym batchingiem, PagedAttention i wsparciem wielo-GPU. Ollama optymalizuje szybki lokalny setup, wygody jednowyżycikowej i proste zarządzanie modelami.

Aby uzyskać szczegółowy przewodnik decyzyjny obejmujący sygnały migracji, kroki planowania, konfigurację Docker Compose i praktyczną kontrolną listę, zobacz Ollama do vLLM: Kiedy Przenieść Lokalny Serwer LLM.

vLLM kontra 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ę do vLLM?

Filozofia Architektury

Docker Model Runner ma być “Dockerm dla AI” – prostym, ustandaryzowanym sposobem uruchamiania modeli AI lokalnie z taką samą łatwością, jak uruchamiania kontenerów. Abstrahuje złożoność i zapewnia spójny interfejs między różnymi modelami i frameworkami.

vLLM to specjalizowany silnik wnioskowania skupiony wyłącznie na serwowaniu LLM z maksymalną wydajnością. To narzędzie niższego poziomu, które konteneryzujesz z Dockerem, a nie kompletna platforma.

Setup i Rozpoczęcie

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

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

Ta podobność do przepływu obrazów Dockera czyni ją natychmiast znajomą 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 Dockera:

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

Cechy Wydajnościowe

vLLM dostarcza lepszą przepustowość w scenariuszach wieloużytkowników dzięki PagedAttention i ciągłemu batchingowi. Dla produkcyjnych usług API obsługujących setki żądań na sekundę, optymalizacje vLLM zapewniają 2-5 razy lepszą przepustowość niż generyczne podejścia do serwowania.

Docker Model Runner koncentruje się na łatwości użycia, a nie na maksymalnej wydajności. Jest odpowiedni do lokalnego rozwoju, testowania i umiarkowanych obciążeń, ale nie implementuje zaawansowanych optymalizacji, które czynią vLLM mistrzem skalowania.

Wsparcie Modełów

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

vLLM specjalizuje się we wnioskowaniu LLM z głębokim wsparciem dla modeli językowych opartych na transformerach. Obsługuje każdy LLM kompatybilny z HuggingFace, ale nie rozszerza się na inne typy modeli AI, jak generowanie obrazów czy rozpoznawanie mowy.

Wdrożenia Produkcyjne

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

Docker Model Runner jest nowszy i pozycjonuje się bardziej dla scenariuszy deweloperskich i lokalnego testowania. Chociaż mógłby serwować ruch produkcyjny, brakuje mu udokumentowanego track recordu i optymalizacji wydajnościowych, które wymagają wdrożenia produkcyjne.

Ekosystem Integracji

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

Docker Model Runner integruje się naturalnie z ekosystemem Dockera i Docker Desktop. Dla zespołów mocno zainwestowanych w Docker, ta integracja zapewnia spójne doświadczenie, ale mniej specjalizowanych funkcji serwowania LLM.

Kiedy Korzystać z Każdego

Używaj vLLM do:

• Produkcyjnych usług API LLM
• Wysokoprzepustowych, wieloużytkowników wdrożeń
• Wrażliwych na koszty wdrożeń chmurowych wymagających maksymalnej efektywności
• Środowisk Kubernetes i chmurowych
• Gdy potrzebujesz udowodnionej skalowalności i wydajności

Używaj Docker Model Runner do:

• Lokalnego rozwoju i testowania
• Uruchamiania różnych typów modeli AI (nie tylko LLM)
• Zespołów mocno zainwestowanych w ekosystem Dockera
• Szybkiego eksperymentowania bez setupu infrastruktury
• Celów edukacyjnych i naukowych

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

Najlepsze Praktyki Wdrożeń Produkcyjnych

Wdrożenie Docker

Stwórz gotowy 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

Wdróż 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

Monitorowanie i Obserwowalność

vLLM eksponuje metryki Prometheus do monitorowania:

import requests

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

Kluczowe metryki do monitorowania:

• vllm:num_requests_running - Aktywne żądania
• vllm:gpu_cache_usage_perc - Wykorzystanie pamięci podręcznej KV
• vllm:time_to_first_token - Metryka opóźnienia
• vllm:time_per_output_token - Szybkość generowania

Dostrajanie Wydajności

Optymalizuj Wykorzystanie Pamięci GPU: Zacznij z --gpu-memory-utilization 0.90 i dostosuj na podstawie obserwowanego zachowania. Wyższe wartości pozwalają na większe wsady, ale niosą ryzyko błędów OOM podczas skoków ruchu.

Dostrój Maksymalną Długość Sekwencji: Jeśli Twój przypadek użycia nie wymaga pełnej długości kontekstu, zmniejsz --max-model-len. To zwalnia pamięć dla większych wsadów. Na przykład, jeśli potrzebujesz tylko kontekstu 4K, ustaw --max-model-len 4096 zamiast używać maksimum modelu (często 8K-32K).

Wybierz Odpowiednią Kwantyzację: Dla modeli, które to wspierają, użyj wersji skwantyzowanych (8-bit, 4-bit) do redukcji pamięci i zwiększenia przepustowości:

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

Włącz Pamięć Podręczną Prefiksów: Dla aplikacji z powtarzającymi się promptami (jak czatboty z komunikatami systemowymi), włącz pamięć podręczną prefiksów:

--enable-prefix-caching

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

Rozwiązywanie Najczęstszych Problemów

Błędy Braku Pamięci (Out of Memory)

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 pozwala
• Obniż --max-num-seqs, aby zmniejszyć rozmiar wsadu
• Użyj wersji skwantyzowanej modelu
• Włącz równoległość tensorową do dystrybucji na więcej GPU

Niska Przepustowość

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

Rozwiązania:

• Zwiększ --max-num-seqs, aby pozwolić na większe wsady
• 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 być 95%+
• Włącz FP16, jeśli używasz FP32: --dtype float16

Wolny Czas Pierwszego Tokena

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

Rozwiązania:

• Użyj mniejszych modeli dla aplikacji krytycznych pod względem opóźnień
• Włącz pamięć podręczną prefiksów dla powtarzających się promptów
• Zmniejsz --max-num-seqs, aby priorytetyzować opóźnienie nad przepustowość
• Rozważ dekodowanie spekulacyjne dla obsługiwanych modeli
• Optymalizuj konfigurację równoległości tensorowej

Nieudne Ładowanie Modelu

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

Rozwiązania:

• Zweryfikuj, czy nazwa modelu dokładnie pasuje do formatu HuggingFace
• Sprawdź łączność sieciową z HuggingFace Hub
• Upewnij się, że wystarczająco miejsca na dysku w ~/.cache/huggingface
• Dla modeli gated, ustaw zmienną środowiskową HF_TOKEN
• Spróbuj ręcznego pobrania z huggingface-cli download <model>

Zaawansowane Funkcje

Dekodowanie Spekulacyjne

vLLM obsługuje dekodowanie spekulacyjne, gdzie mniejszy model roboczy proponuje tokeny, które większy model docelowy weryfikuje. To może przyspieszyć generowanie 1.5-2x. Aby uzyskać kompleksowy przewodnik po metodach dekodowania spekulacyjnego — modelach roboczych, EAGLE-3, P-EAGLE i n-gram — zobacz Dekodowanie Spekulacyjne: Szybsze Wnioskowanie 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 ma być użyty 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"
)

Wielowarstwowe Serwowanie LoRA

Wielowarstwowe serwowanie LoRA w vLLM pozwala na hostowanie dziesiątków dostrojonych adapterów z minimalnym nadmiarowym zużyciem pamięci. To idealne do serwowania wariantów modeli specyficznych dla klientów lub zadań:

# Żą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"}
)

Pamięć Podręczna Prefiksów

Włącz automatyczne cachowanie prefiksów, aby uniknąć ponownego obliczania pamięci KV dla powtarzających się prefiksów promptów:

--enable-prefix-caching

To jest szczególnie skuteczne dla:

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

Pamięć podręczna prefiksów może zmniejszyć czas do pierwszego tokena o 50-80% dla żądań dzielących prefiksy promptów.

Przykłady Integracji

Integracja z 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 z 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 z rzeczywistej wydajności pomagają zilustrować zalety vLLM:

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

• vLLM: ~3,500 tokenów/sekunda przy 64 współbieżnych użytkownikach
• HuggingFace Transformers: ~250 tokenów/sekunda przy tym samym współbieżności
• Ollama: ~1,200 tokenów/sekunda przy tym samym współbieżności
• Wynik: vLLM zapewnia 14-krotną poprawę w stosunku do podstawowych implementacji

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

• Standardowa implementacja: 24GB VRAM, 32 współbieżne sekwencje
• vLLM z PagedAttention: 24GB VRAM, 128 współbieżnych sekwencji
• Wynik: 4 razy więcej współbieżnych żądań przy tej samej pamięci

Opóźnienie Pod Obciążeniem (Mixtral-8x7B na 2xA100):

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

Te benchmarki demonstrują, dlaczego vLLM stało się de facto standardem dla produkcyjnego serwowania LLM, gdzie wydajność ma znaczenie.

Analiza Kosztów

Zrozumienie implikacji kosztowych wyboru vLLM:

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

Ze Standardowym Serwowaniem:

• Wymagane: 8x GPU A100 (80GB)
• Koszt AWS: ~$32/godzinę × 24 × 30 = $23,040/miesiąc
• Koszt za 1M tokenów: ~$0.75

Z vLLM:

• Wymagane: 2x GPU A100 (80GB)
• Koszt AWS: ~$8/godzinę × 24 × 30 = $5,760/miesiąc
• Koszt za 1M tokenów: ~$0.19
• Oszczędność: $17,280/miesiąc (75% redukcja)

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

Uwierzytelnianie

vLLM nie zawiera uwierzytelniania domyślnie. Dla produkcji, zaimplementuj uwierzytelnianie 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;
}

Lub użyj bram API jak Kong, Traefik lub AWS API Gateway dla uwierzytelniania i limitowania szybkości klasy enterprise.

Izolacja Sieciowa

Uruchamiaj vLLM w prywatnych sieciach, nie bezpośrednio wystawiając do internetu:

# 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 Szybkości

Zaimplementuj limitowanie szybkości, aby zapobiec nadużyciom:

# Przykład używający Redis do limitowania szybkości
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="Przekroczono limit szybkości")
    
    return await call_next(request)

Kontrola Dostępu do Modełów

Dla wdrożeń wielodostawczych, 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 samodzielnie hostowanego 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ś uwierzytelnianie
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hello"}]
)

Wystarczą dwie zmiany: aktualizacja base_url i nazwy model. Reszta kodu pozostaje identyczna.

Z Ollamy do vLLM

Ollama używa innego formatu API. Podstawowa zmiana po stronie klienta polega na przełączeniu się z punktu końcowego REST Ollamy na API vLLM kompatybilne z OpenAI:

API Ollamy:

import requests

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

Równoważnik 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?"
)

Aby uzyskać gruntowny przewodnik migracyjny obejmujący wybór modelu, szablony czatu, stopniową migrację i praktyczną kontrolną listę, zobacz Ollama do vLLM: Kiedy Przenieść Lokalny Serwer LLM.

Z HuggingFace Transformers do vLLM

Bezpośrednia migracja 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 wnioskowania wsadowego.

Przyszłość vLLM

vLLM kontynuuje szybki rozwój z ekscytującymi funkcjami na roadmapie:

Serwowanie Rozdzielone: Oddzielenie prefilla (przetwarzanie promptów) i dekodowania (generowanie tokenów) na różne GPU do optymalizacji wykorzystania zasobów. Prefill jest ograniczony obliczeniami, podczas gdy dekodowanie jest ograniczone pamięcią, więc uruchamianie ich na specjalizowanym sprzęcie poprawia efektywność.

Wnioskowanie Wielo-Węzłowe: Dystrybucja bardzo dużych modeli (100B+ parametrów) między wiele maszyn, umożliwiając serwowanie modeli zbyt dużych dla konfiguracji jednowęzłowych.

Zaawansowana Kwantyzacja: Wsparcie dla nowych formatów kwantyzacji, jak GGUF (używane przez llama.cpp) i poprawiona integracja AWQ/GPTQ dla lepszej wydajności z modelami skwantyzowanymi.

Poprawy Dekodowania Spekulacyjnego: Bardziej efektywne modele robocze i adaptacyjne strategie spekulacji do osiągnięcia wyższych przyśpieszeń bez utraty dokładności.

Optymalizacje Uwagi: FlashAttention 3, ring attention dla ekstremalnie długich kontekstów (100K+ tokenów) i inne nowocześnie mechanizmy uwagi.

Lepsze Pokrycie Modełów: Rozszerzenie wsparcia do modeli multimodalnych (modele wizji-językowe), modeli audio i specjalizowanych architektur, jak się pojawiają.

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ę bardziej krytyczne dla systemów produkcyjnych, rola vLLM jako standardu wydajnościowego nadal rośnie. Aby uzyskać szersze porównanie vLLM z innymi infrastrukturami LLM lokalnych i chmurowych, sprawdź nasze Hostowanie LLM: Infrastruktura Lokalna, Samodzielnie Hostowana i Chmurowa – Porównanie.

Przydatne Linki

Powiązane Artykuły na Tej Stronie

• Lokalny Hosting LLM: Kompletny Przewodnik 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio i Więcej - Kompleksowe porównanie 12+ narzędzi do lokalnego hostowania LLM, w tym szczegółowa analiza vLLM obok Ollamy, LocalAI, Jan, LM Studio i innych. Obejmuje dojrzałość API, wsparcie wywoływania narzędzi, kompatybilność GGUF i benchmarki wydajności, aby pomóc wybrać odpowiednie rozwiązanie.

• Ollama Cheatsheet - Kompletny przewodnik komend i cheatsheet Ollamy obejmujący instalację, zarządzanie modelami, użycie API i najlepsze praktyki dla lokalnego wdrożenia LLM. Niezbędne dla deweloperów używających Ollamy obok lub zamiast vLLM.

• llama.cpp Szybki Start z CLI i Serwerem - Lekki wnioskowanie C/C++ dla modeli GGUF z llama-cli i serwerem llama-server kompatybilnym z OpenAI. Idealne, gdy potrzebujesz precyzyjnej kontroli, wdrożenia offline lub minimalnego stacku bez Pythona.

• Docker Model Runner kontra Ollama: Co Wybrać? - Dogłębne porównanie Model Runner Dockera i Ollamy dla lokalnego wdrożenia LLM, analizując wydajność, wsparcie GPU, kompatybilność API i przypadki użycia. Pomaga zrozumieć konkurencyjny krajobraz, w którym operuje vLLM.

• Docker Model Runner Cheatsheet: Komendy i Przykłady - Praktyczny cheatsheet Docker Model Runner z komendami i przykładami do wdrożenia modeli AI. Przydatny dla zespołów porównujących podejście Dockera ze specjalizowanymi możliwościami serwowania LLM 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ędny zasób do bycia na bieżąco z najnowszymi funkcjami i rozwiązywaniem problemów.

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

• Artykuł o PagedAttention - Artykuł akademicki wprowadzający algorytm PagedAttention, który napędza efektywność vLLM. Niezbędna lektura do zrozumienia innowacji technicznych stojących za zaletami wydajnościowymi vLLM.

• Blog vLLM - Oficjalny blog vLLM z ogłoszeniami wydania, benchmarkami wydajności, technicznymi analizami i studiami przypadku społeczności z wdrożeń produkcyjnych.

• HuggingFace Model Hub - Kompleksowe repozytorium open-source LLM, które działają z vLLM. Szukaj modeli po rozmiarze, zadaniu, licencji i cechach wydajnościowych, aby znaleźć odpowiedni model dla Twojego przypadku użycia.

• Dokumentacja Ray Serve - Dokumentacja frameworka Ray Serve do budowy skalowalnych, dystrybuowanych wdrożeń vLLM. Ray zapewnia zaawansowane funkcje, takie jak autoscaling, wielomodelowe serwowanie i zarządzanie zasobami dla systemów produkcyjnych.

• NVIDIA TensorRT-LLM - TensorRT-LLM od NVIDIA dla wysoce zoptymalizowanego wnioskowania na GPU NVIDIA. Alternatywa dla vLLM z różnymi strategiami optymalizacji, przydatna do porównania i zrozumienia krajobrazu optymalizacji wnioskowania.

• Referencja API OpenAI - Oficjalna dokumentacja API OpenAI, z którą API vLLM jest kompatybilne. Skonsultuj się z tym przy budowaniu aplikacji, które muszą działać zarówno z OpenAI, jak i samodzielnie hostowanymi punktami końcowymi vLLM zamiennie.