Nikt nie mówi o RAM. Każde rozczarowanie local-LLM to problem RAM.

Wejdź do dowolnego wątku o lokalnych LLM, a kłótnia będzie o GPU. Benchmarki VRAM, karty 24 GB, CUDA kontra ROCm, dyskusje czy 3060 to wciąż ludzka karta. Tymczasem liczba, która naprawdę decyduje, czy twój model w ogóle ruszy, siedzi w drugim slocie — bez benchmarku i bez marketingu: ile RAM ma ta maszyna.

VRAM sprzedaje sen. RAM decyduje, czy model w ogóle się uruchomi — i ile kontekstu przetrwa, gdy już ruszy.

Sprawdziłem to na maszynie stojącej przede mną, pisząc ten wpis: desktop Ryzen z 32 GB RAM i GeForce RTX 3060 z 12 GB VRAM. Pobrałem llama3.1:8b — strona pobierania mówi 4,9 GB. Zobacz, co naprawdę zarezerwował:

Cały argument mieści się na tym ekranie. „Model 4,9 GB” zarezerwował 7,0 GB, zanim odpowiedział na pierwszy prompt — podatek kontekstowy 43% — i zatrzymał 7 963 z 12 288 MiB VRAM. Wagi nigdy nie były budżetem. Budżetem był kontekst.

Skąd biorą się dodatkowe gigabajty

Notatki o pamięci w llama.cpp wykładają rachunek, który strony pobierania pomijają: pamięć całkowita = wagi modelu + cache KV + bufor obliczeniowy. Tylko pierwszy składnik jest stały. Cache KV rośnie liniowo z długością kontekstu, bufor obliczeniowy z batchem. Ollama obudowuje llama.cpp, więc to samo prawo obowiązuje — dlatego ollama ps pokazał 7,0 GB dla taga 4,9 GB przy oknie 32 000 tokenów, wszystko rezydentnie na GPU.

Zkwantyzowany model to nie kompromis. To przyznanie, że pamięć zawsze była prawdziwym budżetem.

Dlatego w ogóle istnieje drabina kwantyzacji GGUF. Q4 to nie religia; to sposób, by rachunek pamięci zmieścił się w sprzęcie, który ludzie faktycznie mają. I dlatego dwie „identyczne” konfiguracje 8B nie są do siebie podobne: ten sam model, inna długość kontekstu, inne maszyny.

Tabela, której nikt nie wypełnia przed zakupem

Trzy klasy modeli, oba typy pamięci, karta 12 GB i 32 GB RAM — konfiguracja, którą tysiące programistów naprawdę ma:

Klasa modelu (Q4)	Pobieranie	Załadowany + ctx 32k	Na 12 GB VRAM	Na 32 GB RAM
7–8B (llama3.1:8b)	4,9 GB	7,0 GB (zmierzone)	100% GPU, ~8 GiB w użyciu	ledwo zauważalne
13–14B (qwen2.5:14b)	9,0 GB	~12 GB	zaczyna się offload	w porządku
27–32B (gemma3:27b)	17 GB	~20 GB i więcej	CPU ciąże wagi	jedyny powód, dlaczego to działa

Przeczytaj jeszcze raz dwa ostatnie wiersze. Na samej VRAM model 14B z prawdziwym kontekstem to już zadanie z podzielonym offloadem, a 27B jest niemożliwy. Na 32 GB RAM oba są po prostu wolne. Ta różnica — między niemożliwym a wolnym — to cała praktyczna różnica między VRAM a RAM. Zmieściło się w VRAM — szybko. Zmieściło się w RAM — działa. Nie zmieściło się nigdzie — robisz swap na NVMe i czas traci sens.

Offload idzie przez PCIe, a FAQ Ollamy mówi wprost o cenie: warstwy, które nie mieszczą się na GPU, liczą się na CPU, a przepustowość spada, gdy udział GPU się kurczy. Nikt świadomie nie wybiera tego kompromisu. Przychodzi po cichu, warstwa po warstwie, a objawem jest tylko „lokalne modele są przereklamowane”.

Uczciwa księga

Co się zepsuło albo zaskoczyło, gdy to pisałem, po kolei:

1. Sama liczba 43%. Oczekiwałem, że model 8B zajmie „mniej więcej tyle, ile waży plik”. Zarezerwował 7,0 GB przy 4,9 GB pobrania. Jeśli zaskoczyło to mnie, zaskoczy każdego, kto czyta karty katalogowe zamiast ps.
2. Sesja ze zrzutami ekranu. Pierwsze ujęcie złapało złe okno. Drugie wyszło — to wyżej. Dowody to proces pracy, nie klimat; a cykl pull → zrzut → ollama rm trzyma dysk w uczciwości.
3. Co się nie zepsuło: GPU nigdy nie przepełnił. 8B przy kontekście 32k na 12 GB to naprawdę wygoda. Karta jest w porządku. Źle skalibrowany jest dyskurs wokół karty.

Nic z tego nie znaczy, że GPU nie mają znaczenia — linijka 100% GPU na zrzucie to powód, dla którego generowanie wydawało się natychmiastowe. To znaczy, że GPU to drugie pytanie. Wybór między Ollamą a llama.cpp zapada po ustaleniu, co się mieści, nie przed.

Zasada, którą warto zapamiętać

Potrzebny RAM = plik modelu + cache KV dla twojego realnego kontekstu + 4 GB na to, by pozostać komputerem. Dla 7–8B w Q4 wygodne jest 16 GB. Dla 14B–32B, 32 GB przestaje być luksusem, a staje się sednem. Kupuj VRAM za szybkość, jakiej chcesz przy kontekście, którego używasz; kupuj RAM za wszystko, co kiedykolwiek załadujesz.

Jedno spojrzenie na ollama ps i religia kart katalogowych cicho się kończy.

A więc dwa pytania. Składając następną maszynę, kupujesz VRAM za benchmarki, które będziesz pokazywać — czy RAM za modele, które naprawdę uruchomisz? I szczerze: ile modeli pobranych o drugiej w nocy skasowałeś przed śniadaniem? Ja skasowałem dziś, w trakcie pisania. Napisz w komentarzach, że nie jestem sam — i po której stronie linii RAM/VRAM stoi twoja maszyna.