Satlyt ha raccolto 8 milioni di dollari in un round iniziale per sviluppare software destinato ai computer dei satelliti. Il suo caso immediato è più circoscritto e misurabile di un enorme centro dati spaziale: analizzare telemetria, registri e immagini vicino alla fonte e inviare informazioni più utili attraverso una capacità limitata di collegamento verso terra.

L’obiettivo maggiore è rendere il calcolo portabile tra veicoli di produttori differenti. Satlyt ha esperienza di volo ed esperimenti dei clienti, ma non ha ancora dimostrato un cloud distribuito tra satelliti diversi. Separare queste tappe è essenziale per capire investimento e rischio.

Una proposta interna respinta diventa un’impresa finanziata

Il fondatore Rama Afullo ha lavorato nel cloud di Google prima di entrare nel settore Starlink di SpaceX nel 2024. Ha raccontato a TechCrunch che entrambi avevano allora respinto le sue proposte interne sul calcolo orbitale. Ha poi cofondato Satlyt, attiva a Sunnyvale, California, e Nairobi, Kenya.

Non Sibi Ventures, di Houston, ha guidato il round. Tra i suoi partner figura l’ex astronauta NASA Bernard Harris. Satlyt afferma che il software ha volato in due missioni dimostrative; l’ultimo impiego riportato utilizza hardware di calcolo satellitare dell’indiana TakeMe2Space.

La missione ospita tre carichi diversi. La NASA paga per provare protocolli cloud nello spazio. Stellerian, attiva nella sorveglianza orbitale, intende valutare l’elaborazione delle immagini, mentre TakeMe2Space vuole dimostrare di ospitare software esterno. Sono esperimenti dei clienti con scopi differenti, non la prova di un servizio orbitale condiviso maturo.

Afullo punta al 20% dei satelliti entro la fine del decennio. Satlyt dice inoltre di aver preparato software per un massimo di 50 installazioni su veicoli nel 2026. Né l’obiettivo né la capacità pronta equivalgono a installazioni attive, rinnovi pagati o quota di mercato verificata indipendentemente.

Il risultato iniziale più chiaro è un messaggio diagnostico minore

Satlyt ha installato un Gemma 3 quantizzato da un miliardo di parametri su un satellite operato da Momentus, mediante llama.cpp. La quantizzazione riduce la precisione numerica per richiedere meno memoria e calcolo. Il caso Gemma descrive analisi locale di telemetria, registri applicativi ed errori software.

In due scenari di iniezione di guasti, i dati diagnostici sono passati da 1.319 a 469 byte e da 1.318 a 464 byte, riduzioni del 64,4% e 64,8%. Il modello ha prodotto diagnosi brevi e azioni consigliate. Le velocità dichiarate superavano 22 token al secondo in quegli scenari.

Test aziendali più ampi hanno esaminato circa 11 watt di potenza del processore durante inferenza e un aumento termico di tre-cinque gradi Celsius. Sono misure fornite dall’azienda in condizioni limitate, non un profilo operativo di flotta stabilito indipendentemente. Ridurre i dati non dimostra nemmeno una diagnosi corretta per qualsiasi guasto.

Il meccanismo è semplice: riassumere un errore prima della finestra di comunicazione anziché scaricare tutti i registri grezzi. I gruppi a terra possono ricevere un rapporto più piccolo e utile. L’elaborazione delle immagini può anche scartare fotogrammi coperti da nubi o dare priorità a possibili bersagli di sorveglianza prima della trasmissione.

Sono applicazioni di calcolo periferico che non richiedono prima enormi cluster orbitali di IA. Il valore economico dipende da contratto di banda, personale ed esigenze di risposta della missione. Le prove utili collegherebbero i byte risparmiati a risoluzione più rapida, immagini di maggior valore o minor lavoro a terra, misurando anche accuratezza, energia e memoria.

Portabilità e integrazione verticale risolvono problemi diversi

Afullo paragona SpaceX a un iPhone orbitale e Satlyt ad Android. La distinzione è tra software su hardware eterogeneo e uno stack strettamente coordinato. Non afferma che le imprese abbiano dimensioni simili né che Satlyt sia già uno standard industriale aperto.

