Požadavky LLM na VRAM: Hlavní tabulka pro rok 2026 (každý model, každá kvantizace)

Požadavky LLM na VRAM: Hlavní tabulka pro rok 2026 (každý model, každá kvantizace)

Zde je číslo, které každého překvapí: DeepSeek-V3.2 má 671 miliard parametrů, ale při zpracování jakéhokoli tokenu se aktivuje pouze 37 miliard. Kolik VRAM tedy skutečně potřebuje? Všechných 671 miliard, což je přibližně 382 GB při kvantizaci Q4. Požadavky LLM na VRAM se zřídka řídí intuicí a právě mezera mezi „aktivními parametry“ a tím, co musíte načíst do paměti, je místem, kde se rozpočty na hardware rychle vyčerpávají. Tento průvodce vám poskytuje hlavní tabulku (každý hlavní open-source model, každá úroveň kvantizace, údaj v GB a GPU, které jej spustí) plus vzorec, pomocí kterého si velikost libovolného modelu spočítáte sami za asi deset sekund.

Klíčová zjištění

• VRAM pro váhy ≈ parametry × bajty na parametr: FP16 = 2,0, Q8 = 1,0, Q5_K_M ≈ 0,68, Q4_K_M ≈ 0,57. Přidejte KV cache a ~15–20 % režii navíc.
• Modely typu Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) musí načíst každého experta do VRAM. „Aktivní parametry“ vám přinášejí rychlost, ne úsporu paměti.
• KV cache je skrytým nákladem. Llama 3.3 70B potřebuje při kontextu 8K asi 2,6 GB cache a při 128K přibližně 41 GB, a to nad rámec samotných vah.
• Q4_K_M je rozumná výchozí volba: kvalita blízká plné přesnosti při zhruba čtvrtinové velikosti oproti FP16.
• Model o velikosti 12B, jako je Gemma 4, se vejde na kartu s 8 GB paměti při Q4. Hustý model o velikosti 70B potřebuje asi 40 GB. Špičkový MoE model o velikosti 671B vyžaduje malý server.

Požadavky LLM na VRAM podle modelu: Hlavní tabulka

Stručná odpověď: při Q4_K_M se malé modely (do 14B) vejdou na spotřebitelské karty s 8–12 GB, středně velké modely (24–32B) chtějí 16–24 GB, hustý model o velikosti 70B potřebuje asi 40 GB a špičkové MoE modely skočí do stovek gigabajtů, protože každý expert musí být přítomen v paměti. Zde je kompletní přehled na jednom místě. Všechny údaje představují paměť pouze pro váhy, vypočtenou z počtu parametrů každého modelu a ověřenou proti oficiálním kartám modelů od Meta AI, Qwen a Hugging Face.

Z této tabulky lze vyčíst dvě věci. Za prvé, kvantizace je největší pákou, kterou máte k dispozici: přechod z FP16 na Q4 sníží footprint přibližně 4x s jen stěha postřehnutelným dopadem na kvalitu. Za druhé, řádky s MoE vypadají drasticky, protože takové jsou. Qwen3-30B-A3B aktivuje pouze 3 miliardy parametrů na token, takže běží rychlostí malého modelu, ale stále musíte mít v paměti všech 30 miliard, aby byli všichni experti připraveni. Chcete znát podrobnosti modelu po modelu za těmito čísly? Naše hloubková analýza Gemma 4 12B a přehled nejlepších open-source LLM pro rok 2026 pokrývají benchmarky a licence.

Vzorec pro VRAM: Vypočítejte si nároky libovolného modelu sami

Pro určení velikosti libovolného modelu vynásobte počet jeho parametrů počtem bajtů na parametr pro vaši kvantizaci a poté přidejte něco málo pro KV cache a režii runtime. To je vše. Váhy jsou dominantní položkou a aritmetika je dostatečně jednoduchá na to, aby se dala provést na zadní straně ubrousku.

Základní rovnice pro váhy:

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

Hodnoty bitů na váhu, které potřebujete (jedná se o efektivní rates pro GGUF k-quant soubory, které nesou trochu blokových metadat nad nominální bitovou hloubkou):

