Trenowanie Amazon Trainium rzuca wyzwanie Nvidia dzięki natywnemu PyTorch

Amazon uruchomił 20 października natywną obsługę PyTorch dla Trainium, rzucając wyzwanie przewadze Nvidia w oprogramowaniu do trenowania poprzez przepływy pracy, z których badacze już korzystają. Trenowanie Amazon Trainium ma teraz backend publicznej bety o nazwie TorchNeuron — komponent oprogramowania, który łączy kod modeli PyTorch z akceleratorami Amazon. PyTorch to framework, którego deweloperzy używają do definiowania, trenowania i uruchamiania modeli.

Ta zmiana ma znaczenie, ponieważ sprzęt do trenowania konkuruje nie tylko mocą obliczeniową. Badacze muszą móc zmieniać modele, analizować błędy i powtarzać eksperymenty bez przebudowywania oprogramowania wokół nieznanego urządzenia. Platforma CUDA firmy Nvidia, jej środowisko programistyczne do obliczeń przyspieszonych, pozostaje punktem odniesienia dla takiego doświadczenia.

Ocena SemiAnalysis z 23 października dostarcza zachęcających praktycznych dowodów, ale wskazuje też na opóźnienia kompilacji i niedokończoną kompatybilność. Wyłaniająca się rywalizacja dotyczy tego, czy Amazon zdoła uczynić Trainium praktycznym rozwiązaniem dla codziennych badań. Nie oznacza to, że Amazon wyprzedził Nvidia we wszystkich obciążeniach treningowych.

Trenowanie Amazon Trainium zyskuje natywną ścieżkę PyTorch

Amazon zmienia umowę programową między badaczami a swoimi chipami.

Publiczna beta TorchNeuron od AWS obsługuje instancje Trainium2 i Trainium3. Firma twierdzi, że deweloperzy mogą wybrać urządzenie neuron, zachowując standardowe interfejsy PyTorch. Obsługuje również niestandardowe operatory za pośrednictwem Neuron Kernel Interface, interfejsu Amazon do pisania procedur obliczeniowych specyficznych dla urządzenia.

To ogłoszenie odpowiada na praktyczną przeszkodę: dystans między modelem, który badacze rozumieją, a stosem sprzętowym, do którego muszą się dostosować. Obiecujący akcelerator staje się mniej atrakcyjny, gdy jego wdrożenie oznacza konieczność utrzymywania osobnej wersji eksperymentu.

Natywna integracja zmienia miejsce, w którym następuje to dostosowanie. W idealnym przypadku backend sprzętowy przejmuje więcej pracy specyficznej dla urządzenia, pozostawiając badaczom rozwiązanie bliższe ich istniejącym definicjom modeli. Daje to Amazon wyraźniejszą drogę do zespołów, które nie mają dedykowanych specjalistów od akceleratorów.

To sformułowanie nadal wymaga ostrożności. Natywna obsługa opisuje podejście integracyjne; nie gwarantuje identycznego działania każdej operacji, biblioteki ani obciążenia. Publiczna beta sygnalizuje również, że deweloperzy powinni oczekiwać ewolucji obsługiwanego zakresu.

Dla zespołu badawczego użyteczne jest rozróżnienie między rozpoczęciem eksperymentu a utrzymaniem programu badawczego. Rozpoczęcie wymaga, aby model się załadował i wykonał. Utrzymanie wymaga, by zmiany architektury, debugowanie, ewaluacja i aktualizacje oprogramowania pozostawały możliwe do opanowania.

Trenowanie Amazon Trainium staje się bardziej konkurencyjne, jeśli te późniejsze działania przestają wymagać nadzwyczajnego wysiłku. Udana demonstracja może ustanowić punkt wejścia. Powtarzane, zwyczajne eksperymenty decydują, czy ten punkt wejścia stanie się niezawodnym środowiskiem pracy.

Rozważmy przykładowy zespół modyfikujący mechanizm attention modelu językowego — komponent określający, które informacje wpływają na każdą predykcję. Zespół musi porównać swoją modyfikację z punktem odniesienia. Wybór sprzętu nie powinien stać się odrębnym projektem badawczym.

Ten przykład wyjaśnia, dlaczego ogłoszenie wykracza poza grono specjalistów od infrastruktury. Badacze wybierają narzędzia częściowo według tego, jakie eksperymenty pozwalają one podejmować. Kompatybilność sprzętu wpływa więc na pytania, które zespół może badać w dostępnym czasie.

