Ile VRAM potrzebuje model językowy, policzysz w kilka minut, jeśli znasz trzy liczby: liczbę parametrów, precyzję (czyli kwantyzację) oraz długość kontekstu pomnożoną przez liczbę równoczesnych użytkowników. Pokazujemy prosty wzór, przykłady dla modeli od 8B do ponad 2T parametrów i tabelę, która od razu wskazuje sprzęt.
To najczęstsze pytanie, jakie dostajemy przed doborem serwera GPU. Odpowiedź „model ma 70B, więc potrzeba 140 GB” bywa prawdziwa, ale często prowadzi do zakupu za dużego albo – częściej – za małego sprzętu. Wszystko przez KV cache, o którym wiele kalkulatorów zapomina. Przykłady modeli są aktualne na listopad 2026; rynek modeli otwartych zmienia się co miesiąc, ale sposób liczenia pozostaje ten sam.
Wzór: ile VRAM potrzebuje model językowy
Pamięć potrzebna do inferencji (uruchamiania modelu) to w przybliżeniu:
VRAM ≈ wagi + KV cache + 10–20% narzutu
gdzie wagi = liczba parametrów × bajty na parametr. Liczba bajtów zależy od precyzji:
- FP16 / BF16 – 2 bajty na parametr (pełna precyzja, w jakiej publikuje się większość modeli),
- FP8 / INT8 – 1 bajt,
- 4-bit (np. GGUF Q4, AWQ, GPTQ) – ok. 0,5 bajta. W praktyce nieco więcej, bo dochodzą współczynniki skalowania kwantyzacji.
Narzut to m.in. kontekst CUDA, bufory silnika inferencji, aktywacje i fragmentacja pamięci. Przyjmij 10% przy dobrze dostrojonym silniku i 20%, jeśli chcesz mieć spokojny zapas.
Ważne przy modelach MoE (Mixture of Experts): w pamięci musi zmieścić się cała liczba parametrów, choć przy każdym tokenie liczona jest tylko część („aktywne” parametry). Model oznaczony 1T-A52B potrzebuje pamięci jak model o bilionie parametrów. Liczba aktywnych wpływa na szybkość, nie na zapotrzebowanie na VRAM.
Same wagi: przykłady dla 8B, 27–32B, 70B, 120B i 400B+
Model 8B
Np. Llama-PLLuM-8B. W BF16: 8 mld × 2 B = 16 GB. W FP8: 8 GB, w 4-bit: ok. 4 GB. Wersję 4-bit uruchomisz na karcie 12 GB, wersję BF16 – na GPU z 24 GB, ale wtedy zostaje niewiele miejsca na kontekst.
Model 27–32B
Np. Qwen3.8-27B (27,8B parametrów) lub Gemma 4 31B. W BF16: 27,8 × 2 = 55,6 GB, a dla 31B – 62 GB. W FP8: 28–31 GB, w 4-bit: 14–16 GB. To klasa modeli, która w BF16 mieści się na jednej karcie RTX PRO 6000 z 96 GB.
Model 70B
Np. Llama-PLLuM-70B. W BF16: 70 × 2 = 140 GB – to już więcej niż jedna karta 96 GB czy nawet H200 (141 GB), bo trzeba jeszcze doliczyć KV cache i narzut. W FP8: 70 GB, w 4-bit: 35 GB.
Model ok. 120B (MoE)
Np. gpt-oss-120b, który ma łącznie 117B parametrów. W BF16: 117 × 2 = 234 GB, w FP8: 117 GB, w 4-bit: 58,5 GB. Mimo że przy każdym tokenie liczona jest tylko niewielka część parametrów, pamięć trzeba zarezerwować na wszystkie 117B. W 4-bit model zmieści się na jednej karcie 96 GB albo na DGX Spark ze 128 GB.
Modele 400B+
Llama 4 Maverick (ok. 400B): 800 GB w BF16, 400 GB w FP8, 200 GB w 4-bit. DeepSeek-V4.1-Flash (ok. 763B): 763 GB w FP8, ok. 380 GB w 4-bit. Kimi K3 (ok. 2,78T): 2 780 GB w FP8, 1 390 GB w 4-bit. Takie modele wymagają wielu GPU, systemu HGX albo klastra.
KV cache, czyli pamięć kontekstu
Podczas generowania odpowiedzi model zapamiętuje dla każdego przetworzonego tokenu pośrednie wyniki (klucze i wartości mechanizmu uwagi), żeby nie liczyć ich od nowa. To jest KV cache. Rośnie liniowo z długością kontekstu i z liczbą równoczesnych rozmów. Jeśli nie wiesz, czym dokładnie jest token, zajrzyj do naszego artykułu o tokenach w modelach językowych.
Standardowy wzór na KV cache dla jednej sekwencji (jednej rozmowy) to:
KV cache = 2 × liczba warstw × liczba głów KV × wymiar głowy × bajty na wartość × liczba tokenów
Dwójka na początku oznacza, że przechowywane są osobno klucze (K) i wartości (V). Parametry architektury znajdziesz w pliku config.json modelu (pola num_hidden_layers, num_key_value_heads i head_dim; jeśli tego ostatniego brakuje, wymiar głowy to hidden_size podzielone przez num_attention_heads). Dla kilku równoczesnych rozmów mnożysz wynik przez ich liczbę.
Przykład: model 70B na architekturze Llama 3.1
Llama-PLLuM-70B bazuje na Llama 3.1 70B: 80 warstw, 8 głów KV, wymiar głowy 128. KV cache w BF16 (2 bajty) na jeden token to 2 × 80 × 8 × 128 × 2 = 327 680 bajtów, czyli ok. 0,33 MB. Dla jednej rozmowy daje to:
| Długość kontekstu | KV cache – 1 rozmowa | KV cache – 10 rozmów |
|---|---|---|
| 8 192 tokeny | ok. 2,7 GB | ok. 26,8 GB |
| 32 768 tokenów | ok. 10,7 GB | ok. 107 GB |
| 131 072 tokeny | ok. 42,9 GB | ok. 429 GB |
Dla porównania model 8B na tej samej architekturze (32 warstwy) potrzebuje ok. 0,13 MB na token, czyli ok. 4,3 GB na jedną rozmowę z kontekstem 32 768 tokenów.
Wniosek: przy długim kontekście i wielu użytkownikach KV cache może zająć więcej pamięci niż same wagi. Pomaga kilka rzeczy. Część silników (np. vLLM) potrafi trzymać KV cache w FP8, co zmniejsza go o połowę. vLLM dzięki PagedAttention przydziela pamięć na bieżąco, zamiast rezerwować pełny kontekst dla każdego zapytania. Niektóre architektury mocno kompresują KV cache, dlatego zawsze sprawdzaj config.json konkretnego modelu.
Przykład od początku do końca: model 70B dla 10 osób
Załóżmy model 70B w FP8, 10 równoczesnych rozmów, każda z kontekstem do 8 192 tokenów:
- wagi: 70 GB,
- KV cache w BF16: 10 × ok. 2,68 GB = ok. 26,8 GB,
- razem: ok. 96,8 GB, a z narzutem 10–20%: ok. 106–116 GB.
To się nie zmieści na jednej karcie RTX PRO 6000 (96 GB). Nawet z KV cache w FP8 (ok. 13,4 GB) wychodzi ok. 92–100 GB, czyli na styk. Rozsądne opcje to dwie karty RTX PRO 6000 (192 GB) albo jeden GPU B200 (180 GB). DGX Spark ze 128 GB pomieści taki zestaw, ale przy przepustowości pamięci 273 GB/s odpowiedzi dla 10 osób będą generowane wolno – to sprzęt do prototypu, nie do produkcji.
Tabela: rozmiar modelu, precyzja, pamięć i przykładowy sprzęt
To najszybszy sposób, żeby sprawdzić, ile VRAM potrzebuje model językowy, który rozważasz. Kolumna „wagi” nie zawiera KV cache ani narzutu. Sprzęt dobraliśmy z zapasem na umiarkowany kontekst. Przy wielu użytkownikach i długich dokumentach przejdź o szczebel wyżej.
| Model (przykład) | Precyzja | Wagi (ok.) | Przykładowy sprzęt |
|---|---|---|---|
| 8B (Llama-PLLuM-8B) | BF16 | 16 GB | GPU 24 GB (krótki kontekst); 1× RTX PRO 6000 dla wielu użytkowników |
| 8B | 4-bit | 4 GB | GPU 12 GB |
| 27–32B (Qwen3.8-27B, Gemma 4 31B) | BF16 | 56–64 GB | 1× RTX PRO 6000 (96 GB); DGX Spark (128 GB) |
| 27–32B | 4-bit | 14–16 GB | GPU 24 GB (krótki kontekst) lub 48 GB |
| 70B (Llama-PLLuM-70B) | BF16 | 140 GB | 2× RTX PRO 6000 (192 GB); 1× B200 (180 GB) |
| 70B | FP8 | 70 GB | 1× RTX PRO 6000 (mało miejsca na kontekst); 2× RTX PRO 6000; DGX Spark do testów |
| 70B | 4-bit | 35 GB | 1× RTX PRO 6000 z dużym zapasem; 2× A40 (96 GB) |
| ok. 120B MoE (gpt-oss-120b, 117B) | FP8 | 117 GB | 2× RTX PRO 6000; na DGX Spark za ciasno |
| ok. 120B MoE | 4-bit | 58,5 GB | 1× RTX PRO 6000; DGX Spark |
| ok. 400B (Llama 4 Maverick) | FP8 | 400 GB | 8× RTX PRO 6000 (768 GB); HGX B200 (1 440 GB) |
| ok. 400B | 4-bit | 200 GB | 4× RTX PRO 6000 (384 GB); klaster 2× DGX Spark (256 GB, na styk) |
| ok. 750B (DeepSeek-V4.1-Flash, GLM-5.3) | FP8 | 750–765 GB | HGX B200 (1 440 GB); HGX B300 (ok. 2,3 TB) |
| ok. 750B | 4-bit | ok. 380 GB | 8× RTX PRO 6000 (768 GB); klaster 4× DGX Spark (512 GB) |
| 1–1,65T (Mistral Large 4, DeepSeek-V4-Pro) | FP8 | 1 000–1 650 GB | HGX B200 (dla ok. 1T); HGX B300 (do ok. 1,65T) |
| 2,4–2,8T (Qwen3.8-2.4T-A95B, Kimi K3) | 4-bit | 1 200–1 390 GB | HGX B300; w FP8 – więcej niż jeden węzeł |
DGX Spark ma 128 GB pamięci zunifikowanej, współdzielonej przez CPU i GPU, więc część zajmuje system operacyjny. Jego realna przewaga to pojemność przy niskim poborze prądu, a nie szybkość. Szczegółowe porównanie kart znajdziesz w artykule jaki GPU do LLM wybrać w 2026, a o samym urządzeniu piszemy w tekście NVIDIA DGX Spark jako usługa.
Kwantyzacja: ile oszczędzasz, ile ryzykujesz
Przejście z BF16 na FP8 zmniejsza pamięć na wagi o połowę, a na 4-bit – do jednej czwartej. Duże modele zwykle dobrze znoszą kwantyzację FP8, a przy 4-bit spadek jakości bywa niewielki, choć zależy od modelu, metody i zadania. Małe modele są na kwantyzację bardziej wrażliwe. Zanim zdecydujesz, przetestuj wersję skwantyzowaną na własnych danych, zwłaszcza w zadaniach po polsku, gdzie różnice wychodzą szybciej niż w ogólnych benchmarkach.
Praktyczny przykład, jak kwantyzacja obniża koszt infrastruktury, opisaliśmy w artykule o redukcji kosztów wdrożeń AI dzięki kwantyzacji. Jeśli jeszcze wybierasz model, zobacz nasze porównanie modeli open source do self-hostingu.
Najczęstsze błędy przy liczeniu VRAM do LLM
- Pominięcie KV cache. Model „mieści się”, ale przy pierwszym długim dokumencie albo piątym użytkowniku kończy się pamięć.
- Liczenie tylko aktywnych parametrów w MoE. Pamięć potrzebna jest na wszystkie parametry.
- Mylenie GB z GiB. 1 GiB to ok. 1,074 GB. Narzędzia systemowe często pokazują GiB, a karty katalogowe GB.
- Traktowanie wielu GPU jak jednej puli. Przy podziale modelu na kilka kart każda ma własny narzut, a podział zwykle musi być równy. Dwie karty 96 GB to w praktyce mniej niż 192 GB użytecznej pamięci.
- Przenoszenie wyliczeń z inferencji na trening. Trening i pełny fine-tuning przechowują dodatkowo gradienty i stany optymalizatora, więc potrzebują kilkukrotnie więcej pamięci. Metody LoRA i QLoRA znacznie to ograniczają.
FAQ: najczęściej zadawane pytania
Ile VRAM potrzeba do modelu 7B lub 8B?
W pełnej precyzji BF16 ok. 16 GB na wagi plus kontekst, więc minimum to karta 24 GB. W kwantyzacji 4-bit wagi zajmują ok. 4 GB i model działa na karcie 12 GB.
Ile VRAM potrzebuje model 70B?
Wagi zajmują ok. 140 GB w BF16, 70 GB w FP8 i 35 GB w 4-bit. Do tego dolicz KV cache: przy architekturze Llama 3.1 70B to ok. 2,7 GB na rozmowę z kontekstem 8 192 tokenów (w BF16) i 10–20% narzutu.
Czy model MoE potrzebuje mniej pamięci?
Nie. Model MoE liczy przy każdym tokenie tylko część parametrów, więc działa szybciej, ale w pamięci muszą się zmieścić wszystkie. gpt-oss-120b potrzebuje pamięci na 117B parametrów.
Czy można uruchomić LLM, gdy VRAM nie wystarcza?
Można część warstw przenieść do pamięci RAM i liczyć na CPU (np. w llama.cpp), ale generowanie zwalnia wtedy wielokrotnie. Do testów to wystarczy, do pracy zespołu – nie.
Jak długość kontekstu wpływa na zapotrzebowanie na VRAM?
Liniowo: dwa razy dłuższy kontekst to dwa razy większy KV cache dla każdej rozmowy. Przy kontekście 128k i wielu użytkownikach KV cache może zająć więcej pamięci niż same wagi modelu.
Podaj nam model, długość kontekstu i liczbę użytkowników, a policzymy zapotrzebowanie na pamięć i zaproponujemy konfigurację: od gotowych pakietów GPU (od 899 zł netto miesięcznie) po serwery GPU z RTX PRO 6000 i HGX B200/B300 w wycenie indywidualnej. Skontaktuj się z nami.