Jak uruchomić lokalne LLM na PC i nie zabić RAM-u

Po co lokalne LLM i kiedy ma to sens

Różnica między AI w chmurze a lokalnym LLM

Modele w chmurze (typu ChatGPT, Claude, Gemini) działają na potężnych serwerach, a Ty tylko wysyłasz do nich zapytania. Lokalny LLM działa bezpośrednio na Twoim PC – model jest zapisany na dysku, ładuje się do RAM‑u/VRAM‑u i generuje odpowiedzi na Twoim sprzęcie. Różnica nie jest tylko techniczna, ale przede wszystkim dotyczy prywatności, kontroli i kosztów.

Przy chmurze treść Twoich zapytań trafia na cudze serwery. Zwykle jest szyfrowana w transmisji, ale i tak musisz ufać dostawcy, że robi z tymi danymi dokładnie to, co deklaruje w regulaminie. Dla wielu osób prywatne notatki albo wrażliwe dane klientów to granica nie do przekroczenia. Lokalny LLM rozwiązuje ten problem częściowo: dane nie wychodzą z komputera, a logi konwersacji zostają u Ciebie (chyba że sam je synchronizujesz w chmurze, np. przez Dropbox/OneDrive).

Druga sprawa to kontrola. W chmurze nie masz wpływu na wersję modelu, jego aktualizacje, czasem nawet na długość kontekstu. Dostawca zmieni model z GPT‑3.5 na GPT‑4-mini i Twój workflow nagle działa inaczej. Na lokalnym LLM to Ty decydujesz: jaka architektura (Llama, Mistral, Qwen), jaka quantization, jakie parametry generacji. Płacisz za to czasem i odrobiną bólu konfiguracji, ale zyskujesz stabilne środowisko.

Kwestia kosztów jest mniej jednoznaczna. Przy lekkim, okazjonalnym użyciu chmura bywa tańsza (albo darmowa). Przy regularnym, intensywnym korzystaniu – generowaniu tysięcy tokenów dziennie, fine‑tungu, testach wielu modeli – własny komputer zaczyna mieć sens ekonomiczny. Płacisz raz: za sprzęt, prąd i ewentualnie płatne GUI. Nie płacisz cyklicznie za subskrypcję ani za każdy token.

Kiedy lokalne LLM jest praktycznie sensowne

Nie każdy scenariusz korzystania z AI wymaga lokalnego modelu. Najwięcej zyskują osoby, które:

• pracują na wrażliwych danych (dokumentacja wewnętrzna, dane klientów, kody źródłowe zamkniętych projektów),
• potrzebują stałego dostępu offline (podróże, słaby internet, środowiska odcięte od sieci),
• często prototypują – testują wiele promptów, narzędzi, rozszerzeń bez ograniczeń API,
• chcą zintegrować LLM w lokalnych narzędziach (skrypty, automatyzacje, edytory kodu),
• uczą się LLM „od środka”: architektury, prompt engineeringu, inference.

Do notatek, szybkich szkiców tekstów, prostego refactoringu kodu czy tłumaczeń, lokalne modele 7B–13B dają już dziś komfortową jakość – zwłaszcza w języku angielskim. W języku polskim bywa różnie, ale modele typu Qwen, Llama 3 czy niektóre Mistrale z dodatkowymi korpusami radzą sobie zaskakująco dobrze. Na procesorach z 16–32 GB RAM da się osiągnąć responsywność akceptowalną na co dzień.

W scenariuszach ciężkich – złożone analizy prawne, zaawansowana matematyka, bardzo kreatywne pisanie jak copy senior, deep coding na poziomie GPT‑4 – lokalne LLM na zwykłych PC wciąż odstają. Można je podciągnąć dobrym promptem, ale przepaść jakościowa jest wyczuwalna. Wtedy hybryda ma sens: lokalny model do „czyszczenia” danych, szkiców i supportu, chmura do trudnych zadań.

Realistyczne oczekiwania i mity wokół lokalnych LLM

Najczęstsze rozczarowanie wygląda tak: ktoś pobiera 7‑miliardowy model, odpala go w LM Studio i oczekuje „lokalnego GPT‑4”. Pierwsze minuty są nawet obiecujące, ale przy trudniejszym zadaniu wychodzi brutalna prawda – odpowiedzi są bardziej ogólne, mniej precyzyjne, częściej halucynują. Źródło problemu: zbyt wysokie oczekiwania.

Modele 7B–8B najczęściej wystarczą do:

• skracania tekstów, parafraz i prostego streszczania,
• wyjaśnień koncepcji na poziomie „przewodnika dla średniozaawansowanego”,
• podpowiedzi kodu, poprawy drobnych błędów, szybkich snippetów,
• tworzenia zarysów maili, ogłoszeń, prostych artykułów,
• eksperymentów z promptami, gdzie liczy się szybkość, nie perfekcja.

Modele 13B–14B są zauważalnie lepsze w dłuższych, spójnych wypowiedziach, planowaniu kroków, lepszym „rozumieniu” kontekstu i zachowaniu instrukcji. Wciąż jednak nie są pełnym zamiennikiem GPT‑4 w zadaniach wymagających głębokiej analizy. Powyżej 30B robi się ciekawiej, ale wtedy wymagania RAM/VRAM rosną do poziomu, który przeciętny laptop po prostu nie „udźwignie”.

Benchmarki w sieci bywają mylące. Prosty ranking „model X ma 85 punktów w teście Y, model Z ma 83” nic nie znaczy bez kontekstu. Testy często dotyczą tylko angielskiego, krótkich zadań i nie zawsze oddają to, jak model radzi sobie w interaktywnym czacie. Zamiast ufać ślepo tabelkom, lepiej przetestować 2–3 modele na własnych, typowych zadaniach i samodzielnie ocenić jakość.

