Lokalne modele AI - jak uruchomić model językowy na własnym komputerze

Stan na 10 września 2026. Wersje modeli i ich wymagania sprawdzone tego dnia w kartach modeli producentów. Rynek otwartych modeli zmienia się co kilka tygodni, więc przed wdrożeniem sprawdźcie aktualne karty na Hugging Face.

Lokalne modele AI to modele językowe uruchamiane na własnym komputerze lub serwerze firmowym, bez wysyłania danych do zewnętrznego dostawcy. Rozwiązanie dla firm, które przetwarzają dane klientów, briefy kampanii albo dokumentację objętą tajemnicą handlową i nie chcą, żeby ta treść trafiała do cudzej infrastruktury.

Wdrożenie opiera się na dwóch narzędziach: Ollama (linia komend, serwer API na porcie 11434) albo LM Studio (interfejs graficzny z menedżerem modeli). Wybór modelu zależy od pamięci, jaką dysponujecie. Dzięki kwantyzacji model klasy 8B zmieścicie na karcie z 8 GB VRAM, a na 24 GB uruchomicie warianty, które w codziennej pracy redakcyjnej realnie zastępują asystenta chmurowego.

Poniżej instalacja krok po kroku na Windows, macOS i Linux, dobór modelu do sprzętu i podłączenie lokalnego API do automatyzacji.

Dlaczego biznes i marketing przechodzą na lokalne modele językowe

Uruchomienie modelu lokalnie zmienia model ryzyka, a nie tylko rachunek kosztów. Żaden fragment tekstu nie opuszcza infrastruktury firmy, więc znika konieczność zawierania umowy powierzenia przetwarzania danych z dostawcą AI i pytanie o to, gdzie fizycznie leżą serwery.

Decyzja o przejściu na model lokalny wynika zwykle z pięciu czynników. Poniższa tabela porządkuje je względem typowej subskrypcji chmurowej.

Ostatni wiersz jest naszym zdaniem najbardziej niedoceniany. Prompt dopracowany pod konkretny model przestaje działać po cichej aktualizacji po stronie dostawcy, a plik GGUF na dysku firmowym zachowuje się identycznie za rok i za trzy lata. Ma to znaczenie wszędzie tam, gdzie generowanie treści jest powtarzalnym procesem, a nie jednorazowym eksperymentem.

Fine-tuning jest drugą rzeczą, której chmura zwykle nie daje. Model można douczyć na wewnętrznej bazie wiedzy, tonie marki i terminologii branżowej, co przekłada się na jakość automatyzacji treści i na pozycjonowanie AI prowadzone na własnych danych.

Wymagania sprzętowe: modele gęste, MoE, Apple Silicon i CUDA

Zapotrzebowanie na pamięć wynika z prostego rachunku: liczba parametrów razy liczba bitów na parametr, plus narzut na cache uwagi. Model 8B skwantyzowany do 4 bitów to około 4,5 do 5 GB pliku, model 14B około 9 do 10 GB, model 35B około 20 GB. Do tego dochodzi pamięć na kontekst, która przy dużych oknach potrafi zdominować rachunek.

Praktyczne progi, którymi kierujemy się przy doborze sprzętu u nas i u klientów:

• 2B do 4B - około 8 GB RAM i grafika zintegrowana. Laptop biurowy, bez dedykowanej karty.
• 8B do 14B - 16 GB RAM i karta z 8 do 12 GB VRAM. Najczęstszy wybór w marketingu: generowanie treści, streszczenia, analiza dokumentów.
• 27B do 35B - 32 GB RAM i karta 16 do 24 GB. Próg, od którego model lokalny zaczyna wystarczać do codziennej pracy redakcyjnej.
• 100B i więcej - karta serwerowa 80 GB albo stacja z bardzo dużą pamięcią zunifikowaną.

Dlaczego architektura MoE zmieniła te widełki

