Jak przygotować infrastrukturę IT pod projekty AI w zakładach przemysłowych

Dlaczego projekty AI w przemyśle rozbijają się o infrastrukturę

Ambicje AI kontra realia zakładowego IT i OT

Większość rozmów o sztucznej inteligencji w zakładach przemysłowych zaczyna się podobnie: predykcyjne utrzymanie ruchu, optymalizacja parametrów procesu, automatyczna kontrola jakości na kamerach, inteligentne planowanie produkcji. Na poziomie zarządu i prezentacji wszystko wygląda prosto – są dane, są algorytmy, więc „wystarczy to połączyć”.

Zderzenie następuje wtedy, gdy pierwszy poważniejszy projekt AI ma opuścić dział R&D i wejść na halę. Nagle okazuje się, że:

• dane z czujników nie są nigdzie archiwizowane, tylko „przelatują” przez SCADA,
• każda linia ma innego producenta sterowników i inne nazewnictwo tagów,
• sieć na hali jest łataną przez lata mieszanką switchy, bez segmentacji i bez gwarancji przepustowości,
• serwerownia ma wolne miejsce na jednym przeciążonym serwerze plików, ale nie na trenowanie modeli AI,
• dział IT boi się podłączać coś nowego do sieci produkcyjnej, a dział utrzymania ruchu boi się wszystkiego, co może „dotknąć PLC”.

Na tym tle nawet dobrze przygotowany model AI, który działał na danych z eksportu CSV, przestaje mieć znaczenie. Bez stabilnej, zaprojektowanej pod dane i obliczenia infrastruktury IT projekt kończy się na poziomie prezentacji.

Proof of concept na laptopie a system 24/7

PoC w przemyśle często wygląda tak: inżynier lub zewnętrzny dostawca zbiera paczkę danych z kilku tygodni, uruchamia model na swoim laptopie lub w chmurze, generuje ciekawe wykresy, pokazuje wysoką trafność predykcji. Sukces. Problem zaczyna się, gdy trzeba to zamienić w system działający:

• na żywych danych,
• z opóźnieniem liczonym w sekundach czy milisekundach,
• bez przestojów,
• w realnym środowisku sieciowym i sprzętowym zakładu.

Proof of concept korzysta z „idealnych” danych już zebranych, często oczyszczonych ręcznie. System produkcyjny musi:

• sam pobrać dane z różnych źródeł (SCADA, PLC, MES, czujniki IoT, bazy jakości),
• poradzić sobie z brakami odczytów, różnymi częstotliwościami próbkowania, błędnymi timestampami,
• mieć zagwarantowaną moc obliczeniową do przetwarzania strumienia danych,
• pracować w architekturze zgodnej z polityką bezpieczeństwa IT/OT.

To przeskok z „sprytnego Excela” na poziom systemu krytycznego. Bez przygotowanej infrastruktury IT pod AI w przemyśle, taki przeskok staje się nieproporcjonalnie drogi albo wręcz niemożliwy.

Typowe ograniczenia w zakładach produkcyjnych

W wielu fabrykach pojawia się podobny zestaw problemów infrastrukturalnych:

• Stare sieci i brak segmentacji – ruch IT i OT miesza się na tych samych urządzeniach, VLAN-y są w szczątkowej formie, a niektóre odcinki sieci działają jeszcze na 100 Mb/s.
• Wyspy automatyki – każda linia to osobny świat: inne sterowniki, inne protokoły, brak wspólnego standardu tagów.
• Brak centralnej bazy danych procesowych – dane istnieją tylko w runtime sterownika lub SCADA, bez historycznej perspektywy.
• Ograniczone zasoby serwerowe – serwerownia jest zaprojektowana pod ERP, pliki, kilka aplikacji biznesowych, ale nie pod masowe przetwarzanie danych z maszyn.
• Chaotyczna archiwizacja – część danych zapisuje się w CSV na lokalnych dyskach operatorów, część w pojedynczych bazach MS SQL, część w logach aplikacji, do których nikt nie ma dostępu.

Te ograniczenia same w sobie nie uniemożliwiają AI. Uniemożliwiają natomiast budowanie projektów skalowalnych i powtarzalnych. Bez uporządkowania fundamentów, każdy kolejny projekt będzie wymagał „ręcznego” spięcia danych i sprzętu.

Myślenie w horyzoncie 3–5 lat, nie jednego pilota

Decyzje infrastrukturalne w zakładzie przemysłowym działają latami. Nowy serwer, macierz dyskowa, przebudowa sieci – to nie jest zakup na kwartał, tylko na 3–5 lat. Jeżeli cała architektura danych i obliczeń zostanie zaprojektowana tylko pod aktualny PoC, szybko pojawi się problem:

• kolejny zespół chce wdrożyć inną aplikację AI,
• dane z nowej linii nie pasują do dotychczasowego modelu,
• brakuje portów, mocy lub miejsca na przechowywanie nowych strumieni danych.

W efekcie trzeba dokupować sprzęt doraźnie, budując mozaikę niespójnych rozwiązań. Z budżetowego punktu widzenia oznacza to przepalanie pieniędzy na integrację i łatki, zamiast na świadome, etapowe budowanie infrastruktury IT pod AI w przemyśle.

Krótki przykład z praktyki: PoC uwięziony w R&D

Jeden z zakładów średniej wielkości przygotował model predykcyjnego utrzymania ruchu dla kluczowej sprężarki. Dane zebrano z PLC przez miesiąc, zapisano na laptopie inżyniera, przetworzono w Pythonie. Model wskazał kilka anomalii, które faktycznie korelowały z awariami – wszyscy byli zadowoleni.

Kiedy pojawiło się zadanie uruchomienia tego modelu „na żywo”:

• okazało się, że PLC nie jest podłączone do sieci zakładowej, tylko do osobnego switcha „od automatyki”,
• nie było żadnej serwerowni przy linii, więc podłączenie laptopa jako „serwera AI” było nie do przyjęcia dla IT,
• łącze zakładu z internetem nie zapewniało stabilnego połączenia do chmury z akceptowalną latencją,
• dział bezpieczeństwa zablokował transfer danych produkcyjnych poza zakład bez analizy ryzyka.

Finalnie projekt został zamknięty jako „ciekawy, ale trudny do wdrożenia na obecnej infrastrukturze”. Problem nie leżał w AI, lecz w braku przygotowania sieci, architektury danych i warstwy obliczeniowej. Takich historii można znaleźć w przemyśle bardzo wiele.

Ocena punktu wyjścia – co już masz i co naprawdę jest potrzebne

Inwentaryzacja sprzętu i systemów w zakładzie

Zanim pojawi się dyskusja o serwerach GPU na hali produkcyjnej i chmurze hybrydowej, trzeba dokładnie policzyć to, co już istnieje. W wielu firmach stoi sporo niewykorzystanego sprzętu, a jednocześnie brakuje prostego podglądu, gdzie i jak można go wykorzystać pod projekty AI.

Podstawowa inwentaryzacja obejmuje:

• Serwery i storage – typy maszyn, liczba rdzeni, ilość RAM, rodzaj dysków (HDD/SSD), wolna przestrzeń, możliwości rozbudowy (sloty PCIe, wolne zatoki), używane hypervisory.
• Sieć – topologia, przepustowości (1G, 10G), obecność VLAN-ów, sprzęt sieciowy na hali (switche przemysłowe, routery), łącza do internetu i między lokalizacjami.
• Komputery przemysłowe przy liniach – IPC, panele operatorskie, lokalne serwery linii, do jakich sieci są podłączone, jakie mają systemy operacyjne.
• Systemy nadrzędne – SCADA, MES, ERP, CMMS, systemy jakości, bazy danych laboratoryjnych, wraz z informacją, jakie dane wystawiają i w jakiej formie.

Najprostsza forma to arkusz lub bazowa dokumentacja z kilkoma kluczowymi polami. Bez przesadnych szczegółów – ważna jest użyteczność: które zasoby da się w rozsądny sposób wykorzystać do zbierania i przetwarzania danych dla AI, a które są „nietykalne” (np. sprzęt podtrzymujący krytyczne systemy ERP).

Mapa przepływu danych produkcyjnych

Kolejny krok to zrozumienie, jak biegną dane przez zakład. Chodzi o praktyczną mapę, a nie piękną grafikę marketingową. Dla projektów AI kluczowe są przede wszystkim:

• dane z sensorów i PLC (prądy, temperatury, przepływy, stany binarne),
• dane z systemów procesowych (SCADA, DCS),
• dane jakościowe (pomiarowe, laboratoryjne, wyniki inspekcji),
• dane z serwisu i utrzymania ruchu (awarie, przestoje, interwencje),
• dane z systemów planistycznych (MES, APS, ERP).

Warto odpowiedzieć sobie na kilka prostych pytań:

• Skąd wychodzą dane (konkretny system, linia, sterownik)?
• W jakiej postaci istnieją – baza SQL, pliki CSV, logi tekstowe, API, OPC UA?
• Gdzie aktualnie lądują i kto ma do nich dostęp?
• Jak długo są przechowywane i czy istnieje historia?

Mapa przepływu danych pozwala wychwycić najtańsze „punkty zaczepienia” dla pierwszych projektów AI: często wystarczy wyciągnąć dane z już istniejącego systemu SCADA lub MES, zamiast budować od zera rozbudowane IoT. To szczególnie ważne z perspektywy budżetowego pragmatyzmu.

Identyfikacja wąskich gardeł w danych

Na podstawie mapy przepływu można wskazać miejsca, które najbardziej utrudnią wdrożenie AI:

• Brak archiwizacji danych historycznych – SCADA przechowuje dane tylko z kilku dni lub tygodni; do trenowania modeli potrzeba miesięcy.
• Zbyt mało miejsca na logi – serwer bazy danych co chwilę się zapycha, przez co część odczytów jest tracona.
• Brak standaryzacji tagów – ten sam parametr w różnych liniach ma inne nazwy i jednostki, co utrudnia skalowanie modeli.
• Ręczne eksporty – dane są dostępne tylko, gdy ktoś raz na jakiś czas wyeksportuje pliki i wyśle e-mailem.

Nie chodzi o to, żeby od razu rozwiązać wszystkie problemy. Wystarczy wskazać te, które blokują projekty AI o największym potencjale biznesowym. Często jeden niewielki upgrade storage’u lub konfiguracji SCADA otwiera drogę do sensownej archiwizacji danych dla kilku linii.

Rozróżnienie potrzeb MVP a docelowej architektury

Dobrym podejściem jest rozdzielenie:

• MVP (minimum viable product) dla AI – co jest absolutnie konieczne, aby przeprowadzić pilota na rzeczywistych danych w warunkach zbliżonych do produkcji,
• Architektury docelowej – jak ma wyglądać infrastruktura IT pod AI w przemyśle, gdy takich projektów będzie kilka lub kilkanaście równocześnie.

Przykład:

• Dla MVP predykcyjnego utrzymania ruchu może wystarczyć: jeden serwer z bazą danych czasowych, prosty agent zbierający dane z wybranych PLC, proste API dla modelu.
• Dla docelowej architektury, która ma obsłużyć różne linie i hale, potrzeba: skalowalnej bazy time-series, uporządkowanej nomenklatury tagów, centralnego repozytorium danych, automatycznego backupu.