Jak działa LLM od strony zasobów – uczciwe minimum

Co faktycznie zjada RAM i VRAM podczas działania modelu

Typowy użytkownik widzi tylko plik modelu: np. 4 GB, 8 GB, 16 GB. Z tego rodzi się prosty, ale błędny wniosek: „skoro plik ma 4 GB, to tyle RAM‑u potrzebuje model”. W praktyce widoczny w menedżerze zadań użytek pamięci bywa 1,5–3 razy większy od rozmiaru pliku. Dzieje się tak przez kilka warstw narzutu.

Przy generowaniu tekstu pamięć zajmują:

• wagi modelu – to, co jest w pliku GGUF/GGML, ładowane do RAM‑u lub VRAM‑u,
• cache atencji – informacje o dotychczas wygenerowanych tokenach, konieczne do kolejnych kroków,
• bufor kontekstu – same tokeny wejściowe i wyjściowe, które model „pamięta”,
• narzut aplikacji – GUI, backend (np. llama.cpp, koboldcpp, text-generation-webui), interpretatory (Python),
• dodatkowe funkcje – narzędzia (tools), RAG, biblioteki GPU, wątki systemowe.

Cache atencji rośnie wraz z długością konwersacji. Długi czat z modelami z dużym oknem kontekstu (np. 16k, 32k) potrafi spokojnie dobić do kilku GB dodatkowego zużycia pamięci. To dlatego przy krótkich zapytaniach wszystko jest szybkie i stabilne, a przy „sesjach maratonach” pojawia się swapowanie na dysk i drastyczne spowolnienia.

VRAM działa podobnie, gdy używasz GPU: część wag modelu ląduje w pamięci karty graficznej, co daje dużo większą szybkość generacji, ale ogranicza rozmiar modelu. Jeżeli VRAM się skończy, biblioteka (np. CUDA, Metal) albo nie uruchomi modelu wcale, albo będzie przerzucać dane między VRAM a RAM, co niszczy zysk wydajności.

Rozmiar pliku modelu a realne użycie pamięci

Rozmiar pliku modelu jest funkcją: liczba parametrów × liczba bitów na parametr (quantization) + narzuty metadanych. Przykładowo, model 7B w quant Q4 (4 bity na wagę) może mieć kilka gigabajtów, podczas gdy ta sama architektura w Q8 przybliży się do dwucyfrowej liczby GB. Jednak nawet przy Q4, w pamięci potrzebne są struktury pomocnicze – stąd typowy mnożnik 1,2–1,8× względem rozmiaru pliku.

Częsty scenariusz: użytkownik ma 8 GB RAM i pobiera model 4 GB, licząc że „zmieści się spokojnie”. System operacyjny, przeglądarka, aplikacje w tle już zużywają 3–4 GB. Po wczytaniu modelu narzut aplikacji i cache kontekstu podbijają całość do 6–7 GB. System zaczyna swapować na dysk, wszystko robi się ślamazarne, a czasem zostaje tylko twardy reset.

Bezpiecznym podejściem jest przyjęcie, że model + narzut = ok. 2× rozmiar pliku w kontekście minimalnych wymagań RAM (i to przy niezbyt długich sesjach). Jeżeli chcesz zachować przyzwoity margines bezpieczeństwa (brak swapu przy dłuższym czacie), dobrze jest mieć wolne w RAM minimum 2–3× rozmiaru pliku modelu, zanim go wczytasz.

Generowanie tokenów: krok po kroku a obciążenie CPU/GPU

Duże modele językowe działają token po tokenie. Dla każdego nowego tokena model musi przetworzyć cały kontekst dotychczasowych tokenów, zaktualizować cache atencji i obliczyć rozkład prawdopodobieństwa kolejnego symbolu. Matematycznie to mnóstwo mnożeń macierzy – idealne zadanie dla GPU, ale wykonalne też na CPU.

Na CPU kluczowe są instrukcje wektorowe (AVX2, AVX‑512, NEON na ARM), liczba rdzeni i ich taktowanie. Dobrym kompromisem jest uruchomienie modelu na 4–8 wątkach – więcej nie zawsze przyspiesza generację, a podnosi zużycie energii i temperaturę. Na GPU generacja bywa kilkukrotnie szybsza, ale tylko o ile model mieści się w VRAM całkowicie lub w większości (tzw. offload części warstw).

Obciążenie CPU/GPU rośnie liniowo z liczbą generowanych tokenów, ale pamięć rośnie głównie z długością kontekstu. Dlatego sensowne limity: maksymalna liczba tokenów w jednej odpowiedzi, maksymalna długość historii czatu oraz cięcie/przycinanie starego kontekstu chronią RAM dużo skuteczniej niż sama zmiana modelu na mniejszy.

Szybkość kontra stabilność – dlaczego czasem warto zwolnić

Każdy chciałby, żeby lokalne LLM generowało odpowiedzi tak szybko jak GPT‑4 w chmurze. Tylko że pogoń za maksymalną prędkością często kończy się niestabilnością: przegrzewaniem CPU/GPU, throttlingiem, swapem na dysk i w efekcie gorszym doświadczeniem. Minimalny FPS, który daje poczucie płynności, to zwykle 10–15 tokenów na sekundę. Na wolniejszym sprzęcie realne jest 3–8 tok/s – i to już bywa w praktyce używalne.

Czasem opłaca się:

• zostawić część rdzeni wolnych (np. używać 4 zamiast 12 wątków),
• wybrać model 7B w lepszej jakości quant zamiast 13B w brutalnym Q2,
• zmniejszyć context window (np. z 16k na 8k),
• wyłączyć zbędne dodatki w GUI, które trzymają własne bufory w pamięci.

