NVIDIA Vera Rubin na OCI zmierza w stronę skali wielu gigawatów, a CPU odgrywają większą rolę

NVIDIA i Oracle ogłosiły 27 października planowaną rozbudowę do skali wielu gigawatów, a także ogólną dostępność NVIDIA Vera Rubin na OCI. Ogłoszenie łączy nową pojemność GPU z niezależnymi CPU Vera do zadań wykonywanych między wywołaniami modeli. Jego znaczenie wykracza poza większe klastry: klienci mogą niezależnie rozbudowywać te zasoby wraz ze zmianami w swoich aplikacjach.

OCI, skrót od Oracle Cloud Infrastructure, przedstawia tę elastyczność deweloperom tworzącym agentów, czyli systemy oprogramowania wywołujące modele i uruchamiające narzędzia. Takie aplikacje naprzemiennie generują odpowiedzi i wykonują zwykłe zadania obliczeniowe. Zakup większej pojemności do obsługi modeli nie przyspiesza automatycznie towarzyszącej im pracy.

Główne napięcie dotyczy rozbudowy zainstalowanej mocy obliczeniowej przy jednoczesnym utrzymaniu jej produktywności. Google Cloud już promuje skoordynowaną infrastrukturę CPU i akceleratorów za pośrednictwem Ironwood i Axion. Ogłoszenie Oracle wyraźniej eksponuje tę samą konkurencję na poziomie całych systemów, jednocześnie zapewniając biznesowi CPU NVIDIA bardziej widoczne miejsce obok jej GPU.

NVIDIA Vera Rubin na OCI łączy dostępność z planem rozbudowy

Bezpośrednie wprowadzenie produktu na rynek i planowana rozbudowa infrastruktury to różne etapy.

We wspólnym komunikacie dotyczącym rozbudowy Vera Rubin NVIDIA i Oracle odróżniają obecną dostępność od przyszłej skali. Systemy Vera Rubin NVL72 i CPU Vera są ogólnie dostępne na OCI. Rozbudowa OCI Superclusters z wykorzystaniem tych systemów do skali wielu gigawatów pozostaje deklarowanym planem.

To rozróżnienie ma znaczenie dla czytelników interpretujących nagłówek. Ogólna dostępność ustanawia ofertę komercyjną. Nie oznacza, że cała planowana rozbudowa jest zainstalowana, zasilana, zarezerwowana lub obsługuje obciążenia klientów.

Gigawat mierzy moc, a nie ilość wykonanej pracy obliczeniowej. Przełożenie zobowiązania energetycznego na użyteczne usługi AI wymaga sprzętu, sieci, chłodzenia, oprogramowania i wdrożeń klientów. Nagłówek opisuje więc zamierzony ślad infrastrukturalny, nie potwierdzając odpowiadającej mu ilości dostarczonych wyników aplikacji.

Sama szafa serwerowa stanowi bardziej konkretny punkt odniesienia. Specyfikacja NVL72 firmy NVIDIA opisuje konfigurację łączącą 72 GPU Rubin i 36 CPU Vera. GPU, czyli procesor graficzny, realizuje równoległe obliczenia kluczowe dla trenowania modeli i inferencji, czyli procesu generowania wyników przez model.

Komponenty te współpracują wewnątrz szafy, ale osobna oferta CPU odpowiada na inną decyzję zakupową. Klienci uruchamiający wykonywanie narzędzi lub usługi aplikacyjne potrzebują mocy obliczeniowej poza ściśle połączonym systemem obsługi modeli. Oracle i NVIDIA twierdzą, że klienci mogą niezależnie skalować swoje zasoby CPU i GPU.

Praktycznym skutkiem jest elastyczność w sposobie konstruowania aplikacji przez klientów. Zespół nie musi koniecznie rozbudowywać każdej puli zasobów za każdym razem, gdy jeden etap staje się przeciążony. Może ocenić, czy dodatkowej pojemności wymaga generowanie przez model, wykonywanie kodu, wyszukiwanie informacji czy inny etap.

