Z czego naprawdę składa się stack fizycznej AI: pełny stos od symulacji po edge compute

Kiedy słyszy się hasło “fizyczna AI”, łatwo wyobrazić sobie jeden wielki model, który po prostu “wie”, jak chwycić kubek albo przejść przez korytarz magazynu. Rzeczywistość jest bardziej uwarstwiona i, szczerze mówiąc, bardziej inżynierska. Robot, który działa niezawodnie poza laboratorium, stoi na kilku wyraźnie oddzielonych warstwach oprogramowania i sprzętu — od środowiska symulacyjnego, w którym powstają miliony wirtualnych prób, przez modele fundamentowe uczone na tych danych, po system operacyjny spinający czujniki z silnikami i chip w obudowie robota, który musi podjąć decyzję w ułamku sekundy. Ten artykuł rozkłada ten stos na czynniki pierwsze — warstwa po warstwie, z konkretnymi narzędziami, liczbami i firmami, które już na nim budują.

Z czego naprawdę składa się stos fizycznej AI?

Stos oprogramowania robotyki da się opisać jako cztery powiązane ze sobą warstwy. Pierwsza to symulacja i cyfrowe bliźniaki — środowisko, w którym robot “ćwiczy” miliony razy bez ryzyka zniszczenia sprzętu, zanim w ogóle dotknie prawdziwego świata. Druga to modele fundamentowe dla robotyki, czyli sieci neuronowe typu vision-language-action (VLA), które na podstawie obrazu z kamery i polecenia w języku naturalnym generują sekwencję ruchów — flagowym przykładem jest tu rodzina NVIDIA Isaac GR00T. Trzecia warstwa to oprogramowanie pośredniczące, najczęściej ROS 2, które działa jak system nerwowy robota: odbiera dane z czujników, rozdziela je między moduły percepcji, planowania i sterowania, i wysyła komendy do napędów. Czwarta warstwa to sprzęt brzegowy (edge compute) — komputer pokładowy w samym robocie, który musi uruchomić model AI lokalnie, bez czekania na odpowiedź z chmury, bo w fizycznym świecie milisekundy opóźnienia oznaczają upuszczony przedmiot albo kolizję. Do tego dochodzi piąta, spajająca wszystko warstwa danych z prawdziwego świata — teleoperacja, czyli zdalne sterowanie robotem przez człowieka, które dostarcza próbki nie do podrobienia w żadnej symulacji. Każda z tych warstw ma dziś swoich liderów technologicznych, własne ograniczenia i własną logikę kosztów, którą warto rozumieć, zanim zdecyduje się, gdzie inwestować budżet i czas zespołu.

Skąd biorą się dane treningowe? Symulacja i cyfrowe bliźniaki jako fundament

Zanim robot dostanie szansę popełnić błąd w prawdziwym magazynie czy fabryce, powinien popełnić go tysiące razy w symulacji. Cyfrowy bliźniak stanowiska pracy — wirtualna kopia hali, regału czy linii montażowej — pozwala wygenerować ogromne ilości zróżnicowanych scenariuszy: inne oświetlenie, inne ułożenie przedmiotów, inne warianty usterek. To rozwiązuje jeden z najbardziej dotkliwych problemów fizycznej AI, czyli deficyt danych. O ile modele językowe uczą się na tekście dostępnym w internecie w praktycznie nieograniczonej ilości, o tyle nagrania z prawdziwych ramion robotycznych wykonujących konkretne zadania są rzadkie, drogie w pozyskaniu i trudne do ustandaryzowania. Symulacja fizyczna, oparta na silnikach uwzględniających prawa dynamiki, tarcie i kolizje, pozwala nadrobić tę różnicę syntetycznymi danymi, które później są mieszane z nagraniami z prawdziwego świata. Dokładniejsze omówienie tego, jak buduje się i weryfikuje takie środowiska, znajdziesz w osobnym artykule o symulacji robotów i cyfrowych bliźniakach — tu warto zapamiętać jedno: ta warstwa nie jest dodatkiem do stosu, tylko jego punktem startowym, bo od jakości i różnorodności danych syntetycznych zależy, jak dobrze model poradzi sobie później z sytuacjami, których nigdy wcześniej nie widział.

Jak trenuje się modele fizycznej AI? GR00T i architektura VLA