Stabilne, przewidywalne 5–7 tok/s bez przywieszania systemu jest zwykle lepsze niż szarpane 15–20 tok/s poprzedzielane chwilami, gdy mysz nie reaguje, a wentylatory wyją. Przy lokalnym LLM komfort pracy jest ważniejszy niż „benchmarkowa” prędkość.

Ocena swojego sprzętu – co Twój PC realnie potrafi

Jak sprawdzić RAM, VRAM i procesor

Zanim wybierzesz model, trzeba uczciwie policzyć, na czym stoisz. Minimalny zestaw informacji to:

• ilość RAM – najlepiej w GB, z informacją, ile jest zajęte w spoczynku,
• GPU i VRAM – marka (NVIDIA/AMD/Intel), ilość pamięci na karcie, wersja sterowników,
• CPU – model procesora, liczba rdzeni/logicznych wątków, wsparcie AVX2/AVX‑512 (na x86),
• system operacyjny – Windows, Linux, macOS, wersja oraz architektura (x86_64/ARM).

Na Windows wygodny jest Menedżer zadań (Ctrl+Shift+Esc): zakładka „Wydajność” pokazuje RAM, GPU, VRAM. Więcej szczegółów dają narzędzia typu CPU‑Z, GPU‑Z. Obsługę AVX2/AVX‑512 można sprawdzić w CPU‑Z albo na stronie producenta procesora. W Linuxie podstawą jest lscpu, free -h, nvidia-smi (dla NVIDII) oraz monitory systemowe KDE/GNOME. Na macOS informacje znajdują się w „Ten Mac” → „Raport systemowy”.

Jeśli nie wiesz, czy Twój GPU ma sens w kontekście LLM, najprościej spojrzeć na VRAM. 2 GB to w praktyce za mało. 4 GB – bardzo na styk, tylko najmniejsze modele i częściowy offload. 6–8 GB – da się sensownie przyspieszyć modele 7B/8B. 12 GB i więcej – zaczyna się komfort, szczególnie przy Llama 3 8B i lekkich 13B.

Co uciągnie 8 GB, 16 GB i 32+ GB RAM

Wyobrażenia o tym, „co się da na 8 GB RAM”, są często oderwane od realiów, zwłaszcza gdy w tle działa przeglądarka z kilkunastoma kartami. W uproszczeniu:

• 8 GB RAM – tylko bardzo małe modele (3B–7B) w agresywnej quantization, często z wyłączoną przeglądarką i innymi aplikacjami. Konieczne pilnowanie długości kontekstu. Komfortowe tylko do sporadycznych, krótkich zadań.

Przypadek 16 GB i 32+ GB – kiedy robi się wygodnie

Przy 16 GB RAM sytuacja zmienia się z „uda się, jeśli nic nie dotkniesz” na „da się normalnie pracować, o ile nie przesadzisz z modelem i kontekstem”. Bardziej przypomina to realne biurko niż balansowanie na krawędzi stołu.

• 16 GB RAM – sensowny punkt wyjścia. Modele 7B w przyzwoitej quant (Q4–Q5) na CPU są już praktycznie używalne, 8B zwykle też, zwłaszcza przy krótszym kontekście (4k–8k). Małe 13B w agresywniejszej quant (Q3, Q4) są możliwe, ale bez wielu aplikacji w tle i z rozsądną długością historii czatu. Do typowego: notatek, prostych podpowiedzi programistycznych, streszczania tekstu – wystarcza.
• 32 GB RAM i więcej – tu wchodzą stabilne 13B, niektóre 70B w bardzo mocnych quantach (bardziej do „pobawienia się” niż codziennej pracy) oraz możliwość równoległego odpalania kilku instancji modelu. Da się mieć otwarte IDE, przeglądarkę, player w tle i nadal korzystać z lokalnego LLM bez nerwowego zerkania w monitor zużycia pamięci.

Na 32 GB można spokojnie przyjąć, że dla modeli 7B–13B w rozsądnej quantization wystarcza trzymać się zasady „wolne 2× rozmiar pliku modelu” i zwykle zostanie jeszcze bufor. Problemy zaczynają się głównie wtedy, gdy ktoś łączy kilka „pazernych” elementów naraz: bardzo długi kontekst, duży model, intensywne GUI w Electronie i do tego Chrome z kilkudziesięcioma kartami.

CPU vs GPU – który z nich będzie wąskim gardłem

Na papierze wszystko wygląda pięknie: „mam 8 rdzeni, 16 wątków, będzie śmigać”. W praktyce bywa, że wąskim gardłem jest coś zupełnie innego niż się zakłada.

• CPU słabe, GPU przyzwoite – typowy scenariusz w laptopach gamingowych: procesor średniej klasy, ale karta z 6–8 GB VRAM. Tu warto szukać rozwiązań z offloadem na GPU (Ollama, LM Studio), bo czyste CPU nie wykorzysta potencjału sprzętu. Przy poprawnej konfiguracji GPU „pociągnie” większość obliczeń, CPU głównie będzie zajmować się obsługą aplikacji.
• CPU mocne, GPU zintegrowane/bez sensownego VRAM – często w ultrabookach i mini‑PC. Takie maszyny nadają się bardziej do modeli 3B–7B w trybie CPU‑only, bez cudów z offloadem. Liczy się wsparcie AVX2/AVX‑512 (lub NEON na ARM) i chłodzenie – krztuszący się throttlingiem procesor może być wolniejszy niż starsza, ale solidnie chłodzona jednostka stacjonarna.
• mocne GPU, mało RAM – karta ma 8–12 GB VRAM, ale całość systemu tylko 8 GB RAM. Da się uruchomić częściowy offload modeli, ale pojawia się paradoks: sam backend, GUI, system i tak „zjedzą” sporą część RAM‑u, a każde przekroczenie progu kończy się swapowaniem, które w praktyce zabija przewagę GPU.

