Uczenie ze wzmocnieniem MoE na Amazon EKS osiąga o 40% większą przepustowość, ale benchmark ma ograniczenia

Amazon twierdzi, że uczenie ze wzmocnieniem MoE na Amazon EKS zapewniło o 40% wyższą łączną przepustowość rolloutów po włączeniu przez jego inżynierów DeepEP przez Elastic Fabric Adapter. Test objął 48 instancji P5en: 16 przeznaczono do trenowania polityki, a 32 do generowania rolloutów inferencyjnych. To znaczący wynik dla kosztownego etapu post-treningu dużych modeli.

Najważniejsza zmiana nie polega po prostu na zastosowaniu kolejnej szybszej konfiguracji GPU. Amazon dostosował ścieżkę komunikacji ekspertów DeepEP do użycia libfabric, zapewniając DeepEP v2 natywną obsługę sieci AWS. Integracja jest ukierunkowana na nieregularny wzorzec ruchu powstający, gdy model Mixture-of-Experts kieruje tokeny między ekspertami działającymi na różnych GPU.

Wynik wymaga też ostrożnego ujęcia. AWS ujawnił względny wzrost przepustowości dla jednego bardzo rzadkiego obciążenia MoE, a nie uniwersalny benchmark dla każdego modelu, klastra czy frameworka uczenia ze wzmocnieniem. Niezależne badania systemowe udokumentowały trudności w przenoszeniu komunikacji równoległej ekspertów między różnymi architekturami GPU i sieci.

Co Amazon zmienił w swoim stosie uczenia ze wzmocnieniem MoE

Raportowany przez Amazon wzrost wynikał ze zmiany sposobu przesyłania kierowanych tokenów między ekspertami, a nie z dodania kolejnych maszyn do mierzonego klastra.

Architektura AWS dzieli zadanie uczenia ze wzmocnieniem na kilka grup workerów. Węzły GPU obsługują trenowanie polityki, inferencję modelu nagrody i generowanie rolloutów. Węzły CPU uruchamiają środowiska i przetwarzanie wstępne, natomiast węzły zoptymalizowane pod kątem pamięci przechowują bufory doświadczeń i cache checkpointów.

Amazon EKS działa jako warstwa orkiestracji. Rozmieszcza kontenery, zarządza oddzielnymi grupami węzłów, koordynuje awarie i pozwala operatorom niezależnie skalować każdą część obciążenia. Amazon S3 przechowuje zbiory danych, checkpointy, końcowe wagi i inne trwałe artefakty poza wrażliwą na opóźnienia ścieżką wykonawczą.

To rozdzielenie ma znaczenie, ponieważ uczenie ze wzmocnieniem nie jest jednolitym obliczeniem. Podczas generowania rolloutów worker inferencyjny wykorzystuje bieżącą politykę do interakcji ze środowiskiem i tworzenia kandydackich odpowiedzi lub trajektorii. System nagród ocenia te próbki, a workery trenujące politykę wykorzystują uzyskane doświadczenie.

Zaktualizowane wagi wracają następnie do floty obsługującej rollouts, rozpoczynając kolejną iterację polityki. Ta pętla występuje w Reinforcement Learning from Human Feedback, czyli RLHF, wykorzystującym sygnały preferencji do ulepszania modelu. Pojawia się również w Group Relative Policy Optimization, czyli GRPO, które ocenia wyniki względem innych próbek w grupie.

Każdy etap inaczej obciąża infrastrukturę. Generowanie rolloutów przypomina rozproszoną inferencję i często może dzielić pracę między niezależnych workerów. Trenowanie polityki wymaga ściślejszej synchronizacji, ponieważ uczestniczące GPU muszą zakończyć skoordynowane operacje, zanim będzie można przejść do kolejnego kroku.

Dlatego architektura rozdziela 32 instancje inferencyjne od 16 instancji treningowych w opisywanym teście. W 48 systemach P5en Amazon twierdzi, że DeepEP przez EFA zwiększył łączną przepustowość rolloutów o 40% względem konfiguracji bez DeepEP.

Instancje P5en wykorzystują GPU NVIDIA H200 oraz wysokoprzepustową sieć AWS. W pełni obsadzona konfiguracja 48 instancji obejmuje setki akceleratorów, choć AWS podaje, że jego większa architektura może skalować się do około tysiąca akceleratorów. Opublikowany procent opisuje porównanie dla 48 instancji, a nie każdy możliwy rozmiar klastra.