Dane z symulacji i teleoperacji trafiają do modeli fundamentowych, które są sercem warstwy decyzyjnej. Najbardziej rozpoznawalną rodziną w tym segmencie jest NVIDIA Isaac GR00T — model typu vision-language-action, który na wejściu dostaje obraz z kamery i polecenie tekstowe, a na wyjściu generuje konkretną sekwencję ruchów manipulatora czy nóg robota humanoidalnego. Postęp między kolejnymi generacjami tego modelu jest mierzalny: według danych NVIDIA Research wersja GR00T N1.5 osiągnęła 38,3% skuteczności na dwunastu zadaniach wprowadzonych w ramach zestawu testowego DreamGen, podczas gdy poprzednia generacja, GR00T N1, uzyskała na tych samych zadaniach jedynie 13,1%. To niemal trzykrotny skok jakościowy w jednej iteracji modelu — i dobra ilustracja tego, jak szybko zmienia się ta część stosu.

Warto przy tym zachować czujność co do statusu najnowszych wersji. Dla GR00T N1.7 pojawiają się rozbieżne opisy: część materiałów prasowych określa go jako wydanie ogólnodostępne (GA) z pełnym wsparciem, podczas gdy oficjalny wątek na forum deweloperskim NVIDIA oraz wpis na blogu Hugging Face opisują go jako wydanie wczesnego dostępu (Early Access), a więc jeszcze nie w pełni stabilne. Na dziś nie da się jednoznacznie potwierdzić, który status obowiązuje — i to samo w sobie jest wskazówką dla każdego, kto planuje wdrożenie: przed produkcyjnym użyciem konkretnej wersji modelu warto samodzielnie zweryfikować jej status w oficjalnej dokumentacji, a nie polegać na zapowiedziach prasowych. Więcej o samej architekturze GR00T, jej poprzednikach i sposobie trenowania opisujemy w osobnym materiale poświęconym platformie Isaac i modelom GR00T.

Co spina to wszystko w działającego robota? ROS 2 jako system nerwowy

Model AI, nawet najlepiej wytrenowany, sam z siebie nie porusza żadnym silnikiem. Potrzebna jest warstwa pośrednicząca, która rozdziela zadania między dziesiątki modułów — percepcję, lokalizację, planowanie trajektorii, sterowanie napędami, obsługę awarii — i robi to w czasie rzeczywistym, z gwarancją, że krytyczne polecenie (na przykład natychmiastowe zatrzymanie) dotrze do silnika zanim dotrze cokolwiek innego. Od ponad dekady rolę tę pełni ROS (Robot Operating System), a jego druga generacja, ROS 2, została zaprojektowana od podstaw z myślą o zastosowaniach produkcyjnych i przemysłowych, w tym o pracy w czasie rzeczywistym i komunikacji o gwarantowanej jakości usługi.

Warto znać rytm wydań tego projektu, bo wpływa on bezpośrednio na planowanie utrzymania floty robotów. Standardowe wydanie ROS 2 Kilted Kaiju trafiło do użytku w maju 2025 roku i będzie wspierane do listopada 2026. Równolegle funkcjonuje wydanie długoterminowego wsparcia (LTS) Jazzy Jalisco, wydane w maju 2024 roku, z opieką techniczną zaplanowaną aż do maja 2029. Dla zespołów wdrażających roboty komercyjnie oznacza to jasny wybór: wydania LTS jak Jazzy Jalisco dają kilka lat stabilności bez konieczności częstych migracji, podczas gdy wydania standardowe niosą nowsze funkcje kosztem krótszego okresu wsparcia. Co do faktycznego udziału rynkowego ROS 2 względem starszej generacji ROS 1 — napotykane szacunki (rzędu kilkudziesięciu procent) pochodzą wyłącznie z raportów firm analitycznych rynku, bez potwierdzenia w niezależnym źródle pierwotnym, więc traktujemy je z rezerwą zamiast podawać jako pewnik. Szersze omówienie tego, jak ROS 2 sprawdza się poza laboratorium, opisaliśmy w artykule o ROS 2 w środowisku produkcyjnym.

Skąd biorą się dane z prawdziwego świata? Teleoperacja jako pomost