To opcja architektoniczna, a nie automatyczna poprawa efektywności. Aplikacje nadal potrzebują oprogramowania, które kieruje pracę do odpowiednich zasobów i reaguje na zmiany popytu. Niezależne skalowanie daje operatorom dodatkową kontrolę; nie decyduje za nich, jak powinni z niej korzystać.

Dla nabywców ogłoszenie rodzi odrębne pytania dotyczące dostępności i realizacji. Jakie konfiguracje mogą uzyskać teraz? Gdzie mogą je uzyskać? Jaką pojemność Oracle może zagwarantować przez cały okres ich wdrożenia?

Te pytania określają również, jak dużą wagę należy przypisać planowi rozbudowy. Duży przyszły ślad infrastrukturalny stanowi użyteczny kontekst dla długoterminowych zakupów. Konkretna alokacja, obsługiwana konfiguracja i termin wdrożenia dostarczają bardziej bezpośrednich dowodów przy podejmowaniu decyzji inżynieryjnej.

Obciążenia agentowe zwiększają presję na obliczenia między wywołaniami modeli

Ogłoszenie wywiera presję na zespoły, które mierzą pojemność AI głównie przez pryzmat swojej floty GPU.

Odpowiedź modelu jest tylko częścią pracy agenta. Po wybraniu działania aplikacja musi je wykonać, sprawdzić wynik i zdecydować, co wydarzy się dalej. Te etapy wprowadzają inne wymagania obliczeniowe i inne źródła opóźnień.

Rozważmy przykładowego agenta programistycznego, któremu powierzono naprawę niedziałającej aplikacji. Pobiera pliki projektu, prosi model o zaproponowanie zmiany, uruchamia testy i przekazuje wyniki do kolejnej decyzji. Model i narzędzie uruchamiające testy wykonują różną pracę, choć użytkownik doświadcza jednego ciągłego zadania.

Dodanie pojemności do obsługi modeli pomaga, gdy ograniczeniem jest generowanie. Pomaga znacznie mniej, gdy testy czekają na środowisko wykonawcze lub czas poświęcany jest na kompilowanie zależności. Istotne pytanie dotyczy tego, gdzie przepływ pracy czeka, a nie który komponent ma najbardziej imponującą specyfikację.

NVIDIA i Oracle wprost wskazują wykonywanie narzędzi, testowanie kodu i pobieranie danych jako zadania intensywnie wykorzystujące CPU, wspierające agentów. CPU, czyli jednostka centralna, wykonuje ogólne instrukcje aplikacji i zarządza dużą częścią tej otaczającej pracy. Firmy pozycjonują niezależną pojemność Vera jako sposób na oddzielne wsparcie tych etapów.

Wdrożenie Vera CPU przez Oracle zawiera deklarację dotyczącą skali: początkowe wdrożenie 150 000 CPU. Oracle opisuje również wczesny dostęp klientów i twierdzi, że OpenAI wprowadza Vera do produkcji dla obciążeń agentowych. Są to oświadczenia dostawcy i klienta przedstawione w publikacji Oracle.

Liczba CPU pokazuje skalę, jaką Oracle przypisuje tej ofercie. Nie ujawnia jednak, ile procesorów może zarezerwować konkretny klient, jak intensywnie są używane ani jaką przepustowość aplikacji zapewniają. Te rozróżnienia zapobiegają traktowaniu skali wdrożenia jako substytutu dowodów operacyjnych.

Bezpośrednia presja spada na planistów infrastruktury i zespoły aplikacji AI. Muszą oni zrozumieć równowagę między żądaniami do modeli a pracą wywoływaną przez te żądania. Proces zakupowy skoncentrowany na liczbie akceleratorów pozostawia tę równowagę niewystarczająco zbadaną.

