Przestań projektować infrastrukturę AI wokół GPU

Dlaczego MSP powinni zaczynać od obciążenia, a nie od sprzętu

Spędź pięć minut na konferencji AI, a łatwo uwierzysz, że każde udane wdrożenie AI zaczyna się od zakupu większej liczby GPU. Łatwo to zrozumieć. Sprzęt dominuje rozmowy. Klienci słyszą o systemach Blackwell, sieciach InfiniBand, chmurach hyperskalowych i coraz większych klastrach AI. Dostawcy naturalnie przyciągają najnowsze akceleratory i najszybsze systemy, ponieważ są ekscytujące, istotne i stosunkowo łatwe do wprowadzenia na rynek.

Problem nie polega na tym, że moc obliczeniowa nie ma znaczenia. Ma ona ogromne znaczenie.

Problem polega na tym, że zaczynanie od tego może skłonić organizacje do zadawania niewłaściwego pytania. Rynek AI nie znajduje się już w fazie eksperymentów. AI jest wprowadzane do produkcji, firmy inwestują prawdziwe pieniądze i oczekują wymiernych rezultatów biznesowych. Decyzje dotyczące infrastruktury stały się znacznie ważniejsze niż dwa lata temu. Jednak zbyt mało decyzji jest podejmowanych na podstawie wymagań biznesowych – wciąż dominują decyzje technologiczne.

Pierwszym pytaniem nie powinno być „Jakie GPU powinniśmy kupić?”

„Jakie obciążenie staramy się obsłużyć?” powinno być w centrum uwagi.

Ta pozornie niewielka zmiana wpływa na prawie każdą decyzję infrastrukturalną, która następuje później.

Nie ma standardowej infrastruktury AI

Jednym z największych nieporozumień na rynku jest przekonanie, że istnieje standardowy szablon infrastruktury AI. Nie ma takiego.

Mówimy o AI, jakby było jednorodnym obciążeniem. W rzeczywistości AI obejmuje ogromny wachlarz zastosowań biznesowych o bardzo różnych wymaganiach. Platforma AI do rozpoznawania mowy nie ma tych samych wymagań infrastrukturalnych co medyczne obrazowanie. Wyszukiwanie wiedzy różni się od generowania obrazów. Wykrywanie oszustw nie wygląda jak analityka predykcyjna i nie przypomina przetwarzania wideo. Wszystkie korzystają z AI. Po prostu wykorzystują infrastrukturę w inny sposób.

Nie projektujesz infrastruktury dla „AI”. Projektujesz infrastrukturę dla aplikacji biznesowej, która przypadkowo wykorzystuje AI. To rozróżnienie ma znaczenie. Każde obciążenie stawia przed infrastrukturą unikalne wymagania. Niektóre potrzebują znacznych zasobów obliczeniowych. Inne silnie zależą od wydajności pamięci, ponieważ nieustannie pobierają duże zestawy danych. Niektóre są ograniczone przepustowością sieci, inne zaś żyją lub umierają z powodu opóźnień, ponieważ każdy milisekund wpływa na doświadczenie klienta.

Istnieje także praktyczna rzeczywistość. Infrastruktura, dla której model został zaprojektowany, nie zawsze jest dostępna w momencie wdrożenia. Dostępność sprzętu, długie czasy realizacji lub terminy wdrożenia mogą zmusić organizacje do użycia innych GPU, akceleratorów lub konfiguracji niż pierwotnie planowano. To może wymagać ponownej optymalizacji modelu lub nawet jego przeprojektowania pod kątem dostępnego sprzętu.

Wymagania bezpieczeństwa i zarządzania są równie specyficzne dla obciążenia. Aplikacja przetwarzająca informacje publiczne ma zupełnie inne wymagania niż ta obsługująca transakcje finansowe, rekordy medyczne czy własną własność intelektualną. Ochrona danych, zarządzanie tożsamością i dostępem, zgodność, suwerenność, backup, odzyskiwanie i dostępność nie mogą być po prostu dodane po wdrożeniu. Są to decyzje architektoniczne.

Wymagania biznesowe dodają kolejny wymiar. Jak szybko aplikacja będzie musiała skalować? Jakie koszty operacyjne są akceptowalne? Jaki poziom dostępności jest wymagany? Ile złożoności organizacja jest w stanie realistycznie zarządzać? Na te pytania odpowiedzi będą się różnić w zależności od klienta. Dlatego nie istnieje jednorazowa, uniwersalna infrastruktura AI.

