Szybki start z vLLM: Wysokowydajne obsługiwanie modeli językowych (LLM) – 2026

Szybka inferencja LLM z użyciem API OpenAI

Page content

vLLM to wysokiej wydajności, pamięciowo efektywny silnik wnioskowania i serwowania dla dużych modeli językowych (LLM), opracowany przez Sky Computing Lab z UC Berkeley.

Z jego rewolucyjnym algorytmem PagedAttention, vLLM osiąga wydajność 14–24 razy wyższą niż tradycyjne metody serwowania, stając się najlepszym wyborem do wdrożeń LLM w środowisku produkcyjnym.

vllm logo

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 w przypadkach wdrożeń produkcyjnych. Wprowadzona w 2023 roku, wprowadziła PagedAttention, innowacyjną technikę zarządzania pamięcią, która znacząco poprawia wydajność serwowania.

Kluczowe funkcje

Wysoka wydajność: vLLM dostarcza wydajność 14–24 razy większą w porównaniu do HuggingFace Transformers przy tym samym sprzęcie. Duży 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. Pozwala to na płynne przenoszenie się z OpenAI na infrastrukturę własną bez zmiany kodu aplikacji. Wystarczy ustawić klienta API na punkt końcowy vLLM, a działa on przezroczysto.

Algorytm PagedAttention: Jądro innowacji za wydajność vLLM to PagedAttention, który stosuje 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 do 4 razy i umożliwia znacznie większe rozmiary batcha.

Ciągłe batchowanie: W przeciwieństwie do statycznego batchowania, gdzie czekasz, aż wszystkie sekwencje zostaną ukończone, vLLM korzysta z ciągłego (rolującego) batchowania. Z chwili, gdy jedna sekwencja zostaje ukończona, można natychmiast dodać nową do batcha. To maksymalizuje wykorzystanie GPU i minimalizuje opóźnienia dla przychodzących żądań.

Wsparcie wielo-GPU: vLLM obsługuje tensorowe i rurkowe parallelizm do dystrybucji dużych modeli na wiele GPU. Może efektywnie serwować modele, które nie mieszczą się w pamięci jednego GPU, wspierając konfiguracje od 2 do 8+ GPU.

Szeroka obsługa modeli: Kompatybilny z popularnymi architekturami modeli, w tym LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma i wieloma innymi. Wspiera zarówno modele wytrenowane w sposób instrukcyjny, jak i bazowe modele z HuggingFace Hub.

Kiedy używać vLLM

vLLM świetnie sprawdza się w konkretnych scenariuszach, w których jego zalety są najbardziej widoczne:

Usługi API produkcyjne: Kiedy potrzebujesz serwowania LLM wielu współbieżnym użytkownikom przez API, wysoka wydajność i efektywne batchowanie vLLM sprawiają, że jest najlepszym wyborem. 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ę.

Wysoka współbieżność: Jeśli Twoja aplikacja ma wiele współbieżnych użytkowników wysyłających żądania, ciągłe batchowanie i PagedAttention w vLLM pozwalają serwować więcej użytkowników przy tym samym sprzęcie niż inne opcje.

Optymalizacja kosztów: Kiedy koszty GPU są kwestią, wyższa wydajność vLLM oznacza, że możesz obsłużyć ten sam ruch przy mniejszej liczbie GPU, bezpośrednio obniżając koszty infrastruktury. 4-krotnie większa efektywność pamięci z PagedAttention pozwala również używać mniejszych, tańszych instancji GPU.

Wdrożenia w Kubernetes: Bezstanowa architektura i przyjazne konteneryzowane wdrożenia vLLM sprawiają, że są idealne do klastrów Kubernetes. Jego spójna wydajność przy obciążeniu i prostota zarządzania zasobami dobrze łączą się z infrastrukturą natywnej chmury.

Kiedy NIE używać vLLM: Dla rozwoju lokalnego, eksperymentów lub scenariuszy jednoosobowych, narzędzia takie jak Ollama oferują lepsze doświadczenie użytkownika z prostszym ustawieniem. Złożoność vLLM jest uzasadniona, gdy potrzebujesz jego zalet 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: NVIDIA GPU 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 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 innymi wersjami CUDA zainstaluj odpowiednie koło:

