TL;DR

Local AI to uruchamianie LLM-ów i infrastruktury w pełni na własnym sprzęcie – bez zewnętrznych API
Prywatność i bezpieczeństwo są kluczowe dla firm w regulowanych branżach jak healthcare czy finanse
Wymagania sprzętowe zależą od rozmiaru modelu – od 4GB VRAM dla 7B parametrów do 35-40GB dla 70B
Local AI Package to gotowe rozwiązanie Docker z Ollama, Supabase, N8N i Open Web UI
OpenAI API compatibility pozwala łatwo migrować istniejące agenty na local AI
Deployment w chmurze możliwy na prywatnych serwerach z pełną kontrolą nad danymi
Quantization (Q4) zmniejsza rozmiar modeli bez znaczącej utraty jakości

Czym jest Local AI i dlaczego warto się tym zainteresować

Local AI oznacza uruchamianie własnych dużych modeli językowych oraz całej infrastruktury w pełni na własnej maszynie, w 100% offline. W przeciwieństwie do tradycyjnego podejścia, gdzie płacimy za API OpenAI czy Claude, tutaj wszystko działa na naszym sprzęcie.

Cole Medin podkreśla, że prywatność i bezpieczeństwo to główna zaleta local AI. Dane nigdy nie opuszczają naszego sprzętu i pozostają pod pełną kontrolą. Szczególnie istotne jest to dla firm w wysoko regulowanych branżach.

„Nie masz pojęcia, ile firm rozmawiałem, które są gotowe włożyć dziesiątki tysięcy dolarów w uruchamianie własnych LLM-ów i infrastruktury, ponieważ prywatność i bezpieczeństwo jest tak kluczowe dla rzeczy, które budują z AI” – zauważa autor.

Dodatkowe korzyści obejmują możliwość fine-tuningu modeli z własnymi danymi oraz potencjalne oszczędności kosztów. Zamiast płacić za każde wywołanie API, ponosimy tylko koszty energii elektrycznej.

Czy local AI ma sens w porównaniu z cloud AI

Autor prezentacji szczerze omawia wady i zalety obu podejść. Cloud AI wygrywa pod względem łatwości konfiguracji oraz dostępu do najlepszych modeli jak Claude 4 czy GPT-4. Aktualnie najlepsze modele cloud są mocniejsze od lokalnych odpowiedników.

Jednak gap się zmniejsza. Autor przewiduje przyszłość, w której lokalne modele dorównają jakością tym w chmurze, podczas gdy zalety cloud AI stopniowo znikną dzięki lepszym narzędziom i instrukcjom dla local AI.

Local AI ma sens już teraz, gdy:

Pracujesz z wrażliwymi danymi
Potrzebujesz pełnej kontroli nad infrastrukturą
Chcesz uniknąć zależności od zewnętrznych dostawców
Masz wymagania dotyczące prywatności

Wymagania sprzętowe – ile mocy potrzebujesz

Modele językowe to miliardy parametrów (liczb) połączonych w sieć. GPT-4 ma szacunkowo 1,4 biliona parametrów. Dlatego aby zmieścić cały model w karcie graficznej, potrzebujemy odpowiedniej ilości VRAM.

Rozmiary modeli i wymagania VRAM

7-8 miliardów parametrów:
- Potrzeba: 4-5 GB VRAM (przy kwantyzacji Q4)
- Przykład karty: RTX 3060 Ti (8GB)
- Prędkość: 25-35 tokenów/sekundę
- Uwaga: Za małe do złożonych zadań agentowych
14 miliardów parametrów:
- Potrzeba: 8-10 GB VRAM
- Przykład karty: RTX 4070 Ti (16GB)
- Prędkość: 15-25 tokenów/sekundę
- To minimum dla tool calling – dopiero tutaj agenty mogą skutecznie używać narzędzi
32 miliardy parametrów:
- Potrzeba: 16-20 GB VRAM
- Przykład karty: RTX 3090 (24GB) lub Mac M4 Pro (24GB unified memory)
- Prędkość: 10-20 tokenów/sekundę
- Tutaj modele robią pierwsze wrażenie jakością
70 miliardów parametrów:
- Potrzeba: 35-40 GB VRAM – wymaga dzielenia między GPU
- Przykład: dwie RTX 3090 lub karty enterprise
- Prędkość: 8-12 tokenów/sekundę (wolniejsze przez podział)

Rekomendacje sprzętowe