Sam model opisano jedynie jako bardzo rzadki model MoE. Model Mixture-of-Experts zawiera wiele wyspecjalizowanych bloków feed-forward, ale dla każdego tokenu aktywuje tylko ich podzbiór. Rzadkość zmniejsza ilość obliczeń na token, lecz tworzy wymagający problem routingu, gdy eksperci znajdują się na różnych GPU.

Standardowe operacje kolektywne dobrze działają, gdy każdy rank wymienia przewidywalne bloki danych o podobnym rozmiarze. Routing MoE wygląda inaczej. Tokeny dynamicznie wybierają ekspertów, więc ruch może być rzadki, nierównomierny i składać się z wielu małych transferów.

Ta różnica wyjaśnia, dlaczego infrastruktura ma tak duże znaczenie. Większa teoretyczna pojemność modelu nie przekłada się automatycznie na większą liczbę użytecznych tokenów na sekundę. Jeśli wysyłanie tokenów do ekspertów i zbieranie wyników przeciążają sieć, kosztowne GPU czekają na aktywacje zamiast je przetwarzać.

Dlaczego uczenie ze wzmocnieniem MoE na Amazon EKS napotyka ograniczenia sieciowe

Rzadkie obliczenia oszczędzają operacje arytmetyczne, ale równoległość ekspertów może zwrócić ten koszt w postaci opóźnień komunikacyjnych.

Równoległość ekspertów rozdziela ekspertów modelu między GPU. Gdy router wybiera zdalnych ekspertów, system musi wysłać aktywację każdego tokenu do właściwego urządzenia. Po przetworzeniu przez eksperta operacja combine zwraca wynik na pierwotną ścieżkę wykonawczą.

Te wymiany zachodzą wielokrotnie w całym modelu. Ich miejsca docelowe zależą od decyzji routingu podejmowanych w czasie wykonywania, a różni eksperci mogą otrzymywać różną liczbę tokenów. Sieć musi więc obsłużyć wiele drobnoziarnistych transferów, nie pozwalając, by kilka intensywnie używanych miejsc docelowych zatrzymało wszystkich uczestników.

DeepEP powstał z myślą o takim wzorcu. Projekt DeepEP zapewnia wyspecjalizowane kernely dispatch i combine dla obciążeń opartych na równoległości ekspertów. Wykorzystuje NVLink do komunikacji wewnątrz serwera oraz transport obsługujący RDMA między serwerami.

Remote Direct Memory Access, czyli RDMA, pozwala jednej maszynie przesyłać dane bezpośrednio do pamięci innej maszyny przy mniejszym zaangażowaniu CPU. Krótsza ścieżka może ograniczyć narzut programowy i lepiej wykorzystać szybki sprzęt sieciowy.

Elastic Fabric Adapter, czyli EFA, jest niskolatencyjnym interfejsem sieciowym AWS dla ściśle sprzężonych obliczeń. Dokumentacja EFA opisuje ścieżkę z pominięciem systemu operacyjnego, opartą na AWS Scalable Reliable Datagram. EKS może udostępniać urządzenia EFA podom uruchamiającym rozproszone aplikacje uczenia maszynowego.

Wewnątrz każdej instancji P5en NVLink i NVSwitch przenoszą ruch GPU przez lokalną strukturę akceleratorów. W przypadku transferów między instancjami istotną ścieżką staje się EFA. Integracja Amazon wykorzystuje libfabric, interfejs pozwalający aplikacjom korzystać z różnych wysokowydajnych dostawców sieci przez wspólne API.

Amazon podaje, że jego inżynierowie wnieśli funkcje przenoszące prymitywy komunikacyjne DeepEP z backendu RDMA specyficznego dla CUDA do libfabric. Dzięki temu DeepEP v2 może przesyłać dane między węzłami przez EFA, zachowując wyspecjalizowane kernely do dispatch i combine ekspertów.

Rozróżnienie między wyspecjalizowanymi operacjami ekspertów a gęstymi kolektywami ma kluczowe znaczenie dla wyniku. NCCL nadal jest przydatny w regularnych operacjach, takich jak all-reduce, all-gather i reduce-scatter. DeepEP jest ukierunkowany na rzadkie wymiany all-to-all wokół warstw MoE.

