Model waży 20 GB, karta ma 24 GB. Przy trzecim użytkowniku wszystko zjeżdża na CPU

Karta ma 24 GB pamięci, model w kwantyzacji Q4_K_M waży 20 GB, więc arytmetyka wydaje się domknięta. Po przepięciu firmowego asystenta z jednego testera na pięcioosobowy zespół prędkość generowania spada z kilkudziesięciu tokenów na sekundę do kilku, a ollama ps zamiast „100% GPU” pokazuje podział w rodzaju „48%/52% CPU/GPU”. Nic się nie zepsuło i nic nie trzeba wymieniać w pierwszej kolejności. Zabrakło miejsca na pamięć podręczną kluczy i wartości — składnik, którego w kalkulacji przed zakupem nie było, bo policzono wyłącznie wagi modelu.

Ten tekst pokazuje, jak policzyć zapotrzebowanie na VRAM zanim sprzęt trafi do serwerowni: skąd bierze się drugi składnik rachunku, jak mnoży go liczba równoległych użytkowników i co da się zrobić, gdy budżet pamięci się nie domyka. Wszystkie wartości domyślne opisane niżej pochodzą z dokumentacji producentów, zweryfikowanej 24 września 2026 — to akurat warstwa, która zmienia się między wydaniami, więc przy własnym wdrożeniu sprawdź je ponownie.

Trzy składniki zajętości VRAM

Pamięć karty pod obciążeniem inferencyjnym dzieli się na trzy części, a tylko pierwsza jest stała i łatwa do sprawdzenia.

• Wagi modelu. Wielkość pliku po kwantyzacji. Dla rodziny Qwen3 w domyślnej kwantyzacji biblioteka Ollamy podaje 5,2 GB dla wariantu 8B, 9,3 GB dla 14B i 20 GB dla 32B. Ta liczba nie zależy od tego, ilu masz użytkowników.
• KV cache. Pamięć podręczna kluczy i wartości, w której model trzyma stan całej dotychczasowej rozmowy. Rośnie liniowo z długością kontekstu i liniowo z liczbą jednocześnie obsługiwanych rozmów. To ten składnik przewraca planowanie.
• Bufor obliczeniowy i kontekst sterownika. Aktywacje, bufory backendu, kontekst CUDA. Rząd wielkości to zwykle 1–2 GB, ale konkretna wartość zależy od backendu, wersji sterownika i tego, czy włączona jest flash attention. Tej pozycji nie da się policzyć z parametrów modelu — trzeba ją zmierzyć na własnej maszynie.

Pierwszy składnik jest publiczny, trzeci trzeba zmierzyć, a drugi da się wyliczyć z konfiguracji modelu z dokładnością wystarczającą do decyzji zakupowej.

KV cache: wzór i liczby dla trzech modeli

Zapotrzebowanie KV cache na jeden token wynosi: 2 × liczba warstw × liczba głowic KV × wymiar głowicy × liczba bajtów na element. Dwójka na początku bierze się stąd, że dla każdej warstwy zapisywane są osobno klucze i wartości. Liczba bajtów to 2 przy FP16, czyli przy ustawieniu domyślnym.

Istotne jest, że we wzorze występuje liczba głowic KV, a nie głowic uwagi. Współczesne modele używają grouped-query attention, w którym głowic KV jest wielokrotnie mniej niż głowic uwagi — w Qwen3-32B jest ich 8 wobec 64 głowic uwagi, co zmniejsza cache ośmiokrotnie względem klasycznej architektury. Wszystkie trzy potrzebne parametry są jawne w pliku config.json na karcie modelu.

Ostatnia kolumna jest sednem problemu. Model o wagach 20 GB przy kontekście 32 tysięcy tokenów potrzebuje dodatkowych 8 GiB na jedną rozmowę. Karta 24 GB nie ma tyle wolnego miejsca po załadowaniu wag, niezależnie od tego, ilu ludzi z niej korzysta.

Mnożnik równoległości