# 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, szczególnie 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 odpowiednią komunikację międzyprocesową.

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 .

Szybki start z vLLM

Uruchamianie pierwszego modelu

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

# 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 pobra model z HuggingFace Hub (jeśli nie jest jeszcze w pamięci podręcznej) i uruchomi serwer. Widzisz wyprowadzone informacje 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

Wysyłanie żądań API

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

Używając 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 tensorowym parallelizmem
    --dtype float16 \                 # Użyj precyzji FP16
    --max-num-seqs 256                # Maksymalna liczba sekwencji

Wyjaśnienie kluczowych parametrów:

  • --gpu-memory-utilization: Jaką część pamięci GPU ma być używana (0.90 = 90%). Wysokie wartości pozwalają na większe batchy, ale pozostawiają mniejszy margines na wstrząsy pamięci.
  • --max-model-len: Maksymalna długość kontekstu. Zmniejszenie tej wartości oszczędza pamięć dla większych batchów.
  • --tensor-parallel-size: Liczba GPU, na które ma zostać podzielony model.
  • --dtype: Typ danych dla wag (float16, bfloat16 lub float32). FP16 jest zwykle 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 przepustowość

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

Ollama optymalizuje się pod kątem interaktywnego użytkowania przez jednego użytkownika, koncentrując się na niskim opóźnieniu dla pojedynczych żądań. Choć nie dorównuje vLLM pod względem przepustowości wielu użytkowników, oferuje świetną wydajność w przypadku rozwoju i użycia osobistego z szybszymi czasami startu i mniejszym zużyciem zasobów w stanie bezczynności.

Łatwość użycia

Ollama wygrywa decydująco pod względem prostoty. Instalacja to jedno polecenie (curl | sh), a uruchamianie modeli to tyle, co ollama run llama2. Zawiera bibliotekę modeli z wersjami kwantyzowanymi zoptymalizowanymi dla różnych profili sprzętu. Doświadczenie użytkownika przypomina Docker – pobierz, uruchom i gotowe.

vLLM wymaga większej ilości konfiguracji: zarządzania środowiskiem Pythona, instalacji CUDA, zrozumienia parametrów serwowania i ręcznego określenia modelu. Krzywa uczenia się jest steeper, ale otrzymujesz drobne kontrolowanie nad optymalizacją wydajności. Ta złożoność jest uzasadniona, gdy potrzebujesz maksymalnej wydajności sprzętu w wdrożeniach produkcyjnych.

API i integracja

vLLM oferuje gotowe REST API kompatybilne z OpenAI, co czyni go łatwym do wdrożenia w istniejących aplikacjach zamiast API OpenAI. Jest to kluczowe dla migracji usług produkcyjnych z dostawców chmurowych na infrastrukturę własną bez zmian w kodzie.

Ollama oferuje prostsze REST API i dedykowaną bibliotekę Pythona/JavaScript. Choć funkcjonalne, nie jest kompatybilne z formatem OpenAI, co wymaga zmian w kodzie przy integracji z aplikacjami oczekującymi na format OpenAI. Jednak projekt społecznościowy takie jak Ollama-OpenAI adaptery uzupełniają tę lukę.

Zarządzanie pamięcią

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

Ollama korzysta z prostszego zarządzania pamięcią odpowiedniego dla scenariuszy jednoosobowych. Automatycznie zarządza ładowaniem i wyładowywaniem modeli na podstawie aktywności, co jest wygodne do rozwoju, ale nie optymalne do wyższej współbieżności w wdrożeniach produkcyjnych.

Wsparcie wielo-GPU

vLLM wyróżnia się natywnym tensorowym i rurkowym parallelizmem, efektywnie dystrybuując modele na 2–8+ GPU. Jest to niezbędne do serwowania dużych modeli, takich jak LLM z 70B parametrami, które nie mieszczą się w pamięci jednego GPU.

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