Organizacje, które zaczynają od preferowanej chmury, platformy sprzętowej lub dostawcy, nie trafiają w sedno infrastruktury AI. Liderzy zaczynają od obciążenia i projektują architekturę wokół celu biznesowego.

Trening przyciąga nagłówki. Inferencja dostarcza wartość biznesową.

Fascynacja branży treningiem to kolejny powód, dla którego dyskusje o infrastrukturze AI mogą zmierzać w niewłaściwym kierunku.

Trening dużego modelu językowego to niezwykłe wyzwanie inżynieryjne. Wymagane są ogromne zestawy danych, masywne klastry GPU, znaczna moc elektryczna oraz infrastruktura zdolna do pracy na pełnych obrotach przez dni, tygodnie, a nawet miesiące. To kosztowne, technicznie imponujące i naturalnie przyciąga uwagę.

Większość organizacji nie buduje jednak kolejnego przełomowego modelu. Tworzą aplikacje obsługi klienta, systemy AI głosowego, asystentów pracowniczych, asystentów wiedzy, narzędzia wyszukiwania, platformy podsumowywania dokumentów, systemy wykrywania oszustw i dziesiątki innych praktycznych zastosowań, korzystając z modeli już wytrenowanych.

Są to obciążenia inferencyjne, a inferencja zmienia równanie infrastrukturalne. Zamiast optymalizować wyłącznie pod kątem maksymalnej mocy obliczeniowej, organizacje mogą potrzebować optymalizacji pod kątem szybkich czasów odpowiedzi, niskich opóźnień, przewidywalnych kosztów operacyjnych i stabilnej wydajności.

Klient nie przejmuje się, jak potężny jest podkładowy GPU, jeśli chatbot odpowiada pięć sekund. Dzwoniący nie interesuje się specyfikacją klastra AI, jeśli asystent głosowy wielokrotnie nie rozumie poleceń lub waha się w trakcie rozmowy. Po prostu wiedzą, że aplikacja nie działa wystarczająco dobrze.

Projektowanie każdego środowiska AI tak, jakbyś trenował model podstawowy, jest więc zazwyczaj niewłaściwym podejściem i często niepotrzebnie kosztownym.

Celem większości klientów MSP nie jest zbudowanie największego klastra GPU na świecie. Celem jest szybkie, niezawodne, bezpieczne i ekonomiczne wprowadzenie aplikacji AI do produkcji.

Wyzwanie polega na znalezieniu właściwej równowagi między wydajnością, bezpieczeństwem, skalowalnością, odpornością i kosztami dla faktycznie uruchamianych obciążeń.

Może to nie GPU jest Twoim wąskim gardłem

GPU stały się gwiazdą infrastruktury AI. Są drogie, trudne do zdobycia i łatwe do porównania, co czyni je centrum niezliczonych dyskusji o infrastrukturze. Jednak GPU może nie być tym, co hamuje rozwój aplikacji AI po przejściu do produkcji.

„Ile GPU potrzebujemy?” nie jest pytaniem, które powinniśmy zadawać, raczej „Co spowolni tę aplikację za sześć miesięcy?”

Odpowiedź może leżeć gdzie indziej w architekturze.

Przykładem jest pamięć masowa. Ogromne ilości danych są zużywane przez obciążenia AI – i te zestawy danych rosną z czasem. Nawet bardzo potężny GPU może spędzać cenny czas w oczekiwaniu, jeśli pamięć nie dostarczy informacji wystarczająco szybko. Te dane muszą być także chronione, kopiowane, przechowywane, zabezpieczone i zarządzane przez cały ich cykl życia.

Równie ważna jest sieć. Przepustowość, opóźnienia, ruch wschód-zachód i komunikacja między klastrami AI wpływają na wydajność aplikacji. Dobrze zaprojektowane środowisko obliczeniowe nie może nieustannie rekompensować słabo zaprojektowanej sieci.

Bezpieczeństwo musi być częścią architektury od samego początku. Pytania, które trzeba rozwiązać przed produkcją, obejmują: gdzie przechowywane są wrażliwe dane, jak segmentowane są sieci, czy obciążenia komunikują się przez prywatne czy publiczne połączenia oraz w jaki sposób spełniane są wymogi zgodności i suwerenności.

