Wymagania VRAM dla LLM: Tabela mistrzowska 2026 (Każdy model, każda kwantyzacja)

Wymagania VRAM dla LLM: Tabela mistrzowska 2026 (Każdy model, każda kwantyzacja)

Oto liczba, która zawsze zaskakuje: DeepSeek-V3.2 ma 671 miliardów parametrów, ale przy każdym tokenie aktywnych jest tylko 37 miliardów. Ile pamięci VRAM więc naprawdę potrzebuje? Wszystkich 671 miliardów, co przy kwantyzacji Q4 daje około 382 GB. Wymagania VRAM dla LLM rzadko idą w parze z intuicją, a przepaść między „aktywnymi parametrami” a tym, co musisz załadować do pamięci, to właśnie miejsce, gdzie budżety na sprzęt wybuchają. Ten przewodnik dostarcza Ci tabelę mistrzowską (każdy główny model open-source, każdy poziom kwantyzacji, wartość w GB oraz GPU, który to obsłuży) plus wzór, dzięki któremu obliczysz zapotrzebowanie dla dowolnego modelu w około dziesięć sekund.

Kluczowe wnioski

• VRAM na wagi ≈ parametry × bajty-na-parametr: FP16 = 2,0, Q8 = 1,0, Q5_K_M ≈ 0,68, Q4_K_M ≈ 0,57. Do tego dodaj cache KV i około 15-20% narzutu.
• Modele Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) muszą załadować każdego eksperta do VRAM. „Aktywne parametry” dają prędkość, nie oszczędność pamięci.
• Cache KV to ukryty koszt. Llama 3.3 70B potrzebuje około 2,6 GB cache przy kontekście 8K i roughly 41 GB przy 128K, dodatkowo do wag.
• Q4_K_M to rozsądny domyślny wybór: jakość bliska pełnej przy około ćwierci footprintu FP16.
• Model 12B, taki jak Gemma 4, zmieści się na karcie 8 GB przy Q4. Gęsty model 70B potrzebuje około 40 GB. Czołowy model MoE 671B wymaga małego serwera.

Wymagania VRAM dla LLM według modelu: Tabela mistrzowska

Krótka odpowiedź: przy Q4_K_M małe modele (poniżej 14B) mieszczą się na konsumenckich kartach 8-12 GB, modele średniej wielkości (24-32B) chcą 16-24 GB, gęsty model 70B potrzebuje około 40 GB, a czołowe modele MoE skaczą w setki gigabajtów, ponieważ każdy ekspert musi być rezydentny w pamięci. Oto pełny obraz w jednym miejscu. Wszystkie wartości dotyczą samej pamięci na wagi, obliczone na podstawie liczby parametrów każdego modelu i zweryfikowane z oficjalnymi kartami modeli od Meta AI, Qwen oraz Hugging Face.

Dwie rzeczy wynikające z tej tabeli. Po pierwsze, kwantyzacja to największy dźwignia, jaką masz: przejście z FP16 do Q4 redukuje footprint około 4-krotnie przy ledwo zauważalnym spadku jakości. Po drugie, wiersze MoE wyglądają brutalnie, bo takie są. Qwen3-30B-A3B aktywuje tylko 3 miliardy parametrów na token, więc działa z prędkością maleńkiego modelu, ale nadal musisz trzymać wszystkie 30 miliardów w pamięci, aby mieć gotowych każdego eksperta. Chcesz szczegółów model po modelu stojących za tymi liczbami? Nasz dogłębny artykuł o Gemma 4 12B oraz podsumowanie najlepszych open-source'owych LLM w 2026 roku omawiają benchmarki i licencje.

Wzór na VRAM: Oblicz sam dla dowolnego modelu

Aby oszacować zapotrzebowanie dowolnego modelu, pomnóż liczbę jego parametrów przez liczbę bajtów na parametr dla wybranej kwantyzacji, a następnie dodaj trochę na cache KV i narzut runtime’owy. To wszystko. Wagi to dominujący składnik, a arytmetyka jest na tyle prosta, że można ją zrobić na odwrocie serwetki.

Podstawowe równanie dla wag:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Wartości bitów na wagę, których potrzebujesz (są to efektywne rates dla plików GGUF k-quant, które niosą ze sobą nieco metadanych bloków ponad nominalną głębią bitową):