Jeżeli po uruchomieniu modelu widzisz, że CPU dobija do 100%, a GPU prawie się nudzi – konfiguracja offloadu jest prawdopodobnie zbyt zachowawcza (za mało warstw na GPU). Gdy odwrotnie – GPU na 100%, VRAM na granicy, a CPU tylko się przygląda – model jest zwykle za duży jak na posiadaną kartę i działa na krawędzi stabilności.

Dysk: SSD, HDD i dlaczego I/O też potrafi przeszkodzić

W dyskusjach o lokalnych LLM dysk bywa pomijany. Do momentu, aż ktoś próbuje wczytać 20‑gigabajtowy model z HDD i zastanawia się, czemu start trwa wieczność.

Najważniejsze fakty:

• SSD NVMe – najlepszy scenariusz. Model wczytuje się szybko, a nawet jeśli system chwilowo zrzuci coś do swapa, odczyt nie jest katastrofalny. Przy dużych modelach i częstych restartach backendu różnica w czasie ładowania potrafi być odczuwalna.
• SSD SATA – nadal jak najbardziej OK, zwłaszcza gdy nie ma tysiąca małych plików. Różnica względem NVMe jest, ale w codziennym użyciu lokalesów nie musi być krytyczna.
• HDD – model da się trzymać na talerzówce, ale samo wczytanie kilku–kilkunastu GB może trwać długo, szczególnie jeśli dysk jest pofragmentowany, a system coś jeszcze na nim robi. Przy intensywnym swapowaniu generacja zamienia się w poklatkowy pokaz slajdów.

Jeśli konfiguracja często „dobija do ściany” RAM, lepiej mieć trochę wolnego miejsca na szybkim SSD (na plik wymiany), niż liczyć, że system sprytnie sobie poradzi na starym HDD. To nie rozwiązuje problemu, ale ogranicza skalę katastrofy.

Dobór modelu do sprzętu – bez życzeniowego myślenia

Rozmiar w parametrach (B) a realne możliwości

Nazwy typu 3B, 7B, 8B, 13B, 70B opisują liczbę parametrów, ale same w sobie niewiele mówią o tym, jak model zachowa się na konkretnym komputerze. Dwa modele 7B mogą mieć różne architektury, różny kontekst i bardzo różny rozmiar po quantization. Mimo to da się zarysować praktyczne przedziały:

• 3B–4B – bardzo lekkie, dobre na start na słabym sprzęcie (8 GB RAM, brak GPU). Przeważnie ustępują większym modelom pod względem jakości, ale w zadaniach typu: krótkie podpowiedzi, prosty refactoring, generowanie pomysłów – bywają wystarczające.
• 7B–8B – „złoty środek” dla lokalnych zastosowań. Na 16 GB RAM działają jeszcze komfortowo, na 32 GB – wręcz swobodnie. Na GPU z 6–8 GB VRAM da się je ładnie przyspieszyć.
• 13B – sensowny krok w górę jakości przy widocznym koszcie pamięci. Minimalnie 16 GB RAM z dość ostrymi cięciami (krótszy kontekst, ubogie tło), realistycznie 32 GB wzwyż. Na GPU wymaga to już co najmniej 8–10 GB VRAM, a i tak często tylko częściowego offloadu.
• 34B i więcej – terytorium entuzjastów i stacji roboczych. Bez 48–64 GB RAM i sensownej karty graficznej (kilkanaście GB VRAM) trudno mówić o komfortowym użytkowaniu. Dla przeciętnego laptopa to egzotyka.

Sam rozmiar w parametrach nie gwarantuje jakości. Bywa, że dobrze wytrenowany 7B z nowej rodziny (np. Llama 3 8B) w wielu zadaniach bije stare 13B. Wybór modelu wyłącznie po liczbie parametrów to prosty sposób, żeby wpakować się w problemy z pamięcią bez realnej poprawy rezultatów.

Modele „instruct” vs „base” – który typ do domowego użytku

Do rozmów w stylu czatu, pomocy przy pisaniu, prostych analiz kodu i tekstu, potrzebny jest model typu instruct/chat. Modele base są surowe, mniej „posłuszne”, oczekują bardziej technicznego promtu i nie mają tak wypolerowanego sposobu odpowiadania.

Przy ograniczonym RAM‑ie szkoda marnować miejsce na duży model base tylko po to, żeby potem łatać go skomplikowanym promtem. Dużo sensowniej jest wziąć mniejszy, ale dobrze przygotowany model instruct, dopasowany do języka (choćby częściowo) i typu zadań.

Dobór pod język: angielski, polski i reszta świata

Większość modeli jest trenowana głównie na angielskim. Polski, choć coraz lepiej reprezentowany, nadal bywa marginesem. W praktyce oznacza to kilka rzeczy:

• mały model (3B–4B) z dominującym angielskim może w polskim zachowywać się bardzo losowo, szczególnie w zadaniach wymagających precyzji (np. prawo, medycyna);
• większy model (7B–13B) z porządnym treningiem wielojęzycznym poradzi sobie z polskim całkiem nieźle, o ile zadania nie są bardzo specjalistyczne;
• niektóre modele są wyraźnie „przesterowane” na angielski – po kilku wymianach zdań potrafią wracać do niego mimo polskiego promtu.

Jeśli priorytetem jest praca po polsku, lepiej czasem wybrać trochę mniejszy, ale dobrze zoptymalizowany model wielojęzyczny niż większego „potwora” trenowanego głównie na angielskim. Znowu: test na własnych zadaniach zwykle mówi więcej niż jakikolwiek leaderboard.

Model do zastosowań: notatki, kod, analiza dokumentów

Nie ma jednego „najlepszego” modelu do wszystkiego. Kilka orientacyjnych par typ zadań → typ modelu:

• krótkie notatki, pomysły, proste maile – lekkie 3B–7B w Q4–Q5, ważniejszy jest styl odpowiedzi niż absolutna „inteligencja”.
• pomoc programistyczna – modele, które były dodatkowo dostrajane na kodzie (Code Llama, modele „Coder”, „Code” itp.). Lepsze 7B–8B potrafią sensownie radzić sobie z refactoringiem i wyjaśnianiem fragmentów.
• analiza dłuższych tekstów/dokumentów – tu liczy się długość kontekstu. Model z oknem 8k–16k tokenów sensownie wczyta raport czy rozdział książki, ale będzie kosztował więcej pamięci. Lepiej użyć mniejszego modelu z długim kontekstem, niż większego z oknem 2k, który gubi połowę dokumentu.

Jeśli zadania są powtarzalne (np. zawsze chodzi o skracanie długich tekstów), można pokusić się o osobny, mniejszy model tylko do tej roli. Dzięki temu nie trzeba za każdym razem wciągać do RAM dużego „kombajnu”.

Quantization i formaty modeli – jak oszczędzić pamięć z głową

O co chodzi w quantization – skracanie wag bez magii

Quantization sprowadza się do jednego: zamiast trzymać każdą wagę modelu jako liczbę 16‑ czy 32‑bitową, upycha się ją w 2–8 bitach. Mniej bitów = mniejszy plik = mniejsze zużycie pamięci. Problem w tym, że każdy taki skrót to przybliżenie, a przybliżenia kumulują się jako spadek jakości.

Popularne poziomy quantization (na przykładzie GGUF/GGML względnie zbliżonych formatów):

• Q2 – ekstremalne odchudzenie, głównie do testów „czy w ogóle ruszy”. Jakość wyraźnie gorsza, potrafi gubić sens nawet przy prostych zadaniach.
• Q3 – nadal agresywne, ale już trochę bardziej używalne. Umożliwia wciśnięcie większego modelu w mały RAM kosztem części jakości.
• Q4 – rozsądny kompromis między jakością a rozmiarem. Wiele modeli 7B–8B w Q4 zachowuje się zaskakująco dobrze na codziennych zadaniach.
• Q5 – wyższa jakość, większy rozmiar. Jeżeli RAM na to pozwala, a model ma być niezawodnym narzędziem, Q5 bywa dobrym wyborem.
• Q6/Q8 – lekkie przycinanie względem pełnej precyzji. Zazwyczaj blisko jakości FP16, ale rozmiar pliku już odczuwalnie większy. Sens przede wszystkim na sprzęcie z dużą ilością RAM/VRAM.

Uproszczenie typu „Q4 jest zawsze wystarczające” nie trzyma się kupy. Dla prostych zadań – często tak. Dla zadań wymagających precyzyjnej logiki, rachunków, analizy długich łańcuchów zależności – już niekoniecznie. Różnice między Q4 a Q5 potrafią być niewielkie „na oko”, dopóki nie trafisz w konkretny przypadek, gdzie nagle wszystko się rozsypuje.

GGUF, GGML, Safetensors i spółka – co z czym działa

Na lokalnych LLM przewijają się głównie trzy rodziny formatów:

• GGUF/GGML – formaty powiązane z ekosystemem llama.cpp. GGUF to nowsza, wygodniejsza wersja, z lepszym wsparciem metadanych. To typowy wybór dla narzędzi korzystających z llama.cpp (Ollama, LM Studio w trybie CPU/GGUF, koboldcpp, część integracji w text‑generation‑webui).
• Safetensors – popularny w ekosystemie PyTorch/Hugging Face. Nadaje się bardziej do pracy na GPU poprzez biblioteki typu Transformers. Zwykle wymaga więcej pamięci, ale oferuje większą elastyczność i dostęp do pełnych modeli FP16/BF16.
• ONNX/TensorRT i inne – raczej bardziej specjalistyczne zastosowania i eksperymentalne integracje. Dla przeciętnego użytkownika domowego rzadziej mają znaczenie.

Wybór formatu w praktyce jest pochodną wyboru narzędzia. Jeśli narzędzie wspiera GGUF – najprościej korzystać właśnie z niego. Próby ręcznego konwertowania między formatami bez wyraźnej potrzeby kończą się często w ślepym zaułku: niby się udało, ale model nie jest wspierany, albo traci się obsługę części funkcji (np. LoRA, specyficznych tokenezerów).

Jak ocenić, która quantization ma sens na Twoim sprzęcie

Najprostsza procedura przypomina testowanie kompresji grafiki: zamiast wierzyć opisom, sprawdzasz, jak to wygląda w praktyce.

1. Wybierz 1 model (np. Llama 3 8B, Q4 i Q5 od tego samego autora, z tym samym tokenezerem).

Praktyczny test kilku wariantów – krok po kroku

2. Pobierz 2–3 warianty quantization – np. Q3, Q4, Q5 tego samego modelu. Jeśli masz mało RAM, zamiast Q5 możesz wziąć Q2/Q3, żeby zobaczyć, jak bardzo wszystko się „sypie”.
3. Przygotuj kilka stałych zadań testowych:
   • krótki prompt konwersacyjny po polsku i po angielsku,
   • fragment kodu do wyjaśnienia,
   • 1–2 przykładowe dokumenty (np. 2–3 strony regulaminu albo raportu).
4. Odpalenie testu:
   • dla każdego wariantu quantization wykonaj te same zadania,
   • notuj subiektywnie: sens wypowiedzi, spójność, błędy logiczne, „odklejenie” od tematu,
   • zwracaj uwagę na prędkość (tokeny/sekundę) i stabilność (czy system nie zaczyna mielić dyskiem lub swapem).