Nie oznacza to, że każda aplikacja agentowa potrzebuje wyspecjalizowanego wdrożenia CPU. Niektóre przepływy pracy spędzają większość czasu na oczekiwaniu na usługi zewnętrzne. Inne generują długie odpowiedzi modelu przy stosunkowo niewielkim użyciu narzędzi. Odpowiednia mieszanka zasobów zależy od rzeczywistej sekwencji operacji aplikacji.

Ta sama zasada dotyczy przepływów pracy z wiedzą. Asystent przeszukujący bazę wiedzy AI musi odzyskać istotne materiały, zanim przygotuje użyteczną odpowiedź. Dodatkowa pojemność generowania nie zrekompensuje niedostępnych dokumentów, brakujących uprawnień ani wolnego wyszukiwania.

Dla nabywców korporacyjnych łączy to decyzje infrastrukturalne z doświadczeniem użytkownika. Usługa wydaje się wolna, gdy zadanie zatrzymuje się w dowolnym punkcie swojej ścieżki. Klienci rzadko rozróżniają, czy opóźnienie pochodziło od modelu, narzędzia, bazy danych czy oprogramowania je koordynującego.

Ogłoszenie zachęca więc do szerszego standardu oceny. Zespoły powinny pytać, jak infrastruktura wspiera ukończone zadanie, wraz z jego etapami pośrednimi. To presja wywołana przez premierę: wyjaśnianie wydajności aplikacji staje się równie istotne jak opisywanie zainstalowanego sprzętu.

Niezależne skalowanie rozwiązuje problem harmonogramowania

Rozdzielenie wzrostu CPU i GPU pomaga tylko wtedy, gdy aplikacja potrafi skutecznie wykorzystać to rozdzielenie.

Mechanizm stojący za NVIDIA Vera Rubin na OCI jest prosty na poziomie architektury. Należy utrzymywać ściśle połączone zasoby razem tam, gdzie wymaga tego model. Dla otaczających zadań, których zapotrzebowanie podąża innym wzorcem, należy zapewnić oddzielną moc obliczeniową.

Architektura platformy Rubin firmy NVIDIA opisuje system zaprojektowany wokół skoordynowanych obliczeń, sieci i oprogramowania. NVLink, szybkie połączenie NVIDIA między procesorami, wspiera komunikację wewnątrz systemu obliczeniowego modelu. To wewnętrzne połączenie służy innemu celowi niż przydzielanie osobnej puli pracowników wykonujących narzędzia.

To rozróżnienie pozwala uniknąć częstego nieporozumienia. Niezależne skalowanie nie oznacza, że każdy komponent wewnątrz szafy NVL72 zmienia się niezależnie. Opisuje ono sposób, w jaki klienci mogą rozbudowywać odrębne zasoby CPU i GPU w całej infrastrukturze aplikacyjnej.

Wróćmy do przykładu agenta programistycznego. Nagły wzrost aktywności testowej może wymagać dodatkowych pracowników wykonawczych, podczas gdy zapotrzebowanie na model pozostaje względnie stabilne. Inne obciążenie może generować więcej żądań do modeli bez odpowiadającego temu wzrostu kompilacji lub testowania.

Stała alokacja grozi niedostatecznym wykorzystaniem jednej puli zasobów, podczas gdy w innej tworzy się kolejka. Niezależne pule dają operatorom sposób na skorygowanie tej nierównowagi. Korzyść zależy od tego, czy ich oprogramowanie rozpoznaje ograniczenie i wystarczająco szybko udostępnia użyteczną pojemność.

W tym miejscu kluczowe staje się harmonogramowanie, czyli przydzielanie pracy do dostępnych zasobów. Aplikacja musi zdecydować, gdzie uruchamiane jest narzędzie, jakie dane otrzymuje i kiedy zwraca wynik. Dodatkowe procesory pozostają niepełną odpowiedzią, jeśli praca nie może skutecznie do nich dotrzeć.