Do niedawna liczba parametrów mówiła o wymaganiach wszystko. Dziś dominuje Mixture of Experts (MoE), gdzie przy generowaniu każdego tokenu aktywuje się tylko część sieci. Qwen3.6-35B-A3B ma 35 miliardów parametrów łącznie i 3 miliardy aktywne na token (karta modelu, Hugging Face). Llama 4 Scout ma 17 miliardów aktywnych ze 109 miliardów łącznie, a Maverick 17 miliardów z około 400 miliardów (The Llama 4 herd, Meta AI).

Konsekwencja jest dwuczłonowa i łatwo ją pomylić:

• Do pamięci muszą trafić wszystkie parametry. Model 35B w 4 bitach nadal zajmuje około 20 GB.
• O szybkości decyduje liczba parametrów aktywnych. Ten sam model generuje tokeny w tempie zbliżonym do modelu 3B.

MoE daje więc jakość dużego modelu przy szybkości małego, ale wymaga dużo pamięci. Jeśli macie 64 GB RAM i słabe GPU, model MoE będzie lepszym wyborem niż gęsty model tej samej wielkości. Przy karcie 8 GB i 16 GB RAM zostajecie przy modelach gęstych 8B do 14B.

Apple Silicon, CUDA i karty AMD

Apple Silicon korzysta z pamięci zunifikowanej, dzielonej między CPU, GPU i Neural Engine, więc nie ma tu podziału na RAM i VRAM. Mac z 16 GB obsłuży modele średnie, 32 GB otwiera drogę do klasy 27B do 35B. Przy dużych modelach MoE daje to Apple przewagę nad kartami konsumenckimi z 8 czy 12 GB VRAM.

Na Windows i Linux najlepiej wspieranym środowiskiem pozostaje CUDA od NVIDII. Użytkownicy AMD mają dwie drogi: ROCm, czyli oficjalny stos AMD, oraz Vulkan jako uniwersalny backend działający też na kartach Intel Arc i grafice zintegrowanej. Oba są wspierane przez llama.cpp, a przez to również przez Ollamę i LM Studio (llama.cpp, dokumentacja backendów). DirectML, wymieniany w starszych poradnikach, stracił znaczenie na rzecz tych dwóch.

Jak działa kwantyzacja i format GGUF

Czym jest kwantyzacja i jak dobrać rozmiar modelu

Kwantyzacja redukuje precyzję zapisu parametrów, najczęściej z 16 bitów (FP16 lub BF16) do 4, 5 lub 8 bitów. Zmniejsza to plik i zapotrzebowanie na pamięć, a przy poziomach Q4_K_M i Q5_K_M utrata jakości jest w zastosowaniach marketingowych trudna do zauważenia. Standardem zapisu jest GGUF, format zaprojektowany pod szybkie wczytywanie na sprzęcie konsumenckim, który zastąpił starszy GGML i stał się domyślnym nośnikiem modeli na Hugging Face.

Przy pobieraniu modelu spotkacie trzy warianty kwantyzacji.

1. Kwantyzacja klasyczna (Q4_K_M, Q5_K_M, Q6_K) Najpopularniejsza i uniwersalna, dostępna praktycznie dla każdego modelu w GGUF.
2. Kwantyzacja z macierzą ważności (imatrix, warianty IQ) Wykorzystuje statystykę rzeczywistych aktywacji, żeby chronić najważniejsze wagi. Przy tym samym rozmiarze pliku daje lepszą jakość niż klasyczne Q4, szczególnie przy kompresji do 3 bitów i niżej.
3. Kwantyzacja natywna (MXFP4) Część modeli jest publikowana od razu w 4 bitach. Tak jest z gpt-oss, gdzie wersja 20B mieści się w 16 GB pamięci, a 120B na pojedynczej karcie 80 GB (Introducing gpt-oss, OpenAI). Model nie był kompresowany po fakcie, więc nie ma tu typowej dla kwantyzacji utraty jakości.