~800 USD: RTX 4060 Ti + 32GB RAM
~2000 USD: RTX 3090 + 64GB RAM lub Mac M4 Pro 24GB
~4000 USD: Dwie RTX 3090 + 128GB RAM lub Mac M4 Max 64GB

Konkretne rekomendacje modeli do wypróbowania

Cole Medin szczegółowo omawia najlepsze modele lokalne dostępne w Ollama:

DeepSeek R1 – najpopularniejszy lokalny LLM ever. Ma wersje dopasowane do wszystkich kategorii sprzętowych: 7B, 14B, 32B, 70B i pełną wersję 671B parametrów (dla najbogatszych). To model reasoning – potrafi „myśleć” przed odpowiedzią.

Qwen 3 – najnowszy reasoning LLM, autor uważa go za „bardzo dobry”. Dostępny w rozmiarach 8B, 14B i 32B parametrów. Nie ma wersji 70B, jednak jakość jest imponująca.

Mistral Small – solidny wybór z 22-24B parametrów, idealny dla RTX 3090 lub Mac M4 Pro. Dostępna również wersja DevStral – fine-tuned specjalnie do kodowania.

Testowanie przed kupnem sprzętu

Mimo to nie musisz od razu inwestować w drogie GPU. Użyj OpenRouter lub Groq aby przetestować te modele w chmurze zanim zdecydujesz się na hardware. Autor pokazuje jak można wypróbować Qwen 3 32B przez OpenRouter z darmowym limitem, żeby sprawdzić czy jest wystarczająco mocny dla twoich agentów.

Dopiero po testach wiesz czy warto kupić RTX 3090 do uruchomienia tego samego modelu lokalnie.

Quantization – jak zmniejszyć modele bez utraty jakości

Quantization to obniżenie precyzji każdego parametru z 16 bitów do 8, 4 lub 2 bitów. Quantization Q4 to generalnie najlepszy balans między rozmiarem a jakością, dlatego Ollama domyślnie używa tej wartości.

Cole porównuje to do zaokrąglania liczby z długimi miejscami dziesiętnymi do prostszej formy. Robimy to jednak dla miliardów parametrów jednocześnie.

Praktyczne efekty quantization:

• Q8: Połowa rozmiaru, niemal idealna jakość • Q4: Jedna czwarta rozmiaru, nadal świetna jakość
• Q2: Bardzo mały rozmiar, ale zauważalna utrata jakości

Zasada autora: wybierz największy model, który zmieści się na twoim sprzęcie przy quantization Q4.

Alternatywne quantizations

W Ollama każdy model domyślnie używa Q4, ale możesz eksplorować inne opcje. Kliknij „View all” przy dowolnym modelu aby zobaczyć wszystkie warianty quantization – Q8 dla lepszej jakości, Q2 dla najmniejszego rozmiaru, czy nawet pełne FP16 dla maksymalnej jakości (jeśli masz dużo VRAM).

Offloading – gdy model nie mieści się w GPU

Gdy model jest za duży dla VRAM, może być dzielony między GPU a CPU/RAM. To nazywa się offloading i znacznie spowalnia działanie. Autor ostrzega że to „nie jest fun” – komputer się laguje, odpowiedzi są wolne.

Co gorsza, jeśli zabraknie też RAM, model może się rozlać na dysk twardy. To już kompletna katastrofa – odpowiedzi stają się nieznośnie wolne, ale technicznie jest możliwe.

Praktyczne sytuacje offloading:

Długie rozmowy przepełniają VRAM kontekstem
Model ledwo mieści się w GPU przy krótkich promptach
Próba uruchomienia za dużego modelu

Local AI Package – wszystko w jednym pakiecie

Cole przez miesiące tworzył Local AI Package – starannie dobrane rozwiązanie Docker, które eliminuje bariery techniczne. Pakiet zawiera wszystkie potrzebne usługi do uruchomienia kompletnej infrastruktury local AI.

Składniki pakietu

Ollama – do uruchamiania lokalnych LLM-ów
Supabase – open source baza danych
N8N – automatyzacja workflow bez kodu
Open Web UI – interfejs jak ChatGPT do rozmów z modelami
Flowwise – alternatywne narzędzie do budowania agentów
SearXNG – prywatna wyszukiwarka internetowa
Qdrant – baza danych wektorowych
Neo4j – silnik grafów wiedzy
Langfuse – monitorowanie agentów
Caddy – reverse proxy do domen

Całość wymaga około 8GB RAM do działania. Można jednak usuwać niepotrzebne usługi z docker-compose.yml.

✅ Checklist instalacji Local AI Package

Wymagania wstępne:

Python zainstalowany
Git lub GitHub Desktop
Docker lub Docker Desktop
Minimum 8GB RAM w systemie

Kroki instalacji:

Sklonuj repozytorium: git clone [url]
Skopiuj .env.example na .env
Wygeneruj klucze szyfrowania (OpenSSL lub Python)
Skonfiguruj wszystkie zmienne środowiskowe
Uruchom: python start_services.py --profile gpu-nvidia (lub odpowiedni profil)
Sprawdź czy wszystkie kontenery mają zielone statusy
Przetestuj dostęp do usług przez localhost

Typowe porty dostępu:

N8N: localhost:5678
Open Web UI: localhost:8080
Supabase: localhost:8000

Konfiguracja środowiska

Najdłuższy etap to ustawienie zmiennych środowiskowych. Kluczowe elementy to generowanie kluczy szyfrowania dla N8N przy użyciu OpenSSL lub Python, konfiguracja Supabase z JWT secrets i kluczami dostępu, oraz ustawienie haseł dla Neo4j i Langfuse.

Generowanie kluczy szyfrowania:

Linux/Mac: openssl rand -hex 32 Windows (Git Bash): openssl rand -hex 32
Python: python -c "import secrets; print(secrets.token_hex(32))"

Szczególnie ważne są zmienne środowiskowe dla Ollama. Flash attention należy ustawić na true dla optymalizacji obliczeń, quantized KV cache na Q8 kompresuje kontekst rozmowy, a context length trzeba podnieść z domyślnych 2000 do 8000-32000 tokenów. Ponadto warto ograniczyć max loaded models do 1-2 dla lepszej kontroli VRAM.

Maintenance i aktualizacje

Autor szczegółowo wyjaśnia jak aktualizować Local AI Package. To ważne, bo jesteś odpowiedzialny za utrzymanie własnej infrastruktury:

# 1. Zatrzymaj wszystkie usługi
python stop_services.py --profile gpu-nvidia

# 2. Pobierz najnowsze wersje kontenerów  
docker-compose pull --profile gpu-nvidia

# 3. Uruchom ponownie z nowymi wersjami
python start_services.py --profile gpu-nvidia

Kluczowa informacja: Dane przetrwają aktualizację dzięki Docker volumes. Wszystkie workflow N8N, rozmowy Open Web UI i tabele Supabase są zapisane w wolumenach, więc można bezpiecznie restartować i aktualizować kontenery.

OpenAI API compatibility – migracja bez bólu

Najważniejsza cecha Ollama to kompatybilność z OpenAI API. To oznacza, że istniejące agenty można przepiąć na local AI zmieniając tylko dwie linijki kodu.

Standardowy endpoint OpenAI:

base_url = "https://api.openai.com/v1"
api_key = "twój-klucz-openai"

Ollama lokalnie:

base_url = "http://localhost:11434/v1"
api_key = "dowolna-wartość"

Autor pokazuje działający przykład, gdzie ten sam kod Python działa z OpenAI i Ollama – zmienia się tylko konfiguracja. To samo działa z każdym frameworkiem AI jak Pydantic AI, CrewAI czy AutoGen.

Budowanie agentów w N8N

W N8N tworzenie local AI agenta zaczyna się od chat triggera i AI Agent node. Kluczowe jest jednak prawidłowe skonfigurowanie połączeń między kontenerami w sieci Docker.

Kluczowy koncept: Docker network communication

To najważniejsza rzecz do zrozumienia w Local AI Package. Wszystkie usługi działają w tej samej sieci Docker i komunikują się przez nazwy, nie porty.

Zasady połączeń:

W kontenerze → inne kontenery: używaj nazw (ollama, db, searxng)
W kontenerze → host machine: używaj host.docker.internal
Na hoście → kontenery: używaj localhost:port

Typowe błędy: ❌ localhost:11434 w Open Web UI settings (kontener próbuje połączyć się ze sobą) ✅ ollama:11434 (kontener łączy się z Ollama container)

❌ localhost:5432 w N8N do Supabase
✅ db:5432 (nazwa serwisu Postgres w Supabase stack)

Połączenia między usługami

Base URL dla Ollama zależy od lokalizacji. Gdy Ollama działa na hoście, używamy host.docker.internal:11434. Natomiast gdy Ollama jest w kontenerze, używamy nazwy usługi ollama:11434. Nazwa „ollama” to odwołanie do serwisu w docker-compose – kontenery w tej samej sieci komunikują się przez nazwy usług.

