NVIDIA cuObject Otwiera AI storage poza plikami, ale interoperacyjność nadal jest niedopracowana

30 września NVIDIA udostępniła biblioteki klienckie i serwerowe cuObject w wersji ogólnie dostępnej, rozszerzając przyspieszony dostęp do danych dla AI poza konwencjonalne systemy plików. Wydanie NVIDIA cuObject dodaje ustandaryzowane API oraz protokół RDMA do przesyłania danych obiektowych bez kierowania danych właściwych przez CPU serwera.

Firma zaprezentowała także SCADA Server SDK do obsługi żądań storage’u inicjowanych przez GPU. SCADA oznacza Scaled Accelerated Data Access — framework zaprojektowany dla dużych wolumenów precyzyjnych operacji storage’owych. IBM zbudował już wczesny prototyp Storage Scale z użyciem SDK.

Zapowiedź dotyczy trwałego podziału w infrastrukturze AI. Storage obiektowy oferuje pojemność i znane interfejsy zgodne z S3, podczas gdy wysokowydajne procesy trenowania i inferencji często opierają się na szybszych systemach plików lub lokalnym scratch storage. NVIDIA chce zmniejszyć tę lukę za pomocą cuObject, lecz jej szerszy plan interoperacyjności pozostaje niedokończony.

NVIDIA cuObject Przechodzi Od Biblioteki Produktowej do Propozycji Branżowej

Istotna zmiana nie polega wyłącznie na wydaniu przez NVIDIA kolejnej biblioteki storage’owej. Firma zachęca dostawców chmury i storage’u do zbieżności wokół wspólnego, przyspieszonego protokołu obiektowego.

Według zapowiedzi NVIDIA, zarówno biblioteki klienckie, jak i serwerowe cuObject są obecnie ogólnie dostępne. NVIDIA wydała również cuObject Server 2.0.0 dla dostawców storage’u oceniających integrację po stronie serwera.

Biblioteka kliencka działa wewnątrz aplikacji GPU, data loadera lub warstwy middleware. Łączy operacje na obiektach na poziomie aplikacji ze ścieżką danych RDMA. Remote direct memory access, czyli RDMA, umożliwia sprzętowi sieciowemu bezpośrednie przesyłanie danych między zarejestrowanymi regionami pamięci.

Biblioteka serwerowa integruje się z usługą storage’u obiektowego. Zarządza zarejestrowanymi buforami i wykonuje operacje RDMA, które przesyłają dane do lub od klienta. System może wykorzystywać pamięć GPU albo pamięć systemową.

Projekt ten rozwiązuje problem, którego GPUDirect Storage nie wyeliminował w pełni. GPUDirect Storage zapewniał już bezpośrednią ścieżkę między storage’em a pamięcią GPU, lecz jego najlepiej znany interfejs, cuFile, koncentrował się na dostępie do plików. Wiele zbiorów danych AI znajduje się natomiast za interfejsami obiektowymi.

Różnica ma znaczenie dla organizacji przechowujących próbki treningowe, dokumenty, obrazy, checkpointy i wygenerowane artefakty w repozytoriach zgodnych z S3. Systemy te są atrakcyjne, ponieważ skalują się w dużych przestrzeniach nazw i oddzielają storage od obliczeń. Konwencjonalny dostęp do obiektów zwykle przebiega jednak przez stos TCP i bufory zarządzane przez CPU.

NVIDIA cuObject zachowuje operacje kontrolne zorientowane na obiekty, zmieniając jednocześnie ścieżkę danych właściwych. Klient nadal może wysyłać znane żądania GET lub PUT przez dostosowany zestaw SDK S3. Dane obiektowe mogą następnie być przesyłane przez RDMA zamiast zwykłą ścieżką danych TCP.

Ogólna dostępność zapewnia deweloperom wspierany punkt wyjścia, ale NVIDIA realizuje szerszy cel za pośrednictwem xio-sig. Grupa rozszerza zakres z dostępu do plików na dostęp do obiektów, planując osobne prace dotyczące API klienta, protokołu transmisji i testów zgodności.

