Hub smart home z lokalnym LLM – jak AI może analizować kamery bez wysyłania nagrań do chmury?

Kamera przy drzwiach wykrywa człowieka. Kilka sekund później dom wysyła komunikat: „Kurier zostawił paczkę przy wejściu, nikogo już nie ma przed drzwiami”. Technicznie nie jest to dziś szczególnie trudne. Ciekawsze jest coś innego: cała analiza może odbyć się w domu, bez przesyłania klatki z kamery do serwera producenta, OpenAI, Google czy innego dostawcy chmurowej AI.

Tak zbudowany system różni się od klasycznego monitoringu. Kamera dostarcza obraz, lokalny NVR wykrywa ruch i obiekty, a lokalny model językowo-wizyjny VLM interpretuje wybrane klatki. Home Assistant lub inny hub wykorzystuje wynik do automatyzacji. Internet może być potrzebny do aktualizacji oprogramowania, ale nie do codziennego rozpoznawania tego, co dzieje się przed domem.

Najważniejsze jest jednak właściwe rozłożenie zadań. Uruchamianie dużego modelu AI na każdej klatce z czterech kamer to świetny sposób na zakup drogiego komputera i osiągnięcie kiepskich rezultatów. Dobrze zaprojektowany system działa odwrotnie: najpierw tani obliczeniowo filtr, później detekcja obiektu, a generatywna AI dopiero na końcu.

Lokalny LLM nie powinien oglądać całego monitoringu

Termin „lokalny LLM” jest w przypadku kamer pewnym uproszczeniem. Zwykły LLM – Large Language Model – pracuje przede wszystkim na tekście. Żeby model mógł interpretować zdjęcie z kamery, potrzebny jest model multimodalny, najczęściej określany jako VLM, czyli Vision-Language Model.

Praktyczny system można podzielić na cztery warstwy:

• kamera IP dostarcza strumień RTSP,

• system taki jak Frigate wykrywa ruch i obiekty,

• wybrana klatka trafia do lokalnego VLM,

• Home Assistant podejmuje decyzję na podstawie wyniku.

To rozdzielenie ma ogromne znaczenie.

Frigate nie musi pytać dużego modelu: „czy na obrazie jest człowiek?”. Do tego wystarczy klasyczny model detekcji obiektów, np. rodzina YOLO, MobileNet lub inny model uruchamiany przez OpenVINO, TensorRT, Hailo czy Edge TPU.

Model językowo-wizyjny powinien dostać bardziej wymagające pytanie:

„Co robi osoba stojąca przed drzwiami?”

albo:

„Czy samochód zatrzymał się przed bramą, czy tylko przejeżdża?”

Można pójść dalej:

„Czy paczka została pozostawiona przy wejściu?”

To właśnie na tym poziomie lokalna generatywna AI zaczyna mieć sens.

W praktycznej konfiguracji kamera może posiadać dwa strumienie. Główny, np. 2560 × 1440 lub 3840 × 2160, służy do nagrywania. Drugi strumień, np. 1280 × 720 przy 5 kl./s, można wykorzystać do detekcji.

Nie ma powodu analizować 25 czy 30 klatek na sekundę tylko po to, żeby wykryć człowieka idącego chodnikiem. Frigate sam stosuje architekturę, w której detekcja ruchu ogranicza liczbę klatek przekazywanych do kosztowniejszej analizy obiektów.

To daje bardzo konkretną korzyść: cztery kamery nie oznaczają czterokrotnego obciążenia modelu VLM.

Typowa sekwencja może wyglądać tak:

1. Kamera wykrywa zmianę obrazu.

2. Frigate identyfikuje obiekt jako person.

3. System czeka np. 1–2 sekundy, aby uzyskać lepszą klatkę.

4. Jedno zdjęcie trafia do lokalnego modelu VLM.

5. Model zwraca krótki opis.

6. Home Assistant sprawdza dodatkowe warunki.

7. Dopiero wtedy wysyłane jest powiadomienie.

Przykład:

Frigate: wykryto człowieka w strefie furtka.