Rekomendacje do 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 z API OpenAI dla istniejących aplikacji
  • Serwowanie dużych modeli wymagających wsparcia wielo-GPU
  • Wydajność i przepustowość są kluczowymi wymaganiami

Wybierz Ollama, gdy:

  • Rozwój lokalny i eksperymenty
  • 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 stacjach roboczych lub laptopach
  • Prostota i łatwość użycia są priorytetami

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

Porównanie vLLM z 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 być “Dockerem dla AI” – prostym, standaryzowanym sposobem na uruchamianie modeli AI lokalnie z tą samą łatwością, jak uruchamianie kontenerów. Abstrahuje skomplikowane elementy i oferuje spójny interfejs dla różnych modeli i frameworków.

vLLM to specjalistyczny silnik wnioskowania skupiony wyłącznie na serwowaniu LLM z maksymalną wydajnością. Jest to narzędzie niższego poziomu, które konteneryzujesz za pomocą Docker, zamiast pełnej platformy.

Ustawianie i rozpoczęcie pracy

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 przepływu pracy obrazów Docker czyni to natychmiast znane deweloperom korzystającym z kontenerów.

vLLM wymaga większej ilości 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/vllm-openai:latest --model <model-name>

Charakterystyka wydajności

vLLM dostarcza wyższą przepustowość w scenariuszach 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 większą przepustowość niż ogólne metody serwowania.

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

Wsparcie modeli

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

vLLM specjalizuje się w wnioskowaniu LLM z głęboką obsługą modeli językowych opartych na transformatorach. Obsługuje każdy LLM kompatybilny z HuggingFace, ale nie rozbudowuje się do innych typów modeli AI, takich jak generowanie obrazów lub rozpoznawanie mowy.

Wdrożenia produkcyjne

vLLM został testowany w środowisku produkcyjnym w firmach takich jak Anthropic, Replicate i wielu innych, obsługujących miliardy tokenów dziennie. Jego charakterystyka wydajności i stabilność przy obciążeniu ciężkim czynią z niego standard dla serwowania LLM w środowisku produkcyjnym.

Docker Model Runner jest nowszy i pozycjonuje się bardziej dla scenariuszy rozwoju i testowania lokalnego. Choć mógłby obsłużyć ruch produkcyjny, brakuje mu udowodnionej historii i optymalizacji wydajności, które są konieczne do wdrożeń produkcyjnych.

Ekosystem integracji

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

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

Kiedy używać każdego

Użyj vLLM, gdy:

  • Serwowanie API LLM produkcyjnych
  • Wysoka przepustowość, wdrożenia wielu użytkowników
  • Kosztowne wdrożenia chmurowe potrzebujące maksymalnej efektywności
  • Kubernetes i środowiska natywne chmurowe
  • Kiedy potrzebujesz udowodnionej skalowalności i wydajności

Użyj Docker Model Runner, gdy:

  • Rozwój lokalny i testowanie
  • Uruchamianie różnych typów modeli AI (nie tylko LLM)
  • Zespoły intensywnie zstandardowane na ekosystem Docker
  • Szybkie eksperymentowanie bez konfiguracji infrastruktury
  • Cel edukacyjny i naukowy

Zhybrydowy podejście: Wiele zespołów rozwija się lokalnie z Docker Model Runner dla wygody, a następnie wdraża z vLLM w środowisku produkcyjnym 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 środowisku produkcyjnym

Wdrażanie w Dockerze

Utwórz konfigurację Docker Compose gotową do wdrożenia w środowisku produkcyjnym:

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 w środowisku produkcyjnym:

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 - Użycie pamięci cache GPU
  • vllm:time_to_first_token - Metryka opóźnienia
  • vllm:time_per_output_token - Szybkość generowania

Optymalizacja wydajności

Optymalizacja wykorzystania pamięci GPU: Zaczynaj od --gpu-memory-utilization 0.90 i dostosuj na podstawie obserwowanego zachowania. Wysokie 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 scenariusz 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żywania maksymalnej długości modelu (zwykle 8K–32K).

Wybierz odpowiednią kwantyzację: Dla modeli, które to wspierają, użyj wersji kwantyzowanych (8-bit, 4-bit), aby zmniejszyć pamięć i zwiększyć przepustowość:

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

