Oprogramowanie AI Satlyt dla orbity wybrało otwartą drogę, którą SpaceX i Google odrzuciły
Oprogramowanie AI Satlyt dla orbity trafia w przestrzeń kosmiczną po tym, jak SpaceX i Google odrzuciły wewnętrzne propozycje założyciela, Ramy Afullo, dotyczące rozproszonych obliczeń na orbicie. Satlyt pozyskał obecnie rundę seed o wartości 8 mln dolarów i zapewnił miejsce dla swojego oprogramowania w wielu misjach satelitarnych.
Zmiana ta stała się wyjątkowo widoczna, gdy oprogramowanie Satlyt dotarło na orbitę za pośrednictwem SpaceX, obok sprzętu dla Google Project Suncatcher. Obaj byli pracodawcy wspierają teraz strategie obliczeń orbitalnych, lecz realizują architekturę inną niż ta, którą wybrał Afullo.
Satlyt chce dostarczać warstwę oprogramowania działającą na statkach kosmicznych wielu producentów. SpaceX reprezentuje przeciwne podejście: jedną firmę kontrolującą starty, satelity, łączność, sprzęt obliczeniowy i dużą część środowiska operacyjnego.
Ta różnica ma większe znaczenie niż zbieg okoliczności polegający na współdzieleniu rakiety. Wyznacza wczesną rywalizację o to, kto kontroluje warstwę obliczeniową nad Ziemią: właściciele pionowo zintegrowanych statków kosmicznych czy niezależna platforma łącząca zróżnicowane floty.
Oprogramowanie AI Satlyt dla orbity wykroczyło poza etap prezentacji
Najważniejsza zmiana polega na tym, że Satlyt ma teraz finansowanie, doświadczenie lotnicze i rzeczywiste obciążenia robocze zamiast odrzuconej wewnętrznej propozycji.
Afullo pracował w organizacji chmurowej Google, zanim w 2024 roku dołączył do biznesu Starlink firmy SpaceX. Powiedział TechCrunch, że proponował obliczenia orbitalne w obu firmach. Każda z nich odrzuciła ten pomysł w tamtym czasie.
Następnie współzałożył Satlyt, działający w Sunnyvale w Kalifornii oraz w Nairobi w Kenii. Firma rozwija oprogramowanie, które pozwala satelitom przetwarzać dane lokalnie, a docelowo współdzielić zadania obliczeniowe między statkami kosmicznymi.
Rundę seed Satlyt o wartości 8 mln dolarów poprowadził działający w Houston fundusz Non Sibi Ventures. Wśród partnerów inwestora znajduje się były astronauta NASA Bernard Harris, którego doświadczenie pomogło firmie ocenić propozycję pod względem technicznym i komercyjnym.
Finansowanie jest tylko jedną częścią tego wydarzenia. Satlyt twierdzi, że jego oprogramowanie odbyło już loty w dwóch misjach demonstracyjnych, zapewniając firmie doświadczenie z ograniczonymi zasobami obliczeniowymi poza testami laboratoryjnymi.
Najnowsze zgłoszone wdrożenie obejmuje sprzęt zbudowany przez TakeMe2Space, indyjską firmę opracowującą systemy obliczeniowe dla satelitów. Misja przenosi na statek kosmiczny trzy różne obciążenia robocze klientów.
NASA płaci za testowanie protokołów chmury obliczeniowej w kosmosie. Stellerian, firma zajmująca się obserwacją orbitalną, planuje ocenić przetwarzanie obrazów. TakeMe2Space chce pokazać, że jej satelita może obsługiwać oprogramowanie firm zewnętrznych.
Ci klienci reprezentują trzy istotne warstwy popytu. Agencja rządowa chce walidacji technicznej, operator komercyjny chce szybszej analizy, a producent statków kosmicznych chce bardziej elastycznego produktu.
To połączenie zapewnia Satlyt mocniejszy test niż prosta demonstracja oprogramowania. Platforma musi obsługiwać różne obciążenia robocze, działając jednocześnie w granicach jednego statku kosmicznego pod względem energii, pamięci, temperatury i łączności.
Firma wdrożyła również skwantyzowany model Gemma 3 na pokładzie satelity obsługiwanego przez Momentus. Kwantyzacja zmniejsza precyzję numeryczną modelu, pomagając mu działać przy mniejszym zapotrzebowaniu na pamięć i moc obliczeniową.
Według testów Gemma model o miliardzie parametrów analizował lokalnie telemetrię, logi aplikacji i błędy oprogramowania. Działał za pośrednictwem llama.cpp, frameworka inferencyjnego zaprojektowanego pod kątem wydajnego wykonywania modeli.
W dwóch testach wstrzykiwania błędów system zmniejszył rozmiar ładunków diagnostycznych z 1319 bajtów do 469 bajtów oraz z 1318 bajtów do 464 bajtów. Redukcje wyniosły odpowiednio 64,4% i 64,8%.
Model generował też krótkie diagnozy i zalecane działania na podstawie dostępnego kontekstu technicznego. Wynik ten nie potwierdza niezawodności autonomicznych operacji statków kosmicznych, ale ilustruje bezpośrednie zastosowanie AI na pokładzie.
Zamiast przesyłać każdy surowy log na Ziemię, satelita może podsumować błąd przed wykorzystaniem ograniczonego okna łączności w dół. Kontrolerzy naziemni otrzymują wtedy mniejszy, bardziej użyteczny komunikat.
Postępy Satlyt opierają się więc na praktycznym obciążeniu roboczym, a nie wyłącznie na odległej wizji ogromnych orbitalnych centrów danych. Firma zaczyna od diagnostyki oprogramowania, analizy telemetrii i przetwarzania obrazów na sprzęcie, który już zmierza na orbitę.
Tworzy to centralne napięcie artykułu. SpaceX i Google mogą rozwijać obliczenia orbitalne poprzez ściśle kontrolowane systemy, podczas gdy Satlyt musi udowodnić, że współdzielone oprogramowanie może działać na urządzeniach innych firm.
Rynkiem w najbliższej perspektywie jest przetwarzanie na pokładzie, a nie gigantyczne kosmiczne centra danych
Satlyt nie potrzebuje pełnoskalowej chmury orbitalnej, aby tworzyć wartość, ale potrzebuje, aby operatorzy satelitarni traktowali oprogramowanie jako niezależną decyzję zakupową.
Większość satelitów nadal w dużym stopniu zależy od stacji naziemnych. Gromadzą obrazy, odczyty czujników, dane operacyjne i logi błędów, a następnie przesyłają wybrane informacje podczas zaplanowanych okien komunikacyjnych.
Model ten tworzy wąskie gardło. Statek kosmiczny może generować więcej danych, niż jest w stanie ekonomicznie przesłać na Ziemię, zwłaszcza gdy okna kontaktu są krótkie lub przepustowość jest sporna.
Przetwarzanie na pokładzie przenosi część decyzji bliżej czujnika. Satelita może odrzucać bezużyteczne obrazy, priorytetyzować podejrzane obiekty, podsumowywać usterki lub kompresować obserwacje przed transmisją.
Pomysł ten przypomina edge computing na Ziemi. Edge computing prowadzi analizę blisko źródła danych, ograniczając potrzebę przesyłania wszystkiego do scentralizowanej chmury.
Kosmos czyni ten kompromis bardziej dotkliwym. Zdalne urządzenie naziemne może odzyskać połączenie sieciowe w ciągu kilku minut. Statek kosmiczny może mierzyć się z ograniczonym zasięgiem, ścisłymi budżetami energetycznymi, promieniowaniem i brakiem możliwości fizycznej naprawy.
Dlatego przykład diagnostyczny Satlyt ma znaczenie. Zmniejszenie raportu błędu o ponad 60% brzmi skromnie w porównaniu z wizjami klastrów AI na orbicie. Rozwiązuje jednak koszt, z którym operatorzy już się mierzą.
Firma twierdzi, że lokalna analiza może ograniczyć pracę związaną z przetwarzaniem naziemnym i skrócić czas reakcji na anomalie. Dokładne oszczędności finansowe będą różnić się zależnie od satelity, misji, modelu zatrudnienia i umowy telekomunikacyjnej.
Przetwarzanie obrazów oferuje kolejny bezpośredni przypadek użycia. Satelita obserwacji Ziemi może identyfikować kadry zasłonięte chmurami przed ich przesłaniem na Ziemię lub nadawać priorytet obrazom zawierającym docelowy warunek.
Obciążenia robocze związane z obserwacją kosmosu działają według tej samej logiki. Satelita może filtrować obrazy pod kątem potencjalnych obiektów lub nietypowego ruchu, a następnie przesyłać najistotniejsze dane w pierwszej kolejności.
Zastosowania te nie wymagają centrum danych wielkości magazynu na orbicie. Wymagają małych modeli, które działają przewidywalnie na ograniczonych komputerach i generują użyteczne wyniki w ramach ścisłych budżetów zasobów.
To rozróżnienie przyciągnęło również głównego inwestora Satlyt. Partner Non Sibi, Kent Lucas, powiedział TechCrunch, że firma nie potrzebuje gigantycznych kosmicznych centrów danych, aby odnieść sukces. Sam wzrost liczby satelitów może poszerzyć jej rynek docelowy.
Argument jest rozsądny, lecz nadal zależy od kilku założeń. Więcej statków kosmicznych musi być wyposażonych w procesory ogólnego przeznaczenia, operatorzy muszą zezwalać na oprogramowanie firm zewnętrznych, a projektanci misji muszą przeznaczać ograniczoną energię na obciążenia AI.
Afullo oczekuje, że zaawansowane procesory staną się powszechne w satelitach. Wyznaczył ambitny cel dotarcia do 20% satelitów do końca tej dekady.
Cel ten pozostaje aspiracją firmy, a nie niezależną prognozą. Floty satelitarne znacznie się różnią, a wiele statków kosmicznych wykorzystuje wyspecjalizowane komputery zaprojektowane dla jednej, starannie zwalidowanej misji.
Możliwość jest jednak łatwiejsza do zrozumienia niż szeroka narracja o chmurze orbitalnej. Satlyt może sprzedawać użyteczne przetwarzanie na pokładzie, zanim satelity zaczną współdzielić największe obciążenia AI.
Deweloperzy powinni postrzegać tę fazę jako test przenośności oprogramowania. Kluczowe pytanie brzmi, czy jedna warstwa operacyjna może obsługiwać różne procesory, ładunki użyteczne, systemy łączności i wymogi bezpieczeństwa statków kosmicznych.
Nabywcy korporacyjni powinni koncentrować się na wynikach, a nie na retoryce. Mniejsza ilość danych przesyłanych w dół, szybsza reakcja na anomalie i obrazy o wyższej wartości to mierzalne korzyści, nawet jeśli system bazowy nigdy nie stanie się gigantycznym centrum danych.
Te praktyczne wskaźniki wyjaśniają również, dlaczego zasiedziałe firmy kosmiczne odczuwają presję. Jeśli klienci cenią przenośne oprogramowanie, dostawcy sprzętu tracą część kontroli nad aplikacjami działającymi na ich satelitach.
SpaceX buduje iPhone’a, podczas gdy Satlyt chce zbudować Androida
Główna rywalizacja nie dotyczy wielkości Satlyt i SpaceX; chodzi o otwartą warstwę oprogramowania kontra zamknięty, pionowo zintegrowany stos obliczeniowy.
Afullo używa znanej analogii, aby wyjaśnić różnicę. Jeśli SpaceX stanie się iPhone’em orbitalnych centrów danych, on chce, aby Satlyt stał się Androidem.
Porównanie nie jest doskonałe, lecz oddaje strategiczny podział. Apple łączy sprzęt, oprogramowanie operacyjne, usługi i dystrybucję w ramach jednego ściśle zarządzanego systemu. Android obsługuje urządzenia wielu producentów.
SpaceX już kontroluje większą część fizycznego stosu niż większość potencjalnych konkurentów. Buduje rakiety, obsługuje infrastrukturę startową, produkuje satelity, zarządza konstelacją komunikacyjną i obsługuje klientów usług łączności.
Taka integracja może ograniczać koszty koordynacji. Inżynierowie mogą wspólnie optymalizować sprzęt i oprogramowanie, utrzymywać spójne interfejsy oraz działać szybko bez negocjowania standardów między niepowiązanymi dostawcami statków kosmicznych.
Tworzy jednak także zależność. Klient budujący rozwiązanie na zastrzeżonej platformie orbitalnej może zostać związany z harmonogramem startów jednej firmy, jej planem technologicznym, cenami, interfejsami i decyzjami dotyczącymi dostępu.
Satlyt stawia na przeciwne rozwiązanie. Nie planuje produkować satelitów. Jego oprogramowanie ma działać na statkach kosmicznych należących do różnych operatorów i przekształcać ich zasoby obliczeniowe we współdzieloną usługę.
Firma porównuje swoją rolę do VMware i Snowflake. VMware oddzielił aplikacje od konkretnych serwerów fizycznych, podczas gdy Snowflake zapewnił klientom zarządzaną warstwę danych działającą w infrastrukturze chmurowej.
Na orbicie taka abstrakcja jest znacznie trudniejsza. Naziemne serwery chmurowe korzystają ze stosunkowo ustandaryzowanych procesorów, sieci, zasilaczy, systemów pamięci masowej i praktyk utrzymaniowych.
Satelity są niestandardowymi maszynami wystawionymi na promieniowanie, cykle termiczne, ograniczoną energię, przerywane łącza i ruch orbitalny. Nawet ponowne uruchomienie procesu, który uległ awarii, może mieć konsekwencje na poziomie misji.
Otwarta platforma orbitalna musi zatem robić więcej niż instalować ten sam pakiet na różnych komputerach. Musi uwzględniać różnice sprzętowe bez osłabiania mechanizmów bezpieczeństwa ani zakłócania podstawowych funkcji statku kosmicznego.
Platforma potrzebuje również bezpiecznej metody harmonogramowania pracy. Aplikacja zewnętrzna nie może zużywać energii, pamięci ani przepustowości sieciowej potrzebnych do nawigacji, łączności lub podstawowego ładunku użytecznego.
Wyzwania te wzmacniają argument za integracją pionową. SpaceX może projektować swój sprzęt obliczeniowy, łącza między satelitami, środowisko operacyjne i systemy zasilania jako jeden skoordynowany produkt.
Integracja nie gwarantuje jednak, że klienci wybiorą system zamknięty. Producenci i operatorzy satelitów mogą chcieć dostępu do kilku dostawców startów, procesorów, modeli i dostawców analityki.
Niezależna warstwa oprogramowania zyskuje na wartości wraz ze wzrostem różnorodności. Każdy dodatkowy kompatybilny statek kosmiczny rozszerza potencjalną pulę zasobów obliczeniowych, bez konieczności finansowania przez Satlyt własnej floty satelitów.
To ten sam efekt sieciowy, który wspierał rozwój platform programistycznych na Ziemi. Większa baza sprzętowa przyciąga programistów, a większa liczba aplikacji czyni bazową platformę bardziej atrakcyjną dla dostawców sprzętu.
Orbita stwarza trudny problem zimnego startu. Satlyt potrzebuje kompatybilnych satelitów, zanim zainwestują programiści, ale konstruktorzy statków kosmicznych potrzebują użytecznych aplikacji, zanim przeznaczą zasoby dla Satlyt.
Wczesne misje firmy mają rozwiązać ten problem za pomocą konkretnych obciążeń roboczych. NASA zapewnia przypadek użycia do walidacji, Stellerian dostarcza aplikację, a TakeMe2Space — sprzęt hostingowy.
Podejście Google stanowi inny punkt odniesienia. Project Suncatcher zakłada sieć połączonych satelitów wyposażonych w Google Tensor Processing Units, czyli TPU, zasilanych obfitą energią słoneczną.
Pierwsze kroki programu koncentrują się na własnym sprzęcie obliczeniowym Google. Prototyp, zbudowany wspólnie z Planet, zaprojektowano w celu zbadania, jak TPU reagują na siły startowe, promieniowanie i warunki termiczne w przestrzeni kosmicznej.
Google potwierdziło, że prototyp osiągnął orbitę podczas misji SpaceX Transporter-18 1 października 2026 roku. Satelita nawiązał łączność i rozpoczął program testowy.
Google sprawdza więc, czy jego wyspecjalizowane układy mogą przetrwać i działać w kosmosie. Satlyt testuje, czy oprogramowanie może uczynić różnorodne komputery orbitalne użytecznymi dla zewnętrznych klientów.
Firmy nie są dziś bezpośrednimi konkurentami. Ich architektury mogłyby nawet się uzupełniać, gdyby niezależna platforma ostatecznie uruchamiała obciążenia na procesorach zaprojektowanych przez Google lub innych wyspecjalizowanych układach.
Ich priorytety nadal ujawniają jednak konkurencyjne centra kontroli. Google zaczyna od sprzętu, który posiada i rozumie. Satlyt zaczyna od przenośności między sprzętem, którego nie kontroluje.
Jeśli przetwarzanie orbitalne będzie się rozwijać, to rozróżnienie wpłynie na marże, wybór klientów i dostęp programistów. Ostateczny zwycięzca może nie posiadać najwięcej satelitów, ale będzie wpływać na sposób, w jaki aplikacje przemieszczają się między nimi.
Otwarta Chmura Orbitalna Nadal Musi Zderzyć Się z Rzeczywistością
Najmocniejszym argumentem Satlyt jest elastyczność, lecz staje się ona obciążeniem, gdy statki kosmiczne zbyt mocno się różnią lub klienci odmawiają współdzielenia zasobów.
Firma pokazała, że mały model językowy może przetwarzać dane diagnostyczne na pokładzie sprzętu o ograniczonych zasobach. To nie to samo co obsługa rozproszonej chmury obejmującej satelity.
Kolejnym ważnym celem technicznym Satlyt jest połączenie mocy obliczeniowej dwóch różnych statków kosmicznych. Firma spodziewa się przeprowadzić tę demonstrację w przyszłym roku.
Udany test miałby znaczenie, ponieważ przetwarzanie rozproszone wymaga koordynacji między maszynami. Oprogramowanie musi dzielić pracę, przesyłać dane, radzić sobie z opóźnieniami, odzyskiwać działanie po przerwach i potwierdzać poprawność wyników.
Takie zadania są rutynowe w naziemnych centrach danych z niezawodnym zasilaniem i szybkimi sieciami. Stają się trudniejsze, gdy oba komputery krążą wokół Ziemi i komunikują się wyłącznie w określonych warunkach orbitalnych.
Opóźnienia nie są jedynym problemem. Satelity mogą mieć różne procesory, systemy operacyjne, wymagania bezpieczeństwa, dostępną moc i priorytety misji.
Łącza międzysatelitarne również mogą znacznie się różnić. Niektóre statki kosmiczne dysponują komunikacją laserową, inne korzystają z łączy radiowych, a wiele z nich nigdy nie zaprojektowano do wymiany dużych obciążeń obliczeniowych z sąsiednimi satelitami.
Google opisało precyzję wymaganą dla planowanych połączeń laserowych jako równoważną trafieniu w cel wielkości monety z odległości wielu mil, podczas gdy oba punkty się poruszają.
Testy firmy pokazują również wyzwanie sprzętowe. Google twierdzi, że komponenty podczas startu mogą doświadczać sił sięgających od 50 do 100 razy przyspieszenia ziemskiego, podczas gdy promieniowanie może zmieniać dane przechowywane w systemach elektronicznych.
Równie ważna pozostaje kontrola termiczna. Procesor wytwarza ciepło, lecz statek kosmiczny nie może chłodzić go zwykłym przepływem powietrza, ponieważ kosmos jest próżnią.
Oprogramowanie Satlyt nie jest w stanie usunąć tych fizycznych ograniczeń. Może je jedynie uwzględniać w harmonogramie, gdy statki kosmiczne udostępniają dokładną telemetrię i zapewniają platformie wystarczającą kontrolę operacyjną.
Kolejną barierę tworzy cyberbezpieczeństwo. Oprogramowanie zarządzające obciążeniami na kilku satelitach może stać się cennym celem, ponieważ naruszenie bezpieczeństwa mogłoby dotknąć wielu operatorów.
Klienci będą wymagać izolacji między aplikacjami, podpisanych aktualizacji, kontroli dostępu, zapisów audytowych i jasnego określenia uprawnień do awaryjnego wyłączania. Te zabezpieczenia zużywają dodatkowe zasoby obliczeniowe.
Wyniki AI niosą inne ryzyko. Model może nieprawidłowo podsumować błąd lub błędnie sklasyfikować obraz, zwłaszcza gdy dane wejściowe różnią się od tych wykorzystywanych podczas szkolenia i testów.
Z tego powodu obecne zastosowanie diagnostyczne Satlyt wygląda bezpieczniej niż autonomiczne sterowanie. Model może rekomendować działanie operatorom naziemnym, nie otrzymując uprawnień do zmiany zachowania statku kosmicznego.
Firma twierdzi, że operatorzy zachowają władzę decyzyjną w miarę rozwoju w kierunku wykrywania anomalii i decyzji wieloagentowych. Praktyczna granica między pomocą a kontrolą będzie wymagała starannej walidacji.
Równie niepewne są zachęty biznesowe. Właściciel satelity może dysponować niewykorzystanym czasem procesora, lecz udostępnienie go zewnętrznemu obciążeniu może wprowadzać odpowiedzialność bez generowania wystarczających przychodów.
Właściciel musi również zarezerwować pojemność dla swojej podstawowej misji. Satelita obserwacji Ziemi nie może opóźniać zdjęć klientów, ponieważ inna aplikacja zużyła energię lub zapełniła pamięć masową.
Strategia Satlyt oparta na modelu „Androida” działa tylko wtedy, gdy producenci statków kosmicznych wspierają wspólne interfejsy. Bez istotnej standaryzacji każda integracja staje się projektem inżynieryjnym szytym na miarę.
Osłabiłoby to ekonomikę niezależnej platformy. Marże na oprogramowaniu zależą od powielania tego samego produktu u wielu klientów, a nie od przebudowywania go dla każdego satelity.
Konkurencja może również nadejść ze strony firm posiadających sprzęt. SpaceX, Google, Starcloud i inne przedsięwzięcia w dziedzinie przetwarzania orbitalnego mogą udostępniać interfejsy dla programistów, zachowując jednocześnie własnościowy charakter swoich systemów bazowych.
Zarządzana zamknięta platforma może okazać się łatwiejsza do kupienia niż otwarta sieć. Klienci często akceptują zależność od dostawcy, gdy jeden podmiot oferuje prostsze wdrożenie, lepsze wsparcie i przewidywalną wydajność.
Satlyt nie wykazał więc jeszcze, że model Androida zdominuje rynek. Wykazał, że otwarta ścieżka jest wystarczająco wiarygodna, by pozyskać finansowanie i dotrzeć do aktywnych misji.
Kolejna faza musi dowieść powtarzalności. Jeden model na jednym satelicie potwierdza wykonalność, podczas gdy przenośne obciążenia działające na różnych statkach kosmicznych potwierdziłyby szerszą tezę dotyczącą platformy.
Trzy Sygnały Pokażą, Czy Satlyt Może Stać Się Platformą Orbitalną
Kolejne dowody muszą pochodzić z przetwarzania między satelitami, powracających klientów i mierzalnej wartości operacyjnej, a nie z kolejnego ambitnego porównania.
Pierwszym sygnałem jest planowana przez Satlyt demonstracja chmury wykorzystującej dwa satelity. To najbardziej bezpośredni test centralnej tezy technicznej firmy.
Obserwatorzy powinni zwrócić uwagę na potwierdzenie, że statki kosmiczne pochodzą z różnych platform. Dwa identyczne satelity obsługiwane przez jednego operatora przetestowałyby przetwarzanie rozproszone, lecz nie szeroką interoperacyjność.
Demonstracja powinna również ujawnić, jakie zadania są przenoszone między satelitami. Niewielka wymiana komunikatów ma mniejsze znaczenie niż skoordynowane przetwarzanie z udokumentowanymi opóźnieniami, zużyciem zasobów i zachowaniem podczas odzyskiwania działania.
Udana realizacja wzmocniłaby argument Satlyt, że firma może abstrahować od różnic sprzętowych. Opóźnienie lub węższa demonstracja pokazałyby, że otwarta platforma pozostaje na wcześniejszym etapie, niż sugeruje marketing.
Drugim sygnałem jest powtarzalność klientów. NASA, Stellerian i TakeMe2Space zapewniają firmie przydatne początkowe obciążenia, lecz projekty pilotażowe nie dowodzą trwałego popytu.
Mocniejszym sygnałem byłby klient rozszerzający pojedynczy eksperyment na kilka statków kosmicznych. Wskazywałoby to, że oprogramowanie stworzyło wartość wystarczającą, by przetrwać ocenę misji i proces budżetowy.
Kolejną ważną miarą jest liczba niezależnych konstruktorów statków kosmicznych integrujących Satlyt. Analogia do Androida wymaga wielu producentów, a nie kilku misji na sprzęcie jednego partnera.
Satlyt twierdzi, że ma oprogramowanie przygotowane do nawet 50 wdrożeń na statkach kosmicznych w 2026 roku. Gotowa pojemność nie jest tym samym co aktywowane wdrożenia, dlatego ukończone instalacje mają większe znaczenie.
Czytelnicy powinni rozróżniać podpisane umowy, wystrzelone systemy, aktywne obciążenia i płatne odnowienia. Każdy etap reprezentuje inny poziom dowodów komercyjnych.
Trzecim sygnałem jest wydajność operacyjna. Ograniczenie transmisji danych na Ziemię stanowi wczesną miarę, lecz klientów będą interesować także dokładność, zużycie energii, wykorzystanie pamięci i czas reakcji.
Testy Gemma oferują użyteczny punkt odniesienia. Satlyt podał, że w dwóch scenariuszach ładunki diagnostyczne były o około 64% mniejsze, a prędkość generowania przekraczała 22 tokeny na sekundę.
Szersze testy firmy analizują podczas inferencji zużycie mocy procesora wynoszące około 11 watów oraz wzrost temperatury od trzech do pięciu stopni Celsjusza. Są to pomiary przedstawione przez firmę, pochodzące z ograniczonych warunków testowych.
Przyszłe ujawnienia powinny powiązać te wyniki techniczne z efektami misji. Czy operatorzy szybciej rozwiązywali awarie, przesyłali na Ziemię cenniejsze obrazy lub ograniczali obciążenie pracy naziemnej?
Niezależne potwierdzenie miałoby większą wagę niż kolejny wewnętrzny benchmark. Dane z lotów kosmicznych od klientów lub partnerów badawczych wyjaśniłyby, czy korzyści utrzymują się poza kontrolowanymi testami.
SpaceX i Google prawdopodobnie nie będą czekać. Google już zbiera dane ze swojego orbitalnego prototypu TPU, w tym dotyczące wydajności w warunkach promieniowania i ekstremalnych temperatur.
Kolejny planowany kamień milowy obejmuje test komunikacji między dwoma satelitami. Postęp w tym zakresie wzmocniłby model pionowo skoordynowany, nawet jeśli Google nie zaoferuje szerokiej platformy komercyjnej.
SpaceX ma inną przewagę: skalę wdrożeń. Kontrola firmy nad startami i produkcją satelitów pozwala jej wprowadzać kolejne iteracje bez czekania, aż niezależni dostawcy statków kosmicznych przyjmą wspólny interfejs.
Satlyt nie może dorównać tym zasobom kapitałowym. Jego szansa polega na sprawieniu, by reszta rynku działała bardziej jak wspólna baza obliczeniowa.
Ten wzorzec sprawdził się w innych branżach. Niezależne oprogramowanie zyskuje na wartości, gdy klienci chcą mieć wybór, a żaden dostawca sprzętu nie może kontrolować całego rynku.
Kosmos nie jest jednak zwykłym rynkiem oprogramowania. Standardy niezawodności, ograniczenia fizyczne, obawy dotyczące bezpieczeństwa narodowego i długie cykle zakupowe spowalniają przyjmowanie platform.
Programiści powinni obserwować interfejsy wyłaniające się z pierwszych misji. Stabilny model aplikacji ułatwiłby tworzenie oprogramowania raz i wdrażanie go na kilku statkach kosmicznych.
Nabywcy satelitów powinni pytać, kto kontroluje aktualizacje, harmonogramowanie obciążeń, dostęp do telemetrii i odzyskiwanie działania po awarii. Te szczegóły określają, czy „otwarte” oznacza przenośne, czy jedynie kompatybilne dzięki pracy szytej na miarę.
Zespoły oceniające dowody potrzebują także uporządkowanych zapisów obejmujących raporty z misji, wyniki testów, umowy i decyzje inżynieryjne. Przeszukiwalna baza wiedzy może zachować powiązanie tych twierdzeń z dokumentami, które je potwierdzają.
Oprogramowanie orbitalne AI firmy Satlyt osiągnęło ważny próg. Ma teraz kapitał, doświadczenie z lotów, eksperymenty z klientami i wyraźnego architektonicznego przeciwnika.
Firma nie zbudowała jeszcze chmury orbitalnej obejmującej różne satelity. Nie wykazała również, że producenci oddadzą wystarczająco dużo kontroli, by niezależna platforma mogła się skalować.
To właśnie sprawia, że tę historię warto śledzić. Odrzucony pomysł nie jest już hipotetyczny, lecz jego kluczowa obietnica wciąż pozostaje nieudowodniona.
W nadchodzących miesiącach warto obserwować test z udziałem dwóch satelitów, kolejne wdrożenia oraz dane dotyczące wydajności na poziomie misji. Razem pokażą one, czy Satlyt buduje Androida dla orbity, czy wyspecjalizowane narzędzie dla niewielkiej liczby statków kosmicznych.