Najnowsze badania odzwierciedlają ten podział. Autorzy NCCL EP opisują osobne tryby niskich opóźnień i wysokiej przepustowości dla komunikacji ekspertów. Ich projekt wysokiej przepustowości agreguje dane w domenach NVLink, zanim prześle je przez połączenia RDMA między węzłami.

Ta hierarchia ogranicza ilość drobnoziarnistego ruchu przekraczającego wolniejszą granicę między maszynami. Uznaje też, że klaster nie jest jedną jednolitą siecią. Komunikacja wewnątrz serwera ma inne właściwości przepustowości i opóźnień niż komunikacja między serwerami.

Implementacja AWS kieruje się tą samą ogólną zasadą. Ruch lokalny pozostaje w NVLink, natomiast libfabric przenosi międzywęzłowy ruch DeepEP przez EFA. Ta świadoma topologii ścieżka zastępuje ogólne traktowanie każdego transferu tokenu.

Wynikowy wzrost o 40% odnosi się do łącznego wyniku rolloutów, a nie wyłącznie do mikrobenchmarku komunikacji. Taki pomiar end-to-end jest wartościowy, ponieważ szybszy kernel nie zawsze przyspiesza całą pętlę uczenia ze wzmocnieniem. Zysk sugeruje, że komunikacja ekspertów była na tyle istotna, by wpłynąć na ukończoną pracę związaną z rolloutami.

Przepustowość rolloutów pozostaje jednak tylko jedną warstwą systemu. Czas iteracji polityki zależy również od wykonywania środowiska, oceny nagród, buforowania próbek, publikowania checkpointów, obliczeń treningowych i synchronizacji wag. Optymalizacja jednego etapu może ujawnić wąskie gardło w innym.

Rzeczywista rywalizacja to wyspecjalizowany routing kontra ogólne kolektywy

Główna rywalizacja dotyczy komunikacji zaprojektowanej dla dynamicznego routingu ekspertów oraz operacji kolektywnych zaprojektowanych dla regularnego przepływu danych.

Ogólne kolektywy są atrakcyjne, ponieważ są dojrzałe, szeroko wspierane i łatwiejsze do integracji. Działają w wielu frameworkach treningowych i konfiguracjach sprzętowych. Operatorzy mogą je również testować znanymi narzędziami i analizować ich zachowanie synchronizacyjne.

Ruch MoE narusza kilka założeń, które zapewniają efektywność tych kolektywów. Każdy token może wybrać inny zestaw ekspertów. Niektórzy eksperci stają się tymczasowo popularni, rozmiary wiadomości pozostają niewielkie, a system wykonuje operacje dispatch i combine w każdej warstwie MoE.

Konwencjonalna implementacja może pakować ten ruch w operacje all-to-all. Podejście pozostaje funkcjonalne, ale narzut synchronizacji i obsługi wiadomości rośnie, gdy równoległość ekspertów obejmuje więcej węzłów. Więcej GPU tworzy wówczas więcej relacji komunikacyjnych zamiast proporcjonalnie większej ilości użytecznych obliczeń.

DeepEP rozwiązuje ten problem za pomocą kerneli zbudowanych wokół semantyki routingu ekspertów. Kernel dispatch wysyła aktywacje tokenów do wybranych ekspertów. Kernel combine zwraca przetworzone aktywacje, unikając pracy, którą ogólny kolektyw mógłby wykonać dla niewykorzystanych miejsc docelowych.

Projekt dąży również do nakładania komunikacji na obliczenia. Jeśli GPU może kontynuować użyteczne operacje macierzowe w trakcie transferów, część czasu sieciowego znika ze ścieżki krytycznej. Takie nakładanie staje się trudniejsze, gdy komunikacja wymaga wielokrotnej koordynacji CPU lub ścisłej globalnej synchronizacji.

Migracja Amazon do libfabric ma znaczenie, ponieważ pierwotna optymalizacja była ściśle związana z GPU NVIDIA i sieciami w stylu InfiniBand. Biblioteka komunikacyjna działająca dobrze w jednej strukturze sieciowej nie musi automatycznie zachowywać się tak samo w innej. Gwarancje kolejności, inicjowanie wiadomości i interfejsy urządzeń różnią się.