Příklad výpočtu, Gemma 4 12B při Q4_K_M: 11,95 × 4,5 ÷ 8 = asi 6,7 GB pro váhy. To odpovídá přibližně 6,6 GB uvedeným v oficiální kartě modelu a vysvětluje, proč se vejde na kartu s 8 GB paměti s rezervou pro modestní kontext. Pokud provedete stejný výpočet pro model 70B při Q4, dostanete 70 × 4,5 ÷ 8 = 39,4 GB, což je důvod, proč „potřebujete dvě karty s 24 GB nebo jednu s 48 GB pro model 70B“ je pravidlem, které všichni opakují.

Kompletní obraz přidává dvě další položky: celková VRAM ≈ váhy + KV cache + ~15–20 % rezerva. Rezerva pokrývá aktivační buffery, CUDA kontext a fragmentaci paměti a vaše GPU si také rezervuje přibližně půl gigabajtu pro ovladač, takže nikdy neplánujte využití 100 % deklarované VRAM.

Proč je KV cache číslo, které vás bolí

KV cache ukládá klíče a hodnoty attention pro každý token již přítomný v kontextu a roste lineárně s délkou kontextu. U krátkých promptů je to zanedbatelné. Při posunu k dlouhému kontextu může konkurovat nebo dokonce převyšovat samotné váhy. To je jediný nejčastější důvod, proč model, který by „měl sedět“, uprostřed generování vyhodí chybu out-of-memory.

Vzorec, 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)

Vezměme Llama 3.3 70B: 80 vrstev, 8 KV hlav, dimenze hlavy 128, takže kv_dim je 1024. Při FP16 je to 80 × 2 × 1024 × 2 = 327 680 bajtů na token, což je asi 0,31 MB. Vynásobte délkou kontextu a příběh se píše sám: při 8K tocenech je cache zhruba 2,6 GB, při 32K je to asi 10 GB a při 128K naroste na kolem 41 GB. Toto poslední číslo je navíc k 40 GB vah, takže „model o velikosti 40 GB“ se tiše stane problémem o velikosti 80 GB ve chvíli, kdy zaplníte okno.

Dvě praktická východiska. Grouped-query attention (který používá každý nedávný model) již drasticky snižuje kv_dim oproti starému designu s více hlavami, takže moderní modely jsou v tomto ohledu mnohem laskavější než Llama 2. A většina inference engineů dokáže kvantizovat KV cache na 8bitovou nebo 4bitovou, čímž se její velikost sníží na polovinu nebo čtvrtinu za cenu malé ztráty kvality. Pokud nasazujete dlouhé kontexty v produkci, srovnání vLLM vs SGLang popisuje, který backend spravuje tuto paměť nejefektivněji pomocí paged attention.

Modely MoE: Proč „aktivní parametry“ nezachrání VRAM

To je past, která lidi stojí nejvíce peněz. Model Mixture-of-Experts, jako je DeepSeek-V3.2 (671B celkem, 37B aktivních, sdílí architekturu V3) nebo GLM-5.2 (744B celkem, 40B aktivních), směruje každý token prostřednictvím malé podmnožiny svých expertů. Marketing se opírá o aktivní číslo, protože popisuje rychlost: platíte pouze výpočetní výkon za 37 miliard parametrů na token, takže inference je rychlá vzhledem k velikosti modelu. Ale každý expert musí sedět v paměti, připraven k výběru, což znamená, že váš rozpočet na VRAM je určen celkovým počtem parametrů, nikoli aktivním.

Takže upřímné čtení výše uvedené tabulky: GLM-5.2 běží rychlostí modelu o velikosti 40B, ale zabírá paměť modelu o velikosti 744B. Proto tyto špičkové open-source modely potřebují server s 8 GPU nebo velký stroj s unified memory, i když jeden forward pass je levný. Qwen3-235B-A22B má stejný tvar v menším měřítku, rychlý na token, náročný na hostování.