Lokalizacja danych komplikuje tę decyzję. Pracownik potrzebuje dostępu do plików, zależności, poświadczeń i odpowiedniego stanu aplikacji. Przeniesienie wykonywania poza infrastrukturę obsługi modeli tworzy kolejną granicę, którą oprogramowanie musi zarządzać.

Ta granica nie jest z natury wadą. Może wspierać bardziej przejrzysty przydział i izolację. Nabywca powinien jednak uwzględnić jej konsekwencje operacyjne przy ocenie korzyści z oddzielnych pul zasobów.

Przydatna ocena śledzi reprezentatywne zadanie od zgłoszenia do ukończenia. Rejestruje czas poświęcony na generowanie wyników modelu, oczekiwanie na narzędzia, uruchamianie kodu, pobieranie informacji i ponawianie nieudanych kroków. Celem jest ustalenie, w którym miejscu dodatkowa pojemność zmienia wynik.

Znaczenie ma również pomyślne ukończenie. Szybsze wykonanie jest mniej wartościowe, jeśli prowadzi do większej liczby nieudanych zadań lub wymaga dodatkowych prób. Między znaczącymi porównaniami utrzymuje się stałość zadania i kryteriów akceptacji, analizując jednocześnie wykorzystane zasoby.

Są to zasady oceny, a nie opublikowane wyniki ogłoszenia. Wyjaśniają, jakie dowody wspierałyby argument firm dotyczący efektywności. Premiera ustanawia dostępną architekturę; pomiary klientów muszą potwierdzić jej wartość dla konkretnych aplikacji.

Wyzwanie operacyjne rośnie, gdy obciążenia zmieniają się w czasie. Usługa, która dziś głównie odpowiada na pytania, może po aktualizacji produktu wykonywać więcej działań. Niezależne skalowanie daje możliwość reakcji, pod warunkiem że aplikacja ujawnia informacje potrzebne operatorom.

To sprawia, że oferta CPU jest czymś więcej niż dodatkiem do premiery GPU. Tworzy kolejne miejsce, w którym NVIDIA i Oracle mogą uczestniczyć w infrastrukturze aplikacyjnej. To, czy klienci odniosą korzyść, zależy od tego, jak ściśle ta infrastruktura odpowiada pracy, którą faktycznie wykonują.

Rywale w chmurze konkurują wokół kompletnej aplikacji AI

Ogłoszenie Oracle wpisuje się w rywalizację dotyczącą skoordynowanych systemów, w tym infrastruktury obliczeniowej ogólnego przeznaczenia wspierającej modele AI.

Google Cloud stanowi użyteczne porównanie, ponieważ wyraźnie łączy rozwój akceleratorów i CPU. W ogłoszeniu dotyczącym Ironwood i Axion omawia koordynację wymaganą przez przepływy pracy agentów. Ironwood to TPU, wyspecjalizowany procesor Google do uczenia maszynowego, natomiast Axion obsługuje obliczenia ogólnego przeznaczenia.

Znaczenie ma tu architektura. Google opisuje przyspieszanie modeli wraz z usługami aplikacyjnymi, przygotowaniem danych i innymi zadaniami wymaganymi wokół niego. Oracle i NVIDIA podkreślają obecnie porównywalną potrzebę poprzez systemy Rubin i niezależnie dostępne procesory Vera CPU.

Nie oznacza to równoważności produktów ani wydajności. Platformy różnią się procesorami, środowiskami programistycznymi, ofertą usług i modelami wdrożeń. Ich ogłoszenia wskazują jednak na wspólne pytanie zakupowe: jak dobrze kompletny system wspiera aplikację?

W przypadku Oracle samodzielne procesory Vera CPU rozszerzają dyskusję poza dostęp do akceleratorów NVIDIA. Firma może oferować zasoby do obsługi modeli oraz realizacji zadań wykonywanych wokół nich. Daje to klientom kolejną konfigurację do oceny przy podejmowaniu decyzji, gdzie powinny działać ich agenci.