Google Cloud ocenia rozszerzone uczestnictwo wokół cuObject. Microsoft również poinformował, że planuje dołączyć do zarządu xio-sig. Prototyp SCADA IBM dodaje dostawcę storage’u do wczesnej grupy, choć prototyp nie jest równoznaczny ze wsparciem produkcyjnym.

To rozróżnienie jest kluczowe dla tej historii. NVIDIA ma już komponenty dostępne do pobrania, dokumentację i partnerów rozmawiających o interoperacyjności. Nie ma jeszcze dojrzałego, wielodostawcowego standardu storage’u obiektowego z kilkoma sprawdzonymi wdrożeniami produkcyjnymi.

Czyni to wydanie jednocześnie konkretnym i tymczasowym. Deweloperzy mogą już rozpocząć ocenę bibliotek. Szersza obietnica zależy od tego, czy platformy chmurowe, dostawcy storage’u, frameworki i twórcy aplikacji przyjmą te same interfejsy.

Jak NVIDIA cuObject Rozdziela Kontrolę Od Danych

NVIDIA cuObject utrzymuje komunikaty kontrolne w stylu S3 na znanej ścieżce, podczas gdy dane obiektowe przesyła przez RDMA.

Architektura cuObject dzieli każdą operację na płaszczyznę kontroli i płaszczyznę danych. Standardowe żądania S3 GET i PUT pozostają częścią przepływu sterowania. Dostosowane SDK S3 dodaje metadane opisujące transfer RDMA.

Dane obiektowe podążają inną trasą. Klient rejestruje region pamięci i tworzy token RDMA zawierający informacje niezbędne do transferu. Token jest dołączany do żądania HTTP za pomocą niestandardowego nagłówka.

Brama storage’u analizuje żądanie i kieruje odpowiedni węzeł danych do wykonania operacji. Węzeł rejestruje swój lokalny bufor przez API serwera cuObject. Następnie przesyła lub pobiera dane właściwe za pomocą zapisu albo odczytu RDMA.

Pomyślna odpowiedź bramy kończy transakcję kontrolną po zakończeniu operacji RDMA. Taki podział pozwala aplikacji zachować semantykę obiektową, jednocześnie usuwając CPU serwera z głównej ścieżki danych właściwych.

Podejście to jest ukierunkowane na coś więcej niż surową przepustowość. Przetwarzanie CPU może stać się ograniczeniem, gdy wiele akceleratorów generuje równoczesne operacje storage’owe. Unikanie przetwarzania TCP dla każdego payloadu może zachować zasoby CPU dla metadanych, koordynacji, bezpieczeństwa i innych usług.

Obecna implementacja wykorzystuje transport Dynamically Connected, powszechnie nazywany DC. DC eliminuje konieczność utrzymywania niezawodnego połączenia między każdą parą klienta i serwera storage’u. Ta cecha jest przydatna, gdy duży klaster obliczeniowy komunikuje się z wieloma węzłami storage’u.

NVIDIA dokumentuje wsparcie DC dla InfiniBand i RoCEv2. RoCEv2 przesyła ruch RDMA przez sieci Ethernet skonfigurowane do obsługi wymaganego zachowania. Obie opcje wymagają planowania infrastruktury wykraczającego poza instalację biblioteki.

Klient nie współpracuje też z niezmienionym endpointem S3. Dokumentacja NVIDIA wskazuje, że integracja wymaga modyfikacji SDK S3 po stronie klienta oraz oprogramowania storage’owego po stronie serwera. Zmiany te tworzą przyspieszoną ścieżkę i wymieniają metadane RDMA.

Obsługiwane operacje obejmują GET, PUT, operacje multipart upload oraz odczyty zakresów bajtów. Dostęp zakresowy ma znaczenie, gdy aplikacja potrzebuje tylko części dużego obiektu, zamiast przesyłać cały obiekt do pamięci GPU.

Ta architektura może usunąć powszechny etap stagingu. Tradycyjne procesy AI często kopiują dane z repozytorium obiektowego do lokalnego lub rozproszonego scratch file system. Węzły obliczeniowe odczytują następnie dane z tej warstwy pośredniej.

