Lokalny model AI w centrali monitoringu – jak wyszukiwać zdarzenia z kamer naturalnym językiem bez wysyłania nagrań do chmury?

Operator monitoringu nie powinien przewijać sześciu godzin nagrania tylko po to, żeby znaleźć moment, w którym pod magazyn podjechał biały bus, kierowca wysiadł i zostawił paczkę przy bramie. Dobrze zbudowany lokalny system AI pozwala wpisać: „biały bus zatrzymał się przy bramie nr 2 po godz. 18:00, ktoś wysiadł od strony kierowcy” i w kilka–kilkanaście sekund dostać listę najbardziej pasujących zdarzeń.

Najważniejsze jest jednak słowo „lokalny”. Obraz z kamer może pozostać w centrali monitoringu, serwerowni zakładu albo wydzielonej sieci klienta. Do internetu nie trzeba wysyłać ani pełnych nagrań, ani miniaturek, ani opisów scen. To istotne nie tylko z punktu widzenia RODO, tajemnicy przedsiębiorstwa czy polityki bezpieczeństwa. W praktyce oznacza również, że wyszukiwarka działa przy awarii łącza, nie generuje opłat za każdą przeanalizowaną godzinę materiału i może indeksować nagrania z kilkudziesięciu kamer bez uzależniania działania systemu od zewnętrznej usługi.

Trzeba jednak dobrze ustawić oczekiwania. Lokalny model nie „ogląda” bez przerwy wszystkich kamer tak jak człowiek. Najbardziej racjonalna architektura wygląda inaczej: klasyczna analityka wykrywa ruch, ludzi i pojazdy, z istotnych fragmentów powstają klatki lub krótkie zdarzenia, model zamienia ich treść na wektory semantyczne, a wyszukiwarka porównuje je później z pytaniem operatora. Większy model multimodalny uruchamia się dopiero tam, gdzie potrzebny jest dokładniejszy opis sceny. Dzięki temu koszt sprzętu i pobór energii nie wymykają się spod kontroli.

Jak z nagrania powstaje wyszukiwarka, która rozumie „człowiek z czerwoną torbą przy bramie”

Najczęstszy błąd projektowy polega na próbie przepuszczania pełnego strumienia 25 kl./s z każdej kamery przez duży model vision-language. Technicznie można zbudować bardzo mocny serwer, który będzie próbował to robić. Ekonomicznie zwykle nie ma to sensu.

Przy 32 kamerach oznaczałoby to analizę nawet 800 klatek na sekundę. Zdecydowana większość tych obrazów pokazuje niemal dokładnie to samo, co klatka poprzednia. Operator nie potrzebuje 25 opisów tej samej osoby przechodzącej przez parking.

W instalacji, która ma działać stabilnie, przetwarzanie warto rozdzielić na kilka etapów.

Najpierw rejestrator lub warstwa analityczna odbiera strumienie RTSP/ONVIF z kamer. W zależności od infrastruktury mogą to być urządzenia Axis, Hanwha Vision, Hikvision, Dahua, Bosch czy inne kamery współpracujące z VMS-em. Nie ma potrzeby wymiany całego systemu CCTV tylko dlatego, że dokładamy wyszukiwanie semantyczne.

Drugi etap to lekka detekcja:

• człowiek,

• samochód,

• ciężarówka,

• rower,

• motocykl,

• zwierzę,

• ruch w określonej strefie.

Taki model powinien działać praktycznie cały czas. Jego zadaniem nie jest opisanie sceny, lecz odpowiedź: „czy dzieje się tu coś, co warto dalej indeksować?”

Dopiero wtedy zapisuje się klatkę kluczową, serię kilku klatek albo kilkusekundowy fragment zdarzenia. Obraz trafia do modelu typu CLIP/SigLIP lub innego modelu multimodalnych embeddingów, który zamienia go na ciąg liczb reprezentujących znaczenie wizualne sceny.

Przykładowo Jina CLIP v2 tworzy wektor do 1024 wymiarów i obsługuje wyszukiwanie tekst–obraz w wielu językach. To istotne w Polsce: nie trzeba zmuszać operatora do wpisywania „man wearing red jacket near entrance”. Zapytanie „mężczyzna w czerwonej kurtce przy wejściu” może zostać porównane bezpośrednio z indeksowanymi obrazami.

Sam indeks zajmuje niewiele miejsca. Wektor 1024-elementowy przechowywany jako wartości FP32 to około 4 kB. Jeśli system zapisuje średnio jedno zdarzenie na minutę z każdej z 32 kamer, powstaje około 46 tys. wpisów dziennie. Surowe wektory zajmą wtedy mniej więcej 180–190 MB dziennie. Do tego dochodzą miniatury, identyfikatory nagrań, czas, kamera, strefa i ewentualne opisy tekstowe, ale nadal są to wartości małe w porównaniu z archiwum wideo.