Dla NVIDIA ogłoszenie zwiększa handlowe znaczenie jej CPU poza rolą w zintegrowanej szafie serwerowej. Jeśli klienci wdrożą Vera do odrębnych usług wykonawczych, NVIDIA będzie uczestniczyć w większej części ich architektury obliczeniowej.

Tej możliwości nie należy mylić z uniwersalnym argumentem za migracją. Istniejące aplikacje mają utrwalone zależności i praktyki operacyjne. Zespoły muszą zestawić nową konfigurację z pracą wymaganą do jej wdrożenia i utrzymania.

Presja konkurencyjna obejmuje również konwencjonalne wdrożenia serwerowe. Nabywcy rozważający Vera będą oczekiwać porównań z systemami, na których już działają ich narzędzia i usługi aplikacyjne. Znana infrastruktura stanowi praktyczny punkt odniesienia, ponieważ zespoły rozumieją jej zachowanie przy własnych obciążeniach.

Najlepsze porównanie zaczyna się zatem od istniejącej aplikacji klienta. Analizuje, czy zmiana platformy wykonawczej poprawia realizację zadań, szybkość reakcji, zużycie zasobów lub niezawodność operacyjną. Przewaga na poziomie komponentu odnosi się jedynie do części tej decyzji.

Ciągłość programowa również ma znaczenie. Firma z ustalonym środowiskiem obsługi modeli rozważy, jak nowa konfiguracja wpisuje się w jej procesy wdrażania i wsparcia. Każda ocena sprzętu, która pomija te procesy, zaniża nakład pracy związany z wdrożeniem.

Dlatego opowieść konkurencyjna powinna pozostać oddzielona od niepopartych twierdzeń o zwycięzcy. Premiera Oracle poszerza wachlarz dostępnych opcji. Strategia Google dotycząca CPU i akceleratorów dostarcza istotnego kontekstu. Żadne z ogłoszeń nie przesądza, która platforma zapewnia najlepszy wynik dla każdego obciążenia agentowego.

Szersza zmiana dotyczy tego, co dostawcy proszą klientów, by oceniali. Specyfikacje akceleratorów pozostają istotne, lecz wspierające środowisko wykonawcze coraz częściej staje się częścią tej samej rozmowy. Dostawcy infrastruktury muszą wyjaśniać, jak ich komponenty współpracują podczas realizacji zadania.

Dla czytelników śledzących NVIDIA Vera Rubin na OCI jest to najbardziej użyteczna rama konkurencyjna. Nagłówek dotyczy większych zobowiązań infrastrukturalnych. Decyzja zakupowa dotyczy tego, czy konkretne połączenie usług może skuteczniej wspierać aplikację niż jej obecna konfiguracja.

Dostępność i liczba procesorów pozostawiają istotne pytania otwarte

Ogłoszenie ustanawia produkty i plany, ale nie potwierdza uniwersalnego wzrostu produktywności klientów.

Pierwsza niepewność dotyczy związku między ogólną dostępnością a praktycznym dostępem. Publiczna premiera nie określa przydziału każdego klienta, lokalizacji wdrożenia ani harmonogramu dostaw. Kupujący potrzebują tych szczegółów, zanim przełożą ogłoszenie na plan wdrożenia.

Druga dotyczy planowanej wielogigawatowej skali. Ogłoszenie opisuje rozbudowę, ale sam nagłówek nie przedstawia kompletnego harmonogramu realizacji. Czytelnicy powinni odróżniać zamierzoną skalę od działającej pojemności w miarę pojawiania się dalszych informacji.

Trzecia dotyczy wyników aplikacji. Duże wdrożenie CPU i nowa generacja GPU same w sobie nie określają, o ile szybciej agent realizuje użyteczną pracę. Wymaga to zdefiniowanego obciążenia i porównania z jasnym punktem odniesienia.