Integracja oznacza zatem więcej niż zmianę adresu sieciowego. Założenia DeepEP muszą zostać odwzorowane na semantykę transportu EFA, a implementacja musi zachować poprawne dostarczanie tokenów. Musi też uniknąć wprowadzenia tak dużego narzutu programowego, który zniwelowałby korzyści wyspecjalizowanego routingu.

Amazon podaje, że obsługiwane systemy P5 i P6 mogą korzystać z GPUDirect RDMA z EFA. GPUDirect RDMA umożliwia transferom sieciowym odczyt i zapis pamięci GPU bez pośredniczenia każdego ładunku przez zwykłą pamięć hosta. System operacyjny pozostaje poza główną ścieżką danych.

Ten projekt wywiera presję na ogólne wdrożenia MoE, które opierają się wyłącznie na standardowych kolektywach. Zespoły infrastrukturalne wykorzystujące duże modele równoległe ekspertów mają teraz dowód, że wyspecjalizowana ścieżka może poprawić jedno istotne produkcyjnie obciążenie uczenia ze wzmocnieniem.

Wynik wywiera także presję na opiekunów frameworków. Obsługa DeepEP musi dotrzeć do silników servingowych, systemów uczenia ze wzmocnieniem, obrazów kontenerów, schedulerów i narzędzi obserwowalności. Szybki transport wymagający kruchego, niestandardowego builda może utracić przewagę podczas wdrożenia lub odzyskiwania po awarii.

NCCL 2.31 dodaje kolejny element układanki. AWS podaje, że ta wersja obejmuje nowsze optymalizacje EFA dla intensywnej komunikacji kolektywnej. Realistyczny stos treningowy MoE wykorzystuje więc różne mechanizmy dla różnych klas ruchu, zamiast wskazywać jednego uniwersalnego zwycięzcę.

DeepEP obsługuje nieregularne rozsyłanie i łączenie ekspertów. NCCL nadal obsługuje intensywną synchronizację wokół warstw uwagi, równoległości tensorowej, równoległości danych i stanu optymalizatora. EFA przenosi obie klasy między maszynami ścieżkami zoptymalizowanymi pod kątem ich odpowiednich wzorców.

Ten podział jest ważniejszą lekcją architektoniczną. Skalowanie MoE zależy od identyfikowania komunikacji według jej kształtu i celu. Traktowanie każdego transferu jako wymiennego pozostawia niewykorzystaną wydajność.

Czego nie dowodzi deklaracja 40% przepustowości DeepEP

Benchmark wspiera konkretną decyzję architektoniczną, ale nie potwierdza uniwersalnego zysku 40% DeepEP względem EFA.

Amazon wskazuje przydział instancji, względną poprawę i ogólny profil rzadkości modelu. Nie publikuje liczby parametrów modelu, liczby ekspertów, rozkładu routingu, długości sekwencji, rozmiarów batchy ani pełnej konfiguracji bazowej.

Te szczegóły bezpośrednio wpływają na komunikację ekspertów. Model aktywujący więcej ekspertów na token może generować większy ruch. Większe batche mogą efektywniej łączyć wiadomości, podczas gdy małe batche dekodowania mogą potęgować stałe opóźnienia.

Określenie „łączna przepustowość rolloutów” również wymaga kontekstu. AWS nie podaje w publicznym wpisie bezwzględnej liczby tokenów wyjściowych, trajektorii ani ukończonych żądań na sekundę. Czytelnicy nie mogą obliczyć całkowitego wykorzystania klastra ani bezpośrednio porównać go z innym dostawcą.

Konfiguracja bazowa ma równie duże znaczenie. „Bez DeepEP” może oznaczać standardową implementację NCCL all-to-all z konkretnymi ustawieniami strojenia. Inne agregowanie wiadomości, rozmieszczenie ekspertów, współbieżność lub polityki routingu mogłyby zmniejszyć albo zwiększyć zmierzoną różnicę.

Amazon przedstawia kontrolowany wynik ze swojego wewnętrznego obciążenia. Firma nie twierdzi, że benchmark został niezależnie audytowany, a materiały publiczne nie zawierają wariancji z powtarzanych prób. Właściwe sformułowanie brzmi zatem: AWS podaje, że przepustowość wzrosła o 40%.

