Wyścig infrastrukturalny AMD i Google zmienia się, gdy Schneider Electric umożliwia wdrożenie Helios
- Martin Chen

- 4 sie
- 11 minut(y) czytania
Schneider Electric i AMD opublikowały pierwszy projekt infrastruktury dla Helios, obsługujący szafy rack o mocy 246 kilowatów oraz klastry o obciążeniu IT sięgającym 10,4 megawata. To w praktyczny sposób zmienia rywalizację infrastrukturalną amd google. AMD ma teraz udokumentowaną ścieżkę od specyfikacji akceleratorów do działającego centrum danych o wysokiej gęstości.
Ogłoszenie nie daje AMD nagłej przewagi wydajnościowej nad Google, Nvidia ani innym dostawcą platform. Rozwiązuje inną słabość konkurencyjną. Zakup akceleratorów to dopiero początek, gdy każda szafa rack wymaga również specjalistycznej dystrybucji zasilania, chłodzenia cieczą, systemów sterowania i modelowania na poziomie obiektu.
Google przez lata rozwijało te systemy wokół swoich Tensor Processing Units, czyli TPU — procesorów zoptymalizowanych pod kątem zadań uczenia maszynowego. Nvidia również współpracowała ze Schneider Electric nad fizyczną infrastrukturą dla swoich systemów przyspieszanych. AMD musi przekonać operatorów, że Helios może stać się operacyjnym klastrem, nie zmuszając ich do samodzielnego projektowania wspierającej go infrastruktury.
Dlatego ten projekt referencyjny ma znaczenie. Sprawia, że Schneider Electric jest czymś więcej niż dostawcą sprzętu. Firma staje się częścią odpowiedzi AMD na pionowo zintegrowaną infrastrukturę AI.
Plan Helios łączy chipy z obiektem o mocy 10,4 MW
AMD i Schneider Electric zdefiniowały fizyczne systemy otaczające Helios, a nie tylko układ procesorów wewnątrz jego szafy rack.
Firmy ogłosiły wspólnie opracowany projekt w San Francisco 23 lipca 2026 roku. Według planu Helios obsługuje on modułowe klastry AI osiągające 10,4 megawata mocy IT.
Każda szafa rack o wysokiej gęstości może wymagać do 246 kilowatów. Szafa na tym poziomie zużywa kilkukrotnie więcej energii niż wiele konwencjonalnych instalacji korporacyjnych. Koncentruje też niemal całą tę energię elektryczną w postaci ciepła, które musi być nieustannie odprowadzane.
Helios łączy akceleratory AMD Instinct MI455X, procesory EPYC szóstej generacji, karty sieciowe Pensando Vulcano oraz środowisko programowe ROCm. ROCm to otwarty stos oprogramowania AMD do programowania i obsługi jego akceleratorów.
Te komponenty obliczeniowe stanowią tylko jedną warstwę. Projekt referencyjny obejmuje zasilanie obiektu, chłodzenie obiektu, przestrzeń IT oraz oprogramowanie do zarządzania cyklem życia. Określa, jak te warstwy powinny współpracować wokół wymagań Helios.
Schneider Electric podaje, że jego system chłodzenia Motivair może odprowadzać do 84 procent ciepła za pomocą metod opartych na cieczy oraz hybrydowego chłodzenia powietrzno-cieczowego. Jednostki dystrybucji chłodziwa, czyli CDU, przenoszą ciepło między obiegiem szafy rack a systemem chłodzenia budynku.
Projekt wykorzystuje również modelowanie elektryczne ETAP i obliczeniową dynamikę płynów za pośrednictwem EcoStruxure IT Design. Obliczeniowa dynamika płynów symuluje przepływ powietrza i zachowanie temperatury, zanim sprzęt trafi na miejsce instalacji.
Operatorzy mogą używać elektrycznego cyfrowego bliźniaka do modelowania zachowania infrastruktury. Unified Operations Center firmy AVEVA zapewnia monitorowanie i widoczność operacyjną po wdrożeniu. Narzędzia te mają wcześniej ujawniać konflikty elektryczne lub termiczne w procesie budowy.
Schneider Electric twierdzi, że ukończona konfiguracja może osiągnąć wskaźnik efektywności wykorzystania energii, czyli PUE, wynoszący około 1,12 przy pełnym obciążeniu. PUE porównuje całkowite zużycie energii przez obiekt z energią dostarczaną do sprzętu obliczeniowego. Wartość bliższa 1 oznacza mniejsze narzuty, choć rzeczywiste wyniki zależą od klimatu, wykorzystania zasobów i wyborów operacyjnych.
Początkowy projekt spełnia wymagania American National Standards Institute dla wdrożeń w Stanach Zjednoczonych. Schneider Electric planuje opracować wersję zgodną ze standardami International Electrotechnical Commission dla innych rynków.
To ograniczenie geograficzne ma znaczenie. Ogłoszenie oferuje zweryfikowany punkt wyjścia, a nie uniwersalny projekt, który może ominąć lokalne przepisy elektryczne lub warunki sieciowe. Klienci nadal potrzebują prac inżynieryjnych dostosowanych do ich lokalizacji.
Zgodnie z niezależnymi doniesieniami, plan jest dostępny bez odrębnej opłaty dla klienta. Jego rzeczywista wartość wynika z ograniczenia niepewności związanej z integracją, a nie z kosztu pozyskania dokumentu.
Projekt referencyjny nie dostarcza energii elektrycznej ani nie zapewnia przyłącza do sieci. Nie może wylać betonu, uzyskać praw do wody ani rozwiązać kwestii lokalnych pozwoleń. Może zawęzić zakres nierozstrzygniętych pytań inżynieryjnych, gdy istnieje już odpowiednia lokalizacja.
To rozróżnienie ustanawia główne napięcie artykułu. AMD stworzyło konkurencyjne procesory i architekturę w skali szafy rack. Teraz potrzebuje powtarzalnego sposobu instalowania tej architektury w obiektach budowanych z uwzględnieniem rzeczywistych ograniczeń fizycznych.
Dlaczego rywalizacja AMD i Google wykracza poza chipy
Porównanie amd google coraz bardziej zależy od inżynierii obiektowej, ponieważ gęste systemy AI konkurują jako kompletne platformy elektryczne, termiczne, sieciowe i programowe.
Google eksploatuje własną infrastrukturę AI od około dekady. W ramach jednej organizacji projektuje TPU, sieci w skali podów, systemy chłodzenia, platformy programowe i wiele wspierających komponentów centrów danych.
To doświadczenie zapewnia przewagę, której nie oddają same specyfikacje akceleratorów. Google może koordynować plany rozwoju procesorów z budynkami, w których te procesory pracują. Może też testować zmiany infrastrukturalne w dużej wewnętrznej flocie, zanim zaoferuje moce obliczeniowe za pośrednictwem Google Cloud.
Google podało, że przez siedem lat wdrożyło chłodzenie cieczą w skali gigawatów w ponad 2 000 podów TPU. Firma poinformowała również o dostępności na poziomie około 99,999 procent dla tych wdrożeń chłodzenia. Omówiła to doświadczenie podczas prezentacji projektów szaf rack o mocy jednego megawata.
Są to dane raportowane przez firmę, a nie niezależne porównanie z AMD Helios. Pokazują jednak dojrzałość operacyjną, z którą muszą się zmierzyć konkurencyjne platformy infrastrukturalne.
Google opracowało również Brazos — montowany w szafie rack system chłodzenia ciecz-powietrze dla sprzętu chłodzonego cieczą w obiektach chłodzonych powietrzem. System Brazos odbiera ciepło przez zamknięty obieg cieczy, a następnie oddaje je do istniejącego gorącego korytarza.
Brazos i projekt Helios firmy Schneider Electric odpowiadają na różne scenariusze wdrożeniowe. Oba jednak odzwierciedlają tę samą presję w branży. Wdrażanie sprzętu AI zatrzymuje się, gdy docelowy budynek nie może zapewnić wymaganego obiegu cieczy, zasilania elektrycznego lub zdolności odprowadzania ciepła.
AMD nie posiada floty hiperskalowych centrów danych porównywalnej z Google. Potrzebuje więc partnerów infrastrukturalnych, producentów serwerów, dostawców chmury i dostawców sieci, aby stworzyć równoważną ścieżkę dla klientów.
Schneider Electric wypełnia znaczną część tej luki. Wnosi dystrybucję zasilania, sprzęt chłodzący, oprogramowanie do modelowania i inżynierię obiektową do programu AMD w skali szafy rack. HPE zapewnia inną drogę, włączając Helios do systemów komercyjnych.
Ten model partnerstwa może oferować elastyczność. Klient nie jest ograniczony do procesora lub architektury obiektu jednego operatora chmury. Operatorzy mogą dostosować otwarty projekt do projektów kolokacyjnych, chmur prywatnych, suwerennej AI i wyspecjalizowanych systemów obliczeniowych.
Model oparty na partnerach stwarza jednak również ryzyko koordynacyjne. Zmiany w akceleratorze, przełączniku, CDU, magistrali elektrycznej lub wydaniu oprogramowania mogą wpływać na kilka firm. Walidacja musi nadążać za planami rozwoju każdego kluczowego komponentu.
Zintegrowany model Google zmniejsza część tego organizacyjnego dystansu. Firma może zgrywać zespoły TPU, sieci, oprogramowania i infrastruktury poprzez wewnętrzne planowanie. Może też zarezerwować swoją infrastrukturę dla obciążeń pasujących do jej ekonomiki.
Kompromisem jest kontrola klienta. Klient Google Cloud korzysta z platformy głównie jako z usługi zarządzanej. Nabywca Helios może uzyskać bardziej bezpośrednią kontrolę nad środowiskiem obliczeniowym, projektem obiektu i modelem operacyjnym.
Nie oznacza to, że AMD i Google są bezpośrednimi substytutami w każdym procesie zakupowym. Google sprzedaje usługi chmurowe i używa własnych układów krzemowych, podczas gdy AMD sprzedaje procesory i technologię platformową za pośrednictwem sieci branżowej.
Mimo to nabywcy korporacyjni porównują uzyskaną w ten sposób moc obliczeniową. Analizują czas wdrożenia, kompatybilność modeli, dostępne regiony, kontrolę operacyjną, wydajność i zużycie energii. Jednostką konkurencji staje się działający klaster AI, a nie pojedynczy chip.
Nvidia pozostaje najważniejszym punktem odniesienia na tym rynku. Schneider Electric ogłosił współpracę infrastrukturalną z Nvidia w 2024 roku, koncentrującą się na dystrybucji wysokiej mocy i chłodzeniu cieczą dla gęstych klastrów akceleratorów. Ta wcześniejsza współpraca z Nvidia pokazuje, że Schneider nie wybiera jednej platformy akceleratorowej.
Zamiast tego Schneider Electric odnosi korzyści, gdy kilka architektur wymaga nowych projektów obiektowych. Dla AMD relacja ta zapewnia wiarygodność infrastrukturalną. Dla klientów tworzy kolejną zaprojektowaną opcję obok natywnych dla chmury TPU i systemów skoncentrowanych na Nvidia.
Zasilanie i chłodzenie definiują teraz mechanizm konkurencji
Wkład Schneider Electric ma znaczenie, ponieważ szafa rack o mocy 246 kilowatów zmienia obiekt szybciej, niż zmienia arkusz kalkulacyjny procesu zakupowego.
Tradycyjne planowanie serwerów często traktowało centrum danych jako stabilny kontener. Nabywcy wybierali serwery, przydzielali pozycje w szafach rack i sprawdzali, czy istniejąca moc elektryczna oraz wydajność chłodzenia są wystarczające.
AI o wysokiej gęstości odwraca tę kolejność. Obciążenie i plan rozwoju akceleratorów kształtują teraz topologię elektryczną, instalację rurową, układ powierzchni, model redundancji i harmonogram budowy. Budynek zaprojektowany dla wczorajszych serwerów nie może automatycznie przyjąć jutrzejszych szaf rack.
Przy 246 kilowatach szafa Helios wymaga bezpośredniej koordynacji między sprzętem obliczeniowym a systemami obiektu. Projekt elektryczny musi obsłużyć obciążenie stałe, zachowanie przejściowe, ustawienia zabezpieczeń, stany konserwacyjne i scenariusze awarii.
Projekt chłodzenia musi dostarczać wystarczającą ilość cieczy do każdej płyty chłodzącej. Musi też przenosić ciepło przez CDU i obiegi obiektowe bez powodowania niedopuszczalnych zmian temperatury lub nierównowagi przepływu.
Chłodzenie powietrzem pozostaje częścią projektu, ponieważ niektóre komponenty i otaczające urządzenia nadal oddają ciepło do pomieszczenia. Schneider Electric opisuje więc podejście hybrydowe, zamiast twierdzić, że ciecz eliminuje wszystkie wymagania po stronie chłodzenia powietrzem.
Biblioteka projektów referencyjnych firmy wyjaśnia, dlaczego modelowanie musi obejmować zachowanie elektryczne, przepływ powietrza i przepływ cieczy. Każdy model wykrywa inną klasę awarii. Ich połączenie może zidentyfikować wzajemne oddziaływania, zanim operatorzy zasilą klaster.
Rozważmy częściową awarię chłodzenia. Pozostałe urządzenia muszą przejąć dodatkowe ciepło albo obciążenie obliczeniowe musi szybko spaść. Takie zdarzenie wpływa na systemy sterowania obiektem, harmonogramowanie klastra i potencjalnie na postęp trenowania modeli.
Przerwa w zasilaniu tworzy kolejny problem obejmujący wiele warstw. Systemy zapasowe muszą obsługiwać zakładany stan działania, podczas gdy środowisko programowe radzi sobie z przerwanymi zadaniami. Odporności obiektu i odporności systemów obliczeniowych nie można planować niezależnie.
To jest mechanizm stojący za partnerstwem Helios. AMD definiuje zachowanie i wymagania platformy obliczeniowej. Schneider Electric przekłada te wymagania na konfiguracje infrastruktury, które zespoły projektowe mogą ocenić.
Modułowy projekt klastra o mocy 10,4 megawata dodaje kolejną warstwę. Operatorzy mogą planować przepustowość w powtarzalnych blokach, zamiast projektować każde wdrożenie od zera. Standaryzacja może uprościć zakupy i ograniczyć rozbieżności między inżynierami, wykonawcami i dostawcami technologii.
Powtarzalność pomaga również dostawcom prognozować zapotrzebowanie na sprzęt. Moduły CDU, rozdzielnice, systemy monitoringu i prefabrykowane elementy można planować wokół znanych konfiguracji klastrów. Jednak nawet powielany moduł nadal wymaga integracji na poziomie lokalizacji.
Możliwości sieci elektroenergetycznej pozostają najtrudniejszą granicą. Dopracowany projekt nie gwarantuje, że dostawca energii będzie w stanie dostarczyć dodatkowe 10,4 megawata w pożądanym terminie. Kolejki przyłączeniowe i prace przy stacjach transformatorowych mogą trwać dłużej niż harmonogram wdrożenia sprzętu obliczeniowego.
Odprowadzanie wody i ciepła również różni się zależnie od lokalizacji. Obiekt może wymagać agregatów chłodniczych, suchych chłodnic, wież chłodniczych lub innej konfiguracji, zależnie od klimatu i lokalnych ograniczeń. Projekt referencyjny nie może wyeliminować tych różnic środowiskowych.
Deklarowane PUE na poziomie około 1,12 zasługuje na podobny kontekst. PUE zmienia się wraz z wykorzystaniem, pogodą, redundancją, metodą chłodzenia i granicami pomiaru. Modelowana wartość przy pełnym obciążeniu nie powinna być traktowana jako gwarantowany wynik roczny.
Operatorzy muszą też zdecydować, jaką część mocy zarezerwować na konserwację i awarie. Wykorzystanie redundantnej infrastruktury do dodatkowych obliczeń może poprawić wykorzystanie podczas normalnej pracy. Jednocześnie zmniejsza margines dostępny, gdy sprzęt zostaje wyłączony z eksploatacji.
Schneider Electric opisuje ten wybór jako konkurencję między dodatkową mocą obliczeniową a pierwotną strategią redundancji. Decyzja powinna być wyraźna, ponieważ niewykorzystana przepustowość zapasowa nie jest automatycznie darmową mocą produkcyjną.
Google napotyka te same fizyczne ograniczenia mimo swojego zintegrowanego modelu. Prace firmy nad chłodzeniem cieczą pokazują, że własne układy scalone nie eliminują konieczności inżynierii obiektowej. Zamiast tego organizacja musi rozwijać systemy chłodzenia i zasilania wraz z każdą generacją systemów obliczeniowych.
Porównanie amd google ujawnia zatem dwa podejścia do tego samego mechanizmu. Google koordynuje znaczną część stosu wewnętrznie. AMD buduje otwartą sieć partnerów wokół Helios, a Schneider Electric obsługuje kluczową warstwę infrastruktury obiektu.
Zweryfikowany projekt to nie zweryfikowane wdrożenie
Główna niepewność dotyczy tego, czy klienci będą w stanie odtworzyć modelowane wyniki projektu w rzeczywistych lokalizacjach, przy różnych obciążeniach, dostawcach i warunkach operacyjnych.
Schneider Electric i AMD opisują projekt jako wspólnie opracowany i zweryfikowany. Taka weryfikacja wskazuje, że komponenty i założenia inżynieryjne oceniono łącznie. Nie potwierdza jednak wydajności w warunkach terenowych w dużej bazie zainstalowanej.
Wraz z lipcowym ogłoszeniem nie przedstawiono publicznych wyników wdrożeń u klientów. Firmy nie ujawniły ukończonego obiektu Helios, działającego nieprzerwanie przy 246 kilowatach na szafę rack w ramach nowego projektu.
Ta luka jest normalna w przypadku nowo wydanej architektury. Nadal ogranicza to, co nabywcy mogą wnioskować o czasie uruchomienia, zachowaniu w przypadku awarii, dostępności komponentów i długoterminowym utrzymaniu.
Platforma Helios zależy również od dostaw sprzętu zgodnie z planem. Jej projekt obejmuje akceleratory MI455X, procesory EPYC szóstej generacji i interfejsy sieciowe Vulcano. Opóźnienia lub zmiany specyfikacji mogą wymusić kolejny cykl walidacji.
Sieci stanowią szczególne ryzyko. Helios wykorzystuje otwarte podejście zorientowane na Ethernet, zaprojektowane jako alternatywa dla ściśle zintegrowanego środowiska NVLink firmy Nvidia. Daje to nabywcom większą elastyczność w wyborze dostawców, ale zwiększa znaczenie rozwijającego się ekosystemu partnerów.
HPE ogłosiło plany oferowania systemów opartych na Helios, zapewniając AMD istotny kanał komercyjny. Wdrożenie HPE wykorzystuje wysokoprzepustową strukturę akceleratorową i przeznaczony do tego przełącznik.
Szczegółowa analiza systemu Helios opisała planowaną konfigurację z 72 akceleratorami MI455X. Raport wskazał również cel AMD wynoszący 31 terabajtów pamięci HBM4 i 2,9 eksaFLOPS mocy obliczeniowej FP4 na szafę rack.
Te wartości są celami powiązanymi z przyszłym sprzętem, a nie niezależnie zweryfikowanymi wynikami produkcyjnymi. FP4 to niskoprecyzyjny format liczbowy stosowany w niektórych zadaniach inferencji AI. Nie należy porównywać go bezpośrednio z każdym obciążeniem treningowym czy naukowym.
Oprogramowanie pozostaje kolejną zmienną. ROCm rozszerzył obsługę frameworków i modeli, lecz sama dostępność sprzętu nie gwarantuje równoważnej wydajności aplikacji. Nabywcy muszą testować własne modele, operatory, kompilatory i zachowanie rozproszonego treningu.
Google może optymalizować kluczowe obciążenia dla TPU za pośrednictwem JAX, XLA i swojego wewnętrznego środowiska programowego. Nvidia dysponuje od dawna ugruntowaną bazą programistów CUDA. AMD musi udowodnić, że jej otwarty stos zmniejsza zależność bez przenoszenia nadmiernej pracy integracyjnej na klientów.
Projekt referencyjny może rozwiązać kwestię planu obiektu, pozostawiając nierozwiązaną migrację aplikacji. Ta granica ma znaczenie dla zespołów korporacyjnych oceniających pełny koszt zmiany platform akceleratorowych.
Konserwacja tworzy kolejny test. Obiegi cieczy dodają pompy, połączenia, czujniki, kolektory i procedury serwisowe w pobliżu kosztownego sprzętu obliczeniowego. Operatorzy potrzebują dowodów dotyczących wycieków, filtracji, jakości chłodziwa, wymiany komponentów i szkolenia personelu.
Wartość 84 procent odprowadzania ciepła również wymaga ostrożnej interpretacji. Schneider Electric twierdzi, że proponowane rozwiązania chłodzenia są zdolne usuwać w ten sposób tę część ciepła za pośrednictwem cieczy. Pozostałe obciążenie cieplne i warunki pracy nadal kształtują potrzeby chłodzenia na poziomie pomieszczenia.
Ta sama ostrożność dotyczy szybkości wdrożenia. Wstępnie zaprojektowany projekt może skrócić planowanie i ograniczyć powielanie pracy. Nie może zagwarantować szybszej budowy, gdy transformatory, rozdzielnice, agregaty chłodnicze, akceleratory lub modernizacje sieci pozostają ograniczone.
Pojawia się też pytanie komercyjne. Nabywcy muszą zdecydować, czy większy wybór architektoniczny uzasadnia obsługę bardziej rozproszonej relacji z dostawcami. Niektórzy wybiorą usługę chmurową, która ukrywa infrastrukturę obiektu pod API.
Inni docenią bezpośrednią kontrolę, lokalną rezydencję danych lub niezależność od jednej platformy chmurowej. Projekty suwerennej AI i wyspecjalizowani dostawcy chmury są szczególnie skłonni rozważyć tę opcję.
To napięcie sprawia, że strategia AMD jest wiarygodna, ale nieukończona. Schneider Electric ograniczył jedną kategorię niepewności. Wdrożenia u klientów muszą teraz pokazać, czy połączony system działa konsekwentnie poza modelowanym środowiskiem.
Trzy sygnały pokażą, czy AMD zdoła zamknąć lukę infrastrukturalną
Kolejny etap zależy od dowodów operacyjnych, realizacji przez partnerów i powtarzalnego wdrażania przez klientów, a nie od kolejnej rundy deklaracji architektonicznych.
Pierwszym sygnałem będzie ukończone wdrożenie u klienta wykorzystujące projekt Schneider Electric. Najmocniejsze dowody obejmowałyby zmierzoną gęstość szaf rack, czas uruchomienia, wydajność chłodzenia, dostępność i PUE przy realistycznych zmianach obciążeń.
Jeden pilotaż potwierdziłby, że projekt może opuścić środowisko projektowe. Kilka wdrożeń w różnych klimatach i typach obiektów wspierałoby mocniejszy wniosek o powtarzalności.
Wynik zbliżony do deklarowanego PUE 1,12 przy pełnym obciążeniu wzmocniłby argument firm dotyczący efektywności. Wynik znacząco wyższy od tej wartości nie unieważniłby automatycznie projektu, lecz pokazałby znaczenie warunków lokalizacyjnych.
Nabywcy powinni również obserwować, jak operatorzy radzą sobie z awariami i konserwacją. Klaster o wysokiej gęstości musi pozostać serwisowalny, gdy uwagi wymaga CDU, pompa, komponent elektryczny lub taca obliczeniowa.
Drugim sygnałem będzie skoordynowana realizacja przez partnerów AMD w zakresie sprzętu i sieci. Akceleratory MI455X, nowe procesory EPYC, interfejsy Vulcano, przełączniki, serwery i wyposażenie obiektu muszą trafiać do projektów w zgodnych harmonogramach.
Architektura referencyjna traci wartość, jeśli jeden niezbędny komponent powoduje długie opóźnienie. Z kolei zsynchronizowana dostępność pokazałaby, że model partnerski AMD może działać jak spójna platforma.
Testy interoperacyjności będą szczególnie ważne. Klienci potrzebują dowodów, że zmiany w serwerach, przełącznikach, oprogramowaniu, zasilaniu i chłodzeniu nie tworzą powtarzających się cykli przeprojektowywania.
Komercyjne systemy Helios firmy HPE zapewnią wczesny test. Dodatkowi producenci serwerów lub operatorzy chmurowi, którzy przyjmą te same założenia na poziomie szafy rack, wzmocniliby standaryzację.
Trzecim sygnałem będzie wdrażanie obciążeń w konkurencji z TPU Google i systemami Nvidia. AMD nie potrzebuje, aby każdy nabywca zastąpił te platformy. Potrzebuje wystarczającej liczby obciążeń produkcyjnych, by ustanowić Helios jako niezawodną alternatywę.
Dowody te powinny obejmować zastosowania treningowe i inferencyjne, a nie tylko szczytowe wyniki benchmarków. Operatorzy będą analizować użyteczną wydajność, nakład pracy związany z oprogramowaniem, dostępność klastra, zużycie energii i szybkość rozszerzania mocy.
Własny rozwój infrastruktury Google stanowi użyteczny punkt odniesienia. Długa historia firmy w zakresie chłodzenia cieczą pokazuje, że wiedza operacyjna kumuluje się przez kolejne generacje sprzętu. AMD i Schneider Electric muszą zacząć budować porównywalny dorobek za pośrednictwem klientów i partnerów.
Porównanie amd google pozostanie niedoskonałe, ponieważ firmy zajmują różne pozycje na rynku. Google prowadzi zintegrowaną chmurę i platformę opartą na własnych układach scalonych. AMD dostarcza otwartą architekturę wdrażaną przez inne firmy.
Jednak to właśnie ten kontrast sprawia, że nowy projekt ma znaczenie. Daje nabywcom wybór między korzystaniem ze zintegrowanej platformy a budowaniem zweryfikowanego systemu opartego na partnerach i pozostającego pod ich kontrolą.
Nvidia również wpłynie na wynik. Jej systemy na skalę szafy rack, baza oprogramowania i partnerstwa infrastrukturalne wyznaczają punkt odniesienia dla dojrzałości wdrożeniowej. Jeśli Nvidia będzie rozwijać się szybciej, otwarta architektura AMD będzie musiała to zrekompensować elastycznością, dostępnością lub ekonomią obciążeń.
Schneider Electric ma zachęty do wspierania każdej dużej platformy. Ta neutralna pozycja może pomóc klientom porównywać wymagania infrastrukturalne bez traktowania jednej mapy rozwoju akceleratorów jako trwałej.
Dla zespołów technicznych i zakupowych natychmiastowe działanie jest konkretne. Najpierw należy modelować zamierzone obciążenia, a następnie sprawdzić, czy wybrana lokalizacja może spełnić ich wymagania elektryczne, cieplne, sieciowe i dotyczące odporności.
Zespoły oceniające duże ogłoszenia infrastrukturalne potrzebują również trwałego sposobu łączenia założeń inżynieryjnych z późniejszymi dowodami operacyjnymi. Przeszukiwalna baza wiedzy technicznej może zapewnić dostępność dokumentów projektowych, wyników testów i decyzji dotyczących dostawców w miarę zmian projektów.
Projekt Schneider Electric nie rozstrzyga wyścigu akceleratorów. Przenosi AMD do trudniejszego etapu, w którym specyfikacje szaf rack muszą wytrzymać ograniczenia sieci elektroenergetycznej, harmonogramy budowy, awarie chłodzenia i obciążenia produkcyjne.
Czy klienci Helios opublikują zmierzone wyniki zgodne z projektem i czy partnerzy dostarczą każdą warstwę na czas? To są testy, które mają teraz znaczenie. Obserwuj pierwsze działające lokalizacje, skoordynowaną dostępność sprzętu i wdrażanie obciążeń, zanim ogłosisz zwycięzcę wyścigu infrastrukturalnego AMD Google.