Publikacja Oracle zawiera twierdzenia dotyczące wydajności, lecz pozostają one deklaracjami firmy, o ile nie są poparte niezależnie możliwą do oceny metodologią. Kupujący powinni zbadać konfigurację, oprogramowanie, obciążenie i granice pomiaru stojące za każdą reklamowaną poprawą.

Granica ta jest szczególnie ważna w przypadku agentów. Pomiar szybkości wykonania procesora różni się od pomiaru kompletnego zadania, które obejmuje wywołania modeli i usługi zewnętrzne. Poprawa na jednym etapie nie potwierdza takiej samej poprawy w całym przepływie pracy.

Istnieje też rozróżnienie między wykorzystaniem zasobów a wartością dla klienta. Zajęty procesor może realizować produktywną pracę, ponowne próby lub zbędne obliczenia. Wysoka aktywność staje się istotna tylko wtedy, gdy przyczynia się do zaakceptowanych rezultatów.

Z kolei część niewykorzystanej pojemności służy celom operacyjnym. Aplikacje mogą utrzymywać zapas na skoki obciążenia, awarie lub wymogi czasu odpowiedzi. Ocena powinna odróżniać możliwe do uniknięcia marnotrawstwo od pojemności utrzymywanej w celu spełnienia zobowiązania usługowego.

Niezależne skalowanie przenosi również decyzje na operatora aplikacji. Zespoły muszą ustalić, kiedy dodać pojemność, ile jej utrzymać i jak reagować, gdy zależności zawodzą. Elastyczność jest wartościowa, ale wprowadza wybory wymagające pomiarów i osądu operacyjnego.

Bezpieczeństwo dodaje kolejny wymiar. Agenci wykonujący wygenerowany kod potrzebują kontroli nad swoim środowiskiem i dostępem. Sandbox, izolowane środowisko wykonawcze, ogranicza zakres zasobów dostępnych dla tego kodu, lecz jego skuteczność zależy od otaczającej implementacji.

Klienci powinni oceniać uprawnienia wykonawcze, obsługę danych i ograniczanie skutków awarii wraz z przepustowością. Szybszy worker z nieodpowiednim dostępem nie tworzy lepszego systemu produkcyjnego. Ma to szczególne znaczenie, gdy agent pobiera zastrzeżone informacje lub działa za pośrednictwem połączonych narzędzi przedsiębiorstwa.

Migracja stanowi odrębne pytanie. Przeniesienie aplikacji do innego środowiska CPU wymaga sprawdzenia zależności programowych i zgodności wdrożeniowej. Wymagany wysiłek zależy od aplikacji, dlatego szerokie ogłoszenie premiery nie może rozstrzygnąć tej kwestii dla każdego klienta.

Te niepewności nie podważają premiery. Wskazują dowody potrzebne do jej trafnej oceny. Firmy ogłosiły opcję infrastrukturalną z jasnym uzasadnieniem architektonicznym; wynikające z niej korzyści operacyjne pozostają zależne od obciążenia.

Ostrożna interpretacja jest zatem konkretna. Niezależne zasoby CPU i GPU dają klientom kolejną możliwość radzenia sobie z niedopasowanym popytem. To, czy opcja ta ogranicza marnotrawstwo lub poprawia szybkość reakcji, musi zostać potwierdzone wynikami na poziomie aplikacji.

Obserwuj dostęp do pojemności, pomiary klientów i oprogramowanie wykonawcze

Kolejne dowody powinny połączyć ogłoszoną infrastrukturę z osiągalną pojemnością i ukończonymi obciążeniami klientów.

Pierwszym sygnałem są bardziej szczegółowe informacje o dostępie. W nadchodzących miesiącach klienci powinni obserwować obsługiwane konfiguracje, lokalizacje wdrożeń, warunki przydziału i kamienie milowe rozbudowy. Szczegóły te wyjaśnią, jak ogłoszone produkty przekładają się na praktyczną pojemność.