Nawet najlepsza symulacja nie odda w pełni fizyki tego, jak prawdziwa dłoń zaciska się na uchwycie, ani niuansów tarcia między dwoma nierównymi powierzchniami. Dlatego warstwa symulacyjna jest uzupełniana danymi z teleoperacji — operator zdalnie steruje ramieniem robota lub całym robotem humanoidalnym, a każdy jego ruch jest rejestrowany jako para “sytuacja–akcja” i trafia do zbioru danych treningowych. To metoda kosztowna i wolniejsza niż generowanie danych syntetycznych, ale niezastąpiona tam, gdzie liczy się precyzyjne odwzorowanie fizycznych właściwości manipulacji — chwytania przedmiotów o nietypowym kształcie, montażu drobnych elementów czy pracy w bliskim kontakcie z ludźmi. W praktyce najskuteczniejsze zespoły łączą oba źródła: masową symulację do budowania ogólnej kompetencji ruchowej i starannie wyselekcjonowaną teleoperację do dopracowania zadań wymagających chirurgicznej precyzji. Mechanikę zbierania takich danych i typowe narzędzia do teleoperacji opisujemy szerzej w tekście o teleoperacji i zbieraniu danych robotów.

Gdzie kończy się chmura, a zaczyna robot? Edge compute i Jetson Thor

Nawet najlepiej wytrenowany model VLA jest bezużyteczny, jeśli robot musi czekać sekundę czy dwie na odpowiedź z serwera w chmurze, zanim zareaguje na przedmiot spadający z regału. Dlatego czwartą, fizycznie najbardziej namacalną warstwą stosu jest komputer pokładowy — chip, który uruchamia wnioskowanie modelu bezpośrednio wewnątrz obudowy robota. Obecnym punktem odniesienia w tym segmencie jest NVIDIA Jetson AGX Thor, oparty na module obliczeniowym T5000. Zestaw deweloperski kosztuje 3499 dolarów amerykańskich i oferuje moc obliczeniową do 2070 TFLOPS w precyzji FP4 oraz 1035 TFLOPS w precyzji FP8, dzięki układowi graficznemu z architekturą Blackwell wyposażonemu w 2560 rdzeni CUDA i 96 rdzeni Tensor. Towarzyszy mu 14-rdzeniowy procesor Arm Neoverse i 128 GB pamięci LPDDR5x. Według danych producenta przekłada się to na około 7,5-krotny wzrost wydajności AI i 3,5-krotną poprawę efektywności energetycznej względem poprzedniej generacji, Jetson AGX Orin.

Te liczby mają znaczenie praktyczne, nie tylko marketingowe. Wyższa wydajność energetyczna na jednostkę obliczeń oznacza dłuższy czas pracy robota mobilnego na jednym ładowaniu akumulatora, a większa pamięć pozwala uruchomić lokalnie większe modele bez kompresji, która zwykle odbywa się kosztem jakości. Dla zespołów projektujących robota od zera to właśnie na tym etapie zapada decyzja kompromisowa między mocą obliczeniową, poborem energii, ciężarem układu chłodzenia i budżetem materiałowym całego produktu — i to zwykle ta decyzja, a nie wybór modelu AI, ogranicza, jak szybko i jak inteligentnie robot może reagować na zmieniające się otoczenie.

Jak te cztery warstwy współpracują w praktyce, dzień po dniu?

Warto zobaczyć ten stos nie jako listę osobnych narzędzi, tylko jako zamkniętą pętlę, która z czasem coraz mocniej się zacieśnia. Zespół zaczyna od zbudowania cyfrowego bliźniaka konkretnego zadania i generuje w nim pierwszą, dużą partię danych syntetycznych. Na tej partii douczany jest model fundamentowy typu VLA, który następnie trafia do testów — najpierw znowu w symulacji, potem na pojedynczym egzemplarzu robota podłączonym przez ROS 2 do prawdziwych czujników i napędów. Tam, gdzie model się myli — na przykład źle ocenia głębokość przy nietypowym oświetleniu albo gubi chwyt przy nierównej powierzchni — zespół zbiera dodatkowe przykłady przez teleoperację, celując dokładnie w te słabe punkty, zamiast losowo mnożyć dane. Poprawiony model wraca na komputer pokładowy, tym razem w postaci zoptymalizowanej pod konkretny chip — z pełną precyzją FP8 tam, gdzie liczy się dokładność, i skompresowaną precyzją FP4 tam, gdzie liczy się szybkość reakcji. Cały cykl powtarza się co kilka tygodni, a nie raz na rok, bo koszt jednej iteracji w symulacji jest ułamkiem kosztu jednej iteracji na prawdziwym sprzęcie. To właśnie ta pętla sprzężenia zwrotnego — symulacja, model, sprzęt, korekta z prawdziwego świata, symulacja od nowa — a nie pojedyncza “przełomowa” technologia, tłumaczy, dlaczego postęp w fizycznej AI ostatnio przyspieszył tak wyraźnie.

Jakie są największe pułapki przy łączeniu tych warstw w jeden system?