Okno kontekstu dokłada się do rachunku i przy nowych modelach potrafi go zdominować. Qwen3.6 obsługuje natywnie 262 tysiące tokenów (karta modelu, Hugging Face), a Gemma 4 do 256 tysięcy (Gemma 4, blog Google). Wypełnione w całości okno tej wielkości zużywa na cache uwagi więcej pamięci niż same wagi. Zejście z kontekstu z 32 tysięcy do 8 tysięcy tokenów bywa jedynym sposobem, żeby zmieścić większy model bez schodzenia z kwantyzacją.

Jak działa offloading między CPU a GPU

Offloading rozdziela warstwy modelu między procesor i kartę, gdy VRAM nie wystarcza na całość. Część warstw liczy GPU, resztę CPU z użyciem RAM. Mechanizm obsługuje llama.cpp, silnik napędzający zarówno Ollamę, jak i LM Studio, więc zasady są takie same niezależnie od wybranego interfejsu.

Im więcej warstw działa na GPU, tym szybsza odpowiedź, bo obliczenia równoległe na karcie są szybsze od sekwencyjnych na procesorze. Przy pełnym offloadzie generowanie idzie bez przestojów, przy częściowym każda warstwa na CPU dokłada opóźnienie związane z przerzucaniem danych między pamięcią systemową a pamięcią karty.

Z naszej praktyki wynika jedna zasada: spadek z pełnego offloadu na częściowy jest gwałtowny, nie liniowy. Jeśli model mieści się w VRAM w dziewięćdziesięciu procentach, lepiej zejść o jeden poziom kwantyzacji albo zmniejszyć kontekst, niż zgodzić się na offload kilku warstw. Nieznacznie gorsza jakość tekstu boli mniej niż kilkukrotnie wolniejsze generowanie.

Ollama i LM Studio: instalacja krok po kroku

Instalacja Ollama na Windows, macOS i Linux

Ollama to darmowy framework działający z linii komend, dostępny na wszystkie trzy systemy, z opcjonalną aplikacją okienkową. Instaluje się natywnie, bez kontenera, i po instalacji wystawia lokalny serwer API pod adresem 127.0.0.1:11434 (dokumentacja Ollama).

• macOS - oficjalna aplikacja ze strony projektu, zawiera GUI i CLI. Samo CLI instaluje też Homebrew komendą brew install ollama.
• Linux - skrypt instalacyjny curl -fsSL https://ollama.com/install.sh | sh. Usługa startuje pod systemd, więc serwer API wstaje razem z systemem.
• Windows - instalator z interfejsem graficznym, po którym Ollama działa w tle i udostępnia to samo API co na pozostałych systemach.

Pobranie modelu:

ollama pull qwen3:8b

Uruchomienie go w terminalu:

ollama run qwen3:8b

Dwie komendy wystarczą, żeby mieć działający model bez żadnego interfejsu graficznego. Przydają się jeszcze ollama list (co jest pobrane i ile zajmuje), ollama ps (co jest załadowane do pamięci) oraz ollama rm (usunięcie modelu, który zajmuje kilkanaście gigabajtów).

LM Studio jako alternatywa graficzna

LM Studio to darmowa aplikacja desktopowa na macOS, Windows i Linux dla osób, które nie chcą pracować w terminalu. Działa na llama.cpp, a na Apple Silicon również na MLX, i udostępnia lokalny serwer API zgodny ze standardem OpenAI, domyślnie na porcie 1234 (dokumentacja LM Studio).

Wbudowany menedżer modeli sięga bezpośrednio do Hugging Face i obsługuje GGUF natywnie. Wyszukiwanie, pobieranie i przełączanie wersji kwantyzacji odbywa się z panelu, a interfejs sam sygnalizuje, które warianty zmieszczą się w pamięci danego komputera. To najszybszy znany nam sposób na dobranie kwantyzacji bez liczenia w głowie.

Open WebUI, Jan i vLLM

Open WebUI to nakładka webowa najczęściej łączona z API Ollamy. Daje interfejs czatu podobny do usług chmurowych, ale działający lokalnie: historię rozmów, obsługę dokumentów i przełączanie modeli. W firmach bywa uruchamiana jako usługa obok Ollamy, żeby kilka osób korzystało z jednego modelu przez adres w sieci wewnętrznej.

