Kosmiczne centra danych Google osiągnęły orbitę, ale aby się skalować, potrzebują 1800 startów Starshipa
Kosmiczne centra danych Google wyszły poza etap pracy badawczej 1 października, gdy firma wysłała na orbitę cztery układy AI. Eksperyment ujawnił jednak również znacznie większy problem. Model ekonomiczny Google zakłada, że SpaceX zdoła wykonać około 1800 lotów Starshipem w ciągu dekady.
Szacunek ten oznacza około 180 startów rocznie, przy założeniu, że każda misja przewozi 200 ton metrycznych ładunku. Starship po raz pierwszy osiągnął orbitę okołoziemską zaledwie kilka dni przed startem satelity Google. Zanim prognozowana przez Google ekonomika stanie się realna, SpaceX musi więc przekształcić rozwijaną rakietę w przemysłową sieć transportową.
Mały satelita nie rozstrzyga tej kwestii. Sprawdza, czy Tensor Processing Units, czyli TPU Google, są w stanie przetrwać promieniowanie, wibracje podczas startu i skrajne zmiany temperatur. Misja bada także, czy układy te mogą działać bez chłodzenia powietrzem dostępnego w naziemnych centrach danych.
Google nazywa szersze przedsięwzięcie Project Suncatcher. Proponowany system zakłada umieszczenie zasilanych energią słoneczną satelitów obliczeniowych na niskiej orbicie okołoziemskiej i połączenie ich łączami optycznymi. Atutem jest obfita energia słoneczna, lecz praktyczne bariery obejmują koszt startów, odprowadzanie ciepła, komunikację, konserwację i koordynację orbitalną.
SpaceX jest w tym planie zarazem kluczowym dostawcą i najtrudniejszą zależnością. Google może wewnętrznie udoskonalać układy, oprogramowanie i projekty satelitów. Nie może jednak stworzyć taniego transportu orbitalnego bez operatora startowego, który osiągnie ponowne wykorzystanie na niespotykaną dotąd skalę.
Kosmiczne centra danych Google zaczynają od czterech układów, a nie orbitalnej chmury
Google uruchomiło eksperyment sprzętowy, a nie działający zamiennik ziemskiego centrum danych.
Pierwszy statek kosmiczny Project Suncatcher, nazwany MVP, wystartował z Kalifornii w ramach wspólnej misji Transporter-18 SpaceX. Falcon 9 wyniósł go wraz ze 129 innymi ładunkami, według przeglądu misji orbitalnej.
Satelita powstał we współpracy z Planet, firmą zajmującą się obrazowaniem Ziemi. Google dostarczyło sprzęt obliczeniowy, w tym cztery TPU. TPU to opracowany przez Google akcelerator do trenowania modeli uczenia maszynowego i wykonywania inferencji.
Statek kosmiczny wielkości lodówki otrzymuje około jednego kilowata energii z paneli słonecznych. Takie zasilanie jest znikome w porównaniu z wymaganiami komercyjnego obiektu AI. Duże systemy naziemne wykorzystują tysiące akceleratorów wspieranych przez rozbudowaną infrastrukturę sieciową, pamięć masową, chłodzenie i wyposażenie elektryczne.
MVP będzie uruchamiać zadania Gemini, aby sprawdzić zachowanie sprzętu na orbicie. Według doniesień satelita może używać procesorów przez około 15 minut, zanim musi wstrzymać pracę, by odprowadzić zgromadzone ciepło. Taki wzorzec działania czyni go instrumentem naukowym, a nie stale dostępną usługą obliczeniową.
Misja przyspieszyła pierwotny harmonogram Google. Firma wcześniej opisywała realizowaną z Planet misję badawczą z dwoma satelitami, planowaną na początek 2027 roku. Integracja układów z istniejącym statkiem kosmicznym Planet pozwoliła Google wcześniej zebrać dane orbitalne.
Google twierdzi, że satelita oceni fizyczne obciążenia podczas startu oraz warunki termiczne i radiacyjne występujące w przestrzeni kosmicznej. Pomiary te powinny dostarczyć inżynierom dowodów, których symulacje naziemne nie potrafią w pełni odtworzyć.
To rozróżnienie ma znaczenie, ponieważ określenie „kosmiczne centrum danych” może sugerować dojrzały obiekt obsługujący zadania klientów. MVP jest bliższy kompaktowemu laboratorium. Jego zadaniem jest identyfikowanie trybów awarii, zanim Google zaangażuje się w większą architekturę satelitarną.
Mimo to ten start zmienia status Project Suncatcher. Projekt ma teraz sprzęt wystawiony na rzeczywiste warunki orbitalne, a nie wyłącznie na symulacje. Zebrane dane mogą potwierdzić założenia, ujawnić nieoczekiwane usterki lub zmusić Google do przeprojektowania systemu.
Test nastąpił również w ważnym momencie dla SpaceX. Starship po raz pierwszy osiągnął orbitę okołoziemską 28 września, a następnie rozmieścił 26 satelitów Starlink. Górny stopień stracił silnik i powrócił wcześniej niż planowano, ale misja wykazała niezbędną zdolność.
Satelita Google nie poleciał na Starshipie. Misję obsłużył Falcon 9. Falcon 9 nie zapewnia jednak ekonomiki ładunku ani objętości, których Google spodziewa się potrzebować dla pełnej orbitalnej sieci obliczeniowej.
Dlatego niewielki eksperyment od razu wskazuje na znacznie większe pytanie infrastrukturalne. Cztery układy mogą polecieć w misji współdzielonej. Tysiące satelitów przenoszących gęsto upakowane systemy obliczeniowe wymagają radykalnie innej operacji startowej.
Dlaczego Project Suncatcher potrzebuje ekonomiki Starshipa
Project Suncatcher zależy od spadku cen startów dzięki powtarzalności, ponownemu wykorzystaniu i ogromnej łącznej masie wynoszonych ładunków.
Badania Google szacują, że transport na niską orbitę okołoziemską może zbliżyć się do poziomu 200 dolarów za kilogram w połowie lat 30. XXI wieku. Szacunek opiera się na krzywej uczenia wyprowadzonej z historycznych cen startów SpaceX i łącznej masy wyniesionych ładunków.
Krzywa uczenia łączy doświadczenie produkcyjne ze spadkiem kosztu jednostkowego. Badacze Google szacują, że SpaceX osiągało około 20-procentowy spadek ceny za kilogram za każdym razem, gdy łączna wyniesiona masa podwajała się.
Przedłużenie tego trendu na Starshipa prowadzi do najbardziej zaskakującej liczby projektu. SpaceX musiałoby dostarczyć na orbitę około 370 000 dodatkowych ton metrycznych.
Przy 200 tonach metrycznych na misję daje to około 1800 startów Starshipa. Uśrednione na dziesięć lat oznacza to około 180 misji rocznie. Początkowe lata prawdopodobnie znalazłyby się poniżej tej średniej, zmuszając późniejsze operacje do jeszcze szybszego tempa.
Liczby te pochodzą z pracy Google o obliczeniach orbitalnych. Badacze podkreślają, że ich praca nie stanowi kompletnego studium wykonalności ekonomicznej. Zamiast tego ich obliczenia pokazują, co musi się wydarzyć, aby ceny startów przestały dominować w analizie biznesowej.
Próg 200 dolarów ma znaczenie, ponieważ Google porównuje koszty dostarczenia na orbitę z powtarzalnymi wydatkami energetycznymi ziemskich centrów danych. Przy takiej cenie startu skorygowane o cały okres eksploatacji koszty transportu efektywnych satelitów mogłyby wejść w szeroki zakres kosztów energii elektrycznej na Ziemi.
To porównanie ma ograniczenia. Wyklucza kilka wydatków, które decydują o konkurencyjności rzeczywistej usługi. Satelity trzeba projektować, produkować, ubezpieczać, obsługiwać, łączyć, naprawiać poprzez redundancję, a ostatecznie zastępować.
Praca zakłada również, że historyczna poprawa cen może być kontynuowana mimo istotnej zmiany projektu pojazdu. Falcon 9 i Starship nie mają identycznych systemów produkcyjnych, wzorców operacyjnych ani profili ryzyka. Trend wyprowadzony z wcześniejszych rakiet nie może zagwarantować przyszłych wyników Starshipa.
Analiza Google przyznaje, że istnieje taka niepewność. Wskazuje, że szacunek zależy od wysokiego poziomu ponownego wykorzystania, skumulowanego wolumenu, realizacji technicznej, konkurencji rynkowej i warunków regulacyjnych. Projekcja cenowa jest więc wynikiem warunkowym, a nie przedstawioną ofertą handlową.
Firma analizuje także ścieżkę o niższym wolumenie. Jeśli wzrost ładunków nie osiągnie centralnego szacunku o około 70 procent, ceny startów mogą mimo to spaść do około 300 dolarów za kilogram. Taki wynik mógłby poprawić ekonomikę orbitalną bez realizacji pełnego scenariusza 1800 startów.
Niższe ceny startów same w sobie nie tworzą jednak popytu. SpaceX potrzebuje klientów z wystarczającą ilością ładunku, aby zapełniać powtarzające się misje Starshipa. Obliczenia orbitalne mogłyby stać się jednym z takich źródeł popytu, ale tylko jeśli tanie starty najpierw uczynią systemy obliczeniowe wiarygodnymi.
Powstaje tu zależność kołowa. Kosmiczne centra danych potrzebują taniej zdolności startowej, by się skalować. Starship potrzebuje ogromnego popytu na starty, by zejść po prognozowanej krzywej kosztów.
Google nie czeka jedynie na tańsze rakiety. Project Suncatcher mógłby sam dostarczyć część masy potrzebnej, by te rakiety stały się tańsze. Ta możliwość stawia Google i SpaceX w relacji wzajemnej zależności, a nie w ramach zwykłej umowy z dostawcą.
Liczba startów jest zatem czymś więcej niż przyciągającą uwagę statystyką. To mechanizm łączący eksperyment z czterema układami z ekonomiką przyszłej sieci orbitalnej.
Google kontra realia częstotliwości startów
Głównym przeciwnikiem nie jest inny dostawca chmury. Jest nim luka między ambicjami startowymi SpaceX a operacyjnym tempem 180 misji rocznie.
Pierwszy lot orbitalny Starshipa był istotnym kamieniem milowym, lecz jednokrotne osiągnięcie orbity różni się od wykonywania setek lotów rocznie. SpaceX musi bezpiecznie powtarzać starty, ponownie wykorzystywać oba stopnie pojazdu, ograniczać prace remontowe i utrzymywać kilka miejsc startowych.
Wrześniowa misja pokazała tę lukę. Starship pomyślnie rozmieścił ładunek, lecz jeden silnik górnego stopnia przestał działać. SpaceX skróciło także planowany lot i sprowadziło pojazd po około trzech godzinach.
Loty rozwojowe mają ujawniać problemy. Problem z silnikiem nie unieważnia pojazdu ani badań Google. Pokazuje jednak, dlaczego niezawodnego tempa lotów nie można wywnioskować wyłącznie z pojemności ładunkowej.
System wykonujący 180 lotów rocznie średnio przeprowadza niemal jeden start co dwa dni. Średnia ta musi uwzględniać czas potrzebny na inspekcje, integrację ładunków, opóźnienia pogodowe, zgody regulacyjne, konserwację stanowisk startowych i reakcje na anomalie.
Liczba ta zakłada również, że każdy lot może dostarczyć 200 ton metrycznych. Rzeczywisty ładunek zależy od konfiguracji pojazdu, orbity, planów odzysku i wymagań misji. Niższa średnia masa ładunku wymagałaby większej liczby startów, aby dostarczyć tę samą łączną masę.
SpaceX opisywało znacznie wyższe długoterminowe częstotliwości lotów. Elon Musk mówił o docelowym wykonywaniu przez Starshipa tysięcy lotów rocznie. Takie wypowiedzi określają ambicje firmy, ale nie dowodzą, że system operacyjny już istnieje.
Najnowsze postępy wzmacniają argument, że Starship może zostać komercyjną rakietą nośną. Jego misja orbitalna rozmieściła 26 satelitów Starlink V3, a booster wykonał symulowane lądowanie w pobliżu wybrzeża. SpaceX rozwija pojazd z myślą o szybkim ponownym wykorzystaniu, a nie jednorazowym sprzęcie.
Starlink zapewnia SpaceX wewnętrzne źródło popytu. Firma może wynosić własne satelity komunikacyjne, jednocześnie dopracowując operacje Starshipa. Ta pionowa integracja pomogła Falconowi 9 zdobywać doświadczenie lotnicze i może wspierać wczesne tempo Starshipa.
Orbitalne centra danych stawiałyby inne wymagania. Satelity obliczeniowe przenoszą sprzęt do zarządzania ciepłem, duże panele słoneczne, optyczne wyposażenie komunikacyjne i kosztowne procesory. Muszą osiągać precyzyjne formacje orbitalne, zamiast po prostu dołączać do konstelacji szerokopasmowej.
Google jest również inwestorem SpaceX, co zbiega część interesów. Inwestycja nie usuwa jednak technicznej zależności. Harmonogram Google pozostaje związany z systemem transportowym, którego firma ani nie projektuje, ani nie kontroluje.
Inni dostawcy startów mogą ostatecznie zmniejszyć tę ekspozycję. Blue Origin, Rocket Lab i przyszli konkurenci w segmencie ciężkich startów mogą obniżyć ceny. Żaden z nich nie oferuje obecnie sprawdzonego substytutu odpowiadającego zamierzonemu przez Starshipa połączeniu dużej masy ładunku i pełnego ponownego wykorzystania.
Falcon 9 pozostaje niezawodny dla prototypów, ale model Google wskazuje na ograniczenia wolumenu, które czynią go nieodpowiednim dla masowego wdrożenia. Powstaje przez to niezręczne przejście. Istniejąca rakieta może przetestować tę ideę, podczas gdy niedokończona rakieta musi uczynić ją opłacalną.
Szacunek 1 800 startów został początkowo błędnie podany jako 1 600 w nagłówku źródłowego materiału i jego URL-u. Opublikowane sprostowanie potwierdza, że wartość wynikająca z analizy wynosi 1 800.
To sprostowanie ma znaczenie, ponieważ podkreśla skalę wyzwania. Dodatkowe dwieście startów oznacza ponad rok pracy przy wymaganej średniej częstotliwości lotów.
Rozstrzygające dowody przyniosą operacje, a nie prognozy. SpaceX musi wykazać krótszy czas przygotowania do ponownego lotu, wielokrotne wykorzystanie pojazdów, niezawodne dostarczanie ładunków i rosnącą przepustowość miejsc startowych. Do tego czasu krzywa kosztów Google pozostaje technicznie uzasadnionym scenariuszem.
Klaster AI złożony z 81 satelitów musi działać jak jeden komputer
Tani transport rozwiązuje tylko pierwszy problem, ponieważ rozproszona AI wymaga także precyzyjnego lotu w formacji i łączności na poziomie centrum danych.
Proponowana przez Google architektura wykorzystuje grupy po 81 satelitów. Jeden przykładowy klaster krążyłby na średniej wysokości około 650 kilometrów i mieściłby się w promieniu jednego kilometra.
Satelity utrzymywałyby odległość około 100–200 metrów od pobliskich jednostek. Taka geometria musi pozostawać stabilna, gdy każdy statek kosmiczny porusza się wokół Ziemi z prędkością orbitalną.
Obciążenia związane z uczeniem maszynowym wymagają częstej wymiany danych między akceleratorami. Trenowanie dużego modelu wymaga synchronizowania przez procesory danych i wyników pośrednich przy niewielkich opóźnieniach. Powolne lub niestabilne połączenia mogą sprawić, że kosztowne układy będą czekać na informacje.
Naziemne centra danych rozwiązują ten problem za pomocą światłowodów i wyspecjalizowanych przełączników. Project Suncatcher zastępuje te stałe połączenia optycznymi łączami w wolnej przestrzeni, które przesyłają dane za pośrednictwem precyzyjnie kierowanych wiązek laserowych.
Google zademonstrowało przepustowość 800 gigabitów na sekundę w jednym kierunku na krótkiej ścieżce laboratoryjnej. Dwukierunkowa przepustowość osiągnęła 1,6 terabita na sekundę. Test potwierdza podstawową koncepcję komunikacji, ale nie odtworzył całej poruszającej się formacji orbitalnej.
Rzeczywista konstelacja musi precyzyjnie kierować wieloma wiązkami, gdy satelity zmieniają położenie. System musi radzić sobie z drganiami, zmianami temperatury, degradacją komponentów, unikaniem śmieci orbitalnych oraz awariami wewnątrz klastra.
Google proponuje wykorzystanie modeli uczenia maszynowego do przewidywania ruchu orbitalnego i sterowania formacją. Takie podejście mogłoby utrzymać sąsiednie satelity w zasięgu komunikacji. Jednocześnie dodaje wymogi dotyczące zapewnienia niezawodności oprogramowania do już złożonego systemu fizycznego.
Łączność z Ziemią stanowi kolejne ograniczenie. Przepustowość między satelitami nie eliminuje potrzeby przesyłania danych wejściowych i wyników między Ziemią a orbitą. Turbulencje atmosferyczne, chmury, śledzenie wiązek i dostępność stacji naziemnych mogą ograniczać komunikację optyczną.
Niektóre obciążenia lepiej pasują do tej architektury niż inne. Przetwarzanie danych zebranych już na orbicie mogłoby zmniejszyć ilość informacji przesyłanych na Ziemię. Analiza zdjęć satelitarnych jest oczywistym przykładem, ponieważ surowe dane powstają w pobliżu procesorów.
Duże naziemne zadania treningowe są trudniejszym przypadkiem. Ich zbiory danych mogą pochodzić z systemów magazynowania danych na Ziemi. Przesyłanie tych materiałów na orbitę, koordynowanie tysięcy procesorów i odbieranie wyników może zniwelować część korzyści wynikających z obfitej energii słonecznej.
Obciążenia inferencyjne mogą okazać się bardziej wyrozumiałe. Inferencja oznacza uruchamianie wytrenowanego modelu w celu wygenerowania odpowiedzi, klasyfikacji lub prognozy. Zadania te mogą być mniejsze i wymagać mniej intensywnej synchronizacji niż długie procesy treningowe.
Testy odporności na promieniowanie przeprowadzone przez Google wspierają to rozróżnienie. Badacze firmy twierdzą, że TPU Trillium przetrwały dawkę promieniowania jonizującego odpowiadającą pięcioletniej misji bez trwałej awarii. Cząstki o wysokiej energii wciąż jednak mogą powodować tymczasowe błędy obliczeniowe.
Jeden z badaczy powiedział TechCrunch, że typowa inferencja może napotkać błąd mniej więcej raz na milion operacji. Ten sam wskaźnik staje się bardziej niepokojący, gdy tysiące układów koordynują trwający kilka miesięcy proces treningowy.
Oprogramowanie może wykrywać i ponawiać część błędnych obliczeń. Nadmiarowe procesory mogą również zastępować utraconą wydajność. Obie reakcje zużywają energię, sprzęt lub czas, osłabiając argumenty ekonomiczne.
Proponowany klaster nie jest więc po prostu szafą serwerową umieszczoną nad Ziemią. To rozproszony superkomputer, którego sieć, zasilanie, system chłodzenia i układ fizyczny pozostają w ciągłym ruchu.
Project Suncatcher, wyjaśniony na poziomie całego systemu, mniej przypomina przenoszenie konwencjonalnego regionu chmurowego. Bardziej przypomina projektowanie nowej platformy obliczeniowej wokół ograniczeń mechaniki orbitalnej.
Chłodzenie i naprawy mogą podważyć uzasadnienie biznesowe
Najtrudniejsze ryzyka nadal dotyczą odprowadzania ciepła i konserwacji, ponieważ przestrzeń kosmiczna zapewnia światło słoneczne, ale nie oferuje powietrza, wody ani techników.
Energia słoneczna jest największą zaletą Project Suncatcher. Google twierdzi, że satelity na odpowiednich niskich orbitach okołoziemskich mogą otrzymywać nawet osiem razy więcej energii słonecznej niż panele w porównywalnych lokalizacjach na Ziemi.
Dostęp do światła słonecznego pozwala uniknąć części ograniczeń naziemnej sieci energetycznej. Nowe centra danych na Ziemi mogą latami czekać na modernizację sieci przesyłowej, umowy dotyczące wytwarzania energii, zezwolenia i lokalną akceptację. Systemy orbitalne wytwarzałyby energię elektryczną bezpośrednio obok procesorów.
Jednak energia trafiająca do układu ostatecznie zamienia się w ciepło. Na Ziemi obiekty odprowadzają je za pomocą powietrza, wody, czynników chłodniczych, pomp, wież chłodniczych i wymienników ciepła. Próżnia nie ma powietrza, które mogłoby odprowadzać ciepło.
Statki kosmiczne muszą zamiast tego przewodzić ciepło z procesorów do radiatorów. Powierzchnie te oddają energię w postaci promieniowania podczerwonego. Ich wymagana powierzchnia rośnie wraz z ilością wytwarzanego ciepła oraz temperaturami, jakie może tolerować sprzęt.
MVP Google uwypukla to ograniczenie. Jego cztery układy mogą działać tylko przez krótkie okresy, zanim system zostanie wstrzymany w celu chłodzenia. Przejście od 15-minutowych eksperymentów do ciągłej działalności komercyjnej wymaga znacznie większego lub wydajniejszego sprzętu termicznego.
Radiatory zwiększają masę i powierzchnię. Większa masa podnosi wymagania startowe, a większe konstrukcje komplikują rozkładanie oraz unikanie kolizji. Osłony ochronne powodują tę samą karę, gdy inżynierowie stosują je przeciw promieniowaniu.
Niezależna ocena termiczna wskazuje na ten kompromis w kilku propozycjach orbitalnego przetwarzania danych. Konwencjonalne akceleratory AI zapewniają wymaganą wydajność, lecz nie zostały zaprojektowane jako utwardzone radiacyjnie komponenty statków kosmicznych.
Osłanianie układów zwiększa masę. Pozostawienie ich bez ochrony zwiększa liczbę błędów i ryzyko awarii. Nadmiarowy sprzęt poprawia niezawodność, ale wysyłanie zapasowych procesorów na orbitę ponownie zwiększa wymagania dotyczące masy, energii i chłodzenia.
Konserwacja jest równie bezwzględna. Technicy rutynowo wymieniają uszkodzone dyski, sprzęt sieciowy, zasilacze i karty akceleratorów w naziemnych obiektach. Klaster orbitalny nie może polegać na rutynowych wizytach serwisowych ludzi.
Artykuł Google proponuje nadmiarowe wyposażenie jako najprostsze rozwiązanie. Oznacza to wyniesienie większej mocy obliczeniowej, niż system początkowo potrzebuje, a następnie omijanie awarii.
Nadmiarowość pozwala usłudze działać, ale zmienia poziom wykorzystania zasobów. Zapasowy sprzęt nadal generuje koszty produkcji i startu. Część komponentów może pozostawać nieaktywna, dopóki inny element nie ulegnie awarii.
Żywotność satelity wprowadza kolejne ograniczenie. Google ocenia ekspozycję na promieniowanie w perspektywie pięciu lat. Obiekt naziemny może etapami wymieniać procesory, podczas gdy satelita może łączyć obliczenia, zasilanie, chłodzenie i komunikację w jednym zasobie o ograniczonej żywotności.
Szybkie cykle rozwoju sprzętu AI komplikują ten model. Satelita wystrzelony z obecnymi procesorami może stać się mniej wydajny niż nowsze naziemne układy na długo przed tym, zanim promieniowanie zakończy jego misję. Wymiana wymaga kolejnego startu, a nie podmiany serwera.
Usuwanie starego sprzętu z orbity musi również stanowić część projektu systemu. Klaster złożony z 81 satelitów jest możliwy do zarządzania tylko wtedy, gdy uszkodzone jednostki mogą bezpiecznie opuścić orbitę. Wdrożenie na dużą skalę zwielokrotnia obawy dotyczące kolizji i śmieci kosmicznych.
Problemy te nie dowodzą, że przetwarzanie orbitalne jest niemożliwe. Pokazują, dlaczego jeden udany test układu nie może potwierdzić zasadności usługi komercyjnej. Google musi mierzyć wskaźniki błędów, trwałą wydajność cieplną, dostępność energii i degradację komponentów w czasie.
Misja MVP jest cenna właśnie dlatego, że awaria byłaby pouczająca. Wykrycie obecnie ograniczenia temperatury lub wzorca promieniowania kosztuje mniej niż odkrycie go po wdrożeniu całego klastra.
Publiczna narracja Google pozostaje odpowiednio ostrożna. Aktualizacja Project Suncatcher określa satelitę jako wstępny test i wskazuje chłodzenie jako kluczowe wyzwanie badawcze.
Ta powściągliwość odróżnia program badawczy od bardziej agresywnych twierdzeń dotyczących krótkoterminowej orbitalnej mocy chmurowej. Test dostarcza dowodów, ale nie potwierdza jeszcze ciągłych obciążeń, konkurencyjnych kosztów ani możliwej do wdrożenia strategii konserwacji.
Trzy sygnały zdecydują, czy przetwarzanie w kosmosie może się skalować
Kolejne dowody muszą połączyć udany eksperyment z powtarzalnym przetwarzaniem, startami wielokrotnego użytku i wiarygodną drogą wykraczającą poza jednego satelitę.
Pierwszym sygnałem są dane MVP dotyczące długotrwałej pracy. Google musi ujawnić, jak często działają TPU, jak szybko gromadzi się ciepło oraz jak promieniowanie wpływa na dokładność inferencji.
Udane krótkie sesje potwierdziłyby, że konwencjonalne akceleratory mogą działać na orbicie. Dłuższe sesje z przewidywalnym chłodzeniem dostarczyłyby silniejszych dowodów. Częste wyłączenia lub niewyjaśnione błędy osłabiłyby argumenty za gęstymi klastrami orbitalnymi.
Czytelnicy powinni również obserwować, czy Google publikuje wyniki inferencji Gemini, a nie wyłącznie pomiary stanu sprzętu. Działający układ jest konieczny, lecz wydajność użytecznego obciążenia stanowi bardziej znaczący kamień milowy.
Drugim sygnałem jest postęp w kierunku planowanej przez Google misji z wieloma satelitami. Dwa lub więcej statków kosmicznych może przetestować łącza optyczne, koordynację i rozproszone obciążenia, których nie da się odtworzyć przy użyciu pojedynczego satelity.
Google wcześniej celowało w początek 2027 roku w przypadku dwóch prototypowych satelitów wraz z Planet. Każdy zaktualizowany harmonogram, projekt lub cel misji pokaże, jak wnioski z MVP wpłyną na ten plan.
Demonstracja z wieloma satelitami powinna ujawnić stabilność połączeń, dokładność śledzenia wiązek oraz wpływ ruchu orbitalnego na koordynację obciążeń. Pomiary te rozpoczęłyby testowanie Project Suncatcher jako systemu.
Trzecim sygnałem jest rzeczywista częstotliwość startów Starship i historia jego ponownego wykorzystania. Ekonomia Google staje się bardziej wiarygodna, gdy SpaceX wielokrotnie lata odzyskanym sprzętem, skraca czas przygotowania do ponownego lotu i zwiększa możliwości operacji ładunkowych.
Jedna misja orbitalna nie ustanawia krzywej kosztów. Sekwencja niezawodnych lotów komercyjnych dostarczyłaby istotnych dowodów. Ponowne wykorzystanie obu stopni miałoby większe znaczenie niż osiągnięcie kolejnego odizolowanego kamienia milowego lotu.
Udźwig musi również przejść od założenia projektowego do potwierdzonej wydajności operacyjnej. Obliczenie Google zakładające 1 800 startów opiera się na 200 tonach metrycznych na lot. Niższa zademonstrowana ładowność zmienia liczbę wymaganych misji.
Sygnały te należy oceniać łącznie. Lepsze układy nie zrekompensują niedostępnego cenowo transportu. Tani transport nie odprowadzi ciepła z procesorów. Skuteczne chłodzenie nie zapewni przepustowości potrzebnej do rozproszonego treningu.
Konkurenci dostarczą użytecznych porównań. SpaceX zaproponował własną orbitalną sieć obliczeniową, podczas gdy Starcloud i inne startupy testują odmienne architektury. Ich wyniki mogą ujawnić, czy projekt klastra Google jest wyjątkowo konserwatywny, czy optymistyczny.
Wczesne zastosowania komercyjne mogą również różnić się od największej wizji Google. Przetwarzanie natywne dla przestrzeni kosmicznej, w tym analiza danych z czujników lub obrazów przed transmisją, wymaga mniejszej przepustowości naziemnej. To czyni je bardziej wiarygodnym rynkiem początkowym.
Ogólne usługi chmurowe dla użytkowników na Ziemi stawiają bardziej rygorystyczne wymagania. Klienci oczekują niezawodnego dostępu, przewidywalnych opóźnień, bezpiecznego przetwarzania danych, szybkiej wymiany sprzętu i jasnych gwarancji dotyczących poziomu usług. Infrastruktura orbitalna musi spełniać te oczekiwania, jednocześnie poruszając się po orbicie.
Najważniejszy wniosek nie jest taki, że Google potrzebuje dokładnie 1 800 startów. Liczba ta pochodzi z modelu o założeniach, które będą się zmieniać wraz z rozwojem Starship, projektów satelitów i rynków.
Jej znaczenie polega na tym, co ujawnia. Centra danych Google w kosmosie wymagają systemu przemysłowego obejmującego rakiety, fabryki statków kosmicznych, sieci optyczne, inżynierię termiczną, autonomiczne operacje i sprzęt AI.
Project Suncatcher rozpoczął już testowanie jednego ogniwa tego łańcucha. Satelita może powiedzieć Google, czy jego chipy wytrzymują rzeczywiste warunki kosmiczne. Nie jest jednak w stanie określić, czy SpaceX zapewni setki startów rocznie.
Eksperyment zasługuje na uwagę, ponieważ przekształca spekulacyjny pomysł w mierzalny program inżynieryjny. Sprawia też, że pozostały dystans trudniej zignorować.
Warto obserwować, co Google raportuje z MVP, czy jego misja wielosatelitarna utrzyma harmonogram oraz jak często Starship wykonuje komercyjne misje wielokrotnego użytku. Te trzy sygnały pokażą, czy orbitalna AI staje się infrastrukturą, czy pozostaje ambitnym projektem badawczym.