Przykład dla Gemma 4 12B przy Q4_K_M: 11,95 × 4,5 ÷ 8 = około 6,7 GB na wagi. To zgadza się z roughly 6,6 GB podanymi w oficjalnej karcie modelu i wyjaśnia, dlaczego mieści się on na karcie 8 GB z zapasem na umiarkowany kontekst. Wykonaj te same obliczenia dla modelu 70B przy Q4, a otrzymasz 70 × 4,5 ÷ 8 = 39,4 GB, co wyjaśnia, dlaczego „potrzebujesz dwóch kart 24 GB lub jednej 48 GB dla modelu 70B” to zasada powtarzana przez wszystkich.

Pełny obraz dodaje dwa kolejne składniki: całkowite VRAM ≈ wagi + cache KV + ~15-20% narzutu. Narzut pokrywa bufory aktywacji, kontekst CUDA i fragmentację pamięci, a Twój GPU rezerwuje też około pół gigabajta dla sterownika, więc nigdy nie planuj wykorzystania 100% deklarowanej pamięci VRAM.

Dlaczego cache KV to liczba, która Cię ugryzie

Cache KV przechowuje klucze i wartości attention dla każdego tokena już znajdującego się w kontekście i rośnie liniowo wraz z długością kontekstu. Przy krótkich promptach to błąd zaokrąglenia. Przy długim kontekście może rywalizować z wagami lub nawet je przewyższyć. To najczęstszy powód, dla którego model, który „powinien się zmieścić”, wyrzuca błąd out-of-memory w trakcie generowania.

Wzór, na token:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Weźmy Llama 3.3 70B: 80 warstw, 8 głow KV, wymiar głowy 128, więc kv_dim wynosi 1024. Przy FP16 daje to 80 × 2 × 1024 × 2 = 327 680 bajtów na token, czyli około 0,31 MB. Pomnóż przez długość kontekstu, a historia pisze się sama: przy 8K tokenów cache ma około 2,6 GB, przy 32K około 10 GB, a przy 128K puchnie do około 41 GB. Ta ostatnia wartość jest dodatkowo do 40 GB wag, więc „model 40 GB” cicho staje się problemem 80 GB w momencie wypełnienia okna kontekstowego.

Dwa praktyczne wyjścia. Grouped-query attention (którego używa każdy najnowszy model) już teraz drastycznie redukuje kv_dim w porównaniu do starego designu multi-head, więc nowoczesne modele są pod tym względem znacznie łagodniejsze niż Llama 2. Ponadto większość silników inferencji potrafi kwantyzować cache KV do 8-bitów lub 4-bitów, redukując jego rozmiar o połowę lub ćwierć kosztem niewielkiej utraty jakości. Jeśli obsługujesz długie konteksty w produkcji, porównanie vLLM vs SGLang pokazuje, który backend zarządza tą pamięcią najefektywniej dzięki paged attention.

Modele MoE: Dlaczego „Aktywne Parametry” Nie Oszczędzają VRAM

To pułapka, która kosztuje ludzi najwięcej pieniędzy. Model Mixture-of-Experts, taki jak DeepSeek-V3.2 (671B łącznie, 37B aktywnych, dzielący architekturę V3) lub GLM-5.2 (744B łącznie, 40B aktywnych), kieruje każdy token przez mały podzbiór swoich ekspertów. Marketing opiera się na liczbie aktywnej, bo opisuje ona prędkość: płacisz tylko za obliczenia równe 37 miliardom parametrów na token, więc wnioskowanie jest szybkie jak na rozmiar modelu. Ale każdy ekspert musi siedzieć w pamięci, gotowy do wyboru, co oznacza, że Twój budżet VRAM jest określony przez całkowitą liczbę parametrów, a nie aktywną.

Tak więc uczciwa interpretacja powyższej tabeli: GLM-5.2 działa z prędkością modelu 40B, ale zajmuje pamięć modelu 744B. Dlatego te czołowe modele open-source potrzebują serwera z 8 GPU lub dużej maszyny z jednolitą pamięcią, mimo że pojedyncze przejście forward jest tanie. Qwen3-235B-A22B ma tę samą strukturę w mniejszej skali – szybki na token, ciężki do hostowania.

Zaleta MoE pojawia się na sprzęcie z jednolitą pamięcią. Mac Studio z 512 GB jednolitej pamięci może pomieścić model 671B przy Q4 i nadal uruchamiać go z użyteczną prędkością, właśnie dlatego, że aktywuje się tylko 37B, więc zapotrzebowanie na przepustowość pamięci na token pozostaje rozsądne. Jeśli dopiero zaczynasz uruchamiać je lokalnie, zacznij od naszego przewodnika po konfiguracji lokalnych LLM, zanim wydasz pieniądze na sprzęt.