Staging może zapewniać przewidywalną wydajność, ale zużywa pojemność i zwiększa nakład pracy operacyjnej. Zespoły muszą harmonogramować kopie, monitorować synchronizację, usuwać nieaktualne dane i określać, które zbiory zasługują na szybki storage.

NVIDIA cuObject proponuje bardziej bezpośrednią ścieżkę od storage’u obiektowego do pamięci akceleratora. Przy wsparciu od końca do końca aplikacja może odczytywać dane z głównego repozytorium obiektowego bez uprzedniego tworzenia kolejnej pełnej kopii.

Ta korzyść nie eliminuje każdej operacji pośredniej. Dane mogą nadal wymagać dekodowania, dekompresji, walidacji, batchowania lub transformacji. Oprogramowanie storage’owe może także korzystać z wewnętrznych buforów przed dostarczeniem danych przez RDMA.

Wydanie zmienia zatem możliwości transportu, a nie cały pipeline danych. Aplikacje nadal muszą zarządzać formatami, uprawnieniami dostępu, metadanymi obiektów i odzyskiwaniem po awariach. Dostawcy storage’u muszą połączyć przyspieszoną ścieżkę z własnymi systemami rozmieszczania danych i zapewniania trwałości.

NVIDIA cuObject działa najlepiej jako warstwa integracyjna między tymi komponentami. Nie zastępuje object store, płaszczyzny kontroli S3, data loadera ani infrastruktury sieciowej.

SCADA Server SDK Przesuwa Kontrolę Żądań w Kierunku GPU

SCADA Server SDK rozwiązuje inne wąskie gardło: wiele małych żądań, których koordynacja może przeciążyć CPU, zanim storage osiągnie swoje limity.

Przy dużych transferach sekwencyjnych przepustowość jest oczywistą miarą. Zadania treningowe odczytujące duże próbki lub checkpointy mogą rozłożyć narzut żądań na każdy transfer. Praca kontrolna staje się mniejszą częścią całej operacji.

Systemy inferencji i retrieval tworzą inny wzorzec. Wyszukiwanie semantyczne, rekomendacje, wykrywanie oszustw i pamięć agentów mogą generować wiele mniejszych odwołań. GPU może mieć wystarczająco dużo równoległej pracy, aby wykonywać te operacje z wysoką współbieżnością.

Konwencjonalne oprogramowanie storage’owe oczekuje, że CPU skonstruuje, wyśle i zakończy te żądania. Taki projekt staje się mniej efektywny, gdy rozmiary żądań maleją, a liczba operacji rośnie. Stałe koszty przetwarzania pochłaniają większą część każdej transakcji.

SCADA pozwala klientom opartym na GPU inicjować żądania storage’u przez wspólny interfejs. Nowe SDK daje zewnętrznym dostawcom storage’u sposób na budowanie serwerów odbierających te żądania. Serwer może realizować je z lokalnego lub zdalnego storage’u, zanim zwróci dane przez RDMA.

SDK nie wymaga, by każdy system storage’owy bezpośrednio ujawniał GPU swoją wewnętrzną architekturę. Zamiast tego serwer SCADA pełni funkcję mostu między wspólnym interfejsem klienta a specyficzną dla dostawcy logiką storage’u.

IBM zademonstrował początkowy serwer oparty na SDK dla IBM Storage Scale. W tym prototypie klient SCADA wysyła żądania do serwera zbudowanego przez IBM. Serwer łączy wspólny model żądań ze Storage Scale.

To wczesny sygnał interoperacyjności, ale jego zakres pozostaje ograniczony. NVIDIA nie opublikowała niezależnych wyników produkcyjnych dla prototypu IBM. Zapowiedź nie zawiera również porównawczych pomiarów opóźnień, przepustowości ani wykorzystania CPU.

SCADA obejmuje prace wspierające wykraczające poza SDK serwera. NVIDIA opublikowała Storage Lender Service do zapewniania dostępu do kolejek NVMe. Narzędzie wiersza poleceń ma również pomóc w konfigurowaniu i wdrażaniu komponentów SCADA.