Złożenie czterech warstw w jeden działający produkt rzadko bywa tak proste, jak sugerują materiały marketingowe dostawców. Pierwsza typowa pułapka to rozjazd między symulacją a rzeczywistością — model, który w środowisku wirtualnym osiąga niemal stuprocentową skuteczność, potrafi zawodzić na prawdziwym sprzęcie, bo silnik fizyki nie odwzorował dokładnie tarcia, luzu w przekładni albo opóźnienia czujnika. Druga pułapka to niedoszacowanie kosztu integracji — ROS 2 świetnie się sprawdza jako warstwa komunikacyjna, ale podłączenie do niego konkretnego modelu czujnika czy sterownika silnika często wymaga napisania własnego sterownika, a nie tylko skonfigurowania gotowego. Trzecia, często pomijana pułapka to niedopasowanie mocy obliczeniowej do zadania — zespół, który dobiera komputer pokładowy dopiero po wytrenowaniu modelu, może odkryć, że model jest za duży, by zmieścić się w budżecie energetycznym docelowego robota, i musi wracać do etapu kompresji albo destylacji modelu. Czwarta wreszcie to kwestia wersjonowania — kiedy symulacja, model i oprogramowanie pośredniczące pochodzą z różnych, niezależnie aktualizowanych projektów, łatwo o niezgodność wersji, która ujawnia się dopiero na etapie wdrożenia. Świadomość tych czterech pułapek na starcie projektu pozwala zaplanować bufory czasowe, zamiast odkrywać je w najgorszym możliwym momencie — tuż przed wdrożeniem produkcyjnym.

Ile kosztuje zbudowanie własnego stosu fizycznej AI?

Poniższa tabela porządkuje cztery warstwy stosu razem z reprezentatywnymi narzędziami i przybliżonym progiem wejścia — nie jako cennik, ale jako mapa decyzji, które trzeba podjąć w pierwszej kolejności.

Warstwa stosu	Reprezentatywne narzędzie	Funkcja w stosie	Orientacyjny próg wejścia
Symulacja i cyfrowe bliźniaki	Środowiska fizyczne kompatybilne z Isaac Sim	Generowanie syntetycznych danych treningowych bez ryzyka dla sprzętu	Głównie koszt pracy inżynierów i mocy obliczeniowej w chmurze
Modele fundamentowe (VLA)	NVIDIA Isaac GR00T (rodzina N1/N1.5)	Zamiana obrazu i polecenia językowego na sekwencję ruchów	Dostęp do modelu bazowego + koszt douczania na własnych danych
Oprogramowanie pośredniczące	ROS 2 (np. Jazzy Jalisco, Kilted Kaiju)	Komunikacja między czujnikami, planowaniem i napędami w czasie rzeczywistym	Otwarte oprogramowanie, koszt to głównie integracja
Komputer pokładowy (edge compute)	NVIDIA Jetson AGX Thor	Lokalne wnioskowanie modelu AI bezpośrednio w robocie	Zestaw deweloperski od 3499 USD
Dane z prawdziwego świata	Systemy teleoperacji	Zbieranie precyzyjnych par “sytuacja–akcja” niemożliwych do uzyskania w symulacji	Koszt operatorów i sprzętu do zdalnego sterowania

Z tej tabeli wynika jedna praktyczna obserwacja: warstwa sprzętowa (Jetson) ma dziś najbardziej przejrzysty i jednoznaczny cennik, podczas gdy koszty pozostałych warstw — symulacji, douczania modeli, teleoperacji — są w dużej mierze kosztami czasu zespołu i mocy obliczeniowej, a nie jednorazowej licencji. To odróżnia budowę stosu fizycznej AI od typowego wdrożenia oprogramowania korporacyjnego, gdzie większość kosztu da się z góry oszacować w jednej pozycji budżetowej.

Kto już stoi na tym stosie? Amazon, Figure AI, Neura Robotics

Teoria stosu nabiera sensu dopiero w zestawieniu z tym, kto go już faktycznie używa na dużą skalę. Amazon ogłosił w połowie 2025 roku, że przekroczył próg miliona wdrożonych robotów w swojej globalnej sieci centrów logistycznych — flota obejmuje systemy takie jak Sequoia, Hercules, Pegasus i Proteus, a firma jednocześnie zaprezentowała własny generatywny model AI dla robotyki magazynowej. To pokazuje skalę, w jakiej stos fizycznej AI może działać w praktyce, gdy trafi do środowiska o wysokiej powtarzalności zadań, jakim jest magazyn.

