AI zmienia profil ruchu w sieci: czego się spodziewać
Typy obciążeń AI a zachowanie sieci
Wdrożenia AI w organizacji nie wyglądają „sieciowo” tak samo. Trening modeli, inferencja batchowa i inferencja interaktywna mają zupełnie różny profil ruchu i inne wymagania wobec infrastruktury. Bez ich rozróżnienia cała ocena gotowości sieci staje się z góry skażona błędem – mieszają się potrzeby przepustowości i opóźnień.
Trening modeli AI generuje długotrwały, masywny ruch pomiędzy magazynem danych a klastrami GPU/TPU. Dominują tu strumienie o wysokiej przepływności, wrażliwe głównie na stabilność i straty, a nie na pojedyncze milisekundy opóźnienia. Jeśli dane są ładowane z NAS, obiektówki lub z chmury, cały ruch przechodzi przez te same uplinki, które zwykle obsługują backupy, replikację i hurtownie danych.
Inferencja batchowa (np. nocne generowanie raportów, przetwarzanie dużych kolekcji dokumentów) też bywa ciężka przepustowościowo, ale bardziej „pofragmentowana”. Tworzy okna czasowe o dużym obciążeniu – często pokrywające się z innymi zadaniami wsadowymi. Pod kątem sieci ma znaczenie, czy zadania są zsynchronizowane (jeden ogromny pik), czy rozproszone (seria mniejszych, ale częstszych pików).
Inferencja interaktywna – chatboty, copiloty w IDE, AI w call center – to dokładne przeciwieństwo treningu. Tu liczy się latencja end-to-end. Pojedyncze zapytania są niewielkie objętościowo (teksty, metadane, krótkie fragmenty audio), ale generują setki lub tysiące krótkich sesji TCP/TLS. Każde dodatkowe 50–100 ms opóźnienia jest widoczne dla użytkownika jako „lag” lub „przycinanie się” asystenta.
Jeśli w organizacji wszystkie te scenariusze mieszają się na jednej, płaskiej infrastrukturze bez rozróżnienia profili ruchu, sieć reaguje chaotycznie. Trening może w praktyce „wypychać” z kolejek zapytania interaktywne, a batchowe zadania AI zlecone przez działy analityczne będą konkurować z kluczowymi systemami transakcyjnymi.
Charakterystyka ruchu AI: skąd, dokąd, jak intensywnie
Obciążenie sieci przez AI ma kilka powtarzalnych cech, które warto zmapować przed jakąkolwiek decyzją inwestycyjną. Pierwsza z nich to kierunek przepływu danych. Trening i cięższa inferencja generują ruch głównie pomiędzy:
- magazynem danych (NAS, SAN, obiektówka) a klastrami GPU,
- lokalnymi serwerami a chmurą (np. do korzystania z zewnętrznych API modeli),
- siecią kampusową a centralnymi usługami AI (on-prem lub w chmurze).
Druga cecha to typowy rozmiar strumieni. Ruch treningowy to duże, długotrwałe przepływy, w których pojedyncze sesje TCP mogą trwać dziesiątki minut. Interaktywne wywołania API to natomiast krótki burst pakietów, zamknięcie sesji i kolejne połączenie. Dla sieci oznacza to inne zachowanie buforów, tablic stanu i mechanizmów równoważenia ruchu.
Trzecia cecha to punkt styku z chmurą. Architektura hybrydowa AI (on-prem i chmura) powoduje, że znacząca część ruchu przechodzi przez te same bramy internetowe lub łącza WAN, które wcześniej obsługiwały głównie HTTP i pocztę. Nagle pojawia się intensywne korzystanie z API AI SaaS/PaaS: OpenAI, Azure OpenAI, AWS Bedrock, własne endpointy modeli w chmurze. Jeśli te strumienie nie są ani monitorowane, ani klasyfikowane, z czasem stają się ukrytym wąskim gardłem.
Jeśli nie wiadomo, jakie strumienie ruchu AI są najcięższe, nie da się poprawnie rozłożyć obciążeń między lokalną infrastrukturę GPU a chmurę ani zaprojektować sensownego QoS i segmentacji sieci dla modeli AI.
Rozrzut obciążeń w czasie i wpływ na sieć kampusową
AI używana „punktowo” przez zespół R&D obciąża sieć inaczej niż AI rozsiana po całej organizacji. Gdy z chatbota albo copilotów korzystają tylko pojedyncze osoby, ruch jest mało zauważalny. Problem zaczyna się, gdy te narzędzia staną się standardem pracy – wówczas piki ruchu pojawiają się o typowych porach dnia (9:00–11:00, 13:00–15:00) i zderzają się z innymi szczytami (wideokonferencje, systemy ERP, backupy „na szybko” po pracy użytkowników).
W sieci kampusowej i Wi‑Fi objawia się to jako:
- sporadyczne, ale intensywne przeciążenia AP przy salach szkoleniowych/konferencyjnych, gdzie wiele osób jednocześnie używa copilotów lub chatbotów,
- nagłe wzrosty opóźnień przy dostępie do centralnych zasobów, gdy systemy analityczne wywołują modele AI z wielu lokalizacji jednocześnie,
- kaskadowe efekty w uplinkach przełączników dostępowych, gdy ruch z wielu portów kumuluje się w przeciążonych łączach agregacyjnych.
Szczególnie kłopotliwe są zlecenia wsadowe AI uruchamiane w ciągu dnia pracy. Nawet jeśli pojedyncze zadanie jest stosunkowo małe, duża liczba równoległych zadań generowanych przez różne działy może podnieść wykorzystanie łączy i buforów do granic możliwości.
Jeśli sieć kampusowa i WAN są projektowane „pod klasyczne aplikacje biurowe”, a AI jest dokładana bez przemyślenia, pierwszym objawem będzie nie tyle awaria, co chroniczne „zamulanie” usług czasu rzeczywistego – VoIP, wideokonferencji, zdalnych pulpitów.
Pierwsze sygnały ostrzegawcze przy wdrożeniach AI
Profil ruchu AI nie tylko zwiększa wolumen, ale też obciąża krytyczne miejsca w topologii. Sygnały ostrzegawcze pojawiają się dość szybko, tylko trzeba je właściwie powiązać z konkretnymi wdrożeniami. Typowe symptomy to:
- skoki opóźnień w dostępie do kluczowych usług tuż po uruchomieniu nowych narzędzi AI dla większej grupy użytkowników,
- zrywane sesje VPN lub RDP w okresach, gdy np. dział analiz masowo używa narzędzi AI w chmurze,
- spadek jakości wideokonferencji (artefakty audio/video, zwiększone jitter) w godzinach, gdy zespół call center korzysta z asystentów AI do obsługi klientów,
- wzrost retransmisji TCP na łączach do chmury, gdy ruch AI zaczyna konkurować z innymi krytycznymi strumieniami.
Jeżeli takie symptomy są rejestrowane, a w logach zmian widać równolegle wdrożenia AI, to jest to punkt kontrolny: trzeba natychmiast zacząć klasyfikować ruch AI i mierzyć jego udział w godzinach szczytu, zanim zostanie on utrwalony jako „nowa normalność”.
Jeśli profil ruchu AI nie jest zmapowany, nikt go nie rozróżnia w monitoringu i brak jest widoczności, które aplikacje są źródłem obciążeń, planowanie przepustowości staje się zgadywanką, a budżet idzie w ślepe rozbudowy.
Inwentaryzacja i punkt wyjścia: jak naprawdę wygląda twoja sieć
Minimum danych przed oceną gotowości na AI
Ocena gotowości sieci na AI zaczyna się od rzetelnej inwentaryzacji. Nie chodzi tu o „ładny diagram do prezentacji”, ale o minimalny zestaw danych, który pozwala odpowiedzieć na pytanie: gdzie tak naprawdę popłynie ruch AI i co już dziś jest blisko granic wydolności.
Podstawowy spis elementów krytycznych powinien objąć:
- przełączniki i routery rdzeniowe, wraz z informacją o przepustowości backplane i liczbie uplinków,
- warstwę agregacji i dostępu, szczególnie w lokalizacjach, które będą intensywnie korzystać z usług AI (call center, działy developerskie, zespoły analityczne),
- wszystkie łącza WAN i wyjścia do internetu, w tym tunele VPN do chmur publicznych i prywatnych,
- segmenty serwerowe, w których już działają lub będą działały klastry GPU/TPU,
- istniejące połączenia z chmurą (Direct Connect, ExpressRoute, prywatne peeringi, MPLS/SD‑WAN).
Drugim elementem minimum jest mapa typowych ścieżek ruchu. Dla każdej planowanej grupy usług AI trzeba jasno określić: z których lokalizacji użytkownicy będą się łączyć, gdzie znajdują się endpointy modeli, którędy przejdzie ruch (lokalnie, przez WAN, przez internet, przez centralny firewall). Bez tego QoS i segmentacja będą działaniami pozornymi.
Trzeci składnik to aktualne profile ruchu: kto generuje najwięcej, w jakich godzinach, jakie aplikacje dominują w wolumenie. Jeśli takie dane nie są zbierane systematycznie (NetFlow/sFlow, NTA), trzeba zacząć co najmniej od kilku tygodni pomiarów przed większym wdrożeniem AI.
Topologia logiczna vs fizyczna – gdzie naprawdę popłynie AI
Wiele organizacji ma ładne rysunki VLAN‑ów i VRF‑ów, ale realny przepływ ruchu często idzie inaczej niż na diagramach. AI mocno uwidacznia tę różnicę. Trzeba zestawić dwie perspektywy:
- topologia logiczna – VLAN‑y, segmenty IP, routing (OSPF/BGP), VRF‑y, strefy bezpieczeństwa,
- topologia fizyczna – konkretne przełączniki, ich uplinki, patch‑panele, połączenia między szafami i lokalizacjami.
Jeśli na przykład klastry GPU są w innej serwerowni niż główna obiektówka danych, ruch treningowy będzie przechodził przez dodatkową warstwę agregacji lub nawet WAN, choć w logice serwerów wszystko jest „w jednym VLAN‑ie storage”. To typowy sygnał ostrzegawczy: ryzyko niespodziewanego nasycenia uplinków, o których nikt nawet nie myślał przy planowaniu AI.
Podobnie, jeśli architektura hybrydowa AI zakłada, że użytkownicy łączą się przez lokalne breakouty internetowe, a w praktyce cały ruch idzie do centrali i wraca do chmury (tromboning), oznacza to, że:
- bramy centralne staną się jednym, wielkim wąskim gardłem,
- czas odpowiedzi aplikacji AI będzie zbędnie wydłużony,
- QoS będzie trudniejsze, bo różne profile ruchu skumulują się w jednym miejscu.
Jeśli nie ma aktualnej mapy ścieżek ruchu (np. z narzędzi typu path trace, NetFlow end‑to‑end, SD‑WAN telemetry), trzeba ją odtworzyć zanim powstanie jakikolwiek projekt pod AI. W przeciwnym razie QoS i segmentacja będą projektowane na diagramach, a nie na realnych przepływach.
Obecne polityki QoS i segmentacji: punkt startowy
Przed wdrożeniem AI trzeba zrozumieć, co już jest zdefiniowane w sieci w zakresie priorytetów i podziału ruchu. Kluczowe pytania kontrolne:
- czy istnieją zdefiniowane klasy QoS – np. dla VoIP, ruchu krytycznego biznesowo, ruchu best effort, kopii danych,
- jakie oznaczenia DSCP są używane i czy są one konsekwentnie przenoszone przez wszystkie warstwy sieci,
- czy sieć jest w dużej mierze „flat” (jeden duży VLAN/VRF), czy istnieje segmentacja na poziomie L3, stref bezpieczeństwa, SD‑WAN,
- czy narzędzia analityczne, dev/test, laboratoria już są odseparowane, czy korzystają z tych samych zasobów co systemy produkcyjne.
Na tym etapie dobrze jest wyszczególnić, które mechanizmy są już w użyciu: priorytetyzacja, policing, shaping, WRED, klasy usług w WAN, mikrosegmentacja (np. z wykorzystaniem polityk opartych o tożsamość lub tagi). Pozwala to ocenić, czy ruch AI da się wpiąć w istniejącą klasyfikację, czy trzeba projektować nowe klasy od zera.
Jeżeli QoS funkcjonuje tylko „na papierze”, a w praktyce wszystkie pakiety mają DSCP 0, to każdy scenariusz priorytetyzacji ruchu AI będzie wymagał najpierw podstawowego porządkowania polityk w całej infrastrukturze.
Wskaźniki bazowe: bez nich nie ocenisz zmian
Minimalny punkt odniesienia (baseline) dla gotowości sieci na AI obejmuje zestaw wskaźników, które trzeba zbierać przed wdrożeniami. Bez nich nie da się uczciwie stwierdzić, czy problemy po wdrożeniu AI wynikają z niej, czy po prostu zostały uwidocznione.
Na liście absolutnego minimum powinny się znaleźć:
- średnie i maksymalne opóźnienia (latencja) między kluczowymi punktami (lokacje – DC – chmura),
- jitter na łączach, które obsługują ruch czasu rzeczywistego (VoIP, wideokonferencje),
- współczynnik wykorzystania interfejsów (średnia i piki) na uplinkach, rdzeniu, łączach WAN,
- liczba dropów na kolejkach, buforach, interfejsach,
- retransmisje TCP w kluczowych segmentach (szczególnie do chmury).
Te dane powinny być zebrane w ujęciu co najmniej tygodniowym, lepiej miesięcznym, aby oddać sezonowość ruchu. Pozwoli to zbudować referencję „jak było przed AI”.
Wąskie gardła: jak je znaleźć zanim zatrzymają wdrożenia AI
Krytyczne punkty przepływu ruchu AI
Na potrzeby audytu pod kątem AI trzeba wskazać konkretne miejsca, które najczęściej stają się wąskim gardłem. Zwykle nie są to „efektowne” elementy infrastruktury, lecz te, o których zapomniano przy projektowaniu lub modernizacji.
Lista podstawowych kandydatów na wąskie gardła obejmuje:
- uplinki z warstwy dostępowej do agregacji – szczególnie tam, gdzie zespoły analityczne i developerskie siedzą na tych samych przełącznikach co biuro i call center,
- rdzeń kampusu, jeśli część AI działa lokalnie, a część w chmurze i cały ruch przechodzi przez centralne przełączniki,
- firewalle i urządzenia UTM – zarówno sprzętowe, jak i wirtualne, zwłaszcza przy topologii typu hub-and-spoke z centralnym wyjściem do internetu,
- koncentratory VPN oraz bramy SD‑WAN, które terminują tunele z oddziałów lub z chmury,
- łącza do chmury (Direct Connect, ExpressRoute, IPsec do VPC/VNet), gdzie AI w chmurze konkuruje z ruchem do SaaS i systemów ERP/CRM.
Jeśli w którejkolwiek z tych stref średnie wykorzystanie łącza przekracza 40–50% w godzinach szczytu, a jednocześnie pojawiają się plany intensywnego użycia AI, to jest to wyraźny punkt kontrolny: bez pre‑capacity planningu wdrożenie AI będzie ruletką.
Jak odróżnić „wysokie użycie” od faktycznego zatoru
Sam procent zajętości interfejsu nie wystarcza, aby stwierdzić, że mamy do czynienia z wąskim gardłem. Kryteria diagnostyczne powinny łączyć dane ilościowe i jakościowe:
- wysoka zajętość + rosnące opóźnienia (bufferbloat) na tych samych interfejsach,
- dropy w kolejkach przy jednoczesnym wzroście retransmisji TCP w tym segmencie,
- skok jitter dla ruchu czasu rzeczywistego, mimo że średnie zużycie łącza formalnie nie osiąga 100%,
- wyraźne „schodki” w throughput w logach testów przepustowości (np. iPerf) przy rosnącym obciążeniu ruchem AI.
Jeżeli monitoring pokazuje wysokie wykorzystanie, ale brak korelacji z opóźnieniami, dropami i jitterem, to jest to raczej sygnał do planowania rozbudowy w horyzoncie kilku kwartałów. Jeśli natomiast każdy skok wolumenu ruchu AI pociąga za sobą widoczny spadek jakości usług czasu rzeczywistego, mamy już wąskie gardło w sensie praktycznym – niezależnie od tego, co „mówi” SLA operatora.
Testy przeciążeniowe z ruchem zbliżonym do AI
Żeby nie czekać na problemy w produkcji, można wymusić ruch o charakterystyce zbliżonej do planowanych obciążeń AI. Nie chodzi o syntetyczne „zalewanie” sieci, ale o kontrolowane scenariusze:
- uruchomienie serii symulowanych zapytań do modeli w chmurze z kilku kluczowych lokalizacji,
- włączenie testowych zadań trenowania na klastrach GPU, które replikują spodziewany pattern ruchu do storage,
- połączenie tego z aktywnym monitorowaniem VoIP i wideokonferencji (testowe połączenia, MOS).
Takie testy powinny być zaprojektowane w porozumieniu z zespołami, które będą korzystały z AI w trybie produkcyjnym, aby scenariusze nie były „laboratoryjne”. Jeżeli nawet przy ograniczonej skali testów udaje się łatwo sprowokować skoki opóźnień lub dropy na konkretnych uplinkach, jest to silny sygnał ostrzegawczy przed skalowaniem AI.
Sprzęt a oprogramowanie: ukryte limity wydajności
W wielu środowiskach to nie tylko fizyczna przepustowość łącza jest problemem, ale ograniczenia wynikające z architektury urządzeń i licencji:
- limit liczby sesji lub przepływów, który firewalle, load balancery czy bramy VPN są w stanie śledzić jednocześnie,
- wydajność procesora i pamięci na urządzeniach, gdzie włączenie inspekcji SSL/TLS lub IDS/IPS gwałtownie obcina przepustowość,
- feature‑licensing powodujący, że teoretycznie szybki sprzęt w praktyce działa z obniżonym throughputem (np. brak licencji na pełną przepustowość lub określoną funkcję akceleracji).
W kontekście AI specjalną uwagę trzeba poświęcić miejscom, gdzie ruch jest terminowany i analizowany (firewalle, proxy, bramy API). Jeśli modele w chmurze korzystają z HTTPS i każdy strumień przechodzi przez inspekcję TLS, łatwo o sytuację, w której CPU firewalli staje się faktycznym wąskim gardłem, mimo że interfejsy sieciowe raportują zapas przepustowości.
Jeżeli audyt pokazuje wysokie obciążenie CPU/ram przy umiarkowanym ruchu, a jednocześnie planowane jest zwiększenie wolumenu żądań do usług AI, to jest to punkt kontrolny wymagający natychmiastowego przeglądu architektury bezpieczeństwa i ewentualnej zmiany ścieżek ruchu.
Najczęstsze „punkty zapalne” przy AI w chmurze
W scenariuszach, gdzie modele działają w chmurach publicznych, lista typowych problemów zawęża się do kilku miejsc:
- centralne wyjście internetowe, przez które idzie zarówno ruch AI, jak i SaaS oraz aktualizacje,
- pojedynczy tunel VPN/IPsec zestawiony jako „tymczasowy” dostęp do VPC/VNet, który staje się w praktyce produkcyjnym kręgosłupem,
- niewydzielone łącza do chmury, gdzie klasy ruchu operatora WAN traktują wszystko jako „best effort”.
Jeśli architektura hybrydowa jest budowana stopniowo, bez formalnego projektu pod AI, pojawia się efekt „sklejania” kolejnych usług do istniejącego tunelu lub wyjścia internetowego. W pewnym momencie każde kolejne wdrożenie AI w chmurze działa coraz gorzej, a wskaźniki w NOC wyglądają na „średnio w normie”, bo kumulują różne profile ruchu. To klasyczny sygnał ostrzegawczy, że segmentacja i QoS w kierunku chmury są niewystarczające lub nie istnieją.
QoS dla AI: jak ustawić priorytety bez paraliżu reszty usług
Dlaczego AI nie może mieć „z automatu” najwyższego priorytetu
Presja biznesu bywa prosta: „AI jest strategiczne, dajcie jej najwyższy priorytet w sieci”. Taka decyzja, podjęta bez analizy, potrafi zniszczyć dotychczasowy model QoS. AI rzadko jest ruchem czasu rzeczywistego w tym samym sensie, co VoIP czy systemy sterowania produkcją.
Kluczowe kryteria kwalifikowania ruchu AI do klas QoS:
- wrażliwość na opóźnienia – czy opóźnienie o kilkaset milisekund faktycznie wpływa na doświadczenie użytkownika,
- wrażliwość na jitter – większość zapytań do modeli LLM lub batchowych zadań ML nie wymaga stabilnego jitteru,
- wrażliwość na utratę pakietów – czy retransmisje TCP przy niewielkim drop rate są akceptowalne,
- kontekst biznesowy – czy dane wdrożenie AI obsługuje proces o znaczeniu krytycznym (np. real‑time scoring transakcji) czy wsparcie analityczne działu marketingu.
Jeżeli AI nie jest elementem łańcucha o twardych wymaganiach czasowych, nie powinna trafiać do tej samej klasy, co VoIP i systemy sterujące. To punkt kontrolny przy projektowaniu polityk: „AI strategiczna” nie oznacza „AI zawsze na najwyższej kolejce”.
Podstawowe klasy usług z uwzględnieniem AI
W większości przypadków wystarczy dostosować istniejące klasy QoS, zamiast budować całkowicie nowe drzewo polityk. Przykładowa struktura klas, w której AI ma swoje miejsce, ale nie dominuje sieci, może wyglądać następująco:
- klasa czasu rzeczywistego – VoIP, wideokonferencje, krytyczne systemy OT; minimalizacja jitter i opóźnień, niewielki, twardo ograniczony procent pasma,
- klasa transakcyjna – kluczowe systemy biznesowe, aplikacje klient/serwer o wysokiej wrażliwości na opóźnienia,
- klasa AI „interaktywnej” – zapytania użytkowników do asystentów AI, usługi inference w trybie online, które muszą odpowiadać w sekundach, a nie minutach,
- klasa AI „batchowej” – trening modeli, hurtowe przetwarzanie danych, zadania ETL powiązane z AI,
- klasa best effort – ruch biurowy, przeglądanie www, niekrytyczne usługi SaaS,
- klasa niskiego priorytetu – kopie zapasowe, aktualizacje, synchronizacje, ciężkie transfery plików bez twardych wymagań czasowych.
AI pojawia się tu w dwóch wariantach – interaktywnym i batchowym. Jeśli audyt wykaże, że obie formy są wrzucane do jednej grupy, to punkt kontrolny: trzeba rozdzielić ruch, bo ich profile i oczekiwania biznesowe są inne.
Klasyfikacja ruchu AI: jak go w ogóle „złapać”
Skuteczne QoS jest możliwe tylko wtedy, gdy ruch AI da się wiarygodnie rozpoznać i oznaczyć. To zwykle największe wyzwanie, bo usługi AI często są konsumowane jako dodatki do istniejących aplikacji SaaS lub jako połączenia HTTPS do chmury.
Ścieżki klasyfikacji ruchu AI można oprzeć na kilku warstwach:
- adresy IP i FQDN – dedykowane subnets / adresy serwerów API AI w DC/chmurze, osobne rekordy DNS dla endpointów modeli,
- porty i protokoły<