Szybki start z vLLM: wysokiej wydajności serwowanie modeli językowych – 2026

vLLM to wysokoprzepływny, pamięciowo wydajny silnik wnioskowania i serwowania dla dużych modeli językowych (LLM), opracowany przez Sky Computing Lab z UC Berkeley.

Dzięki rewolucyjnemu algorytmowi PagedAttention, vLLM osiąga wydajność 14–24 razy większą niż tradycyjne metody serwowania, stając się najlepszym wyborem do wdrożeń produkcyjnych LLM. Aby zobaczyć, jak vLLM mieści się wśród Ollama, Docker Model Runner, LocalAI i dostawców chmurowych – w tym analizy kosztów i infrastruktury – zobacz Hostowanie LLM: lokalne, samodzielne i infrastruktura chmurowa porównane.

Co to jest vLLM?

vLLM (wirtualny LLM) to biblioteka open source do szybkiego wnioskowania i serwowania LLM, która szybko stała się standardem branżowym dla wdrożeń produkcyjnych. Wydana w 2023 roku, wprowadziła PagedAttention, innowacyjną technikę zarządzania pamięcią, która znacząco poprawiła wydajność serwowania.

Kluczowe funkcje

Wysoka wydajność przepływna: vLLM dostarcza wydajność 14–24 razy większą niż HuggingFace Transformers przy tej samej aparaturze. Ten ogromny wzrost wydajności pochodzi z ciągłego batchowania, zoptymalizowanych jąder CUDA i algorytmu PagedAttention, który eliminuje fragmentację pamięci.

Kompatybilność z API OpenAI: vLLM zawiera wbudowany serwer API, który jest w pełni kompatybilny z formatem OpenAI. To umożliwia płynną migrację z OpenAI na infrastrukturę samodzielnie hostowaną bez zmiany kodu aplikacji. Prosto skieruj swojego klienta API do punktu końcowego vLLM i działa transparentnie.

Algorytm PagedAttention: Jądro innowacji za wydajność vLLM to PagedAttention, który zastosował koncepcję wirtualnego paginowania pamięci do mechanizmów uwagi. Zamiast alokować ciągłe bloki pamięci dla KV cache (co prowadzi do fragmentacji), PagedAttention dzieli pamięć na stałe rozmiary bloków, które mogą być alokowane na żądanie. To zmniejsza marnotrawstwo pamięci nawet do 4 razy i umożliwia znacznie większe rozmiary batchów.

Ciągłe batchowanie: Odpowiadając na statyczne batchowanie, gdzie czekasz, aż wszystkie sekwencje zostaną ukończone, vLLM korzysta z ciągłego (rolującego) batchowania. Jak tylko jedna sekwencja zostanie ukończona, nowa może zostać dodana do batcha. To maksymalizuje wykorzystanie GPU i minimalizuje opóźnienia dla przychodzących żądań.

Wsparcie wielo-GPU: vLLM obsługuje tensorowe i rurkowe równoległość do dystrybuowania dużych modeli na wielu GPU. Może efektywnie serwować modele, które nie mieszczą się w pamięci pojedynczego GPU, wspierają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. Wspiera zarówno modele dostrajane do instrukcji, jak i bazowe modele z HuggingFace Hub.

Kiedy używać vLLM

vLLM wyróżnia się w konkretnych scenariuszach, w których jego zalety są najbardziej widoczne:

Usługi API produkcyjne: Kiedy potrzebujesz serwowania LLM dla wielu współbieżnych użytkowników przez API, wysoka przepływność i efektywne batchowanie vLLM czynią z niego najlepszy wybór. Firmy prowadzące chatboty, asystentów kodu lub usługi generowania treści korzystają z jego zdolności do obsługi setek żądań na sekundę.

Wysokie obciążenia współbieżne: Jeśli Twoja aplikacja ma wiele jednoczesnych użytkowników wysyłających żądania, ciągłe batchowanie i PagedAttention vLLM umożliwiają serwowanie większej liczby użytkowników przy tej samej aparaturze niż inne alternatywy.

Optymalizacja kosztów: Kiedy koszty GPU są problemem, wyższa przepływność vLLM oznacza, że możesz obsłużyć ten sam ruch przy mniejszej liczbie GPU, bezpośrednio zmniejszając koszty infrastruktury. 4-krotna efektywność pamięci z PagedAttention pozwala również na użycie mniejszych, tańszych instancji GPU.

