Wnioskowanie robotów NVIDIA trafia na pokład, ale centra danych wciąż mierzą wyżej
Wnioskowanie robotów NVIDIA znacznie zbliżyło się do samej maszyny, mimo że przez lata rozwój AI koncentrował się na zdalnych centrach danych. Jetson Thor zapewnia producentom robotów wystarczającą moc obliczeniową na pokładzie, aby uruchamiać kilka wymagających modeli bez oczekiwania, aż każda decyzja przejdzie przez sieć.
Ta zmiana nie czyni chmury zbędną. Tworzy wyraźniejszy podział między natychmiastową kontrolą fizyczną a kosztownym obliczeniowo rozumowaniem. Roboty potrzebują lokalnych odruchów, podczas gdy centra danych nadal oferują większe modele, współdzieloną pamięć, łatwiejsze aktualizacje i lepsze wykorzystanie zasobów.
Główną rywalizacją nie jest więc sprzęt brzegowy przeciwko infrastrukturze chmurowej. Chodzi o lokalną autonomię kontra scentralizowaną inteligencję, przy czym każda firma robotyczna decyduje, gdzie wyznaczyć granicę. Google DeepMind, NVIDIA i producenci robotów już budują swoje rozwiązania wokół różnych wersji tego podziału.
Wnioskowanie robotów NVIDIA dotarło do maszyny
NVIDIA przekształciła wnioskowanie na pokładzie z ograniczonego rozwiązania awaryjnego w wiarygodny fundament zaawansowanego zachowania robotów.
Najwyraźniejszy sygnał sprzętowy nadszedł wraz z ogólną dostępnością Jetson AGX Thor w sierpniu 2025 roku. NVIDIA zaprojektowała ten kompaktowy komputer dla humanoidów, maszyn przemysłowych, urządzeń medycznych i innych systemów przetwarzających dane z czujników w czasie rzeczywistym.
Firma twierdzi, że Jetson Thor zapewnia 7,5 razy większą moc obliczeniową AI niż Jetson AGX Orin. NVIDIA podaje również 3,5 razy większą efektywność energetyczną niż w przypadku poprzednika.
Porównania te pozostają deklaracjami producenta, a rzeczywista wydajność zależy od modelu, precyzji, wykorzystania pamięci i konfiguracji oprogramowania. Mimo to podstawowe parametry platformy wyjaśniają, dlaczego miejsce wykonywania wnioskowania przez roboty stało się pilnym pytaniem architektonicznym.
Według NVIDIA Jetson AGX Thor obejmuje 128 GB pamięci i zapewnia do 2070 teraflopów FP4. FP4 to kompaktowy czterobitowy format numeryczny, który ogranicza zapotrzebowanie modelu na pamięć i obliczenia, kosztem pewnej utraty precyzji.
Pojemność pamięci ma równie duże znaczenie jak deklarowana moc obliczeniowa. Robot może jednocześnie uruchamiać zadania związane z percepcją, językiem, mapowaniem, planowaniem ruchu i bezpieczeństwem. Każde z nich konkuruje o przepustowość pamięci, czas przetwarzania i ograniczony budżet energetyczny.
NVIDIA podaje, że jej społeczność twórców oprogramowania dla robotyki liczy ponad dwa miliony deweloperów. Wśród pierwszych użytkowników Thor wymienianych przez firmę są Amazon Robotics, Boston Dynamics, Figure, Agility Robotics, Caterpillar i Medtronic.
Lista ta obejmuje magazyny, humanoidy, ciężki sprzęt i ochronę zdrowia. Sugeruje, że AI na pokładzie staje się wspólną decyzją infrastrukturalną, a nie wąską funkcją dla jednej kategorii robotów.
Google DeepMind podchodzi do problemu od strony modeli. Jego lokalny model robotyczny został przedstawiony w czerwcu 2025 roku jako system vision-language-action zoptymalizowany do działania bezpośrednio na robotach.
Model vision-language-action, zwykle nazywany VLA, przekształca obrazy i instrukcje w działania fizyczne. Łączy percepcję wizualną, rozumienie języka i sterowanie ruchem w jednym wyuczonym systemie.
DeepMind przedstawił swój model jako użyteczny tam, gdzie opóźnienia sieciowe lub łączność ograniczałyby robota zależnego od chmury. Według firmy model może także dostosowywać się do nowych zadań dzięki dodatkowym demonstracjom.
Premiery te zmieniły praktyczny punkt wyjścia dla architektury robotycznej. Deweloperzy nie muszą już zakładać, że zaawansowana percepcja i manipulacja ogólnego przeznaczenia wymagają stałego połączenia z centrum danych.
Ani NVIDIA, ani Google nie wykazały jednak, że każda warstwa inteligencji robotycznej powinna znajdować się na pokładzie. Ich produkty umożliwiają raczej projekt hybrydowy, co rodzi trudniejsze decyzje dotyczące tego, które obliczenia pozostają lokalne.
Robot nie może czekać, aż chmura go uratuje
Systemy fizyczne narzucają inteligencji terminy, a niedotrzymanie ich może mieć większe znaczenie niż wygenerowanie najbardziej wyrafinowanej odpowiedzi.
Chatbot może się zatrzymać, gdy zdalny model generuje odpowiedź. Robot utrzymujący równowagę na dwóch nogach, unikający pracownika lub chwytający delikatny materiał nie może traktować nieprzewidywalnego opóźnienia sieciowego jako drobnej niedogodności.
Każde żądanie do chmury dodaje kilka etapów. Robot musi zakodować informacje z czujników, przesłać je, poczekać na zdalne przetwarzanie, odebrać wynik i sprawdzić, czy instrukcja nadal jest aktualna.
Świat fizyczny może zmienić się w trakcie tej podróży. Człowiek może wejść na trasę, obiekt może się wyślizgnąć albo pojazd może wjechać na skrzyżowanie. Poprawna, lecz spóźniona odpowiedź może stać się funkcjonalnie niepoprawna.
To ograniczenie sprzyja lokalnym pętlom sterowania. Pętla sterowania wielokrotnie mierzy stan systemu, oblicza korektę i stosuje ją, aby utrzymać stabilność ruchu.
Sterowanie niskopoziomowe równowagą, unikanie kolizji, sterowanie stawami i awaryjne zatrzymywanie powinny znajdować się blisko sprzętu. Funkcje te wymagają deterministycznego działania, czyli czasu odpowiedzi mieszczącego się w znanym zakresie.
Łączność wprowadza zmienność, nawet gdy średnie opóźnienie wygląda akceptowalnie. Przeciążenia, słaby zasięg, problemy z trasowaniem i przerwy w usługach powodują opóźnienia z długiego ogona rozkładu, które średnie wartości ukrywają.
Działanie offline ma znaczenie także poza odległymi lokalizacjami. Fabryki mogą izolować sieci produkcyjne ze względów bezpieczeństwa. Szpitale mogą ograniczać zewnętrzne transfery danych, a gospodarstwa rolne i place budowy często nie dysponują niezawodną łącznością.
Prywatność wzmacnia tę samą presję architektoniczną. Roboty mogą zbierać nagrania wideo i audio, mapy przestrzenne, informacje medyczne oraz obserwacje z prywatnych domów. Wysyłanie każdego surowego strumienia z czujników do zdalnej usługi zwiększa powierzchnię narażenia.
Przetwarzanie lokalne może odrzucać zbędne informacje przed transmisją. Robot magazynowy mógłby wysłać zwięzły raport o wyjątku zamiast ciągłego obrazu wideo z otoczenia pracowników.
Przepustowość stanowi kolejne ograniczenie. Wiele kamer, mikrofonów, czujników głębi i systemów lidar może generować nieprzerwane strumienie. Przesyłanie wszystkiego zużywałoby przepustowość sieci, zanim centrum danych rozpoczęłoby pracę nad wnioskowaniem.
Filtrowanie na urządzeniu pozwala robotowi decydować, które obserwacje zasługują na zdalną analizę. Może utrzymywać rutynową nawigację lokalnie, a nieznane sytuacje eskalować przy użyciu wybranych obrazów, podsumowań stanu lub skompresowanego kontekstu.
Energia komplikuje ten obraz. Lokalne obliczenia zużywają energię z baterii i wytwarzają ciepło, ale transmisja bezprzewodowa również wiąże się z kosztem energetycznym. Lepsza opcja zależy od warunków radiowych, wielkości obciążenia i dostępnych akceleratorów.
Bezpieczeństwo sprawia, że jest to coś więcej niż optymalizacja infrastruktury. Robot powinien pozostawać sterowalny, gdy jego połączenie z chmurą zniknie. Wymóg ten przenosi kluczowe odruchy, limity operacyjne i zachowania awaryjne na maszynę.
Chmura wciąż może doradzać robotowi. Nie powinna jednak być jedynym komponentem zdolnym go zatrzymać.
Dla wnioskowania robotów NVIDIA szansa jest więc konkretna. Procesory pokładowe mogą obsługiwać ścieżkę wrażliwą na czas, nawet gdy większy model zdalny realizuje zadania wymagające namysłu.
Centra danych nadal wyznaczają górną granicę inteligencji
Lokalne układy poprawiają szybkość reakcji robota, ale centra danych zachowują decydującą przewagę, gdy zadanie wymaga skali, pamięci lub współdzielonych obliczeń.
Komputer robota działa w ramach ścisłych ograniczeń. Ma skończoną pamięć, zdolność chłodzenia, czas pracy baterii, przestrzeń fizyczną i koszt produkcji. Zwiększenie jednego zasobu często pogarsza inne ograniczenie.
Centra danych mogą rozdzielać model między wiele akceleratorów. Szybkie połączenia pozwalają tym akceleratorom współdzielić parametry i dane pośrednie, które nie zmieściłyby się w jednym robocie.
Różnica ta wyznacza górną granicę inteligencji. Kompaktowy model może obsługiwać powszechne obiekty i znane instrukcje, podczas gdy model zdalny analizuje rzadkie sytuacje, korzystając z szerszej wiedzy i dłuższego kontekstu.
Rozmiar modelu nie jest idealną miarą możliwości. Mniejsze systemy mogą przewyższać większe, gdy są zoptymalizowane pod wąskie zadanie. Duże modele zdalne pozostają jednak użyteczne przy nieznanych żądaniach, planowaniu wieloetapowym i rozległej wiedzy o świecie.
Centra danych korzystają również z grupowania żądań. Grupowanie łączy żądania od kilku użytkowników lub maszyn, umożliwiając kosztownym akceleratorom bardziej efektywne ich przetwarzanie.
SemiAnalysis opisało wynikający z tego kompromis we wnioskowaniu między przepustowością systemu a interaktywnością dla pojedynczego użytkownika. Duże grupy poprawiają wykorzystanie sprzętu, podczas gdy mniejsze grupy zazwyczaj zapewniają każdemu użytkownikowi szybsze odpowiedzi.
Pojedynczy robot nie może odtworzyć tej ekonomiki. Jego procesor może pozostawać niewykorzystany podczas rutynowej pracy, a mimo to potrzebuje wystarczającej mocy na najbardziej wymagający moment lokalny.
Scentralizowana infrastruktura agreguje to zapotrzebowanie w całej flocie. Jeden zdalny klaster może obsługiwać wiele robotów, których trudne żądania pojawiają się w różnych momentach.
Aktualizacje są również prostsze w centrum danych. Operator może wdrożyć nowy model tylko raz, monitorować jego zachowanie i wycofać go bez dotykania każdej maszyny.
Lokalne modele wymagają procesu dystrybucji. Zespoły muszą zarządzać różnicami sprzętowymi, limitami pamięci masowej, zgodnością oprogramowania układowego, śledzeniem wersji i błędami podczas instalacji.
Uczenie floty także sprzyja centralizacji. Gdy jeden robot napotka nietypową paczkę, narzędzie lub konfigurację pomieszczenia, współdzielona usługa może uwzględnić ten przypadek dla innych maszyn.
Szkolenie modeli jeszcze wyraźniej należy do scentralizowanej infrastruktury. NVIDIA opisuje architekturę trzech komputerów, która oddziela szkolenie, symulację i wykonywanie zadań na pokładzie.
W tym modelu systemy DGX szkolą AI, serwery generują symulowane doświadczenia, a komputery Jetson wykonują wybrane funkcje wewnątrz robotów. Architektura rozdziela pracę zgodnie z jej wymaganiami fizycznymi i obliczeniowymi.
Podział ten pokazuje, dlaczego opowieść wyłącznie o edge AI jest niepełna. Inteligencja robotów zależy od procesu, który tworzy, testuje, wdraża, obserwuje i aktualizuje modele.
Centrum danych nie jest po prostu odległym mózgiem odpowiadającym na bieżące żądania. Jest też warsztatem, w którym buduje się i ulepsza lokalny mózg robota.
Zdalne wnioskowanie pozostaje cenne w ramach tego procesu. Robot może poprosić większy model o interpretację nieznanej instrukcji, porównanie kilku planów lub przeszukanie rozległej technicznej bazy wiedzy.
Odpowiedź nie musi bezpośrednio sterować silnikiem. Może dostarczyć plan, który lokalne systemy zweryfikują i wykonają zgodnie z aktualnymi ograniczeniami bezpieczeństwa.
To rozróżnienie chroni robota przed opóźnionymi lub nieodpowiednimi poleceniami. Zachowuje również dostęp do możliwości, które nie mieszczą się na pokładzie.
Zwycięska architektura oddziela odruchy od rozumowania
Praktyczną odpowiedzią jest hierarchia: systemy lokalne kontrolują natychmiastowe zachowanie, podczas gdy systemy zdalne obsługują kosztowne rozumowanie i uczenie całej floty.
Deweloperzy już stosują hierarchiczne sterowanie w robotyce. Szybkie komponenty zarządzają stabilnością i ruchem, podczas gdy wolniejsze komponenty wybierają cele i sekwencje.
Generatywna AI rozszerza tę strukturę, zamiast ją zastępować. Model VLA może łączyć instrukcje z działaniami, ale nadal działa obok kontrolerów, monitorów bezpieczeństwa, systemów percepcji i planerów.
Najbezpieczniejsza granica wynika z pilności. Obliczenia z twardymi terminami pozostają lokalne. Zadania tolerujące opóźnienie mogą trafić do centrum danych, jeśli zdalne przetwarzanie oferuje lepsze możliwości.
Robot dostawczy stanowi użyteczny przykład. Systemy lokalne powinny wykrywać pieszych, podążać wzdłuż krawężnika, zatrzymywać się przed przeszkodami i utrzymywać równowagę bez połączenia z internetem.
System zdalny może zinterpretować nową instrukcję dostawy, zmienić trasę lub ocenić nieznane wejście do budynku. Robot może następnie zweryfikować proponowany plan względem lokalnych warunków.
Roboty przemysłowe tworzą podobny podział. Przetwarzanie pokładowe może kontrolować części i korygować ruch podczas montażu. Centralna usługa może analizować wzorce produkcyjne w kilku zakładach.
Humanoidy sprawiają, że wyznaczenie tej granicy jest trudniejsze, ponieważ ich zadania są mniej przewidywalne. Potrzebują szybkiego sterowania całym ciałem, lecz użytkownicy mogą prosić je o wykonanie długich, nowych sekwencji.
Oryginalne badanie Gemini Robotics firmy Google opisuje modele przeznaczone do uogólniania między zadaniami i formami robotów. Uogólnianie jest ważne, ale ocena laboratoryjna nie jest w stanie objąć wszystkich warunków wdrożeniowych.
Architektura hybrydowa daje możliwość eskalacji. Gdy pewność spada poniżej progu, robot może się zatrzymać, poprosić o pomoc lub wysłać wybrany kontekst do silniejszego modelu zdalnego.
Sama pewność nie wystarcza. Wyuczone modele mogą pozostawać pewne mimo błędów, dlatego systemy potrzebują także wyraźnych limitów działania i niezależnych kontroli.
Usługa zdalna powinna zwracać ustrukturyzowane intencje zamiast nieograniczonych poleceń dla siłowników. Na przykład może zaproponować cel: „umieść niebieski pojemnik na trzeciej półce”.
Lokalne oprogramowanie planujące może odrzucić ten cel, jeśli półka jest zablokowana, obiekt jest niestabilny albo osoba wejdzie do obszaru pracy.
Taki projekt czyni z centrum danych konsultanta, a nie lalkarza. Zachowuje scentralizowaną inteligencję, nie uzależniając każdej pętli sterowania od niezawodności sieci.
Kierowanie obciążeń staje się kluczową funkcją produktu. System musi oceniać, który model może rozwiązać każde żądanie w ramach jego budżetu czasu, energii, prywatności i bezpieczeństwa.
Proste żądania mogą pozostać na pokładzie. Złożone żądania mogą korzystać ze zdalnej inferencji, a wrażliwe żądania mogą wymagać przetwarzania lokalnego, nawet gdy lokalny wynik jest mniej zaawansowany.
Buforowanie może ograniczyć liczbę powtarzanych wywołań chmury. Robot może pobrać zdalne wskazówki dotyczące nowego zadania, a następnie zapisać zwięzłą politykę do przyszłego wykorzystania.
Operatorzy flot mogą także planować niepilne analizy. Dzienniki ukończonych zadań mogą być przesyłane w bezpiecznych okresach, co pozwala modelom w centrum danych identyfikować awarie bez wpływu na bieżące zachowanie.
To podejście przypomina architektury obliczeniowe łączące lokalne aplikacje z usługami chmurowymi. Robotyka podnosi stawkę, ponieważ rezultat zmienia obiekty fizyczne i wspólne środowiska.
Przewaga NVIDIA polega na dostarczaniu obu stron tego podziału. Jej akceleratory do centrów danych wspierają rozwój modeli i zdalną inferencję, podczas gdy Jetson uruchamia wybrane obciążenia na brzegu sieci.
Ta pozycja tworzy również napięcia dla klientów. Wertykalnie zintegrowany stos może uprościć rozwój, ale może zwiększyć zależność od sprzętu, oprogramowania i narzędzi modelowych jednego dostawcy.
Google podchodzi do problemu przez modele i usługi chmurowe, podczas gdy producenci robotów kontrolują końcową integrację sprzętową. Inni producenci układów mogą konkurować, oferując niższe zużycie energii lub bardziej otwarte opcje wdrożenia.
Istotna rywalizacja nie dotyczy tego, która firma ogłosi się mózgiem robota. Chodzi o to, który stos przenosi pracę między poziomami hierarchii bez naruszania wymogów opóźnienia, bezpieczeństwa i ekonomiki.
Czego nie pokazują deklaracje dotyczące AI działającej na urządzeniu
Specyfikacje dostawców dowodzą, że w robotach mieści się więcej mocy obliczeniowej, ale nie dowodzą niezawodnej autonomii w niekontrolowanych środowiskach.
Liczby dotyczące szczytowej przepustowości rzadko opisują cały wdrożony system. Rzeczywiste roboty muszą dzielić zasoby między kamery, czujniki, sieć, planowanie, rejestrowanie danych i funkcje bezpieczeństwa.
Znaczenie ma również reklamowana precyzja. Wydajność FP4 oznacza obliczenia o niskiej precyzji, ale niektóre modele lub operacje wymagają wyższej precyzji. Ich efektywna przepustowość może różnić się od wartości podawanej w nagłówkach.
Pojemność pamięci również nie jest równa użytecznej pojemności dla modeli. System operacyjny, potoki percepcji, pamięci podręczne i równolegle działające aplikacje zużywają część dostępnej przestrzeni.
Ciepło może obniżać trwałą wydajność. Procesor może na krótko osiągnąć szczyt, a następnie zwolnić, gdy chłodzenie nie jest w stanie odprowadzić wystarczającej ilości ciepła z kompaktowej obudowy.
Roboty zasilane bateriami stoją przed kolejnym kompromisem. Więcej rozumowania pokładowego może ograniczyć zależność od sieci, ale stałe użycie akceleratora może skrócić czas pracy lub wymagać większej baterii.
Kompresja modeli wprowadza własne ryzyka. Kwantyzacja zmniejsza liczbę bitów używanych dla wag modelu, dzięki czemu model staje się mniejszy i szybszy.
Kompresja może jednak nierównomiernie pogarszać wydajność. Rzadkie obiekty, subtelne szczegóły wizualne lub nietypowe instrukcje mogą ucierpieć bardziej niż typowe zadania benchmarkowe.
Demonstracje laboratoryjne zwykle działają w ramach kontrolowanych zestawów zadań. Wdrożenia komercyjne wprowadzają odblaski, kurz, hałas, uszkodzone obiekty, zatłoczone przestrzenie i użytkowników formułujących żądania w nieprzewidywalny sposób.
Model ogólnego przeznaczenia nadal może zawodzić na obrzeżach swojego rozkładu treningowego. Kluczowe pytanie nie brzmi, czy ukończył dopracowaną demonstrację.
Operatorzy potrzebują wskaźników awarii z długotrwałych wdrożeń. Potrzebują również danych o zachowaniu podczas odzyskiwania sprawności, częstotliwości interwencji i wydajności po ustabilizowaniu się temperatur sprzętu.
Zdalna inferencja mierzy się z porównywalnymi lukami. Większy model może wygenerować lepszy plan, pozostając jednocześnie podatnym na nieaktualne informacje z czujników lub niejednoznaczne instrukcje.
Statystyki dostępności chmury również nie ujmują jakości połączenia każdego robota. Usługa może pozostawać operacyjna, gdy maszyna traci lokalny zasięg w windzie lub obiekcie o metalowych ścianach.
Bezpieczeństwo działa w obie strony. Przetwarzanie lokalne ogranicza transmisję danych, ale umieszczenie wartościowych modeli i zapisów operacyjnych na urządzeniu tworzy fizyczny cel ataku.
Atakujący mogą ukraść robota, zbadać jego pamięć masową lub wykorzystać niezałataną lokalną usługę. Systemy scentralizowane są łatwiejsze do aktualizacji, choć pojedyncze naruszenie może wpłynąć na większą flotę.
Systemy hybrydowe dziedziczą obie powierzchnie ataku. Potrzebują uwierzytelniania urządzeń, szyfrowanej komunikacji, podpisanych aktualizacji modeli, kontroli dostępu i jasnych zasad działania offline.
Zależność od dostawcy również zasługuje na analizę. Firma robotyczna może optymalizować modele pod jeden akcelerator, środowisko uruchomieniowe i łańcuch narzędzi wdrożeniowych.
Zmiana dostawców może wtedy wymagać konwersji modeli, ponownego testowania wydajności i nowej walidacji bezpieczeństwa. Koszty te mogą utrzymywać się przez cały komercyjny okres życia robota.
NVIDIA twierdzi, że jej stos physical AI łączy Jetson Thor z oprogramowaniem robotycznym Isaac i powiązanymi narzędziami do przetwarzania sygnałów z czujników. Klienci muszą zdecydować, czy ta integracja przeważa nad kosztem zależności.
Wydania on-device firmy Google DeepMind rodzą kolejną niepewność: dostęp. Programy dla wczesnych użytkowników lub zaufanych testerów mogą demonstrować kierunek techniczny, nie pokazując szerokiej dostępności produkcyjnej.
Ani imponujący sprzęt, ani zdolny VLA nie rozwiązują kwestii odpowiedzialności. Gdy hybrydowy robot zawiedzie, śledczy muszą ustalić, czy błąd spowodowało urządzenie, sieć, zdalny model czy polityka kierowania.
To wyzwanie diagnostyczne będzie kształtować ubezpieczenia, zamówienia i regulacje. Nabywcy będą wymagać dzienników odtwarzających to, co każdy komponent zaobserwował i zdecydował.
Najsilniejsze wdrożenia nie ukryją tej złożoności za pojedynczym wynikiem autonomii. Będą osobno mierzyć zachowanie lokalne, eskalację do chmury i interwencję człowieka.
Trzy sygnały ujawnią, gdzie roboty naprawdę myślą
O kolejnym etapie zdecyduje zachowanie we wdrożeniach, a nie kolejna runda ogłoszeń o szczytowej mocy obliczeniowej.
Pierwszym sygnałem jest udział zadań robota ukończonych bez zdalnej inferencji. Dostawcy powinni raportować, jak często maszyny eskalują zadania, ile trwają te eskalacje i co dzieje się podczas utraty połączenia.
Rosnący wskaźnik lokalnego ukończenia zadań wzmocniłby argument za inferencją robotyczną NVIDIA i innymi platformami brzegowymi. Pokazałby, że systemy pokładowe potrafią obsłużyć więcej niż odruchy awaryjne.
Metryka wymaga jednak stabilnej definicji zadania. Robot obsługujący lokalnie prostsze zlecenia niekoniecznie przewyższa robota, który wysyła trudniejsze problemy do chmury.
Drugim sygnałem jest trwała wydajność przy rzeczywistych ograniczeniach energetycznych i termicznych. Nabywcy potrzebują wyników kompletnych robotów pracujących przez długie zmiany, a nie odizolowanych procesorów uruchamiających krótkie testy.
Jeśli Jetson Thor i konkurencyjne systemy utrzymają działanie kilku modeli bez niedopuszczalnych skutków termicznych lub dla baterii, więcej planowania przeniesie się na maszyny. Utrzymujące się ograniczanie wydajności zachowa większą rolę chmury.
Trzecim sygnałem jest projekt architektur produkcyjnych flot. Warto obserwować, czy czołowi producenci robotów udostępniają działanie lokalne jako priorytet, zdalną eskalację i audytowalne zachowanie awaryjne jako wyraźne funkcje produktu.
Jasna hierarchia potwierdziłaby tezę hybrydową. System, który po cichu zależy od stałej łączności, pokaże, że jego najważniejsza inteligencja nadal znajduje się gdzie indziej.
Dostawcy centrów danych również mają powody, by wspierać tę hierarchię. Mogą sprzedawać bardziej wartościowe rozumowanie, analitykę flot, symulacje i szkolenie modeli bez przetwarzania każdej klatki z czujników.
Producenci układów brzegowych korzystają, gdy lokalne obciążenia rosną. Producenci robotów korzystają, gdy mogą wybierać najtańsze bezpieczne miejsce wykonania każdego zadania.
Klienci powinni zadawać dostawcom bezpośrednie pytania przed wyborem platformy. Które funkcje przetrwają awarię sieci? Jakie dane opuszczają maszynę? Który model podejmuje każdą decyzję?
Powinni także pytać, jak robot odrzuca nieaktualne instrukcje z chmury. Zdalny plan utworzony kilka sekund wcześniej może już nie pasować do bieżącej sceny.
Dla deweloperów podstawowym zadaniem projektowym nie jest już wybór jednego miejsca inferencji. Jest nim budowa routera, który traktuje opóźnienie, pewność, prywatność i bezpieczeństwo jako ograniczenia pierwszej klasy.
Pracownicy umysłowi spotkają się z tą samą decyzją za pośrednictwem robotów biurowych, autonomicznych urządzeń i systemów AI obserwujących przestrzenie fizyczne. Lokalizacja danych będzie kształtować zaufanie równie mocno jak możliwości modelu.
Inferencja robotyczna NVIDIA czyni architekturę local-first bardziej praktyczną, ale nie rozstrzyga większej rywalizacji. Centra danych nadal dostarczają największe modele i wspólną pętlę uczenia.
Lepsze pytanie nie brzmi więc, gdzie robot myśli. Należy zapytać, które myśli muszą wydarzyć się teraz, które wymagają większej skali i kto pozostaje odpowiedzialny, gdy te dwa podejścia się nie zgadzają.