Dla nabywców korporacyjnych konsekwencja jest równie konkretna. Porównania zakupowe powinny obejmować pracę inżynieryjną potrzebną do utrzymania obciążenia w dobrej kondycji. Dostępność urządzenia niewiele znaczy, gdy wysiłek programistyczny czyni eksperymentowanie niepraktycznym.

Bezpośrednią zmianą jest zatem szersze zaproszenie do oceny Trainium. AWS zapewnił do tej oceny znajomy interfejs. To, czy zespoły pozostaną przy rozwiązaniu, zależy od zachowania pod tym interfejsem, zwłaszcza gdy ich kod odbiega od przygotowanej demonstracji.

Nvidia odczuwa presję tam, gdzie badacze spędzają czas

Konkurencyjną szansą jest wysiłek potrzebny do przeniesienia badań, a nie pojedynczy wynik sprzętowy.

Nvidia jest głównym konkurentem w tej historii, ponieważ Amazon zajmuje się nawykami programowymi związanymi z trenowaniem na GPU. GPU to procesor zaprojektowany do obliczeń równoległych. Badacze oceniają całe środowisko pracy wokół niego, w tym debugowanie, biblioteki i zgromadzoną wiedzę zespołu.

Te inwestycje tworzą silny powód, by pozostać przy istniejącej platformie. Organizacja wie, które błędy są rutynowe, które zmiany wymagają ostrożności i gdzie znajduje się jej wewnętrzna wiedza ekspercka. Zmiana sprzętu może zachwiać tym rozumieniem.

Podejście Amazon bezpośrednio atakuje koszt zmiany. Jeśli badacze zachowują znajome interfejsy, mają mniej powodów, by odrzucić alternatywę przed jej przetestowaniem. To przewaga konkurencyjna jeszcze zanim nabywca zdecyduje, która platforma działa lepiej.

Presja na Nvidia jest zatem konkretna. AWS próbuje uczynić ocenę sprzętu mniej zakłócającą dla procesu badawczego. Nvidia musi nadal zasługiwać na preferencję zespołów, które zyskują bardziej dostępną alternatywę.

Tej presji nie należy mylić z prognozą natychmiastowej migracji. Laboratorium może badać Trainium, zachowując istniejącą infrastrukturę GPU. Ocena poszerza dostępne możliwości, nie przesądzając, jak duża część pracy zostanie ostatecznie przeniesiona.

TorchTitan, framework PyTorch do tworzenia przepływów pracy trenowania na dużą skalę, stanowi użyteczny punkt odniesienia. Jego projekt opisuje modułowe definicje modeli i konfigurowalne wykonywanie rozproszone, czyli obliczenia rozłożone na wiele urządzeń. To czyni go istotnym dla zespołów badawczych adaptujących istniejący fundament treningowy.

Wartość strategiczna polega na zachowaniu tego fundamentu. Zespół nie chce, aby każdy eksperyment sprzętowy tworzył trwałą odnogę jego pracy naukowej. Im bliższe pozostają implementacje, tym łatwiej porównywać ich wyniki.

To również wyjaśnia, dlaczego sukces w inferencji nie może automatycznie potwierdzać przydatności do trenowania. Inferencja wykorzystuje wytrenowany model do generowania wyników. Trenowanie badawcze zmienia parametry modelu, podczas gdy deweloperzy analizują architektury, dane i wybory optymalizacyjne.

Obciążenie obsługujące może nagradzać staranną optymalizację stabilnej ścieżki. Obciążenie badawcze nagradza również tolerancję na zmiany. Akcelerator musi wspierać eksperymenty, których jego dostawca nie przygotował konkretnie z myślą o nich.

Dla nabywców sugeruje to inną interpretację konkurencji. Istotne pytanie brzmi, ile użytecznych badań zespół realizuje dzięki dostępnemu personelowi i infrastrukturze. Przepustowość sprzętu przyczynia się do tego wyniku, podobnie jak wysiłek wdrożeniowy i czas diagnozowania.

Amazon ma wiarygodną szansę, jeśli zmniejszy te dodatkowe obciążenia. Nvidia zachowuje przewagę wszędzie tam, gdzie jej środowisko pracy czyni zespoły bardziej produktywnymi. Rywalizacja będzie zależeć od obciążenia, zależności programowych i wiedzy osób, które je obsługują.