Wdrożenia w Kubernetes: Bezstanowa architektura i kontenerowalny charakter vLLM czynią z niego idealny wybór dla klastrów Kubernetes. Jego spójna wydajność przy obciążeniu i prosty zarządzanie zasobami dobrze integrują się z infrastrukturą chmurową.

Kiedy NIE używać vLLM: Dla lokalnego rozwoju, eksperymentowania lub scenariuszy jednoosobowych, narzędzia takie jak Ollama oferują lepsze doświadczenie użytkownika z prostszym ustawieniem. Złożoność vLLM jest uzasadniona, kiedy potrzebujesz jego zalet wydajności dla obciążeń produkcyjnych.

Jak zainstalować vLLM

Wymagania wstępne

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

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

Instalacja przez pip

Najprostszy sposób instalacji to użycie pip. Działa to na systemach z CUDA 11.8 lub nowszym:

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

# Zainstaluj vLLM
pip install vllm

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

Dla systemów z różnymi 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 za pomocą Docker

Docker oferuje najbardziej niezawodny sposób wdrażania, zwłaszcza w przypadku wdrożeń produkcyjnych:

# 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 wielo-GPU, ponieważ umożliwia odpowiednie komunikowanie się między procesami.

Budowanie z źródła

Dla najnowszych funkcji lub niestandardowych modyfikacji, zbuduj z źródła:

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

Krótki przewodnik startowy vLLM

Uruchamianie pierwszego modelu

Uruchom vLLM z modelem za pomocą interfejsu wiersza poleceń:

# Pobierz i uruchom 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 pobra model z HuggingFace Hub (jeśli nie jest jeszcze zapisany) i uruchomi serwer. Zobaczysz 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

Tworzenie żądań API

Po uruchomieniu serwera możesz wysyłać żądania za pomocą klienta Pythona 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": "Wyjaśnij, co to jest vLLM w jednym zdaniu:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Użycie klienta Pythona OpenAI:

from openai import OpenAI

# Wskazuje na serwer vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM nie wymaga uwierzytelnienia domyślnie
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Wyjaśnij, co to jest vLLM w jednym zdaniu:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API do uzupełnień rozmowy:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Jesteś pomocnym asystentem."},
        {"role": "user", "content": "Co to jest PagedAttention?"}
    ],
    max_tokens=200
)

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

Zaawansowane konfiguracje

vLLM oferuje wiele parametrów 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                # Maksymalna liczba sekwencji

Wyjaśnienie kluczowych parametrów:

• --gpu-memory-utilization: Jaka część pamięci GPU ma zostać wykorzystana (0.90 = 90%). Wyższe wartości pozwalają na większe batchy, ale pozostawiają mniej marginesu na wstrząsy pamięci.
• --max-model-len: Maksymalna długość kontekstu. Zmniejszenie tej wartości oszczędza pamięć na większe batchy.
• --tensor-parallel-size: Liczba GPU, na które ma zostać podzielony model.
• --dtype: Typ danych dla wag (float16, bfloat16 lub float32). FP16 jest zazwyczaj optymalny.
• --max-num-seqs: Maksymalna liczba sekwencji do przetworzenia w batchu.

Porównanie vLLM z Ollama

Oba vLLM i Ollama są popularnymi opcjami do lokalnego hostowania LLM, ale skierowane są do różnych przypadków użycia. Zrozumienie, kiedy używać każdego narzędzia, może znacząco wpłynąć na sukces projektu.

Wydajność i przepływność

vLLM jest projektowany do maksymalnej przepływności w scenariuszach wielu użytkowników. Jego PagedAttention i ciągłe batchowanie pozwalają na efektywne obsługiwanie setek współbieżnych żądań. Testy pokazują, że vLLM osiąga wydajność 14–24 razy większą niż standardowe implementacje i 2–4 razy większą niż Ollama przy wysokiej współbieżności.

Ollama optymalizuje się dla interaktywnego użycia przez jednego użytkownika, z koncentracją na niskim opóźnieniu dla pojedynczych żądań. Choć nie dorównuje vLLM w przepływności wielu użytkowników, oferuje bardzo dobre wydajność w przypadkach rozwoju i użytkowania osobistego z szybszymi czasami startu i niższym zużyciem zasobów w czasie bezczynności.

