Gdy klient pyta „jaki GPU do lokalnego LLM", zazwyczaj ma na myśli jedno pytanie: czy zmieści mi się model, którego chcę używać? Odpowiedź zależy od trzech liczb — rozmiar wag modelu, rozmiar KV cache przy danym kontekście oraz overhead frameworku. Wszystkie trzy da się wyliczyć z góry. Mimo to większość decyzji sprzętowych zapada na podstawie przybliżeń, a wynikiem jest albo zbędnie drogi serwer, albo serwer, który nie nadąża.
Ten artykuł podaje konkretne liczby: ile VRAM realnie zajmie model 7B, 13B, 34B i 70B przy różnych formatach kwantyzacji, co zmieści się na karcie 24 GB / 48 GB / 80 GB i kiedy warto przejść na multi-GPU.
Podstawowy wzór: wagi modelu
Najprostsze oszacowanie VRAM dla samych wag:
VRAM (GB) ≈ (liczba parametrów w miliardach × liczba bitów) / 8Przykłady: - Model 7B, FP16 (16 bitów): 7 × 16 / 8 = 14 GB (w praktyce z overhead-em ~16–18 GB) - Model 7B, Q4_K_M (4 bity): 7 × 4 / 8 = 3,5 GB — w praktyce ze względu na overhead około 5–7 GB - Model 70B, FP16: 70 × 16 / 8 = 140 GB - Model 70B, Q4_K_M: 70 × 4 / 8 = 35 GB — w praktyce około 38–40 GB
Wzór na wagi to tylko punkt wyjścia. Do tego zawsze dochodzi KV cache, overhead frameworku servingowego, a w przypadku kwantyzacji również bufory dequantyzacji.
Czym jest KV cache i dlaczego jest ważny
Podczas inferencji model generuje tokeny jeden po drugim. Aby nie przeliczać całej sekwencji dla każdego nowego tokenu, przechowuje wyniki pośrednie — tzw. pary klucz-wartość dla każdej warstwy uwagi (attention layer). Te wyniki pośrednie tworzą KV cache.
KV cache rośnie liniowo wraz z długością sekwencji. W środowisku produkcyjnym z równoległymi żądaniami szybko staje się tak samo poważnym problemem jak same wagi.
Orientacyjne rozmiary KV cache dla typowych modeli:
- Model 7B, kontekst 8K, 1 równoległe żądanie: ~1–2 GB
- Model 7B, kontekst 32K, 4 równoległe żądania: ~8–16 GB
- Model 70B, kontekst 32K, 1 żądanie: ~8–12 GB
- Model 70B, kontekst 128K, 1 żądanie: ~40 GB
Liczby zależą od liczby warstw uwagi, liczby głowic i grup (nowoczesne modele stosują Grouped Query Attention, GQA, które dramatically zmniejsza KV cache w porównaniu ze starszym multi-head attention). Każdy model ma inny mnożnik — sprawdź plik konfiguracyjny modelu (config.json w repozytorium HuggingFace) przed wyborem sprzętu.
Praktyczna konsekwencja: jeśli planujesz długie konteksty lub większą liczbę równoczesnych użytkowników, KV cache decyduje w równym stopniu co wagi. To nie jest techniczny szczegół — to główna przyczyna błędów OOM podczas wdrożeń.
Co zmieści się na 24 GB (RTX 4090, L4)
24 GB to najpopularniejszy tier dla deweloperskich i mniejszych produkcyjnych wdrożeń on-prem.
Co zmieści się bez problemu: - 7B FP16 — wagi ~16–18 GB, reszta na KV cache (~6 GB) wystarczy dla średnich kontekstów (8–16K) przy niewielkiej liczbie równoczesnych żądań - 7B Q8_0 — wagi ~8–9 GB, KV cache ma dość miejsca nawet przy kontekście 32K - 13B Q4_K_M — wagi ~8 GB, KV cache przy kontekście 8K ma dużo miejsca - 13B Q8_0 — wagi ~14 GB, ciasno, ale zmieści się przy krótszych kontekstach
Co się nie zmieści: - 13B FP16 — wagi ~26 GB, przekracza pojemność - 34B w jakimkolwiek typowym formacie — nawet przy Q4 wagi (~17–20 GB) + KV cache nie zmieszczą się na 24 GB przy realnym obciążeniu
Dla karty 24 GB Q4_K_M jest praktycznie standardem przy modelach 13B; przy 7B masz swobodę wyboru Q8 lub FP16 w zależności od tego, ile kontekstu potrzebujesz.
Co zmieści się na 48 GB (RTX 6000 Ada, A40, L40S)
48 GB otwiera sensowną przestrzeń dla większych modeli.
Co działa dobrze: - 13B FP16 — mieści się bez problemu, reszta na KV cache wystarczy przy kontekście 16–32K - 34B Q4_K_M — wagi ~17–20 GB, wystarczająco dużo na produkcyjny KV cache - 34B Q8_0 — wagi ~30–34 GB, ciasno, ale funkcjonalne przy krótszych kontekstach - 70B Q4_K_M — wagi ~38–40 GB, reszta na KV cache (~6–10 GB) ogranicza do krótkich kontekstów (4–8K) lub 1 równoległego żądania
Co nie jest idealne: - 70B FP16 — 140 GB, trzykrotność pojemności - 70B Q8_0 — ~70–75 GB, wciąż przekracza
Karta 48 GB jest w stanie obsługiwać model 70B w Q4_K_M, ale z ograniczonym kontekstem. Dla większości firmowych przypadków użycia — RAG nad dokumentami, klasyfikacja, strukturowana ekstrakcja — krótszy kontekst (do 8K) wystarczy.
Co zmieści się na 80 GB (A100, H100, H200)
80 GB to tier, gdzie większość produkcyjnych wdrożeń modeli 70B działa bez kompromisów.
- 70B FP16 — wagi ~140 GB, nie zmieści się nawet tutaj. Potrzebujesz co najmniej dwóch kart.
- 70B Q8_0 — wagi ~70–75 GB, mieści się, pozostaje ~5–10 GB na KV cache — ogranicza do bardzo krótkich kontekstów lub 1 żądania
- 70B Q4_K_M — wagi ~38–40 GB, reszta ~38–40 GB na KV cache — komfortowe dla kontekstu 32K, 2–4 równoczesnych żądań
- 34B FP16 — wagi ~54–68 GB, mieści się z przyzwoitą przestrzenią na KV cache
Na H100 80GB przy 70B Q4_K_M z vLLM lub SGLang uzyskasz produkcyjny serving z throughput-em odpowiednim dla dziesiątek równoczesnych użytkowników.
Kwantyzacja: gdzie zaoszczędzić bez straty jakości
Kwantyzacja obniża precyzję wag (z FP16/BF16 do INT8, INT4 i niżej) w zamian za mniejszy footprint VRAM i szybszą inferencję. Pytanie nie brzmi „czy kwantyzować" — lecz gdzie gubi się jakość, a gdzie nie.
Orientacyjne zachowanie jakości względem FP16:
- Q8_0 (GGUF): ~98–99 % — praktycznie nieodróżnialne. Standardowy wybór, gdy masz wystarczająco VRAM i zależy Ci na maksymalnej precyzji.
- Q4_K_M (GGUF): ~92–95 % — sweet spot. Większość firmowych przypadków użycia (RAG, klasyfikacja, ekstrakcja, czytanie dokumentów) nie zauważy różnicy.
- AWQ 4-bit: ~93–96 % — nieznacznie lepsze dla koherencji tekstu i kodu. Wymaga GPU NVIDIA, integruje się czysto z
vLLM. - GPTQ 4-bit: ~90–93 % — maksymalny throughput na stacku NVIDIA, nieco niższa jakość niż AWQ.
- Q2 (GGUF): wyraźna degradacja — zauważalna przy złożonym rozumowaniu, długich generacjach, tekstach wielojęzycznych.
Różnica w perplexity między Q4 a BF16 wynosi według benchmarków poniżej 6 %. Dla większości przemysłowych przypadków użycia jest to pomijalnie małe. Strata pojawia się, gdy model musi przeprowadzić precyzyjne wieloetapowe rozumowanie lub generuje długie spójne teksty — tam Q4 potrafi gubić wątek w porównaniu z Q8.
Szczegółowe omówienie formatów kwantyzacji, ich różnic i przypadków zastosowania znajdziesz w przeglądzie kwantyzacji GGUF, AWQ, GPTQ.
Multi-GPU: kiedy i jak
Gdy model nie mieści się na jednej karcie, masz dwie możliwości: kwantyzować albo dodać GPU. Czasem potrzebujesz obu.
Tensor parallelism — model jest dzielony po warstwach (lub po głowicach uwagi) pomiędzy wiele GPU. vLLM i SGLang obsługują to natywnie. Przy dwóch A100 80GB uzyskujesz efektywnie 160 GB VRAM i możesz obsługiwać 70B FP16.
Pipeline parallelism — różne bloki modelu działają na różnych GPU kolejno po sobie. Mniej efektywne niż tensor parallelism (czas bezczynności przy przejściu między kartami), ale działa nawet na kartach bez NVLink.
Praktyczne rekomendacje: - 2× RTX 4090 (2× 24 GB = 48 GB): 34B Q4_K_M bez problemu, 70B Q4_K_M ciasno — mieści się, KV cache ograniczony - 2× A100 80 GB (2× 80 GB = 160 GB): 70B FP16 bez kompromisów, 70B Q8_0 z dużym KV cache - NVLink między kartami znacząco redukuje overhead komunikacyjny przy tensor parallelism — przy produkcyjnych wdrożeniach preferuj karty z obsługą NVLink (A100, H100, RTX 6000 Ada)
Większość konsumenckich GPU (RTX 4090) nie ma NVLink — komunikują się przez PCIe, co zwiększa latencję przy podziale multi-GPU. Do celów deweloperskich to wystarczy; w środowisku produkcyjnym z niskimi latencjami inwestycja w GPU klasy workstation się opłaca.
Overhead frameworku servingowego
Do wag i KV cache dochodzi overhead samego rozwiązania servingowego. vLLM stosuje PagedAttention — zarządza KV cache na stronach podobnie jak OS zarządza pamięcią, co redukuje fragmentację z typowego 60–80 % marnotrawstwa do poniżej 4 %. Mimo to zarezerwuj dodatkową przestrzeń:
- Overhead `vLLM`: typowo 1–3 GB ponad bufory aktywacji, prefetch i scheduling
- Overhead `SGLang`: porównywalny z vLLM, dodatkowo drzewo RadixAttention dla prefix caching
Zasada kciuka: licz z ~10–15 % rezerwą ponad oszacowane wagi + KV cache. Dla karty 24 GB oznacza to celowanie w ~20–22 GB efektywnego wykorzystania, nie w pełne 24 GB.
W odróżnieniu od produkcyjnych frameworków Ollama korzysta pod spodem z llama.cpp — jest doskonałe dla deweloperskich desktopów i single-user eksperymentów, ale nie jest zaprojektowane dla równoczesnych żądań. Przy 8 równoległych użytkownikach vLLM jest znacznie szybszy (ok. 2–3×). Więcej o różnicach między rozwiązaniami servingowymi znajdziesz w porównaniu vLLM vs SGLang vs Ollama.
Praktyczna tabela referencyjna: co do czego
Podsumowanie dla typowych scenariuszy:
Deweloperska stacja robocza, single user: - Modele 7B–13B, krótki kontekst → 1× RTX 4090 (24 GB) z Q4_K_M lub Q8_0 - Model 34B → 2× RTX 4090 albo 1× RTX 6000 Ada (48 GB) z Q4_K_M
Serwer produkcyjny, 5–20 równoczesnych użytkowników: - 7B FP16 lub Q8_0 → 1× A40 lub L40S (48 GB) - 13B–34B Q4_K_M → 1× A40 lub L40S - 70B Q4_K_M z krótkim kontekstem → 1× A100 80 GB lub H100 80 GB - 70B Q4_K_M z długim kontekstem, wyższy throughput → 2× A100 lub 2× H100
On-prem enterprise, regulowane branże: - Jakość bez kompromisów → 70B Q8_0 lub FP16 → 2× H100 80 GB (NVLink) - Jeśli on-prem ma sens dla Twojego przypadku użycia z perspektywy RODO i kosztów, zajrzyj też do artykułu on-prem LLM dla regulowanych branż
Dla każdej z tych decyzji obowiązuje jedna zasada: pojemność obliczeniowa to tylko jedna strona równania. Równie ważne jest to, czego oczekujesz od modelu — i co model wiedziałby, gdyby był odpowiednio dotrenowany na Twoich danych. O tym, kiedy instalować większy GPU, a kiedy lepiej fine-tunować mniejszy model, piszemy w artykule mały fine-tuned vs duży model bazowy.
Najczęstsze pytania
Czy model 70B zmieści się na jednym RTX 4090?
Nie w sensowny sposób. RTX 4090 ma 24 GB VRAM. Wagi modelu 70B w Q4_K_M zajmują około 38–40 GB — to prawie dwa razy więcej niż pojemność karty. Do inferencji modelu 70B potrzebujesz albo dwóch kart (2× 24 GB przez PCIe tensor parallelism), albo jednej karty 48 GB, gdzie zmieści się tylko przy ograniczonym kontekście.
Jaka jest różnica między VRAM GPU a RAM systemową przy inferencji?
Model musi być załadowany do VRAM GPU — RAM systemowa nie może go zastąpić przy inferencji GPU. Inferencja na CPU (przez llama.cpp bez GPU) działa z RAM systemowej, ale jest rzędy wielkości wolniejsza. Niektóre rozwiązania (np. llama.cpp z partial offloading) ładują część warstw do VRAM, a resztę pozostawiają w RAM — praktycznie użyteczne dla deweloperskich eksperymentów, nie dla produkcji.
Ile VRAM dodaje długi kontekst?
Zależy od modelu. Orientacyjnie: przy modelu 7B każde 8K tokenów kontekstu dodaje ~1–2 GB KV cache. Przy modelu 70B to ~5–10 GB na każde 8K tokenów. Nowoczesne modele z Grouped Query Attention (GQA) są znacznie oszczędniejsze niż starsze. Przed zakupem sprzętu sprawdź parametr num_key_value_heads w pliku konfiguracyjnym docelowego modelu.
Czy kwantyzacja Q4_K_M jest wystarczająca dla firmowych dokumentów i RAG?
W większości przypadków tak. Przy RAG nad firmową dokumentacją (ekstrakcja informacji, kategoryzacja, streszczanie) różnica między Q4_K_M a FP16 jest w praktyce trudno mierzalna. Degradacja pojawia się przy złożonym wieloetapowym rozumowaniu lub przy generowaniu długich spójnych tekstów. Jeśli masz wątpliwości, przetestuj konkretny przypadek użycia z Q4_K_M i porównaj z Q8_0 — wynik zazwyczaj zaskoczy Cię pozytywnie.
Kiedy przejść na multi-GPU zamiast jednej większej karty?
Jedna większa karta jest zazwyczaj lepszym wyborem, gdy istnieje (niższy overhead komunikacyjny, prostsza administracja). Multi-GPU ma sens, gdy: (1) model fizycznie nie mieści się na jednej karcie nawet przy agresywnej kwantyzacji, (2) potrzebujesz redundancji dla wysokiej dostępności, lub (3) planujesz obsługiwać dużą liczbę równoczesnych żądań i throughput jest Twoją podstawową metryką.
*Wybór odpowiedniego GPU do lokalnej inferencji wydaje się na pierwszy rzut oka pytaniem technicznym — w rzeczywistości jest to decyzja architektoniczna, która wpływa na koszty, okno kontekstu, liczbę równoczesnych użytkowników i dostępność systemu. W MP Industrial Solutions pomagamy firmom przejść od docelowego przypadku użycia przez wybór modelu po konkretne rekomendacje sprzętowe — wraz z kalkulacją TCO w porównaniu z cloud API. Jeśli przygotowujesz pierwsze wdrożenie on-prem lub weryfikujesz istniejący serwer, chętnie przejrzymy Twoje liczby.*