Dla porównania: 32 kamery generujące strumień po 4 Mb/s produkują łącznie około 1,38 TB nagrań na dobę. Czternaście dni retencji to już około 19 TB danych, bez zapasu na system plików, redundancję czy materiał z dodatkowych strumieni.

Dlatego nie powinno się kopiować pełnego archiwum CCTV do osobnej bazy AI. Indeks powinien przechowywać odnośnik do właściwego materiału w VMS/NVR:

kamera 17 → 18:42:31 → zdarzenie 12 sekund → rekord 984521.

Wynik wyszukiwania prowadzi operatora bezpośrednio do właściwego fragmentu nagrania.

Do przechowywania embeddingów można wykorzystać m.in. PostgreSQL z pgvector, Qdrant, Milvus albo OpenSearch. W małej instalacji dodatkowy wyspecjalizowany klaster bazodanowy jest zbędny. PostgreSQL z pgvector spokojnie wystarcza do prototypów i wielu systemów obejmujących setki tysięcy czy kilka milionów zdarzeń.

Kolejna warstwa to reranking lub lokalny model vision-language, który sprawdza najlepiej dopasowane wyniki. Tu można zastosować większy model, np. rodzinę Qwen3-VL, jeśli licencja i wymagania sprzętowe konkretnego wariantu odpowiadają projektowi.

To właśnie ten drugi etap pozwala rozróżnić zapytania:

„osoba stoi obok samochodu”

od:

„osoba wyjmuje przedmiot z bagażnika samochodu”.

Model embeddingowy dobrze odnajduje sceny podobne znaczeniowo, ale nie jest niezawodnym systemem rozumowania. Duży model multimodalny potrafi ocenić relacje między obiektami dokładniej, tyle że zużywa znacznie więcej pamięci GPU i czasu.

W praktyce najlepiej działa więc układ:

detekcja → klatka kluczowa → embedding → wyszukiwanie wektorowe → opcjonalna weryfikacja przez VLM → odtworzenie nagrania.

Taka konstrukcja ma jeszcze jedną zaletę: łatwo ją odseparować od internetu. Modele można wcześniej pobrać, zweryfikować, przenieść do serwerowni i uruchamiać w środowisku air-gapped. Po wdrożeniu centrala monitoringu nie musi mieć dostępu do żadnego API AI.

Ile kosztuje lokalne AI do monitoringu i jak dobrać serwer, żeby nie przepłacić

Najpierw trzeba ustalić, co dokładnie ma być analizowane. Liczba kamer sama w sobie jest słabym parametrem doboru sprzętu. Znacznie ważniejsze są:

• liczba zdarzeń na minutę,

• rozdzielczość klatek przekazywanych do AI,

• częstotliwość indeksowania,

• wykorzystanie modelu generującego opisy,

• wymagana liczba równoczesnych zapytań,

• czas, w którym nowy materiał ma pojawić się w wyszukiwarce.

Dla kilkunastu kamer nie zaczynałbym od profesjonalnego GPU za kilkadziesiąt tysięcy złotych. Proof of concept można uruchomić na jednej mocnej karcie konsumenckiej, a dopiero pomiary z realnych kamer pokażą, czy potrzebna jest większa maszyna.

W polskich sklepach we wrześniu 2026 r. karty GeForce RTX 5080 16 GB kosztują mniej więcej 6–8 tys. zł brutto. 16 GB VRAM wystarcza do modeli embeddingowych oraz części mniejszych modeli multimodalnych, szczególnie po kwantyzacji. Problem pojawia się wtedy, gdy chcemy jednocześnie wykonywać dużo opisów scen większym VLM-em.

RTX 5080 pobiera do około 360 W, więc cały serwer przy mocnym obciążeniu może pobierać mniej więcej 500–700 W zależnie od CPU, dysków i reszty konfiguracji.

Klasa wyżej to GPU z 32 GB pamięci, np. GeForce RTX 5090. Większa pamięć daje znacznie więcej swobody przy lokalnych modelach multimodalnych, ale karta ma maksymalny pobór około 575 W, a producent zakłada zasilacz klasy około 1000 W dla typowej stacji roboczej. To nie jest sprzęt, który chciałbym stawiać w małej, niewentylowanej szafie teletechnicznej obok rejestratora i UPS-a.

