Mamy AI w domu

Cześć,

dziś chciałbym ciebie zaprosić na niesamowitą wyprawę w dążeniu do niezależności i wolności od technologicznych gigantów w aspekcie używania dużych modeli językowych, czyli LLMów.

Cel jest jeszcze bardzo odległy. Aktualny stan rzeczy pozostawia dużo do życzenia, szczególnie jeśli porównujemy lokalne modele do tego, co dostajemy w zamkniętych usługach od dużych firm. Mimo to już dziś możemy korzystać z tej, mimo wszystko, niesamowitej technologii w pełni prywatnie, lokalnie i w domowym zaciszu.

Ten wpis powstał na podstawie prezentacji pokazanej na Poznańskiej Imprezie Wolnego Oprogramowania PIWO, na której miałem przyjemność wystąpić już drugi raz.

Slajdy z prezentacji są dostępne tutaj: mamy-ai-w-domu.pdf.

Dlaczego mnie to interesuje?

Lokalne modele językowe nie są dla mnie tylko zabawką. W pracy inżynierskiej zajmowałem się tematem:

Wykorzystanie chatbota z technologią RAG do wspomagania pracy serwisantów w aplikacji iService.

W praktyce oznaczało to zabawę z takimi elementami jak RAG, lokalny LLM, Mistral 7B, karta NVIDIA Tesla P100 16 GB oraz sentence transformers.

Demo: ollama + opencode

Na początku prezentacji pokazywałem demo, żeby od razu ustawić cel. Nie chodziło o opowiadanie o abstrakcyjnym AI, tylko o dojście do momentu, w którym lokalny model faktycznie działa i da się go użyć w realnym narzędziu.

Kod tego przykładu jest w repozytorium homelab-ai-demo, w katalogu ./opencode-ollama. Najważniejszy plik do odtworzenia środowiska to flake.nix.

Scenariusz wyglądał mniej więcej tak:

• pobieram flake.nix, bo nie byłby to mój blog gdyby nie padło chociaż raz nix
• uruchamiam środowisko z Ollamą i OpenCode
• wybieram model
• pobieram go lokalnie
• odpalam OpenCode połączony z Ollamą
• mam gotowe środowisko do zabawy z LLMami

Ten nix flake jest w pełni opcjonalny. On tylko spina środowisko tak, żebym nie musiał ręcznie tłumaczyć każdej instalacji. Sedno jest prostsze: lokalny runtime modelu plus narzędzie, które potrafi do niego gadać.

Po przeczytaniu tego wpisu chciałbym, żebyś wiedział czego potrzebujesz, żeby odtworzyć taki setup u siebie i jakie alternatywy będą lepsze w twoim przypadku.

LLM != AI

Zanim zaczniemy, warto rozwiać pewną nieścisłość z tytułu. Będziemy tu mówić głównie o LLMach, które są dużo węższym pojęciem niż mistyczne "AI".

AI w domu mogłoby oznaczać wiele rzeczy:

• lokalne TTS, czyli Text to Speech, do czytania maili
• kamerę na podwórku, która wysyła powiadomienie po wykryciu nierozpoznanej twarzy
• system sterowania światłem za pomocą głosu
• lokalny system klasyfikacji dokumentów
• automatyzacje w Home Assistant

Dziś zawężamy mocno ten obszar do przetwarzania i generowania tekstu, a w szczególności kodu. Dlatego skupiamy się na dużych modelach językowych i ich inferencji.

Inferencja to proces wykorzystywania wytrenowanego modelu do analizy nowych danych i generowania odpowiedzi.

LLM to tylko kawałek większej układanki. Mamy AI, w nim ML, w nim modele językowe, a obok tego całe morze pojęć: sieci neuronowe, transformery, attention mechanism, embeddings, RAG, fine-tuning, RLHF, alignment problem, przestrzenie latentne i inne tematy, które bardzo szybko robią z prostego wpisu książkę.

Dlatego tu trzymamy się praktycznego pytania: jak odpalić model językowy lokalnie i co da się z tym sensownie zrobić?

Open weight != open source

Mimo że często będę używał skrótu "open-source model", rzeczywistość jest trochę bardziej szara.