Inicjatywa Storage-Next zapewnia szerszy kontekst branżowy. NVIDIA twierdzi, że grupa obejmuje ponad 40 dostawców i klientów z obszarów flash, kontrolerów, systemów storage’owych, infrastruktury chmurowej i tworzenia aplikacji.

Grupa próbuje zdefiniować, jak powinien działać storage sterowany przez GPU. Jej prace dotyczą zarówno dużych transferów danych, jak i niewielkich, precyzyjnych operacji. Celem jest przekształcenie współpracy dostawców w interoperacyjne interfejsy i standardy.

Termin odzwierciedla zmieniające się wzorce dostępu do danych AI. Trenowanie nadal jest istotne, lecz inferencja produkcyjna wprowadza pobieranie kontekstu, wywołania narzędzi, wyszukiwania w bazach danych i trwałą pamięć. Każde żądanie użytkownika może uruchamiać kilka dalszych operacji na danych.

Usługa obsługująca długi kontekst wywiera również presję poza pamięcią GPU. Dane key-value cache rejestrują stan uwagi z wcześniej przetworzonych tokenów. Gdy stan ten nie może pozostać w pamięci akceleratora, systemy potrzebują innej warstwy, która potrafi go sprawnie zwrócić.

Storage jest tańszy i pojemniejszy niż pamięć akceleratora, ale ma inną charakterystykę opóźnień. SCADA próbuje umożliwić GPU tolerowanie tej różnicy dzięki równoległości. Wiele wątków GPU może utrzymywać operacje w toku, zamiast czekać na sekwencję żądań sterowaną przez CPU.

Koncepcja ta uzupełnia cuObject, a nie go zastępuje. NVIDIA cuObject koncentruje się na przyspieszonym dostępie do storage’u obiektowego zgodnego z S3. SCADA koncentruje się na precyzyjnym dostępie inicjowanym przez GPU w różnych implementacjach storage’u.

Razem rozszerzają wpływ NVIDIA z obliczeń na protokoły łączące akceleratory z przechowywanymi danymi. To rozszerzenie tworzy główną presję konkurencyjną stojącą za ogłoszeniem.

Otwarte interfejsy konkurują z przyspieszeniem specyficznym dla dostawcy

Główna rywalizacja toczy się między współdzielonymi interfejsami akceleratorów i pamięci masowej a odrębnymi integracjami tworzonymi dla każdego dostawcy chmury lub pamięci masowej.

Magazynowanie obiektowe przez RDMA nie miało dotąd powszechnie przyjętego wspólnego protokołu komunikacyjnego. Programista szukający bezpośredniego dostępu GPU mógł polegać na tradycyjnych transferach S3, korzystać z pośredniego systemu plików albo budować rozwiązanie wokół przyspieszonej ścieżki konkretnego dostawcy.

Każda opcja wiąże się z innym kosztem. Tradycyjny dostęp zachowuje kompatybilność, lecz utrzymuje narzut CPU i TCP. Etapowanie może poprawić lokalność, jednocześnie powielając dane. Integracja specyficzna dla dostawcy może działać dobrze, ale tworzy kolejną zależność.

NVIDIA chce, aby xio-sig ograniczył tę fragmentację. Organizacja xio-sig opisuje odrębne działania dotyczące cuObject: API klienta, przyspieszony protokół komunikacyjny oraz pakiet testów zgodności. Ta sama organizacja obejmuje także powiązane prace nad cuFile.

Zgodność jest kluczowa, ponieważ opublikowanie interfejsu nie gwarantuje zgodnego działania. Implementacje muszą uzgadniać semantykę żądań, rejestrację pamięci, obsługę błędów, granice bezpieczeństwa i zachowanie awaryjne. Muszą też działać spójnie w warunkach awarii i współbieżności.

W momencie publikacji publiczna organizacja informuje, że kod pojawi się po zintegrowaniu i zweryfikowaniu warstw przez uczestników założycielskich. Jej strona statusu podaje również, że stosy muszą przejść testy zgodności przed publikacją.