Druga pułapka siedzi w ustawieniach serwera inferencyjnego, nie w modelu. Dokumentacja Ollamy podaje, że domyślny rozmiar okna kontekstu to 4096 tokenów, a OLLAMA_NUM_PARALLEL ma wartość domyślną 1, przy czym — cytując wprost — zapotrzebowanie na pamięć skaluje się jako iloczyn OLLAMA_NUM_PARALLEL i OLLAMA_CONTEXT_LENGTH.

To oznacza, że dwa niezależne ustawienia mnożą się przez siebie. Zespół, który podniósł kontekst do 32 tysięcy tokenów, bo asystent gubił wątek przy dłuższych dokumentach, i równolegle ustawił cztery jednoczesne żądania, bo zgłaszano kolejkowanie, zamówił 32 GiB samego KV cache. Żadna z tych dwóch zmian z osobna nie wyglądała na decyzję sprzętową.

Dwie uwagi do tej tabeli. Bufor przyjęto jako 1,5 GB, co jest założeniem rzędu wielkości, a nie pomiarem — u siebie odczytaj różnicę między zajętością raportowaną przez kartę a sumą wag i KV cache. Druga rzecz: rozmiary plików producenci podają w gigabajtach dziesiętnych, a pamięć karty liczy się w gibibajtach, co daje około 7 procent rozjazdu. Przy planowaniu potraktuj tę różnicę jako część zapasu, nie jako miejsce do wykorzystania.

Wniosek z tabeli jest niewygodny, ale jednoznaczny: konfiguracja, w której model 32B działa na karcie 24 GB, to konfiguracja jednoosobowa z krótkim kontekstem. Do obsługi zespołu przy sensownym oknie kontekstu trzeba albo mniejszego modelu, albo karty z 48 GB, albo dwóch kart. Każde z tych wyjść to wydatek, który trzeba zestawić z mierzalnym efektem wdrożenia, a przeliczenie wyniku pilotażu na pieniądze jest tu trudniejsze niż sam rachunek pamięci.

Osobna sprawa to liczba, którą wstawia się w kolumnę „równoległe żądania”. Najczęstszy błąd polega na wpisaniu tam liczby pracowników. Jednoczesność to nie to samo co liczba kont: znaczenie ma, ile żądań nakłada się na siebie w czasie, a pojedyncza odpowiedź zajmuje kilka do kilkunastu sekund. Przy dwudziestu osobach sięgających po asystenta kilka razy dziennie szczyt jednoczesności bywa rzędu dwóch–trzech. Da się to policzyć z logów serwera: dla każdego żądania weź znacznik startu i końca, a następnie znajdź maksymalną liczbę przedziałów pokrywających się w jednym momencie. Jeśli logów jeszcze nie ma, bo wdrożenie dopiero powstaje, przyjmij ostrożne oszacowanie i zaplanuj pomiar po pierwszym miesiącu — z zastrzeżeniem, że to jest wtedy założenie, a nie dana.

Warto rozdzielić przy tym dwa tryby pracy, bo mają różne profile. Asystent w oknie czatu generuje krótkie, rozłożone w czasie zapytania i rzadko daje wysoki szczyt. Przetwarzanie wsadowe — przepuszczenie przez model katalogu dokumentów — generuje jednoczesność równą ustawionej równoległości, przez cały czas trwania zadania. Jeżeli oba tryby mają dzielić jedną kartę, budżet trzeba policzyć dla wariantu wsadowego, bo to on wyznacza szczyt.

Zachowanie serwera po przekroczeniu budżetu

Przekroczenie dostępnej pamięci nie kończy się jednakowo w każdym silniku i to jest powód, dla którego objawy bywają mylące.

Ollama przy braku miejsca rozkłada model między urządzenia. W dokumentacji opisano, że kolumna Processor w wyniku ollama ps pokazuje wtedy podział procentowy w rodzaju „48%/52% CPU/GPU”. Nie pojawia się błąd — pojawia się kilkukrotnie wolniejsza generacja, bo część warstw liczy się na procesorze. Zespół zgłasza „model zwolnił”, administrator nie widzi żadnego wyjątku w logach, a przyczyną jest po prostu przekroczony budżet VRAM.

