gik|iewicz

title: „Lokalny LLM nie jest głupi – to Twój stack go psuje, sprawdź dlaczego”
description: „Twój lokalny LLM nie jest głupi – działa skwantyzowany, z krótkim kontekstem i bez promptu systemowego. Sprawdź, co obniża jakość odpowiedzi i jak to naprawić.”
coverImage: „https://gikiewicz.eu/wp-content/uploads/2026/08/dlaczego-twoj-lokalny-llm-wydaje-sie-glupszy-niz-jest-w-rzec-cover.jpg”
date: „2026-08-23”
author: „Grzegorz Kikiewicz”
category: „AI”
tags:
– LLM
– lokalne-modele
– kwantyzacja
– ollama
slug: „dlaczego-twoj-lokalny-llm-wydaje-sie-glupszy-niz-jest-w-rzeczywistosci”

Użytkownicy lokalnych modeli LLM często porzucają je po pierwszych testach, bo model „wydaje się głupi”. Tymczasem problem w większości przypadków leży nie w samych wagach modelu, lecz w całym łańcuchu uruchomieniowym, który zniekształca to, co model faktycznie potrafi. Kwantyzacja, ucięty system prompt, złe parametry samplowania i zbyt mały kontekst potrafią obniżyć jakość odpowiedzi o kilka klas. Warto to zrozumieć, zanim wydasz werdykt.

TL;DR: Lokalny LLM rzadko jest tak słaby, jak wygląda po pierwszym uruchomieniu. Najczęściej to stack – kwantyzacja, domyślne parametry samplingu, ucięty kontekst i brak system prompta – degraduje jego odpowiedzi. Lifehacker opisuje, że lokalne modele można dziś uruchamiać nawet na telefonie, więc bariera wejścia jest niska, a próg frustracji zaskakująco wysoki.

Dlaczego kwantyzacja potrafi „ogłupić” lokalny model LLM?

Najczęstszy winowajca to kwantyzacja – kompresja wag modelu do mniejszej precyzji, bez której wiele kart graficznych po prostu nie udźwignęłoby modelu. Model 70B w pełnej precyzji FP16 zajmuje ponad 140 GB, natomiast wersja 4-bitowa mieści się w okolicach 40 GB. Taka redukcja ma jednak swoją cenę, ponieważ mniej precyzyjne wagi wprowadzają szum do każdego kroku wnioskowania.

W praktyce różnica między Q8 a Q4 bywa odczuwalna głównie w zadaniach wymagających precyzji: arytmetyce, kodzie, wieloetapowym rozumowaniu. W prostszych zadaniach konwersacyjnych degradacja bywa niemal niezauważalna. Dlatego warto testować kilka poziomów kwantyzacji tego samego modelu, zanim orzeknie się, że jest słaby. Rekomenduję zacząć od najwyższej precyzji, jaką pozwala uruchomić dostępny sprzęt.

• Q8_0 – minimalna degradacja jakości, wysokie wymagania VRAM
• Q6_K – dobry kompromis między jakością a rozmiarem
• Q5_K_M – często sweet spot dla modeli klasy 7B-14B
• Q4_K_M – popularny wybór, lecz widoczna utrata precyzji w kodzie
• IQ4_XS – agresywna kompresja dla słabszych kart graficznych

Jak parametry samplingu psują wrażenie z lokalnego modelu?

Domyślne temperature i top_p w wielu lokalnych narzędziach są ustawione „na oko” i rzadko odpowiadają wartościom, z jakimi model był trenowany. Zbyt wysoka temperatura sprawia, że model zaczyna halucynować i gubi wątek, natomiast zbyt niska czyni odpowiedzi sztampowymi i płytkimi. Użytkownik widzi efekt i wini wagi, choć wystarczyłoby przekręcić jeden suwak.

Na przykład modele typu reasoning często wymagają temperatury bliskiej wartościom z karty modelu na Hugging Face, a nie generycznym 0.7 z aplikacji. Co więcej, powtarzanie penalizacji (repetition penalty) ustawione zbyt agresywnie potrafi rozbić spójność dłuższych odpowiedzi. Moim zdaniem to drugi, po kwantyzacji, najczęstszy powód fałszywego wyroku „ten model jest głupi”.

