Praktyczny przewodnik po lokalnym uruchamianiu LLM: jak zbudować własną prywatną sztuczną inteligencję na domowym PC

Po co w ogóle lokalny LLM? Motywacje i granice możliwości

Prywatność danych: co faktycznie zostaje „u siebie”, a co nie

Najczęstsza motywacja do lokalnego uruchamiania LLM jest prosta: nic nie wypływa z komputera. Standardowe czatboty w chmurze działają na cudzych serwerach. Każde pytanie, każdy fragment kodu, każde poufne zdanie trafia do zewnętrznej infrastruktury – nawet jeśli jest później anonimizowane. Przy modelu lokalnym wszystko odbywa się na Twoim PC: tekst wejściowy, generowanie odpowiedzi, bufor kontekstu – całość żyje w RAM-ie i na dysku.

To jednak działa pod pewnymi warunkami. Jeśli używasz prostych aplikacji typu LM Studio, Ollama czy OpenWebUI i nie konfigurujesz żadnych zewnętrznych usług telemetrii ani wtyczek do chmury, dane faktycznie zostają lokalnie. Ale gdy do gry wchodzą rozszerzenia (np. wyszukiwanie w sieci, podpinanie usług typu Google Drive, integracje przeglądarkowe), łatwo nieświadomie wynieść część treści na zewnątrz. Konfiguracja dodatków wymaga więc minimum świadomości: co łączy się z internetem, a co nie.

Lokalny LLM jest szczególnie sensowny tam, gdzie operujesz na treściach objętych NDA, danych klientów, nieopublikowanym kodzie, analizach finansowych czy prywatnych notatkach. W takich scenariuszach wysyłanie czegokolwiek do modelu chmurowego bywa wprost zabronione polityką firmy. Własna instancja modelu na domowym PC pozwala obejść ten problem – oczywiście pod warunkiem, że komputer sam w sobie jest odpowiednio zabezpieczony.

Istotny aspekt: lokalność nie oznacza pełnej anonimowości. System operacyjny może zbierać dane diagnostyczne, oprogramowanie antywirusowe skanuje pamięć, a kopie zapasowe mogą lądować w chmurze. Jeśli modele obsługują historię czatów, jest ona zapisywana na dysku. Trzeba więc dopasować poziom ochrony do poziomu wrażliwości danych – od szyfrowania dysku, po wyłączenie backupu dla folderu z historią rozmów.

Koszty i niezależność od chmury – kiedy lokalny model ma sens

Drugim silnym motywatorem są koszty. Przy intensywnym używaniu modeli chmurowych (szczególnie tych z wysokimi limitami kontekstu) rachunek miesięczny potrafi rosnąć szybko i boleśnie. W lokalnym podejściu płacisz głównie za sprzęt i prąd. Model raz pobrany możesz używać bez liczenia tokenów i zastanawiania się, czy kolejna długa analiza zmieści się w darmowym limicie.

Lokale LLM ma sens, gdy:

• pracujesz z modelem codziennie, często i długo,
• przetwarzasz spore ilości tekstu (długie notatki, dokumentacje, logi),
• nie chcesz wiązać się jednym dostawcą chmury i jego polityką cenową,
• zależy Ci na pracy offline – np. na wyjazdach, w słabym internecie, w sieci odłączonej od świata.

Modele chmurowe mają przewagę pod względem jakości – zwłaszcza topowe, bardzo duże architektury. Jednak w wielu zadaniach biurowych i programistycznych sensownie skonfigurowany model lokalny daje „wystarczająco dobry” poziom, przy znacznie niższych długoterminowych kosztach. Inny plus: uniezależniasz się od zmian API, zmian regulaminu czy nagłego wycofania modelu z oferty.

Na tle rosnących kosztów usług subskrypcyjnych trend jest podobny jak przy usługach streamingowych. Zamiast mieć wszystko wszędzie, masz dobrze dobrane narzędzie na własnym sprzęcie. Oczywiście, wymaga to trochę wysiłku konfiguracyjnego, ale raz ustawione środowisko służy latami.

