Wnioskowanie NVIDIA dla robotów przerosło możliwości robotów
Wnioskowanie NVIDIA dla robotów stoi dziś przed wyraźnym podziałem, mimo że Jetson Thor zapewnia 2 070 teraflopów FP4 przy poborze mocy od 40 do 130 watów. Szybkie sterowanie nadal musi działać na pokładzie. Największe modele rozumowania coraz częściej wymagają jednak procesorów GPU w centrach danych, współdzielonej pamięci i chłodzenia, których mobilny robot nie jest w stanie przenosić.
Ten podział zmienia kluczowe pytanie w robotyce. Problemem nie jest już to, czy wnioskowanie lokalne czy zdalne wygrywa we wszystkich zastosowaniach. Chodzi o to, które decyzje muszą pozostać wewnątrz maszyny, a które mogą przekraczać sieć bez obniżania jej niezawodności.
Analiza wnioskowania dla robotów opublikowana 14 września przez SemiAnalysis przedstawia wyjątkowo konkretny argument ekonomiczny. Zrekonstruowany benchmark sugeruje, że jeden B300 może obsłużyć 12 robotów przy 500-milisekundowym limicie czasowym dla fragmentu działania. Oszczędności te zależą jednak od przetwarzania wsadowego, wykorzystania zasobów, przewidywalnego ruchu i infrastruktury bezprzewodowej, której większość budynków nie posiada.
Boston Dynamics reprezentuje jedną stronę tego podziału. Według opisywanej architektury sterowanie ruchem Atlas działa na Jetson Thor, podczas gdy planowanie wyższego poziomu jest przesyłane przez platformę Orbit do infrastruktury Google. Inni deweloperzy utrzymują lokalnie cały stos od percepcji do działania, akceptując mniejsze modele, aby uniknąć zależności od łączności bezprzewodowej.
Rezultatem nie jest prosty pojedynek edge kontra chmura. To konflikt między skoncentrowaną inteligencją a pewnością operacyjną. Centra danych mogą sprawić, że większe modele staną się ekonomiczne dla całej floty. Robot nadal musi jednak pozostać bezpieczny, gdy połączenie zostanie zakłócone.
Inteligencja robota rozdziela się na dwa systemy
Najważniejsza zmiana ma charakter architektoniczny: rozumowanie robota i jego ruch nie muszą już działać w tym samym miejscu.
Robot ogólnego przeznaczenia wykonuje kilka rodzajów obliczeń z bardzo różną szybkością. Niskopoziomowe pętle bezpieczeństwa i serwomechanizmów szacują stan, utrzymują równowagę i wydają polecenia siłownikom. Takie pętle mogą działać setki razy na sekundę.
Przy częstotliwości 100 herców kolejne wyjście musi nadejść w ciągu 10 milisekund. Nawet zwykły bezprzewodowy przesył danych w obie strony może zużyć całe to okno, zanim rozpocznie się wnioskowanie. Sterowanie niskiego poziomu nie może więc zależeć od zdalnego GPU.
Warstwa działania również podlega rygorystycznym wymaganiom czasowym. Model vision-language-action, czyli VLA, przekształca obrazy i krótkie instrukcje w ruchy fizyczne. Opóźniona odpowiedź językowa jest irytująca, lecz spóźnione polecenie silnika może stać się nieaktualne wraz ze zmianą sytuacji.
Planowanie działa w wolniejszym rytmie. Planer może zinterpretować zlecenie pracy, podzielić je na podzadania i wysłać zwięzłe instrukcje do polityki ruchu. Jeśli działa z częstotliwością pięciu herców, każda decyzja ma 200-milisekundowe okno.
Szerszy budżet czasowy tworzy przestrzeń dla wnioskowania poza robotem. Planer może korzystać z większych modeli, głębszego kontekstu i pamięci klasy centrów danych, podczas gdy lokalna polityka obsługuje natychmiastowy ruch. Robot pozostaje fizycznie responsywny, nawet gdy rozumowanie wyższego poziomu trwa dłużej.
SemiAnalysis podaje, że Boston Dynamics stosuje ten hierarchiczny wzorzec w Atlasie. Warstwa System 1 obsługuje sterowanie wzrokowo-ruchowe na Jetson Thor. System 2 realizuje planowanie zdalnie za pośrednictwem Orbit i infrastruktury Google.
Zlecenie produkcyjne może polecać Atlasowi wykonanie zadania i umieszczenie rezultatu w określonym pojemniku magazynowym. System 2 przekłada to abstrakcyjne żądanie na mniejsze instrukcje, które System 1 może wykonać.
Tłumaczenie to może obejmować wskazówki wizualne. Zdalny planer może wskazać właściwy pojemnik za pomocą znacznika w polu widzenia robota. Lokalny VLA otrzymuje następnie konkretną instrukcję powiązaną z widocznym obiektem.
Według raportu System 2 nadzoruje również wykonanie. Obserwuje postępy i wykrywa sytuacje, w których polityka niższego poziomu działa nieprawidłowo. Taka rola wymaga częstszej komunikacji niż sporadyczne zlecenie zadania.
SemiAnalysis wskazuje, że założenie robocze może obejmować od jednego zapytania co dziesięć sekund do jednego lub dwóch zapytań na sekundę. Taka częstotliwość włącza sieć bezpośrednio do przepływu operacyjnego.
Architektura oferuje praktyczny kompromis. Atlas nie czeka na pojedynczy model łączący zaawansowane rozumowanie z wydajnością systemu wbudowanego. Boston Dynamics może zachować lokalnie deterministyczną pętlę, jednocześnie uzyskując zdalny dostęp do bardziej zaawansowanego planowania.
Kompromis ten ujawnia też główny konflikt artykułu. Każda dodatkowa zdalna decyzja zwiększa inteligencję robota, ale tworzy również kolejny moment, w którym łączność może przerwać użyteczną pracę.
Alternatywą jest pełne wykonywanie lokalne. Firmy rozwijające węższe zastosowania magazynowe, produkcyjne lub domowe mogą trenować mniejsze polityki dla ograniczonego środowiska. Systemy te rezygnują z części uniwersalności, aby usunąć zdalne wnioskowanie ze ścieżki wykonawczej.
Żadne z tych podejść nie eliminuje całkowicie sieci. Roboty z lokalną inteligencją nadal przesyłają dane treningowe, otrzymują aktualizacje oprogramowania, raportują telemetrię floty lub proszą o teleoperację. Różnica polega na tym, czy awaria sieci zatrzymuje bieżące działanie.
To rozróżnienie ma większe znaczenie niż wynik benchmarku. Oddziela robota, który tymczasowo traci usługi floty, od robota, który tymczasowo traci dostęp do części własnego mózgu.
Wnioskowanie NVIDIA dla robotów napotyka ograniczenie pamięci
Jetson Thor podnosi pułap systemów wbudowanych, ale wzrost modeli postępuje szybciej, niż mobilna platforma jest w stanie go wchłonąć.
NVIDIA pozycjonuje Jetson Thor jako wiodącą platformę dla fizycznej AI. Opublikowane specyfikacje Jetson Thor wymieniają 128 GB pamięci, przepustowość pamięci 273 GB na sekundę oraz 2 070 teraflopów FP4.
Moduł może działać przy poborze od 40 do 130 watów. NVIDIA podaje, że zapewnia 7,5 raza wyższą wydajność i 3,5 raza większą efektywność energetyczną niż AGX Orin. Są to porównania firmy, a nie niezależne wyniki wdrożeń.
Dla robota zakres mocy ma duże znaczenie. Mobilna platforma musi podzielić energię z akumulatora między lokomocję, czujniki, siłowniki, komunikację i obliczenia. Sprzęt chłodzący również zużywa przestrzeń i energię.
B300 w centrum danych należy do innej kategorii fizycznej. Został zaprojektowany dla systemów montowanych w szafach rackowych, z pamięcią o dużej pojemności, gęstym zasilaniem i chłodzeniem cieczą. Nie podlega ograniczeniom masy, wibracji ani temperatury, z którymi mierzy się chodząca maszyna.
Różnica nie sprowadza się tylko do surowej wydajności arytmetycznej. Duże modele wielokrotnie przenoszą parametry i dane pośrednie przez pamięć. Pojemność pamięci determinuje, czy model się zmieści, a przepustowość wpływa na szybkość generowania odpowiedzi.
Jetson Thor ma więcej pamięci niż jego poprzednicy. Xavier korzystał z 32 GB, podczas gdy AGX Orin osiągnął 64 GB. Thor podwaja tę wartość do 128 GB.
Modele robotyczne pozostają znacznie mniejsze niż największe modele językowe, lecz rosną. SemiAnalysis przytacza uniwersalne polityki liczące od około trzech do 14 miliardów parametrów. Architektura, precyzja, kontekst i projekt środowiska uruchomieniowego sprawiają, że liczba parametrów jest niedoskonałą miarą porównawczą.
Niektóre obecne systemy już przekroczyły praktyczne możliwości modułu wbudowanego. DreamZero firmy NVIDIA to model działania świata o 14 miliardach parametrów, zbudowany wokół dyfuzji wideo. SemiAnalysis podaje, że działanie w czasie rzeczywistym wymaga dwóch procesorów GB200 poza robotem.
Inny projekt NVIDIA, RoboTTT, wskazuje przeciwny kierunek. Wykorzystuje mniejszą politykę z trenowaniem w czasie testu, które aktualizuje tymczasowe wagi podczas działania. Według doniesień taka konstrukcja zapewnia dłuższy użyteczny kontekst, pozostając wystarczająco małą do wdrożenia na pokładzie.
Te kontrastujące projekty pokazują, dlaczego wnioskowania NVIDIA dla robotów nie można sprowadzić do jednej mapy drogowej. Lepsze układy scalone zachęcają deweloperów do przenoszenia większej części inteligencji lokalnie. Większe modele pochłaniają te zyski i odnawiają argument za przenoszeniem obliczeń na zewnątrz.
Presja dociera również do łańcucha dostaw półprzewodników. Produkty Jetson i akceleratory centrów danych coraz częściej zależą od wiodących węzłów produkcyjnych. Każdy robot z dedykowanymi wysokowydajnymi obliczeniami na stałe przypisuje krzem i pamięć do jednej maszyny.
Współdzielone wnioskowanie w centrum danych zmienia tę alokację. Ten sam akcelerator może obsługiwać wiele robotów, których żądania nadchodzą w różnych momentach. Takie łączenie zasobów staje się szczególnie atrakcyjne, gdy pojedyncze maszyny długo czekają lub poruszają się bez wywoływania największego modelu.
SemiAnalysis szacuje punkt przecięcia efektywności krzemowej na około siedmiu robotów na współdzielony GPU. Według jego szacunku pamięci punkt przecięcia przypada na około pięć robotów na GPU. Liczby te zależą od przyjętego modelu, obciążenia i założeń sprzętowych.
Kierunek ma większe znaczenie niż dokładny punkt przecięcia. Dedykowane obliczenia zapewniają przewidywalną własność zasobów, podczas gdy współdzielone obliczenia wydobywają więcej pracy z kosztownego krzemu. Skala floty wzmacnia tę różnicę.
Sprzęt wbudowany działa również w trudnych warunkach. Wibruje, pochłania wstrząsy, styka się z pyłem, a czasem pracuje w pobliżu cieczy lub przy wahaniach temperatury. Akceleratory centrów danych znajdują się w kontrolowanych szafach rackowych ze specjalistyczną obsługą.
Wymiana elementu na pokładzie wpływa na coś więcej niż budżet obliczeniowy. Serwisowanie modułu może wyłączyć z działania całego robota. Uszkodzony serwerowy GPU można odizolować, podczas gdy inne maszyny nadal korzystają z pozostałej części klastra.
Centrum danych nie eliminuje jednak potrzeby lokalnego sprzętu. Każdy robot wciąż potrzebuje wystarczającej mocy obliczeniowej do percepcji, bezpieczeństwa i zachowania awaryjnego. Przenoszenie obliczeń zmienia docelową pojemność; nie przekształca robota w zdalnie sterowaną powłokę.
Dlatego Jetson Thor i B300 nie są bezpośrednimi substytutami. Thor zapewnia ograniczoną lokalną autonomię w mobilnym budżecie energetycznym. B300 oferuje współdzieloną zdolność rozumowania, gdy pozwalają na to obciążenie i sieć.
Ekonomia B300 zależy od aktywnej floty
Współdzielony B300 staje się atrakcyjny, gdy wiele robotów utrzymuje go w ciągłej pracy, a nie tylko dlatego, że układ jest szybszy.
SemiAnalysis zrekonstruował obciążenie podobne do NVIDIA RoboTTT, ponieważ publicznie nie udostępniono kodu ani wag modelu. Rekonstrukcja odpowiadała profilowi obliczeniowemu i pamięciowemu artykułu, a nie jego dokładności w zadaniach.
To zastrzeżenie jest kluczowe. Benchmark mierzy koszt obsługi reprezentatywnego obciążenia. Nie potwierdza, że zrekonstruowany system wykonuje zadania robotyczne równie dobrze jak nieopublikowany model.
Test umieścił 16 modułów trenowania w czasie testu w 32 blokach głowicy działania. Każdy robot przechowywał również 151 MB tymczasowego stanu szybkich wag. Serwer musiał gromadzić i ponownie rozdzielać ten stan wokół wywołań wsadowych.
W tych warunkach jeden B300 miał rzekomo obsłużyć 12 robotów w ramach 500-milisekundowego terminu dla fragmentu działania. RTX 6000 Pro Server Edition obsłużył cztery. W porównaniu zastosowano kryterium opóźnienia wysokiego percentyla, w którym wolne odpowiedzi mają większe znaczenie niż średnia.
SemiAnalysis następnie zamodelował trzy wdrożenia obsługujące 96 robotów. Pierwsze umieszczało pojemność B300 w centrum danych, drugie korzystało z serwerów RTX, a trzecie instalowało sprzęt Jetson Thor w każdym robocie.
Przed korektą o wykorzystanie Jetson Thor pozostawał konkurencyjny. Analiza obliczyła niemal podobny godzinowy koszt na jednostkę gęstych obliczeń FP4 dla Thor i B300. Sprzęt RTX wypadał mniej korzystnie przy tym konkretnym obciążeniu.
Wykorzystanie zmieniło rezultat. Serwer może łączyć popyt w całej flocie i przetwarzać pracę różnych robotów przez cały dzień. Moduł pokładowy pozostaje przypisany do jednej maszyny, nawet gdy robot się ładuje, czeka lub wykonuje lekkie zadanie.
Model zakładał około 90-procentowe wykorzystanie B300 i około 40-procentowe wykorzystanie modułów Thor na pokładzie. Po tej korekcie koszt B300 na jednostkę gęstych obliczeń FP4 spadł do około 46 procent wartości dla Thor.
Wdrożenia domowe pogłębiły modelowaną różnicę. SemiAnalysis podaje, że roboty domowe wdrożone przez jedną firmę pracują obecnie tylko jedną lub dwie godziny dziennie. Odpowiada to mniej więcej czterem do ośmiu procentom doby.
Firma podobno oczekuje, że wraz z poprawą możliwości wykorzystanie wzrośnie do około czterech lub pięciu godzin. Nawet wtedy domowe obowiązki tworzą naturalny pułap. Robot nie otrzymuje nieprzerwanego strumienia zadań domowych.
Roboty przemysłowe mogą pracować dłużej. SemiAnalysis przytacza wdrożenie Figure w BMW, które zapewniło około 1 250 godzin pracy w ciągu mniej więcej 11 miesięcy. Maszyny miały podobno pracować około dziesięciu godzin dziennie przy wykorzystaniu na poziomie około 40 procent.
Te obserwacje wyjaśniają przewagę współdzielenia puli zasobów. GPU w centrum danych może obsługiwać roboty na różnych zmianach, w różnych lokalizacjach lub strefach czasowych. Niewykorzystana pojemność jednego wdrożenia może przejąć zapotrzebowanie innego.
Model wykazał, że ekonomika B300 stawała się korzystniejsza od poziomu około pięciu robotów przemysłowych na GPU. Poniżej tego progu dedykowany serwer może stać się kolejnym niedostatecznie wykorzystywanym aktywem kapitałowym.
To kluczowe zastrzeżenie stojące za porównaniem całkowitego kosztu posiadania Jetson Thor i B300. B300 nie staje się opłacalny tylko dlatego, że stoi w serwerowni. Potrzebuje wystarczająco skoordynowanego popytu, aby zamortyzować szafę rack, sieć, zasilanie i systemy wsparcia.
Wynajem w chmurze może ograniczyć ryzyko w małych wdrożeniach, lecz wprowadza odrębne zmienne. Operatorzy muszą uwzględnić marże dostawców, regionalną dostępność zasobów, transfer danych i dostępność usług. SemiAnalysis modelowało ekonomikę właściciela-operatora, a nie standardową umowę najmu chmury.
Gęste obliczenia FP4 również są niepełną miarą biznesową. Nabywca robota płaci za pomyślnie wykonane zadania, przewidywalne zmiany i możliwe do opanowania awarie. Tanie obliczenia mają ograniczoną wartość, jeśli przerwy w sieci obniżają przepustowość lub wymagają interwencji człowieka.
To samo ostrzeżenie dotyczy lokalnego wnioskowania. W pełni wykorzystany moduł pokładowy może na papierze wyglądać efektywnie, ale może zużywać pojemność baterii potrzebną do użytecznego ruchu. Większe baterie zwiększają masę, co może podnieść energię wymaganą do poruszania się.
Operator floty potrzebuje zatem porównania na poziomie obciążenia roboczego. Istotną jednostką mogą być zrealizowane pobrania, pomyślnie wykonane etapy montażu lub godziny autonomicznej pracy. Przepustowość sprzętu jest tylko jednym z czynników.
Ekonomika B300 wywiera presję na firmy robotyczne budujące floty ogólnego przeznaczenia. Gdy wdrożenia osiągną wystarczającą gęstość, architektura wyłącznie lokalna może unieruchamiać kosztowne zasoby obliczeniowe w maszynach używanych jedynie okresowo.
Odwrotna presja dotyka twórców stawiających przede wszystkim na zdalne działanie. Muszą udowodnić, że oszczędności ze współdzielenia puli zasobów przetrwają realne budynki, rzeczywiste zakłócenia radiowe i opóźnienia wysokiego percentyla. W przeciwnym razie teoretyczne wykorzystanie zamienia się w przestoje operacyjne.
Bariera sieciowa to problem opóźnień ogonowych
Średnia szybkość sieci może wyglądać akceptowalnie, podczas gdy rzadkie opóźnienia sprawiają, że zdalne wnioskowanie robota staje się niebezpieczne lub bezużyteczne.
Stałe opóźnienie często da się obsłużyć. System może oszacować, jak zmieni się scena, i planować z wyprzedzeniem. Zmienne opóźnienie, powszechnie nazywane jitterem, uniemożliwia robotowi określenie, kiedy nadejdzie kolejna aktualizacja.
Najbardziej szkodliwym zdarzeniem może być okazjonalny skok opóźnienia do jednej sekundy. Panel kontrolny może go tolerować. Robot trzymający komponent, zbliżający się do człowieka lub odzyskujący równowagę nie może uznać go za niegroźny.
Microsoft Research doszedł do podobnego wniosku w swoim badaniu robotics offloading study z 2026 roku. Badacze testowali obciążenia mobilnej manipulacji na pokładowych, brzegowych i chmurowych platformach GPU.
Badanie wykazało, że mniejsze pokładowe GPU nie były w stanie uruchomić pełnego stosu obciążeń. Większe pokładowe GPU skracały czas pracy na baterii o kilka godzin. Przeniesienie obliczeń łagodziło te ograniczenia, lecz dodatkowe opóźnienie sieciowe obniżało dokładność zadań.
Przepustowość stworzyła kolejną barierę. Wysyłanie obserwacji robota do zdalnego modelu może wymagać ciągłej transmisji uplink. Ten wzorzec ruchu różni się od konsumenckich usług internetowych, które priorytetowo traktują pobieranie danych do względnie nieruchomych urządzeń.
Robot porusza się, jednocześnie wysyłając strumienie z kamer i dane z czujników. Jego metalowa obudowa może blokować lub odbijać sygnały radiowe. Silniki i pobliskie urządzenia wprowadzają zakłócenia elektromagnetyczne, a orientacja stale zmienia geometrię anteny.
Fabryki dodają gęste regały, przemieszczające się zapasy, maszyny i liczne punkty dostępowe. Łącze, które działało podczas instalacji, może pogorszyć się po przestawieniu sprzętu lub uruchomieniu innej maszyny.
Domy stwarzają inny rodzaj niepewności. Ściany tworzą strefy słabego zasięgu, routery konsumenckie zapewniają nierównomierne pokrycie, a sąsiedni użytkownicy konkurują o współdzieloną przepustowość. Robot domowy może dotrzeć do martwej strefy, po prostu wchodząc do innego pokoju.
Szczególnie niebezpieczne są przełączenia między punktami dostępowymi. SemiAnalysis twierdzi, że zwykłe routery mogą zatrzymać ruch od 100 milisekund do kilku sekund podczas przejścia. Odzyskanie połączenia może wymagać dodatkowego czasu.
Tych awarii nie uchwyci prosta średnia. Sieć, która odpowiada szybko w 99 żądaniach, nadal może być nieakceptowalna, jeśli setne nadejdzie po terminie robota.
Opóźnienie wysokiego percentyla powinno zatem znajdować się obok dokładności modelu i przepustowości sprzętu w każdej ocenie wdrożenia. Twórcy muszą mierzyć najwolniejsze odpowiedzi istotne operacyjnie, a nie tylko medianę wydajności.
Microsoft measurement paper stwierdza, że żadna pojedyncza strategia umiejscowienia nie sprawdza się we wszystkich scenariuszach. Wydajność, przepustowość, energia, opóźnienie, koszt pieniężny i rywalizacja o współdzielone zasoby wzajemnie na siebie oddziałują.
Dowody te osłabiają wszelkie twierdzenia, że robotyka masowo przeniesie się do centrów danych. Zdalne wnioskowanie staje się realne wyłącznie dla obciążeń, których terminy mogą absorbować zmienność sieci. Pętle krytyczne dla bezpieczeństwa nadal wymagają lokalnego wykonania i zdefiniowanego zachowania awaryjnego.
Zdalne planowanie może również rodzić obawy dotyczące zarządzania danymi. Kamera robota może rejestrować metody produkcji, pracowników, własność klientów lub aktywność wewnątrz domu. Wysyłanie tych klatek poza lokalizację rozszerza granicę bezpieczeństwa.
SemiAnalysis podaje, że Boston Dynamics daje klientom szczegółową kontrolę nad udostępnianymi danymi. Orbit posiada certyfikat SOC 2 Type 2, a infrastruktura Google obsługuje warstwę zdalnego rozumowania.
Certyfikaty i zabezpieczenia kontraktowe rozwiązują kwestie zarządzania, lecz nie mogą spełnić wymogów każdego wdrożenia. Obiekty wojskowe, zakłady jądrowe i inne środowiska o ograniczonym dostępie mogą zakazywać przesyłania danych poza lokalizację niezależnie od zabezpieczeń technicznych.
To ograniczenie tworzy trwały rynek dla lokalnych klastrów brzegowych. Pobliskich serwer może oferować większą moc niż robot, jednocześnie utrzymując dane w obrębie obiektu. Skraca ścieżkę sieciową, lecz nadal zależy od niezawodności lokalnej sieci bezprzewodowej.
Twórcy mogą też ostrożniej dzielić modele. Robot może kompresować obrazy, wybierać istotne klatki lub przesyłać cechy pośrednie zamiast ciągłego surowego wideo. Każda z tych technik ogranicza wymagania przepustowości, zwiększając jednocześnie lokalne obliczenia i złożoność systemu.
Kolejną opcją są redundantne łącza. Robot może korzystać z wielu pasm Wi-Fi lub łączyć Wi-Fi z prywatnym 5G. Zduplikowane transmisje poprawiają niezawodność, lecz dodatkowe radia zużywają energię i wymagają skoordynowanego harmonogramowania.
Sceptyczny wniosek jest prosty. Wnioskowanie w centrum danych oferuje wiarygodną przewagę ekonomiczną i funkcjonalną, lecz żaden publiczny benchmark nie dowodzi, że zwykłe sieci mogą wszędzie zapewniać wymaganą niezawodność.
Dopóki wdrożenia nie opublikują rozkładów awarii, wskaźników interwencji i metryk ukończonych zadań, porównania TCO pozostaną warunkowe. Sieć jest częścią systemu wnioskowania, a nie oddzielnym medium.
Sieci robotów muszą być projektowane wokół ruchu uplink
Rozumowanie poza urządzeniem wymaga specjalnie zaprojektowanego harmonogramowania od kamery robota do GPU w centrum danych.
Większość infrastruktury bezprzewodowej zakłada, że użytkownicy pobierają więcej informacji, niż wysyłają. Wnioskowanie robota odwraca ten wzorzec. Kamery stale tworzą obserwacje, które muszą zostać przesłane uplink, zanim model będzie mógł odpowiedzieć.
Zwiększenie deklarowanej przepustowości nie rozwiązuje całego problemu. Wiele robotów może nadawać w tej samej chwili, tworząc kolejki i kolizje. Kanał o dużej pojemności nadal generuje jitter bez kontroli dostępu i przewidywalnego harmonogramowania.
Punkty dostępowe świadome potrzeb robotów mogłyby rezerwować powtarzające się sloty uplink dla każdej maszyny. Zamiast konkurować o czas antenowy, robot przesyłałby obserwacje w określonym rytmie. Pozostały ruch wykorzystywałby wolną pojemność.
Ten harmonogram musi uwzględniać taktowanie modelu. Zdalny planer uruchamiany raz na kilka sekund wymaga innej rezerwacji niż polityka przetwarzająca kilka klatek na sekundę. Konfiguracja sieci i projekt wnioskowania stają się ze sobą powiązane.
Uwzględniające lokalizację formowanie wiązki może przygotowywać pokrycie radiowe wokół poruszającej się maszyny. Sieć wykorzystywałaby pozycję i planowany ruch do kierowania sygnałów lub inicjowania przełączeń, zanim istniejące połączenie się pogorszy.
Znaczenie ma także centralne taktowanie. Grupowanie żądań przynosi oszczędności w centrum danych tylko wtedy, gdy żądania z wielu robotów nadchodzą wystarczająco blisko siebie, aby zostały uruchomione wspólnie. Losowe czasy nadejścia zmuszają serwer do czekania lub przetwarzania mniejszych grup.
Wspólny zegar mógłby koordynować rejestrację, kodowanie, transmisję i wnioskowanie. Serwer wiedziałby, kiedy powinna nadejść kolejna grupa obserwacji, i rezerwowałby dla niej pojemność GPU.
Spóźnione obserwacje nie powinny pozostawać bez końca w zwykłej kolejce. Mogą należeć do następnej grupy albo lokalny system może wymagać ich odrzucenia. Nieaktualna klatka może być bardziej niebezpieczna niż brakująca klatka.
Platforma centrum danych NVIDIA pokazuje, jak daleko posunęła się strona serwerowa. System GB300 NVL72 system łączy 72 GPU Blackwell Ultra i 36 CPU Grace w chłodzonej cieczą szafie rack.
NVIDIA podaje 20 TB łącznej pamięci GPU i 130 TB na sekundę przepustowości NVLink. Projekt ConnectX-8 zapewnia rozbudowaną przepustowość sieciową dla każdego GPU. Liczby te opisują zintegrowaną fabrykę AI, a nie konwencjonalne urządzenie brzegowe.
Sieć centrum danych wewnątrz szafy rack jest zatem tylko jedną częścią ścieżki. Ruch robota musi nadal przekroczyć łącze radiowe, punkt dostępowy, sieć obiektową, połączenie rozległe i granicę dostawcy, zanim dotrze do akceleratora.
Każda granica dodaje kolejną kolejkę lub domenę awarii. Operatorzy potrzebują kompleksowych poziomów usług, a nie odizolowanych deklaracji sprzętowych. Szybkie GPU nie może odzyskać czasu już utraconego przez nieprzewidywalny uplink.
Prywatne 5G może pomagać na trasach zewnętrznych lub w dużych zakładach przemysłowych. Wi-Fi oferuje dużą lokalną pojemność w domach i wielu fabrykach. Żadna z tych technologii nie zapewnia automatycznie deterministycznego działania.
Najsilniejsza architektura prawdopodobnie połączy różne łącza. Harmonogram może wybierać Wi-Fi, gdy warunki lokalne są dobre, przełączać się awaryjnie na sieć komórkową i przez cały czas utrzymywać aktywną minimalną politykę lokalną.
Zmiany w percepcji mogą dodatkowo ograniczać ruch. Robot może przycinać istotne obszary, obniżać liczbę klatek w stabilnych okresach lub kodować cechy specyficzne dla zadania. Celem jest przesyłanie użytecznej informacji, a nie każdego dostępnego piksela.
Te optymalizacje wprowadzają własne ryzyko. Jeśli lokalny filtr odrzuci coś istotnego, zdalny model nigdy tego nie zobaczy. Twórcy muszą walidować kompresję i wybór danych wobec nietypowych obiektów, oświetlenia, przesłonięć i awarii.
Model może również dostosowywać częstotliwość żądań. Proste działania mogą być realizowane całkowicie na pokładzie, podczas gdy nieznane sceny uruchamiają zdalne wsparcie. Ta kaskada skupia kosztowne rozumowanie tam, gdzie przynosi ono największą korzyść.
Takie systemy zacierają granicę między wnioskowaniem na urządzeniu a wnioskowaniem w centrum danych. Umiejscowienie staje się dynamiczne, a nie trwałe. Robot wybiera ścieżkę na podstawie ryzyka, dostępnej przepustowości, pewności modelu i złożoności zadania.
Ta elastyczność jest atrakcyjna, ale utrudnia weryfikację. Inżynierowie muszą testować więcej trybów pracy i przejść między nimi. System potrzebuje jasno określonego zachowania, gdy zdalne żądanie zostanie pomyślnie rozpoczęte, lecz połączenie zniknie przed jego ukończeniem.
Lokalny tryb awaryjny powinien zachowywać bezpieczeństwo, nie udając przy tym zachowania pełnych możliwości. Robot może się zatrzymać, bezpiecznie odłożyć przedmiot, wycofać się lub poprosić człowieka o pomoc. Kontynuowanie pracy według nieaktualnych zdalnych wskazówek stwarza inne ryzyko.
Granica sieciowa jest więc granicą inżynieryjną i produktową. Deweloperzy, którzy ją pokonają, uzyskają dostęp do współdzielonej inteligencji. Klienci muszą zdecydować, jak wiele infrastruktury zainstalują, aby otrzymać tę korzyść.
Wdrożenia dzielą generalistów od specjalistów
Im bardziej zróżnicowane zadanie, tym mocniejsze uzasadnienie dla zdalnego rozumowania, podczas gdy ograniczone zadania sprzyjają mniejszym lokalnym politykom.
Fabryki łączą przewidywalną powtarzalność z uporczywą zmiennością. Tradycyjna automatyzacja sprawdza się dobrze, gdy środowisko, komponent i ruch pozostają stabilne. Staje się kosztowna, gdy asortyment produktów i instrukcje często się zmieniają.
SemiAnalysis zauważa, że pojazd może składać się z dziesiątek tysięcy części. Jedna linia produkcyjna może obsługiwać od pięciu do dziesięciu modeli w wielu kolorach. Zmiany rocznika modelowego wymuszają dodatkową rekonfigurację.
Humanoid ogólnego przeznaczenia musi interpretować te zmieniające się warunki, zamiast odtwarzać jedną ustaloną trajektorię. Wymóg ten zwiększa wartość dużych modeli planowania, długiego kontekstu i scentralizowanych aktualizacji.
Boston Dynamics najwyraźniej jest gotowe zaakceptować zależność od sieci w zamian za szersze możliwości. Jego lokalny System 1 nadal odpowiada za ruch, podczas gdy zdalny System 2 obsługuje instrukcje, tłumaczenie i nadzór.
Wdrożenia specjalistyczne dokonują innego kompromisu. Zadania takie jak kompletowanie zamówień w magazynie, pakowanie czy ograniczone prace montażowe mogą być wystarczająco wąskie dla modelu liczącego kilka miliardów parametrów. Kompletną politykę wykonawczą można wtedy uruchomić na sprzęcie klasy Jetson lub wywodzącym się ze stacji roboczych.
Lokalne wykonywanie poprawia prywatność i izolację awarii. Upraszcza też obowiązki klienta związane z siecią. Wdrożenie może nadal działać, gdy usługa zewnętrzna staje się niedostępna.
Model specjalistyczny może jednak napotkać sufit możliwości. Rozszerzenie zakresu z jednej rodziny produktów na otwartą pracę może wymagać dodatkowych modeli, ponownego treningu lub większego zdalnego wsparcia. Lokalna pewność może stać się ograniczeniem generalizacji.
Roboty domowe stoją przed nietypowym połączeniem warunków. Ich obowiązki są zróżnicowane, co sprzyja większym modelom rozumowania. Ich sieci i układy fizyczne są niekontrolowane, co sprzyja wnioskowaniu pokładowemu.
Dostawca nie może przeprojektować rozmieszczenia routerów u każdego klienta. Nie może też zakładać, że użytkownicy zainstalują prywatną infrastrukturę komórkową. Maszyna musi dostosować się do martwych stref, przeciążenia i współdzielonego szerokopasmowego dostępu do internetu.
Pojazdy autonomiczne należą do najbardziej jednoznacznej kategorii lokalnej w pierwszej kolejności. Poruszają się po ogromnych obszarach o niekontrolowanych warunkach radiowych i wymagających terminach reakcji. Ich krytyczne dla bezpieczeństwa systemy percepcji i sterowania nie mogą czekać na wnioskowanie w centrum danych.
Usługi zdalne nadal wspierają mapowanie, analitykę flot, trening i dystrybucję oprogramowania. Funkcje te działają poza bezpośrednią pętlą od percepcji do działania. Łączność ulepsza produkt, nie stając się jedynym źródłem bezpiecznego sterowania.
Ten wzorzec sugeruje, że wnioskowanie robotyczne NVIDIA rozprzestrzeni się na kilka warstw. Moduły klasy Jetson będą chronić autonomię w czasie rzeczywistym. Lokalne serwery brzegowe obsłużą wrażliwe lub specyficzne dla danego miejsca rozumowanie. Duże centra danych dostarczą najcięższe współdzielone modele.
Komercyjna rywalizacja będzie dotyczyć orkiestracji w takim samym stopniu jak chipów. Ktoś musi kierować każde żądanie, monitorować opóźnienia, synchronizować floty, chronić dane i decydować, kiedy lokalne możliwości są wystarczające.
Producenci robotów mogliby posiadać całą tę warstwę. Dostawcy chmury mogliby sprzedawać ją jako zarządzaną infrastrukturę. Dostawcy sieci mogliby wbudować harmonogramowanie uwzględniające roboty w punkty dostępu i prywatne systemy komórkowe.
NVIDIA ma również przewagę, ponieważ dostarcza zarówno sprzęt wbudowany, jak i sprzęt do centrów danych. Wspólny stos oprogramowania może umożliwić deweloperom przenoszenie obciążeń między Thor, GPU stacji roboczych i serwerami B300 bez przebudowywania każdego komponentu.
Ta przewaga nie jest automatyczna. Różne cele sprzętowe nadal narzucają ograniczenia związane z kwantyzacją, pamięcią, temperaturą i harmonogramowaniem. Polityka zweryfikowana na serwerze może zachowywać się inaczej po optymalizacji dla urządzenia wbudowanego.
Konkurencja będzie zatem obejmować dowody z wdrożeń. Kupujący muszą zobaczyć powodzenie wykonywania zadań przy realistycznym obciążeniu, a nie odizolowane demonstracje modeli. Potrzebują też przejrzystego zachowania przy pogarszającej się łączności.
Najbardziej wiarygodni dostawcy będą raportować wskaźniki interwencji, odzyskiwanie sprawności po awarii sieci, produktywne godziny, zużycie energii i ukończone zadania. Pomiary te łączą inteligencję modelu z wartością biznesową.
W tym miejscu podział na generalistów i specjalistów staje się praktyczny. Generaliści uzasadniają większą infrastrukturę, jeśli zastępują wiele dedykowanych systemów. Specjaliści uzasadniają lokalną prostotę, jeśli niezawodnie wykonują jedno wartościowe zadanie.
Wygrywająca architektura może różnić się zależnie od lokalizacji. Kontrolowana fabryka z dziesiątkami robotów zapewnia silne korzyści ekonomiczne wynikające ze współdzielenia zasobów. Odległe miejsce pracy o słabej łączności może preferować w pełni lokalne wykonywanie, nawet z mniejszym modelem.
Trzy sygnały zdecydują, gdzie robot myśli
O kolejnym etapie zdecydują dowody z wdrożeń, wykorzystanie floty i niezawodność sieci, a nie kolejne ogłoszenie szczytowej mocy obliczeniowej.
Pierwszym sygnałem są niezależne dane o opóźnieniach z flot produkcyjnych. Dostawcy powinni ujawniać czasy odpowiedzi z wysokich percentyli, przerwy w przekazywaniu sterowania, wskaźniki utraconych żądań oraz zachowanie podczas odzyskiwania sprawności w trakcie pełnych zmian roboczych.
Stałe opóźnienie ogonowe wzmocniłoby argument za zdalnym planowaniem. Częste pauzy lub interwencje człowieka osłabiłyby go, nawet gdyby średni czas odpowiedzi i przepustowość serwera wyglądały znakomicie.
Drugim sygnałem jest rzeczywiste wykorzystanie B300 w wielu flotach robotów. SemiAnalysis modelowało około 90-procentowe wykorzystanie serwerów, które napędza znaczną część prognozowanej przewagi ekonomicznej.
Operatorzy muszą wykazać, czy popyt rzeczywiście da się łączyć na takim poziomie. Żądania robotów mogą synchronizować się zbyt ściśle, różnić się w zależności od zadania lub pozostawać zbyt rzadkie na wczesnym etapie wdrożeń.
Trwałe wykorzystanie przy stabilnym opóźnieniu zadań wspierałoby tezę o współdzielonych centrach danych. Niewykorzystane klastry przesunęłyby ekonomiczny punkt przejścia w stronę lokalnego wnioskowania i mniejszych serwerów na miejscu.
Trzecim sygnałem są możliwości modelu w ramach ograniczeń Jetson Thor. RoboTTT sugeruje, że architektura i adaptacja w czasie testowania mogą zapewnić dłuższy kontekst bez polegania na ogromnych modelach.
Jeśli mniejsze lokalne polityki zbliżą się jakością do zdalnego rozumowania, zależność od sieci będzie trudniejsza do uzasadnienia. Jeśli możliwości będą nadal podążać za wielkością modelu i pamięci, więcej planowania przeniesie się do współdzielonych akceleratorów.
Kupujący powinni prosić dostawców o jednoznaczne zdefiniowanie granicy. Które pętle pozostają lokalne? Które żądania opuszczają lokalizację? Co dzieje się, gdy połączenie zwalnia, i jak długo robot może bezpiecznie kontynuować pracę?
Powinni też wymagać ekonomiki opartej na obciążeniu. Koszt jednostki teoretycznej mocy obliczeniowej nie pokazuje realizacji zadań, wpływu na baterię, interwencji ani przestojów. Produktywne autonomiczne godziny oferują bardziej użyteczny mianownik.
Deweloperzy stoją przed pokrewnym wyborem projektowym. Mogą poświęcić ograniczone zasoby inżynieryjne na zmniejszanie modelu albo zbudować niezawodny rozproszony system wnioskowania. Większość zespołów ostatecznie zrobi po trochu obu tych rzeczy.
Wnioskowanie robotyczne NVIDIA obejmuje obecnie cały ten wybór. Jetson Thor sprawia, że zaawansowane lokalne sterowanie jest wiarygodną możliwością, podczas gdy B300 czyni współdzielone rozumowanie atrakcyjnym w skali floty. Nierozstrzygniętym elementem pozostaje ścieżka, która je łączy.
Wyłaniająca się odpowiedź jest hierarchiczna, a nie bezwzględna. Bezpieczeństwo, ruch i politykę awaryjną należy utrzymywać na maszynie. Wolniejsze, bardziej złożone rozumowanie należy wysyłać na zewnątrz, gdy pozwalają na to reguły sieciowe i dotyczące danych.
Taki projekt nie eliminuje kompromisów. Czyni je widocznymi i możliwymi do przypisania. Każda zdalna funkcja potrzebuje terminu, działania awaryjnego, granicy danych i mierzalnej korzyści ekonomicznej.
Dla zespołów oceniających fizyczną AI bezpośrednie pytanie nie brzmi po prostu, gdzie działa wnioskowanie. Chodzi o to, czy każda warstwa pozostaje użyteczna, gdy największy mózg staje się tymczasowo niedostępny.