Ta zmienność sprawia, że szerokie deklaracje zwycięstwa są przedwczesne. Czyni też ogłoszenie istotnym: AWS konkuruje o dzień pracy badacza, w którym preferencje sprzętowe stają się trwałe.

Natywny PyTorch zmienia cykl eksperymentowania

Mechanizmem stojącym za wyzwaniem Amazon jest krótsza droga od zmiany kodu modelu do oceny jego zachowania.

Natywny backend PyTorch od AWS używa standardowego mechanizmu rozszerzeń PyTorch do zarejestrowania Trainium jako urządzenia. Jego dokumentacja opisuje wykonywanie eager, w którym operacje działają, gdy deweloperzy je wywołują, oraz wykonywanie kompilowane, w którym oprogramowanie optymalizuje przechwycone obliczenia przed ich uruchomieniem.

Tryby te służą różnym momentom eksperymentu. Wykonywanie interaktywne pomaga deweloperom analizować zachowanie, gdy pomysł pozostaje nieustalony. Kompilacja staje się atrakcyjna, gdy obliczenie się stabilizuje, a jego wielokrotne wykonanie zasługuje na dodatkową optymalizację.

Praktyczna korzyść wynika z przechodzenia między tymi momentami bez porzucania kodu badawczego. Badacze mogą analizować zmianę, ustalić, czy działa, a następnie zbadać wydajność. Backend obsługujący taką sekwencję odpowiada rzeczywistemu przebiegowi pracy eksperymentalnej.

Dokumentacja AWS wyjaśnia również, dlaczego znajome wykonywanie nie eliminuje kosztów kompilacji. Wcześniej niewidziane kształty operacji mogą wymagać kompilacji przy pierwszym użyciu. Wyniki zapisane w pamięci podręcznej mogą pomóc przy późniejszym wykonywaniu, lecz początkowe oczekiwanie nadal jest częścią doświadczenia badacza.

Ten szczegół łączy historię integracji z pozostałymi trudnościami. Model może sprawiać wrażenie znajomego na poziomie interfejsu, a jednocześnie powodować nieznane przerwy pod nim. Deweloperzy muszą rozumieć obie warstwy, zanim oszacują, ile czasu iteracji zaoszczędzą.

TorchNeuron wyjaśniony z tej perspektywy jest zmianą odpowiedzialności. Więcej adaptacji przenosi się do backendu, podczas gdy badacz zachowuje bardziej znajomy kod. Inżynieria specyficzna dla urządzenia pozostaje konieczna tam, gdzie pokrycie lub wydajność nie wystarczają.

Ta sama dokumentacja rozróżnia zachowanie awaryjne między trybami wykonywania. W trybie eager nieobsługiwany operator może zostać uruchomiony na CPU, procesorze ogólnego przeznaczenia komputera, z ostrzeżeniem. Przy kompilacji operacja, której backend nie może przetłumaczyć, może zamiast tego spowodować niepowodzenie kompilacji.

To rozróżnienie ma znaczenie przy ocenie udanego uruchomienia. Samo ukończenie nie dowodzi, że zamierzone obliczenie pozostało na akceleratorze. Działający eksperyment i efektywnie przyspieszony eksperyment to odrębne ustalenia.

Dla przykładowej grupy badawczej ocena powinna podążać za pracą, którą rzeczywiście wykonuje. Standardowy model ustanawia punkt odniesienia. Istotna modyfikacja architektury ujawnia, czy kompatybilność wykracza poza przygotowaną ścieżkę.

Grupa może następnie porównać wynik naukowy i wysiłek potrzebny do jego uzyskania. Jeśli zmodyfikowany eksperyment działa poprawnie, lecz wymaga rozległych napraw, ulepszenie interfejsu spełniło tylko część swojej obietnicy.

Strategia programowa Amazon ułatwia podjęcie takiej oceny. Jej długoterminowa wartość zależy od tego, jak konsekwentnie backend radzi sobie z nieuporządkowanymi zmianami wprowadzanymi przez badaczy. To jest związek między natywną integracją a szerszą działalnością szkoleniową.

Bardziej dostępny punkt startowy zwiększa pulę potencjalnych użytkowników. Niezawodny cykl eksperymentowania daje tym użytkownikom powód, by kontynuować.

Kontrola jakości musi obejmować poprawność i oczekiwanie

Oprogramowanie treningowe zdobywa zaufanie, zachowując wyniki i utrzymując praktyczność powtarzania eksperymentów.