Łatwość użycia

Ollama wygrywa decydująco w prostocie. Instalacja to jedno polecenie (curl | sh), a uruchamianie modeli to tak proste jak ollama run llama2. Wchodzi w skład biblioteki modeli z wersjami skwantowanymi zoptymalizowanymi dla różnych profilów sprzętu. Doświadczenie użytkownika przypomina Docker – pobierz, uruchom i idź.

vLLM wymaga więcej konfiguracji: zarządzanie środowiskiem Pythona, instalacja CUDA, zrozumienie parametrów serwowania i ręczne określanie modelu. Kurwa uczenia się jest bardziej stroma, ale otrzymujesz szczegółowe kontrole nad optymalizacją wydajności. Ta złożoność jest uzasadniona w przypadkach wdrożeń produkcyjnych, gdzie potrzebujesz maksymalnej wydajności sprzętu.

API i integracja

vLLM dostarcza gotowe REST API kompatybilne z OpenAI, co czyni z niego natychmiastową zamianę API OpenAI w istniejących aplikacjach. To jest kluczowe do migracji usług produkcyjnych z dostawców chmurowych na infrastrukturę samodzielnie hostowaną bez zmian w kodzie.

Ollama oferuje prostsze REST API i dedykowane biblioteki Pythona/JavaScript. Choć funkcjonalne, nie jest kompatybilne z formatem OpenAI, wymagając zmian w kodzie przy integracji z aplikacjami oczekującymi formatu OpenAI. Jednak projekt społecznościowe, takie jak Ollama-OpenAI adaptatory, wypełniają tę lukę.

Zarządzanie pamięcią

vLLM algorytm PagedAttention oferuje wyższą wydajność pamięci dla współbieżnych żądań. Może obsługiwać 2–4 razy więcej współbieżnych użytkowników przy tej samej VRAM niż implementacje proste. To bezpośrednio przekłada się na oszczędności kosztów w wdrożeniach produkcyjnych.

Ollama używa prostszego zarządzania pamięcią odpowiedniego dla scenariuszy jednoosobowych. Automatycznie zarządza ładowaniem/wyładowywaniem modelu na podstawie aktywności, co jest wygodne dla rozwoju, ale nie optymalne dla wdrożeń produkcyjnych z wysoką współbieżnością.

Wsparcie wielo-GPU

vLLM wyróżnia się natywną równoległością tensorową i rurkową, efektywnie dystrybuując modele na 2–8+ GPU. To jest niezbędne do serwowania dużych modeli, takich jak LLM z 70B parametrami, które nie mieszczą się w jednym GPU.

Ollama obecnie ma ograniczone wsparcie wielo-GPU, najlepiej działając z jednym GPU. To czyni go mniej odpowiednim dla bardzo dużych modeli wymagających rozproszonego wnioskowania.

Rekomendacje przypadków użycia

Wybierz vLLM, gdy:

• Serwowanie API produkcyjnych z wieloma współbieżnymi użytkownikami
• Optymalizacja kosztów na żądanie w wdrożeniach chmurowych
• Uruchamianie w Kubernetes lub platformach orchestracji kontenerów
• Potrzeba kompatybilności API OpenAI dla istniejących aplikacji
• Serwowanie dużych modeli wymagających wsparcia wielo-GPU
• Wydajność i przepływność są kluczowymi wymaganiami

Wybierz Ollama, gdy:

• Lokalny rozwój i eksperymentowanie
• Interaktywne użycie przez jednego użytkownika (asystenci, chatboty)
• Szybkie prototypowanie i ocena modeli
• Poznawanie LLM bez złożoności infrastruktury
• Uruchamianie na osobistych komputerach stacjonarnych lub laptopach
• Prostota i łatwość użycia są priorytetem

Wiele zespołów używa obu: Ollama do rozwoju i eksperymentów, a następnie vLLM do wdrożeń produkcyjnych. Ta kombinacja zapewnia produktywność programistów, jednocześnie utrzymując wydajność wdrożeń produkcyjnych.

vLLM vs Docker Model Runner

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

Filozofia architektury

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

vLLM to specjalistyczny silnik wnioskowania skupiony wyłącznie na serwowaniu LLM z maksymalną wydajnością. Jest to niższy poziom narzędzia, który kontenerujesz za pomocą Docker, a nie pełnoprawna platforma.