VLM: „Osoba trzyma karton i stoi przy furtce”.

Home Assistant: dom jest pusty, właściciele są poza strefą domu.

Akcja: wyślij powiadomienie „Prawdopodobnie kurier jest przy furtce”.

To jest znacznie rozsądniejsze niż przekazywanie całego obrazu bezpośrednio do generatywnej AI.

Jest też druga korzyść: mniej fałszywych alarmów. Same algorytmy detekcji potrafią poprawnie rozpoznać człowieka, ale nie rozumieją kontekstu. Dla klasycznego detektora osoba przechodząca chodnikiem i osoba próbująca otworzyć furtkę należą do tej samej klasy person.

VLM potrafi rozróżnić te sytuacje znacznie lepiej, choć nadal nie daje stuprocentowej pewności. To ważne ograniczenie. Generatywny model może błędnie opisać gest, pomylić torbę z paczką albo dopowiedzieć szczegół, którego na obrazie nie widać.

Dlatego LLM lub VLM nie powinien samodzielnie sterować zamkiem, bramą czy alarmem na podstawie pojedynczej interpretacji obrazu.

Powiadomienie? Tak.

Włączenie dodatkowego światła? Zwykle tak.

Automatyczne otwarcie drzwi, bo AI uznało osobę za domownika? Zdecydowanie nie jako jedyne kryterium.

Ile sprzętu potrzeba i gdzie pojawia się prawdziwe wąskie gardło

Najczęstszy błąd przy budowie lokalnego AI smart home polega na ocenianiu całego systemu przez liczbę TOPS podaną w reklamie procesora.

TOPS nie jest uniwersalną miarą szybkości LLM. Wydajność zależy również od rodzaju obliczeń, pamięci, przepustowości RAM, obsługiwanej precyzji modelu oraz konkretnego backendu.

Do samego Home Assistanta wystarczy sprzęt bardzo skromny. Do Frigate z kilkoma kamerami potrzebny jest już rozsądny dekoder wideo i akceleracja detekcji. Lokalny VLM podnosi wymagania jeszcze o poziom wyżej.

W 2026 roku sensowne są trzy klasy konfiguracji.

1. Mini-PC z Intelem – rozsądna baza pod monitoring

Komputer z Intelem N100/N150, 16 GB RAM i SSD 512 GB można znaleźć mniej więcej za 700–1200 zł, zależnie od producenta, systemu i wyposażenia.

Taki sprzęt dobrze sprawdza się jako:

• Home Assistant,

• broker MQTT,

• Frigate,

• lokalny NVR,

• OpenVINO do detekcji obiektów,

• serwer automatyzacji.

Frigate potrafi wykorzystywać Intel iGPU przez OpenVINO oraz akcelerację sprzętową dekodowania obrazu. To istotne, ponieważ samo dekodowanie kilku strumieni H.264/H.265 potrafi niepotrzebnie obciążyć CPU.

N100 nie jest natomiast idealnym komputerem do regularnego uruchamiania większego VLM. Mały skwantyzowany model da się uruchomić, ale czas odpowiedzi może być irytujący. Jeżeli analiza pojedynczego zdarzenia trwa kilkanaście lub kilkadziesiąt sekund, automatyzacja zaczyna przypominać raport po fakcie zamiast systemu czasu rzeczywistego.

2. Raspberry Pi 5 z akceleratorem – energooszczędnie, ale niekoniecznie tanio

Raspberry Pi 5 8 GB kosztuje w Polsce około 800–850 zł za samą płytkę. Po dodaniu obudowy, chłodzenia, odpowiedniego zasilacza i pamięci masowej kompletny zestaw potrafi dojść do 1200–1400 zł.

Do wykrywania obiektów można dodać np. akcelerator Hailo-8 lub Hailo-8L.

Hailo-8L w zastosowaniach obsługiwanych przez Frigate potrafi osiągać czasy inferencji rzędu około 10–20 ms dla niewielkich modeli detekcji, zależnie od architektury.

To świetnie nadaje się do wykrywania:

• ludzi,

• samochodów,

• zwierząt,