5. Obserwuj użycie pamięci – monitor systemu (Menedżer zadań, htop itp.) powie więcej niż opis na stronie modelu. Jeżeli przy prostym promcie RAM skacze na 95% i system zaczyna lagować, to znak, że:
   • albo quantization jest zbyt „luksusowe” (np. Q6 zamiast Q4),
   • albo sam model jest za duży jak na sprzęt.
6. Wybierz sensowny kompromis – zazwyczaj kończy się na:
   • „najniższa quantization, przy której model nadal zachowuje się racjonalnie na Twoich zadaniach”
   • albo „trochę wyższa quantization, ale mniejszy model”.

Jeśli wąskim gardłem jest RAM, zwykle lepszy efekt daje przejście z 13B Q4 na 7B Q5 niż próby upychania większego modelu na granicy możliwości systemu. Z punktu widzenia stabilności systemu „trochę gorszy model, który działa zawsze” jest bardziej użyteczny niż „potwór, który czasem się załadował, a czasem zawiesił cały pulpit”.

Mieszane strategie – różne quantization dla różnych zadań

Nie ma obowiązku trzymania się jednego modelu i jednej quantization do wszystkiego. Często wygodniej jest przygotować sobie zestaw:

• mały, mocno skompresowany model (np. 3B–4B w Q4/Q3) do szybkich, prostych pytań,
• średni model (7B w Q5) do pracy nad kodem czy dłuższym tekstem,
• ewentualnie większy (13B) w przyzwoitej quantization tylko do konkretnych „ciężkich” zadań.

Przy pracy codziennej większość zapytań trafia do lekkiego modelu, który odpala się błyskawicznie i nie zjada całej pamięci. Po większą „armatę” sięgasz tylko wtedy, gdy naprawdę jej potrzebujesz. W praktyce przekłada się to na mniejsze ryzyko, że w środku dnia roboczego przeglądarka nagle zacznie zamykać karty, bo zabrakło RAM‑u.

Wybór narzędzia: jakiego „frontu” użyć, żeby nie męczyć się bardziej niż trzeba

Ollama – minimalizm i prostota kosztem elastyczności

Ollama to opcja dla tych, którzy chcą „po prostu uruchomić model” bez wchodzenia w parametry linii komend i konfigurację Pythona. Instalujesz, uruchamiasz usługę w tle i korzystasz przez terminal albo wtyczki (np. integracje z edytorami kodu).

Główne cechy z perspektywy RAM‑u i codziennego użycia:

• Automatyczne zarządzanie modelami – komenda w stylu ollama run llama3 sama pobiera odpowiedni plik i uruchamia go w rozsądnej konfiguracji. Mniej miejsca na pomyłki, ale też mniej kontroli nad konkretną quantization.
• Dobre użycie GGUF i llama.cpp – modele są od razu w formacie zoptymalizowanym pod lokalne uruchamianie, bez dłubania przy konwersjach.
• Ograniczone grzebanie w szczegółach – można zmieniać część parametrów (kontekst, temperatura, offload na GPU), jednak nie jest to narzędzie dla maniaków tuningu każdej warstwy.

Typowy scenariusz: laptop z 16–32 GB RAM, bez dedykowanego GPU albo ze skromnym GPU mobilnym. Ollama pozwala w kilka minut sprawdzić, czy 7B w ogóle ma sens, a potem ewentualnie przejść do bardziej rozbudowanych narzędzi, jeżeli pojawi się potrzeba precyzyjnej kontroli.

LM Studio – graficzny kombajn dla GGUF

LM Studio przypomina „menedżer modeli” dla lokalnych LLM z interfejsem graficznym. Dla wielu osób to wygodniejsza forma niż terminal:

• Przeglądarka modeli – możesz wyszukiwać, filtrować i pobierać modele (głównie GGUF) z poziomu aplikacji. Widać od razu parametry, quantization, rozmiar.
• Podgląd zużycia zasobów – łatwo zobaczyć, ile RAM/VRAM ciągnie konkretny model i czy nie przekracza granic rozsądku.
• Wsparcie dla GPU – przy odpowiedniej konfiguracji część wag trafia na kartę graficzną, co odciąża RAM i przyspiesza generację.

Z punktu widzenia „niezabijania RAM‑u” największą zaletą jest to, że eksperymenty z różnymi quantization odbywają się poprzez kilka kliknięć. Nie trzeba zapamiętywać nazw plików ani ścieżek – po prostu uruchamiasz inny wariant tego samego modelu i obserwujesz, jak zachowuje się system.

koboldcpp – lekki, ale zaskakująco giętki koń roboczy

koboldcpp wyrósł z narzędzi skupionych wokół generowania fikcji i gier tekstowych, ale w praktyce jest elastycznym frontem do llama.cpp z własnym UI. Kilka rzeczy, które mają znaczenie przy ograniczonych zasobach:

• Dobre wsparcie dla GGUF i wielkiej liczby modeli,
• sporo przełączników wydajności – rodzaj backendu, liczba wątków, różne sztuczki przyspieszające dekodowanie tokenów,
• profil pod długie konteksty – sensowne do interaktywnych historii, ale też do analizowania obszerniejszych tekstów.

Minusem bywa to, że mnogość opcji łatwo kusi do przekręcania wszystkiego „na maksa”: maksymalne wątki, maksymalny kontekst, agresywne offloady na GPU. Efekt bywa odwrotny od zamierzonego – system zaczyna się dławić, a całość działa wolniej niż na zachowawczych ustawieniach. Rozsądniej jest podnieść zasoby stopniowo i sprawdzać, czy realnie przyspiesza to generację, zamiast ufać, że „więcej = szybciej”.

text-generation-webui – elastyczność Pythona za cenę zasobów

text-generation-webui to bardziej zaawansowane środowisko oparte na Pythonie, które potrafi odpalać modele w wielu backendach (Transformers, ExLlama, llama.cpp itd.). Daje ogromną swobodę, ale wymaga też więcej zasobów i cierpliwości przy konfiguracji.