Testy trenowania Trainium przeprowadzone przez SemiAnalysis wykazały przepustowość Qwen3-32B na poziomie 11 099 tokenów na sekundę w trybie eager oraz 14 156 w trybie kompilowanym na 16 chipach Trainium2. Tokeny to jednostki tekstu przetwarzane przez model językowy. Są to pomiary specyficzne dla obciążenia, a nie ogólne porównanie z Nvidia.

Publikacja odnotowała również 27-minutowe i 17-sekundowe oczekiwanie na kompilację dla receptury trenowania gpt-oss. Jej ocena FlexAttention na Trainium3 przeszła 89 z 96 przypadków; pozostałe przypadki przekroczyły limity czasu kompilacji. FlexAttention to interfejs PyTorch do definiowania wariantów attention.

Wyniki te uzasadniają wyważoną interpretację. Stos może realizować istotne eksperymenty treningowe, choć czas oczekiwania nadal wpływa na użyteczność w badaniach. Szybsze wielokrotne wykonywanie nie eliminuje czasu potrzebnego, by je osiągnąć.

To rozróżnienie nabiera szczególnego znaczenia w przypadku krótkich eksperymentów. Badacz testujący pomysł może bardziej przejmować się czasem potrzebnym do uzyskania pierwszego wyniku. Dłuższe uruchomienie pozwala rozłożyć koszty przygotowania na większą ilość użytecznych obliczeń.

Oznacza to, że raportowanie wydajności powinno oddzielać przygotowanie, wykonanie i pomyślne ukończenie. Łączenie ich w jedną korzystną liczbę może ukrywać tę część doświadczenia, która decyduje o tym, czy badacze będą nadal korzystać z platformy.

Poprawność stawia dodatkowy wymóg. Model, który działa szybko, lecz uczy się inaczej, wymaga zbadania, zanim jego szybkość stanie się użyteczna. Zgodność numeryczna oznacza sprawdzenie, czy obliczenia dają wystarczająco spójne wyniki przy wybranej precyzji i warunkach testowych.

AWS opisuje szeroko zakrojone automatyczne testy w swojej metodologii testowania TorchNeuron. Firma podaje, że jej przegląd modeli obejmuje 100 000 modeli Hugging Face w ograniczonych konfiguracjach, rejestrując zachowanie podczas wykonania, kompilacji i przejścia awaryjnego. Są to deklaracje dotyczące pokrycia raportowane przez dostawcę.

W tym samym opisie wskazano około 154 000 wyników testów nadrzędnych w sierpniu, z czego około 69 000 pominięto. Część pominięć wynikała z zasad kwalifikacji PyTorch, a pozostałe odzwierciedlały decyzje dotyczące pokrycia Neuron. Wśród wymienionych początkowych wyłączeń znalazły się operacje rzadkie i dynamiczne kształty.

Ciągła integracja, czyli automatyczne testowanie zmian w oprogramowaniu, ma tu znaczenie, ponieważ ulepszenia backendu mogą powodować regresje w innych obszarach. Przydatny system testowy wykrywa takie regresje, zanim badacze odkryją je podczas kosztownego eksperymentu.

Sama liczba testów nie może potwierdzić niezawodności. Czytelnicy muszą wiedzieć, co uruchomiono, co pominięto i na ile testowana konfiguracja przypomina ich obciążenie. Szeroki przegląd katalogu nie zastąpi pełnej walidacji treningu każdego wymienionego modelu.

Najmocniejsze dowody łączyłyby przejrzyste raportowanie pokrycia z odtwarzalnymi wynikami zewnętrznymi. Ujawnienia AWS dostarczają materiału do takiej oceny. Doświadczenia SemiAnalysis oferują perspektywę z zewnątrz, w tym problemy, które korzystny język premierowy mógłby w przeciwnym razie przesłonić.

Trening Amazon Trainium zasługuje na ocenę w obu wymiarach: czy eksperymenty kończą się poprawnie oraz czy zespoły mogą je powtarzać bez nadmiernych opóźnień. Postęp w jednym wymiarze nigdy nie powinien ukrywać słabości w drugim.

Profiler daje Amazon kolejny sposób konkurowania

Lepsza widoczność wolnego wykonywania może ułatwić ulepszanie akceleratora, nawet jeśli jego pierwszy wynik rozczarowuje.