Przy takim wdrożeniu jest jedna rzecz, o której trzeba pamiętać: serwer API Ollamy nie ma własnego uwierzytelniania. Wystawienie go poza localhost bez reverse proxy z logowaniem oznacza, że korzystać z niego może każdy, kto ma dostęp do sieci.

Poza tą trójką warto znać trzy narzędzia. Jan to otwarta aplikacja desktopowa dla osób, które chcą pracować bez telemetrii. Bionic to nowszy klient desktopowy z własnym menedżerem modeli sięgającym do Hugging Face, z którego pochodzi zrzut listy wariantów kwantyzacji w sekcji o GGUF. vLLM to silnik serwerowy do wdrożeń firmowych, obsługujący wielu użytkowników równocześnie. Nie jest to narzędzie na laptopa, ale gdy model ma obsłużyć cały zespół, jest lepszym wyborem niż Ollama.

Najlepsze lokalne modele językowe do pracy po polsku

Do pracy po polsku bierzemy wersje Instruct, czyli dostrojone do prowadzenia rozmowy i wykonywania poleceń. Wersje bazowe wymagają dodatkowego dostrajania i do redagowania treści się nie nadają. Poniższy przegląd odzwierciedla stan na wrzesień 2026.

• Bielik 11B v3 - polski model rozwijany wspólnie przez projekt SpeakLeash i ACK Cyfronet AGH, trenowany na polskich korpusach tekstowych, rozwinięty z modelu Mistral-7B-v0.2 (karta modelu, Hugging Face). Istnieje osobny wariant Bielik-PL-11B-v3.0-Instruct z tokenizerem zoptymalizowanym pod polszczyznę (karta modelu) oraz mniejszy Bielik-Minitron-7B dla słabszego sprzętu. Radzi sobie z fleksją i rejestrem lepiej niż modele trenowane głównie na angielskim, co widać przy opisach produktowych i komunikacji biznesowej. Serwis aisight.pl podaje, że v3 zajął czwarte miejsce w rankingu EuroEval wśród wielojęzycznych modeli bazowych (aisight.pl); to relacja medialna, nie wynik potwierdzony przez nas samodzielnie.
• Qwen3 i Qwen3.6 - rodzina Alibaby, dziś domyślna odpowiedź na pytanie, co uruchomić lokalnie. Warianty Qwen3 8B i 14B pasują do typowego sprzętu, a Qwen3.6-35B-A3B na licencji Apache 2.0 obsługuje tekst, obraz i wideo przy 262 tysiącach tokenów kontekstu (karta modelu, Hugging Face). Polszczyzna przyzwoita, choć bardziej techniczna niż u Bielika.
• Gemma 4 - rodzina Google wydana 31 marca 2026 w wariantach E2B, E4B, 26B A4B i 31B, uzupełniona 3 czerwca 2026 o model 12B Unified (historia wydań, Google AI for Developers). Licencja Apache 2.0, kontekst do 256 tysięcy tokenów, ponad 140 języków, obsługa obrazu we wszystkich wariantach i dźwięku w E2B, E4B oraz 12B (Gemma 4, blog Google). Warianty E2B i E4B to naszym zdaniem najlepszy dziś wybór na komputer bez dedykowanej karty.
• gpt-oss 20B i 120B - otwarte wagi OpenAI na licencji Apache 2.0, publikowane natywnie w MXFP4. Wersja 20B mieści się w 16 GB pamięci, 120B na karcie 80 GB (Introducing gpt-oss, OpenAI). Modele z rozumowaniem krokowym, mocne w analizie, stylistycznie po polsku słabsze od Bielika.
• Llama 4 - rodzina Mety w architekturze MoE, natywnie multimodalna: Scout (17B aktywnych, 109B łącznie, 16 ekspertów) i Maverick (17B aktywnych, około 400B łącznie, 128 ekspertów) (The Llama 4 herd, Meta AI). Wbrew intuicji nie jest to model na mocniejszą kartę konsumencką, tylko na stację roboczą, bo nawet Scout w 4 bitach potrzebuje kilkudziesięciu gigabajtów. Starsze Llama 3 i 3.3 nadal działają, ale na nowy projekt ich nie wybieramy.
• Mistral - francuska rodzina ceniona za jakość przy niewielkiej liczbie parametrów i za swobodne licencje. W polskim contencie bywa alternatywą dla Bielika, o innym profilu stylistycznym.
• DeepSeek R1 i modele rozumujące - osobna kategoria, w której model przed odpowiedzią generuje jawny łańcuch rozumowania. Kosztuje to znacznie więcej tokenów i czasu, więc do opisów produktowych jest przerostem formy. Sprawdza się przy analizie danych i wnioskowaniu wieloetapowym.