SpaceX controlla lancio, costruzione dei satelliti, connettività e gran parte dell’ambiente operativo. L’integrazione può semplificare interfacce e coordinare energia, collegamenti e processori. I clienti potrebbero accettare la dipendenza da un’unica tabella di marcia, calendario di lancio o politica di prezzo in cambio di installazione e assistenza più semplici.

Satlyt non intende costruire satelliti. Paragona la propria astrazione a VMware e Snowflake: le applicazioni dovrebbero dipendere meno da macchine fisiche specifiche. Più produttori compatibili potrebbero attirare sviluppatori e più applicazioni attirare produttori. Per ora deve risolvere l’avvio in cui entrambe le parti aspettano l’altra.

Il Project Suncatcher di Google parte da TPU propri e satelliti interconnessi a energia solare. Il prototipo con Planet verifica effetti di lancio, radiazioni e temperatura. Google ha dichiarato che il prototipo ha raggiunto l’orbita con Transporter-18 di SpaceX il 1º ottobre 2026, ha stabilito il contatto e iniziato i test.

Condividere il lancio non rende uguali gli approcci. Google prova hardware specializzato nello spazio; Satlyt verifica se clienti esterni possono usare software tra computer non suoi. Non sono necessariamente concorrenti diretti oggi e potrebbero diventare complementari.

La sicurezza dei veicoli limita lo strato condiviso

I server terrestri hanno interfacce standard, reti affidabili e manutenzione fisica. I satelliti affrontano radiazioni, cicli termici, collegamenti intermittenti, moto orbitale e limiti energetici rigidi. Processori, sistemi operativi e priorità differiscono; molti veicoli non dispongono di collegamenti pensati per scambiare grandi carichi di calcolo.

Google paragona il puntamento dei futuri collegamenti laser al colpire un bersaglio mobile grande come una moneta da chilometri di distanza. I componenti possono subire da 50 a 100 volte la gravità al lancio; le radiazioni alterare dati e il vuoto impedire il normale raffreddamento ad aria. Il software può pianificare attorno ai limiti solo con telemetria affidabile e sufficiente accesso operativo.

Un’applicazione esterna non deve consumare memoria, energia o comunicazioni necessarie a navigazione o carico principale. Isolamento, aggiornamenti firmati, controlli di accesso, registri di verifica e autorità di arresto d’emergenza sono requisiti, non opzioni. La gestione di più operatori crea anche un bersaglio informatico attraente.

L’IA può diagnosticare male un guasto o classificare erroneamente un’immagine. Raccomandare azioni al controllo a terra è diverso dal comandare un veicolo. Satlyt afferma che gli operatori manterranno il comando con il rilevamento anomalie e le decisioni multiagente; il confine va verificato nelle integrazioni reali.

Gli incentivi commerciali possono essere altrettanto difficili. Tempo processore libero non giustifica automaticamente responsabilità per carichi esterni o condizioni di ripartizione dei ricavi. Senza interfacce comuni, ogni integrazione diventa ingegneria su misura, indebolendo l’economia ripetibile del software.

Le prossime prove devono dimostrare più di un lancio

Satlyt prevede di tentare calcolo tra due veicoli diversi l’anno prossimo. Una comunicazione significativa identificherebbe piattaforme, elaborazione coordinata, latenza, risorse e recupero, non solo scambio di messaggi. Due macchine identiche possono dimostrare distribuzione senza provare un’interoperabilità ampia.

Clienti ricorrenti e costruttori indipendenti rafforzerebbero il caso commerciale. Accordi, hardware lanciato, carichi attivi e rinnovi pagati sono livelli di prova diversi. I dati più forti arriverebbero da clienti o ricercatori oltre ai test interni, mentre Google prosegue i collegamenti tra satelliti e SpaceX conserva il vantaggio di scala.

Rapporti di missione, definizioni dei test e contratti possono essere seguiti in una base di conoscenza di documenti ingegneristici. Satlyt supera la proposta, ma la promessa decisiva resta futura: calcolo portabile, sicuro ed economicamente ripetibile in flotte miste. Questo, non un’altra analogia con Android, trasformerebbe strumenti a bordo in una piattaforma orbitale.

Fonti

Esplora la directory degli strumenti →