Realistyczne oczekiwania: gdzie lokalny LLM wygrywa, a gdzie przegrywa z chmurowym

Lokalny LLM nie zamieni domowego PC w kopię najnowszego, gigantycznego modelu z chmury. Różnica jest głównie w skali. Modele chmurowe to często dziesiątki lub setki miliardów parametrów, trenowane na ogromnych zbiorach danych, złożonych pipeline’ach RLHF i specjalistycznych systemach bezpieczeństwa. W domu pracujesz z modelami mniejszymi i silniej skompresowanymi.

Lokalny model często wygrywa w:

• zadaniach powtarzalnych i „rzemieślniczych”: streszczanie, porządkowanie tekstu, parafrazy,
• generowaniu kodu na bazie lokalnej bazy wiedzy (np. Twoje repozytoria, dokumentacja projektu),
• scenariuszach, gdzie liczy się prywatność, a nie absolutnie najlepsza możliwa odpowiedź,
• specjalistycznych zadaniach, jeśli wybierzesz model dopasowany do niszy (np. „coder”, „math”).

Z kolei przegrywa (na razie) tam, gdzie wymagane jest:

• bardzo głębokie rozumienie kontekstu (długie dialogi, wiele dokumentów naraz),
• czysto „kreatywne” teksty najwyższej jakości literackiej lub marketingowej,
• złożone rozumowanie mieszające tekst, obrazy, kod, wykresy,
• najwyższa odporność na błędy i halucynacje w zadaniach wymagających dużej precyzji.

Dobrze działa podejście hybrydowe: lokalny LLM do codziennej pracy (notatki, kod, tłumaczenia) i chmura do momentów „premium” – np. raz na jakiś czas, gdy potrzebujesz dopracowanego tekstu pod publikację lub bardzo skomplikowanej analizy.

Typowe zastosowania w domu i małej firmie

W praktyce lokalne LLM na PC świetnie sprawdza się w roli osobistego „pomocnika tekstowego”. W domu może obsługiwać:

• streszczanie artykułów i materiałów do nauki,
• tworzenie planów nauki, list zadań, konspektów projektów hobby,
• redakcję tekstów: poprawa stylu, upraszczanie złożonych opisów technicznych,
• tworzenie scenariuszy DIY – np. opis kroków do zbudowania własnego serwera NAS.

W małej firmie lokalny model jest przydatny do:

• obrabiania dokumentów: podsumowania umów, wyciąganie kluczowych punktów,
• tworzenia draftów maili, ofert, prostych instrukcji dla klientów,
• wstępnej analizy opinii klientów (podział na kategorie, wyciąganie tematów),
• wsparcia zespołu programistycznego bez wysyłania kodu do chmury.

Przykład z życia: ktoś buduje system inteligentnego domu opartego na Home Assistant. Lokalny LLM pomaga mu generować fragmenty konfiguracji YAML, tłumaczyć dokumentację integracji z angielskiego na polski i wyjaśniać błędy w logach. Cały projekt jest „w kapciach”, bez obaw o wrażliwe dane o domowej infrastrukturze.

Jak działa LLM w pigułce – intuicyjnie, bez matematyki

Predykcja kolejnych słów zamiast „myślenia”

Model językowy nie „rozumie” tekstu jak człowiek. Działa jak ekstremalnie dobrze wytrenowany system przewidywania kolejnych słów. Na wejściu dostaje ciąg tokenów (kawałków tekstu), a jego zadaniem jest policzyć, jaki token powinien pojawić się jako następny. Na tej podstawie generuje odpowiedź – słowo po słowie, token po tokenie.

Cała magia polega na tym, że model widział podczas treningu ogromne ilości tekstu. Nauczył się wzorców: jak wygląda poprawna składnia, jak łączą się pojęcia, jakie są typowe odpowiedzi na konkretne pytania. Gdy prosisz o wyjaśnienie pojęcia, model nie szuka w bazie gotowych definicji – on odtwarza strukturę definicji, która „pasuje” do Twojej prośby i do tego, co nauczył się wcześniej.