Rekomendacja na start zależy wyłącznie od pamięci. Laptop bez dedykowanej karty: Gemma 4 E4B albo Bielik-Minitron-7B. Karta 8 do 12 GB: Qwen3 8B i Bielik 11B, porównane na własnych tekstach. Karta 24 GB albo Mac z 32 GB: Qwen3.6-35B-A3B lub gpt-oss 20B.

Bielik kontra Gemma: to samo polecenie, dwie odpowiedzi

Poniżej wynik testu z 10 września 2026, przeprowadzonego na laptopie z 16 GB RAM i grafiką zintegrowaną, bez dedykowanej karty. Oba modele szły przez Ollamę, dostały identyczne polecenie i pracowały na ustawieniach domyślnych, więc jest to porównanie stylu, nie pomiar wydajności.

Polecenie:

Napisz opis produktu na 300 znaków: bezprzewodowe słuchawki douszne z redukcją szumów, dla osób pracujących w open space.

Bielik 11B v3.0 Instruct, Q4_K_M

Bezprzewodowe słuchawki douszne z zaawansowaną redukcją szumów idealne dla osób pracujących w otwartych przestrzeniach biurowych. Zapewniają czysty dźwięk i wygodę użytkowania przez cały dzień. Lekkie, ergonomiczne i łatwe w obsłudze. Długi czas pracy na baterii i szybkie ładowanie. Idealne do pracy, muzyki i rozmów. Odporność na pot i wodę (IPX4). Doskonałe rozwiązanie dla profesjonalistów ceniących ciszę i koncentrację.

Gemma 3 4B

Zanurz się w ciszy! Bezpłciowe douszki z redukcją szumów to idealne rozwiązanie dla pracy w open space. Ciesz się czystym dźwiękiem i komfortem dzięki intuicyjnemu sterowaniu i długiemu czasowi pracy na baterii. Skup się na tym, co ważne! 🎧 #słuchawki #redukcjeszumów #open space

Różnicę widać w pierwszym słowie opisu. Gemma napisała „Bezpłciowe douszki" zamiast „Bezprzewodowe": podmieniła wyraz na inny, podobnie zaczynający się, ale znaczący coś zupełnie innego, i zrobiła to w miejscu, którego nie da się przeoczyć. To nie jest niezgrabny szyk ani kalka z angielskiego, tylko pomyłka na poziomie słowa.

Powtórzyliśmy to polecenie dwa razy i za każdym razem wyszło to samo słowo, mimo że reszta opisu była za drugim razem inna. To nie jest więc jednorazowa wpadka, tylko powtarzalne zachowanie modelu na tym prompcie. Bielik w obu podejściach napisał „Bezprzewodowe" i to jest dokładnie ta przewaga, którą daje trening na polskim korpusie.

Bielik przetłumaczył też „open space" na „otwarte przestrzenie biurowe", zamiast zostawić zapożyczenie. W tekście reklamowym bywa to dyskusyjne, bo branża mówi „open space", ale świadczy o tym, że model pracuje na polskiej semantyce, a nie przepisuje angielskich klocków.