Instalacja i start

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

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

Ta podobieństwo do workflow Docker’a sprawia, że jest od razu znane deweloperom korzystającym z kontenerów.

vLLM wymaga więcej początkowej konfiguracji (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/vll身-8000 --model <model-name>

Właściwości wydajnościowe

vLLM dostarcza lepszą przepływność dla scenariuszy wielu użytkowników dzięki PagedAttention i ciągłemu batchowaniu. Dla usług API produkcyjnych obsługujących setki żądań na sekundę, optymalizacje vLLM zapewniają 2–5 razy lepszą przepływność niż ogólne podejścia do serwowania.

Docker Model Runner skupia się na łatwości użycia zamiast maksymalnej wydajności. Jest odpowiedni do lokalnego rozwoju, testowania i średnich obciążeń, ale nie implementuje zaawansowanych optymalizacji, które sprawiają, że vLLM wyróżnia się przy dużych skalach.

Wsparcie modeli

Docker Model Runner oferuje wyselekcjonowaną bibliotekę modeli z jednowierszowym dostępem do popularnych modeli. Wspiera wiele ram (nie tylko LLM) w tym Stable Diffusion, Whisper i inne modele AI, czyniąc go bardziej uniwersalnym dla różnych obciążeń AI.

vLLM specjalizuje się w wnioskowaniu LLM z głębokim wsparciem dla modeli językowych opartych na transformatorach. Wspiera dowolny LLM kompatybilny z HuggingFace, ale nie rozwija się na inne typy modeli AI, takie jak generowanie obrazów lub rozpoznawanie mowy.

Wdrożenia produkcyjne

vLLM testowany w produkcji przez firmy takie jak Anthropic, Replicate i wiele innych, które obsługują miliardy tokenów dziennie. Jego właściwości wydajnościowe i stabilność przy obciążeniu ciężkim czynią z niego standardowy standard dla serwowania LLM w produkcji.

Docker Model Runner jest nowszy i pozycjonuje się bardziej dla scenariuszy rozwoju i testowania lokalnego. Choć może obsługiwać ruch produkcyjny, brakuje mu udowodnionej historii i optymalizacji wydajności, które wymagają wdrożeń produkcyjnych.

Ekosystem integracji

vLLM integruje się z narzędziami infrastruktury produkcyjnej: operatory Kubernetes, metryki Prometheus, Ray dla rozproszonego serwowania i szerokie kompatybilność API OpenAI dla istniejących aplikacji.

Docker Model Runner integruje się naturalnie z ekosystemem Docker i Docker Desktop. Dla zespołów standardowo opartych na Dockerze, ta integracja oferuje spójne doświadczenie, ale mniej specjalistycznych funkcji serwowania LLM.

Kiedy używać każdego

Użyj vLLM, gdy:

• Usługi API LLM w produkcji
• Wysoka przepływność, wdrożenia wielu użytkowników
• Kosztowe wdrożenia chmurowe wymagające maksymalnej efektywności
• Kubernetes i środowiska chmurowe
• Kiedy potrzebujesz udowodnionej skalowalności i wydajności

Użyj Docker Model Runner, gdy:

• Lokalny rozwój i testowanie
• Uruchamianie różnych typów modeli AI (nie tylko LLM)
• Zespoły intensywnie oparte na Dockerze
• Szybkie eksperymentowanie bez konfiguracji infrastruktury
• Edukacyjne i edukacyjne cele

Hybrydowy podejście: Wiele zespołów rozwija się lokalnie za pomocą Docker Model Runner dla wygody, a następnie wdraża w produkcji za pomocą vLLM 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 wdrażania w produkcji

Wdrażanie w Dockerze

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

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]

Wdrażanie w Kubernetes

Wdrażanie vLLM w Kubernetes dla skalowalności 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 obserwacja

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 - Użycie cache KV
• vllm:time_to_first_token - Metryka opóźnienia
• vllm:time_per_output_token - Prędkość generowania

Optymalizacja wydajności

Optymalizacja użycia pamięci GPU: Zacznij od --gpu-memory-utilization 0.90 i dostosuj na podstawie obserwowanego zachowania. Wyższe wartości pozwalają na większe batchy, ale ryzykują błędy OOM podczas wstrząsów ruchu.