Pozostawia to istotną lukę między ogłoszeniem NVIDIA a gotową warstwą interoperacyjności. Struktura repozytoriów istnieje, a zamierzone komponenty zostały nazwane. Znaczna część implementacji gotowej do użycia produkcyjnego nadal czeka na publiczne wydanie.

Google Cloud i Microsoft wnoszą ważną wiarygodność, ponieważ dostawcy chmurowi obsługują duże platformy magazynowania obiektowego. Ich udział sprawdza także, czy xio-sig może obsłużyć infrastrukturę niekontrolowaną przez NVIDIA.

Partnerzy podjęli jednak różne zobowiązania. Google Cloud ocenia szerszy udział w cuObject. Microsoft wskazał zamiar dołączenia do rady. Żadne z tych stwierdzeń samo w sobie nie potwierdza powszechnej dostępności dla klientów w ich usługach obiektowych.

Prototyp IBM stanowi bardziej namacalną implementację, lecz dotyczy SCADA i Storage Scale. Nie dowodzi, że kilka niezależnych platform zgodnych z S3 może wymieniać ruch cuObject za pośrednictwem jednego, sprawdzonego produkcyjnie protokołu.

Firmy z branży pamięci masowej również mają powody, by zachowywać własne metody przyspieszenia. Ścieżki specyficzne dla dostawcy mogą udostępniać zróżnicowane mechanizmy buforowania, rozmieszczania danych, bezpieczeństwa lub usługi danych. Wspólny protokół musi pozostać wystarczająco szeroki dla interoperacyjności, nie eliminując tych funkcji.

NVIDIA ma własny interes strategiczny. Wspólna ścieżka z pamięci masowej do pamięci GPU może ułatwić używanie akceleratorów NVIDIA z większymi zbiorami danych. Może też włączyć produkty sieciowe, DPU, oprogramowanie CUDA i partnerów pamięci masowej do skoordynowanej architektury.

Nie czyni to dążenia do interoperacyjności z natury zamkniętym. Opublikowana organizacja używa licencji Apache-2.0 dla obecnego repozytorium, a prace nad zgodnością mogą obniżyć ryzyko integracji. O tym, jak otwarty stanie się rezultat, zdecydują jednak szczegóły zarządzania i implementacji.

Inni dostawcy akceleratorów stanowią kolejny test. W swoim wpisie NVIDIA odnosi się do GPU, TPU i XPU, opisując zapotrzebowanie na moc obliczeniową. Naprawdę przenośny interfejs pamięci masowej nie powinien zależeć od jednej architektury akceleratora na każdej warstwie.

Najbardziej jednoznacznym dowodem będą implementacje inne niż NVIDIA, przechodzące wspólne testy. Znaczenie miałoby także wsparcie w popularnych frameworkach. Programistów mniej interesuje członkostwo organizacyjne niż to, czy istniejąca aplikacja może zmienić backend bez przepisywania.

Dla nabywców pamięci masowej praktycznym pytaniem jest przenośność. Interfejs ma wartość, gdy zachowuje zachowanie aplikacji w kilku obsługiwanych produktach. Jedna szybka ścieżka powiązana z jedną zweryfikowaną kombinacją pozostaje integracją, a nie standardem branżowym.

Ogólna dostępność nie eliminuje ryzyka wdrożeniowego

Biblioteki są dostępne, ale wdrożenie produkcyjne nadal wymaga wyspecjalizowanych sieci, zmodyfikowanego oprogramowania, ostrożnego zarządzania pamięcią i wiarygodnych benchmarków.

Informacje o wydaniach cuObject pokazują, że klient osiągnął wersję 1.3.0 w sierpniu 2026 roku. Wcześniejsze wydania dodały przełączanie awaryjne wielościeżkowe, powrót do pierwotnej ścieżki i obsługę IPv6. Wersja 1.3.0 dodała metodę unieważniania nieaktualnych tokenów RDMA.

