vLLM (Wysokowydajny silnik inferencyjny)

1. Przegląd koncepcji i problem systemowy

Tradycyjne biblioteki głębokiego uczenia (czysty PyTorch lub Hugging Face Transformers) były projektowane z myślą o badaniach, a nie o środowiskach produkcyjnych o wysokim obciążeniu. Próba jednoczesnej obsługi dziesiątek użytkowników prowadzi do katastrofalnego marnowania zasobów pamięci wideo:

• Nieprzerwana statyczna alokacja: aby przetworzyć żądanie, framework przydziela ciągły blok VRAM dla maksymalnej długości okna (np. 8 192 tokeny), nawet jeśli użytkownik zadał pytanie składające się z trzech słów.
• Fragmentacja wewnętrzna i zewnętrzna: ponad 60–80% niezwykle drogiej pamięci kart A100/H100 pozostaje puste, zablokowane „na wszelki wypadek”.
• Blokujący batching: jeśli jedno żądanie wymaga wygenerowania 10 tokenów, a sąsiednie – 2000, pierwsze musi czekać na zakończenie bloku obliczeniowego drugiego.

vLLM (opracowany w laboratorium LMSYS / UC Berkeley) rozwiązał ten problem raz na zawsze. Dzięki algorytmowi PagedAttention oraz iteracyjnemu ciągłemu planowaniu, vLLM stał się przemysłowym standardem self-hostingu modeli językowych, pozwalając wycisnąć maksymalną przepustowość z każdego akceleratora graficznego.

2. Taksonomia architektoniczna i model mentalny

Stos architektoniczny vLLM opiera się na optymalizacji dostępu do pamięci i wielowątkowości:

┌─────────────────────────────────────────────────────────────┐
│                    ARCHITEKTURA SILNIKA vLLM                │
├─────────────────────────────────────────────────────────────┤
│ 1. Warstwa frontendu asynchronicznego:                      │
│    • Serwer HTTP zgodny z OpenAI (FastAPI / Uvicorn)        │
│    • Menedżer odpowiedzi strumieniowych (Server-Sent Events)│
├─────────────────────────────────────────────────────────────┤
│ 2. Scheduler ciągłego batchowania:                          │
│    • Planowanie na poziomie iteracji (bez statycznych       │
│      przerw w batchowaniu)                                  │
│    • Automatyczne buforowanie prefiksów promptów            │
│      (współdzielenie KV-Cache)                              │
├─────────────────────────────────────────────────────────────┤
│ 3. Podsystem pamięci (Silnik PagedAttention):               │
│    • Pula bloków fizycznych                                 │
│      (Strony pamięci po 16 tokenów)                         │
│    • Tablica bloków                                         │
│      (Mapowanie logicznych i fizycznych bloków)             │
├─────────────────────────────────────────────────────────────┤
│ 4. Podsystem obliczeniowy: Własne jądra CUDA / ROCm, FP8,   │
│    TP                                                       │
└─────────────────────────────────────────────────────────────┘

1. Silnik PagedAttention:
   • Dzieli cache KV sekwencji na małe strony o stałym rozmiarze (zazwyczaj 16 lub 32 tokeny).
   • Fizyczne strony mogą być rozmieszczone w dowolnym miejscu VRAM bez konieczności bycia sąsiadującymi, co całkowicie eliminuje fragmentację zewnętrzną.
2. Ciągły batching (Continuous Batching):
   • Obliczenia są planowane na poziomie pojedynczej iteracji generowania tokenu. Gdy tylko żądanie zakończy odpowiedź, jego strony są natychmiast zwalniane, a na ich miejsce wskakuje nowe żądanie z kolejki.
3. Automatyczne cache’owanie prefiksów (Automatic Prefix Caching - APC):
   • Jeśli setki żądań zaczynają się od tego samego promptu systemowego lub tych samych plików kodu, vLLM zachowuje te strony cache i współdzieli je między różnymi użytkownikami przy zerowych kosztach obliczeniowych.
4. Rozproszony równoległość (Distributed Execution):
   • Obsługa Tensor Parallelism (TP) oraz Pipeline Parallelism (PP) bazująca na protokołach NCCL, umożliwiająca bezproblemowe dzielenie modelu między 2, 4 lub 8 kartami graficznymi.