vLLM zachowuje się inaczej: rezerwuje pulę pamięci z góry i przy niedoborze wywłaszcza żądania. Dokumentacja podaje komunikat „Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space” i zaleca w takiej sytuacji podniesienie gpu_memory_utilization albo obniżenie max_num_seqs lub max_num_batched_tokens. Wywłaszczone żądanie jest przeliczane od nowa, co widać jako skokowe wydłużenie czasu odpowiedzi przy części zapytań, przy normalnych czasach dla reszty. Wartości domyślnej gpu_memory_utilization nie podaję, bo bywała zmieniana między wydaniami — odczytaj ją z dokumentacji swojej wersji.

Praktyczna konsekwencja: jeśli w umowie z klientem albo w wewnętrznym SLA jest zapis o czasie odpowiedzi, sam pomiar średniej niczego nie wykryje. Wywłaszczanie widać dopiero w rozkładzie, w okolicach 95. percentyla.

Redukcja zapotrzebowania bez wymiany sprzętu

Zanim trafi do koszyka droższa karta, są trzy dźwignie o różnym koszcie jakościowym.

Kwantyzacja KV cache. Dokumentacja Ollamy opisuje zmienną OLLAMA_KV_CACHE_TYPE z wartością domyślną f16 oraz opcjami q8_0, zużywającą około połowy pamięci f16, i q4_0, zużywającą około jednej czwartej. Dla Qwen3-32B przy 32 tysiącach tokenów oznacza to spadek z 8 GiB do około 4 GiB przy q8_0. Wpływ na jakość odpowiedzi zależy od modelu i zadania i nie jest liniowy — to zmiana, którą trzeba przetestować na własnym zbiorze zapytań, a nie przyjąć na wiarę.

Flash attention. Wymuszana przez OLLAMA_FLASH_ATTENTION=1, zmniejsza zużycie pamięci na bufory pośrednie przy długich sekwencjach. Zysk zależy od modelu i długości kontekstu, więc podanie tu jednej liczby byłoby zgadywaniem.

Uczciwe okno kontekstu. Najtańsza dźwignia i najczęściej pomijana. Kontekst 32 tysięcy tokenów ustawia się zwykle „na zapas”, a realne zapytania zajmują ułamek tego okna. Zmierz rozkład długości faktycznych rozmów w logach i ustaw okno na poziomie wysokiego percentyla, nie maksimum. Różnica między 32 768 a 8 192 tokenami to dla modelu 32B sześć gibibajtów na każde równoległe żądanie.

Czwarta możliwość jest strukturalna: mniejszy model o wyższej kwantyzacji często wygrywa z większym modelem zepchniętym częściowo na CPU. Qwen3-14B w q8_0 zmieści się na karcie 24 GB z sensownym kontekstem i będzie działać w całości na GPU. Który wariant daje lepsze odpowiedzi dla konkretnego zastosowania, rozstrzyga test na własnych danych.

Piąta dotyczy maszyn z dwiema kartami i bywa źle rozumiana. Dokumentacja vLLM wskazuje, że zwiększenie tensor_parallel_size dzieli wagi modelu między karty, dzięki czemu na każdej zostaje więcej miejsca na KV cache. Efekt nie polega więc na tym, że dwie karty po 24 GB zachowują się jak jedna z 48 GB — wagi są dzielone, ale każda karta utrzymuje własną część cache, a między urządzeniami dochodzi narzut komunikacji. Ollama działa tu inaczej: jej dokumentacja opisuje, że model mieszczący się w całości na jednej karcie zostanie na niej załadowany, a dopiero model, który się nie mieści, jest rozkładany na wszystkie dostępne karty. Przy dwóch kartach i modelu mieszczącym się na jednej opłaca się to sprawdzić, bo domyślne zachowanie może zostawić drugą kartę nietkniętą.