Każdy z modeli zawiódł jednak inaczej, więc żadnego nie da się polecić bez zastrzeżeń.

Gemma zmieściła się w limicie, ale dołożyła rzeczy, o które nikt nie prosił. 275 znaków, licząc nagłówek, opis i hashtagi bez emoji, czyli polecenie wykonane. Do tego jednak nagłówek, emoji i hashtagi, o których w prompcie nie było mowy, a dwa z tych hashtagów są zepsute: „#redukcjeszumów" to sklejka bez odmiany, a „#open space" ze spacją w środku przestaje być hashtagiem w jakimkolwiek serwisie.

Bielik napisał lepszą polszczyznę, ale zignorował limit i zmyślił parametr. 425 znaków zamiast 300, czyli przekroczenie o 125. Gorsze jest to, że dopisał „Odporność na pot i wodę (IPX4)", a o normie IPX4 nie było ani słowa w poleceniu. Model wymyślił parametr techniczny i podał go z pełnym przekonaniem. W opisie produktu w sklepie jest to błąd kosztowniejszy niż literówka, bo dotyczy cechy, za którą klient płaci.

Wniosek dla marketingu jest z tego prosty. Model lokalny nadaje się do szkicu, nie do publikacji bez czytania. Mniejszy model myli słowa, większy zmyśla dane i lekceważy ograniczenia formalne, a jedno i drugie wychodzi dopiero przy uważnej lekturze. Jeśli generowanie opisów ma być procesem, to weryfikacja parametrów technicznych musi być jego częścią, niezależnie od tego, jak dobrze model pisze po polsku.

Czy lokalny model działa bez filtrów treści

Krąży przekonanie, że uruchomienie modelu lokalnie znosi wszelkie ograniczenia. To nieporozumienie i lepiej rozbroić je przed decyzją zakupową. Lokalnie znikają trzy rzeczy: limity zapytań, moderacja po stronie API i logowanie treści u dostawcy. Nie znika alignment wtrenowany w same wagi. Modele Instruct, w tym Bielik, Qwen, Gemma i Llama, odmówią offline dokładnie tego samego co przez API, bo skłonność do odmowy jest częścią wytrenowanych parametrów, a nie zewnętrznym filtrem.

Realna przewaga jest inna i wystarczająco mocna: żadna treść nie trafia do cudzej moderacji ani do cudzych logów. Analiza konkurencji, brief kampanii i dane klienta zostają na waszym sprzęcie. To argument o prywatności, nie o braku ograniczeń.

Integracja lokalnego API z narzędziami automatyzacji

Ollama i LM Studio wystawiają API zgodne ze standardem OpenAI, więc scenariusz zbudowany pod chmurowe API wystarczy przekierować na adres lokalny. Zmieniacie endpoint i podajecie dowolną wartość jako klucz, bo lokalny serwer nie wymaga uwierzytelniania w chmurze.

Adresy trzeba rozróżnić, bo to najczęstsze źródło błędów przy pierwszej integracji:

• Zgodny z OpenAI (Ollama): http://127.0.0.1:11434/v1/chat/completions
• Natywny Ollamy: http://127.0.0.1:11434/api/chat - inna struktura żądania i odpowiedzi, nie zadziała jako podmianka pod integrację napisaną pod OpenAI
• LM Studio: http://127.0.0.1:1234/v1/chat/completions

Dostępne są też /v1/embeddings do wyszukiwania semantycznego oraz /v1/models do sprawdzenia, czy serwer w ogóle odpowiada.

Make, Zapier i problem localhost

Make i Zapier działają w chmurze i nie mają dostępu do waszego localhost. Dotyczy to obu platform tak samo. Żeby podłączyć do nich model lokalny, trzeba udostępnić port przez tunel: Cloudflare Tunnel albo ngrok. W Make robi to moduł HTTP, w Zapierze akcja Webhooks by Zapier, a żądanie kierujecie na publiczny adres tunelu, nie na 127.0.0.1.