Výhoda MoE se projeví na hardwaru s unified memory. Mac Studio s 512 GB unified memory může udržet model 671B při Q4 a stále jej provozovat použitelnou rychlostí právě proto, že se aktivuje pouze 37B, takže požadavek na paměťovou propustnost na token zůstává rozumný. Pokud teprve začínáte s lokálním provozem těchto modelů, začněte naším průvodcem nastavením lokálního LLM, než utratíte peníze za hardware.

Jakou kvantizaci byste měli vybrat?

Pro téměř každého je Q4_K_M správnou výchozí volbou: udržuje kvalitu blízkou plné přesnosti, zatímco footprint FP16 zmenšuje asi 4x. Přejděte na Q5_K_M nebo Q8 pouze tehdy, pokud máte rezervu ve VRAM a úkol citlivý na kvalitu, a sáhněte po FP16 pouze při fine-tuningu nebo benchmarkingu vůči referenci. Pod Q4 se degradace kvality rychle stává znatelnou, takže Q3 a nižší jsou poslední možností pro vmáčknutí modelu na kartu, která je opravdu příliš malá.

Jedno upozornění: kvalita kvantizace není u všech modelů identická. Velmi malé modely (pod 4B) cítí Q4 více než ty velké, protože mají méně redundance, kterou by mohly obětovat. U modelu 70B je rozdíl mezi Q4 a Q8 na většině úkolů těžko rozeznatelný. U modelu 1,7B je rozdíl reálný.

Jaké GPU skutečně potřebujete?

Spařte sloupec Q4 z hlavní tabulky s kartou, která má malou rezervu pro KV cache. Zde je praktické mapování od budgetového spotřebitelského hardwaru až po datacentrum, včetně tieru modelu, který každá třída pohodlně spustí při Q4.

Apple Silicon si zasluhuje zvláštní zmínku, protože unified memory mění kalkulus. Mac nerozděluje VRAM od systémové RAM, takže stroj M-series se 128 GB může načíst modely, které by jinak potřebovaly více diskrétních GPU, a vyměňuje špičkovou propustnost za schopnost vejít se s obrovskými vahami na jeden desktop. Pro backendy, které z těchto karet vytěží maximum, náš přehled nejlepších nástrojů pro lokální běh LLM benchmarkuje rozdíly v reálné rychlosti.

Jak určujeme velikost VRAM pro klientské nasazení

Ve společnosti Techsy nasazujeme open-source modely pro klienty tak často, že určování velikosti VRAM je první konverzací, před výběrem modelu, před prompty, před čímkoli jiným. Naše metoda je záměrně nudná, protože režim selhání (OOM v produkci pod reálným zatížením kontextu) je drahý. Zde je proces, který skutečně provádíme.

Začínáme matematikou z tabulky, poté měříme. Po načtení modelu kontrolujeme skutečný residentní footprint, místo abychom věřili odhadu:

# 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

Poučení, které se neustále opakuje: týmy určují velikost pro váhy a zapomínají na KV cache, pak se diví, proč model, který se načtl v pořádku, zemře tři dlouhé requesty do dema. Určujeme velikost pro váhy plus KV cache při maximálním kontextu, který aplikace skutečně použije, plus rezerva, a omezujeme --ctx-size, aby rogue request nemohl způsobit OOM boxu. Pro cokoli zákaznicky orientovaného raději provozujeme kvantizovaný 32B, který nikdy nespadne, než FP16 70B, který pod zátěží dostane OOM.

Pokud zvažujete, zda self-hostovat open-source model, nebo zůstat u hostovaného API, tento trade-off (náklady na hardware a operační zátěž versus cena za token a kontrola) je přesně to, co náš tým scopinguje během AI integračního engagementu. Pokud by vám pomohlo, když někdo provede výpočty proti vaší skutečné zátěži, získejte bezplatnou konzultaci a spočítáme to s vámi.

O autorovi

Mert Batur Gurbuz je spoluzakladatelem Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o stacku nástrojů pro LLM, který tým Techsy skutečně používá v produkci.

Kredence: Spoluzakladatel, Techsy.io, University of Birmingham. Spoňte se na LinkedIn.