Na poziomie praktycznym oznacza to dwie rzeczy:

• model bywa genialny w „dopowiadaniu” sensownych fragmentów,
• model nie ma pojęcia, czy to, co generuje, jest prawdziwe – liczy się tylko „statystyczna spójność”.

Właśnie dlatego lokalny LLM może być doskonałym narzędziem do pisania, tłumaczeń czy generowania kodu – ale wymaga czujnego użytkownika, który weryfikuje wyniki.

Parametry, architektura, wersje „instruct” i „chat”

Każdy model językowy ma określoną architekturę (np. rodzina LLaMA, Mistral, Phi) i liczbę parametrów (o tym za chwilę). Na tej bazie może powstać wiele wariantów przeznaczonych do różnych zadań. Dwie szczególnie ważne grupy to modele:

• „base” – surowe, wytrenowane do przewidywania kolejnych słów, bez specjalnego dostosowania do dialogu,
• „instruct” / „chat” – dodatkowo „nauczone”, jak odpowiadać na polecenia, pytania, prowadzić rozmowę.

Modele typu „instruct” powstają zazwyczaj przez fine-tuning (dodatkowe trenowanie) na zbiorach dialogów typu „pytanie – dobra odpowiedź”. Dzięki temu wiedzą, że po zdaniu „Wyjaśnij krok po kroku, jak…” powinny wygenerować uporządkowaną instrukcję, a nie np. kontynuację w stylu literackim.

Na potrzeby lokalnej sztucznej inteligencji na domowym PC prawie zawsze wybiera się modele „chat” lub „instruct”. Modele „base” są świetne dla badaczy i twórców kolejnych fine-tuningów, ale w codziennej pracy potrafią zachowywać się dziwnie: ignorować polecenia, gubić strukturę odpowiedzi czy schodzić w dygresje.

Co oznaczają nazwy typu „7B”, „13B”, „70B” i wpływ na sprzęt

Oznaczenia 7B, 13B, 34B, 70B odnoszą się do liczby parametrów modelu – w miliardach (Billion). 7B to około 7 miliardów parametrów, 13B – około 13 miliardów, itd. Im więcej parametrów, tym potencjalnie:

• lepsza jakość odpowiedzi (bogatsza „pamięć” wzorców),
• lepsze rozumienie złożonych pytań i dłuższych kontekstów,
• większe wymagania sprzętowe: RAM, VRAM i moc obliczeniowa.

Dla uproszczenia:

• modele 3B–7B – lekkie, dobre na słabsze laptopy, przyzwoite do prostych zadań,
• modele 8B–14B – złoty środek: zauważalnie lepsze odpowiedzi, ale nadal możliwe do uruchomienia na sensownym domowym PC,
• modele 30B+ – ciężkie działa: bardzo dobre, ale wymagają mocnego GPU lub dużej ilości RAM.

W praktyce sporo użytkowników kończy z jednym „małym” modelem 7–8B do szybkich zadań i jednym większym 13–14B do pracy, gdzie jakość jest ważniejsza niż czas generacji. Największe modele (30B i więcej) nadal są możliwe do uruchomienia lokalnie, ale głównie na maszynach z dużą ilością VRAM (np. 24 GB i więcej) albo w mocno skompresowanej postaci, co bywa kompromisem jakości.

Skąd się bierze „halucynowanie” i dlaczego lokalny model też się myli

„Halucynacja” to sytuacja, w której model generuje odpowiedź przekonująco brzmiącą, ale niezgodną z faktami – np. „wymyśla” biblioteki, cytaty, funkcje w języku programowania, które nie istnieją. Powód jest prosty: model nie ma wbudowanego modułu prawdy. Jego zadanie to jedynie przewidzieć najbardziej prawdopodobną kontynuację tekstu.