Włącz cache prefiksów: Dla aplikacji z powtarzającymi się wskazówkami (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ń udostępniających ten sam prefiks wskazówki.

Rozwiązywanie typowych problemów

Błędy braku pamięci

Symptomy: Serwer zawiesza się 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 scenariusz to pozwala
  • Zmniejsz --max-num-seqs, aby zmniejszyć rozmiar batcha
  • Użyj wersji modelu kwantyzowanej
  • Włącz tensorowy parallelizm, aby rozdzielić na więcej GPU

Niska przepustowość

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

Rozwiązania:

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

Wolne pierwsze tokeny

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

Rozwiązania:

  • Użyj mniejszych modeli dla aplikacji krytycznych pod względem opóźnienia
  • Włącz cache prefiksów dla powtarzających się wskazówek
  • Zmniejsz --max-num-seqs, aby priorytetyzować opóźnienie nad przepustowością
  • Rozważ dekodowanie spekulacyjne dla wspieranych modeli
  • Optymalizuj konfigurację tensorowego parallelizmu

Błędy ładowania modelu

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

Rozwiązania:

  • Zweryfikuj, czy nazwa modelu dokładnie odpowiada formatowi HuggingFace
  • Zweryfikuj połączenie sieciowe z HuggingFace Hub
  • Upewnij się, że jest wystarczająco dużo miejsca na dysku w ~/.cache/huggingface
  • Dla modeli z ograniczeniem dostępu, 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 są weryfikowane przez większy model target. Może to 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

Adapter LoRA

Serwowanie wielu adapterów LoRA na podstawie modelu 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żywany na żądanie:

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

Serwowanie wielu LoRA

vLLM’s multi-LoRA serwowanie pozwala na hostowanie dziesiątek dopasowanych adapterów z minimalnym nakładem pamięci. Jest to idealne do serwowania wersji modeli dopasowanych do konkretnych 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": "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 wskazówek:

--enable-prefix-caching

To jest szczególnie skuteczne dla:

  • Chatbotów z ustalonymi wskazówkami systemowymi
  • Aplikacji RAG z konserwatywnymi szablonami kontekstu
  • Wskazówek few-shot powtarzanych w żądaniach

Caching prefiksów może zmniejszyć czas do pierwszego tokena o 50–80% dla żądań udostępniających prefiksy wskazówek.

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

Dane z rzeczywistego świata pomagają ilustrować zalety vLLM:

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

  • vLLM: ~3500 tokenów/sekunda z 64 współbieżnymi użytkownikami
  • HuggingFace Transformers: ~250 tokenów/sekunda z tą samą współbieżnością
  • Ollama: ~1200 tokenów/sekundy z tą samą współbieżnością
  • Wynik: vLLM dostarcza 14-krotnie lepszą wydajność niż podstawowe implementacje

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 przy obciążeniu (Mixtral-8x7B na 2xA100):

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

Te testy pokazują, dlaczego vLLM stał się standardem de facto dla serwowania LLM w środowisku produkcyjnym, 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 dolary/godzina × 24 × 30 = 23 040 dolarów/miesiąc
  • Koszt na 1 mln tokenów: ~0,75 dolara

Z użyciem vLLM:

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

Ta zaleta kosztowa rośnie wraz 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

Uwierzytelnienie

vLLM nie zawiera uwierzytelnienia domyślnie. Dla środowiska produkcyjnego, zaimplementuj uwierzytelnienie 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 zaawansowanego uwierzytelnienia i ograniczania przepustowości.

Izolacja sieciowa

Uruchamiaj 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 przepustowości

Zaimplementuj ograniczanie przepustowości, aby zapobiec nadużyciu:

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

Kontrola dostępu do modeli

Dla wdrożeń wielu użytkowników, 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 samodzielne vLLM jest prosty 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ś uwierzytelnienie
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Cześć"}]
)

Tylko dwa zmiany są konieczne: aktualizacja base_url i nazwy modelu. Wszystki inny kod pozostaje identyczny.

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?'
    })

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="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 dla wnioskowania w batchach.