Do pracy 24/7 w środowisku przedsiębiorstwa dochodzi jeszcze kwestia konstrukcji chłodzenia, gwarancji, sterowników i przewidywalności konfiguracji. Tu zaczynają mieć sens karty profesjonalne.

NVIDIA RTX 6000 Ada 48 GB kosztuje obecnie w Polsce około 36–42 tys. zł brutto. Nowsza RTX PRO 6000 Blackwell 96 GB to już mniej więcej 92–100 tys. zł, zależnie od dostawcy. Ma 96 GB pamięci GDDR7 ECC i pobór do 600 W.

Czy do wyszukiwania człowieka z torbą na 20 kamerach potrzebna jest karta za 100 tys. zł? Nie. Byłby to zakup trudny do obrony.

Taki sprzęt zaczyna mieć sens, kiedy jedna centrala ma obsługiwać dużą liczbę kamer, wiele równoległych procesów AI lub większe modele VLM, a klient wymaga sprzętu klasy workstation/server i dużego zapasu VRAM.

Dla instalacji rzędu 16–32 kamer sensowny serwer pilotażowy wygląda raczej tak:

• CPU klasy Ryzen 9, Intel Core Ultra z wyższej półki lub serwerowy Xeon/EPYC, jeśli wymagane są platformowe funkcje enterprise;

• 64 GB RAM jako rozsądne minimum, 128 GB przy większym środowisku;

• GPU z 16–32 GB VRAM;

• dysk NVMe 1–2 TB na system, bazę i cache;

• drugi dysk lub macierz zgodnie z polityką redundancji;

• karta sieciowa 2,5/10 GbE przy większym ruchu;

• Ubuntu Server lub inna wspierana dystrybucja Linux;

• Docker/Podman albo wdrożenie bezpośrednie, zależnie od polityki IT.

Cała stacja z RTX 5080 może zamknąć się mniej więcej w 12–18 tys. zł brutto. Mocniejsza konfiguracja z GPU 32 GB i serwerowym zapasem pamięci będzie raczej kosztować 20–35 tys. zł. Sprzęt profesjonalny z 48–96 GB VRAM przesuwa budżet w okolice 50–120 tys. zł i więcej.

Do tego trzeba doliczyć integrację. Open-source nie oznacza darmowego wdrożenia.

Sam Frigate może realizować lokalne wyszukiwanie semantyczne i przechowywać embeddingi na miejscu, ale jego użycie jako kompletnej platformy dla profesjonalnej centrali monitoringu wymaga oceny zakresu funkcji, redundancji, audytu dostępu i integracji z istniejącym VMS-em. To świetne narzędzie do prototypowania i części zastosowań, lecz nie należy zakładać, że automatycznie zastąpi Milestone XProtect, Genetec Security Center czy rozbudowany system operatorski.

Najdroższy bywa nie GPU, lecz dopracowanie integracji:

• automatyczne pobieranie klatek z VMS,

• mapowanie kamer i stref,

• uprawnienia użytkowników,

• logi audytowe,

• retencja indeksu,

• synchronizacja czasu,

• HA,

• monitoring działania modeli,

• aktualizacje bez rozbijania środowiska produkcyjnego.

W prostym pilotażu warto przyjąć kilka–kilkanaście dni pracy integracyjnej. Produkcyjny system połączony z istniejącą centralą, SSO/Active Directory, VMS-em i procedurami bezpieczeństwa może wymagać wielu tygodni.

Nie kupowałbym sprzętu docelowego przed testem na rzeczywistych nagraniach. To szczególnie ważne przy kamerach nocnych. Świetne wyniki na jasnym parkingu potrafią załamać się po zmroku przy odbiciach IR, kompresji H.265, rozmazaniu ruchu i osobie zajmującej 40 pikseli wysokości.

Model nie odzyska szczegółu, którego kamera nie zarejestrowała. AI nie naprawi złej optyki ani złego ustawienia kamery.

Prywatność zostaje lokalnie, ale RODO i AI Act nadal obowiązują

Hasło „nic nie wysyłamy do chmury” rozwiązuje kilka problemów, ale nie daje automatycznej zgodności z prawem.

Nagranie osoby, którą można zidentyfikować, nadal jest przetwarzaniem danych osobowych. Co więcej, również samo przeglądanie obrazu na żywo jest operacją przetwarzania. Lokalizacja serwera zmienia profil ryzyka i może znacząco ograniczyć ekspozycję danych, ale nie usuwa obowiązków administratora.

Przed uruchomieniem wyszukiwania AI trzeba więc ustalić, czy nowa funkcja jest zgodna z pierwotnym celem monitoringu.