Podczas treningu widział wiele przykładów racjonalnych odpowiedzi, ale też błędnych fragmentów, fikcji, żartów. Jeśli kontekst zachęca do „wymyślania” (np. pytania o nieistniejące rzeczy), model bez wahania to zrobi, bo tak wyszło z jego wewnętrznych statystyk. Lokalne LLM, niezależnie od tego, że działa na Twoim komputerze, ma ten sam mechanizm – korzysta z tych samych rodzin architektur i podobnych danych treningowych.

Ograniczenie halucynacji wymaga kilku podejść:

• dawanie bardzo konkretnych, precyzyjnych poleceń,
• prośba o wskazywanie źródeł, a następnie samodzielna weryfikacja,
• łączenie modelu z lokalną bazą wiedzy (np. dokumentami) – czyli tzw. RAG (Retrieval-Augmented Generation).

W trybie RAG model nie „zgaduje” z próżni, tylko najpierw przeszukuje Twoje dokumenty i dopiero na tej podstawie buduje odpowiedź. To właśnie kierunek, w którym rozwija się wiele domowych instalacji prywatnej sztucznej inteligencji – z czatbota robi się asystent pracujący na Twojej lokalnej wiedzy.

Sprzęt pod lokalny LLM: co wystarczy, a co będzie męką

Minimalny sensowny zestaw: RAM, CPU, GPU w różnych scenariuszach

Modele językowe są łakome na pamięć. Przy lokalnym uruchamianiu LLM liczą się głównie trzy rzeczy:

• RAM – ilość pamięci operacyjnej systemu,
• VRAM – pamięć karty graficznej, jeśli chcesz korzystać z GPU,
• CPU/GPU – moc obliczeniowa, która decyduje o szybkości generacji.

Jeśli model zmieści się w VRAM, generacja odpowiedzi będzie zazwyczaj kilkukrotnie szybsza niż na samym procesorze. Gdy się nie mieści, część obliczeń ląduje w RAM i na CPU, co spowalnia pracę, ale nadal bywa używalne do spokojnych, „niechatowych” zadań (np. generowania dłuższego tekstu w tle).

Praktyczne progi sprzętowe wyglądają mniej więcej tak:

• 8 GB RAM, brak dedykowanego GPU – absolutne minimum; da się uruchomić bardzo małe, mocno skompresowane modele 3B–4B, raczej jako ciekawostkę niż codzienne narzędzie,
• 16 GB RAM + dowolna karta z 4–6 GB VRAM – sensowny start: modele 7B chodzą, choć czasem częściowo na CPU, do notatek, prostego kodu i szybkich podpowiedzi,
• 32 GB RAM + GPU 8–12 GB VRAM – komfortowa strefa: modele 7B–8B w całości na GPU, 13B z częściowym wsparciem GPU, niezła prędkość nawet przy dłuższych sesjach,
• 64 GB RAM + GPU 16–24 GB VRAM – półprofesjonalna konfiguracja: modele 13B w całości na GPU, eksperymenty z 30B, jednoczesne działanie kilku instancji modelu.

Do tego dochodzi sam procesor. Nowoczesne wielordzeniowe CPU (np. 6–8 rdzeni) radzą sobie już całkiem sprawnie nawet bez GPU, o ile nie oczekujesz „wrażenia rozmowy na żywo”. Starsze laptopy z 2–4 rdzeniami też coś udźwigną, ale odpowiedzi będą pojawiały się linijka po linijce, jak dawniej tekst z modemu – akceptowalne dla cierpliwych, męczące przy dłuższym użyciu.

Przy wyborze sprzętu łatwo wpaść w pułapkę gonienia za „największym możliwym modelem”. Bardziej opłaca się dobry balans: przyzwoita ilość RAM, solidna karta graficzna o sensownym VRAM i szybki dysk SSD, niż jedna ekstremalnie droga część i reszta „na styk”. Dzięki temu lokalna sztuczna inteligencja przestaje być demem z konferencji, a staje się codziennym narzędziem, które naprawdę przyspiesza pracę – od notatek, przez kod, po prywatne eksperymenty z własnym małym ekosystemem AI.