Przyszłość vLLM

vLLM kontynuuje szybki rozwój z ciekawymi funkcjami na planie:

Rozdzielone serwowanie: Oddzielanie prefill (przetwarzanie wskazówek) i decode (generowanie tokenów) na różne GPU, aby zoptymalizować wykorzystanie zasobów. Prefill jest obciążeniem obliczeniowym, a decode jest obciążeniem pamięciowym, więc uruchamianie ich na specjalistycznym sprzęcie poprawia wydajność.

Serwowanie wielo-nodowe: Dystrybucja bardzo dużych modeli (100B+ parametrów) na wiele maszyn, umożliwiając serwowanie modeli zbyt dużych dla konfiguracji jedno-nodowych.

Zwiększone kwantyzacje: Wsparcie dla nowych formatów kwantyzacji, takich jak GGUF (używany przez llama.cpp) i poprawiona integracja AWQ/GPTQ dla lepszej wydajności z modelami kwantyzowanymi.

Ulepszenia dekodowania spekulacyjnego: Bardziej efektywne modele draft i adaptacyjne strategie spekulacji, aby osiągnąć większy przyrost prędkości bez utraty dokładności.

Optymalizacje uwagi: FlashAttention 3, uwaga w formie pierścienia 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-visualnych), modeli audio i specjalistycznych architektur, gdy pojawią się.

Projekt vLLM utrzymuje aktywny rozwój z udziałem UC Berkeley, Anyscale i szerszej społeczności open source. W miarę, jak wdrażanie LLM staje się coraz bardziej krytyczne dla systemów produkcyjnych, rola vLLM jako standardu wydajności kontynuuje się rosnąć.

Przydatne linki

Powiązane artykuły na tym serwisie

  • Lokalne hostowanie LLM: kompletny przewodnik 2026 – Ollama, vLLM, LocalAI, Jan, LM Studio i inne – Kompletny porówanie 12+ narzędzi do lokalnego hostowania LLM, w tym szczegółowa analiza vLLM wraz z Ollama, LocalAI, Jan, LM Studio i innymi. Obejmuje dojrzałość API, wsparcie wywoływania narzędzi, kompatybilność GGUF i testy wydajności, które pomogą wybrać odpowiednie rozwiązanie.

  • Ollama – cheat sheet – Kompletny przewodnik po komendach Ollama i cheat sheet, obejmujący instalację, zarządzanie modelami, wykorzystanie API oraz najlepsze praktyki wdrażania lokalnych LLM. Niezwykle przydatny dla deweloperów korzystających z Ollama, a także zamiast vLLM.

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

  • Cheat sheet Docker Model Runner: komendy i przykłady – Praktyczny cheat sheet Docker Model Runner z komendami i przykładami 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. Kluczowy zasób pozwalający na utrzymanie się na bieżąco z najnowszymi funkcjami i rozwiązywanie problemów.

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

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

  • Blog vLLM – Oficjalny blog vLLM, zawierający ogłoszenia o nowych wersjach, testy wydajności, głębsze analizy techniczne oraz przypadki użycia z wdrożeń produkcyjnych społeczności.

  • HuggingFace Model Hub – Kompleksowa repozytorium modeli open source kompatybilnych z vLLM. Możesz wyszukiwać modele według rozmiaru, zadania, licencji i cech wydajnościowych, aby znaleźć odpowiedni model do swojego przypadku użycia.

  • Dokumentacja Ray Serve – Dokumentacja ramki 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.

  • NVIDIA TensorRT-LLM – Biblioteka TensorRT-LLM od NVIDIA, zaprojektowana do bardzo wydajnego wnioskowania na GPU od NVIDIA. Alternatywa dla vLLM z innymi strategiami optymalizacji, przydatna do porównań i zrozumienia krajobrazu optymalizacji wnioskowania.

  • Dokumentacja API OpenAI – Oficjalna dokumentacja API OpenAI, z którą API vLLM jest kompatybilne. Skorzystaj z niej, tworząc aplikacje, które będą pracować zarówno z OpenAI, jak i z lokalnymi punktami końcowymi vLLM.