Dlaczego ucięty kontekst i brak system prompta obniżają inteligencję modelu?

Wiele lokalnych konfiguracji domyślnie ustawia krótkie okno kontekstu, na przykład 2048 lub 4096 tokenów, choć model obsługuje znacznie więcej. Skutkiem tego dłuższa rozmowa zostaje cicho obcięta, a model „zapomina” wcześniejsze ustalenia i zaczyna odpowiadać niespójnie. Użytkownik interpretuje to jako brak rozumowania, mimo że to zwykła amputacja pamięci.

Podobnie dzieje się z system promptem. Duże modele chmurowe, takie jak ChatGPT czy Claude, dostają rozbudowane instrukcje od dostawcy, natomiast lokalny model często startuje z pustym promptem. W rezultacie odpowiada „gołymi” wagami, bez stylu, formatu i ograniczeń, do których przyzwyczaił użytkownik. Lifehacker w przewodniku How to Run a Local LLM on Your Phone pokazuje, że sam model to tylko fragment układanki – reszta zależy od konfiguracji środowiska uruchomieniowego.

Czy porównujesz lokalny LLM z odpowiednikiem z chmury uczciwie?

Ostatni problem jest psychologiczny, a nie techniczny. Użytkownik porównuje lokalny model 7B z ChatGPT czy Claude napędzanym znacznie większym modelem, wzbogaconym o system prompt, RAG i warstwę bezpieczeństwa. To porównanie nieuczciwe z definicji, ponieważ po jednej stronie stoi cały zespół inżynierów promptowych, a po drugiej surowe wagi na domowym GPU.

Sprawiedliwy test wymagałby porównania podobnej klasy modeli w podobnych warunkach. Na przykład warto sprawdzić, czy lokalny model z dobrym system promptem, sensowną kwantyzacją i pełnym kontekstem wciąż odstaje od wersji chmurowej tego samego modelu. Zwykle różnica topnieje. Więcej o praktyce lokalnego uruchamiania modeli pisałem w tekście Przestałem płacić za ChatGPT i przeszedłem na lokalny model LLM działający na moim laptopie, a o narzędziach do tego służących – w notce o Lemonade od AMD: szybkim i otwartym lokalnym serwerze LLM.

Jak format czatu i szablon prompta wpływają na jakość odpowiedzi?

Najczęściej pomijany element to chat template – schemat, w jaki rozmowa jest przekształcana na tokeny wejściowe. Każdy model był trenowany na konkretnym formacie, na przykład ChatML czy Llama-3, natomiast wiele lokalnych aplikacji domyślnie stosuje własny, uniwersalny szablon. W rezultacie model dostaje wejście, którego nigdy nie widział podczas treningu, i odpowiada gorzej, choć jego wagi są w pełni sprawne.

Objaw jest charakterystyczny. Model zaczyna wtrącać dziwne znaczniki, odpowiada jakby kontynuował cudzą wypowiedź albo gubi rolę asystenta. Co więcej, błędny szablon potrafi całkowicie zepsuć modele reasoning, które polegają na specjalnych tokenach rozpoczynających sekwencję myślenia. Dlatego przed oceną modelu warto sprawdzić, czy silnik ładuje szablon z pliku GGUF, zamiast stosować domyślny.

• Sprawdź, czy tokenizer_config zawiera właściwy chat_template
• Porównaj wyjście z podglądu prompta w LM Studio lub Ollama
• Unikaj ręcznego sklejania historii rozmowy bez znaczników ról
• Testuj modele reasoning wyłącznie z natywnym szablonem
• Zweryfikuj, czy tokeny systemowe trafiają tam, gdzie model ich oczekuje

Czy sprzęt i backend uruchomieniowy mogą obniżać inteligencję modelu?

Sam fakt zmieszczenia modelu w VRAM nie gwarantuje poprawnego działania. Podobnie jak w smartfonach, gdzie – jak opisuje Antyweb – nawyki użytkownika potrafią marnować potencjał urządzenia, tak w lokalnym LLM zła konfiguracja backendu marnuje potencjał wag. Gdy model nie mieści się w całości na karcie graficznej, część warstw trafia do RAM-u i następuje tzw. offloading.