Połączenie z Supabase (Postgres) to najtrudniejsze w pakiecie. Host to db (nazwa serwisu bazy Supabase), database i username to postgres, password to wartość z POSTGRES_PASSWORD w .env, a port to standardowy 5432.

Integracja z Open Web UI przez N8N Pipe

Cole Medin stworzył specjalną funkcję „N8N Pipe” dla Open Web UI, która pozwala rozmawiać z agentami N8N jak z modelami językowymi. To game changer – masz przyjazny interfejs jak ChatGPT do testowania swoich agentów.

Konfiguracja N8N Pipe w Open Web UI:

Zaimportuj funkcję z katalogu Open Web UI (Google: „N8N pipe Open Web UI”)
Skonfiguruj valves (ustawienia):
- N8N URL: http://n8n:5678/webhook/invoke-n8n-agent (w kontenerach)
- Bearer token: ten sam co w webhook N8N
- Input/Output fields: chat_input i output

Agent N8N automatycznie rozpoznaje typ zapytania:

Zwykłe pytania → główny agent z narzędziami
Zapytania zaczynające się od „### task” → szybki LLM do generowania tytułów i tagów

Dzięki temu Open Web UI może tworzyć tytuły rozmów i tagi automatycznie, dokładnie jak ChatGPT.

Implementacja w Python z Pydantic AI

Cole pokazuje identycznego agenta napisanego w Python używając Pydantic AI i FastAPI. Główne różnice to tylko konfiguracja połączeń – logika biznesowa pozostaje taka sama.

Struktura obejmuje połączenie z Supabase przez create_client, konfigurację modelu z OpenAI compatibility wskazującą na ollama:11434/v1, oraz definicję agenta z Pydantic AI z system prompt i dependency injection.

Tool do web search przez SearXNG definiujemy jako funkcję z dekoratorem @agent.tool, która wywołuje endpoint searxng:8080. FastAPI endpoint na /invoke-python-agent przyjmuje te same parametry co webhook N8N, dzięki czemu Open Web UI może rozmawiać z oboma wersjami agenta bez zmian.

Konteneryzacja agenta

Ostatni krok to dodanie agenta do docker-compose stack. Dockerfile buduje kontener z Python dependencies, docker-compose.yml dodaje serwis „python-local-ai-agent”, a po konteneryzacji agent może komunikować się z innymi usługami przez nazwy (ollama, searxng) zamiast localhost.

Deployment w chmurze na prywatnym serwerze

Cole pokazuje deployment na Digital Ocean GPU droplet, ale proces działa na każdym Ubuntu VPS. Local AI pozostaje „local” dopóki kontrolujesz serwer – to nie to samo co płacenie za API.

Wybór dostawcy

Rekomendacje autora z konkretnymi cenami:

Digital Ocean GPU:
- RTX 6000 ADA (48GB VRAM): $1.90/godz – może uruchomić 70B modele
- H100 (80GB VRAM): $3.40/godz – absolutna bestia, 240GB RAM
- Wymaga approval (zwykle <24h)
Tensor Dock – tańsze GPU ($0.37/h za RTX 4090), mniej elegancki interfejs
Hostinger – od $7/miesiąc dla CPU-only (KVM2 z 8GB RAM minimum)

Unikaj: Run Pod, Lambda Labs, Vast AI – dają dostęp do kontenerów, nie maszyn. Nie można uruchomić Docker w Docker.

✅ Checklist deployment w chmurze

Przygotowanie serwera:

Wybierz dostawcę z dostępem do maszyny (nie kontenera)
Utwórz instancję Ubuntu z minimum 8GB RAM
Zapisz publiczny adres IP serwera
Skonfiguruj SSH key dla dostępu

Konfiguracja DNS (przed instalacją!):

Utwórz A records dla subdomen (n8n.twoja-domena.com)
Ustaw IP serwera dla każdej subdomeny
Poczekaj na propagację DNS

Bezpieczeństwo:

Włącz firewall: ufw enable
Otwórz porty: ufw allow 80,443/tcp
Przeładuj firewall: ufw reload

Instalacja pakietu:

Sklonuj repozytorium na serwerze
Skonfiguruj zmienne środowiskowe (w tym domeny Caddy)
Zainstaluj Docker Compose jeśli brakuje
Uruchom z --environment public dla bezpieczeństwa
Sprawdź dostępność przez domeny HTTPS

Weryfikacja:

Wszystkie usługi działają (sprawdź docker ps -a)
HTTPS działa automatycznie (Caddy + Let’s Encrypt)
Tylko porty 80/443 otwarte na świat
Dostęp do usług tylko przez reverse proxy