SSD, przepustowość i dlaczego dysk też ma znaczenie

Przy LLM wszyscy patrzą na GPU i RAM, a dysk traktują jak tło. Tymczasem model musi zostać z tego dysku wczytany do pamięci – i to często plik ważący od kilku do kilkudziesięciu gigabajtów. Na talerzowym HDD pierwsze uruchomienie modelu potrafi trwać wieczność; na szybkim SSD NVMe zajmuje to zauważalnie mniej czasu i całość „czuje się” lżej.

Popularne blogi technologiczne, takie jak Informatyka, Nowe technologie, AI, coraz częściej opisują podobne, praktyczne scenariusze użycia, pokazując, że osobista sztuczna inteligencja offline przestaje być ciekawostką, a staje się narzędziem codziennego użytku.

Dysk wpływa na dwie rzeczy:

• czas startu modelu – jak długo czekasz, zanim w ogóle pojawi się pierwsza odpowiedź,
• komfort pracy przy przełączaniu modeli – jeśli lubisz mieć kilka różnych LLM i żonglować nimi w ciągu dnia, wolny dysk zaczyna być naprawdę irytujący.

Do lokalnego LLM rozsądnie jest przeznaczyć osobny folder (albo nawet osobny dysk/partycję) na modele i dane pomocnicze. Dzięki temu:

• łatwiej robić kopie zapasowe i przenosić całą instalację między komputerami,
• nie mieszasz kilkudziesięciogigabajtowych plików z codziennymi dokumentami.

Jeśli masz wybór: dołożyć trochę VRAM czy wymienić HDD na SSD – dla modeli 7B–13B szybszy dysk często daje odczuwalnie większy „skok komfortu” niż symboliczny przyrost pamięci karty graficznej.

Laptop vs desktop: mobilność kontra wygoda pracy z modelem

Lokalne LLM „lubią” stabilne chłodzenie i ciągłe zasilanie. Stacjonarny PC ma tu naturalną przewagę: większe obudowy, lepsze radiatory, możliwość wsadzenia pełnowymiarowej karty graficznej. Przy dłuższych sesjach (np. generowanie dokumentacji czy kodu przez kilkadziesiąt minut) różnica w temperaturach i głośności jest ogromna.

Laptop z kolei pozwala zabrać prywatną AI do kawiarni lub w podróż. W tym scenariuszu pomagają trzy proste nawyki:

• ograniczenie mocy GPU w ustawieniach systemu lub sterownika – trochę wolniej, ale ciszej i chłodniej,
• podłączenie zasilacza – pełna wydajność, brak nerwowego zbijania taktowań,
• korzystanie z mniejszych modeli (3B–7B) w wersjach mocno skompresowanych, gdy jesteś „w terenie”.

Dobry kompromis to konfiguracja hybrydowa: mocniejszy desktop w domu z większymi modelami i lekki laptop z 7B na krótkie zadania. Modele i konfiguracje można synchronizować między maszynami np. za pomocą dysku zewnętrznego lub prywatnego NAS-a.

Przegląd popularnych narzędzi: jak wybrać swoje środowisko

Ollama – „app store” dla modeli na macOS, Windows i Linux

Ollama to jedno z najwygodniejszych narzędzi do pierwszego kontaktu z lokalnym LLM. Działa jak połączenie menedżera modeli, silnika wykonawczego i prostego serwera API. Po instalacji wszystko sprowadza się do komend w stylu:

ollama pull llama3
ollama run llama3

Najważniejsze cechy Ollamy:

• prosta instalacja – gotowy instalator na wszystkie główne systemy,
• wbudowana kolekcja modeli – pobierasz po nazwie, bez ręcznego szukania plików,
• lokalne API – po uruchomieniu modelu możesz łączyć się z nim z innych aplikacji tak, jak z „chmury”.