Neuron Explorer to narzędzie profilujące Amazon, oprogramowanie rejestrujące wykonanie, aby inżynierowie mogli analizować wydajność. Narzędzia AWS do profilowania sprzętu rozróżniają aktywność na poziomie systemu od aktywności na poziomie urządzenia. Udostępniają osie czasu, odnośniki do kodu źródłowego, informacje o zależnościach i widoki pamięci.

Funkcje te rozwiązują problem inny niż kompatybilność. Gdy model już działa, deweloperzy muszą ustalić, dlaczego czeka. Powolny etap może wynikać z obliczeń, przenoszenia danych, komunikacji lub pracy wykonywanej poza akceleratorem.

Całkowity czas trwania wskazuje objaw. Przydatny ślad pomaga zlokalizować przyczynę. Ta różnica decyduje o tym, czy inżynier może wprowadzić ukierunkowaną zmianę, czy musi prowadzić dochodzenie poprzez kolejne próby.

Na przykład ilustracyjne zadanie treningowe może spędzać czas na oczekiwaniu na przenoszenie danych, zanim obliczenia będą mogły postępować. Poprawa samej arytmetyki nie usunęłaby tej zależności. Przejrzysta oś czasu może skierować inżyniera ku pracy, która faktycznie ogranicza postęp.

Dlatego jakość profilera należy uwzględniać w analizie konkurencyjnej. Specyfikacje sprzętowe opisują dostępną zdolność. Narzędzia diagnostyczne pomagają deweloperom przekształcić tę zdolność w użyteczne wykonanie dla ich konkretnego modelu.

Związek z natywną integracją jest również praktyczny. Znajomy kod modelu skraca drogę do pierwszego uruchomienia. Przejrzyste profilowanie skraca drogę od tego uruchomienia do wyjaśnienia jego zachowania.

Łącznie te usprawnienia dotyczą pracy inżynieryjnej otaczającej trening. Nie gwarantują przewagi wydajnościowej. Mogą ułatwić zespołowi ustalenie, czy taka przewaga istnieje.

Sformułowanie „GPU impossible” wymaga powściągliwości. SemiAnalysis używa go, aby opisać swój entuzjazm wobec szczegółowych możliwości profilowania Trainium. Nie powinno ono przekształcać się w twierdzenie, że sprzęt Nvidia nie oferuje żadnych środków obserwowania aktywności w procedurach obliczeniowych.

Nvidia dokumentuje śledzenie zdarzeń wewnątrz kernela, mechanizm rejestrowania zdarzeń wewnątrz kernela, czyli procedury wykonywanej na akceleratorze. Jego istnienie zawęża możliwe do obrony porównanie do integracji, widoczności i nakładu pracy deweloperów przy konkretnych zadaniach.

Nadal jest to znaczące porównanie. Dwie platformy mogą udostępniać powiązane informacje, wymagając jednocześnie różnego nakładu pracy, aby je zebrać i zinterpretować. Istotna ocena dotyczy analizy, którą musi przeprowadzić inżynier.

Dlatego kupujący powinien oceniać profiler na podstawie rzeczywistego, nierozwiązanego pytania dotyczącego wydajności. Atrakcyjne zrzuty ekranu nie dowodzą, jak skutecznie narzędzie pomaga zespołowi na nie odpowiedzieć. Ślad prowadzący do diagnozy umożliwiającej działanie dostarcza mocniejszych dowodów.

Analiza powinna również zachować granicę między diagnozą a naprawą. Wiedza o tym, dlaczego obciążenie się zatrzymuje, nie gwarantuje, że oprogramowanie lub sprzęt może usunąć tę przeszkodę. Lepsza widoczność poprawia decyzję, w tym decyzję o odrzuceniu nieodpowiedniej platformy.

Szansą Amazon jest przyspieszenie tych decyzji i lepsze ich ugruntowanie w informacjach. Wzmocniłoby to jego ofertę treningową bez konieczności uzyskiwania korzystnego wyniku dla każdego obciążenia.

Co potwierdziłoby trwałą alternatywę dla treningu

Kolejne dowody powinny śledzić czas iteracji, utrzymywaną kompatybilność i wdrożenie wykraczające poza obsługiwane demonstracje.

Pierwszym sygnałem w nadchodzących miesiącach będzie odtwarzalne skrócenie czasu oczekiwania na początkową kompilację. Komunikaty o wydaniach powinny być zestawiane z tymi samymi modelami i istotnymi zmianami architektury. W przeciwnym razie szybszy wynik może odzwierciedlać inny eksperyment.