Te dodatki odpowiadają na kwestie operacyjne, lecz ta sama dokumentacja wymienia istotne ograniczenia. Pojedyncze wywołanie rejestracji pamięci ma maksymalny rozmiar poniżej 4 GiB. Jednoczesne operacje GET i PUT nie są obsługiwane na tym samym zarejestrowanym buforze.

Transfery do pamięci hosta wymagają zarejestrowanych buforów. Część zachowań konfiguracji różni się od cuFile, w tym brak puli wątków do wykonywania operacji wejścia-wyjścia cuObject. Aplikacje muszą rozumieć te ograniczenia przed wdrożeniem tej ścieżki.

Cykle życia pamięci wymagają szczególnej ostrożności. Klient nie może ponownie użyć ani wyrejestrować bufora, gdy operacja pozostaje w toku. Obsługa błędów musi także zapobiegać dostępowi nieaktualnych żądań do obszaru pamięci po ponownym użyciu jego klucza.

Wymagania te nie są nietypowe dla wysokowydajnego oprogramowania RDMA. Mimo to przenoszą odpowiedzialność na twórców aplikacji, frameworków i rozwiązań pamięci masowej. Nieprawidłowa integracja może powodować trudne do zdiagnozowania awarie.

Znaczenie ma także sieć. Transport DC przez InfiniBand lub RoCEv2 zakłada odpowiednie adaptery, przełączniki, routing i konfigurację. Organizacje nie mogą oczekiwać, że przyspieszona ścieżka pojawi się w zwykłej sieci bez prac infrastrukturalnych.

Wdrożenia RoCE mogą być wrażliwe na przeciążenia i projekt struktury sieciowej. Zachowanie wielościeżkowe, odzyskiwanie po awariach i telemetria muszą zostać przetestowane przy realistycznym ruchu. Udany transfer laboratoryjny nie potwierdza przewidywalnej wydajności w całym klastrze.

Bezpieczeństwo zasługuje na równie dużą uwagę. Bezpośredni przepływ danych ogranicza udział CPU w ścieżce ładunku, lecz nie może omijać autoryzacji. Systemy nadal potrzebują zaufanej warstwy kontrolnej, która decyduje, który proces może uzyskać dostęp do każdego zarejestrowanego obszaru i przechowywanego obiektu.

NVIDIA opisuje SCADA jako rozdzielenie nieuprzywilejowanych działań aplikacji od uprzywilejowanego komponentu konfiguracji. Taka struktura może chronić ścieżkę danych, jeśli zostanie wdrożona prawidłowo. Dostawcy pamięci masowej muszą jednak nadal połączyć ją z izolacją dzierżawców, audytem, zarządzaniem poświadczeniami i unieważnianiem dostępu.

Ogłoszenie nie zawiera ustandaryzowanego benchmarku porównującego cuObject z konwencjonalnym S3, etapowym dostępem do plików lub alternatywami specyficznymi dla dostawcy. Nie określa też ilościowo korzyści z prototypu IBM.

To pominięcie uniemożliwia szerokie wnioski dotyczące wydajności. RDMA może ograniczyć kopiowanie i przetwarzanie przez CPU, ale rezultaty dla aplikacji zależą od rozmiarów obiektów, wzorców dostępu, nośników pamięci masowej, topologii sieci, współbieżności i przetwarzania wstępnego.

Duże odczyty sekwencyjne mogą już działać wystarczająco dobrze dzięki zoptymalizowanym systemom plików. Bardzo małe żądania mogą ujawnić ograniczenia w innych miejscach, w tym w warstwach translacji flash, usługach metadanych lub synchronizacji aplikacji.

Niezależna analiza pamięci masowej dotycząca SCADA podkreśla to rozróżnienie. Transfery masowe i odczyty o drobnej granularności stawiają różne wymagania, dlatego żadna pojedyncza wartość przepustowości nie może opisać obu przypadków.

Programiści powinni zatem traktować NVIDIA cuObject jako ścieżkę wartą oceny, a nie gwarantowany wynik wydajnościowy. Testy powinny wykorzystywać rzeczywiste rozmiary obiektów, reprezentatywną współbieżność, istniejące transformacje i oczekiwane scenariusze awarii.