Rozpisanie obu poziomów ułatwia obronę budżetu: część inwestycji można odłożyć, a część zrealizować małymi krokami, tak aby każdy etap dawał realną wartość, a jednocześnie budował fundament pod większą całość.

Prosty sposób szacowania minimalnych wymagań sprzętowych

Na start nie ma sensu tworzyć skomplikowanych modeli obciążenia. W większości zakładów można podejść do tego pragmatycznie, opierając się na kilku parametrach:

• Liczba sygnałów i częstotliwość próbkowania – np. 500 tagów z częstotliwością 1 Hz to ok. 500 odczytów na sekundę, co w ujęciu dziennym daje już pokaźny wolumen.
• Retencja danych – ile czasu dane mają być trzymane w szybkim storage (np. rok) i kiedy mogą zostać przeniesione na wolniejsze, tańsze dyski lub do chmury.
• Liczba równoległych modeli / aplikacji AI – jedna aplikacja predykcyjna z aktualizacją co kilka minut vs kilkanaście równoległych zadań.

Na tej podstawie można przyjąć konserwatywne założenia:

• na każdy projekt AI MVP z kilkuset tagami i jednym modelem predykcyjnym wystarczy zwykle 8–16 rdzeni CPU, 32–64 GB RAM i kilkaset GB szybkiego storage’u,
• dodatkowo do trenowania bardziej złożonych modeli warto przewidzieć dostęp do GPU lokalnie lub w chmurze.

To bardzo uproszczone liczby, ale pomagają odróżnić, kiedy da się zacząć od istniejącego serwera, a kiedy naprawdę konieczna jest inwestycja w nową maszynę. W razie wątpliwości lepiej przewymiarować o 20–30% niż każdą drobną zmianę załatwiać upgradem sprzętu.

Dane jako fundament – jak przygotować architekturę danych pod AI

Jakie dane z zakładu są najważniejsze dla AI

W projektach AI w przemyśle powtarza się kilka głównych kategorii danych:

Priorytetowe źródła danych dla pierwszych projektów

Zamiast próbować objąć cały zakład, lepiej zawęzić się do kilku źródeł, które najszybciej dadzą efekt biznesowy i są technicznie dostępne bez wielkiej rewolucji. Typowo będą to:

• SCADA / DCS – zazwyczaj już zbiera większość kluczowych sygnałów procesowych; często ma też własny archiwizator, którego możliwości nie są w pełni wykorzystywane.
• PLC / sterowniki maszyn – szczególnie tam, gdzie SCADA nie obejmuje pełnego zakresu sygnałów lub częstotliwości próbkowania.
• System CMMS / utrzymanie ruchu – informacje o awariach, przestojach, wymianach części, interwencjach serwisu.
• Systemy jakości i laboratorium – wyniki inspekcji, pomiary jakościowe, odrzuty, reklamacje.

Z reguły nie ma sensu na start inwestować w rozbudowane IoT z tysiącami nowych czujników. Tańszym krokiem jest wyciągnięcie lepszej wartości z tego, co już jest mierzone – nawet jeśli wymaga to kilku prostych integracji lub konfiguracji archiwizacji.

Porządkowanie danych u źródła zamiast „magii” po stronie AI

Częsty błąd to próba ratowania bałaganu w danych po stronie zespołu data science. Efekt: duże koszty pracy, trudna utrzymalność, problemy przy każdym kolejnym rozszerzeniu projektu. Znacznie bardziej opłaca się:

• uzgodnić spójne nazewnictwo tagów (przynajmniej dla linii/obszaru objętego projektem),
• ustalić jednostki pomiarowe i unikać sytuacji, gdzie ta sama wielkość występuje raz w barach, raz w kPa, raz w „% zakresu”,
• na poziomie SCADA/PLC wprowadzić proste walidacje (np. zakresy dopuszczalne, wartości domyślne przy błędach komunikacji),
• oddzielić sygnały pomiarowe od sygnałów czysto diagnostycznych / serwisowych.

Każda godzina włożona w uporządkowanie danych u źródła oszczędza później wielokrotność czasu i budżetu po stronie modeli. To nie jest „ładna teoria”, tylko bardzo wymierna różnica w kosztach utrzymania rozwiązania produkcyjnego.

Minimalistyczna warstwa pośrednia – prosty „data hub” dla AI

Zamiast zaczynać od pełnego „data lake’a” czy drogiej platformy danych, często wystarczy niewielki, ale dobrze przemyślany „hub” danych dla AI. Może to być:

• lekka baza danych szeregów czasowych (np. InfluxDB, TimescaleDB) zasilana z kilku kluczowych źródeł,
• prosty broker komunikatów (np. MQTT, Kafka w małej instancji) jako bufor między systemami OT a warstwą analityczną,
• kilka skryptów ETL lub lekkie narzędzie integracyjne do zrzucania danych z SCADA / CMMS w sposób powtarzalny.

Zadaniem takiego huba nie jest objęcie wszystkich danych firmy, tylko:

• udostępnienie spójnego miejsca, z którego korzystają modele AI,
• odseparowanie świata OT (sterowniki, sieć produkcyjna) od świata IT/AI,
• zapewnienie podstawowych funkcji: retencja danych, backup, logowanie dostępu.

To rozwiązanie można budować na istniejącej infrastrukturze – często wystarczy jeden serwer (fizyczny lub VM) w serwerowni zakładowej, dobrze spięty z siecią produkcyjną.

Standardy integracji – na czym oszczędzać, a gdzie nie ciąć kosztów