Bezpieczeństwo

W trybie environment=public pakiet zamyka wszystkie porty oprócz 80/443. Dostęp tylko przez Caddy reverse proxy. To maksymalizuje bezpieczeństwo – żadna usługa nie jest bezpośrednio dostępna z internetu.

Caddy automatycznie zarządza certyfikatami SSL dla wszystkich skonfigurowanych domen oraz działa jako jedyny punkt wejścia do infrastruktury.

Co zrobić, gdy nie masz GPU

Cole proponuje podejście hybrydowe – uruchom Local AI Package bez Ollama, użyj OpenAI/Anthropic dla LLM-ów. Ciągle oszczędzasz na infrastrukturze: Supabase (baza danych), N8N (automatyzacja), Open Web UI (interfejs) i SearXNG (prywatna wyszukiwarka) działają lokalnie. Płacisz tylko za wywołania LLM.

🔧 Troubleshooting – częste problemy

Docker/Konteneryzacja:

[ ] Supabase pooler restart (Windows): Zmień pooler.exs na LF endings
[ ] N8N restart loop: Encryption key musi być ustawiony przed pierwszym uruchomieniem
[ ] Brak Docker Compose: Zainstaluj ręcznie na niektórych VPS
[ ] SearXNG restart: Ustaw permissions chmod 755 searxng/

Połączenia między kontenerami:

[ ] Localhost vs nazwy serwisów: W kontenerach używaj nazw (ollama, db, searxng)
[ ] Host.docker.internal: Gdy łączysz kontener z aplikacją na hoście
[ ] Context length limit: Zmień z domyślnych 2000 na 8000+ tokenów
[ ] Model offloading: Monitoruj VRAM, modele mogą się rozlewać na CPU

Open Web UI:

[ ] Połączenie z Ollama: Ustaw prawidłowy base URL w Settings
[ ] Modele nie ładują się: Refresh po zmianie URL Ollama
[ ] API key error: Ustaw dowolną wartość dla OpenAI field (bug UI)

Weryfikacja GPU compatibility:

[ ] Sprawdź Ollama FAQ czy Twoja karta jest obsługiwana
[ ] Użyj ollama list aby zobaczyć załadowane modele
[ ] Monitoruj logi Ollama czy model ładuje się na GPU czy CPU

Przyszłość local AI

Cole Medin przewiduje, że gap między local a cloud AI będzie się zmniejszał, aż lokalne modele dorównają jakością chmurowym. Jednocześnie narzędzia będą łatwiejsze, a koszty setup będą spadać.

Dla firm wymagających prywatności i kontroli local AI już teraz ma sens, nawet przy obecnych kompromisach w jakości modeli. To inwestycja w przyszłość, gdzie lokalne rozwiązania będą standardem.

Dodatkowe zasoby i społeczność

Cole Medin prowadzi Dynamis AI community – społeczność dla early adopters AI, która oferuje AI Agent Mastery course. Kurs obejmuje pełny proces budowania agentów: planowanie, prototypowanie, kodowanie, front-endy, bezpieczeństwo i deployment. Ważne: kurs pokazuje implementacje zarówno z cloud AI jak i local AI.

Inne zasoby autora:

Kanał YouTube z pogłębionymi tutorials local AI
„Ultimate N8N RAG AI Agent Template, Local AI Edition” – video o RAG z Local AI Package

Kluczowy insight

Migracja to dwie linijki

Standardowo myślimy: Przejście z cloud AI na local AI oznacza przepisanie całego kodu, zmianę architektury i tygodnie pracy programistycznej.

W praktyce okazuje się, że: Dzięki OpenAI API compatibility wystarczy zmienić tylko base_url i api_key. Wszystko inne – logika biznesowa, narzędzia, workflow – pozostaje identyczne.

Dlaczego to jest istotne: Ten pozornie techniczny detal całkowicie zmienia ekonomię decyzji o local AI. Nie musisz wybierać między cloud a local na etapie architektury – możesz zacząć z jednym i przełączyć się w kilka minut.

Test na jutro: Następnym razem gdy budujesz agenta AI, zamiast zastanawiać się nad „cloud vs local” od samego początku, spróbuj zbudować go z OpenAI API compatibility i przetestuj oba podejścia zmieniając tylko dwie linijki kodu.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych prezentacji, podcastów i webinarów, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: The Ultimate Guide to Local AI and AI Agents

Tag: Infrastruktura Ai

Local AI – kompletny przewodnik po prywatnej sztucznej inteligencji #EN145