W segmencie humanoidów tempo inwestycji jest równie wymowne. Figure AI zamknęła rundę finansowania serii C na ponad 1 miliard dolarów przy wycenie 39 miliardów dolarów po inwestycji — rundę tę, zamkniętą we wrześniu 2025 roku, poprowadził fundusz Parkway Venture Capital. Jeszcze większym echem odbiła się runda niemieckiej firmy Neura Robotics, która pozyskała do 1,4 miliarda dolarów w rundzie serii C prowadzonej przez Tether, z udziałem między innymi NVIDIA, Amazon, Qualcomm, Bosch, Schaeffler oraz Europejskiego Banku Inwestycyjnego. Wycena firmy sięgnęła 7 miliardów dolarów, a sama runda jest opisywana jako największe jak dotąd finansowanie firmy robotycznej działającej w modelu pełnego stosu (od czujników po oprogramowanie). Co do łącznej sumy kapitału, jaką branża robotyczna pozyskała w samym 2026 roku — napotkane szacunki rozjeżdżają się bardzo mocno, od kilkunastu do ponad pięćdziesięciu miliardów dolarów, w zależności od tego, jaki zakres firm i rund dane źródło liczy do “robotyki”. Bez jasnej metodologii żadnej z tych sum nie da się uczciwie potwierdzić, więc pomijamy tu jedną łączną liczbę i skupiamy się na pojedynczych, zweryfikowanych rundach.

Czy to już powszechna praktyka? Ekosystem deweloperski wokół stosu

Poza pojedynczymi transakcjami finansowymi wskaźnikiem dojrzałości stosu jest też liczba ludzi, którzy na nim faktycznie programują na co dzień. Na konferencji GTC w 2026 roku NVIDIA ogłosiła, że z jej stosem robotycznym — obejmującym Jetsona, platformę Isaac i modele GR00T — pracuje już ponad 2 miliony deweloperów. Przy tej samej okazji NVIDIA i Hugging Face zapowiedziały połączenie tej społeczności z bazą 13 milionów twórców AI zgromadzoną wokół Hugging Face, co w praktyce oznacza łatwiejszy dostęp do gotowych modeli, zbiorów danych i narzędzi do douczania bezpośrednio z poziomu popularnej platformy społecznościowej dla uczenia maszynowego. Dla kogoś, kto dopiero rozważa wejście w ten obszar, to sygnał, że nie startuje się od zera — dokumentacja, przykładowy kod i społeczność pytań i odpowiedzi są już rozbudowane, co skraca krzywą uczenia w porównaniu z sytuacją sprzed zaledwie kilku lat.

Jak zacząć budować stos fizycznej AI we własnej organizacji?

Praktyczna kolejność wdrożenia zwykle jest odwrotna do tej, w jakiej opisaliśmy warstwy powyżej. Najpierw warto zbudować lub wykorzystać gotowe środowisko symulacyjne dopasowane do własnego zadania — czy to sortowanie paczek, czy montaż podzespołów — bo to tam popełnia się większość błędów najtaniej. Następnie dobiera się model fundamentowy jako punkt startowy do douczania, zamiast trenować sieć od podstaw — to oszczędza miesiące pracy i wymaga zwykle rzędu setek, a nie milionów, przykładów specyficznych dla danego zadania. Trzeci krok to integracja z ROS 2 jako warstwą komunikacyjną, co pozwala podłączyć czujniki, napędy i systemy bezpieczeństwa bez pisania własnego oprogramowania pośredniczącego od zera. Dopiero na końcu dobiera się konkretny komputer pokładowy pod docelowe wymagania mocy obliczeniowej, poboru energii i budżetu — i to właśnie tutaj przenosi się gotowy, przetestowany w symulacji model do fizycznego robota. Równolegle, przez cały ten proces, warto zbierać dane z ograniczonej, kontrolowanej teleoperacji — nawet niewielka, starannie dobrana próbka nagrań z prawdziwego świata potrafi znacząco poprawić skuteczność modelu na zadaniach, których symulacja nie odwzorowuje w pełni wiernie. Szerszy obraz tego, dlaczego w ogóle warto myśleć w kategoriach całego stosu, a nie pojedynczej technologii, znajdziesz w hubie poświęconym stackowi fizycznej AI, a podstawowe pojęcia z tego obszaru zebraliśmy w słowniku fizycznej AI. Osobny tekst pokazuje też, jak dyscyplina agentic engineering — harness, pamięć, ewaluacja, nadzór — nakłada się na te cztery warstwy, kiedy agent AI dostaje fizyczne ciało: agentic engineering dla fizycznej AI.