Ollama szczególnie dobrze sprawdza się na macOS (świetne wsparcie dla procesorów Apple Silicon), ale na Windows i Linuksie też radzi sobie coraz lepiej. Jeśli zależy Ci na „żeby po prostu działało” i nie chcesz śledzić każdego detalu konfiguracji, to bezpieczny start.

LM Studio – graficzny „kombajn” dla osób, które nie lubią terminala

LM Studio to aplikacja z interfejsem graficznym, która pozwala:

• przeglądać katalog modeli (głównie z Hugging Face),
• pobierać je jednym kliknięciem,
• konfigurować parametry generacji (temperatura, długość odpowiedzi, liczba wątków),
• udostępniać lokalne API zgodne z OpenAI.

Przydaje się, gdy chcesz:

• szybko porównywać różne modele „na oko” w jednym oknie,
• mieć historię czatów i możliwość ich tagowania,
• korzystać z lokalnego modelu w narzędziach nastawionych na API OpenAI (np. wtyczki do IDE) bez pisania własnego serwera.

Dla wielu użytkowników LM Studio staje się centrum dowodzenia: w tle działa serwer, w przeglądarce odpalone są dodatki do notatek czy VS Code, a całość wykorzystuje jeden wspólny model przydzielony w aplikacji.

Oobabooga / Text Generation WebUI – elastyczny, ale bardziej „hobbystyczny” potwór

Text Generation WebUI (znane także jako Oobabooga) to rozbudowany, webowy interfejs dla lokalnych modeli, który uruchamiasz we własnej przeglądarce. Jest niezwykle elastyczny:

• obsługuje wiele silników (m.in. llama.cpp, Transformers, ExLlama),
• pozwala łatwo przełączać modele,
• ma system wtyczek: pamięć długoterminowa, RAG, integracje z innymi usługami.

Ceną za tę wszechstronność jest odrobina „majsterkowania”:

• instalacja zwykle wymaga Pythona i kilku kroków w terminalu,
• konfiguracja liczby wątków, urządzeń (CPU/GPU) czy typów kwantyzacji bywa przytłaczająca na start.

Jeśli jednak lubisz mieć wszystko pod kontrolą i chcesz eksperymentować z różnymi rodzinami modeli, Oobabooga jest jednym z najbogatszych ekosystemów w świecie lokalnego LLM.

llama.cpp i spółka – narzędzia „bliżej metalu”

llama.cpp to projekt, od którego zaczęła się fala lekkich, skompilowanych modeli w formacie GGUF. Jego główny cel: maksymalnie wydajny inference (uruchamianie modelu) na zwykłych CPU, z opcjonalnym wsparciem GPU. Z llama.cpp korzysta „pod spodem” wiele aplikacji, w tym LM Studio czy różne wtyczki.

Bezpośrednia praca z llama.cpp ma sens, gdy:

• chcesz wycisnąć maksimum z konkretnego sprzętu (np. płynnie dobrać wątki, offload na GPU, poziom kwantyzacji),
• planujesz własne skrypty i automatyzacje,
• lubisz minimalizm: jeden binarny plik, model i kilka flag w linii komend.

Podobną rolę pełnią inne projekty „silnikowe”, np. koboldcpp czy exllamav2, ale dla typowego użytkownika wygodniej korzystać z nich przez gotowe UI (LM Studio, Oobabooga) niż bezpośrednio.

Modele do domu: co pobrać, by się nie zniechęcić

Rodziny modeli przyjazne użytkownikowi

Modele z różnych rodzin mają różny „charakter”. Kilka popularnych i przyjaznych na start:

• LLaMA 3 / LLaMA 3.1 – bardzo dobre ogólne modele, świetne w rozmowie, tłumaczeniu i ogólnych zadaniach biurowych; wersje 8B i 12B są realistyczne do domu,
• Mistral / Mixtral – wydajne i „sprytne” modele z Europy, często lepiej zoptymalizowane niż starsze LLaMA; Mixtral to model typu „mixture-of-experts”, który bywa wyjątkowo mocny na kodzie i analizie tekstu,
• Phi-3 – małe, ale zaskakująco kompetentne modele, szczególnie dobre na słabsze maszyny; wersja 3.8B potrafi zachowywać się dużo „mądrzej”, niż sugeruje rozmiar.