3. Techniczny pipeline i mechanika wewnętrzna

Cykl życia przetwarzania żądania przez serwer vLLM:

1. Przyjęcie żądania przez OpenAI API: Klient wysyła żądanie POST na /v1/chat/completions.
2. Tokenizacja i sprawdzenie obecności prefiksu: Tokenizer dzieli tekst na identyfikatory. Dyspozytor pamięci sprawdza hash pierwszych tokenów: jeśli prompt systemowy został już załadowany do cache’a Paged przez innego użytkownika, te strony nie są przeliczane ponownie (Cache Hit).
3. Alokacja fizycznych stron pamięci: Menedżer bloków przydziela dokładnie tyle stron po 16 tokenów, ile jest potrzebnych do przechowania kontekstu wejściowego.
4. Iteracyjny krok generacji (Model Forward Step): Niemożliwe do zastąpienia, wysoko zoptymalizowane kernele CUDA odczytują sfragmentowane strony cache’a KV równolegle i wykonują obliczenie następnego tokenu.
5. Streaming i dynamiczna alokacja pamięci: Wygenerowany token jest natychmiast wysyłany do klienta przez SSE. Jeśli bieżąca strona zostanie wypełniona, menedżer bloków przydziela dokładnie jedną nową stronę na 16 tokenów z puli.
6. Czyszczenie zasobów: Po pojawieniu się tokenu końcowego lub zerwaniu połączenia przez klienta, wszystkie przydzielone strony są natychmiast zwracane do puli wolnej pamięci.

4. Praktyczne scenariusze inżynierskie w produkcji

01. Wdrożenie korporacyjnego klastra AI dla 500 pracowników

Firma buduje wewnętrzną usługę wspomagającą deweloperów:

• Serwer z 4 kartami NVIDIA A100 (80GB).
• Uruchomienie komendy:

  vllm serve Qwen/Qwen2.5-Coder-32B-Instruct --tensor-parallel-size 4 --enable-prefix-caching
  

• Serwer obsługuje jednoczesną pracę setek inżynierów w Cursor i VS Code z opóźnieniem pierwszego tokenu mniejszym niż 100 ms.

02. System RAG o wysokim obciążeniu z milionowym strumieniem dokumentów

Indeksowanie wsadowe i interaktywne wyszukiwanie w bazie wiedzy:

• Dzięki Continuous Batching serwer równolegle przetwarza 128 żądań użytkowników, osiągając łączną przepustowość powyżej 3 500 tokenów na sekundę na węzeł.

03. Wymuszona strukturalna generacja JSON (Guided Decoding)

Usługa wymaga absolutnej zgodności ze złożonym schematem Zod:

• vLLM integruje silniki gramatyki syntaktycznej (Outlines / Guidance).
• Na poziomie logitów maskowane są wszystkie tokeny naruszające reguły składni JSON, gwarantując 100% ważność odpowiedzi bez błędów parsera.

5. Pułapki, typowe błędy i bezpieczeństwo

• Błędy OOM przez gpu_memory_utilization: Domyślnie vLLM rezerwuje 90% dostępnej pamięci na cache. Jeśli uruchomimy równolegle inny proces lub ustawimy współczynnik 0.98, skok aktywacji podczas długiego prefillu doprowadzi do awarii procesu z błędem CUDA Out of Memory.
• Brak wbudowanej autentykacji: vLLM był tworzony jako silnik obliczeniowy. Uruchomienie go bezpośrednio w publicznym internecie bez zewnętrznego reverse proxy (Nginx/Caddy) i walidacji kluczy API otwiera niekontrolowany dostęp do Twoich GPU.
• Wrażliwość przy niepoprawnym zatrzymywaniu procesów (Zombie Processes): Przy użyciu tensor parallelism awaryjne zakończenie głównego procesu Python może zostawić procesy potomne NCCL zablokowane w pamięci wideo. Należy czyścić pozostałości za pomocą pkill -f vllm.
• Wysoka wrażliwość na wersje sterowników CUDA: vLLM wykorzystuje ekstremalnie zoptymalizowane, skompilowane jądra C++/CUDA. Niezgodność między wersją PyTorch, sterownikiem NVIDIA a wersją CUDA Toolkit może spowodować błędy kompilacji podczas startu.