Pojawia się także kwestia przenośności. Wcześniejsze badania UCCL-EP wskazywały, że systemy komunikacji ekspertów ściśle powiązane z interfejsami GPU i sieciowymi wymagają znacznej pracy integracyjnej. Artykuł analizował konkretnie, jak różne semantyki porządkowania komplikują obsługę EFA oraz innych sieci nieopartych na InfiniBand.

Badanie to poprzedza nowo opisane przez Amazon natywne rozwiązanie dla EFA. Pozostaje istotne, ponieważ wyjaśnia barierę techniczną, którą AWS — jak podaje — rozwiązał obecnie dzięki wkładom do libfabric. Oba opisy przedstawiają różne momenty w szybko zmieniającej się historii implementacji.

UCCL-EP wybiera inną drogę. Zachowuje decyzje dotyczące routingu na GPU, ale przekazuje wykonanie sieciowe wielowątkowym proxy CPU, wykorzystując kanał sterujący do niwelowania różnic sprzętowych. Jego autorzy raportują poprawę na systemach NVIDIA plus EFA, lecz testy dotyczą własnych modeli, frameworków i konfiguracji.

Żaden z tych wyników nie podważa drugiego. Pokazują one, że projekt transportu może zmienić wynik oraz że „obsługa EFA” nie oznacza jednej stałej ścieżki wykonania. Operatorzy muszą wiedzieć, czy dana kompilacja wykorzystuje transfery inicjowane przez GPU, proxy CPU, agregację wiadomości czy inną warstwę kompatybilności.

Opublikowane wymagania i wyniki wydajności DeepEP również ewoluowały. Aktualna dokumentacja projektu raportuje wysoką przepustowość w obsługiwanych konfiguracjach RDMA, lecz zachęca użytkowników do bezpośredniego benchmarkowania większych wdrożeń z równoległością ekspertów. Ta rada jest szczególnie ważna w środowiskach chmurowych o innej topologii i charakterystyce przeciążeń.

Skala klastra wprowadza dalszą niepewność. Raportowany test wykorzystał 48 instancji P5en, podczas gdy AWS omawia skalowanie szerszej architektury do około tysiąca akceleratorów. Projekt, który działa dobrze na 48 węzłach, nie musi zachowywać tej samej efektywności przy każdej większej skali.

Przeciążenia sieci mogą pojawić się, gdy wiele grup roboczych współdzieli infrastrukturę. Routing tokenów może stawać się bardziej niezrównoważony wraz ze zmianą zachowania modelu lub obciążenia. Pojedynczy wolny rank może także opóźniać ściśle zsynchronizowane operacje treningowe.

Uczenie ze wzmocnieniem dodaje własne źródło zmienności. Długość promptów, długość odpowiedzi, opóźnienia środowiska, ustawienia próbkowania i złożoność modelu nagrody wpływają na czas poświęcany przez workerów rolloutów na komunikację. Zysk 40% przy obciążeniu intensywnie korzystającym z komunikacji może się zmniejszyć, gdy dominuje generowanie lub wykonywanie środowiska.

Wynik mówi jeszcze mniej o obsłudze online. Produkcyjne wnioskowanie często wykorzystuje mniejsze batche i rygorystyczne cele opóźnienia dla pojedynczych żądań. Jądro o wysokiej przepustowości dostrojone do generowania rolloutów nie skraca automatycznie czasu do pierwszego tokenu ani czasu na token wyjściowy dla użytkowników interaktywnych.

Koszt pozostaje nieokreślony jako miara bezwzględna. Wyższa przepustowość na tym samym klastrze zwykle poprawia ilość użytecznej pracy na godzinę akceleratora, ale wpis nie podaje całkowitego kosztu treningu. Nie porównuje też zoptymalizowanej konfiguracji z alternatywnymi typami instancji ani bibliotekami sieciowymi.

Te braki nie czynią wyniku nieistotnym. Określają one, gdzie jest użyteczny. Benchmark stanowi dowód, że integracja DeepEP AWS może usunąć istotne wąskie gardło w jednym dużym potoku uczenia ze wzmocnieniem MoE.

EKS i pojemność Spot zmieniają pozostałą część systemu RL

Zysk komunikacyjny staje się operacyjnie użyteczny tylko wtedy, gdy harmonogram, bufor, pamięć masowa i model awarii utrzymują zaopatrzenie szybszej floty rolloutów.