Dodatkowo są wyspecjalizowane fine-tuningi:

• modele „Coder”/„Code” – zoptymalizowane do programowania,
• modele „Math” – lepsze w zadaniach obliczeniowych,
• modele „Instruct”/„Chat” – do ogólnej rozmowy i poleceń.

Dla domowego asystenta najlepiej sprawdzają się warianty „Instruct/Chat”. Jeśli potrzebny jest dodatkowo asystent do kodu, sensowny zestaw to jeden model ogólny i jeden stricte programistyczny – przełączasz je zależnie od zadania.

Rozmiar a zastosowania – kilka praktycznych „presetów”

Dobór modelu da się sprowadzić do kilku prostych profili użytkownika.

Profil 1: lekkie notatki, proste teksty, pomoc w nauce
Masz laptop z 16 GB RAM i zintegrowaną grafiką. W takim scenariuszu:

• model 3B–4B (np. Phi-3-mini) w średniej kwantyzacji Q4 będzie działać płynnie,
• wystarczy do streszczeń tekstów, prostych wyjaśnień, fiszek do nauki,
• w kodzie pomoże raczej na poziomie podpowiedzi niż skomplikowanej architektury.

Profil 2: codzienny asystent pracy biurowej + kod
PC z 32 GB RAM i GPU 8–12 GB VRAM:

• model ogólny 7B–8B w dobrej kwantyzacji (Q4–Q5) – np. LLaMA 3 8B Instruct,
• do kodu osobny model 7B „Coder” lub Mixtral 8x7B w bardziej agresywnej kwantyzacji,
• prędkość generacji na poziomie „rozmowy” przy odpowiednim ustawieniu wątków.

Profil 3: półprofesjonalna „mini-chmura” dla kilku domowników
Masz maszynę z 64 GB RAM i GPU 24 GB VRAM:

• jeden model ogólny 13B,
• jeden model kodowy 13B (lub mocny Mixtral),
• opcjonalnie mniejszy 7B jako „lekki” do szybkich drobiazgów,
• serwer API wystawiony w sieci lokalnej (np. przez Ollama lub Oobabooga), z którego korzysta kilka urządzeń jednocześnie.

Kwantyzacja – co oznaczają Q2, Q4, Q5, Q8

Kwantyzacja to sposób kompresowania modelu. Zamiast przechowywać parametry z pełną precyzją (np. 16 bitów), zapisuje się je w mniejszej liczbie bitów (2, 4, 5, 8). Mówiąc obrazowo: model „zapomina” część dokładności wewnętrznych wag, żeby zmieścić się w mniejszej pamięci.

Najpopularniejsze poziomy:

• Q2 / Q3 – bardzo mocna kompresja, przydatna na bardzo słabym sprzęcie lub przy gigantycznych modelach, ale jakość odpowiedzi wyraźnie cierpi,
• Q4 – złoty środek na start: wyraźne zmniejszenie wymagań pamięci, a jakość często wciąż bardzo dobra,
• Q5 – kompromis w stronę jakości: trochę większy model, ale odpowiedzi bliższe wersji pełnokrwistej,
• Q8 – niemal pełna precyzja; świetna jakość, ale wymagania pamięciowe zbliżone do „oryginału”.

Jeśli dopiero poznajesz lokalne LLM i masz ograniczony RAM/VRAM, zacznij od wariantu Q4. Gdy widzisz, że model się mieści i działa szybko, możesz spróbować Q5, by poprawić jakość odpowiedzi, zwłaszcza w zadaniach wymagających precyzji (kod, matematyka).

Instalacja krok po kroku: przykładowe scenariusze na Windows, Linux i macOS

Windows + LM Studio: szybki start z interfejsem graficznym

Na Windowsie najprostszą drogą jest LM Studio. Typowy scenariusz wygląda tak:

1. Pobierz insta