Keď sa klient pýta „aká GPU na lokálny LLM", väčšinou má na mysli jednu otázku: zmestí sa mi model, ktorý chcem používať? Odpoveď závisí od troch čísel — veľkosť váh modelu, veľkosť KV cache pri danom kontexte a overhead frameworku. Všetky tri sa dajú spočítať dopredu. Napriek tomu väčšina rozhodnutí o hardware prebieha odhadom, a výsledok je buď zbytočne drahý server, alebo server ktorý nestačí.
Tento článok dáva konkrétne čísla: koľko VRAM reálne zaberie 7B, 13B, 34B a 70B model pri rôznych formátoch kvantizácie, čo sa zmestí na 24 GB / 48 GB / 80 GB kartu, a kedy má zmysel ísť na multi-GPU.
Základný vzorec: váhy modelu
Najjednoduchší odhad VRAM pre samotné váhy:
VRAM (GB) ≈ (počet parametrov v miliardách × počet bitov) / 8Príklady: - 7B model, FP16 (16 bitov): 7 × 16 / 8 = 14 GB (v praxi s overhead-om ~16–18 GB) - 7B model, Q4_K_M (4 bity): 7 × 4 / 8 = 3,5 GB — v praxi kvôli overhead-u okolo 5–7 GB - 70B model, FP16: 70 × 16 / 8 = 140 GB - 70B model, Q4_K_M: 70 × 4 / 8 = 35 GB — v praxi okolo 38–40 GB
Vzorec pre váhy je len základ. Nad neho sa vždy pripočíta KV cache, overhead serving frameworku a v prípade kvantizácie aj dequantizačné buffery.
Čo je KV cache a prečo je dôležitý
Počas inferencie model generuje tokeny jeden po druhom. Aby nemusel pre každý nový token prepočítavať celú sekvenciu, ukladá medzivýsledky — takzvané key-value páry pre každú vrstvu pozornosti (attention layer). Tieto medzivýsledky tvoria KV cache.
KV cache rastie lineárne s dĺžkou sekvencie. Pre produkčné nasadenie so súbežnými requestmi sa rýchlo stáva rovnako veľkým problémom ako samotné váhy.
Orientačné veľkosti KV cache pre bežné modely:
- 7B model, 8K kontext, 1 paralelný request: ~1–2 GB
- 7B model, 32K kontext, 4 paralelné requesty: ~8–16 GB
- 70B model, 32K kontext, 1 request: ~8–12 GB
- 70B model, 128K kontext, 1 request: ~40 GB
Čísla závisia od počtu attention vrstiev, počtu hlavičiek a skupín (moderné modely používajú Grouped Query Attention, GQA, ktoré KV cache dramaticky znižuje oproti staršiemu multi-head attention). Každý model má iný multiplikátor — skontrolujte konfiguračný súbor modelu (config.json v HuggingFace repozitári) pred výberom hardware.
Praktický dôsledok: ak plánujete dlhé kontexty alebo väčší počet súbežných používateľov, KV cache rozhoduje rovnako ako váhy. Nie je to technický detail — je to primárna príčina OOM chýb pri nasadzovaní.
Čo sa zmestí na 24 GB (RTX 4090, L4)
24 GB je najbežnejší tier pre on-prem vývojové a menšie produkčné nasadenia.
Čo sa zmestí pohodlne: - 7B FP16 — váhy ~16–18 GB, zostatok pre KV cache (~6 GB) postačuje pre stredné kontexty (8–16K) s malým súbežným požiadavkám - 7B Q8_0 — váhy ~8–9 GB, KV cache má dosť priestoru aj pri 32K kontexte - 13B Q4_K_M — váhy ~8 GB, KV cache pri 8K veľký priestor - 13B Q8_0 — váhy ~14 GB, tesnejšie, ale zmestí sa pri kratších kontextoch
Čo sa nezmestí: - 13B FP16 — váhy ~26 GB, presahuje kapacitu - 34B akýkoľvek bežný formát — ani pri Q4 sa váhy (~17–20 GB) + KV cache do 24 GB nezmestia pri reálnom workloade
Pre 24 GB kartu je Q4_K_M prakticky štandard pri 13B modeloch, pre 7B máte slobodu voliť Q8 alebo FP16 podľa toho, koľko kontextu potrebujete.
Čo sa zmestí na 48 GB (RTX 6000 Ada, A40, L40S)
48 GB otvára zmysluplný priestor pre väčšie modely.
Čo funguje dobre: - 13B FP16 — zmestí sa pohodlne, zostatok pre KV cache postačuje pri 16–32K kontexte - 34B Q4_K_M — váhy ~17–20 GB, dostatok pre produkčný KV cache - 34B Q8_0 — váhy ~30–34 GB, tesné, ale pri kratších kontextoch funkčné - 70B Q4_K_M — váhy ~38–40 GB, zostatok pre KV cache (~6–10 GB) obmedzuje na krátke kontexty (4–8K) alebo 1 paralelný request
Čo nie je ideálne: - 70B FP16 — 140 GB, trojnásobok kapacity - 70B Q8_0 — ~70–75 GB, stále presahuje
48 GB karta vie obsluhovať 70B model v Q4_K_M, ale s obmedzeným kontextom. Pre väčšinu B2B use-casov — RAG nad dokumentmi, klasifikácia, štruktúrovaná extrakcia — kratší kontext (do 8K) postačuje.
Čo sa zmestí na 80 GB (A100, H100, H200)
80 GB je tier, kde väčšina produkčných nasadení 70B modelov beží bez kompromisov.
- 70B FP16 — váhy ~140 GB, nezmestí sa ani tu. Potrebujete aspoň dva kusy.
- 70B Q8_0 — váhy ~70–75 GB, zmestí sa, ostáva ~5–10 GB pre KV cache — obmedzuje na veľmi krátke kontexty alebo 1 request
- 70B Q4_K_M — váhy ~38–40 GB, zostatok ~38–40 GB pre KV cache — pohodlné pre 32K kontext, 2–4 súbežné requesty
- 34B FP16 — váhy ~54–68 GB, zmestí sa s obstojným KV cache priestorom
Na H100 80GB pri 70B Q4_K_M s vLLM alebo SGLang dostanete produkčný serving s throughput-om vhodným pre desiatky súbežných používateľov.
Kvantizácia: kde ušetriť bez straty kvality
Kvantizácia znižuje presnosť váh (z FP16/BF16 na INT8, INT4 a pod.) výmenou za menší VRAM footprint a rýchlejšiu inferenciu. Otázka nie je „či kvantizovať" — ale kde sa stráca kvalita a kde nie.
Orientačné zachovanie kvality voči FP16:
- Q8_0 (GGUF): ~98–99 % — takmer nerozoznateľné. Štandardná voľba keď máte dostatok VRAM.
- Q4_K_M (GGUF): ~92–95 % — sweet spot. Väčšina B2B use-casov (RAG, klasifikácia, extrakcia, čítanie dokumentov) nezaznamená rozdiel.
- AWQ 4-bit: ~93–96 % — mierne lepšie pre koherenciu textu a kód. Vyžaduje NVIDIA GPU, integruje sa čisto s
vLLM. - GPTQ 4-bit: ~90–93 % — maximálny throughput na NVIDIA stacku, trochu nižšia kvalita ako AWQ.
- Q2 (GGUF): výrazná degradácia — poznateľná na zložitom uvažovaní, dlhých generáciách, viacjazyčných textoch.
Rozdiel v perplexite medzi Q4 a BF16 je naprieč benchmarkmi pod 6 %. Pre väčšinu priemyselných use-casov je to zanedbateľné. Strata nastáva, keď model potrebuje presné viacstupňové uvažovanie alebo generuje dlhé súvislé texty — tam Q4 niekedy stratí niť oproti Q8.
Podrobne o formátoch kvantizácie, ich rozdieloch a prípadoch použitia si môžete prečítať v prehľade kvantizácie GGUF, AWQ, GPTQ.
Multi-GPU: kedy a ako
Keď model nevychádza na jednu kartu, máte dve možnosti: kvantizovať alebo pridať GPU. Niekedy potrebujete oboje.
Tensor parallelism — model sa rozdelí po vrstvách (alebo po pozornostných hlavičkách) medzi viacero GPU. vLLM a SGLang to zvládajú natívne. Pri dvoch A100 80GB dostanete efektívne 160 GB VRAM a môžete obsluhovať 70B FP16.
Pipeline parallelism — rôzne bloky modelu bežia na rôznych GPU za sebou. Menej efektívne ako tensor parallelism (idle čas pri prechode medzi kartami), ale funguje aj na kartách bez NVLink.
Praktické odporúčania: - 2× RTX 4090 (2× 24 GB = 48 GB): 34B Q4_K_M pohodlne, 70B Q4_K_M tesne — zmestí sa, KV cache obmedzený - 2× A100 80 GB (2× 80 GB = 160 GB): 70B FP16 bez kompromisov, 70B Q8_0 s bohatým KV cache - NVLink medzi kartami výrazne znižuje komunikačný overhead pri tensor parallelism — pre produkčné nasadenie preferovať karty s NVLink podporou (A100, H100, RTX 6000 Ada)
Väčšina consumer GPU (RTX 4090) NVLink nemá — komunikujú cez PCIe, čo zvyšuje latencію pri multi-GPU rozdeľovaní. Pre vývojové účely to postačuje, pre produkciu s nízkymi latenciami sa vyplatí investícia do workstation-class GPU.
Overhead serving frameworku
Nad váhy a KV cache sa pripočíta overhead samotného serving riešenia. vLLM používa PagedAttention — spravuje KV cache v stránkach ako OS spravuje pamäť, čo redukuje fragmentáciu z typických 60–80 % plytvania na menej ako 4 %. Napriek tomu rezervujte navyše:
- `vLLM` overhead: typicky 1–3 GB navyše na aktivačné buffery, prefetch a scheduling
- `SGLang` overhead: porovnateľný s vLLM, navyše RadixAttention strom pre prefix kešovanie
Pravidlo palca: počítajte s ~10–15 % rezervou nad odhadnutými váhami + KV cache. Pre 24 GB kartu to znamená cieliť na ~20–22 GB efektívneho využitia, nie na 24 GB.
Na rozdiel od produkčných frameworkov Ollama využíva llama.cpp pod kapotou — je excelentný pre vývojársky desktop a single-user experimenty, ale nie je navrhnutý pre súbežné requesty. Pre 8 paralelných používateľov je vLLM výrazne rýchlejší (cca 2–3×). Viac o rozdieloch medzi serving riešeniami nájdete v porovnaní vLLM vs SGLang vs Ollama.
Praktická referencia: čo na čo
Zhrnutie pre bežné scenáre:
Vývojárska pracovná stanica, single user: - 7B–13B modely, krátky kontext → 1× RTX 4090 (24 GB) s Q4_K_M alebo Q8_0 - 34B model → 2× RTX 4090 alebo 1× RTX 6000 Ada (48 GB) s Q4_K_M
Produkčný server, 5–20 súbežných používateľov: - 7B FP16 alebo Q8_0 → 1× A40 alebo L40S (48 GB) - 13B–34B Q4_K_M → 1× A40 alebo L40S - 70B Q4_K_M s krátkym kontextom → 1× A100 80 GB alebo H100 80 GB - 70B Q4_K_M s dlhým kontextom, vyšší throughput → 2× A100 alebo 2× H100
On-prem enterprise, regulované odvetvie: - Kvalita bez kompromisov → 70B Q8_0 alebo FP16 → 2× H100 80 GB (NVLink) - Ak má zmysel on-prem pre váš use-case z pohľadu GDPR a nákladov, pozrite sa aj na on-prem LLM pre regulované odvetvia
Pre každé z týchto rozhodnutí platí: výpočtová kapacita je len jedna strana rovnice. Rovnako dôležité je, čo od modelu chcete — a čo by model vedel, ak by bol správne dotrénaný na vaše dáta. O tom, kedy inštalovať väčšiu GPU a kedy radšej fine-tunovať menší model, hovoríme v článku malý fine-tuned vs veľký base model.
Časté otázky
Zmestí sa 70B model na jednu RTX 4090?
Nie zmysluplne. RTX 4090 má 24 GB VRAM. Váhy 70B modelu v Q4_K_M zaberajú okolo 38–40 GB — to je takmer dvojnásobok kapacity. Na inferenciu 70B modelu potrebujete buď dve karty (2× 24 GB cez PCIe tensor parallelism), alebo jednu 48 GB kartu, kde sa zmestí len pri obmedzenom kontexte.
Čo je rozdiel medzi VRAM GPU a systémovou RAM pri inferencii?
Model musí byť načítaný do VRAM GPU — systémová RAM ho nedokáže nahradiť pri GPU inferencii. CPU inference (cez llama.cpp bez GPU) funguje zo systémovej RAM, ale je rádovo pomalšia. Niektoré riešenia (napr. llama.cpp s partial offloading) načítajú časť vrstiev do VRAM a zvyšok ponechajú v RAM — prakticky použiteľné pre vývojárske experimenty, nie pre produkciu.
Koľko VRAM pridá dlhý kontext?
Záleží od modelu. Orientačne: pri 7B modeli každých 8K tokenov kontextu pridáva ~1–2 GB KV cache. Pri 70B modeli je to ~5–10 GB na každých 8K tokenov. Moderné modely s Grouped Query Attention (GQA) sú výrazne úspornejšie ako staršie. Pred kúpou hardware overte parametre num_key_value_heads v konfiguračnom súbore cieľového modelu.
Je kvantizácia Q4_K_M dostatočná pre firemné dokumenty a RAG?
Vo väčšine prípadov áno. Pre RAG nad firemnou dokumentáciou (extrakcia informácií, kategorizácia, sumarizácia) je rozdiel medzi Q4_K_M a FP16 v praxi ťažko merateľný. Degradácia nastáva pri zložitom viacstupňovom uvažovaní alebo pri generovaní dlhých súvislých textov. Ak máte pochybnosti, otestujte konkrétny use-case s Q4_K_M a porovnajte s Q8_0 — výsledok vás spravidla prekvapí.
Kedy ísť na multi-GPU namiesto väčšej jednej karty?
Väčšia jedna karta je spravidla lepšia voľba, ak existuje (nižší komunikačný overhead, jednoduchšia správa). Multi-GPU dáva zmysel, keď: (1) model fyzicky nevychádza na jednu kartu ani pri agresívnej kvantizácii, (2) potrebujete redundanciu pre high-availability, alebo (3) plánujete obslúžiť veľký počet súbežných requestov a throughput je primárna metrika.
*Výber správnej GPU pre lokálnu inferenciu je na prvý pohľad technická otázka — v skutočnosti je to architektonické rozhodnutie, ktoré ovplyvňuje náklady, kontextové okno, počet súbežných používateľov a dostupnosť systému. V MP Industrial Solutions pomáhame firmám prejsť od cieľového use-casu cez výber modelu až po konkrétne hardware odporúčanie — aj s kalkuláciou TCO oproti cloud API. Ak sa pripravujete na prvé on-prem nasadenie alebo prehodnocujete existujúci server, radi sa pozrieme na vaše čísla.*