Z punktu widzenia RAM‑u i praktyki:

• Pełne modele w FP16/BF16 na GPU potrafią zużyć błyskawicznie kilkanaście GB VRAM. Dla przeciętnej karty pokroju 6–8 GB oznacza to konieczność mieszanych trybów (część na GPU, część na CPU) albo sięgnięcia po quantized GGUF.
• Sam Python i zależności zjadają dodatkową porcję pamięci, więc przy 8–16 GB RAM ogólne obciążenie systemu może być zauważalne, nawet gdy model nie jest bardzo duży.
• Plus – dostęp do bardziej „egzotycznych” formatów, LoRA, miksów adapterów i eksperymentalnych backendów, co bywa przydatne, jeżeli ktoś robi coś więcej niż tylko rozmowy i generowanie tekstu.

W praktyce text-generation-webui ma sens, kiedy sprzęt jest już w miarę mocny (co najmniej 16 GB RAM, najlepiej 32+ i karta z przyzwoitym VRAM‑em), a użytkownik chce świadomie wybierać między różnymi silnikami i formatami modeli. Na słabym laptopie potrafi działać, ale jest to balansowanie na granicy komfortu.

Inne opcje: własny skrypt, API i lekkie fronty

Poza „dużymi” narzędziami istnieje sporo lżejszych rozwiązań:

• go-llama.cpp, ctransformers i podobne bindingi – biblioteki pod różne języki (Go, Python, Rust), które pozwalają odpalać modele w stylu llama.cpp w ramach własnych aplikacji. Nie ma zbędnego UI, jest tylko to, co potrzebne, przez co narzut RAM bywa minimalny.
• Prosty własny serwer HTTP wokół llama.cpp – dla kogoś, kto nie boi się kompilacji z GitHuba, to często najlżejsza opcja: uruchamiasz binarkę, wystawiasz port i łączysz się przez prostą stronę albo plugin do edytora.
• Lekkie GUI tworzone przez społeczność

Te podejścia są sensowne, gdy ważniejszy jest minimalizm i pełna kontrola niż ładny interfejs. Typowa sytuacja: desktop z 16 GB RAM, bez planów na duże modele. Zamiast ciężkiego ekosystemu Pythona da się utrzymać całość w ramach jednej binarki i paru plików konfiguracyjnych, co zmniejsza ryzyko „tajemniczego” pożerania pamięci przez same narzędzia.

Jak dopasować narzędzie do najsłabszego ogniwa

Dobór narzędzia dobrze jest oprzeć nie na tym, co „najfajniejsze”, tylko na tym, co w Twoim PC jest najsłabsze:

• Mało RAM (8–12 GB), brak sensownego GPU – lekkie fronty oparte na llama.cpp (Ollama, koboldcpp, własna binarka). Modele 3B–7B w niskich quantization. Unikać ciężkich środowisk Pythona, chyba że do prostych eksperymentów.
• Przyzwoity RAM (16–32 GB), skromny GPU – LM Studio, koboldcpp, ewentualnie text-generation-webui w trybie mieszanym. Średnie modele 7B–8B, czasem 13B przy ostrożnym podejściu do kontekstu i quantization.
• Dużo RAM (32+ GB) i porządny GPU (12+ GB VRAM) – pełna swoboda w wyborze: można iść w text-generation-webui z modelami w FP16, eksperymentować z LoRA, długimi kontekstami, precyzyjnymi quantization, a sam RAM przestaje być głównym problemem.

Przy tym samym modelu różne narzędzia potrafią generować różne obciążenie pamięci (zależnie od sposobu ładowania, frameworków, nakładek). Jeżeli system zaczyna się dusić, warto sprawdzić, czy ten sam model w innym froncie nie będzie zachowywał się łagodniej. Dla części użytkowników „przesiadka” z ciężkiego webui na prostszy wrapper pod llama.cpp rozwiązuje 80% problemów bez zmiany sprzętu.

Najczęściej zadawane pytania (FAQ)

Czy lokalne LLM może zastąpić ChatGPT / GPT‑4 na zwykłym PC?

Na typowym PC lokalne modele 7B–13B nie są pełnym zamiennikiem GPT‑4. Sprawdzają się przy skracaniu i parafrazowaniu tekstów, prostych wyjaśnieniach, generowaniu szkiców maili czy lekkim wspomaganiu programowania. Przy takich zadaniach różnica jakości bywa akceptowalna, szczególnie w języku angielskim.

Przy złożonych analizach prawnych, zaawansowanej matematyce, kreatywnym copywritingu na poziomie seniora czy głębokim code review przepaść jakościowa między lokalnym 7B–13B a GPT‑4 jest wyraźna. Rozsądne podejście to często hybryda: lokalny model do wstępnego „przerobienia” danych i prostszych rzeczy, chmura do naprawdę trudnych tematów.

Ile RAM‑u potrzebuję, żeby uruchomić lokalne LLM bez zabijania komputera?

Orientacyjna zasada: sam model + narzut zwykle zajmie około 2× rozmiar pliku modelu. Jeśli plik ma 4 GB, realne zużycie pamięci przy krótszych sesjach to często 6–8 GB razem z aplikacją. Przy dłuższych czatach i większym kontekście licz to raczej jako 2–3× rozmiar pliku modelu.

Na praktycznym poziomie: do małych modeli 7B w mocno skompresowanych wariantach (Q4) sensowne minimum to 16 GB RAM, aby system nie zaczął agresywnie swapować na dysk przy byle dłuższej rozmowie. Przy 8 GB RAM też da się coś uruchomić, ale komfort będzie przeciętny – wystarczy kilka kart w przeglądarce i dłuższy kontekst, by wszystko zaczęło się ciągnąć.