Większość wiadomości w stylu "firma X opublikowała model Y na licencji open source" w praktyce oznacza tylko tyle, że opublikowano końcowe wagi modelu. Najczęściej nie dostajemy pełnych danych treningowych, dokładnego procesu obróbki danych, pełnego przepisu na trening, informacji o filtrach bezpieczeństwa ani realnej możliwości odtworzenia modelu od zera.

Warto rozróżniać trzy światy:

Są projekty, które próbują iść dalej. Dobrym przykładem jest PrimeIntellect/INTELLECT-1, gdzie pojawia się temat rozproszonego treningu dużych modeli. Jest też Open-R1, czyli próba odtworzenia elementów pipeline'u modeli reasoningowych w bardziej otwarty sposób.

I choć przechodzi mi to z bólem, modele naprawdę otwarte nadal często przegrywają możliwościami z tym, co dostajemy w "prezencie" od dużych firm. Ale możliwość uruchomienia modelu lokalnie, bez wysyłania wszystkiego na cudze serwery, nadal jest ogromną wartością.

Hardware

Do uruchomienia modelu w teorii wystarczy CPU i odpowiednia ilość pamięci RAM. W praktyce modele typu transformer są bardzo dobrze przystosowane do przetwarzania równoległego, co swoją drogą umożliwiło ich ogromny rozwój w ostatnich latach. Dlatego w domu najczęściej będziemy patrzeć w stronę kart graficznych.

Masz trzy główne warianty:

• GPU z własnym VRAM
• CPU plus unified memory, na przykład Apple Silicon
• CPU plus RAM

Najważniejsze parametry sprzętu to:

Jeśli patrzysz na karty graficzne, to VRAM jest pierwszym filtrem. W prezentacji przykładem była AMD RX 7900 XT 20 GB za około 3100 zł. To nie jest rekomendacja zakupowa dla każdego, tylko przykład sprzętu z sensowną ilością VRAM w domowym budżecie entuzjasty.

Orientacyjnie wygląda to tak:

To są wartości orientacyjne. Realne wymagania zależą od formatu modelu, kwantyzacji, długości kontekstu, runtime'u i tego, ile KV cache będzie potrzebne podczas generowania.

Do zabawy wystarczy 8-12 GB VRAM. Do sensownego lokalnego AI celowałbym w 12-24 GB. Do większych open-weight modeli przydaje się 24-48 GB. Powyżej tego zaczynamy mówić o zabawie bez większych kompromisów albo o sprzęcie, który trudno nazwać zwykłym domowym setupem.

Jak wybrać swój pierwszy model?

Najlepiej zacząć od Hugging Face, czyli takiego GitHuba dla modeli AI. Znajdziesz tam modele tekstowe, multimodalne, embeddingowe, audio, vision, diffusion i wiele innych. Nie tylko LLMy.

Problem polega na tym, że na Hugging Face trzeba wiedzieć czego się szuka. Nazwy modeli bywają krypticzne. Zawierają skróty architektur, rozmiary, warianty instrukcyjne, formaty plików, typy kwantyzacji i informacje o przeznaczeniu modelu.

Przykładowo nazwa Qwen3-14B-Instruct-GGUF-Q4_K_M mówi nam jednocześnie o rodzinie modelu, liczbie parametrów, sposobie dostrojenia, formacie pliku i poziomie kwantyzacji.

W praktyce warto nauczyć się czytać te nazwy jak etykiety techniczne.

Kwantyzacja to technika zmniejszania zużycia pamięci i kosztu obliczeniowego przez zapis wag modelu w niższej precyzji, na przykład 8-bitowej lub 4-bitowej. Dzięki temu można uruchamiać większe modele na słabszym sprzęcie, często z relatywnie niewielką utratą jakości.

Same skróty nie wystarczą. Przy wyborze modelu warto sprawdzić też kartę modelu, licencję, długość kontekstu, wymagania sprzętowe, format plików, benchmarki oraz to, czy model jest bazowy, instrukcyjny, czatowy, reasoningowy czy multimodalny.

llmfit i llm-checker

Jeśli nie chcesz zgadywać, czy model zmieści się na twoim sprzęcie, są narzędzia, które pomagają zrobić pierwszy filtr.