Przy integracji danych pojawia się pokusa „tanich skrótów”: szybki eksport CSV na udział sieciowy, ręczne zaciąganie plików do Pythona, itp. Na etapie PoC może to mieć sens, ale przy pierwszym poważniejszym wdrożeniu staje się kulą u nogi. Rozsądny kompromis obejmuje:

• OPC UA jako podstawowy standard do odczytu danych z PLC/SCADA – nie zawsze trzeba kupować drogie serwery; często wystarczą lekkie bramki lub licencje na wybrane linie.
• REST / gRPC do integracji z aplikacjami AI – pozwala w prosty sposób skalować i przenosić modele.
• Konwencja nazewnictwa dla API i struktur danych – nawet prosta, ale dokumentowana i przestrzegana.

Osłabianie standardów na poziomie protokołów zwykle kończy się dodatkowymi kosztami przy każdym kolejnym projekcie. Oszczędności lepiej szukać w skali wdrożenia (na ilu liniach, jak często próbkujemy dane), a nie w fundamentach integracji.

Zarządzanie jakością danych – podejście „good enough”

Perfekcyjna jakość danych jest droga i często niepotrzebna. Dla większości modeli predykcyjnych w zupełności wystarczy podejście „wystarczająco dobre”, jeśli jest świadomie zdefiniowane. Praktycznie oznacza to:

• zamiast usuwać wszystkie „brudne” dane, oznaczanie ich flagami jakości (np. brak kalibracji, awaria sensora, praca w trybie ręcznym),
• utrzymanie prostych monitorów spójności (np. alarm, gdy pojawia się zbyt wiele wartości zerowych lub stałych przez dłuższy czas),
• jasne ustalenie, że korekcje ręczne (np. zmiany w CMMS po czasie) są możliwe, ale logowane i nie usuwają oryginalnych zapisów.

To podejście chroni przed dwoma skrajnościami: paraliżem decyzyjnym („dopóki dane nie będą idealne, nie zaczynamy z AI”) oraz ślepą wiarą w każdy rekord („model sobie poradzi”). Koszt wdrożenia prostych zasad jest niski, a wpływ na jakość modeli – bardzo istotny.

Architektura danych a bezpieczeństwo i regulacje

W zakładach przemysłowych dane procesowe często są traktowane jak tajemnica handlowa. Do tego dochodzą wymagania prawne (np. branża spożywcza, farmacja, chemia). Z tego powodu przy budowie architektury danych pod AI trzeba od razu:

• podzielić dane na strefy wrażliwości (np. pełne dane produkcyjne, dane zanonimizowane, dane syntetyczne do testów),
• zdefiniować role i dostęp – kto może czytać dane surowe, kto tylko zagregowane, kto zarządza kopiami testowymi,
• ustalić reguły transferu poza zakład – jakie dane i w jakiej formie mogą trafić do chmury lub do partnerów zewnętrznych.

Zrobienie tego od początku w prosty, ale klarowny sposób oszczędza nerwów przy każdej kolejnej dyskusji z działem bezpieczeństwa czy audytorem. Jednocześnie pozwala świadomie zdecydować, które elementy architektury trzymamy on-prem, a które można spokojnie wyprowadzić poza zakład.

Edge, on-premises czy chmura – dobór modelu obliczeń pod zakład przemysłowy

Kluczowe kryteria wyboru modelu obliczeń

Zamiast zaczynać od technologii („chcemy iść w chmurę” albo „wszystko musi zostać na zakładzie”), lepiej zacząć od kilku prostych pytań:

• Wymogi czasowe – jak szybko model ma reagować? Milisekundy, sekundy, minuty?
• Wrażliwość danych – co się stanie, jeśli surowe dane procesowe opuszczą zakład?
• Dostępność łącza – jak wygląda realna jakość internetu w halach, a nie deklaracje operatora?
• Budżet CAPEX vs OPEX – czy firma woli inwestować w sprzęt, czy płacić za usługę w czasie?

Odpowiedzi naturalnie kierują w stronę edge, on-premises lub chmury – często sensowne jest połączenie tych modeli, a nie kurczowe trzymanie się jednego.

Kiedy ma sens edge computing przy maszynie

Uruchamianie modeli na poziomie linii lub pojedynczej maszyny jest uzasadnione, gdy:

• liczy się bardzo niska latencja (np. detekcja defektu na kamerze wizyjnej przed odrzutem elementu),
• łącze do serwerowni lub chmury jest niestabilne lub jego awaria nie może zatrzymać procesu,
• nie chcemy lub nie możemy wysyłać pełnego strumienia danych (np. obrazów) poza lokalną sieć maszyny.

Edge nie musi oznaczać drogich urządzeń. W wielu przypadkach wystarczy:

• komputer przemysłowy (IPC), który i tak już stoi przy maszynie, minimalnie doposażony w RAM/dysk,
• mały moduł typu NVIDIA Jetson lub podobny akcelerator, jeśli pojawia się wizja lub cięższe modele.

Modele na edge warto utrzymywać możliwie proste (np. przetrenowane w chmurze lub on-prem i tylko wykonywane na urządzeniu), tak aby aktualizacje były rzadkie, a zarządzanie nimi nie wymagało armii specjalistów.

On-premises – kiedy własna serwerownia wygrywa z chmurą

Lokalna infrastruktura obliczeniowa ma sens, gdy:

• produkcja działa w trybie 24/7 i wymaga przewidywalnego czasu reakcji bez zależności od internetu,
• dane są traktowane jako ściśle poufne i ich wyprowadzenie do chmury jest politycznie lub formalnie niemożliwe,
• firma ma już solidną serwerownię i kompetencje IT, które można wykorzystać bez dużych dodatkowych kosztów.

Nie trzeba od razu budować klastra z kilkunastoma serwerami GPU. Pragmatyczny start to:

• jeden lub dwa mocniejsze serwery z możliwością rozbudowy (wolne sloty PCIe, przestrzeń na dyski),
• wirtualizacja (VMware, Proxmox, Hyper-V), aby wydzielić środowiska dla AI obok istniejących systemów,
• jasno określone SLA wewnętrzne – jaki czas niedostępności jest akceptowalny dla modeli AI.

Koszty on-prem są głównie CAPEX (zakup sprzętu) i utrzymanie (energia, chłodzenie, praca administratorów). Przy stałym, przewidywalnym obciążeniu i długim horyzoncie korzystania może to być tańsze niż chmura, szczególnie jeśli serwery wykorzystuje się także do innych zadań (backup, wirtualne maszyny, raportowanie).

Chmura – gdzie naprawdę daje przewagę

Usługi chmurowe najlepiej sprawdzają się tam, gdzie:

• obciążenie mocno się zmienia (intensywne trenowanie modeli raz na jakiś czas, a potem spokojny okres eksploatacji),
• potrzebne są specjalistyczne zasoby (np. nowoczesne GPU, duże klastry, narzędzia MLOps),
• łączność zakładu z internetem jest stabilna i przepustowa, a przesyłanie danych nie łamie polityk bezpieczeństwa.

Dobry kompromis to:

• trening modeli w chmurze na zanonimizowanych lub odpowiednio przygotowanych danych,
• inferencja (wykonywanie modeli) lokalnie – w serwerowni lub na edge, z ograniczonym ruchem do chmury.

Takie podejście pozwala korzystać z elastyczności chmury tam, gdzie naprawdę daje ona przewagę (ciężkie obliczenia, eksperymenty, prototypowanie), a jednocześnie trzymać ruch operacyjny i krytyczne dane bliżej produkcji.

Modele hybrydowe – praktyczne scenariusze

W wielu zakładach kończy się na hybrydzie trzech światów: edge, on-prem i chmura. Przykładowe, realistyczne konfiguracje:

• AI dla wizji maszynowej – kamery i modele detekcji uruchomione na IPC przy linii (edge), okresowe wysyłanie zagregowanych statystyk i próbek do serwera on-prem z bazą danych, trenowanie nowych wersji modeli w chmurze na zanonimizowanych obrazach.
• Predykcyjne utrzymanie ruchu – zbieranie danych w serwerowni zakładowej (on-prem), modele predykcyjne wykonujące się na tych samych serwerach, eksperymenty i testy bardziej złożonych algorytmów w chmurze bez wpływu na środowisko produkcyjne.

Kluczowe jest, aby zakres odpowiedzialności był czytelny: gdzie kończy się odpowiedzialność działu automatyki, gdzie zaczyna IT, a gdzie dostawcy zewnętrznego. W przeciwnym razie każda awaria będzie „niczyja” i wdrożenie AI stanie w miejscu.

Koszty i skalowanie – jak uniknąć pułapek

Niezależnie od wybranego modelu obliczeń, można wpaść w kilka typowych pułapek kosztowych:

• Przewymiarowanie sprzętu on-prem „na wszelki wypadek” – kupienie klastra, który przez większość czasu będzie się nudził.
• Brak limitów w chmurze – brak twardych budżetów i alertów kosztowych, co kończy się niespodziewanymi fakturami.

Jak projektować architekturę pod rozsądne koszty

Z perspektywy budżetu lepiej zadać kilka prostych pytań na etapie projektowania, niż później tłumaczyć się z faktur:

• Czy ten komponent jest krytyczny dla produkcji, czy tylko „miły dodatek” dla zespołu data science?
• Czy komponent można współdzielić z innymi systemami (np. serwery raportowe, macierze backupowe), zamiast kupować dedykowane rozwiązanie pod AI?
• Czy potrzebuję mocy obliczeniowej 24/7, czy tylko w krótkich oknach (np. przy trenowaniu modeli)?

Na tej podstawie architekturę opłaca się układać warstwowo:

• rdzeń krytyczny – elementy, które naprawdę muszą działać non stop (np. serwer inferencji obsługujący kilka linii),
• warstwa wspólna – zasoby współdzielone z innymi systemami (np. hurtownia danych, część serwerów wirtualnych),
• warstwa eksperymentalna – tymczasowe środowiska do testów w chmurze lub na oddzielnych hostach, które można szybko wyłączyć.

Takie podejście pomaga bronić budżetu: gdy pojawia się nowe zadanie z obszaru AI, od razu wiadomo, gdzie powinno wylądować i jakim kosztem.

Monitorowanie zużycia zasobów zamiast „kupmy więcej”

Wiele zespołów IT ucieka w rozbudowę sprzętu, bo nie ma dobrych danych o realnym wykorzystaniu tego, co już stoi w serwerowni. Zanim pojawi się kolejny wniosek zakupowy, dobrze jest:

• wdrożyć proste monitorowanie CPU, RAM, dysków i GPU (np. Prometheus + Grafana, Zabbix, PRTG),
• sprawdzić, czy obciążenie jest ciągłe, czy skokowe – inne rozwiązania pasują do każdego z tych przypadków,
• ustalić limity wykorzystania dla zespołów data science (np. maksymalna liczba równoległych eksperymentów).

Przykład z praktyki: w jednym z zakładów zdiagnozowano „brak mocy obliczeniowej pod AI”. Po włączeniu monitoringu okazało się, że serwer GPU jest zajęty głównie przez stare zadania testowe, które nikt już nie potrzebował. Ich posprzątanie uwolniło ponad połowę zasobów bez złotówki wydanej na sprzęt.

Warstwa obliczeniowa – serwery, GPU, akceleratory i tańsze alternatywy