Jeśli nic nie ma wychodzić na zewnątrz, alternatywą jest n8n uruchomiony na własnym serwerze. Działa w tej samej sieci co model i odwołuje się do niego bezpośrednio, bez tunelu i bez publicznego adresu. Przy danych wrażliwych to zdecydowanie bezpieczniejszy układ i to jego używamy u siebie.

MCP, czyli podłączanie modelu do narzędzi

Model Context Protocol (MCP) to standard opisujący, jak model korzysta z zewnętrznych narzędzi: baz danych, plików, API. W praktyce lokalny model nie tylko generuje tekst, ale sięga po dane i wykonuje działanie. Wsparcie po stronie narzędzi lokalnych jest już dojrzałe, MCP obsługuje między innymi LM Studio, a po stronie modeli tool calling mają Qwen3, Gemma 4, gpt-oss i nowsze Llamy.

Dla marketingu jest to zmiana jakościowa wobec klasycznych automatyzacji. Zamiast budować scenariusz krok po kroku, podłączacie modelowi arkusz z danymi produktowymi i bazę z wytycznymi redakcyjnymi, a on sam sięga po to, czego potrzebuje. Zastosowania zostają te same: opisy produktowe po dodaniu wiersza w arkuszu, warianty reklam z briefu, klasyfikacja leadów. Różnica polega na tym, że dzieje się to bez opłat za tokeny i bez wysyłania danych klienta na zewnątrz.

Analiza dokumentów firmowych i dostrajanie modeli

Analiza umów, procedur i raportów wymaga architektury, w której żaden fragment nie opuszcza organizacji. RAG i fine-tuning to dwie uzupełniające się metody, obie wykonalne lokalnie.

Jak połączyć lokalny model z własnymi dokumentami

RAG podaje modelowi przed wygenerowaniem odpowiedzi te fragmenty dokumentów, które są najbliższe treściowo pytaniu, wyszukane w lokalnej bazie wektorowej. Implementację upraszcza AnythingLLM: import plików (PDF, DOCX, CSV, strony webowe), podział na fragmenty, generowanie embeddingów i zapis w bazie. Podobne możliwości ma dziś Open WebUI, więc przy działającej instalacji nie trzeba dokładać kolejnego narzędzia.

AnythingLLM łączy się bezpośrednio z API Ollamy albo LM Studio na localhost, więc cały łańcuch, od indeksowania po generowanie, zostaje na jednej maszynie. Odpowiedzi opierają się wtedy na faktycznej treści dokumentów, a nie na ogólnej wiedzy modelu.

Uwaga z wdrożeń: jakość RAG zależy bardziej od modelu embeddingów i sposobu dzielenia dokumentów niż od wielkości modelu czatu. Zanim sięgniecie po większy model, sprawdźcie, czy dokumenty nie są cięte w przypadkowych miejscach.

Dostrajanie modeli na danych firmowych

Fine-tuning trwale zmienia wagi na podstawie zbioru przykładów. W odróżnieniu od RAG, który podaje kontekst przy każdym zapytaniu, fine-tuning zapisuje styl, terminologię i ton głosu bezpośrednio w parametrach. Potrzebny jest zbiór par pytanie i odpowiedź albo instrukcja i wynik, zbudowany z rzeczywistych materiałów firmy.

Robi się to techniką LoRA albo oszczędniejszą pamięciowo QLoRA, trenującą na modelu skwantyzowanym. Modyfikuje się wtedy niewielką część parametrów, co obniża próg sprzętowy względem pełnego przetrenowania, a narzędzia takie jak Unsloth czy Axolotl sprowadzają proces do przygotowania danych i uruchomienia skryptu.

Wybór między jednym a drugim sprowadza się do prostego rozróżnienia. RAG odpowiada na pytanie, co model ma wiedzieć. Fine-tuning na pytanie, jak model ma mówić. Fakty zmieniające się co tydzień trzymajcie w bazie wektorowej, ton głosu marki i stałą terminologię zapiszcie w wagach.