Innym łatwo pomijanym czynnikiem jest łączność. Choć nie generują sensacyjnych nagłówków, różnorodność światłowodów, różnorodność tras, relacje peeringowe i bliskość geograficzna mogą krytycznie wpływać na doświadczenie użytkownika – nie wspominając o odporności platformy.

Końcowi klienci nie wiedzą i nie obchodzi ich, który GPU siedzi w szafie. Interesuje ich, czy aplikacja reaguje natychmiast, czy zostawia ich w oczekiwaniu.

Fizyczna infrastruktura także zasługuje na uwagę. Dostępność zasilania, pojemność chłodzenia, gęstość szaf i możliwości rozbudowy determinują, czy dzisiejsze udane wdrożenie może pomieścić jutrzejszy wzrost.

Potem pojawia się grawitacja danych. W miarę jak zestawy danych rosną, przenoszenie petabajtów informacji pomiędzy lokalizacjami, po prostu dlatego że obliczenia znajdują się gdzie indziej, staje się coraz mniej efektywne. W wielu sytuacjach przeniesienie obliczeń bliżej danych może być zarówno praktyczniejsze, jak i tańsze.

Dlatego architektura ma znaczenie.

Pomysł na samochód wyścigowy – samo że ma najlepszy silnik, nie oznacza, że wygra. Ważna jest także skrzynia biegów, opony, zawieszenie, tor i przede wszystkim kierowca. Infrastruktura AI działa w podobny sposób.

Organizacje generujące największą wartość z AI niekoniecznie będą te z największymi klastrami GPU. To będą te, które rozumieją, jak wszystkie warstwy infrastruktury współdziałają.

To różnica między kupowaniem infrastruktury a jej projektowaniem.

Ramowy model planowania najpierw od obciążenia

MSP mają szansę zmienić rozmowę o infrastrukturze.

Zamiast zaczynać od:

• Którego GPU?
• Której chmury?
• Którego dostawcy?

Zacznij od obciążenia:

• Jaki problem biznesowy rozwiązujemy?
• Czy to obciążenie treningowe, czy inferencyjne?
• Jakie opóźnienia może tolerować aplikacja?
• Gdzie znajdują się dane i jak szybko będą rosły?
• Jakie wymagania dotyczące bezpieczeństwa, zgodności i suwerenności mają zastosowanie?
• Jak obciążenie będzie skalować?
• Jaki poziom dostępności wymaga biznes?
• Jaki poziom ryzyka operacyjnego jest akceptowalny?
• Ile będzie kosztować utrzymanie tego środowiska przy rosnącym wykorzystaniu?

Odpowiedzi powinny determinować architekturę. Nie odwrotnie.

Szansa dla MSP

Ta zmiana redefiniuje rolę MSP.

Klienci nie potrzebują kolejnego partnera, który potrafi im sprzedać infrastrukturę. Potrzebny jest partner, który pomoże im podejmować lepsze decyzje infrastrukturalne.

Podejście najpierw od obciążenia jest niezbędne, ponieważ daje MSP możliwość oceny mocy obliczeniowej, pamięci, sieci, łączności, bezpieczeństwa, lokalizacji danych, dostępności i kosztów jako elementów jednej architektury – zamiast oddzielnych decyzji zakupowych.

W ten sposób możesz kontrolować koszty, poprawiać wydajność i identyfikować ryzyka operacyjne oraz bezpieczeństwa, zanim aplikacje trafią do produkcji.

Tworzy się także lepszy model biznesowy dla MSP.

MSP mogą budować wyższej wartości usługi cykliczne wokół architektury, wdrożenia, optymalizacji, bezpieczeństwa, zarządzania cyklem życia, planowania pojemności i ciągłego doskonalenia – zamiast konkurować głównie na coraz mniejszych marżach sprzętowych.

Wartość nie tkwi w polecaniu najnowszego GPU czy najnowszej platformy chmurowej. Polega na tym, by wiedzieć, kiedy klient ich potrzebuje, kiedy nie, i co jeszcze trzeba zaprojektować wokół nich.

Infrastruktura AI ostatecznie nie jest decyzją sprzętową. To decyzja architektoniczna, napędzana obciążeniem, danymi i wynikiem biznesowym, jaki klient chce osiągnąć.

MSP, które rozumieją to rozróżnienie, będą w pozycji, aby stać się czymś znacznie cenniejszym niż dostawcy infrastruktury.

Stanie się ludźmi, którym klienci ufają przy wyborze rzeczywistej infrastruktury, której naprawdę potrzebują.