Odcinek kanału YouTube
Jak zrobić Asystenta AI, który zamieszka u Ciebie w homelabie — krok po kroku | Homelab #5
19.10.2025Prywatny ChatGPT bez abonamentu? Zobacz, jak uruchomić lokalne modele LLM (Ollama + Open WebUI) i mieć do nich bezpieczny dostęp z każdego miejsca na świecie dzięki Tailscale.
YouTube
Film ładuje się dopiero po kliknięciu — bez ciasteczek YouTube przed odtworzeniem.
Notatki do odcinka
Streszczenie i rozwinięcie filmu — dla osób, które wolą najpierw przeskanować temat, zamiast oglądać całość.
W tym odcinku buduję lokalnego asystenta AI, który może działać offline i nie musi wysyłać rozmów do chmury. Stack składa się z Ollamy oraz Open WebUI uruchomionych w Dockerze. Całość można hostować na własnym serwerze albo laptopie, a dostęp z telefonu prowadzę przez Tailscale.
Zaczynam od pytania, po co w ogóle uruchamiać model lokalnie. Prywatność jest jednym z powodów, ale równie ważna jest kontrola nad wersją używanego modelu. Jednocześnie lokalne rozwiązanie ma własne ryzyka: trzeba dobrać model do sprzętu, pamiętać o zasobach i nie wystawić usługi przypadkiem do internetu.
W dalszej części tłumaczę kwantyzację, okno kontekstu i oznaczenia liczby parametrów. Potem przechodzę do Docker Compose, ustawień Ollamy i Open WebUI, zapory UFW oraz Tailscale Serve. Na końcu sprawdzam dostęp do interfejsu z telefonu przez Magic DNS i pokazuję kierunek dalszych automatyzacji pod Shorts.
Co zobaczysz
Najpierw porządkuję argumenty za lokalnym GPT. Model działający na własnym sprzęcie daje większą kontrolę nad tym, gdzie trafiają dane i jaką wersję modelu wybieram. W odcinku omawiam też ryzyka rozwiązań chmurowych, korzystając między innymi z przykładów ujawnienia danych oraz blokady narzędzi po wycieku kodu. Te przykłady nie są obietnicą, że lokalny serwer rozwiązuje wszystkie problemy; mają pokazać, dlaczego miejsce przetwarzania danych ma znaczenie.
Potem przechodzę do doboru modelu. Wyjaśniam, czym różnią się kwantyzacje Q4 i Q5, jak działa num_ctx oraz co oznacza liczba parametrów zapisana przy modelu. Okno kontekstu w opisywanym setupie rozpatruję w zakresie 2k–4k. Łączę te pojęcia z ilością RAM-u, bo model nie jest abstrakcyjnym plikiem: musi zmieścić się w konkretnym środowisku i zachować użyteczną konfigurację.
Następny rozdział dotyczy infrastruktury. W Docker Compose zestawiam Ollamę z Open WebUI, omawiam porty, wolumeny i zależność między usługami. Pojawiają się też ustawienia OLLAMA_HOST, KEEP_ALIVE, BASE_URL oraz tryb offline. Istotne jest to, że porty są przypięte do localhosta, zamiast być bezpośrednio publikowane na publicznym interfejsie.
Warstwę dostępu zdalnego realizuję przez Tailscale Serve. Interfejs Web UI dostaje reverse proxy HTTPS, a API Ollamy korzysta z TCP na porcie 11434 w tailnecie. UFW pomaga utrzymać twardą granicę, a Magic DNS pozwala znaleźć usługę z telefonu bez publicznego adresu IP.
Kluczowe wnioski
Lokalny asystent nie jest po prostu „chmurowym chatbotem na własnym komputerze”. Zyskuję kontrolę nad przepływem danych i wersją modelu, ale przejmuję również odpowiedzialność za sprzęt, konfigurację, aktualizacje i dostęp sieciowy. Dlatego decyzję trzeba oceniać razem z ograniczeniami konkretnego komputera.
Dobór modelu zaczyna się od zasobów. Q4 i Q5 opisują poziom kwantyzacji, num_ctx określa długość kontekstu, a liczba parametrów daje ogólne wyobrażenie o rozmiarze modelu. Żaden z tych skrótów nie działa w oderwaniu od RAM-u. W praktyce wybór jest kompromisem między możliwościami modelu a tym, co może stabilnie uruchomić mój sprzęt.
Bezpieczeństwo jest częścią wdrożenia, nie dodatkiem po demonstracji. Porty przypięte do localhosta, UFW i Tailscale Serve tworzą razem ścieżkę, w której interfejs i API nie muszą być wystawione publicznie. W odcinku wyraźnie rozdzielam HTTPS dla Web UI od dostępu TCP do API Ollamy.
Warto też odróżnić prywatność od pełnej bezobsługowości. Tryb offline i lokalne modele ograniczają wysyłanie danych, ale nie zwalniają z kontroli konfiguracji ani z testowania dostępu. Końcowy test z telefonu przez Magic DNS jest ważny właśnie dlatego, że sprawdza cały przepływ, a nie tylko uruchomienie kontenera.
Jak to odtworzyć
Przygotuj serwer lub laptop i uruchom w Dockerze Ollamę oraz Open WebUI przez Docker Compose. W konfiguracji użyj wolumenów, depends_on, trybu offline oraz zmiennych OLLAMA_HOST, KEEP_ALIVE i BASE_URL. Porty przypnij do localhosta. Następnie pobierz modele z Ollamy i skonfiguruj WebUI.
Dobierz model na podstawie RAM-u, kwantyzacji Q4 albo Q5, liczby parametrów i potrzebnego num_ctx. Na warstwie sieciowej ustaw UFW i Tailscale Serve: HTTPS dla interfejsu oraz TCP dla API na porcie 11434. Włącz Magic DNS i sprawdź połączenie z telefonu. Repozytorium z konfiguracją znajduje się w materiałach.
Najczęstsze pytania
Czy lokalny model działa bez chmury? Tak, odcinek pokazuje Ollamę i Open WebUI w trybie offline na własnym sprzęcie.
Jak wybrać Q4 czy Q5? Trzeba uwzględnić RAM, liczbę parametrów i wymagane okno kontekstu. Odcinek omawia te zależności, ale nie wskazuje jednego modelu dla każdego komputera.
Czy muszę wystawiać porty do internetu? Nie. Opisany dostęp używa localhosta, UFW, Tailscale Serve i Magic DNS.