Bardziej konkretne informacje o dostawach wzmocniłyby argument, że rozbudowa wspiera krótkoterminowe planowanie klientów. Dalszy nacisk na łączną skalę, bez odpowiadających mu szczegółów dostępu, pozostawiłby tę część historii mniej rozstrzygniętą.

Ten sygnał ma odrębne znaczenie dla systemów GPU i samodzielnych CPU. Klienci wdrażający jedno rozwiązanie niekoniecznie mają takie same wymagania lub harmonogramy jak klienci wdrażający drugie. Oddzielne informacje o dostępności ułatwiłyby ocenę propozycji niezależnego skalowania.

Drugim sygnałem są pomiary klientów obejmujące kompletne przepływy pracy. Użyteczne dowody opisywałyby aplikację, jej wcześniejszą konfigurację, zmienione zasoby i kryteria akceptacji. Wyjaśniałyby również, co stało się z realizacją zadań i zużyciem zasobów.

Ocena agenta programistycznego powinna na przykład obejmować wykonywanie i testowanie, zamiast kończyć się na generowaniu przez model. Aplikacja do wyszukiwania informacji powinna uwzględniać dostęp do podstawowych danych. Porównanie staje się bardziej przekonujące, gdy śledzi zadanie użytkownika przez te granice.

Dowody, że dodatkowa pojemność Vera usuwa zmierzone ograniczenie wykonawcze, potwierdziłyby główny argument premiery. Wyniki pokazujące, że większość opóźnień występuje gdzie indziej, zawęziłyby istotne przypadki użycia. Każdy z tych rezultatów pomógłby kupującym podejmować lepiej poinformowane decyzje.

Trzecim sygnałem jest oprogramowanie produkcyjne, które ułatwia obsługę oddzielnych pul zasobów. Obserwuj, jak aplikacje obsługują przydział workerów, dostęp do danych, stan wykonania i awarie. Te możliwości określają, czy niezależne zasoby funkcjonują jako skoordynowana usługa.

Sygnał ten zasługuje na uwagę, ponieważ opcja sprzętowa nie tworzy automatycznie użytecznej architektury aplikacyjnej. Operatorzy potrzebują wystarczającej widoczności, aby rozumieć, gdzie praca oczekuje, oraz wystarczającej kontroli, aby reagować. Lepsza koordynacja wzmocniłaby argument dotyczący efektywności bez wymogu równej poprawy każdego komponentu.

Razem te sygnały zapewniają ugruntowany sposób śledzenia NVIDIA Vera Rubin na OCI. Ujawnienia dotyczące pojemności odnoszą się do dostaw. Pomiary klientów dotyczą wartości. Oprogramowanie wykonawcze dotyczy praktycznej pracy polegającej na łączeniu dostępnych komponentów.

Dla deweloperów ogłoszenie jest powodem, by zbadać, gdzie ich własne przepływy pracy agentów spędzają czas. Dla kupujących w przedsiębiorstwach jest powodem, by zażądać dowodów na poziomie aplikacji. Dla użytkowników istotnym rezultatem pozostaje usługa, która niezawodnie wykonuje użyteczną pracę.

Przed zobowiązaniem się do nowej konfiguracji infrastruktury prześledź reprezentatywne zadanie przez cały system i zidentyfikuj jego rzeczywiste ograniczenie. Poproś dostawcę o rozróżnienie między dostępną pojemnością a planowaną rozbudową oraz między deklaracjami dotyczącymi komponentów a zmierzonymi wynikami aplikacji. Uwzględnij w ocenie wykonywanie, wyszukiwanie, awarie i odzyskiwanie działania. Zachowaj spójność obciążenia i kryteriów akceptacji przy porównywaniu alternatyw. Takie podejście zapewnia uczciwą ocenę NVIDIA Vera Rubin na OCI, jednocześnie wiążąc decyzję zakupową z pracą, którą klienci muszą wykonać. Który etap Twojej aplikacji poprawiłaby dodatkowa pojemność CPU lub GPU i jaki pomiar wykazałby tę poprawę?