Dostosowanie 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 zwalnia pamięć dla większych batchów. Na przykład, jeśli potrzebujesz tylko 4K kontekstu, ustaw --max-model-len 4096 zamiast używać maksymalnej długości modelu (często 8K–32K).

Wybierz odpowiednie skwantowanie: Dla modeli, które to wspierają, użyj wersji skwantowanych (8-bit, 4-bit), aby zmniejszyć pamięć i zwiększyć przepływność:

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

Włącz pamięć cache dla prefiksów: Dla aplikacji z powtarzającymi się promptami (np. chatboty z systemowymi wiadomościami), włącz cache prefiksów:

--enable-prefix-caching

To cacheuje wartości KV dla wspólnych prefiksów, zmniejszając obliczenia dla żądań dzielących się tym samym prefiksem promptu.

Rozwiązywanie typowych problemów

Błędy braku pamięci

Symptomy: Serwer zawodzi z błędami braku pamięci CUDA.

Rozwiązania:

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

Niska przepływność

Symptomy: 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 margines
• Sprawdź, czy CPU jest ograniczona za pomocą htop – rozważ szybsze CPU
• Potwierdź wykorzystanie GPU za pomocą nvidia-smi – powinno być 95%+
• Włącz FP16, jeśli używasz FP32: --dtype float16

Wolny czas pierwszego tokena

Symptomy: Wysokie opóźnienia przed rozpoczęciem generowania.

Rozwiązania:

• Użyj mniejszych modeli dla aplikacji krytycznych dla opóźnienia
• Włącz cache prefiksów dla powtarzających się promptów
• Zmniejsz --max-num-seqs, aby priorytetować opóźnienie nad przepływnością
• Rozważ dekodowanie spekulacyjne dla obsługiwanych modeli
• Optymalizuj konfigurację równoległości tensorowej

Błędy ładowania modelu

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

Rozwiązania:

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

Zaawansowane funkcje

Spekulacyjne dekodowanie

vLLM obsługuje spekulacyjne dekodowanie, gdzie mniejszy model draft proponuje tokeny, które potwierdza większy model target. Może przyspieszyć generowanie o 1,5–2 razy:

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

Adaptywy LoRA

Serwuj wiele adapterów LoRA na model bazowy 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ć w żądaniu:

response = client.completions.create(
    model="sql-lora",  # Użyj adaptera SQL
    prompt="Przekształć to na SQL: Pokaż wszystkich użytkowników utworzonych w tym miesiącu"
)

Serwowanie wielu LoRA

vLLM’s serwowanie wielu LoRA pozwala na hostowanie dziesiątek adapterów zoptymalizowanych pod kątem pamięci. To jest idealne do serwowania wersji modeli zoptymalizowanych pod kątem klienta lub zadań:

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

Caching prefiksów

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

--enable-prefix-caching

To jest szczególnie skuteczne dla:

• Chatbotów z ustalonymi promptami systemowymi
• Aplikacji RAG z konsystentnymi szablonami kontekstu
• Promptów kilku przykładów powtarzanych w żądaniach

