Lokalne duże modele językowe na początku wydają się błyskawiczne. Wczytujesz model o 7 lub 13 miliardach parametrów, wysyłasz krótki prompt i tokeny płyną po ekranie w komfortowym tempie. Potem wklejasz długi blok kodu lub historia czatu rozrasta się do kilkunastu tur i model zaczyna pełznąć. Spowolnienie rzadko jest łagodne. To przepaść. W jednej chwili GPU generuje tokeny; w następnej monitor systemu pokazuje rosnące obciążenie pamięci, a generowanie zaczyna rwać. Nie da się dokładnie przewidzieć, kiedy to nastąpi, za pomocą prostego wzoru. Twoim jedynym wiarygodnym przewodnikiem jest sam sprzęt.

Ukryty koszt kontekstu

Każdy wygenerowany token dodaje stan do cache KV. Ten cache przechowuje klucze i wartości obliczone podczas faz prefillu i generowania, a znajduje się w pamięci obok wag modelu, buforów uwagi i narzutu czasu uruchomienia. Na typowej konsumenckiej karcie GPU z 12 GB lub 16 GB VRAM, cache KV ostatecznie zaczyna rywalizować o miejsce ze wszystkim innym. Gdy dedykowana pamięć wideo się zapełni, system operacyjny nie zgłasza błędu ani nie zatrzymuje pracy. Po cichu przelewa nadmiar do pamięci współdzielonej, przesyłając dane między GPU a pamięcią RAM systemu przez szynę PCIe. Ta szyna jest szybka przy transferach plików, ale jest ślamazarna w porównaniu z przepustowością pamięci wewnątrz karty graficznej. Wynikiem nie jest niewielki spadek wydajności. To kolaps.

Trzy sygnały, że przepaść została osiągnięta

Obserwuj monitory sprzętowe podczas pracy modelu. Gdy nastąpi spadek wydajności, zobaczysz trzy wyraźne sygnały.

  • Wzrost Shared VRAM. Jest to pamięć, którą sterownik GPU wypchnął z dedykowanej pamięci VRAM do puli zarządzanej przez system operacyjny. W momencie, gdy ten wskaźnik przekroczy zero, przekroczyłeś granicę.
  • Wzrost zużycia pamięci RAM systemu. Nadmiar musi gdzieś trafić, a tym miejscem jest Twoja pamięć główna. Jeśli zużycie RAM rośnie podczas generowania tokenów przez model, dane są przenoszone z GPU.
  • Spadek prędkości ewaluacji o połowę lub więcej. 10-procentowe spowolnienie może oznaczać thermal throttling lub procesy działające w tle. Spadek o 50% lub więcej oznacza, że wąskim gardłem przestały być rdzenie tensorowe, a stała się nim przepustowość pamięci i opóźnienia PCIe. Gdy widzisz, że prędkość generowania spada z dwucyfrowych na jednocyfrową, oznacza to, że już spadłeś w przepaść.

Dlaczego Twój szybki benchmark prawdopodobnie Cię oszukuje

Krótki test sprawdzający da Ci fałszywe poczucie pewności. Jeśli wykonasz benchmark modelu przy użyciu promptu o długości stu tokenów, zobaczysz zdrową przepustowość i uznasz sprawę za zamkniętą, zmierzyłeś jedynie fazę miodowego miesiąca. Cache KV jest prawie pusty. Warstwy nie zostały obciążone długim prefillem. Prawdziwe zapotrzebowanie na zasoby ujawnia się dopiero po przetworzeniu przez model znacznego promptu i wypełnieniu cache do jego rzeczywistego rozmiaru roboczego. Musisz testować przy użyciu głębokiego prefillu i długich cykli generowania. Pozwól kontekstowi faktycznie się kumulować. Dopiero wtedy obciążenie pamięci się ustabilizuje i pokaże Ci rzeczywisty limit.

Znajdowanie limitu za pomocą llama.cpp

Jeśli uruchamiasz modele przez llama.cpp, możesz wyznaczyć swoją granicę za pomocą prostego działania i cierpliwego testu.

1. Zmierz zużycie pamięci współdzielonej.
Zapisz bazowe zużycie dedykowanej pamięci VRAM przy minimalnym prompcie, a następnie przeprowadź zadanie z długim kontekstem i zanotuj wartość szczytową. Odejmij wartość bazową od szczytowej. Różnica to ilość danych, które „wylały się” z Twojego GPU do współdzielonej pamięci systemu.

2. Oblicz deltę pamięci RAM.
Wykonaj to samo odejmowanie dla pamięci RAM systemu. Odejmij bazowe zużycie RAM od szczytowego zużycia RAM podczas długiego cyklu. Ta liczba powie Ci dokładnie, jak dużo danych zostało przesuniętych z karty graficznej do pamięci głównej. Kwantyfikuje ona wyciek przez szynę.

3. Zmierz czas kolapsu prędkości ewaluacji.
Porównaj swoją bazową prędkość tokenów na sekundę z prędkością po tym, jak model „przemieli” długi dokument. Możesz obserwować model pracujący z prędkością siedemnastu tokenów na sekundę, gdy kontekst jest świeży, a następnie dostarczający tylko dwa tokeny na sekundę, gdy cache spuchnie. Ten spadek o piętnaście tokenów to Twój kanarek w kopalni.

Triangulacja punktu krytycznego

To map the curve accurately, do not settle for one lonely data point. Run three distinct trials at 16,000 tokens, 32,000 tokens, and 65,000 tokens. Two points might suggest a line, but two dots are just a guess. The third point proves whether you are looking at measurement noise or a real memory wall. Subtract the results between runs to calculate how much extra memory each additional thousand tokens consumes on your specific combination of model, quantization layer, and GPU.

Once you have that slope, you can project forward. Take your per-token cost, multiply it by the target context length, divide by 1024 to move between units, and add the result to your base model VRAM load. The equation looks like this:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

This projection is not prophecy. It is a guidepost derived from actual behavior. Use it to estimate your ceiling before you commit to a full production run.

Why Paper Formulas Fail, and What Quantization Can Fix

Textbook formulas ignore the messy reality of local inference. Different architectures allocate attention buffers differently. Your operating system reserves VRAM for the display driver, compositor, and CUDA context. Driver versions change how aggressively they use shared memory. A theoretical equation cannot know how much VRAM is actually free on your machine at 2:00 PM with a browser full of tabs open. You have to run the model on your specific hardware and watch the meters.

Quantization offers partial relief. Moving the KV cache from f16 to q8_0 halves its memory footprint while keeping precision high enough for nearly all practical tasks. That change buys you headroom. It does not grant immunity. The cache still grows linearly with every token you feed in. Eventually, even the reduced size overwhelms your available dedicated memory and the spillover to system RAM begins. The pressure only stops when the context window is capped or the data stops moving.

The Real Takeaway

Do not trust marketing slides, parameter counts, or back-of-the-envelope math. Load the model. Open your system monitor. Run a 65,000-token thread, watch the RAM climb, and count the tokens per second. The numbers that appear on your specific screen, on your specific GPU, are the only numbers that matter. Context always wins. Your job is to know exactly when it wins on your machine.