Od czego zacząć – nie kupuj od razu klastra GPU

Przy pierwszych projektach AI naturalnym odruchem jest „kupmy mocną maszynę z GPU, żeby się nie ograniczać”. W praktyce rozsądniejsza sekwencja wygląda tak:

1. Wyciskamy, co się da z istniejącej infrastruktury – klasyczne serwery CPU, stare stacje robocze, a nawet laptopy inżynierów do wstępnych POC.
2. Testujemy w chmurze mniejsze instancje z GPU, aby zobaczyć realne potrzeby modeli (ile pamięci, jaki czas treningu).
3. Dopiero potem decydujemy, czy opłaca się kupować własny serwer GPU, czy lepiej zostać przy chmurze/hybrydzie.

Taki proces pozwala zbudować pierwsze doświadczenia tanio, a zakupy sprzętowe oprzeć na realnych metrykach, a nie na prezentacji z konferencji.

Serwery CPU – kiedy „zwykła” moc wystarczy

Nie każdy projekt AI wymaga GPU. W wielu zastosowaniach przemysłowych modele są stosunkowo lekkie, a dane nie mają rozmiaru internetu. Typowe przypadki, gdzie klasyczne serwery CPU w pełni wystarczają:

• modele tablicowe (regresje, gradient boosting, proste sieci) oparte na danych z czujników,
• inferencja na niewielkich próbkach – np. przewidywanie awarii raz na kilka minut na podstawie kilku setek wartości,
• obliczenia wsadowe – analizy dzienne, tygodniowe, raporty z wykorzystaniem modeli.

W takim scenariuszu solidny serwer z kilkunastoma/kilkudziesięcioma rdzeniami CPU, 128–256 GB RAM i szybkimi dyskami NVMe potrafi obsłużyć jednocześnie kilka projektów bez zadyszki. Można też:

• wydzielić kilka maszyn wirtualnych pod różne projekty, zamiast kupować osobny fizyczny serwer pod każdy,
• wykorzystać kontenery (Docker, Kubernetes light) do izolacji środowisk, co pozwala lepiej zagospodarować istniejącą moc.

GPU w zakładzie – kiedy ma to biznesowy sens

Zakup własnych GPU opłaca się, gdy łączą się trzy warunki:

• modele są ciężkie obliczeniowo (wizja maszynowa, głębokie sieci, modele sekwencyjne na długich szeregach czasowych),
• obciążenie jest regularne – GPU będzie wykorzystywane tygodniami, a nie raz w miesiącu,
• z różnych powodów nie chcemy trenować w chmurze (polityka bezpieczeństwa, słabe łącze, wysokie koszty transferu).

W takiej sytuacji najrozsądniejszy jest zwykle:

• 1–2 serwery GPU z możliwością rozbudowy (wolne sloty PCIe),
• karta lub dwie z średniej półki – zamiast od razu topowych, znacznie droższych modeli,
• wyraźny podział na czas treningu (np. nocne okna) i czas inferencji (priorytet dzienny dla produkcji).

Częstym błędem jest kupno wielu słabych kart do różnych serwerów. Zazwyczaj lepiej sprawdza się konsolidacja – jeden mocniejszy host z kilkoma GPU, łatwiejszy do zarządzania, tańszy w utrzymaniu i lepiej wykorzystujący zasoby.

Akceleratory specjalizowane – kiedy nie komplikować sobie życia

Na rynku pojawia się coraz więcej akceleratorów AI (TPU, ASIC-i, karty NPU). Kuszą wydajnością i niskim poborem mocy, ale w kontekście zakładu przemysłowego kluczowe pytanie brzmi: kto będzie to utrzymywał?

Akceleratory mają sens, jeżeli:

• producent dostarcza dojrzały ekosystem (biblioteki, sterowniki, przykładowe pipeline’y),
• zespół data science jest gotowy na ograniczenia (np. konieczność korzystania z konkretnych frameworków),
• skalę wdrożenia liczy się w dziesiątkach urządzeń – wtedy rzeczywiście oszczędza się na energii i sprzęcie.

Przy kilku pilotażach rozsądniejszą drogą jest zazwyczaj GPU lub nawet dobrze zaprojektowane CPU. Rozwiązania specjalizowane zostawiłbym na etap, gdy architektura i modele są ustabilizowane, a celem staje się masowe powielenie na wielu liniach czy zakładach.

Tańsze alternatywy sprzętowe „na start”

Zanim do gry wejdą drogie serwery, można spokojnie przetestować wiele koncepcji na budżetowych komponentach:

• Stacje robocze z działu automatyki lub biura technicznego – często mają przyzwoite procesory i sporo RAM.
• Tanie GPU konsumenckie w stacjach roboczych do prototypów, zanim pojawi się decyzja o serwerze klasy enterprise.
• Małe moduły edge (Jetson, Intel NUC, mini PC z akceleratorem USB) do sprawdzenia, jak model radzi sobie przy maszynie.

Nawet jeśli później rozwiązanie trafi na produkcję na docelowy sprzęt, doświadczenia z fazy „tanich prób” pomagają uniknąć większych błędów projektowych – np. widać, które elementy pipeline’u są wąskim gardłem.

Dobór zasobów do typu projektu AI

Żeby nie zgadywać, warto powiązać wymagania sprzętowe z typowymi scenariuszami:

• Modele predykcyjne dla utrzymania ruchu – zwykle wystarczy CPU on-prem, czasem jeden średniej klasy GPU na serwer testowo-treningowy.
• Wizja maszynowa przy linii – inferencja najlepiej na edge (IPC + mały GPU), trening w chmurze lub na jednym serwerze GPU.
• Optymalizacja procesów (planowanie, harmonogramy) – sporo obliczeń, ale mało danych, więc mocne CPU i dobra implementacja algorytmów potrafią zastąpić GPU.
• Modele językowe / chatboty techniczne na dokumentacji maszyn – trenowanie/finetuning w chmurze, inferencja w lekkich modelach na CPU on-prem lub w wydzielonej usłudze chmurowej.