Amazon EKS pozwala architekturze przypisywać różne typy węzłów do odrębnych zadań. Grupy węzłów GPU mogą skalować się wraz z zapotrzebowaniem treningowym i inferencyjnym. Grupy CPU mogą rozbudowywać się dla workerów środowiskowych, podczas gdy systemy zorientowane na pamięć absorbują krótkotrwałe dane doświadczeń.

Ta heterogeniczność jest szczególnie istotna dla GRPO i RLHF. Workery rolloutów mogą generować duże ilości tymczasowych danych, ale trenery polityki konsumują je w zsynchronizowanych batchach. Jeśli tempo produkcji i konsumpcji się rozchodzą, jedna strona czeka, podczas gdy druga gromadzi kolejkę.

Współdzielony bufor doświadczeń w pamięci rozdziela te tempa w krótkich okresach. Workery rolloutów publikują ukończone próbki, a trenery pobierają batche, gdy są gotowe. Cache checkpointów pomaga rozprowadzać zaktualizowane wagi bez wymuszania przechodzenia każdego transferu przez trwałą pamięć obiektową.

Amazon S3 pełni inną rolę. Przechowuje zbiory danych, checkpointy możliwe do odzyskania, ukończone artefakty modelu i końcowe wagi. Utrzymanie tej trwałej ścieżki poza najczęstszą wymianą próbek zapobiega temu, by opóźnienia pamięci obiektowej sterowały każdym krokiem treningu.

Ten podział wyjaśnia również wartość EKS. Kubernetes nie przyspiesza mnożenia macierzy ani jąder ekspertów. Koordynuje zbiór usług potrzebnych do utrzymania produktywności akceleratorów.

EKS zarządza rozmieszczaniem, restartami, zasadami skalowania i granicami grup węzłów. Może harmonogramować stabilną pojemność treningu polityki oddzielnie od bardziej elastycznych workerów rolloutów. Ta granica wspiera drugą optymalizację Amazonu: wykorzystanie EC2 Spot Instances dla części generowania rolloutów.

Pojemność Spot może zostać przerwana, gdy AWS potrzebuje z powrotem bazowych instancji. Ryzyko to jest trudne dla ściśle zsynchronizowanego treningu polityki, ponieważ utrata jednego workera może zatrzymać lub zrestartować skoordynowane zadanie. Zadania rolloutów łatwiej podzielić i ponowić.

Amazon zaleca przydzielanie workerom rolloutów ograniczonych jednostek pracy i częste publikowanie próbek. Gdy nadejdzie powiadomienie o przerwaniu, worker może dokończyć aktywne żądania i zwrócić niedokończone zadania do kolejki. Inne workery kontynuują pracę bez restartowania całej grupy treningu polityki.

Strategia nie sprawia, że przerwania są bezkosztowe. Utracone częściowe generacje marnują część zasobów obliczeniowych, a węzły zastępcze potrzebują kontenerów, wag modelu i bibliotek komunikacyjnych. Decyzje autoskalowania muszą także uwzględniać głębokość kolejki, czas ładowania modelu i dostępną pojemność Spot.

Mimo to topologia izoluje dwie domeny awarii. Trenery polityki pozostają na stabilnej pojemności, podczas gdy generowanie rolloutów wykorzystuje tańszą, lecz mniej przewidywalną pulę. Taki projekt odpowiada odmiennym wymaganiom synchronizacji obu etapów.

Wzrost przepustowości DeepEP o 40% może zmienić tę równowagę. Szybsze workery inferencyjne mogą dostarczać doświadczenia szybciej, niż trenery je konsumują. Operatorzy muszą wtedy zmienić rozmiar grup węzłów, dostosować harmonogramowanie batchy lub zmniejszyć pojemność inferencyjną, aby uniknąć płacenia za bezczynną produkcję.

Odwrotna sytuacja może wystąpić po aktualizacji polityki. Dystrybucja wag i czas restartu workerów mogą tymczasowo zagłodzić bufor doświadczeń. Użyteczny pulpit produkcyjny musi więc śledzić pełną iterację polityki, a nie tylko liczbę tokenów generowanych na sekundę.

Zespoły potrzebują również powtarzalnych informacji o kompilacji. DeepEP, NCCL, CUDA, libfabric, sterowniki EFA, wersje frameworków i architektura GPU wpływają na ścieżkę danych. Zmiana jednego komponentu może po cichu wybrać wolniejszą ścieżkę awaryjną.

