Dlaczego lokalny LLM w Home Assistant to przełom w 2026 roku
Jeszcze niedawno sterowanie domem głosem wymagało wysyłania komend do chmury. Każde "włącz światło w salonie" opuszczało twój dom, lądowało na serwerach dostawcy i wracało z powrotem. Działało. Tylko że działało na cudzych warunkach.
W 2026 roku obrazek wygląda inaczej. Ollama pozwala uruchomić model językowy na własnym sprzęcie, a integracja z Home Assistant zamienia go w lokalnego asystenta bez klucza API. Żadnych subskrypcji, żadnych limitów zapytań, żadnego wysyłania danych o tym, kiedy wracasz do domu i o której gasisz światło.
To nie czarna magia. Model działa na twoim komputerze, mini PC albo nawet na mocniejszym Raspberry Pi z odpowiednim zapasem RAM.
- Prywatność zostaje w domu, bo żadne zapytanie nie opuszcza lokalnej sieci.
- Koszty są przewidywalne, płacisz raz za sprzęt zamiast miesięcznego abonamentu.
- Działa bez internetu, więc awaria łącza nie wyłącza inteligentnego domu.
- Możesz podłączyć dowolny model i zmienić go, kiedy pojawi się lepszy.
- Brak limitów API oznacza, że asystent odpowiada tak często, jak chcesz.
Moim zdaniem lokalny LLM wygrywa z rozwiązaniami chmurowymi nie dlatego, że jest mądrzejszy, ale ponieważ daje kontrolę. Chmurowy asystent bywa wygodniejszy na start, tylko że uzależnia cię od cudzej infrastruktury i cennika, który może się zmienić z dnia na dzień.
Wyobraź sobie sytuację, w której twoja sieć domowa traci połączenie z internetem na kilka godzin. Chmurowy asystent milknie całkowicie. Lokalny model dalej rozumie polecenia i steruje urządzeniami, bo cała logika siedzi obok ciebie.
I tu zaczyna się problem dla producentów zamkniętych ekosystemów. Trudno sprzedawać subskrypcję, gdy użytkownik może mieć to samo za darmo, u siebie.
Jak działa Ollama z Home Assistant — architektura bez chmury i klucza API
Kluczowa różnica względem chmurowych asystentów jest prosta: żadne zapytanie nie opuszcza Twojej sieci lokalnej. Ollama uruchamia model językowy jako zwykły proces na komputerze w domu, a Home Assistant łączy się z nim przez lokalny adres IP. Koniec z limitami tokenów, subskrypcjami i wysyłaniem stanu domu do obcego serwera.
Cała architektura opiera się na trzech warstwach: modelu, API i integracji. Ollama wystawia lokalny endpoint HTTP, najczęściej na porcie 11434. Home Assistant wysyła do niego prompt, model generuje odpowiedź, a integracja zamienia ją na akcję, scenę albo odpowiedź w asystencie głosowym.
| Warstwa | Rola | Gdzie działa | Klucz API |
|---|---|---|---|
| Model LLM | Rozumie polecenia i generuje tekst | Ollama na PC lub serwerze domowym | Nie |
| API lokalne | Przekazuje zapytania do modelu | Adres IP w sieci LAN | Nie |
| Integracja HA | Zamienia odpowiedzi na akcje | Home Assistant | Nie |
| Chmura | Zwykle zbędna | Poza domem | Zwykle tak |
Masz pełną kontrolę nad tym, który model obsługuje jakie zadania. Lekki model poradzi sobie z prostymi komendami typu „zgaś światło w salonie", a większy z bardziej złożonymi zapytaniami. Diabeł tkwi w szczegółach: im większy model, tym więcej pamięci RAM i mocniejszy procesor potrzebujesz.
Materiał sprzętowy ma znaczenie, ale nie trzeba od razu inwestować w drogi serwer. Moim zdaniem mniejszy model uruchomiony lokalnie działa lepiej niż duży model w chmurze, ponieważ odpowiada bez opóźnień sieciowych i nie zależy od dostępności zewnętrznego dostawcy. Brzmi jak kompromis, ale w praktyce dla sterowania domem to wystarcza.
Instalacja i konfiguracja Ollama krok po kroku: od serwera do integracji
Zacznijmy od tego, gdzie Ollama ma faktycznie działać. Na Raspberry Pi 5 da się ją uruchomić, ale model 7B będzie odpowiadał zauważalnie wolniej niż na mini PC z procesorem N100 i 16 GB RAM. Do sterowania światłami i roletami wystarczy model rzędu 3B, a różnica w czasie reakcji bywa odczuwalna. Serwer z Ollamą powinien stać w sieci lokalnej na stałym adresie IP.
Instalacja na Linuksie sprowadza się do jednego polecenia curl ze skryptu instalacyjnego, na Windows działa instalator, a na macOS wystarczy obraz aplikacji. Po starcie usługa nasłuchuje domyślnie na porcie 11434. Sprawdź to poleceniem curl na endpoint statusu, zanim pójdziesz dalej.
- Zainstaluj Ollamę i uruchom usługę jako stały proces systemowy.
- Pobierz model poleceniem ollama pull, np. wariant 3B albo 7B.
- Ustaw OLLAMA_HOST tak, by usługa przyjmowała połączenia z sieci lokalnej, a nie tylko z localhost.
- W Home Assistant dodaj integrację Ollama i wskaż adres serwera z portem 11434.
- Wybierz pobrany model i przetestuj odpowiedź w narzędziu deweloperskim.
Bezpieczeństwo to najczęściej pomijany krok. Ollama nie ma wbudowanego logowania, więc wystawienie portu 11434 na świat to zaproszenie do kłopotów. Zostaw ją w VLAN-ie bez dostępu z zewnątrz albo postaw przed nią reverse proxy z uwierzytelnianiem. Diabeł tkwi w szczegółach, a tu szczegół kosztuje spokój.
Moim zdaniem model 3B sprawdza się lepiej w automatyce domowej niż większe warianty, ponieważ generuje krótsze odpowiedzi i szybciej wraca z wynikiem. Do prostych poleceń typu "zgaś światło w kuchni" większa modelka nie wnosi nic poza opóźnieniem.
Wyobraź sobie sytuację, w której po aktualizacji systemu usługa wstaje, ale odpowiada tylko na localhost. Wtedy integracja w Home Assistant zgłasza błąd połączenia, choć Ollama działa. Wystarczy poprawić OLLAMA_HOST i zrestartować usługę.
Wybór modelu i optymalizacja sprzętu pod lokalne sterowanie domem
Nie każdy model sprawdzi się w roli domowego asystenta. Duże modele pokroju 70B potrafią rozumować świetnie, ale na typowym mini PC będą generować odpowiedź przez kilkanaście sekund. Przy komendzie "zgaś światło w salonie" to zabójca wrażeń. Małe modele 3B-8B odpowiadają w ułamku sekundy i wystarczają do parsowania intencji.
Kluczowa jest kwantyzacja. Wersje Q4_K_M to złoty środek między jakością a zużyciem RAM. Model 7B w Q4 zajmuje około 4-5 GB pamięci, więc zmieści się na sprzęcie z 8 GB RAM. Poniżej zestawienie orientacyjne dla popularnych rozmiarów:
| Rozmiar modelu | RAM (Q4) | Typowy czas odpowiedzi | Zastosowanie |
|---|---|---|---|
| 3B | ~2 GB | bardzo szybki | proste komendy, klasyfikacja intencji |
| 7B-8B | ~5 GB | szybki | scenariusze, konwersacja |
| 13B | ~8 GB | umiarkowany | złożone polecenia, kontekst |
| 70B | ~40 GB | wolny bez GPU | rzadko sensowny w domu |
Mój pogląd jest taki: model 7B-8B w Q4 działa lepiej niż 13B na tym samym sprzęcie, ponieważ różnica w jakości rozumienia prostych komend jest niewielka, a opóźnienie robi ogromną różnicę w codziennym użytkowaniu. Wyjątkiem są zadania wymagające rozumowania wieloetapowego.
Sprzęt? NUC z 16 GB RAM, mini PC z Ryzenem, a nawet Raspberry Pi 5 z 8 GB da radę przy małych modelach. Karta graficzna przyspiesza, ale nie jest obowiązkowa. Diabeł tkwi w szczegółach: sprawdź, czy twój procesor obsługuje AVX2, bo bez tego wydajność spada zauważalnie.
Praktyczne scenariusze: automatyzacje, głos i sterowanie bez internetu
Gdy Ollama działa lokalnie, automatyzacje przestają zależeć od chmury. Asystent głosowy rozumie polecenia nawet przy zerwanym łączu. To zmienia reguły gry.
Typowy przykład: masz w domu kilka lamp Zigbee, termostat i rolety sterowane przez Home Assistant. Zamiast wpisywać sztywne reguły typu "jeśli ruch, to światło", piszesz asystentowi: "gdy wrócę po zmroku, przygotuj dom do wieczoru". Lokalny model interpretuje intencję i sam dobiera scenę. Bez internetu, bez wysyłania komend na zewnątrz.
Moim zdaniem sterowanie głosem przez lokalny LLM działa lepiej niż klasyczne komendy na sztywno, ponieważ nie musisz pamiętać dokładnych fraz. Wystarczy sens zdania, a model mapuje go na encje w Home Assistant.
| Scenariusz | Co robi lokalny LLM | Zależność od internetu |
|---|---|---|
| Sterowanie głosem | Zamienia mowę na akcję w HA | Brak |
| Automatyzacja kontekstowa | Łączy pogodę, obecność i czas | Brak |
| Podsumowanie czujników | Opisuje stan domu po polsku | Brak |
| Reakcja na awarię sieci | Utrzymuje działanie scen | Brak |
Diabeł tkwi w szczegółach. Model lokalny bywa wolniejszy niż chmurowy, więc warto testować komendy na sprzęcie, który realnie masz. A co jeśli się okaże, że mały model gubi kontekst? Wtedy zostaje dopracowanie promptu. Więcej o konfiguracji asystenta znajdziesz w sekcji o agencie AI w Home Assistant.
Najczęściej zadawane pytania (FAQ)
Czy Ollama naprawdę działa bez żadnego klucza API? Tak, i to jest jej największa zaleta. Model pobierasz komendą w terminalu, uruchamiasz lokalnie na własnym sprzęcie i odpytywujesz przez adres w sieci lokalnej. Żadnej rejestracji, żadnego limitu zapytań, żadnego rachunku za tokeny. Brzmi prosto. Tylko że za wygodę płacisz własnym prądem i czasem konfiguracji.
Poniżej zestawiłem pytania, które przewijają się najczęściej, gdy ktoś pierwszy raz łączy lokalny LLM z Home Assistant to zagadnienie szczegółowo omawiamy w artykule "Home assistant ai agent lokalny llm 2026".
| Pytanie | Krótka odpowiedź | Na co uważać |
|---|---|---|
| Czy potrzebuję karty graficznej? | Nie, ale mocno przyspiesza | Na samym CPU małe modele chodzą, duże będą wolne |
| Czy dane wychodzą z domu? | Nie, wszystko zostaje lokalnie | Chyba że sam dodasz integrację chmurową |
| Czy to działa z Matter i Zigbee? | Tak, przez encje w Home Assistant | Model steruje encjami, nie protokołem bezpośrednio |
| Czy model rozumie polski? | Zależy od modelu | Mniejsze modele częściej mieszają języki |
| Czy to zastąpi automatyzacje? | Nie, uzupełnia je | Do prostych reguł automatyzacja bywa pewniejsza |
Moim zdaniem do sterowania głosem i luźnych poleceń lepiej sprawdza się mały model działający szybko niż duży, który myśli pół minuty nad zapaleniem światła. Powód jest prosty: w smart home liczy się czas reakcji, a nie elokwencja odpowiedzi. Duże modele mają sens przy analizie danych czy podsumowaniach, ale nie przy komendzie "zgaś światło w kuchni".
Zanim postawisz wszystko na jednej maszynie, sprawdź, czy Twój sprzęt udźwignie model w rozsądnym czasie. I pamiętaj, że konfiguracja to proces, nie jednorazowy klik.
Komentarze (0)
Dodaj komentarz