Jeżeli kamery zamontowano w celu ochrony obiektu, a operator wykorzystuje AI do szybszego odnajdywania incydentów związanych z wejściem na teren, ruchem pojazdów czy pozostawieniem przedmiotów, funkcja pozostaje blisko celu bezpieczeństwa.

Znacznie gorzej wygląda pomysł:

„mamy już kamery, więc sprawdzajmy, kto z pracowników najczęściej wychodzi na papierosa”.

Technicznie to banalne. Prawnie i organizacyjnie może być bardzo problematyczne, ponieważ następuje zmiana sposobu wykorzystania monitoringu na obserwację zachowania pracowników.

Jeszcze większą ostrożność trzeba zachować przy biometrii.

Wyszukiwanie:

„osoba w żółtej kurtce”

nie jest tym samym co:

„znajdź Jana Kowalskiego na wszystkich kamerach na podstawie jego twarzy”.

W drugim przypadku system porównuje cechy biometryczne osoby z bazą referencyjną w celu ustalenia tożsamości. Wchodzi więc w obszar identyfikacji biometrycznej, który podlega znacznie ostrzejszym regulacjom niż zwykłe wyszukiwanie podobieństwa obrazu i tekstu.

To bardzo ważna granica projektowa. Jeżeli celem jest tylko szybkie wyszukiwanie zdarzeń, nie dodawałbym rozpoznawania twarzy „przy okazji”. Z technicznego punktu widzenia to kolejny moduł. Z prawnego — może całkowicie zmienić kwalifikację systemu i wymagania wobec organizacji.

AI Act wprowadza również wyraźne ograniczenia dotyczące części zastosowań biometrycznych. Zakazane są m.in. określone przypadki kategoryzowania ludzi na podstawie danych biometrycznych w celu wnioskowania o szczególnie wrażliwych cechach, takich jak poglądy polityczne, religia czy orientacja seksualna. Bardzo restrykcyjnie uregulowano również zdalną identyfikację biometryczną w czasie rzeczywistym w przestrzeni publicznie dostępnej dla celów ścigania przestępstw.

Nie należy też budować funkcji pokroju:

„pokaż pracowników wyglądających na zestresowanych albo zdenerwowanych”.

Rozpoznawanie emocji w miejscu pracy jest w UE co do zasady zakazane, poza określonymi wyjątkami związanymi m.in. z bezpieczeństwem lub zastosowaniami medycznymi.

Dobra lokalna wyszukiwarka CCTV powinna więc operować przede wszystkim na obiektywnych cechach sceny:

• kolor i typ ubrania;

• typ pojazdu;

• obecność przedmiotu;

• kierunek ruchu;

• wejście do określonej strefy;

• czynność widoczna na obrazie;

• czas i lokalizacja.

Nawet wtedy nie można traktować odpowiedzi modelu jak dowodu.

Jeśli operator wpisze „mężczyzna z łomem”, model może wskazać osobę trzymającą długi parasol, kij, statyw albo metalowy element. Wyszukiwanie semantyczne działa na podobieństwie. Nie daje gwarancji poprawnej interpretacji.

Dlatego wynik powinien wyglądać jak:

„10 najbardziej podobnych zdarzeń — sprawdź nagrania”,

a nie:

„AI wykryło sprawcę włamania”.

Nie ustawia się również alarmów bezpieczeństwa wyłącznie na podstawie progu podobieństwa tekst–obraz. Modele typu CLIP świetnie nadają się do eksploracyjnego wyszukiwania, ale wyniki podobieństwa potrafią być zbyt niestabilne, aby arbitralnie uznać np. wartość 0,72 za „pewne wykrycie człowieka z bronią”.

Jeżeli wyszukiwarka ma uruchamiać automatyczną reakcję, dokładam drugi warunek: klasyczny detektor, regułę strefową, dodatkowy model albo potwierdzenie operatora.

Przed wdrożeniem trzeba też zdecydować, co dokładnie przechowujemy. Jeśli archiwum CCTV jest kasowane po określonym czasie, indeks AI nie powinien żyć bez końca jako równoległy zapis historii osób poruszających się po obiekcie. Wraz z usunięciem nagrania powinien zostać usunięty odpowiadający mu rekord, miniatura i opis, chyba że istnieje jasno określona podstawa do ich dalszego przechowywania.

Dla środowiska produkcyjnego ustawiłbym jako minimum:

• brak dostępu serwera AI do internetu poza kontrolowanym oknem administracyjnym albo całkowity air gap;

• szyfrowanie dysków;

• indywidualne konta operatorów;

• role ograniczające dostęp do konkretnych kamer;

• rejestrowanie zapytań i odtworzeń;