Te dowody operacyjne powinny być przechowywane wraz z rekordami modelu i eksperymentów. Zespoły inżynieryjne mogą zachowywać decyzje konfiguracyjne, notatki benchmarkowe i raporty awarii w przeszukiwalnej technicznej bazie wiedzy. Taka praktyka staje się cenna, gdy późniejsza przebudowa obrazu zmienia przepustowość bez zmiany modelu.

Trzy sygnały pokażą, czy zysk da się uogólnić

Kolejnym testem jest powtarzalność w różnych modelach, rozmiarach klastrów i pełnych iteracjach polityki.

Pierwszym sygnałem jest publiczny pakiet benchmarkowy z bezwzględną przepustowością. Użyteczne wyniki obejmowałyby tokeny lub trajektorie na sekundę, rozkłady opóźnień, nierównowagę obciążenia ekspertów, wykorzystanie sieci i wariancję powtarzanych uruchomień.

Pakiet ten powinien określać bazowy kolektyw, wszystkie istotne wersje oprogramowania oraz precyzyjną ścieżkę transportu DeepEP. Powinien też ujawniać wymiary modelu, aktywnych ekspertów na token, rozmiary batchy, długości promptów, długości odpowiedzi i stopień równoległości ekspertów.

Jeśli niezależne zespoły odtworzą podobny zysk, deklaracja AWS stanie się silniejsza. Jeśli wyniki będą się znacząco różnić, integracja pozostanie użyteczna, ale specyficzna dla obciążenia. Każdy z tych rezultatów pomógłby operatorom zdecydować, kiedy jej dodatkowa złożoność jest uzasadniona.

Drugim sygnałem jest efektywność skalowania poza opublikowaną konfiguracją 48 instancji. Wyniki dla kilku rozmiarów klastrów pokażą, czy przepustowość rośnie proporcjonalnie, czy traci na synchronizacji, przeciążeniach i nierównowadze ekspertów.

Znaczące badanie skalowania powinno utrzymywać definicję obciążenia na stałym poziomie przy zwiększaniu zasobów. Powinno raportować zarówno łączny wynik, jak i efektywność na akcelerator. Sama łączna przepustowość może rosnąć, nawet gdy każdy dodany GPU wnosi mniej użytecznej pracy.

Wysoka efektywność w kierunku około tysiąca akceleratorów wspierałaby szerszą deklarację architektoniczną AWS. Gwałtowny spadek wskazywałby, że DeepEP usunął jedno wąskie gardło, podczas gdy przy większej skali pojawiło się inne.

Trzecim sygnałem jest czas pełnej iteracji polityki w warunkach rzeczywistych awarii. Przepustowość rolloutów ma znaczenie, ponieważ workery treningowe potrzebują świeżych doświadczeń, a nie dlatego, że generowanie odizolowanych tokenów jest celem końcowym.

Przyszłe pomiary powinny obejmować wykonywanie środowiska, ocenę nagród, opóźnienia bufora, aktualizacje polityki, publikowanie checkpointów i redystrybucję wag. Powinny też pokazywać, jak przerwania Spot wpływają na ukończone próbki i czas odzyskiwania.

Krótsza pełna iteracja potwierdziłaby, że optymalizacja komunikacji poprawia postęp uczenia ze wzmocnieniem, zamiast przenosić czas bezczynności w inne miejsce. Jeśli czas iteracji prawie się nie zmieni, zespoły powinny zbadać trening, pamięć masową lub synchronizację przed dodaniem większej pojemności rolloutów.

Wzmocnione uczenie MoE na Amazon EKS ma teraz wiarygodną ścieżkę łączenia orkiestracji Kubernetes, sieci EFA i wyspecjalizowanej komunikacji między ekspertami. Raportowany wzrost o 40% sprawia, że warto ją przetestować, ale pozostaje on punktem wyjścia do pomiarów, a nie uniwersalną stałą. Zespoły infrastruktury powinny odtworzyć porównanie na własnym modelu, profilu routingu i pętli RL, zanim ustandaryzują ten stos technologiczny. Praktyczne pytanie nie brzmi, czy DeepEP może wygenerować szybszy wykres. Chodzi o to, czy ten sam klaster realizuje więcej zweryfikowanych aktualizacji polityki przy akceptowalnej niezawodności i koszcie, po uwzględnieniu wszystkich elementów systemu.