Jedna z wrocławskich firm technologicznych kupiła „superserwer AI” za ponad dwa miliony złotych. 8 GPU, złote logo, efektowny rack w serwerowni. Na prezentacjach – petaflopy. W praktyce – model językowy, który przy większej liczbie użytkowników zaczyna czkać jak przeglądarka na starym laptopie.
Kilka miesięcy później ta sama firma stawia obok znacznie skromniej wyglądający węzeł za około 400 tysięcy złotych. Mniej marketingu, mniej logotypów, za to… więcej wyników. Ten „tańszy” serwer dowozi więcej gotowej pracy na modelach LLM. Gdzie jest haczyk? W niewidzialnym podatku hopów – każdej dodatkowej warstwie połączeń między GPU a GPU, GPU a CPU, serwerem a serwerem. I w tym, czy ktoś w ogóle policzył, ile ten podatek kosztuje w złotówkach, a nie tylko w ładnych slajdach.
Niewidzialny podatek operacyjny – o co tu w ogóle chodzi?
Każdy dodatkowy element na ścieżce danych to nie tylko opóźnienie, ale też realne pieniądze i dodatkowe ryzyko dla projektu. W uproszczeniu: w klastrach AI/HPC każde kolejne urządzenie pośredniczące między obliczeniami – hop – dokłada swoją porcję opóźnień i złożoności. Pojedynczy hop (przełącznik, mostek, retimer, kabel między szafami) może wprowadzać opóźnienie liczone w mikro- lub milisekundach oraz powodować zjawisko jitter (wahania opóźnienia). W pojedynczym serwerze można to czasem przełknąć, ale w dużym klastrze AI te mikro-przystanki sumują się wykładniczo wraz z liczbą GPU, węzłów i zadań. Efekt? Wydajność modeli skalujących się na dziesiątki kart graficznych zaczyna drastycznie spadać, a opóźnienia komunikacji ograniczają korzyść z dokładania kolejnych GPU.
Definicja „hopu”:
Hop to każdy „skok” pakietu danych w infrastrukturze – z GPU przez przełącznik, z jednego serwera do drugiego, z jednej szafy rack do kolejnej. Dla aplikacji AI każdy taki skok to mały przystanek na drodze danych. Dziesiątki takich przystanków potrafią zsumować się do opóźnień liczonych już w sekundach, a ich koszt można liczyć w bardzo konkretnych złotówkach.
Czytaj też w Fakty Plus – Od chmury do własnej serwerowni: nowa fala lokalnej AI w polskich firmach
Dlaczego to ważne? Bo opóźnienia to nie abstrakcja – przekładają się na gorsze skalowanie modeli. Przy równoległym trenowaniu (czy to data parallel, tensor parallel, czy pipeline parallel) duże opóźnienia oznaczają, że GPU czekają bezczynnie na siebie nawzajem. Im więcej „hopów”, tym więcej potencjalnych konfliktów sprzętowych i programowych: każdy element ma własny firmware, który może wymagać innej wersji sterownika, a im więcej elementów, tym trudniejsze testowanie całości. W rezultacie klaster może płacić ukryty podatek operacyjny: za niewykorzystane moce obliczeniowe, za nadgodziny inżynierów walczących z konfiguracją i za prąd, który idzie na bezczynnie czekające komponenty.
Skala problemu jest niemała. Według Gartnera globalne wydatki na sztuczną inteligencję sięgną prawie 1,5 bln USD już w 2025 roku, z czego ponad 267 mld USD firmy wydadzą na same serwery AI i akceleratory. Każdy procent niewykorzystanej mocy to zatem realnie miliardy złotych wyrzucone w błoto. A takich strat jest sporo – przy dużych klastrach GPU sieciowe opóźnienia potrafią drastycznie zmniejszyć efektywność: nierzadko GPU pracują realnie tylko na ~50% swoich możliwości. Innymi słowy, połowa tego, za co zapłacono, marnuje się przez architekturę komunikacji. W skrajnych przypadkach jedna wolniejsza karta potrafi spowolnić tysiące pozostałych – przykładowo opóźnienie rzędu 20 µs u jednego „marudzącego” GPU może dodać aż 0,2 sekundy zbiorczego przestoju w klastrze 10 000 GPU. A 0,2 sekundy razy 10 000 – to już odczuwalny koszt przepalanych w bezczynności cykli obliczeń.
„Z podobnymi wyzwaniami mierzą się też globalni dostawcy sztucznej inteligencji – nie brak najnowszych GPU, lecz architektura ich połączeń okazuje się często wąskim gardłem”
— przyznaje Łukasz Woźniak, analityk ds. infrastruktury centrów danych.
Nic dziwnego, że coraz więcej firm zaczyna patrzeć nie na liczbę GPU w serwerze, ale na to, jak są połączone i ile z ich mocy faktycznie da się wycisnąć.
Podatek hopów rozbity na czynniki pierwsze
Z jakich konkretnie „składek” składa się ów podatek hopów? Poniżej rozbijamy go na kilka kluczowych kategorii – każdy to osobny, ukryty koszt spadku wydajności i złożoności, który pojawia się w rozległych konfiguracjach.
Latencja i jej zmienność. Teoretycznie masz w specyfikacji np. 200 Gb/s przepustowości między węzłami, ale w praktyce model potrafi stać w miejscu, czekając na spóźnione gradienty z innego GPU. Gdy przybywa hopów (kolejne switche, mostki, połączenia zdalne), efektywna przepustowość spada nierzadko o dziesiątki procent. Co gorsza, opóźnienie bywa nierównomierne – zmienność sprawia, że czas dostarczenia danych waha się, więc nawet jeśli średnia latencja jest do zaakceptowania, to pojedynczy spóźnialski w klastrze może spóźnić się na synchronizację i przyblokować całą resztę. W masywnych klastrach potrzeba deterministycznie niskich opóźnień – każde dodatkowe 20 µs w jednym wątku może zamrozić tysiące innych GPU na łączną 0,2 sekundy bezczynności, co przekłada się na wymierne koszty zmarnowanych cykli obliczeń.
Rozjazdy firmware. Każdy element ma swoje oprogramowanie układowe: GPU, karty sieciowe (NIC), przełączniki, repeatery/retimery sygnału, kontrolery BMC, BIOS… Im więcej elementów, tym większa szansa, że wersje firmware się rozjadą. Aktualizacja jednego komponentu może wprowadzić konflikt z innym – nagle np. nowe firmware przełącznika nie dogaduje się ze starszym sterownikiem karty sieciowej w serwerze. Przy rozbudowanych topologiach zarządzanie matrycą kompatybilnych wersji staje się koszmarem. Każda aktualizacja to ryzyko (a rollback nie zawsze jest prosty), więc często firmy boją się aktualizować czegokolwiek, żeby nie popsuć kruchej równowagi – a to znaczy, że trudno korzystać z poprawek wydajności czy bezpieczeństwa.
Walidacja i burn-in. Rozbudowana sieć to wykładniczo więcej scenariuszy do przetestowania. Gdy dodasz dodatkowe łącza i przełączniki, zwykły burn-in nowego klastra (testy obciążeniowe „na gorąco”) musi objąć znacznie więcej przypadków. Trzeba sprawdzić długotrwałą stabilność (testy obciążeniowe 24–72h), różne topologie komunikacji, obciążenie wszystkimi GPU naraz, odporność na utratę pojedynczego linku itp. Jeśli wprowadzamy aktualizację firmware czy sterowników, trzeba powtarzać regresję testów. To dodatkowe dni robocze inżynierów, kiedy sprzęt nie robi tego, do czego go kupiono – czyli nie liczy Twojego modelu.
Zarządzanie okablowaniem. Kable to pozornie prozaiczny temat, ale w złożonych klastrach bywają piętą achillesową. Wiązki grubych przewodów i modułów optycznych mogą utrudniać przepływ powietrza (podnosząc temperatury pracy sprzętu), a z czasem gromadzą kurz. Pomyłki przy wpinaniu to klasyka (tu pomylony port, tam wadliwy transceiver). Do tego dochodzą niuanse techniczne: polaryzacja torów w kabelku DAC/AOC, zgodność EEPROM – jeśli ktoś będzie nieuważny, to prędzej czy później zafunduje sobie czkawkę w nocy podczas pracy klastra. Przy rozległej infrastrukturze konieczna jest wręcz inwentaryzacja i system etykiet dla kabli, inaczej patchowanie (przepinanie) na szybko może skończyć się chaosem.
Zużycie mocy. Każdy aktywny element na ścieżce danych pobiera prąd i wydziela ciepło. Retimer sygnału na przedłużce PCIe x16 potrafi zjeść kilka watów, duży przełącznik Ethernet – nawet kilkaset watów. Wat tu, wat tam – i nagle mamy +500 W na rack tylko na infrastrukturę sieciową (poza samymi serwerami). To dodatkowe kilowatogodziny, które obciążają budżet energetyczny firmy, i dodatkowe ciepło, które musi odebrać klimatyzacja w serwerowni (co z kolei znów zwiększa pobór mocy). Zbyt wysoka temperatura zmusza do redukcji wydajności.
„Najdroższy serwer to nie ten za miliony, tylko ten, którego GPU się nudzą. U większości klientów widzimy, że realnie używają do 50% tego, za co zapłacili.”
— Krzysztof Wójcik, architekt infrastruktury AI w DeepFORCE Servers.
Powyższe „podatki” sprawiają, że łatwo przeinwestować w sprzęt, który na papierze ma petaflopy, a realnie połowa flopsów przecieka bokiem. To nie teza marketingowa, a fakt odnotowany w branżowych analizach: złożone systemy GPU często osiągają tylko 35–45% teoretycznej wydajności. To tak, jakby z 8 kupionych GPU działały efektywnie może 3–4, reszta zaś czeka na swoją kolej.
Nic dziwnego, że coraz więcej przedsiębiorstw przy planowaniu inwestycji patrzy nie tylko na liczbę GPU, ale przede wszystkim na to, jak są połączone i ile z ich mocy faktycznie da się wykorzystać.
Serwer „za miliony” kontra węzeł „za 400 tysięcy”
Skonfrontujmy teorię z praktyką. Wspomniana na wstępie historia wrocławskiej firmy to wcale nie odosobniony przypadek, lecz dość typowy case z pola bitwy AI. Scenariusz wyglądał tak: firma inwestuje w bardzo drogi klaster „AI” – flagowy, markowy sprzęt z najwyższej półki. Konfiguracja ze slajdów: maksymalna liczba GPU w jednej obudowie, do tego półka dyskowa i pełna sieć 400 GbE między serwerami. Na papierze – światowa liga. W praktyce – zaczęły się schody.
Problem:
Zespół data science próbował uruchomić duży model językowy (LLM) dla wewnętrznych potrzeb firmy. Przy małej skali wszystko działało, ale gdy tylko próbowali skalować zadanie na kolejne GPU, zyski z dokładania sprzętu okazały się znikome. Skalowanie modelu kulało – kolejne karty graficzne dawały coraz mniejszy przyrost szybkości trenowania i inferencji. Co gorsza, przy większej liczbie użytkowników korzystających z modelu naraz odpowiedzi zaczęły mieć losowe opóźnienia (objawiało się to właśnie „czkawką” – czasem model długo milczał po zadaniu pytania). Dział biznesowy był sfrustrowany: miało być przecież cudowne AI, a tymczasem dział IT tłumaczył się z kolejki zgłoszeń i nierównej wydajności.
Analiza DeepFORCE:
Wezwani na ratunek inżynierowie DeepFORCE Servers szybko rozpracowali topologię „superserwera”. Okazało się, że za wieloma logotypami premium kryje się po prostu rozproszona architektura z wieloma hopami. Owszem, w jednej obudowie było 8 GPU – ale tak naprawdę podzielone na dwa mniejsze moduły, komunikujące się przez dodatkowy wewnętrzny przełącznik. Do tego każdy moduł GPU kontaktował się z macierzą dyskową przez osobny switch w sieci. Suma summarum: dane musiały pokonać kilka „mostków”, nim wszystkie GPU mogły się ze sobą dogadać i zgrać obliczenia. Audyt telemetrii potwierdził masę czekania GPU na siebie nawzajem. Przy każdej synchronizacji gradientów między modułami pojawiały się wąskie gardła. Rzecz jasna, żaden slajd marketingowy nie wspominał o tym ukrytym podatku.
Remedium:
Zespół DeepFORCE zaproponował podejście „topologia najpierw, zakupy potem”. Zaprojektowano rozwiązanie oparte na kilku mniejszych węzłach GPU (każdy za ok. 300–400 tys. zł), ale o krótszych ścieżkach komunikacji. Konkretnie: każdy węzeł miał mniej GPU (np. 4-6 zamiast 8), za to wszystkie te układy komunikowały się lokalnie, bezpośrednio w ramach jednej płyty (bez dodatkowego switcha). W razie potrzeby węzły łączyły się ze sobą prostym fabriciem sieciowym, ale architektura modelu została dobrana tak, by większość ruchu odbywała się wewnątrz jednego węzła, a nie między węzłami. Mówiąc obrazowo – zamiast jednego „autobusu przesiadkowego” z wieloma stacjami, zbudowano kilka szybkich minibusów jadących bezpośrednio do celu.
Efekt:
W skali całego zadania LLM okazało się, że węzeł za 400 tys. zł potrafi dowieźć więcej tokenów na minutę niż wypasiony flagowiec za miliony. Mniejsza liczba GPU, ale idealnie zszytych komunikacyjnie, wygrała z teoretycznie mocniejszą maszyną obarczoną zbyt wieloma hopami. Co więcej, roczny koszt utrzymania okazał się dramatycznie niższy dla prostszej topologii. Zgrupowanie obciążenia na kilku mniejszych, homogenicznych modułach uprościło też utrzymanie – awaria pojedynczego tańszego węzła bolała mniej niż ewentualna awaria jedynego „okrętu flagowego”.
Force Rank:
Inżynierowie DeepFORCE Servers opracowali wewnętrzny wskaźnik Force Rank, który praktyczniej ocenia konfiguracje AI niż same gigaherce czy waty. Zamiast liczyć wyłącznie liczbę GPU w serwerze, Force Rank łączy moc obliczeniową ze „składką” za opóźnienia, topologię połączeń i efektywność wykorzystania mocy na dużych modelach. Okazuje się, że serwer z mniejszą liczbą GPU, ale za to z krótszą ścieżką komunikacji i dobrze dobraną warstwą storage, potrafi mieć wyższy Force Rank niż marketingowa „bryka” z katalogu. W praktyce to taki sprzęt dowozi więcej wyniku przeliczonego na złotówkę – i to on wygrywa, gdy porównać rzeczywistą pracę wykonaną na modelach LLM.
Dzięki takiemu podejściu firma z Wrocławia zobaczyła wreszcie efekt obiecywany przez AI: model językowy zaczął sprawnie obsługiwać użytkowników, GPU przestały się nudzić, a dział biznesowy wreszcie miał podstawy chwalić AI zamiast składać reklamacje. Historia ta idealnie ilustruje główną myśl: ważniejsze od tego, ile kupisz GPU, jest jak je połączysz i wykorzystasz.
Zestawienie porównawcze – konfiguracja „flagowa” vs. zoptymalizowany węzeł DeepFORCE:
| System AI | GPU (szt.) | Warstwy komunikacji (hop) | Efektywny throughput<br/>(tokeny na minutę) | Szac. TCO/rok<br/>(zł) |
| „Superserwer” ~2 000 000 zł | 8 | 2 (np. moduły GPU + przekaźnik) | ~30 000 | ~800 000 |
| „Węzeł” ~300 000 zł | 4 | 0–1 (lokalne GPU bez pośredników) | ~36 000 | ~200 000 |
Czy Twój dostawca sprzedaje GPU, czy wydajność?
Powyższy case ujawnia szerszy problem rynku: wielu dostawców sprzedaje klientom liczbę GPU, a nie realną wydajność. Gdy firmy ruszyły na zakupy akceleratorów AI, niektórzy integratorzy traktowali klaster AI jak zwykłe wyposażenie biura – „proszę osiem GPU, jedną macierz i do tego sieć 200 GbE”. Tyle, że wydajność AI to nie meble, które wystarczy wstawić do pokoju. Tu liczy się architektura i szczegóły integracji, a nie tylko suma komponentów.
Inżynierowie DeepFORCE często są wzywani do projektów, gdzie „na papierze” wszystko powinno hulać, a w rzeczywistości mocne serwery przynoszą mizerny rezultat. Typowy obrazek: ktoś zamówił drogi sprzęt, ale nie zapytał, jak modele będą ze sobą rozmawiać. Dostawca dostarczył to, o co go proszono – np. klaster dwóch szaf GPU, do tego jakaś macierz i szybka sieć – lecz zabrakło refleksji nad topologią. Potem okazuje się, że łącza są „przytkane”, opóźnienia rosną kaskadowo, a konfiguracja firmware woła o pomstę do nieba, bo każda półka serwera ma inny zestaw wersji.
Sprzedawcy rozwiązań AI często optymalizują oferty pod maksymalne upakowanie komponentów (bo to dobrze wygląda w specyfikacji). Jeśli klient mówi „chcę 8 GPU”, to dostanie 8 – choćby miały być wciśnięte na siłę i komunikować się przez wąskie gardło. Rzadko pada pytanie: „A jaka będzie latencja fabricu między tymi GPU? Czy one będą mogły pracować w lockstepie?” Dopiero gdy projekt nie daje wyników, zaczyna się szukanie winnych. Niejednokrotnie właśnie tu DeepFORCE wchodzi do gry – jako „doktor od GPU” po nieudanych wdrożeniach.
„Najbardziej spektakularne porażki widzieliśmy tam, gdzie ktoś zamówił klaster AI jak meble do biura: proszę dwie szafy GPU, jedną macierz i 400 GbE. Nikt nie zapytał, jak te modele będą naprawdę rozmawiać między sobą.”
— Zbigniew Raczyński, inżynier ds. wydajności w DeepFORCE Servers.
Ta brutalna lekcja rynku sprawia, że coraz częściej klienci pytają: czy mój dostawca potrafi sprzedać mi wydajność zamiast ton sprzętu? Bo finalnie nie chodzi o to, by mieć więcej „zabawek” w serwerowni, tylko żeby modele działały szybciej i płynniej.
Właśnie dlatego DeepFORCE woli pełnić rolę partnera, a nie tylko dostawcy pudełek. Zanim dostarczy klientowi sprzęt, najpierw inżynierowie pytają o specyfikę modelu, wolumen danych, typy zadań AI i plany rozwoju. Często okazuje się, że najlepsze wyniki da nie największy i najdroższy klaster, ale mądrzejsza architektura: może mniej GPU, za to bliżej siebie; może prostsza sieć, ale stabilna i przewidywalna.
Jak nie przepłacać za TFLOPS-y: 10 zasad architektury AI bez ukrytych podatków
Skoro wiemy już, gdzie czają się „hopy” pożerające Twoje TFLOPS-y, czas na konkrety. Poniżej dziesięć pragmatycznych zasad projektowania infrastruktury AI, które pozwolą zminimalizować ukryty podatek hopów. To checklista opracowana na bazie doświadczeń DeepFORCE – do powieszenia nad biurkiem każdego CTO i administratora planującego kolejny zakup GPU.
Najpierw topologia, potem zakupy. Zanim wóz techniczny przywiezie do Ciebie pudełka z GPU, zaplanuj graf komunikacji Twojego modelu. Przeanalizuj, jak będzie przebiegał przepływ danych między etapami treningu/inferencji (czy dominować będzie równoległość danych, czy może dzielone tensorowo warstwy, a może pipeline). Dopiero pod ten schemat dobieraj fabric sieciowy i układ węzłów. Innymi słowy – architekturę logiczną przekuj na fizyczną, nie odwrotnie.
Preferuj krótsze ścieżki
Gdzie się da, trzymaj komponenty blisko siebie. Lepiej mieć jeden węzeł z 8–10 GPU komunikującymi się bezpośrednio (np. przez wspólny backplane), niż rozproszony klaster łączony dodatkowymi przełącznikami. Każda warstwa sieci między GPU to potencjalne +10–20 µs latencji – czasem mniej GPU, ale bliżej siebie, da więcej niż dokładanie kolejnych kart „za przełącznikiem”.
Ujednolicaj warstwy. Postaw na jednorodność w ramach jednej warstwy infrastruktury. W jednym segmencie sieci trzymaj się jednej generacji technologii (np. PCIe 4.0 albo 5.0 – unikaj mieszania), jednego dostawcy kart sieciowych, jednego typu optyki czy kabli. To samo tyczy się długości kabli DAC/AOC – staraj się, by były jednakowe tam, gdzie to możliwe. Każda dodatkowa różnorodność to nowe możliwości konfliktów i trudniejsze debugowanie.
Buduj „złotą” matrycę firmware
Przygotuj listę sprawdzonych wersji firmware/sterowników dla każdego elementu (GPU, NIC, switche, BIOS płyty głównej, BMC itd.). To będzie Twoja „złota” konfiguracja – punkt wyjścia, przy którym wiesz, że wszystko ze sobą działa. Wprowadzaj aktualizacje ostrożnie i zawsze z planem awaryjnym. Dokumentuj zmiany. Dzięki temu unikniesz sytuacji, że upgrade BIOS-u nagle obniży Ci throughput między GPU, bo np. zmieniły się parametry PCIe.
Testuj realistycznie
Zanim oddasz klaster w ręce data scientistów, sam spróbuj go „zepsuć” testami. Odpal 24–72 godzinne testy obciążeniowe, puść próbne treningi na różnych wielkościach batchy, różnych długościach sekwencji (jeśli to LLM-y), sprawdź, jak system reaguje, gdy zasymulujesz utratę jednego linku sieci (czy algorytmy komunikacji przeżyją?). Lepiej wykryć niestabilność czy błędy wcześniej niż w środku ważnego treningu modelu. Pamiętaj też, by testować różne scenariusze jednocześnie – prawdziwe obciążenie rzadko jest jednorodne.
Mierz, nie zgaduj
Zainwestuj w telemetrię i monitoring, które pokażą Ci prawdę o opóźnieniach. Statystyki średnie to za mało – patrz na histogramy latencji, 95/99 percentyle. Włącz funkcje typu PFC/ECN (Priority Flow Control, Explicit Congestion Notification), jeśli używasz Ethernetu do AI – pomogą zauważyć, czy masz gubienie pakietów albo zatykanie sieci. Ustaw alerty na flapping portów (niestabilne linki) i błędy CRC – często to one sygnalizują problemy z kablami lub złączami zanim jeszcze wszystko runie.
Prosty magazyn części
Planując sprzęt, od razu zaplanuj N+X na krytyczne elementy: dodatkowe kable, transceivery, wentylatory, zapasowe moduły zasilania, jedną kartę NIC na zapas itp. Dzięki ujednoliceniu (zasada nr 3) nie musisz mieć zoo różnych części – wystarczy po kilka sztuk z każdego typu. Pilnuj jednak numerów rewizji: zamów dokładnie te same modele komponentów, jakie masz w klastrze, bo „prawie to samo” czasem nie zadziała (np. inna rewizja modułu optycznego może mieć inny firmware!). Gdy coś padnie, czas naprawy (MTTR) leci – nie chcesz wtedy gorączkowo szukać na rynku zamiennika, którego nikt nie ma na stanie.
Z góry licz koszty operacyjne
Nie daj się zaskoczyć rachunkom za prąd i licencje. Policz waty na port dla swojej sieci, policz ile to będzie kWh rocznie i pomnóż przez cenę energii – ta liczba musi trafić do Twojego biznesplanu, bo może się okazać znacząca. Pomyśl o chłodzeniu: dodatkowe 500 W w rack to w uproszczeniu dodatkowe ok. 500 W obciążenia klimatyzacji. Dołóż koszty licencji software (np. czy Twój system monitoringu klastrów jest płatny per węzeł?) oraz – przede wszystkim – oszacuj, ile godzin pracy inżynierów pochłonie utrzymanie tej skomplikowanej układanki. Wlicz te wszystkie składniki do całkowitego kosztu posiadania systemu. Może się okazać, że te „drobiazgi” zjedzą Twój budżet szybciej niż zakup nowych GPU.
Segmentuj obciążenia
Nie wszystko musi korzystać z najszybszej możliwej ścieżki komunikacji. Jeśli masz różne typy zadań AI, pogrupuj je: treningi wymagające intensywnej komunikacji trzymaj na węzłach blisko siebie; z kolei inferencję batchową czy mniej wymagające analizy możesz „odpychać” dalej. Dzięki temu krytyczne workloady nie będą dzielić infrastruktury z tymi mniej wrażliwymi – i nie będą się nawzajem blokować.
Plan B na wzrost
Jeśli dziś planujesz klaster na styk, a wiesz, że za rok możesz potrzebować dołożyć GPU – zaprojektuj to od razu. Zostaw miejsce na dodatkowy switch w szafie, dodaj patchpanele i włókna światłowodowe „na zapas”, byś nie musiał wyłączać całej sieci, żeby coś dołożyć. Ale uwaga: nie montuj od razu wszystkiego, co przewidujesz, jeśli i tak nie będzie używane! Każdy nieużywany element to kolejny punkt potencjalnej awarii (i zbędny pobór prądu). Projektuj z myślą o przyszłej rozbudowie, lecz wdrażaj ją dopiero, gdy faktycznie będzie potrzebna.
Checklista anty-podatkowa dla klastrów AI:
– Topologia przed zakupami: zaprojektuj komunikację modelu zawczasu.
– Najkrótsze możliwe ścieżki komunikacji między GPU.
– Jednorodna infrastruktura w warstwach (ta sama generacja i vendor).
– „Złota” matryca firmware plus procedury update i rollback.
– Testy obciążeniowe 24–72 h, różne scenariusze i symulacje awarii.
– Telemetria i alerty: mierz opóźnienia i błędy, nie zgaduj.
– Magazyn części zamiennych: kable, moduły, wentylatory.
– Zaplanowane koszty operacyjne: energia, chłodzenie, licencje, roboczogodziny.
– Workloady krytyczne trzymaj blisko, mniej wrażliwe mogą iść dalej.
– Rozwój: miej plan na rozbudowę, ale nie dokładaj sprzętu „na wszelki wypadek”.
Szybkie reguły kciuka – decyzje „tu i teraz”
Powyższe zasady sprawdzają się na etapie planowania od zera. A co, jeśli już masz pewną infrastrukturę i musisz szybko zdecydować o rozbudowie lub zdiagnozować problem? Oto kilka szybkich reguł kciuka, którymi warto się kierować na co dzień:
Każdy nowy hop = planowany spadek skalowania. Jeśli dorzucasz kolejną warstwę sieci (np. dokładasz drugi switch między serwerami), z góry załóż, że wydajność per GPU spadnie. Czasem mniej GPU bliżej siebie da więcej niż więcej GPU oddalonych o dodatkowy hop.
Każdy nowy typ elementu = +1 do złożoności. Masz już karty NIC producenta X? Trzymaj się ich; nie dokładaj innego modelu Y „bo akurat był w promocji”. Podobnie z optyką – jeden standard transceiverów, jeden dostawca kabli, jedna generacja switchy na segment sieci. Im mniej mieszania, tym łatwiej zarządzać i diagnozować.
Aktualizuj partiami, nie wszystko na raz. Kuszące jest kliknąć „update all”, ale w klastrze AI to przepis na pobudkę w nocy. Wdrażaj nowe wersje oprogramowania najpierw na jednym węźle (canary), daj mu popracować, obserwuj. Dopiero potem aktualizuj resztę. I zdecydowanie nie rób masowych update’ów w piątek wieczorem – weekend z telefonem alarmowym gwarantowany.
Kable to też oprogramowanie. Traktuj okablowanie i połączenia jak element systemu, a nie „głupie druty”. Sprawdzaj zgodność modułów (EEPROM), opisuj kable etykietami, utrzymuj porządek w szafie rack. Wiele problemów z wydajnością bierze się z luźnych kabli, przegrzanych wtyków czy złamanych światłowodów. Ta niewidzialna część infrastruktury potrafi przysporzyć poważnych kłopotów, jeśli zostanie zaniedbana.
„Gdzie inni widzą kabel 200 Gb/s, my widzimy element grafu opóźnień. To różnica między serwerem za milion a serwerem, który naprawdę na siebie zarabia.”
— Tomasz Gajek, współzałożyciel i dyrektor ds. technologii DeepFORCE Servers.
Co z tego ma czytelnik? Konkrety przed kolejnym zakupem GPU
Przekładając powyższe rozważania na realia biznesowe: jak uchronić się przed przepłacaniem za GPU, które potem się nudzą? Jeśli jesteś dyrektorem finansowym, szefem IT czy CTO w firmie planującej inwestycje w AI, oto trzy pytania kontrolne, które musisz zadać swojemu dostawcy GPU zanim podpiszesz kolejną fakturę:
Ile hopów mają dane Twojego modelu między GPU (oraz między węzłami)? Poproś o prosty schemat topologii – rysunek, jak będą połączone komponenty, gdzie są przełączniki, mostki, szafy. Sama lista „8× GPU, 2× CPU, 1× switch” to za mało. Jeśli architekt rozwiązania sam nie potrafi klarownie pokazać ścieżki przepływu danych, to znaczy, że nikt tego nie policzył.
Jaka jest „złota” matryca firmware i plan aktualizacji? Innymi słowy: czy dostawca z góry przewidział, na jakich wersjach oprogramowania będzie działać cały klaster i co zrobi, gdy wyjdą nowe łatki? Czy jest procedura testowania i wycofania (rollback), czy usłyszysz raczej: „zobaczymy, jakoś to będzie”? Ustal też, kto odpowiada za całość – czy dostaniesz wsparcie end-to-end, czy będziesz samodzielnie łączyć pomoc różnych vendorów.
Jaka jest efektywna wydajność na złotówkę dla Twojego workloadu? Poproś o konkret: np. ile tokenów na sekundę uciągnie proponowany klaster na Twoim modelu (powiedzmy LLM 100B, batch 16) i ile złotych kosztuje jedna godzina takiej pracy, wliczając zużycie energii. Jeśli dostawca nie umie odpowiedzieć w liczbach, to sygnał ostrzegawczy – znaczy, że sprzedaje Ci mgłę marketingową. Solidny partner powinien znać te metryki albo chcieć je z Tobą zmierzyć przed sprzedażą.
Żeby zobrazować znaczenie powyższych pytań, zestawmy dwa podejścia: zakup „sprzętu na skróty” vs. zakup „wydajności z głową”. Pierwsze to przypadek superserwera, drugie – zoptymalizowanego węzła. Różnice widać nie tylko w cenie zakupu, ale przede wszystkim w efektywnym wykorzystaniu sprzętu:
Sprzętowy „flagowiec”: główny atut – dużo GPU w jednej obudowie. Niestety komunikacja między nimi przebiega przez kilka hopów (np. dodatkowe switche). Efekt: skalowanie słabe, realny throughput niższy od oczekiwań, GPU się nudzą. Roczny koszt operacyjny wysoki (bo prądożerny kolos, drogie wsparcie, licencje na każdy drobiazg).
Węzeł zoptymalizowany: mniej GPU, ale komunikacja bezpośrednia (lub z minimalną liczbą hopów). Mimo mniejszej mocy „na papierze”, dostarcza więcej wyników na minutę pracy. Tańszy w zakupie i w utrzymaniu – potrzebuje mniej energii, mniej chłodzenia, jest prostszy w obsłudze. W skali roku oszczędności idą w setki tysięcy, a wydajność per złotówka inwestycji bije flagowca na głowę.
Zakończenie: skąd się bierze game changer?
Prawdziwa rewolucja w AI nie dzieje się w błyszczących showroomach pełnych gadżetów, tylko w mozolnej inżynierii: w tabelkach opóźnień, wykresach wykorzystania GPU, matrycach kompatybilności firmware i długich logach z nocnych testów stabilności. To tam rodzą się optymalizacje, które decydują, czy klaster będzie kolejnym spalonym budżetem, czy też game changerem dla biznesu.
„Patrzymy na każdy dodatkowy hop jak na pozycję w arkuszu kalkulacyjnym: ma swój koszt, swoje ryzyko i konkretny wpływ na wynik. Jeśli tego nie policzyć, bardzo łatwo kupić serwer, który wygląda imponująco, ale na modelach zarabia połowę tego, co mógłby. Naszą rolą nie jest „wcisnąć” jak najwięcej GPU, tylko tak złożyć sprzęt, żeby z każdej wydanej złotówki wycisnąć jak najwięcej sensownej pracy modeli. Klienci nie muszą żyć w logach z testów obciążeniowych — od tego są inżynierowie. Od nich oczekujemy jednego: jasnej odpowiedzi, co ich AI ma realnie dowieźć.”
– Tomasz Gajek, dyrektor ds. technologii w DeepFORCE Servers.
Czy za takim podejściem pójdzie reszta rynku? Niekoniecznie. Na fali inwestycji w AI wciąż łatwiej jest sprzedać „szafę za milion” niż spokojnie policzyć ukryty podatek hopów i zaproponować klientowi tańszą, mniej efektowną marketingowo, ale rozsądniej zaprojektowaną architekturę. Dopóki budżety na projekty sztucznej inteligencji rosną szybciej niż świadomość efektywności i kosztów, dostawcy sprzętu nie będą mieli wielkiej motywacji, by samych siebie ograniczać. Rynek prędzej czy później pewnie wymusi tę zmianę – ale na razie inżynierowie tacy jak z DeepFORCE Servers pozostają raczej „frakcją optymalizacyjną” niż głównym nurtem wyścigu na coraz droższe konfiguracje.