• synchronizację czasu przez kontrolowany NTP;

• automatyczne kasowanie indeksów razem z materiałem źródłowym;

• osobne konto serwisowe do komunikacji z VMS;

• zakaz eksportowania miniaturek przez zwykłych operatorów;

• testy wyszukiwania wykonane na rzeczywistych kamerach dziennych i nocnych.

Pierwszym testem przed zakupem serwera nie powinien być benchmark GPU. Powinno nim być 50–100 prawdziwych zapytań operatorskich.

Przygotowałbym zestaw w rodzaju:

„biały dostawczak przy bramie nocą”,
„osoba z plecakiem idąca w kierunku hali”,
„samochód stojący dłużej przy ogrodzeniu”,
„człowiek niosący dwa kartony”,
„osoba w kamizelce odblaskowej obok ciężarówki”.

Następnie dla każdego zapytania trzeba zmierzyć, czy właściwe zdarzenie pojawia się w top 5 lub top 10 wyników. Jeśli system daje dobry rezultat przy 80–90 proc. typowych zapytań, operator faktycznie oszczędzi czas. Jeżeli regularnie pokazuje przypadkowe sceny, dokładanie większego modelu nie zawsze jest rozwiązaniem. Często trzeba poprawić sposób wybierania klatek, strefy kamer, jakość obrazu albo sam sposób indeksowania.

Dopiero po takim teście dobierałbym sprzęt docelowy.

FAQ

Czy lokalny model AI musi mieć dostęp do internetu?
Nie. Po pobraniu modeli, bibliotek i kontenerów cały proces — analiza klatek, generowanie embeddingów, baza wektorowa i wyszukiwanie — może działać w sieci lokalnej bez dostępu do internetu. Aktualizacje można dostarczać kontrolowanym kanałem lub ręcznie.

Czy system może przeszukiwać stare nagrania?
Tak, ale materiał musi zostać najpierw zindeksowany. Przy dużym archiwum pierwsze indeksowanie może mocno obciążyć CPU/GPU i trwać wiele godzin lub dni, dlatego najlepiej wykonywać je partiami poza szczytem pracy systemu.

Czy trzeba wymienić istniejące kamery?
Najczęściej nie. Jeżeli VMS lub rejestrator pozwala pobierać strumienie albo klatki z kamer, warstwę AI można dołożyć obok obecnego systemu. Problemy zaczynają się przy zamkniętych, producentowych rozwiązaniach bez API lub dostępu RTSP.

Czy można wyszukiwać po polsku?
Tak, pod warunkiem zastosowania modelu embeddingowego obsługującego język polski lub warstwy tłumaczącej zapytania. W praktyce lepiej wybrać model wielojęzyczny i nie dodawać tłumacza, który tworzyłby kolejne miejsce potencjalnych błędów.

Czy do takiego systemu potrzebna jest karta graficzna?
Do niewielkiego prototypu nie zawsze. Niektóre modele embeddingowe działają na CPU, a Frigate podaje minimum 8 GB RAM i procesor z AVX/AVX2 dla wyszukiwania semantycznego. Przy systemie używanym produkcyjnie na wielu kamerach GPU zdecydowanie poprawia jednak czas indeksowania i responsywność.

Czy AI znajdzie konkretną osobę bez rozpoznawania twarzy?
Może znaleźć sceny odpowiadające opisowi, np. „osoba w granatowej kurtce z czerwonym plecakiem”, ale nie powinno się na tej podstawie twierdzić, że to konkretny człowiek. Identyfikacja osoby na podstawie cech biometrycznych jest inną funkcją i wymaga odrębnej oceny prawnej.

Czy lokalne AI oznacza pełną zgodność z RODO?
Nie. Lokalność ogranicza transfer danych do podmiotów zewnętrznych i zmniejsza część ryzyk, ale nadal przetwarzane są dane z monitoringu. Trzeba określić cel, podstawę przetwarzania, retencję, dostęp, obowiązki informacyjne i sposób usuwania danych.

Od czego najlepiej zacząć wdrożenie?
Nie od zakupu drogiego GPU. Najpierw wybierz 4–8 reprezentatywnych kamer, zindeksuj kilka dni materiału i przygotuj około 100 zapytań odpowiadających rzeczywistej pracy operatorów. Dopiero gdy system regularnie znajduje prawidłowe zdarzenie w pierwszych kilku wynikach, warto zwiększać liczbę kamer i kupować docelowy serwer. Najdroższy błąd w takim projekcie to postawienie mocnej infrastruktury zanim ktokolwiek sprawdzi, czy AI rzeczywiście rozumie obrazy z konkretnych kamer.