Frazy pomocnicze: architektura danych pod AI, wąskie gardła I/O, transfer danych do GPU, małe pliki i storage obiektowy, batchowanie i partycjonowanie danych, cache i prefetching, preprocessing offline vs online, lokalność danych, inferencja i RAG, walidacja wydajności pipeline’u, koszty egressu, feature store i baza wektorowa
Scenariusz bywa powtarzalny. Na małej próbce wszystko wygląda dobrze: trening rusza sprawnie, inferencja odpowiada szybko, a pipeline testowy nie budzi niepokoju. Potem dochodzi pełny zbiór, zdalny storage, kilka warstw pośrednich i nagle GPU czekają, workery stoją w kolejce, a koszty transferu rosną szybciej niż jakość modelu. Wtedy zwykle okazuje się, że problem nie leży w samym AI, tylko w tym, jak dane są przechowywane, czytane, kopiowane i dostarczane do obliczeń.
Jeśli architektura danych pod AI ma nie dusić się na I/O i transferach, trzeba potraktować ją jak łańcuch dostarczania danych, a nie tylko magazyn plików pod model. Liczy się kolejność decyzji: najpierw wzorzec obciążenia, potem pełna ścieżka danych, następnie układ danych pod odczyt, na końcu lokalność, cache i walidacja pod obciążeniem. To nie jest akademicka kosmetyka. Jedna źle dobrana warstwa kopiowania albo milion małych obiektów potrafią zabrać więcej czasu niż optymalizacja samego modelu.
Punkt wyjścia: gdzie naprawdę dławi się system AI
Objawy, które łatwo pomylić z „wolnym modelem”
Pierwszy błąd pojawia się wtedy, gdy cały problem przypisuje się modelowi albo GPU. Jeśli zadanie trwa długo, to nie znaczy jeszcze, że obliczenia są zbyt ciężkie. Często jest odwrotnie: compute kończy swoją część szybko, ale przez większość czasu czeka na dane. Typowy sygnał to niska utylizacja akceleratorów lub workerów przy wysokim czasie końcowym zadania. Z zewnątrz wygląda to jak problem wydajności modelu, lecz w praktyce winny bywa odczyt z remote storage, rozpakowywanie rekordów, serializacja między usługami albo opóźnienia w kolejce wejściowej.
Drugi sygnał to duża różnica między środowiskiem lokalnym a pełnym przebiegiem produkcyjnym. Jeśli trening działa poprawnie na próbce zapisanej lokalnie, ale zwalnia po przejściu na pełen zbiór trzymany zdalnie, to najczęściej nie model stał się nagle cięższy. Zmieniła się ścieżka danych: doszły listowania obiektów, opóźnienia sieciowe, ponowne próby odczytu, drobne requesty i koszt deserializacji rozproszonej po wielu małych plikach.
Kolejny objaw to niestabilność. Jedne uruchomienia są szybkie, inne zaskakująco wolne mimo podobnego obciążenia. Taki wzorzec często wskazuje na problem z warstwą danych, bo I/O i transfer są bardziej podatne na skoki opóźnień, przeciążenie metadanych, zimny cache albo współdzielenie storage’u z innymi zadaniami. Model zwykle zachowuje się bardziej przewidywalnie niż ścieżka dostarczania danych.
Jak odróżnić problem compute od problemu data delivery
Jeśli chcesz rozpoznać, czy system dławi się na I/O, rozbij czas wykonania na etapy. Nie wystarczy znać całkowity czas zadania. Potrzebne są osobne pomiary dla: pobrania danych, listowania obiektów, otwierania plików, deserializacji, transformacji, kolejkowania batchy, transferu do procesu obliczeniowego oraz zapisu wyników. Gdy suma tych kosztów zaczyna dominować, strojenie modelu daje coraz mniejszy efekt.
W praktyce pomocne jest proste pytanie: czy przyspieszenie modelu o 20% rzeczywiście skróci cały pipeline o podobną wartość? Jeśli nie, to znaczy, że główny hamulec leży gdzie indziej. Gdy model odpowiada za mniejszą część czasu całego przebiegu, zwiększanie jego wydajności bywa tylko kosmetyką. To samo dotyczy sytuacji, w której większa liczba workerów nie poprawia przepustowości. Jeśli dodatkowe procesy nadal czekają na dane, problemem nie jest brak mocy obliczeniowej.
Dobrą próbą diagnostyczną jest uruchomienie tego samego zadania na lokalnym stagingu danych lub na znacznie prostszej ścieżce odczytu. Jeśli czas spada radykalnie bez zmiany modelu, odpowiedź jest jasna: problem dotyczy architektury danych pod AI, a dokładniej ścieżki I/O i transferów.
Robocza definicja wąskiego gardła I/O w systemach AI
W praktyce można przyjąć prostą definicję: system dusi się na I/O wtedy, gdy czas, zmienność i koszt ruchu danych rosną szybciej niż korzyść z kolejnych optymalizacji modelu. Nie chodzi tylko o czystą przepustowość dysku czy sieci. Równie ważne są małe operacje, liczba otwarć plików, serializacja, odczyt losowy, retry, granice sieciowe i kopiowanie między warstwami.
To ważne rozróżnienie, bo „I/O” w architekturze pod AI nie oznacza wyłącznie dysku. Obejmuje cały łańcuch: źródło danych, storage obiektowy lub plikowy, warstwę pośrednią, parsery, cache, sieć, mechanizm kolejkowania batchy oraz zapis wyników. System może mieć szybkie CPU i GPU, a mimo to działać słabo, bo ten łańcuch jest zbyt długi, zbyt rozproszony albo niepasujący do realnego wzorca odczytu.
Krok 1. Najpierw rozpoznaj wzorzec obciążenia, bo od niego zależą wszystkie decyzje
Pięć scenariuszy, które wymagają innej architektury
Trening wsadowy zwykle oznacza duże wolumeny danych, wiele epok i wielokrotne czytanie tych samych zbiorów. Tutaj kluczowe stają się przepustowość, lokalność danych i koszt każdego kolejnego przebiegu. Jeśli dane są daleko od compute, każda epoka zwielokrotnia problem. W takim scenariuszu dobrze działa staging, konsolidacja plików i ograniczanie transformacji wykonywanych za każdym razem od zera.
Fine-tuning ma inny profil. Zbiór bywa mniejszy, ale iteracji jest dużo, bo eksperymentów, wersji i krótkich cykli testowych przybywa szybko. Wtedy bardziej opłaca się uprościć ścieżkę danych, utrzymać lokalny cache i usuwać zbędne warstwy pośrednie. Jeśli zespół codziennie uruchamia małe, częste zadania, rozbudowany pipeline z wieloma punktami serializacji bardziej przeszkadza niż pomaga.
Inferencja online stawia nacisk na opóźnienie i przewidywalność. Tu każdy zdalny odczyt, każda transformacja „w locie” i każde odpytywanie dodatkowej usługi muszą mieć twarde uzasadnienie. Nawet jeśli średni czas odpowiedzi jest akceptowalny, ogony opóźnień mogą zabić stabilność systemu. Format danych wygodny dla treningu może być kompletnie chybiony dla inferencji, jeśli wymaga zbyt ciężkiej deserializacji lub szerokiego skanu danych.
Inferencja batchowa toleruje większe opóźnienia jednostkowe, ale łatwo ją spowolnić przez ogromną liczbę drobnych odczytów i zapisów. To częsty przypadek przy pipeline’ach klasyfikacji dokumentów, scoringu lub generowania embeddingów. Jeśli każdy rekord powoduje osobny request do storage’u lub osobny zapis wyników, narzut operacyjny zaczyna dominować nad obliczeniami.
RAG i embeddingi mają jeszcze inny profil. Oprócz samego modelu dochodzi pobieranie dokumentów, chunking, wyszukiwanie wektorowe, odczyt kontekstu i aktualizacja indeksów. Wąskie gardło może pojawić się nie tylko w storage’u źródłowym, ale też między bazą wektorową, repozytorium dokumentów i warstwą aplikacyjną. Jeśli ścieżka „pobierz dokument → potnij → wygeneruj embedding → zapisz → wyszukaj → dołącz kontekst” jest zbyt rozciągnięta i oparta na wielu drobnych operacjach sieciowych, opóźnienia mnożą się bardzo szybko.
Po czym poznać, z jakim profilem odczytu masz do czynienia
Najpierw sprawdź, czy odczyt jest sekwencyjny czy losowy. Trening na dużych batchach częściej korzysta na sekwencyjnym strumieniu dużych porcji danych. Z kolei RAG albo inferencja online mogą opierać się na losowym dostępie do niewielkich fragmentów. To rozróżnienie wpływa na sensowny format danych, wielkość plików, potrzebę cache i sposób partycjonowania.
Drugi wymiar to częstotliwość ponownych odczytów. Jeśli te same dane będą czytane wielokrotnie, lokalny cache, staging i preprocessing offline zwykle mają sens. Jeśli pipeline ma wykonać jednorazowy pełny przebieg, złożony system cache potrafi kosztować więcej niż daje. To jeden z najczęstszych powodów niepotrzebnej komplikacji architektury.
Trzeci wymiar to wielkość batchy i liczba etapów transformacji. Małe batch’e zwiększają liczbę operacji wejścia-wyjścia, połączeń i kosztów pomocniczych. Duża liczba etapów oznacza więcej miejsc na serializację, przeładowanie danych i błędy koordynacji. Jeśli do prostego zadania trzeba przejść przez pięć usług, dwie kolejki i trzy formaty pośrednie, problem zwykle nie tkwi w modelu.
Kryteria decyzji przed wyborem storage’u i pipeline’u
Przed rozmową o technologiach odpowiedz na kilka pytań w konkretnej kolejności:
- Ile danych jest czytanych w jednym przebiegu i jak często ten przebieg się powtarza?
- Czy dominują duże sekwencyjne skany, czy mnóstwo małych losowych odczytów?
- Czy dane muszą być transformowane przy każdym użyciu, czy można je przygotować wcześniej?
- Jakie są wymagania SLA: przepustowość, opóźnienie, przewidywalność, koszt?
- Ile granic sieciowych przekraczają dane po drodze do modelu?
Jeśli na te pytania nie ma odpowiedzi, projekt architektury danych pod AI staje się zgadywaniem. A zgadywanie przy obciążeniach AI najczęściej kończy się przewymiarowaniem compute przy niedoszacowanej ścieżce danych.
Krok 2. Narysuj pełną ścieżkę danych od źródła do modelu i policz każde kopiowanie
Mapa przepływu, bez której optymalizacja jest zgadywaniem
Najwięcej problemów z I/O bierze się stąd, że zespół nie widzi całej drogi danych. Widzi model, widzi źródło, ale nie widzi wszystkich etapów pomiędzy. Tymczasem to właśnie te etapy decydują, czy system będzie szybki, czy będzie się dusił na transferach. Trzeba rozpisać pełną trasę: źródło danych, typ storage’u, format wejściowy, job transformujący, format pośredni, cache, staging lokalny, proces treningowy lub inferencyjny oraz zapis wyników.
Dla każdego etapu dobrze jest odpowiedzieć na cztery proste pytania: skąd dane są czytane, jak często, w jakiej porcji i kto je transformuje. Dopiero po takim rozrysowaniu widać, ile razy ten sam rekord jest de facto kopiowany albo przebudowywany. Często okazuje się, że dane przechodzą przez kilka usług nie dlatego, że to konieczne, lecz dlatego, że tak wygodniej było rozdzielić odpowiedzialności. Z punktu widzenia wydajności to bywa bardzo kosztowny luksus.
Osobno trzeba oznaczyć granice sieciowe: strefę, region, chmurę, VPC, node, kontener, a czasem nawet bibliotekę klienta wykonującą dodatkowe requesty do metadanych. To miejsca, gdzie pojawiają się opóźnienia i koszty egressu. W praktyce wiele pipeline’ów wygląda dobrze na diagramie logicznym, ale źle na fizycznym, bo compute jest odseparowany od danych o jedną lub dwie warstwy dalej, niż zakładano.
Jak liczyć kopiowanie i narzut pośrednich warstw
Każde kopiowanie danych trzeba potraktować jak koszt, który musi się obronić. Jeśli ścieżka wygląda tak: storage obiektowy → ETL → feature store → cache → job treningowy → lokalny staging, to każda warstwa powinna mieć wyraźną funkcję. Czy zmniejsza koszt odczytu? Czy poprawia lokalność? Czy upraszcza wersjonowanie? Czy obniża opóźnienie? Jeśli odpowiedź brzmi „nie”, warstwa może być tylko dodatkowym hamulcem.
Szczególnie zdradliwe są konwersje formatów i serializacja między usługami. Sam transfer bajtów to nie wszystko. Czasem największy koszt pochodzi z tego, że dane są kolejno pakowane, rozpakowywane, mapowane do nowej struktury i znów zapisywane. Gdy taki cykl powtarza się przed każdą epoką treningu albo przy każdym żądaniu inferencyjnym, narzut staje się systemowy.
W praktyce dobrze działa zasada: nie kopiuj, jeśli wystarczy wskazać; nie serializuj, jeśli można współdzielić gotowy układ; nie transformuj za każdym razem, jeśli transformacja jest stabilna i da się ją policzyć wcześniej. To nie znaczy, że każda warstwa pośrednia jest zła. Znaczy tylko tyle, że musi zarabiać na swoje istnienie wydajnością, prostotą operacyjną albo izolacją krytycznych ścieżek.
Krótki scenariusz: co może pójść nie tak
Typowy problem pojawia się przy wdrożeniu RAG. Dokumenty trafiają do storage’u obiektowego, osobny job czyta je i buduje chunki, potem inna usługa wylicza embeddingi, jeszcze inna zapisuje je do bazy wektorowej. Na końcu aplikacja podczas zapytania pobiera wyniki z bazy wektorowej, ale pełny tekst chunków dociąga z innego miejsca. Efekt: kilka odczytów sieciowych na jedno zapytanie, dwa źródła prawdy i duży koszt przy odświeżaniu indeksu.
Da się temu zapobiec już na etapie mapy przepływu. Jeśli baza wektorowa i storage dokumentów nie są projektowane jako jeden spójny tor dostarczania kontekstu, system będzie cierpiał nie tylko na opóźnienie, ale też na niespójność danych. Czasem lepsza okazuje się prostsza architektura z preobliczonymi chunkami, ograniczoną liczbą transformacji i wyraźnym stagingiem przed aktualizacją indeksu.
W podobny sposób psują się też prostsze pipeline’y scoringowe. Dane wejściowe są w hurtowni, potem eksport do plików, potem kolejny job buduje cechy, a serwis inferencyjny i tak pobiera część informacji jeszcze raz z operacyjnej bazy danych, bo „tam są najświeższe”. Jeśli nie ustali się jednego, kompletnego zestawu wejść dla modelu i nie zaprojektuje ścieżki ich dostarczania od początku do końca, opóźnienie zaczyna zależeć od najwolniejszego elementu całego łańcucha. Często nie jest to model, tylko drobny odczyt z miejsca, którego nikt nie uznał za krytyczne.
Najprostsza metoda obrony jest mało spektakularna, ale skuteczna: dla każdej ścieżki krytycznej policzyć liczbę odczytów, liczbę zapisów, liczbę przejść przez sieć i liczbę transformacji formatu. Jeśli jeden request do modelu wymaga kilku osobnych fetchy kontekstu, deserializacji po drodze i dodatkowego dociągania metadanych, to problem jest architektoniczny. Jeśli pełny retraining zaczyna się od ponownego budowania tych samych artefaktów, które mogły być przygotowane wcześniej i używane wielokrotnie, to problemem jest brak decyzji o materializacji danych, nie brak mocy obliczeniowej.
Dobry projekt zwykle upraszcza tor danych zamiast go „usługizować” bez końca. Jeśli transformacja jest stabilna, policz ją wcześniej. Jeśli model czyta dane zawsze w tym samym układzie, zapisz je w tym układzie. Jeśli inferencja wymaga lokalności, przesuń dane bliżej compute albo przygotuj warstwę cache dokładnie pod ten wzorzec odczytu. Takie decyzje są nudniejsze niż wybór nowego silnika czy bazy, ale to one decydują, czy GPU liczy, czy czeka.
Architektura danych pod AI zaczyna się więc nie od modelu, tylko od dyscypliny w projektowaniu ruchu danych: mniej przypadkowych kopiowań, krótsza ścieżka, mniej granic sieciowych i format dopasowany do realnego sposobu czytania.
Krok 3. Dobierz układ danych pod sposób czytania, nie pod wygodę producenta danych
Format ma przyspieszać odczyt, a nie tylko ułatwiać eksport
Najczęstszy błąd wygląda niewinnie: dane są zapisywane w takim formacie, jaki najłatwiej było wygenerować po stronie źródła. Potem ten wybór mści się na etapie treningu, batchowej inferencji albo budowy embeddingów. Jeśli model czyta duże porcje rekordów i przechodzi przez nie sekwencyjnie, układ danych powinien wspierać duże, przewidywalne odczyty, a nie tysiące drobnych operacji.
Jeśli dominują skany i filtrowanie po wybranych kolumnach, zwykle wygrywają formaty kolumnowe albo rekordowe zoptymalizowane pod batch. Jeśli obciążenie polega na losowym pobieraniu małych fragmentów, ważniejsze stają się rozmiar obiektu, indeks pomocniczy, koszt otwarcia pliku i skuteczność cache. Ten sam zestaw danych może być poprawny analitycznie, a jednocześnie fatalny operacyjnie, jeśli jego fizyczny układ nie pasuje do wzorca odczytu.
W praktyce decyzja o formacie powinna wynikać z trzech pytań:
- czy dane są czytane całymi porcjami, czy wybierane punktowo,
- czy odczyt wymaga wielu kolumn, czy tylko niewielkiego wycinka,
- czy preprocessing ma się odbywać podczas użycia, czy wcześniej.
Jeśli odpowiedzi wskazują na powtarzalny, stabilny sposób użycia, lepiej przygotować dane dokładnie pod ten przypadek niż zostawiać „uniwersalny” format i płacić koszt konwersji przy każdym przebiegu.
Małe pliki to nie detal, tylko osobna klasa awarii
W systemach AI problemem bywa nie tylko liczba bajtów, ale liczba obiektów. Setki tysięcy małych plików potrafią zabić wydajność szybciej niż jeden duży dataset. Każdy plik to dodatkowe operacje listowania, otwarcia, pobrania metadanych, autoryzacji i zamknięcia. Jeśli job treningowy albo embeddingowy musi wykonać to tysiące razy na worker, GPU zaczyna czekać nie na transfer treści, ale na narzut organizacyjny wokół odczytu.
To samo dotyczy dokumentów w RAG. Jeżeli każdy chunk żyje jako osobny obiekt, a aplikacja przy jednym zapytaniu wykonuje wiele drobnych odczytów z remote storage, opóźnienie szybko staje się niestabilne. Lepiej rozważyć pakowanie danych w większe segmenty, przygotowanie indeksu lokalizacji albo utrzymanie warstwy cache dla najczęściej używanego kontekstu.
Sygnały ostrzegawcze są dość czytelne:
- czas startu joba rośnie nieproporcjonalnie do wolumenu danych,
- średnie zużycie CPU po stronie transformacji jest niskie, ale liczba operacji I/O bardzo wysoka,
- storage lub API metadanych dostaje ogromną liczbę drobnych requestów,
- przepustowość sieci wygląda „nisko”, a mimo to pipeline jest wolny.
Jeśli te objawy występują razem, problemem zwykle nie jest brak pasma, tylko zbyt rozdrobniony układ danych.
Partycjonowanie ma ograniczać zbędny odczyt
Partycjonowanie pomaga tylko wtedy, gdy odpowiada na realny filtr używany przez pipeline. Jeśli dane są dzielone według klucza wygodnego dla procesu ingestu, ale trening i inferencja filtrują po czymś innym, system nadal czyta za dużo. Wtedy partycja istnieje, ale nie pracuje.
Dobra praktyka jest prosta: partycjonuj według tego, co najczęściej odcina duży procent niepotrzebnych danych. Dla jednych pipeline’ów będzie to czas, dla innych tenant, język, typ dokumentu, segment produktu albo wersja zbioru. Jeśli model niemal zawsze korzysta z ostatniego wycinka danych, brak takiego podziału oznacza regularne skanowanie znacznie większego wolumenu niż potrzeba.
Źle dobrane partycjonowanie daje dwa skrajne skutki. Albo powstają ogromne partycje, które i tak trzeba długo skanować, albo bardzo drobne, które ponownie wpadają w pułapkę małych plików. Granica sensowności zależy od charakteru workloadu, ale kryterium jest zawsze to samo: czy jedna operacja czyta dokładnie to, czego potrzebuje, bez nadmiarowych odwołań do storage’u.
Kiedy materializować transformacje, a kiedy zostawić je „w locie”
Transformacje wykonywane przy każdym użyciu wyglądają elastycznie, ale często są ukrytym podatkiem od I/O. Jeśli ten sam cleaning, tokenizacja, chunking, łączenie cech albo normalizacja powtarzają się dla tych samych danych, zwykle taniej jest policzyć je wcześniej i zapisać gotowy wynik. Dotyczy to szczególnie treningu iteracyjnego i RAG z częstym odczytem tego samego korpusu.
Przetwarzanie „w locie” ma sens wtedy, gdy dane są bardzo świeże, logika zmienia się często albo koszt materializacji byłby większy niż koszt powtarzanych odczytów. Jeśli jednak pipeline wielokrotnie uruchamia te same etapy, a każdy przebieg zaczyna się od odczytu surowego formatu i pełnej przebudowy artefaktów, architektura sama generuje swoje opóźnienie.
Krótki test decyzyjny:
- Jeśli transformacja jest deterministyczna i używana wielokrotnie, materializuj.
- Jeśli wynik jest ciężki do obliczenia, ale tani do przechowywania, materializuj.
- Jeśli logika zmienia się codziennie lub dane są jednorazowe, licz „w locie”.
- Jeśli pipeline miesza oba podejścia, oddziel warstwę stabilną od zmiennej.
Krok 4. Zaprojektuj transfer i lokalność danych tak, by compute nie czekał
Najtańszy transfer to ten, którego nie trzeba wykonać
Przy obciążeniach AI łatwo skupić się na przepustowości łącza i pominąć prostsze pytanie: czy te dane w ogóle muszą podróżować. Jeśli trening działa w innym regionie niż storage, jeśli embeddingi są liczone poza miejscem przechowywania dokumentów, jeśli serwis inferencyjny przy każdym żądaniu pobiera cechy z odległej warstwy pośredniej, to system regularnie płaci za własny brak lokalności.
Najpierw trzeba