Krótko: 7B w kwantyzacji zmieści się na 8 GB, 13B komfortowo chce 16 GB, 34B wchodzi na 24 GB "na styk", a do 70B realnie potrzebujesz około 40-48 GB VRAM — czyli dwóch kart 24 GB albo jednej z dużą ilością pamięci. Poniżej rozpisuję, skąd biorą się te liczby i dlaczego kontekst potrafi to wszystko popsuć.
Piszę to z perspektywy kogoś, kto stawiał lokalne LLM-y na używanych Teslach z drugiej ręki — nie z folderu producenta, tylko z realnych testów w domowym rack'u. Karty Tesla (P4, P40, P100, V100, A2) nie mają wyjścia wideo i chłodzenia — to karty do serwerowni, kupowane właśnie pod tego typu zastosowania, więc temat "ile VRAM" jest tu pytaniem numer jeden zanim ktoś w ogóle sięgnie po portfel.
Reguła kciuka: parametry × bity + kontekst
Zanim przejdziemy do tabeli, warto zrozumieć skąd w ogóle biorą się te liczby, bo pozwala to samodzielnie policzyć dowolny model, którego nie ma w żadnym zestawieniu.
Najprostsze przybliżenie: rozmiar modelu w GB ≈ liczba parametrów (w miliardach) × bity kwantyzacji / 8, plus narzut na format i bufory. W praktyce dla popularnej kwantyzacji Q4 (4-bit, np. GGUF Q4_K_M) wychodzi z grubsza 0,55-0,65 GB na każdy miliard parametrów. Model 7B w Q4 to więc ok. 4-4,5 GB samych wag. W Q8 (8-bit) to już ok. 7-8 GB, a w pełnym FP16 — około 14 GB.
To jednak nie koniec. Do samych wag modelu dochodzi KV cache, czyli pamięć na kontekst — historię rozmowy i prompt, który aktualnie przetwarzasz. Im dłuższy kontekst (4K, 8K, 32K tokenów), tym więcej VRAM zajmuje sama "pamięć robocza" modelu, niezależnie od wag. Dla mniejszych modeli i krótkich kontekstów to margines rzędu 1-2 GB, ale przy 70B i długim oknie kontekstowym potrafi to urosnąć do kilkunastu gigabajtów dodatkowo. Traktuj to jako regułę kciuka, nie sztywny wzór — dokładna wartość zależy od architektury modelu (liczby warstw, głowic uwagi) i implementacji (llama.cpp inaczej zarządza pamięcią niż natywny PyTorch).
Tabela: model × kwantyzacja → VRAM → karta
| Model | Q4 (4-bit) | Q8 (8-bit) | FP16 | Sugerowana karta |
|---|---|---|---|---|
| 7B | ~4-5 GB | ~7-8 GB | ~14 GB | P4 8GB (Q4, ciasno) lub V100 16GB z zapasem |
| 13B | ~7-8 GB | ~13-14 GB | ~26 GB | V100 16GB komfortowo w Q4/Q8 |
| 34B | ~18-20 GB | ~34-36 GB | ~68 GB | P40 24GB w Q4, na styk |
| 70B | ~38-40 GB | ~70 GB+ | ~140 GB | 2× V100 32GB lub 2× P40 24GB |
Wartości są orientacyjne — realny rozmiar pliku GGUF czy checkpointu potrafi się różnić o kilkanaście procent w zależności od metody kwantyzacji (Q4_0 vs Q4_K_M vs Q5_K_M itd.), ale rząd wielkości się zgadza i to jest tu najważniejsze przy planowaniu zakupu.
To nie zamknięta lista — pokazuję karty, które najczęściej trafiają do tych zastosowań i które mamy w bieżącej ofercie; jeśli potrzebujesz innego modelu (np. z większym VRAM), sprowadzamy go na zamówienie i wyceniamy na zapytanie.
Jedna uwaga praktyczna: A2 16GB to karta niskoprofilowa i energooszczędna (40-60W), świetna do lżejszych zadań inferencji czy jako druga karta w systemie, ale przy dużych modelach jej przepustowość pamięci (ok. 200 GB/s, GDDR6) będzie wyraźnie wolniejsza niż HBM2 w V100 (900 GB/s) czy P100 (732 GB/s) — o tym więcej za chwilę.
Dlaczego kontekst potrafi zepsuć plan
Ustawiłeś model 13B w Q4 na karcie 16 GB i wydawało się, że masz zapas 8 GB? Włączasz kontekst 16K albo 32K tokenów (bo akurat wrzucasz do promptu długi dokument) i nagle zaczynasz dostawać CUDA out of memory. To klasyka na r/LocalLLaMA — ludzie liczą tylko wagi modelu i zapominają, że KV cache rośnie liniowo z długością kontekstu i liczbą jednoczesnych sesji (batcha).
W praktyce: jeśli planujesz długi kontekst (RAG z dużymi dokumentami, długie rozmowy), zostaw sobie większy margines niż "model się zmieścił" — najlepiej 20-30% VRAM w zapasie ponad same wagi, a przy pracy z kontekstami 32K+ na większych modelach nawet więcej.
Dwie karty albo offload do RAM
Gdy model nie mieści się na jednej karcie, są dwie drogi.
Dwie karty (multi-GPU). llama.cpp i Ollama potrafią rozdzielić warstwy modelu między karty (tensor/layer split) — np. 70B w Q4 na 2× P40 24GB czy 2× V100 32GB. To działa nieźle, o ile karty łączy się w jednym systemie z odpowiednim zasilaniem (pamiętaj, że V100 i P40 to karty na złączu EPS, więc trzeba mieć odpowiednie okablowanie w obudowie/serwerze). Strata wydajności przy dobrym split jest zwykle akceptowalna, bo większość czasu i tak dominuje przepustowość pamięci, a nie komunikacja między kartami przy generacji tokenów.
Offload do RAM systemowego. llama.cpp pozwala też trzymać część warstw modelu w RAM-ie, a resztę na GPU (--n-gpu-layers). Działa, uruchomi model, którego inaczej byś nie odpalił — ale kosztem prędkości. RAM DDR4/DDR5 ma przepustowość rzędu 30-90 GB/s w typowym desktopie/serwerze, czyli wielokrotnie mniej niż VRAM (P40: 346 GB/s, V100: 900 GB/s). Dla dużych modeli w trybie częściowego CPU offload spadek generacji tokenów na sekundę bywa drastyczny — z komfortowego czatu robi się czekanie na każdą odpowiedź. To rozwiązanie awaryjne, nie docelowe.
Ollama i llama.cpp w praktyce
W Ollama sprawa jest prosta — wybierasz tag modelu (np. llama3:70b-instruct-q4_0) i Ollama sama próbuje go załadować na dostępny VRAM, w razie potrzeby robiąc częściowy offload. Warto obserwować ollama ps, które pokazuje, ile procent modelu faktycznie siedzi na GPU.
W czystym llama.cpp masz więcej kontroli — flagą -ngl (number of GPU layers) ręcznie ustawiasz, ile warstw ma trafić na kartę. To przydatne, gdy chcesz świadomie zostawić margines na dłuższy kontekst zamiast ładować model "pod korek".
Karty Pascal (P4, P40, P100) mają okrojone wsparcie FP16 w Tensor Core (bo go po prostu nie mają — to Volta i nowsze), więc realnie pracujesz na nich w kwantyzacji INT8/INT4 przez GGUF, i to jest zresztą naturalny wybór do lokalnych LLM-ów. P100 wyróżnia się pełnym FP16 i FP64, co ma znaczenie bardziej przy treningu/fine-tuningu niż przy samej inferencji. V100 (Volta, pierwsza generacja Tensor Core) i A2 (Ampere, BF16/TF32) radzą sobie z FP16 natywnie, co bywa wygodne przy niektórych pipeline'ach, choć w praktyce lokalnej inferencji GGUF i tak dominuje.
Jeśli kupujesz kartę używaną pod ten cel — niezależnie od generacji — przepuść ją przez porządny test obciążeniowy (gpu-burn) zanim zaczniesz na niej cokolwiek trenować czy serwować produkcyjnie. Karty pasywne szczególnie łatwo przegrzać przy niewystarczającym przepływie powietrza w obudowie, a błąd ujawnia się dopiero pod pełnym obciążeniem, nie w spoczynku.
FAQ
- Czy 8 GB VRAM wystarczy do jakiegokolwiek sensownego LLM?
- Tak, do modeli rzędu 7B w kwantyzacji Q4 — to standardowy punkt startowy w społeczności lokalnych LLM-ów. Nie licz jednak na duży kontekst ani wygodny zapas.
- Czy potrzebuję licencji vGPU żeby uruchomić CUDA na Tesli?
- Nie — to częsty mit. Licencje vGPU (NVIDIA GRID) dotyczą wirtualizacji pulpitów/aplikacji graficznych, nie samego CUDA. Do inferencji LLM przez CUDA/llama.cpp/PyTorch nie są potrzebne.
- Czy lepiej kupić jedną większą kartę czy dwie mniejsze?
- Zależy od modelu docelowego. Do 34B jedna karta 24 GB (P40) często wystarczy i jest prostsza w konfiguracji. Do 70B praktycznie zawsze potrzebujesz dwóch kart — jedna karta z aż tyloma GB VRAM w segmencie używanym jest rzadkością i zwykle nieopłacalna względem dwóch mniejszych.
- Jaki system operacyjny do serwera LLM na Tesli?
- Linux jest zdecydowanie preferowany — sterowniki, narzędzia (nvidia-smi, biblioteki CUDA) i większość gotowych obrazów Ollama/llama.cpp są tam najlepiej wspierane i najlepiej udokumentowane.
- Ile realnie zajmie 70B w praktyce, a nie w teorii?
- Licz konserwatywnie: 38-40 GB na same wagi w Q4, plus zapas na kontekst — w praktyce lądujesz w okolicach 44-48 GB, stąd typowa konfiguracja to dwie karty po 24-32 GB.