Jaką Kwantyzację Powinieneś Wybrać?

Dla prawie wszystkich Q4_K_M to właściwy domyślny wybór: utrzymuje jakość bliską pełnej, tnąc footprint FP16 około 4-krotnie. Przejdź na Q5_K_M lub Q8 tylko, jeśli masz zapas VRAM i zadanie wrażliwe na jakość, a sięgnij po FP16 tylko, gdy fine-tunujesz lub benchmarkujesz względem punktu odniesienia. Poniżej Q4 degradacja jakości staje się szybko zauważalna, więc Q3 i niżej to ostateczność, by wcisnąć model na kartę, która jest genuinnie za mała.

Jedno zastrzeżenie: jakość kwantyzacji nie jest identyczna across models. Bardzo małe modele (poniżej 4B) bardziej odczuwają Q4 niż duże, ponieważ mają mniej redundancji do stracenia. W modelu 70B różnica między Q4 a Q8 jest trudna do wychwycenia w większości zadań. W modelu 1.7B luka jest realna.

Jakiego GPU Naprawdę Potrzebujesz?

Dopasuj kolumnę Q4 z tabeli mistrzowskiej do karty z niewielkim zapasem na cache KV. Oto praktyczne mapowanie od budżetowego sprzętu konsumenckiego po data center, z tierem modeli, który każda klasa komfortowo obsługuje przy Q4.

Apple Silicon zasługuje na specjalne wspomnienie, ponieważ jednolita pamięć zmienia rachubę. Mac nie dzieli VRAM od RAM systemowego, więc maszyna M-series ze 128 GB może załadować modele, które wymagałyby wielu dyskretnych GPU, zamieniając szczytową przepustowość na możliwość zmieszczenia ogromnych wag na jednym desktopie. Dla backendów, które wyciskają najwięcej z którejkolwiek z tych kart, nasze podsumowanie najlepszych narzędzi do uruchamiania LLM lokalnie benchmarkuje rzeczywiste różnice w prędkości.

Jak My Szacujemy VRAM dla Wdrożeń Klientów

W Techsy wdrażamy modele open-source dla klientów wystarczająco często, że szacowanie VRAM to pierwsza rozmowa, przed wyborem modelu, przed promptami, przed czymkolwiek. Nasza metoda jest nudna celowo, ponieważ tryb awarii (OOM w produkcji pod realnym obciążeniem kontekstem) jest drogi. Oto proces, który faktycznie stosujemy.

Zaczynamy od matematyki z tabeli, a potem mierzymy. Po załadowaniu modelu sprawdzamy rzeczywisty footprint rezydentny, zamiast ufać estymacie:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

Lekcja, która ciągle się powtarza: zespoły szacują tylko wagi i zapominają o cache KV, a potem dziwią się, dlaczego model, który załadował się poprawnie, pada po trzech długich requestach podczas demo. Szacujemy wagi plus cache KV przy maksymalnym kontekście, jakiego aplikacja będzie naprawdę używać, plus zapas, i limitujemy --ctx-size, aby zbuntowany request nie wyłożył maszyny OOM-em. Dla wszystkiego zwróconego do klienta wolimy uruchomić skwantyzowany model 32B, który nigdy nie padnie, niż FP16 70B, który dostanie OOM pod obciążeniem.

Jeśli ważysz, czy hostować model open-source samodzielnie, czy zostać przy hostowanym API, ta wymiana (koszt sprzętu i obciążenie ops versus cena za token i kontrola) to dokładnie to, co nasz zespół scope’uje podczas engagementu integracji AI. Jeśli pomogłoby Ci, gdyby ktoś przeliczył liczby pod Twoje rzeczywiste obciążenie, umów bezpłatną konsultację, a my wspólnie to oszacujemy.

O Autorze

Mert Batur Gurbuz jest Współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji oraz pipeline’y voice/SDR dla klientów B2B. Studiuje na University of Birmingham i pisze o stacku narzędziowym LLM, z którego zespół Techsy faktycznie korzysta w produkcji.

Kredyty: Współzałożyciel, Techsy.io, University of Birmingham. Połącz się na LinkedIn.

