Kalkulator VRAM dla modeli AI

32 GiB

Szacuje zapotrzebowanie na pamięć przy jednoczesnym załadowaniu kilku modeli. KV cache liczony z rzeczywistej architektury (warstwy × głowice KV × wymiar głowicy), a nie z samej liczby parametrów.

Ustawienia globalne

Precyzja KV cache: FP8 zmniejsza bufor kontekstu o połowę względem FP16 (wsparcie sprzętowe od architektury Ada / Blackwell).

Co oznaczają te ustawienia?

Precyzja KV cache — ile bajtów zajmuje jedna liczba w pamięci kontekstu. FP8 to te same dane zapisane drobniej: połowa miejsca przy minimalnej stracie jakości.

Narzut systemu — liczony raz. Pulpit, przeglądarka i kompozytor okien zajmują VRAM, zanim uruchomisz jakikolwiek model.

Narzut na proces — liczony razy liczba modeli. Każda instancja (Ollama, llama.cpp, vLLM) dostaje własny kontekst CUDA — sterownik rezerwuje 0,3–0,5 GiB niezależnie od wielkości modelu — plus bufory obliczeniowe na wyniki pośrednie. Jeśli trzymasz wszystkie modele w jednym procesie, zjedź do 0,2.

Margines fragmentacji — procent doliczany do całości. Alokator nie upycha bloków idealnie; między nimi zostają nieużywane dziury.

Narzut na proces to reguła kciuka, nie zmierzona stała — inaczej niż mnożniki wag. Zmierz własny: uruchom jeden model i porównaj nvidia-smi --query-gpu=memory.used --format=csv z sumą wag i KV cache z tabeli obok.

Modele załadowane jednocześnie

Całkowite zużycie VRAM

0,0 / 32 GiB
—

Alokacja pamięci

032 GiB

Rozbicie na składniki (GiB). Kolumna „tok/s” to szacunek limitu przepustowości pamięci.
SkładnikWagiKV cacheNarzutRazem~tok/s
Razem

Karta graficzna

Jak to jest liczone

KV cache = 2 × warstwy × głowice_KV × wymiar_głowicy × tokeny × bajty/element, liczone osobno dla warstw globalnych (pełny kontekst) i lokalnych (przycięte do okna). Modele z GQA mają 4–8× mniej głowic KV niż głowic uwagi, więc szacowanie KV cache z samej liczby parametrów zawyża wynik wielokrotnie.

Wagi = parametry × efektywne bajty/wagę. Mnożniki są kalibrowane na realnych plikach modeli klasy 8B, więc uwzględniają skale kwantyzacji i warstwy trzymane w wyższej precyzji.

Czego kalkulator nie modeluje:

  • Uwaga liniowa (Qwen3.6 / 3.8, Mamba, GDN) — te warstwy mają stan o stałym rozmiarze, tu pominięty. Realnie doda ok. 0,1–0,5 GiB.
  • MLA (DeepSeek V2/V3/V4) — kompresja KV nawet kilkunastokrotna, wymaga innego wzoru.
  • Modele OCR i VLM — podane parametry obejmują już wieżę wizyjną, więc wagi się zgadzają. Pamiętaj jednak, że obraz zjada kontekst: strona A4 to zwykle 1–2 tys. tokenów (DeepSeek-OCR kompresuje do ok. 100–800). Przy wsadowym przetwarzaniu ustaw kontekst na tyle stron naraz, ile faktycznie podajesz.
  • Kwantyzacja małych modeli — poniżej ~2 mld parametrów schodzenie do 4 bitów wyraźnie psuje jakość, a oszczędza ułamek GiB. Modele OCR i mowy trzymaj raczej w FP16 lub FP8.
  • Modele mowy — „kontekst” oznacza tu tokeny audio, nie słowa. XTTS mieści ok. 1000 tokenów (ok. 20 s mowy), Whisper generuje maks. 448 naraz, więc najniższa pozycja z listy i tak je przeszacowuje. Modele typu VITS (MMS-TTS, Piper) nie są autoregresyjne i nie mają KV cache — ustaw im rolę „embedding”.
  • Presety odczytane z config.json (sierpień 2026) — przy nowym modelu zweryfikuj wartości, architektury zmieniają się co kwartał.