Wiarygodny proof of concept powinien mierzyć więcej niż przepustowość. Powinien śledzić opóźnienia ogonowe, zużycie CPU serwera, wykorzystanie GPU, narzut rejestracji pamięci, czas odzyskiwania oraz zachowanie, gdy ścieżka RDMA staje się niedostępna.

Zespoły powinny również sprawdzić zachowanie awaryjne. Aplikacja produkcyjna potrzebuje zdefiniowanej reakcji, gdy serwer nie obsługuje RDMA albo komponent sieciowy ulegnie awarii. Kompatybilność ze zwykłym dostępem do obiektów może być równie ważna jak maksymalna wydajność przyspieszonej ścieżki.

Najsilniejszy sceptycyzm dotyczy wdrożenia, a nie technicznej możliwości. NVIDIA pokazała, że komponenty można zbudować. Nie wykazała jeszcze, że szerokie grono dostawców będzie utrzymywać zgodne implementacje przez kilka cykli wydawniczych.

Co obserwować po wydaniu NVIDIA SCADA Server SDK

Trzy sygnały pokażą, czy NVIDIA cuObject stanie się współdzieloną infrastrukturą, czy pozostanie zestawem zoptymalizowanych integracji partnerskich.

Pierwszym sygnałem będzie publiczny kod xio-sig wraz z działającymi testami zgodności. Organizacja wskazała repozytoria dla API klienta cuObject, protokołu komunikacyjnego i pakietu zgodności. Repozytoria te potrzebują istotnych implementacji, a nie tylko opisów interfejsów.

Pozytywne wyniki testów dla niezależnie utrzymywanych klientów i serwerów wzmocniłyby twierdzenie NVIDIA o interoperacyjności. Opóźnienia, wąski zakres testów lub zależności od jednej kombinacji sprzętowej osłabiłyby je.

Drugim sygnałem będzie wsparcie produkcyjne od dostawców chmury i pamięci masowej. Ocena Google Cloud oraz planowany udział Microsoft w radzie są istotne, lecz większe znaczenie miałaby dostępność skierowana do klientów.

Nabywcy powinni szukać obsługiwanych kombinacji usług, udokumentowanych wymagań wdrożeniowych oraz jasnych macierzy kompatybilności. Kolejne implementacje serwera SCADA poza IBM Storage Scale sprawdziłyby również, czy SDK uogólnia się na różne projekty pamięci masowej.

Trzecim sygnałem będą dowody specyficzne dla obciążeń. Dostawcy muszą publikować odtwarzalne wyniki dla pobierania danych do trenowania, operacji checkpoint, wyszukiwania, wyszukiwania semantycznego i dostępu do pamięci podręcznej inferencji. Testy te powinny porównywać standardowe transfery obiektów, przepływy pracy z etapowaniem oraz ścieżki obsługujące RDMA.

Wyniki powinny obejmować zużycie CPU i opóźnienia ogonowe, a nie tylko maksymalną przepustowość. Powinny również ujawniać rozmiary obiektów, konfigurację sieci, nośniki pamięci masowej i zachowanie przy awariach. Bez tego kontekstu liczby dotyczące wydajności będą trudne do zastosowania.

Programiści nie muszą czekać, aby zacząć analizować architekturę. Mogą określić, gdzie ich aplikacje etapują dane obiektowe, profilować czas CPU podczas transferów pamięci masowej i mierzyć rozkład rozmiarów żądań. Ta praca pokazuje, czy cuObject lub SCADA rozwiązuje rzeczywiste wąskie gardło.

Ostateczne pytanie nie brzmi, czy RDMA może szybciej przenosić dane. Chodzi o to, czy kilku dostawców może udostępnić jedną niezawodną ścieżkę bez zamykania aplikacji w wąskim stosie. Warto obserwować repozytoria zgodności, obsługiwane produkty dostawców i odtwarzalne testy obciążeń. Te sygnały zdecydują, czy NVIDIA cuObject stanie się przenośną warstwą pamięci masowej dla AI, czy kolejną wyspecjalizowaną opcją przyspieszenia.