Často kladené otázky

Kolik VRAM potřebuji ke spuštění modelu 70B?

Hustý model 70B, jako je Llama 3.3 70B, potřebuje při Q4_K_M asi 40 GB VRAM pro váhy, takže počítejte s kartou 48 GB (RTX 6000 Ada) nebo dvěma kartami 24 GB. Přidejte několik gigabajtů navíc pro KV cache, pokud používáte dlouhý kontext, což posouvá praktické požadavky směrem k 48 GB nebo více.

Kolik VRAM potřebuje Llama, Qwen nebo DeepSeek?

Záleží zcela na variantě. Llama 4 Scout potřebuje při Q4 asi 62 GB, Qwen3-32B asi 18 GB a Qwen3-8B pod 5 GB. DeepSeek-V3.2, 671B MoE, potřebuje zhruba 382 GB, protože se musí načíst každý expert. U modelů MoE vždy kontrolujte celkový počet parametrů, ne aktivní.

Mohu spustit LLM na GPU s 8 GB?

Ano, pohodlně. Karta s 8 GB, jako je RTX 4060, spustí modely až do velikosti asi 12 miliard parametrů při Q4_K_M. Gemma 4 12B se vejde do zhruba 6,8 GB, což ponechává prostor pro modestní kontext. Pro cokoli většího buď kvantizujete tvrději, udržujete krátký kontext, nebo přejdete na větší kartu.

Co zvládne GPU s 24 GB, jako je RTX 4090?

Karta s 24 GB zvládne husté modely až do velikosti asi 32B při Q4_K_M s rezervou pro rozumný kontext, takže Qwen3-32B a Mistral Small 3.2 24B jsou pohodlné. Spustí také Qwen3-30B-A3B MoE, který načte 30B vah, ale generuje rychlostí modelu 3B díky sparse aktivaci.

Škodí kvantizace kvalitě modelu?

Při Q4_K_M a vyšší je ztráta kvality malá a často nepostřehnutelná na reálných úkolech, zejména u modelů nad 13B. Mezera se zvětšuje, jak jdete níže a jak jsou modely menší, takže Q4 na 70B je téměř zdarma, zatímco Q4 na 1,7B je znatelné. Q8 je efektivně bezztrátové, pokud máte paměť.

Potřebují modely MoE méně VRAM než husté modely?

Ne, a toto je nejčastější mylná představa. Model Mixture-of-Experts musí udržet každého experta ve VRAM, takže jeho paměť je určena celkovým počtem parametrů. Údaj o aktivních parametrech popisuje pouze rychlost inference. GLM-5.2 běží rychlostí modelu 40B, ale potřebuje paměť modelu 744B.

Je unified memory totéž co VRAM?

Funkčně, pro načítání modelů, ano. Apple Silicon a některé jiné systémy sdílejí jednu paměťovou pool mezi CPU a GPU, takže Mac s 128 GB může načíst modely, které by jinak potřebovaly více diskrétních GPU. Trade-offem je šířka pásma: unified memory obvykle poskytuje nižší špičkovou propustnost než high-end datacentrová GPU, takže tokens-per-second je nižší.

Mohu offloadovat část modelu do systémové RAM nebo CPU?

Ano. Enginy jako llama.cpp a Ollama umožňují udržet některé vrstvy na GPU a zbytek v systémové RAM pomocí flagu jako --n-gpu-layers. Umožňuje to spustit model, který je příliš velký pro vaši VRAM, ale každá vrstva na CPU prudce zpomaluje generování, takže ji používejte k tomu, aby byl model možný, ne rychlý.

Jak vypočítám VRAM pro model, který není v tabulce?

Vynásobte počet parametrů v miliardách bity na váhu pro vaši kvantizaci a poté vydělte 8. Pro Q4_K_M použijte asi 4,5 bitu, takže model 40B potřebuje 40 × 4,5 ÷ 8 = asi 22,5 GB pro váhy. Přidejte zhruba 15–20 % režie plus vaši KV cache pro skutečný požadavek.