Często Zadawane Pytania

Ile VRAM potrzebuję, aby uruchomić model 70B?

Gęsty model 70B, taki jak Llama 3.3 70B, potrzebuje około 40 GB VRAM na wagi przy Q4_K_M, więc planuj kartę 48 GB (RTX 6000 Ada) lub dwie karty 24 GB. Dodaj kilka dodatkowych gigabajtów na cache KV, jeśli używasz długiego kontekstu, co przesuwa praktyczne wymagania w stronę 48 GB lub więcej.

Ile VRAM potrzebują Llama, Qwen lub DeepSeek?

To zależy całkowicie od wariantu. Llama 4 Scout potrzebuje około 62 GB przy Q4, Qwen3-32B około 18 GB, a Qwen3-8B poniżej 5 GB. DeepSeek-V3.2, MoE 671B, potrzebuje roughly 382 GB, ponieważ każdy ekspert musi zostać załadowany. Zawsze sprawdzaj całkowitą liczbę parametrów, a nie aktywną, w przypadku modeli MoE.

Czy mogę uruchomić LLM na GPU 8GB?

Tak, komfortowo. Karta 8 GB, taka jak RTX 4060, obsłuży modele do około 12 miliardów parametrów przy Q4_K_M. Gemma 4 12B mieści się w roughly 6,8 GB, zostawiając miejsce na umiarkowany kontekst. Dla czegoś większego musisz albo kwantyzować mocniej, utrzymywać krótki kontekst, lub przejść na większą kartę.

Co obsłuży GPU 24GB, takie jak RTX 4090?

Karta 24 GB radzi sobie z gęstymi modelami do około 32B przy Q4_K_M z zapasem na rozsądny kontekst, więc Qwen3-32B i Mistral Small 3.2 24B są komfortowe. Uruchamia również MoE Qwen3-30B-A3B, który ładuje 30B wag, ale generuje z prędkością modelu 3B dzięki rzadkiej aktywacji.

Czy kwantyzacja psuje jakość modelu?

Przy Q4_K_M i wyżej, utrata jakości jest mała i często niezauważalna w realnych zadaniach, szczególnie dla modeli powyżej 13B. Luka rośnie, gdy schodzisz niżej i gdy modele są mniejsze, więc Q4 na modelu 70B jest niemal darmowe, podczas gdy Q4 na modelu 1.7B jest zauważalne. Q8 jest praktycznie bezstratny, jeśli masz pamięć.

Czy modele MoE potrzebują mniej VRAM niż modele gęste?

Nie, i to najczęstsze nieporozumienie. Model Mixture-of-Experts musi trzymać każdego eksperta w VRAM, więc jego pamięć jest określona przez całkowitą liczbę parametrów. Liczba aktywnych parametrów opisuje tylko prędkość inferencji. GLM-5.2 działa z prędkością modelu 40B, ale potrzebuje pamięci modelu 744B.

Czy jednolita pamięć to to samo co VRAM?

Funkcjonalnie, dla ładowania modeli, tak. Apple Silicon i niektóre inne systemy dzielą jedną pulę pamięci między CPU i GPU, więc Mac ze 128 GB może załadować modele, które w innym wypadku wymagałyby wielu dyskretnych GPU. Kompromisem jest przepustowość: jednolita pamięć zazwyczaj dostarcza niższą szczytową przepustowość niż wysokiej klasy GPU z data center, więc tokens-per-second jest niższe.

Czy mogę offloadować część modelu do RAM systemowego lub CPU?

Tak. Silniki takie jak llama.cpp i Ollama pozwalają trzymać niektóre warstwy na GPU, a resztę w RAM systemowym za pomocą flagi takiej jak --n-gpu-layers. Pozwala to uruchomić model zbyt duży dla Twojego VRAM, ale każda warstwa na CPU drastycznie spowalnia generowanie, więc używaj tego, aby uczynić model możliwym do uruchomienia, a nie szybkim.

Jak obliczyć VRAM dla modelu, którego nie ma w tabeli?

Pomnóż liczbę parametrów w miliardach przez bity-na-wagę dla swojej kwantyzacji, a następnie podziel przez 8. Dla Q4_K_M użyj około 4.5 bita, więc model 40B potrzebuje 40 × 4.5 ÷ 8 = około 22.5 GB na wagi. Dodaj roughly 15-20% narzutu plus Twój cache KV dla rzeczywistego zapotrzebowania.