Skutek jest podwójny. Po pierwsze, spada prędkość generowania, a długie odpowiedzi wymagają cierpliwości, co zniechęca do dopytywania i iterowania. Po drugie, niektóre backendy przy braku VRAM po cichu obniżają okno kontekstu albo wymuszają agresywniejszą kwantyzację cache. Użytkownik tego nie widzi, widzi natomiast gorsze odpowiedzi. Zatem zanim wydasz werdykt o modelu, sprawdź logi silnika pod kątem komunikatów o offloadingu.

Jak uczciwie przetestować lokalny model przed wydaniem werdyktu?

Rzetelny test wymaga kontroli całego stacku, a nie tylko samych wag. Przede wszystkim ustal punkt odniesienia: uruchom model w najwyższej kwantyzacji, na jaką pozwala sprzęt, z szablonem z karty modelu, pełnym kontekstem i sensownym system promptem. Dopiero wtedy porównuj wyniki z oczekiwaniami. Lifehacker opisuje, że lokalne modele działają dziś nawet na telefonie, więc warunki startowe są łatwe do spełnienia.

Warto też zmieniać jeden parametr naraz. Na przykład jeśli testujesz wpływ temperatury, trzymaj stałą kwantyzację i kontekst. W przeciwnym razie nie wiesz, który element poprawił lub pogorszył wynik. Moim zdaniem większość negatywnych opinii o lokalnych modelach pochodzi z testów, w których zmieniono wszystko naraz i nie ustalono żadnej linii bazowej.

Co dalej po naprawieniu konfiguracji?

Gdy stack już działa poprawnie, lokalny model często zaskakuje. Więcej o moich doświadczeniach z odejściem od subskrypcji pisałem w tekście Przestałem płacić za ChatGPT i przeszedłem na lokalny model LLM działający na moim laptopie. Ciekawym dowodem na elastyczność tej technologii jest projekt opisany w Running a 28.9M parameter LLM on an $8 microcontroller.

Często zadawane pytania

Jaka kwantyzacja jest bezpiecznym minimum do oceny modelu?

Q6_K to rozsądne minimum – poniżej Q4 degradacja w kodzie i arytmetyce staje się wyraźna. Dlatego werdykt o „głupocie” modelu wystawiony na wersji Q4 lub niższej nie jest miarodajny.

Dlaczego model zapomina początek rozmowy?

Najczęściej przez okno kontekstu ustawione domyślnie na 2048 lub 4096 tokenów, choć model obsługuje znacznie więcej. Wystarczy zwiększyć context length w ustawieniach silnika, na przykład w LM Studio lub Ollama.

Czy temperatura ma aż tak duże znaczenie?

Tak – zbyt wysoka temperatura powoduje halucynacje i chaos w odpowiedziach. Rekomendacja jest konkretna: bierz wartości z karty modelu na Hugging Face, a nie generyczne 0.7 z aplikacji.

Czy lokalny model 7B może dorównać ChatGPT?

W uczciwym teście – ten sam model, dobry system prompt, pełny kontekst – różnica względem wersji chmurowej tego samego modelu zwykle topnieje. Porównywanie 7B z ChatGPT bez dostrojenia stacku jest natomiast nieuczciwe z definicji.

Podsumowując, lokalny LLM rzadko jest tak głupi, jak sugeruje pierwsze uruchomienie. Po pierwsze, kwantyzacja poniżej Q6 wyraźnie obniża jakość w zadaniach wymagających precyzji. Po drugie, domyślne parametry samplingu i ucięty kontekst psują wrażenie niezależnie od wag. Po trzecie, błędny chat template potrafi całkowicie zepsuć komunikację z modelem. Po czwarte, porównanie z chmurą bez dostrojenia stacku jest po prostu nieuczciwe. Zanim więc skasujesz model z dysku – sprawdź konfigurację. A jeśli chcesz porozmawiać o swoich testach lokalnych LLM, zostaw komentarz pod tym artykułem.

Autor: Grzegorz Kikiewicz – programista i autor bloga gikiewicz.eu, gdzie od lat pisze o technologii, AI i praktycznym programowaniu. Na co dzień testuje lokalne modele LLM i narzędzia open source.