Czym różni się lokalny LLM od AI w chmurze pod kątem prywatności?

Przy modelach w chmurze cały tekst zapytań i odpowiedzi trafia na serwery dostawcy. Transmisja jest zazwyczaj szyfrowana, ale trzeba zaufać, że dane są używane i przechowywane dokładnie tak, jak opisano w regulaminie. Dla wielu osób to akceptowalne przy ogólnych pytaniach, natomiast przy dokumentacji wewnętrznej czy tajnym kodzie źródłowym robi się ryzykownie.

Przy lokalnym LLM dane pozostają na Twoim komputerze – model działa z dysku i RAM‑u/VRAM‑u, a logi konwersacji są lokalne. Wyjątek pojawia się wtedy, gdy sam zsynchronizujesz katalog z historią czatów do chmury (Dropbox, OneDrive itp.). Wtedy prywatność nie jest już „czysto lokalna”, choć nadal masz większą kontrolę niż przy typowej usłudze SaaS.

Czy lokalne LLM ma sens przy słabym internecie lub pracy offline?

Tak, to jeden z mocniejszych argumentów za lokalnym modelem. Po jednorazowym pobraniu pliku modelu możesz generować odpowiedzi całkowicie offline – sprawdza się to w podróży, w biurach z ostrymi zasadami bezpieczeństwa sieci albo tam, gdzie dostęp do chmury bywa blokowany polityką firmy.

Trzeba tylko uwzględnić, że pobranie samego modelu też wymaga internetu i bywa ciężkie (kilka–kilkanaście GB). Jeżeli łącze jest niestabilne, zaplanuj ściągnięcie modeli wcześniej, a później korzystaj już lokalnie bez ryzyka przerwania sesji przez pad sieci.

Jak dobrać rozmiar modelu (7B, 13B, 30B) do mojego komputera?

W uproszczeniu: im więcej parametrów (B = miliardy parametrów), tym większe zużycie RAM/VRAM i z reguły wyższa jakość, ale też wolniejsze działanie. Na przeciętnym PC z 16–32 GB RAM najbardziej praktyczne są modele 7B–13B w skompresowanych wariantach (Q4, Q5). Dają już sensowną jakość do notatek, szkiców tekstów i wsparcia w kodowaniu.

Modele 13B–14B lepiej trzymają kontekst i generują spójniejsze, dłuższe wypowiedzi, jednak stają się odczuwalnie cięższe. Powyżej ~30B wchodzimy w terytorium, gdzie bez dużej ilości RAM‑u i mocnej karty graficznej komfort pracy na domowym sprzęcie drastycznie spada. Lepiej zacząć od dwóch–trzech modeli 7B–13B i sprawdzić je na własnych zadaniach niż ślepo gonić za największą liczbą parametrów.

Czy lokalne LLM faktycznie jest tańsze od chmurowego (API, subskrypcje)?

To zależy od intensywności użycia. Przy sporadycznym użyciu – kilka krótkich zapytań dziennie, bez trenowania własnych modeli – chmura bywa realnie tańsza, bo płacisz tylko za użycie (albo korzystasz z darmowych limitów). Nie musisz inwestować w dodatkowy RAM czy mocniejszą kartę graficzną.

Przy codziennym, ciężkim korzystaniu – tysiące tokenów dziennie, testowanie wielu modeli, eksperymenty z narzędziami – lokalne LLM zaczyna mieć sens ekonomiczny. Płacisz za sprzęt, prąd i ewentualnie płatne GUI, ale nie ma rachunków za każdy wygenerowany token ani abonamentu. Rachunek opłacalności dobrze jest jednak policzyć pod swoje konkretne użycie, a nie w oparciu o ogólne slogany typu „lokalne zawsze tańsze”.

Dlaczego mój lokalny model zużywa więcej RAM niż wynika z rozmiaru pliku?

Plik modelu (np. 4 GB GGUF) to tylko wagi. Po załadowaniu dochodzą kolejne elementy: cache atencji (informacje o dotychczasowych tokenach), bufor kontekstu, narzut aplikacji (GUI, backend, ewentualny Python), a przy GPU także biblioteki obsługujące kartę. Stąd typowo realne zużycie pamięci to 1,5–3× rozmiar pliku modelu.

Im dłuższa konwersacja i większe okno kontekstu (np. 16k, 32k), tym szybciej rośnie cache i tym łatwiej o sytuację, w której system zaczyna przerzucać pamięć na dysk (swap). Efekt użytkowy jest prosty: najpierw przyjemnie szybkie odpowiedzi, a po godzinie jednej długiej sesji – nagły spadek responsywności, wentylator na pełnych obrotach i czasem twardy reset.

Bibliografia

• Attention Is All You Need. NeurIPS (2017) – Architektura transformerów, podstawa działania LLM
• GPT-4 Technical Report. OpenAI (2024) – Charakterystyka dużych modeli w chmurze, możliwości i ograniczenia
• Llama 3 Model Card. Meta AI (2024) – Opis architektury, rozmiarów modeli, zastosowań lokalnych LLM
• Mistral 7B Technical Report. Mistral AI (2023) – Parametry modelu 7B, wydajność i zastosowania praktyczne
• Qwen Technical Report. Alibaba Cloud (2023) – Opis rodziny modeli Qwen, wielojęzyczność, rozmiary parametrów
• Efficient Memory Management for Large Language Model Serving with PagedAttention. MLSys (2024) – Cache atencji, wpływ długości kontekstu na zużycie pamięci
• llama.cpp Documentation. ggerganov – Implementacja inference LLM na CPU, wymagania RAM/VRAM
• Hugging Face Transformers Documentation. Hugging Face – Praktyczne informacje o uruchamianiu i konfiguracji modeli LLM