• rowerów,

• innych klas obiektów.

Nie należy jednak mylić takiego akceleratora z GPU dla dużego modelu językowo-wizyjnego. Sprzęt przeznaczony do szybkiej detekcji YOLO nie staje się automatycznie wydajnym urządzeniem do generatywnej AI.

Podobny problem dotyczy Google Coral. Frigate nadal go obsługuje, ale nie rekomenduje go już jako podstawowego wyboru do nowych instalacji, jeśli dostępna jest nowocześniejsza akceleracja. Coral pozostaje bardzo energooszczędny, lecz służy do określonego rodzaju inferencji. Nie przyspieszy lokalnego LLM ani funkcji takich jak semantyczne wyszukiwanie obrazu.

3. Jetson lub mocniejszy mini-PC – gdy VLM ma rzeczywiście pracować lokalnie

Ciekawszą platformą do eksperymentów z generatywną AI jest NVIDIA Jetson Orin Nano Super. Ma 8 GB pamięci LPDDR5, przepustowość pamięci 102 GB/s, deklarowaną wydajność do 67 INT8 TOPS i pobór mocy konfigurowalny w zakresie około 7–25 W.

To już sprzęt projektowany z myślą o lokalnej AI, w tym modelach językowych i wizyjno-językowych.

Problemem jest cena. W polskich ofertach w 2026 roku Jetson Orin Nano Super pojawia się w okolicach 2000–2900 zł, a do części konfiguracji trzeba doliczyć nośnik NVMe. Drugą niedogodnością jest pamięć: 8 GB współdzielonego RAM-u szybko staje się ograniczeniem przy większych modelach.

Alternatywą są mini-PC z układami AMD Ryzen AI, Intel Core Ultra lub dedykowaną kartą NVIDIA. Tutaj łatwo jednak przejść z domowego huba za około 1000 zł do komputera kosztującego 3000–5000 zł albo więcej.

Dlatego przed zakupem mocnego GPU trzeba odpowiedzieć na jedno pytanie:

czy model naprawdę musi analizować każde zdarzenie natychmiast?

Jeżeli kamera generuje 30 interesujących zdarzeń dziennie, nie potrzeba systemu zdolnego przetwarzać obrazu bez przerwy.

Znacznie ważniejsza od maksymalnej liczby tokenów na sekundę jest dobrze zaprojektowana kolejka.

Przykładowo:

• detekcja person działa cały czas,

• VLM analizuje tylko wejście człowieka do określonej strefy,

• ponowna analiza tej samej osoby jest blokowana przez 30–60 sekund,

• analizowana jest jedna dobra klatka, a nie 20 podobnych,

• zdarzenia o niskim znaczeniu są ignorowane.

W domu z czterema kamerami taka optymalizacja potrafi zrobić większą różnicę niż wymiana procesora na dwukrotnie szybszy.

Trzeba też policzyć dysk.

Cztery kamery zapisujące średnio 4 Mb/s każda generują łącznie około 16 Mb/s, czyli mniej więcej 173 GB danych na dobę przy nagrywaniu ciągłym. W tydzień daje to około 1,2 TB.

Przy sześciu kamerach sytuacja robi się jeszcze ciekawsza.

Dlatego do NVR rozsądniej zastosować osobny SSD/HDD o pojemności 2–4 TB niż zapisywać monitoring na tym samym 256-GB dysku, na którym działa Home Assistant.

Nagrywanie wyłącznie zdarzeń potrafi mocno ograniczyć zużycie miejsca, ale ma oczywistą wadę: jeżeli detektor czegoś nie wykryje, materiał może w ogóle nie zostać zachowany. Przy monitoringu bezpieczeństwa lepszym kompromisem bywa nagrywanie ciągłe z krótszą retencją oraz dłuższe przechowywanie klipów oznaczonych jako istotne.

Prywatność zaczyna się od sieci, a nie od instalacji modelu

Samo uruchomienie Ollamy albo lokalnego VLM nie oznacza jeszcze, że system monitoringu stał się prywatny.