Takie przyporządkowanie można zapisać w prostych wytycznych wewnętrznych – ułatwi to rozmowy między biznesem, IT i data science, gdy zgłaszany jest nowy pomysł na wykorzystanie AI.

Planowanie rozbudowy – małe kroki zamiast wielkiego skoku

Infrastruktura pod projekty AI rzadko jest „gotowa na wszystko” od pierwszego dnia. Zdrowszy model to podejście iteracyjne:

1. Piloty na istniejącej infrastrukturze – POC w chmurze albo na tym, co już stoi w serwerowni.
2. Ocena obciążenia – realne metryki czasu treningu, inferencji, zużycia pamięci i dysku.
3. Zakup jednego elementu – np. pierwszego serwera GPU lub rozbudowy macierzy, zamiast kompletnej „farmy AI”.
4. Ponowna ocena po pół roku – które zasoby się duszą, a które są niedowykorzystane.

Taki cykl pozwala nie tylko lepiej wydać pieniądze, ale też buduje kompetencje zespołu – administratorzy, automatyków i data scientiści uczą się na własnych doświadczeniach, jak projektować kolejne kroki.

Organizacja dostępu do mocy obliczeniowej

Nawet najlepiej dobrany sprzęt nie pomoże, jeśli w praktyce jeden zespół blokuje zasoby, a inni czekają tydzień na okno obliczeniowe. Dlatego przy rosnącej liczbie projektów AI przydają się proste zasady:

• kolejki zadań – narzędzia typu Slurm, Kubernetes lub nawet wewnętrzny kalendarz rezerwacji GPU/serwera,
• priorytety – projekty produkcyjne mają pierwszeństwo przed eksploracyjnymi, ustalone wspólnie z biznesem,
• limity na użytkownika/projekt – maksymalna liczba równoległych zadań, przydział pamięci, czas trwania joba.

Dzięki temu dział data science może sprawnie eksperymentować, a jednocześnie nie ryzykuje się, że jedna źle ustawiona pętla treningowa „położy” wszystkie modele działające na produkcji.

Najczęściej zadawane pytania (FAQ)

Od czego zacząć przygotowanie infrastruktury IT pod projekty AI w zakładzie produkcyjnym?

Na start nie kupuje się serwerów GPU, tylko robi porządną inwentaryzację. Trzeba spisać istniejące serwery, przestrzeń dyskową, topologię sieci, komputery przemysłowe przy liniach oraz kluczowe systemy (SCADA, MES, ERP, CMMS) – z naciskiem na to, jakie dane i w jakiej formie mogą udostępnić.

Drugi krok to prosta mapa przepływu danych: skąd wychodzą (konkretny PLC, linia, system), jakim protokołem, gdzie trafiają i kto ma do nich dostęp. Taka „mapa na jednej stronie” zwykle pokazuje, że część potrzeb można obsłużyć istniejącym sprzętem, a inwestycje ograniczyć do kilku krytycznych miejsc – np. segmentacji sieci OT i jednego centralnego serwera pod dane procesowe.

Jaką infrastrukturę minimalnie trzeba mieć, żeby sensownie wdrażać AI w przemyśle?

Na poziomie „sensownym”, a nie „laboratoryjnym”, potrzebne są trzy rzeczy: stabilna sieć (przynajmniej 1G z podstawową segmentacją IT/OT), miejsce na zbieranie danych procesowych (historyzacja w jednej lub kilku spójnych bazach) oraz wydzielone zasoby obliczeniowe pod projekty danych i AI. To nie musi być od razu klaster GPU – często wystarczy jeden porządny serwer z możliwością rozbudowy.

W wielu średnich zakładach pierwszy etap to:

• wydzielenie VLAN-ów lub osobnych stref dla OT,
• postawienie centralnego archiwum danych (np. SQL + prosty time-series lub historyk SCADA),
• wydzielenie kilku wirtualnych maszyn dla zespołu R&D/analityków, zamiast pracy na „losowych” laptopach.

To już wystarcza, żeby PoC nie utknął w R&D i dało się myśleć o pracy 24/7.

Jak uniknąć sytuacji, że PoC AI działa na laptopie, a nie da się go wdrożyć na hali?

Najprostsza zasada: projekt PoC trzeba od początku projektować tak, jakby miał trafić na produkcję. To oznacza korzystanie z tych samych źródeł danych, z których będzie korzystało docelowe rozwiązanie (SCADA, PLC, MES), oraz testy w realnej sieci zakładowej, a nie tylko na wyeksportowanych plikach CSV.

W praktyce pomaga:

• ustalenie z IT/OT na starcie, gdzie fizycznie będzie działała aplikacja AI (serwerownia centralna, serwer linii, edge),
• zaprojektowanie prostego, ale produkcyjnego „pipeline’u” danych – nawet jeśli PoC jest mały, dane niech płyną tak, jak później,
• sprawdzenie wymagań bezpieczeństwa (transfer poza zakład, chmura) przed startem, a nie po udanym demie.

To kosztuje trochę więcej czasu na początku, ale oszczędza miesiące walki przy próbie wdrożenia.

Czy do AI w zakładzie przemysłowym konieczna jest chmura?

Nie, wiele projektów da się sensownie zrobić „on-premise”, szczególnie tam, gdzie są ograniczenia bezpieczeństwa i słabe łącza internetowe. Chmura daje elastyczność przy trenowaniu modeli i testach, ale w przemyśle inferencja (działanie modelu w czasie rzeczywistym) często ląduje bliżej linii – na serwerze zakładowym lub na edge’u.