Cały proces, od danych przez trening po wdrożenie w Ollamie lub LM Studio, przebiega lokalnie. Dla firm przetwarzających dane osobowe albo informacje objęte tajemnicą handlową jest to jedyny sposób na połączenie jakości dużego modelu z pełną kontrolą nad przepływem danych.

Najczęstsze pytania o lokalne modele AI

1. Czy uruchomienie lokalnego modelu wymaga stałego połączenia z internetem?

Nie. Internet jest potrzebny wyłącznie do pobrania modelu komendą ollama pull albo przez menedżer w LM Studio. Sama inferencja działa w pełni offline i to jedna z głównych zalet tego rozwiązania.

2. Jakie są minimalne wymagania sprzętowe do pracy z tekstem?

Do sensownej pracy z polskim tekstem wystarczy 16 GB RAM i karta z 8 GB VRAM przy modelu 8B w 4 bitach. Bez dedykowanej karty użyteczne są modele 2B do 4B, na przykład Gemma 4 E4B, które działają na grafice zintegrowanej i 8 GB RAM.

3. Ollama czy LM Studio na start?

LM Studio, jeśli nie pracujecie w terminalu i chcecie widzieć, który wariant kwantyzacji zmieści się na waszym sprzęcie. Ollama, jeśli planujecie integracje ze skryptami albo automatyzacjami, bo wystawia API bez dodatkowej konfiguracji i łatwiej uruchomić ją jako usługę. Oba narzędzia korzystają z silnika llama.cpp, więc jakość odpowiedzi będzie taka sama.

4. Który model jest najlepszy do pisania po polsku?

Bielik 11B v3, bo był trenowany na polskich korpusach, a w wariancie Bielik-PL ma tokenizer zoptymalizowany pod polszczyznę. Jako drugi model warto trzymać Qwen3 8B lub 14B, lepszy w zadaniach analitycznych i strukturyzowaniu danych, choć jego polszczyzna jest bardziej techniczna.

5. Czy lokalny model dorównuje jakością ChatGPT?

Do generowania treści, streszczeń, klasyfikacji i analizy dokumentów modele klasy 27B do 35B w zupełności wystarczają. Przy najtrudniejszych zadaniach rozumowania i pracy z bardzo długim kontekstem najlepsze modele chmurowe pozostają mocniejsze.

6. Czy mogę używać lokalnego modelu komercyjnie?

Zależy od licencji modelu, nie od narzędzia, którym go uruchamiacie. Qwen3.6 i gpt-oss są na Apache 2.0, która pozwala na użycie komercyjne. Llama ma własną licencję z warunkami dotyczącymi bardzo dużej skali. Przed wdrożeniem produkcyjnym sprawdźcie licencję na karcie modelu na Hugging Face.

7. Czy architektura MoE oznacza, że model 35B zmieści się na słabszym sprzęcie?

Nie. Do pamięci muszą trafić wszystkie parametry, więc model 35B w 4 bitach nadal zajmuje około 20 GB. MoE poprawia szybkość generowania, bo aktywuje tylko część sieci na token, ale nie zmniejsza zapotrzebowania na pamięć.

8. Czy dane wpisywane do lokalnego modelu są gdziekolwiek zapisywane?

Historia rozmów zapisuje się lokalnie w wybranej aplikacji i można ją usunąć. Model nie uczy się z waszych zapytań i nie wysyła ich dalej. Wyjątkiem jest sytuacja, w której serwer API zostanie świadomie udostępniony poza localhost bez zabezpieczenia, dlatego przy pracy zespołowej używajcie reverse proxy z uwierzytelnianiem.

9. Co zrobić, gdy model odpowiada bardzo wolno?

Najczęstszą przyczyną jest częściowy offloading, czyli sytuacja, w której model nie mieści się w VRAM i część warstw liczy procesor. Zmniejszcie okno kontekstu, zejdźcie o poziom kwantyzacji niżej albo wybierzcie mniejszy model. Lepiej uruchomić mniejszy model w całości na GPU niż większy w połowie.