Ważnym rezultatem jest krótsza droga do wiarygodnego wyniku. Jeśli przygotowanie się poprawia, a poprawność i wielokrotne wykonywanie pozostają porównywalne, propozycja Amazon dla badań staje się mocniejsza. Jeśli oczekiwanie utrzymuje się przy zwykłych zmianach, natywny interfejs pozostawia nierozwiązany znaczący ciężar.

Ocena powinna obejmować zarówno świeże, jak i powtarzane uruchomienia. Badacze muszą odróżniać korzyści wynikające z wyników kompilacji w pamięci podręcznej od ulepszeń pomagających w nieznanych obciążeniach. Oba mają znaczenie, lecz odpowiadają na różne pytania dotyczące codziennej użyteczności.

Drugim sygnałem jest kompatybilność, która przetrwa aktualizacje oprogramowania. Obsługa interfejsu przy premierze ustanawia punkt wyjścia. Zespoły potrzebują, by model, jego zależności i backend urządzenia nadal współdziałały w miarę zmian prowadzonych badań.

Warto obserwować przejrzyste raportowanie nowo obsługiwanych operacji, pozostałych wyłączeń i regresji. Kurcząca się lista wyjątków wzmocniłaby argument, że Amazon przejmuje więcej pracy adaptacyjnej. Powtarzające się naprawy w kodzie użytkownika osłabiłyby go.

To właśnie tutaj TorchNeuron, rozumiany jako strategia rozwoju, staje się bardziej użyteczny niż slogan premierowy. Jego wartość zależy od tego, jak dużej konserwacji specyficznej dla sprzętu użytkownicy mogą z czasem uniknąć. Interfejs jest początkiem tej obietnicy.

Trzecim sygnałem są szczegółowe raporty zespołów obsługujących zróżnicowane obciążenia treningowe. Przydatne relacje powinny wyjaśniać, co przeniesiono, co wymagało dostosowania i co pozostało na istniejącej infrastrukturze. Powinny też odróżniać rutynowe wsparcie dostawcy od wyjątkowej pomocy inżynieryjnej.

Takie raporty pomogłyby czytelnikom ocenić, czy doświadczenie wykracza poza przygotowaną receptę. Niezależne odtworzenie dodatkowo wzmocniłoby dowody. Wąski zestaw demonstracji pozostawiłby niepewność co do skali praktycznego wdrożenia.

Konsekwencje różnią się dla różnych odbiorców. Deweloperzy zyskują kolejne środowisko do oceny względem własnych eksperymentów. Nabywcy korporacyjni zyskują powód, by zadawać bardziej precyzyjne pytania o nakład pracy związany z migracją i utrzymaniem.

Użytkownicy produktów AI powinni oczekiwać pośredniego efektu. Lepsze decyzje infrastrukturalne mogą wpływać na sposób, w jaki zespoły produktowe rozdzielają czas inżynieryjny i realizują ulepszenia modeli. Samo ogłoszenie nie ustanawia żadnej konkretnej poprawy w aplikacjach, z którymi spotykają się ci użytkownicy.

Dla zespołów śledzących tę zmianę: przechowujcie ustawienia benchmarków, wersje oprogramowania i wyjaśnienia awarii obok korzystnych wyników. Przeszukiwalna baza wiedzy może zapewnić dostępność tych dowodów, gdy kolejne wydanie backendu zmieni porównanie.

Zacznij od obciążenia badawczego, które twój zespół rozumie, a następnie oceń pełną drogę od zmiany w kodzie do zweryfikowanego wyniku. Rejestruj czas przygotowania, zachowanie podczas wykonania, nakład pracy przy debugowaniu i potrzeby utrzymaniowe. Utrzymuj porównanie powiązane z pracą, którą zamierzasz powtarzać. Trening Amazon Trainium oferuje teraz bardziej znajomą drogę do takiej oceny, a publiczna beta uwidacznia pozostałe luki szerszej grupie odbiorców. Czytaj ujawnienia dotyczące kompatybilności wraz z wynikami wydajności, a następnie wracaj do decyzji w miarę rozwoju oprogramowania. Użyteczne pytanie brzmi, czy twój zespół może ukończyć więcej wiarygodnych eksperymentów przy dostępnych zasobach. Wybierz platformę, która demonstruje taki rezultat dla twojego obciążenia.