Pragmatyczne podejście budżetowe to model hybrydowy: trenowanie modeli i eksperymenty w chmurze (krótkoterminowe wynajęcie mocy zamiast kupna sprzętu), a produkcyjne wdrożenie na istniejącej infrastrukturze zakładowej, wzmocnionej o kilka brakujących klocków. Tam, gdzie łącze i polityka bezpieczeństwa pozwalają, można część zadań inference także zostawić w chmurze, ale nie powinien to być domyślny wymóg.

Jak planować inwestycje w infrastrukturę pod AI w horyzoncie 3–5 lat?

Zamiast kupować sprzęt pod jeden konkretny PoC, lepiej zaplanować kilka kroków, które „zasilą” wiele projektów. Podstawą jest wspólna architektura danych (wiedza, którędy płyną dane i gdzie są przechowywane) oraz modularna infrastruktura, którą można stopniowo rozbudowywać – dodatkowe dyski, kolejne karty sieciowe, nowe serwery w tym samym standardzie.

Praktycznie wygląda to tak:

• najpierw porządkowanie sieci i punktów zbierania danych (historyzacja),
• potem dołożenie skalowalnego storage’u i kilku uniwersalnych serwerów zamiast „jednorazowych” maszyn pod konkretny projekt,
• dopiero na końcu inwestycje w wyspecjalizowany sprzęt (GPU, edge), gdy wiadomo, jakie obciążenia są realnie potrzebne.

Dzięki temu każdy kolejny projekt AI dokładamy do istniejącej układanki, zamiast budować obok nową „wyspę”.

Jak pogodzić wymagania bezpieczeństwa IT/OT z potrzebami projektów AI?

Podstawą jest to, żeby dział bezpieczeństwa był przy stole od pierwszych rozmów, a nie dopiero przy podpisywaniu zgód na dostęp do PLC czy wysyłkę danych do chmury. Trzeba wspólnie ustalić, które dane mogą wychodzić poza zakład, jak anonimizować lub agregować informacje oraz jakie strefy sieciowe są przeznaczone dla nowych systemów AI.

Częsty, rozsądny kompromis to:

• wydzielenie strefy „DMZ dla OT”, gdzie lądują dane z linii (np. serwer OPC UA, historyk),
• udostępnianie do analizy nie surowych danych z PLC, tylko już zarchiwizowanych i ograniczonych do tego, co rzeczywiście jest potrzebne modelowi,
• lokalne uruchamianie krytycznych modeli (np. bezpieczeństwo, utrzymanie ruchu) w zakładzie, a do chmury wysyłanie jedynie danych do trenowania i analizy offline.

Takie podejście zwykle spełnia wymagania bezpieczeństwa, a jednocześnie nie blokuje rozwoju AI.

Jak poradzić sobie z „wyspami automatyki” i różnymi sterownikami przy projektach AI?

Najtańsza droga to wprowadzenie wspólnej warstwy integracyjnej zamiast prób unifikacji całej automatyki. Chodzi o to, żeby z różnych PLC, protokołów i nazw tagów wyprowadzić dane do jednego, ustandaryzowanego modelu – choćby prostego słownika mapującego nazwy lokalne na wspólne nazwy procesowe.

W praktyce oznacza to:

• postawienie jednego lub kilku serwerów komunikacyjnych (OPC UA/gateway), które „rozmawiają” z różnymi sterownikami,
• uzgodnienie minimalnego standardu nazewnictwa nowych tagów i linii, żeby nie powielać bałaganu,
• budowę wspólnej bazy tagów wykorzystywanej przez projekty AI – nawet w formie prostego repozytorium lub bazy SQL.

To nie likwiduje od razu wszystkich „wysp”, ale pozwala tanim kosztem zacząć zbierać i wykorzystywać dane w sposób powtarzalny.

Najważniejsze wnioski

• Główną barierą dla AI w zakładach nie są algorytmy, tylko infrastruktura: brak archiwizacji danych, chaos w sieci, ograniczone serwery i silos IT/OT sprawiają, że nawet dobry model z PoC nie ma gdzie „zamieszkać”.
• Proof of concept na CSV i laptopie to zupełnie inna liga niż system 24/7 na żywych danych; bez stabilnego pobierania, przetwarzania i udostępniania strumieni danych AI pozostaje ciekawą prezentacją, a nie narzędziem produkcyjnym.
• Typowe bolączki fabryk – stare, niesegmentowane sieci, wyspy automatyki, brak centralnego archiwum procesowego i rozrzucone pliki CSV – uniemożliwiają skalowanie, bo każdy projekt trzeba „rzeźbić ręcznie” od zera.
• Inwestycje w infrastrukturę pod AI trzeba planować w horyzoncie 3–5 lat, pod wiele projektów, a nie pod jednego pilota; inaczej powstaje droga mozaika jednorazowych rozwiązań, która zjada budżet na integrację zamiast na realne efekty.
• Bez sensownie zaprojektowanej sieci, architektury danych i warstwy obliczeniowej nawet udany PoC potrafi utknąć w R&D – jak model predykcji awarii sprężarki, którego nie dało się uruchomić „na żywo” z powodu izolowanego PLC, braku serwera przy linii i ograniczeń bezpieczeństwa.
• Najtańszy pierwszy krok to rzetelna inwentaryzacja obecnej infrastruktury IT/OT i danych: policzenie, co już jest, gdzie są wąskie gardła i co można wykorzystać ponownie, zamiast od razu kupować „serwery GPU i chmurę hybrydową na wszelki wypadek”.