llmfit potrafi wykryć dostępny hardware i przygotować listę modeli, które powinny pasować do maszyny. Jego największą zaletą jest to, że sprowadza pierwszą selekcję do jednej komendy.

llm-checker idzie w podobnym kierunku, ale jest mocniej zintegrowany z Ollamą i wyborem modeli pod lokalny runtime.

To nie zwalnia z myślenia, ale bardzo pomaga na starcie. Zamiast zaczynać od pytania "co teraz?", zaczynasz od listy modeli, które mają jakiekolwiek szanse działać u ciebie.

Domowa destylacja i Open-R1

Jeśli masz minimum 24 GB VRAM, zaczynają się ciekawsze eksperymenty. Nie tylko uruchamianie modeli, ale też praca wokół nich.

W kontekście Open-R1 można bawić się w:

• destylację z większego modelu do mniejszego
• generowanie małych datasetów syntetycznych
• benchmarki małych modeli reasoningowych
• sprawdzanie jak daleko da się zejść z rozmiarem modelu, zanim przestanie być użyteczny

To nadal nie jest "trenuję sobie GPT w piwnicy", ale jest to już realna praca z lokalnym ekosystemem modeli.

Jak uruchomić swój pierwszy model?

Załóżmy, że znaleźliśmy już idealny model. Teraz trzeba go odpalić.

Tu sytuacja z open-source ma się znacznie lepiej niż w przypadku samych modeli. Istnieje wiele dobrych narzędzi do inferencji LLMów.

Ollama

Jeśli to twój pierwszy model, zacząłbym od Ollamy.

Ollama jest najbardziej "plug and play" rozwiązaniem w tym zestawieniu. Potrafi pobrać model, uruchomić go lokalnie i wystawić proste API. Na stronie Ollamy znajdziesz też bibliotekę dostępnych modeli razem z wariantami i informacjami potrzebnymi do szybkiego rozpoczęcia pracy.

Typowy start wygląda tak:

ollama run gemma3:4b

Oczywiście za wygodą idzie koszt. Ollama ukrywa wiele szczegółów i ma dodatkowy narzut związany z zarządzaniem modelem oraz pamięcią. Na początku to zaleta, bo nie musisz wiedzieć wszystkiego. Później może to zacząć przeszkadzać.

llama.cpp

Kiedy Ollama zaczyna ograniczać, naturalnym kolejnym krokiem jest llama.cpp.

To bardzo popularne narzędzie, szczególnie dla modeli w formacie GGUF. Działa na CPU, potrafi korzystać z ograniczonej ilości VRAM, wspiera różne GPU i ma serwer HTTP kompatybilny z API OpenAI.

Przykładowe pobranie modelu z Hugging Face:

llama-cli -hf ggml-org/gemma-3-1b-it-GGUF

llama.cpp jest dobrym wyborem, kiedy masz model z Hugging Face i chcesz sam dobrać parametry uruchomienia.

Przykład takiego serwera jest w ./llmfit-llama-server, a środowisko Nix opisuje jego flake.nix.

vLLM

vLLM jest częściej wybierany do wydajnego serwowania modeli na GPU. Projektowany jest z myślą o wysokiej przepustowości, wielu użytkownikach i produkcyjnych zastosowaniach.

Też wystawia serwer HTTP kompatybilny z API OpenAI. Obsługuje między innymi NVIDIA GPU, AMD GPU, Intel XPU, Apple Silicon i CPU.

Jeśli chcesz wystawić model przez API dla aplikacji lub wielu użytkowników, vLLM zaczyna mieć więcej sensu niż Ollama.

W repozytorium zostawiłem też wariant Hugging Face plus vLLM: ./vllm-hf-server. Powiązany flake.nix pokazuje zależności potrzebne do uruchomienia serwera.

SGLang

SGLang idzie w podobnym kierunku co vLLM, ale jest bardziej frameworkiem do szybkiego serwowania dużych modeli językowych i multimodalnych oraz bardziej złożonych pipeline'ów.

Również wystawia serwer HTTP kompatybilny z API OpenAI. Wspiera sporo backendów: AMD GPUs, Apple Metal, Intel Xeon CPUs, Google TPU, NVIDIA DGX Spark, NVIDIA Jetson, Ascend NPUs i Intel XPU.

To raczej nie jest narzędzie na pierwszy wieczór, ale warto wiedzieć, że istnieje.