Najpierw trzeba sprawdzić gdzie kamera faktycznie wysyła dane.

Część konsumenckich kamer Wi-Fi jest projektowana przede wszystkim do współpracy z chmurą producenta. Aplikacja mobilna może korzystać z serwerów zewnętrznych nawet wtedy, gdy lokalnie dostępny jest RTSP lub ONVIF.

Jeżeli priorytetem jest monitoring lokalny, przy wyborze kamery ważniejsze od efektownej aplikacji są:

• RTSP,

• ONVIF,

• możliwość pracy bez połączenia z chmurą,

• konfiguracja strumienia głównego i pomocniczego,

• lokalna synchronizacja czasu,

• możliwość ustawienia statycznego adresu IP albo rezerwacji DHCP,

• stabilne działanie po odcięciu dostępu do internetu.

Dobrze zaprojektowana sieć stawia kamery w osobnym VLAN-ie IoT.

Kamery powinny móc komunikować się z serwerem Frigate, DNS-em oraz potrzebnymi usługami lokalnymi, ale nie muszą mieć swobodnego dostępu do całego LAN-u.

W bardziej restrykcyjnym wariancie blokuje się im również internet.

To bardzo dobry test zakupowy. Jeśli po zablokowaniu internetu kamera przestaje udostępniać obraz lokalnemu NVR-owi, nie jest najlepszym kandydatem do systemu nastawionego na prywatność.

Drugi element to lokalne przechowywanie nagrań.

Nagranie może pozostawać na własnym dysku, a poza dom wychodzić wyłącznie powiadomienie tekstowe:

„O 14:32 wykryto osobę przy furtce”.

Jeżeli użytkownik potrzebuje podglądu zdjęcia poza domem, można udostępnić dostęp przez VPN, np. WireGuard lub rozwiązanie o podobnej architekturze, zamiast automatycznie publikować monitoring przez otwarte przekierowanie portów.

Portu panelu Home Assistanta, Frigate ani kamery nie powinno się po prostu wystawiać bezpośrednio do internetu.

To jeden z pierwszych błędów, które trzeba wyeliminować.

Lokalna analiza daje również praktyczną kontrolę nad retencją danych. Nie ma technicznego powodu, żeby wszystkie nagrania przechowywać miesiącami.

Można ustawić na przykład:

• pełne nagrania przez 3–7 dni,

• istotne zdarzenia przez 14–30 dni,

• snapshoty alarmowe przez 30 dni,

• automatyczne usuwanie pozostałych danych.

To również ogranicza skutki ewentualnego przejęcia serwera. Im mniej historycznego materiału znajduje się na dysku, tym mniejszy pakiet danych można wykraść.

W polskich warunkach trzeba dodatkowo uważać na kadr kamery. Monitoring obejmujący wyłącznie własną posesję może mieścić się w zakresie osobistej lub domowej aktywności. Sytuacja komplikuje się, gdy kamera stale obejmuje chodnik, ulicę, wejście sąsiada albo inną przestrzeń publiczną. Europejskie zasady dotyczące tzw. wyjątku domowego są interpretowane wąsko i objęcie monitoringiem przestrzeni publicznej może spowodować, że przetwarzanie nie będzie już traktowane jako czysto osobiste.

Praktyczna zasada jest prostsza niż analiza prawna: kadruj tylko tyle, ile rzeczywiście trzeba chronić.

Jeżeli kamera przy furtce obejmuje pół ulicy, najpierw popraw jej ustawienie. Maski prywatności również pomagają, ale lepiej nie zbierać niepotrzebnego obrazu już na etapie źródła.

Kolejna pułapka pojawia się przy lokalnym LLM.

Home Assistant oficjalnie integruje się z lokalnym serwerem Ollama, a modele posiadające obsługę narzędzi mogą także sterować udostępnionymi encjami systemu. Dokumentacja Home Assistanta zaleca przy eksperymentach z mniejszymi lokalnymi modelami ograniczenie liczby udostępnionych encji do mniej niż około 25, ponieważ małe modele częściej popełniają błędy.