Caching prefiksów może zmniejszyć czas pierwszego tokena o 50–80% dla żądań dzielących się prefiksami promptu.

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("Wyjaśnij PagedAttention w prostych słowach")
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("Co to jest 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}

Przegląd wydajności

Rzeczywiste dane wydajności pomagają ilustrować zalety vLLM:

Porównanie przepływności (Mistral-7B na GPU A100):

• vLLM: ~3500 tokenów/sekunda z 64 współbieżnymi użytkownikami
• HuggingFace Transformers: ~250 tokenów/sekunda przy tej samej współbieżności
• Ollama: ~1200 tokenów/sekundy przy tej samej współbieżności
• Wynik: vLLM dostarcza 14-krotnego poprawienia w porównaniu do podstawowych implementacji

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

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

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

• vLLM: P50 opóźnienie 180 ms, P99 opóźnienie 420 ms przy 100 żądań/s
• Standardowe serwowanie: P50 opóźnienie 650 ms, P99 opóźnienie 3200 ms przy 100 żądań/s
• Wynik: vLLM utrzymuje spójną wydajność pod wysokim obciążeniem

Te testy wydajnościowe pokazują, dlaczego vLLM stał się standardem branżowym dla serwowania LLM w produkcji, gdzie znaczy wydajność.

Analiza kosztów

Zrozumienie konsekwencji kosztowych wyboru vLLM:

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

Z użyciem standardowego serwowania:

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

Z vLLM:

• Wymagane: 2x A100 GPU (80 GB)
• Koszt AWS: ~$8/godzina × 24 × 30 = $5 760/miesiąc
• Koszt na 1 mln tokenów: ~$0,19
• Oszczędności: $17 280/miesiąc (75% zmniejszenie)

To zalety kosztowe rosną z skalą. Organizacje obsługujące miliardy tokenów miesięcznie oszczędzają setki tysięcy dolarów, korzystając z zoptymalizowanego serwowania vLLM zamiast podstawowych implementacji.

Rozważania bezpieczeństwa

Autoryzacja

vLLM nie zawiera autoryzacji domyślnie. Dla produkcji zaimplementuj autoryzację na poziomie odwrotnego 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 takich jak Kong, Traefik lub AWS API Gateway dla autoryzacji i ograniczania przepływu dla firmowych rozwiązań.

Izolacja sieci

Uruchom vLLM w prywatnych sieciach, nie bezpośrednio wystawionych na Internet:

# Przykład polityki sieciowej 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

Ograniczanie przepływu

Zaimplementuj ograniczanie przepływu, aby zapobiec nadużyciu:

# Przykład użycia Redis do ograniczania przepływu
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 sekundowy okres
    if requests > 60:  # 60 żądań na minutę
        raise HTTPException(status_code=429, detail="Przekroczono limit przepływu")
    return await call_next(request)

Kontrola dostępu do modelu

Dla wdrożeń wielodostępnych, kontroluj, którzy użytkownicy mogą uzyskać dostęp do jakich 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

Migrowanie z OpenAI na samodzielnie hostowany vLLM jest proste 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": "Cześć"}]
)

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": "Cześć"}]
)

Wymagane są tylko dwa zmiany: zaktualizuj base_url i nazwę modelu. Reszta kodu pozostaje identyczna.

Z Ollama do vLLM

Ollama korzysta z innego formatu API. Oto konwersja:

API Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': 'Dlaczego niebo jest niebieskie?'
    })

Równoważna wersja 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="Dlaczego niebo jest niebieskie?"
)

Musisz zaktualizować wywołania API w całym kodzie, ale biblioteki klienta OpenAI oferują lepsze zarządzanie błędami i funkcje.

Z HuggingFace Transformers do vLLM