Open WebUI

Jeśli chcesz mieć lokalny interfejs bardziej podobny do ChatGPT, warto sprawdzić Open WebUI.

To self-hosted aplikacja webowa, którą można połączyć z wcześniej wymienionymi runtime'ami. Dzięki temu lokalny model przestaje być tylko procesem w terminalu, a zaczyna być narzędziem dostępnym przez przeglądarkę.

Podsumowanie narzędzi

Co można z tym zrobić?

Załóżmy, że mamy lokalnie uruchomiony model w stylu Gemma 3 27B IT albo podobny model, który faktycznie mieści się na naszym sprzęcie i odpowiada w akceptowalnym czasie.

Co można z tym zrobić sensownie?

• lokalne RAG po własnych notatkach i dokumentach
• lokalny asystent do dokumentacji technicznej
• lokalny generator testów i checklist
• lokalny coding assistant w OpenCode
• prompt builder do większych modeli
• prywatny parser i streszczacz dokumentów
• mały asystent do homelabu
• lokalna wiki z wyszukiwaniem semantycznym

To są zastosowania, w których prywatność i lokalność faktycznie mają znaczenie. Notatki, dokumentacja firmowa, kod, prywatne logi, konfiguracje homelabu i inne dane, których niekoniecznie chcemy wrzucać do cudzej usługi.

Czego bym unikał?

Lokalny LLM nie jest magicznym pracownikiem zamkniętym w komputerze. Szczególnie mały model.

Unikałbym powierzania mu:

• dużych zmian kodu bez bardzo dokładnej kontroli
• security audytu
• działania jako samodzielny agent bez nadzoru
• decyzji, za które potem odpowiedzialny będzie człowiek
• zadań, których wyniku nie umiesz szybko sprawdzić

Małe modele najlepiej działają, gdy dostają małe, konkretne i sprawdzalne zadania.

Najlepszy pattern to dzielenie pracy na kroki. Nawet zwykły plan.md potrafi bardzo pomóc. Zamiast prosić model o "zrób mi feature", lepiej rozpisać mu mały fragment pracy, oczekiwany wynik i sposób weryfikacji.

Słodko gorzka prawda

Podsumowując to wszystko, jeszcze minie sporo czasu zanim będziemy mogli cieszyć się poziomem najlepszych zamkniętych modeli w domowym zaciszu. Możliwe, że w pewnych aspektach nigdy to nie nastąpi, biorąc pod uwagę trendy cen sprzętu, koszt treningu i przewagę firm posiadających gigantyczną infrastrukturę.

Nie znaczy to, że lokalne LLM-y są bez sensu.

Światło w tunelu jest. Aktualne możliwości lokalnych modeli, choć nie rozpieszczają, działają i pozwalają zrobić ciekawe rzeczy. Co ważniejsze, bardzo dużo ludzi chce uruchamiać LLMy lokalnie za wszelką cenę. To środowisko będzie się rozwijać.

Małe modele stają się coraz lepsze. Co chwilę wychodzą nowe warianty, nowe kwantyzacje, nowe runtime'y i nowe sztuczki optymalizacyjne. Benchmarki czasem nie nadążają, a modele, które jeszcze niedawno były ciekawostką, dziś da się realnie wykorzystać do małych zadań.

Tylko trzeba pamiętać, że "mamy AI w domu" nie oznacza "mamy GPT-4 w piwnicy". Bardziej: mamy prywatne, lokalne narzędzie, które dobrze użyte potrafi być bardzo przydatne.

Polecany stack

Gdybym miał to złożyć od zera, zacząłbym tak:

Na start: Ollama plus OpenCode albo Open WebUI.

Kiedy chcesz więcej kontroli: llama.cpp.

Kiedy chcesz wystawiać model jako usługę: vLLM albo SGLang.

Linki

• Hugging Face
• Ollama
• OpenCode
• Pi Agent
• llmfit
• llm-checker
• llama.cpp
• vLLM
• SGLang
• Open WebUI
• Open-R1
• PrimeIntellect/INTELLECT-1
• Llama 3.1 na blogu Hugging Face
• Biblioteka modeli Ollama
• Ollama VRAM requirements for local LLMs
• homelab-ai-demo