Jeśli korzystasz z lokalnych modeli językowych, bardzo szybko zauważysz jedną rzecz: wszystkie ustawienia wyglądają na istotne, ale tylko kilka stanowi realne wąskie gardła (model, VRAM, offload, kontekst). Ten wpis to kompletne, praktyczne uzupełnienie materiału wideo. Zamiast omawiać każdy suwak osobno, skupiamy się na tym, co faktycznie wpływa na działanie modeli. Najważniejsza zasada: najpierw model, potem…
Jeśli korzystasz z lokalnych modeli językowych, bardzo szybko zauważysz jedną rzecz: wszystkie ustawienia wyglądają na istotne, ale tylko kilka stanowi realne wąskie gardła (model, VRAM, offload, kontekst).
Ten wpis to kompletne, praktyczne uzupełnienie materiału wideo. Zamiast omawiać każdy suwak osobno, skupiamy się na tym, co faktycznie wpływa na działanie modeli.
Najważniejsza zasada: najpierw model, potem ustawienia
Kolejność decyzji:
Model → kwantyzacja → VRAM/RAM → GPU offload → kontekst → parametry generowania
Jeśli pomylisz tę kolejność, będziesz optymalizował coś, co i tak nie ma szans działać dobrze.
Kwantyzacja , ukryty game changer
Jedna z najważniejszych rzeczy, której wiele osób nie docenia.
- Q4
- 🟢 bardzo szybkie, małe zużycie VRAM
- 🔴 na granicy wyraźnego spadeku jakości
- Q5 / Q6
- 🟢 najlepszy kompromis jakości i wydajności
- 🔴 nadal pewna utrata jakości względem pełnej precyzji
- Q8
- 🟢 najwyższa jakość
- 🔴 duże wymagania sprzętowe
Wniosek:
Lepiej większy model w niższej kwantyzacji niż mały w wysokiej.
Parametry, które naprawdę robią różnicę
1. Wielkość modelu
Największa dźwignia jakości.
Dlaczego to ważne:
- liczba parametrów bezpośrednio przekłada się na zdolność modelu do rozumienia kontekstu i wnioskowania
- większe modele lepiej radzą sobie z zadaniami złożonymi (analiza, kod, wnioskowanie wieloetapowe)
Wpływ na działanie:
- 🟢 większy model → lepsza jakość odpowiedzi, mniej halucynacji, lepsze wnioskowanie
- 🔴 większy model → wolniejsze generowanie, większe wymagania VRAM/RAM
Wniosek praktyczny:
Jeśli masz wybór: najpierw zwiększ model, dopiero potem baw się parametrami.
2. VRAM vs RAM
- model w VRAM → szybki
- model dzielony → wolny
Dlaczego to ważne:
- VRAM (GPU) ma dużo większą przepustowość niż RAM (CPU)
- przenoszenie danych między CPU a GPU jest bardzo kosztowne czasowo
Wpływ na działanie:
- 🟢 cały model w VRAM → maksymalna liczba tokenów/s, niskie opóźnienia
- 🔴 model dzielony (VRAM + RAM) → duży spadek wydajności, „zacinanie” generacji tokenów
Wniosek praktyczny:
Często lepiej użyć mniejszego modelu w całości na GPU niż większego, który „wylewa się” do RAM.
3. GPU Offload
Największy „suwak” wydajności.
Dlaczego to ważne:
- decyduje, jaka część modelu jest wykonywana na GPU, a jaka na CPU
- bezpośrednio wpływa na wykorzystanie VRAM
Wpływ na działanie:
- 🟢 wysoki offload → więcej obliczeń na GPU → znaczący wzrost prędkości
- 🔴 niski offload → więcej pracy na CPU → spadek tokenów/s
Wniosek praktyczny:
Zawsze ustawiaj maksymalny możliwy offload, który mieści się w VRAM , to jeden z najprostszych sposobów na przyspieszenie modelu.
4. Context length
- większy = wolniej + zużywa więcej pamięci
- mniejszy = szybsze działanie
Dlaczego to ważne:
- każdy dodatkowy token zwiększa ilość danych, które model musi przetworzyć
- wpływa bezpośrednio na zużycie VRAM i czas generacji
Wpływ na działanie:
- 🟢 większy kontekst → możliwość pracy na długich dokumentach
- 🔴 większy kontekst → spadek wydajności i większe zużycie pamięci
Wniosek praktyczny:
Nie ustawiaj maksymalnego kontekstu „na zapas” , dopasuj go do realnego use case’u.
Dla orientacji:
- 2000 tokenów ≈ 600,800 słów (~2,3 strony A4)
- 4000 tokenów ≈ 1200,1600 słów (~4,6 stron A4)
- 6000 tokenów ≈ 1800,2400 słów (~6,9 stron A4)
5. Przeznaczenie modelu (często pomijany, a kluczowy czynnik)
To jeden z najczęściej ignorowanych aspektów , a w praktyce ma ogromny wpływ na jakość odpowiedzi.
Dlaczego to ważne:
- modele są trenowane pod konkretne zastosowania
- różnią się danymi treningowymi, fine-tuningiem i optymalizacją
Typy modeli, które warto rozróżniać:
- modele konwersacyjne (chat)
- 🟢 dobre w dialogu, instrukcjach, ogólnej pracy
- 🔴 słabsze w zadaniach specjalistycznych
- modele do kodu (code)
- 🟢 lepsze generowanie i analiza kodu
- 🔴 mogą gorzej radzić sobie z językiem naturalnym
- modele językowe (np. PL, DE, EN-focused)
- 🟢 lepsza jakość w danym języku
- 🔴 często gorsze w zadaniach ogólnych
- modele fine-tuned (instrukcyjne)
- 🟢 lepsze wykonywanie poleceń
- 🔴 mogą być bardziej „sztywne”
- modele specjalistyczne (np. medyczne, prawne)
- 🟢 lepsze w konkretnej dziedzinie
- 🔴 słabsze poza nią
- modele multimodalne (vision)
- 🟢 obsługa obrazów i tekstu
- 🔴 większe wymagania sprzętowe
- modele z narzędziami (tools / function calling)
- 🟢 integracje z aplikacjami
- 🔴 większa złożoność
Wpływ na działanie:
- 🟢 dobrze dobrany model → lepsze odpowiedzi bez zmiany parametrów
- 🔴 źle dobrany model → żadna optymalizacja ustawień nie pomoże
Wniosek praktyczny:
Dobór modelu pod zastosowanie często daje większy efekt niż zmiana jakiegokolwiek parametru.
Jak testować ustawienia (żeby nie zgadywać)
Najczęstszy problem: zmieniasz parametry i „wydaje Ci się”, że jest lepiej.
Co mierzyć:
- tokeny/s
- czas pierwszego tokena
- jakość odpowiedzi
Jak testować:
- używaj tych samych promptów
- testuj 2,3 warianty
- zapisuj wyniki
Minimalny zestaw testowy:
- prompt techniczny
- prompt kreatywny
- praca na długim tekście
Wąskie gardła , dlaczego model działa wolno
Jeśli coś nie działa, to prawie zawsze jeden z tych powodów:
- model nie mieści się w VRAM
- za duży kontekst
- niski GPU offload
- CPU bottleneck
- zbyt duży model względem sprzętu
Gotowe konfiguracje (realne setupy)
8 GB VRAM
- model: 7B,8B (Q4/Q5)
- kontekst: 2k,4k
16 GB VRAM
- model: 13B
- kontekst: 4k,8k
CPU only
- małe modele
- niski kontekst
System Prompt , niedoceniany element
Dobrze napisany system prompt:
- stabilizuje odpowiedzi
- zmniejsza halucynacje
- często daje większy efekt niż zmiana temperature
Parametry o mniejszym znaczeniu
Nie oznacza to, że są nieistotne , tylko że nie są pierwszym miejscem do optymalizacji.
Temperature
Dlaczego to ważne:
- kontroluje „losowość” wyboru kolejnych tokenów
Wpływ na działanie:
- 🟢 wyższa (np. 0.8,1.0) → bardziej kreatywne, mniej przewidywalne odpowiedzi
- 🔴 wyższa → większe ryzyko błędów i halucynacji
- 🟢 niższa (np. 0.1,0.3) → bardziej deterministyczne, spójne odpowiedzi
- 🔴 niższa → odpowiedzi mogą być sztywne i powtarzalne
Wniosek praktyczny:
Do pracy technicznej używaj niskiej temperature, do kreatywnej , wyższej.
Top-p (nucleus sampling)
Dlaczego to ważne:
- ogranicza wybór tokenów do najbardziej prawdopodobnej części rozkładu
Wpływ na działanie:
- 🟢 niższe wartości (np. 0.8,0.9) → bardziej kontrolowane i spójne odpowiedzi
- 🔴 zbyt niskie → utrata różnorodności
- 🟢 wyższe (np. 0.95,1.0) → większa różnorodność
- 🔴 wyższe → większe ryzyko „odjechania” modelu
Wniosek praktyczny:
Najczęściej zostaw domyślne lub lekko obniż (0.9) dla większej stabilności.
Top-k
Dlaczego to ważne:
- ogranicza liczbę tokenów, z których model może wybierać
Wpływ na działanie:
- 🟢 niższe wartości → bardziej przewidywalne odpowiedzi
- 🔴 niższe → mogą być zbyt ograniczone
- 🟢 wyższe → większa swoboda generacji
- 🔴 wyższe → potencjalnie więcej błędów
Wniosek praktyczny:
W większości przypadków możesz zostawić domyślne , wpływ jest mniejszy niż temperature i top-p.
CPU threads
Dlaczego to ważne:
- określa, ile wątków CPU jest używanych do obliczeń
Wpływ na działanie:
- 🟢 więcej wątków → potencjalnie szybsze działanie przy CPU lub niskim offloadzie
- 🔴 zbyt dużo → brak realnej poprawy lub spadek wydajności (narzut systemowy)
Wniosek praktyczny:
Dopasuj do liczby rdzeni CPU, ale nie oczekuj dużych zmian , to optymalizacja drugiego rzędu.
Najczęstsze błędy
- ustawianie maksymalnego kontekstu
- wybór modelu „bo ranking”
- ignorowanie VRAM
- brak powtarzalnych testów
Kiedy optymalizacja nie ma sensu
- gdy model jest źle dobrany
- gdy sprzęt jest za słaby
- gdy problem jest w promptach
3 zasady, które warto zapamiętać
- Model decyduje o jakości
- VRAM decyduje o wydajności
- Kontekst decyduje o tym wykorzystaniu VRAM/RAM
FAQ
Czy większy kontekst zawsze jest lepszy?
Nie , spowalnia model i zwiększa zużycie pamięci.
Ile VRAM potrzebuję?
Im więcej, tym lepiej , ale kluczowe jest dopasowanie modelu.
Czy warto zmieniać temperature?
Tak, ale wpływa głównie na styl, nie wydajność.
Dlaczego model działa wolno?
Najczęściej przez brak VRAM lub zbyt duży kontekst.
Co dalej?
Poniżej jest film, który razem z tym wpisem stanowi spójną całość. Pokazuję w nim przykładowe zestawienie z wynikami modeli na moim komputerze.
Podsumowanie
Optymalizacja lokalnych modeli w LM Studio nie polega na „kręceniu suwakami” , tylko na podejmowaniu właściwych decyzji we właściwej kolejności.
Jeśli miałbyś zapamiętać tylko kilka rzeczy z tego wpisu:
- Dobór modelu (rozmiar + przeznaczenie) ma największy wpływ na jakość
- VRAM jest kluczowym ograniczeniem wydajności
- Kwantyzacja pozwala dopasować model do sprzętu bez dużej utraty jakości
- Kontekst to koszt , używaj go świadomie
- Parametry typu temperature czy top-p to kosmetyka względem powyższych
Najważniejszy wniosek:
Jeśli model działa słabo, problem prawie nigdy nie leży w ustawieniach , tylko w doborze modelu lub ograniczeniach sprzętu.
Dlatego zamiast optymalizować „wszystko”, skup się na:
- dobraniu właściwego modelu
- dopasowaniu go do VRAM
- ustawieniu sensownego kontekstu
Reszta to dopiero fine-tuning.
Sprawdź również:
- LM Studio – optymalizacja lokalnych LLM. Ustawienia, które naprawdę mają znaczenie
- Gotowe prompty AI dla inżynierów, które realnie przyspieszają pracę
- AI w Thunderbirdzie: automatyzacja maili, odpowiedzi i podsumowań z lokalnym LLM
- Thunderbird w 30 minut – jak ogarnąć chaos w mailach i odzyskać kontrolę
- Automatyczne generowanie kart pomieszczeń w Revit za pomocą Dynamo