Procedura liczenia budżetu VRAM

Kolejność, która pozwala podjąć decyzję zakupową na liczbach, a nie na rekomendacji z forum:

• Ustal rozmiar wag w docelowej kwantyzacji — z biblioteki modeli albo z rozmiaru pliku GGUF.
• Odczytaj num_hidden_layers, num_key_value_heads i head_dim z config.json modelu.
• Policz KV na token: 2 × warstwy × głowice KV × head_dim × 2 bajty.
• Zmierz w logach rozkład długości rozmów i wybierz okno kontekstu na poziomie 90.–95. percentyla, zamiast przyjmować maksimum modelu.
• Ustal realną liczbę jednoczesnych rozmów — nie liczbę pracowników, tylko szczyt jednoczesności. Przy dwudziestu osobach korzystających sporadycznie szczyt bywa rzędu trzech.
• Pomnóż: KV na token × okno kontekstu × jednoczesne rozmowy. Dodaj wagi i 1,5–2 GB bufora.
• Porównaj z pamięcią karty i zostaw co najmniej 10 procent zapasu. Budżet domknięty co do gigabajta rozsypie się przy pierwszej aktualizacji sterownika.

Po uruchomieniu zweryfikuj rachunek w praktyce: ollama ps ma pokazywać „100% GPU”, a w vLLM w logach nie mogą pojawiać się komunikaty o wywłaszczaniu. Oba sygnały są binarne i nie wymagają interpretacji.

Czego ten rachunek nie rozstrzyga

Policzony budżet VRAM odpowiada na pytanie „czy to się zmieści i z iloma użytkownikami”. Nie odpowiada na pytanie, czy model lokalny jest w danym przypadku właściwym rozwiązaniem. Jeżeli przesłanką wdrożenia było ograniczenie wypływu danych, zostaje do rozstrzygnięcia, czy własny serwer jest najtańszą drogą do tego celu, czy wystarczy zmiana planu i konfiguracji u obecnego dostawcy. Po stronie dostawcy trzeba wtedy wziąć pod uwagę także to, że sposób naliczania potrafi się zmienić w trakcie umowy, co przy własnym sprzęcie zamienia się na inne ryzyko: koszt utrzymania i dostępność kompetencji.

Osobno zostaje pytanie, kto w organizacji odpowiada za skutki tej decyzji — za nadzór nad tym, co model przetwarza, i za to, komu wolno go rozszerzać o kolejne dane. To rola do obsadzenia przed uruchomieniem serwera, nie po pierwszym incydencie; podziałem tych odpowiedzialności zajmuje się doradztwo w zakresie nadzoru nad wdrożeniami AI.

Rachunek nie mówi też nic o przepustowości. Model, który mieści się w pamięci, nie jest automatycznie modelem, który obsłuży zespół w akceptowalnym czasie — to zależy od przepustowości pamięci karty i od długości promptów. Pojemność i szybkość to dwa osobne ograniczenia, a domknąć trzeba najpierw pojemność: dopóki część warstw ląduje na procesorze, pomiar szybkości mierzy skutek złego budżetu pamięci, a nie możliwości karty.

Decyzja do podjęcia

Otwórz config.json modelu, który chcesz uruchomić, policz KV na token z podanego wzoru i pomnóż przez okno kontekstu oraz szczyt jednoczesnych rozmów. Jeśli suma z wagami i buforem przekracza pamięć karty, masz cztery wyjścia i trzeba wybrać jedno przed zakupem: skrócić okno kontekstu, włączyć kwantyzację KV cache i przetestować jakość, zejść o klasę niżej w rozmiarze modelu albo kupić kartę z 48 GB. Piąte wyjście — uruchomić tak, jak jest, i liczyć, że się zmieści — kończy się modelem rozłożonym między CPU a GPU i zespołem, który przestaje z niego korzystać, bo odpowiedź przychodzi po minucie.