Migrowanie bezpośredniego użycia Pythona:

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("Cześć", 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("Cześć", sampling_params)
result = outputs[0].outputs[0].text

API Pythona vLLM jest prostsze i znacznie szybsze do wnioskowania w batchu.

Przyszłość vLLM

vLLM nadal rozwija się dynamicznie z ciekawymi funkcjami na trasie:

Rozdzielone serwowanie: Oddzielanie prefill (przetwarzanie promptów) i dekodowania (generowanie tokenów) na różne GPU, aby zoptymalizować wykorzystanie zasobów. Prefill jest obliczeniowo ograniczony, a dekodowanie jest ograniczone pamięciowo, więc uruchamianie ich na specjalistycznym sprzęcie poprawia wydajność.

Serwowanie wielu węzłów: Dystrybuowanie bardzo dużych modeli (100B+ parametrów) na wiele maszyn, umożliwiając serwowanie modeli, które nie mieszczą się w konfiguracjach jednowęzłowych.

Zwiększone skwantowanie: Wsparcie dla nowych formatów skwantowania, takich jak GGUF (używany przez llama.cpp) i poprawiona integracja AWQ/GPTQ dla lepszej wydajności modeli skwantowanych.

Poprawy dekodowania spekulacyjnego: Bardziej efektywne modele draft i adaptacyjne strategie spekulacji, aby osiągnąć wyższe przyspieszenie bez utraty dokładności.

Optymalizacje uwagi: FlashAttention 3, uwaga kołowa dla bardzo długich kontekstów (100K+ tokenów) i inne najnowsze mechanizmy uwagi.

Lepsze wsparcie modeli: Rozszerzenie wsparcia do modeli multimodalnych (modeli językowo-wizualnych), modeli audio i specjalistycznych architektur, gdy pojawią się.

Projekt vLLM utrzymuje aktywne rozwijanie z udziałem UC Berkeley, Anyscale i szerokiej społeczności open source. Gdy wdrażanie LLM staje się coraz bardziej krytyczne dla systemów produkcyjnych, rola vLLM jako standardu wydajności kontynuuje się rosnąć. Dla szerszego porównania vLLM z innymi lokalnymi i chmurowymi infrastrukturami LLM, sprawdź nasz Hostowanie LLM: lokalne, samodzielne i infrastruktura chmurowa porównane.

Przydatne linki

Powiązane artykuły na tym serwerze

• Lokalne hostowanie LLM: Kompletny przewodnik 2026 – Ollama, vLLM, LocalAI, Jan, LM Studio & więcej – Kompletny przegląd 12+ narzędzi do lokalnego hostowania LLM, w tym szczegółowa analiza vLLM wraz z Ollama, LocalAI, Jan, LM Studio i innymi. Porównuje dojrzałość API, wsparcie wywoływania narzędzi, kompatybilność GGUF i wyniki testów wydajności, aby pomóc wybrać odpowiednie rozwiązanie.

• Ollama: Przewodnik po komendach – Kompletny przewodnik po komendach Ollama i najlepszych praktykach wdrażania lokalnych LLM, obejmujący instalację, zarządzanie modelami, użycie API i najlepsze praktyki. Niezwykle przydatny dla deweloperów korzystających z Ollama wraz z vLLM lub zamiast niego.

• Docker Model Runner vs Ollama: Który wybrać? – Szczegółowe porównanie Model Runnera od Dockera i Ollama w kontekście lokalnego hostowania LLM, analizujące wydajność, wsparcie GPU, kompatybilność API i przypadki użycia. Pomaga zrozumieć konkurencyjny klimat, w którym działa vLLM.

• Docker Model Runner: Przewodnik po komendach i przykładach – Praktyczny przewodnik po komendach i przykładach dla Docker Model Runnera wdrażania modeli AI. Przydatny dla zespołów porównujących podejście Dockera z specjalistycznymi możliwościami serwowania LLM od vLLM.

Zewnętrzne zasoby i dokumentacja

• Repozytorium vLLM na GitHub – Oficjalne repozytorium vLLM z kodem źródłowym, kompleksową dokumentacją, przewodnikami instalacyjnymi i aktywnymi dyskusjami społecznościowymi. Niezwykle ważny zasób do utrzymania się na bieżąco z najnowszymi funkcjami i rozwiązywania problemów.

• Dokumentacja vLLM – Oficjalna dokumentacja obejmująca wszystkie aspekty vLLM, od podstawowej konfiguracji po zaawansowane ustawienia. Zawiera referencje API, przewodniki dotyczące optymalizacji wydajności i najlepsze praktyki wdrażania.

• Artykuł PagedAttention – Akademicki artykuł przedstawiający algorytm PagedAttention, który stanowi podstawę wydajności vLLM. Niezwykle istotna lektura do zrozumienia technicznych innowacji, które zapewniają przewagę wydajności vLLM.

• Blog vLLM – Oficjalny blog vLLM z ogłoszeniami o nowych wersjach, wynikami testów, głębszymi analizami technicznymi i przypadkami użycia z wdrożeń produkcyjnych społeczności.

• Repozytorium modeli HuggingFace – Kompleksowa kolekcja modeli LLM open source kompatybilnych z vLLM. Szukaj modeli według wielkości, zadania, licencji i cech wydajnościowych, aby znaleźć odpowiedni model do Twojego przypadku użycia.

• Dokumentacja Ray Serve – Dokumentacja frameworka Ray Serve do tworzenia skalowalnych, rozproszonych wdrożeń vLLM. Ray oferuje zaawansowane funkcje, takie jak automatyczne skalowanie, serwowanie wielu modeli i zarządzanie zasobami dla systemów produkcyjnych.

• TensorRT-LLM od NVIDIA – TensorRT-LLM od NVIDIA do bardzo optymalizowanego wnioskowania na GPU NVIDIA. Alternatywa dla vLLM z innymi strategiami optymalizacji, przydatna do porównania i zrozumienia krajobrazu optymalizacji wnioskowania.

• Dokumentacja API OpenAI – Oficjalna dokumentacja API OpenAI, z którą API vLLM jest kompatybilne. Użyj jej jako odniesienia przy budowaniu aplikacji, które mają działać zarówno z OpenAI, jak i z lokalnymi punktami końcowymi vLLM.