To jest dobra zasada również poza Home Assistantem: model powinien widzieć tylko te urządzenia, których naprawdę potrzebuje.

Model opisujący zdjęcia z furtki nie potrzebuje dostępu do:

• zamka drzwi wejściowych,

• bramy garażowej,

• alarmu,

• termostatu,

• wszystkich świateł w budynku.

Najbezpieczniej traktować AI jako warstwę interpretującą, a nie centralny system uprawnień.

Dopiero kiedy lokalny model przez kilka tygodni poprawnie klasyfikuje zdarzenia, można pozwolić mu wyzwalać automatyzacje o niewielkich konsekwencjach.

Najlepsza kolejność budowy takiego systemu jest więc bardzo konkretna.

Najpierw uruchom jedną kamerę RTSP, Frigate i sprzętową detekcję obiektów. Ustaw poprawnie strefy oraz maski ruchu i obserwuj przez kilka dni liczbę fałszywych wykryć. Dopiero kiedy klasyczne rozpoznawanie person, car czy dog działa stabilnie, dodaj lokalny VLM do analizy pojedynczych snapshotów.

Nie kupuj najpierw GPU za kilka tysięcy złotych. Największym błędem w takich instalacjach zwykle nie jest zbyt wolny model, tylko wysyłanie do AI zbyt wielu źle wybranych obrazów.

FAQ

Czy do lokalnej analizy kamer potrzebny jest internet?
Nie do samej analizy, jeżeli kamera, Frigate, model AI i Home Assistant działają lokalnie. Internet będzie jednak potrzebny m.in. do pobierania modeli, aktualizacji oraz niektórych usług zewnętrznych.

Czy Raspberry Pi 5 wystarczy do czterech kamer?
Do Home Assistanta, NVR-u i detekcji wspomaganej odpowiednim akceleratorem może wystarczyć. Do komfortowego uruchamiania większego modelu VLM 8 GB RAM jest jednak poważnym ograniczeniem. Jeśli AI ma często opisywać obrazy, mocniejszy mini-PC lub platforma z GPU będzie wygodniejsza.

Czy lokalny model rozpoznaje twarze?
VLM może próbować opisywać osoby, ale nie powinien zastępować dedykowanego systemu identyfikacji twarzy. Frigate posiada osobne funkcje rozpoznawania twarzy. Trzeba też pamiętać, że dane biometryczne wymagają znacznie ostrożniejszego podejścia niż zwykłe wykrycie klasy person.

Czy warto dziś kupować Google Coral?
Do istniejącej instalacji nadal może być użyteczny i jest bardzo energooszczędny. Do nowej instalacji Frigate wskazuje obecnie również nowsze rozwiązania, takie jak Hailo, OpenVINO na Intel GPU/NPU czy akcelerację NVIDIA. Coral nie przyspieszy LLM ani VLM.

Czy lokalny LLM może otwierać bramę po rozpoznaniu właściciela?
Technicznie można zbudować taką automatyzację, ale nie należy opierać kontroli dostępu wyłącznie na wyniku modelu generatywnego. Bezpieczniejszy układ wymaga dodatkowego warunku, np. obecności telefonu właściciela, BLE, geofencingu albo uwierzytelnienia użytkownika.

Ile miejsca zajmuje lokalny monitoring?
Przy czterech kamerach generujących średnio po 4 Mb/s ciągły zapis to około 173 GB na dobę, czyli mniej więcej 1,2 TB na siedem dni. Rzeczywiste zużycie zależy od kodeka, bitrate’u, liczby kamer oraz tego, czy zapis jest ciągły czy zdarzeniowy.

Od czego zacząć, jeśli system ma być prywatny od pierwszego dnia?
Od sprawdzenia kamery bez internetu. Włącz RTSP/ONVIF, odetnij urządzeniu WAN i zobacz, czy Frigate nadal odbiera obraz. Jeśli monitoring przestaje działać po utracie połączenia z serwerem producenta, rozwiąż ten problem albo wybierz inną kamerę zanim zaczniesz kupować sprzęt do lokalnego AI.

Więcej informacji na: https://househub.pl