Il lancio di Google Project Suncatcher anticipa il test del data center spaziale
Google ha anticipato al 1° ottobre il suo primo test orbitale di Project Suncatcher, facendo avanzare una parte di una missione originariamente incentrata su due satelliti nel 2027. Il lancio di Google Project Suncatcher invierà quattro acceleratori AI in orbita terrestre bassa a bordo di un razzo SpaceX.
Potrebbe sembrare l'inizio di un data center spaziale. È più corretto considerarlo un esperimento sulla sopravvivenza dell'hardware, con limiti rigorosi. Il satellite dispone di circa un kilowatt di energia solare e i suoi processori possono funzionare per circa 15 minuti prima che diventi necessario il raffreddamento.
Google sta accelerando un test, non l'intero calendario di implementazione. L'azienda prevede ancora una missione più ambiziosa con due satelliti nel 2027. Quei veicoli spaziali testeranno le connessioni ottiche necessarie per distribuire i carichi di lavoro AI su una costellazione strettamente raggruppata.
Il lancio anticipato è importante perché sostituisce le ipotesi di laboratorio con dati operativi. Esporrà le normali Google Tensor Processing Units, o TPU, a vibrazioni da lancio, radiazioni, variazioni di temperatura e raffreddamento nel vuoto.
Anche SpaceX, Starcloud, Aetherflux e altre aziende stanno esplorando il calcolo orbitale. Google, tuttavia, affronta il problema attraverso il proprio stack infrastrutturale, che include TPU, modelli Gemini, ricerca sulle reti ed esperienza nei data center.
La competizione, quindi, non riguarda chi metterà per primo un computer in orbita. Riguarda piuttosto la possibilità che il calcolo orbitale evolva da brevi dimostrazioni a un'infrastruttura affidabile e connessa in rete.
Il lancio di Google Project Suncatcher è un primo test dell'hardware
Google sta lanciando un piccolo laboratorio orbitale, non un data center di produzione.
Il satellite sperimentale, chiamato MVP, ha approssimativamente le dimensioni di un frigorifero. Contiene quattro TPU Trillium di Google, la stessa famiglia di processori utilizzata per i carichi di lavoro AI nell'infrastruttura cloud terrestre.
MVP volerà nella missione Transporter-18 di SpaceX, un volo condiviso di Falcon 9 che trasporta più carichi utili. Google ha sviluppato l'esperimento con Planet, che ha fornito una piattaforma satellitare esistente anziché richiedere un nuovo progetto di veicolo spaziale.
Questa decisione spiega come Google abbia anticipato il calendario. Il piano originario prevedeva due satelliti prototipo progettati appositamente entro l'inizio del 2027. L'aggiunta dell'hardware TPU a un veicolo spaziale Planet esistente ha creato un'opportunità più rapida per raccogliere dati di volo.
L'aggiornamento della missione di Google del 24 settembre descrive il lancio come il primo test orbitale di Project Suncatcher. La missione esaminerà se i suoi processori resistono alle condizioni meccaniche e ambientali che non possono essere sperimentate pienamente in laboratorio.
La distinzione tra test e implementazione è importante. MVP trasporta quattro TPU, mentre un data center terrestre può contenere migliaia di acceleratori. I suoi pannelli solari producono circa un kilowatt, molto al di sotto della potenza disponibile persino in una struttura server di dimensioni modeste.
Il raffreddamento limita ulteriormente l'esperimento. Le TPU eseguiranno carichi di lavoro Gemini per periodi di circa 15 minuti. Dovranno poi fermarsi mentre il radiatore del satellite dissipa il calore accumulato.
Questo schema operativo non supporta servizi AI continui. Permette invece agli ingegneri di misurare il comportamento dei processori, gli errori di memoria, il consumo energetico, le prestazioni termiche e l'integrità dei carichi di lavoro durante intervalli controllati.
La missione non dispone inoltre dei collegamenti laser centrali nell'architettura finale di Google. Un singolo satellite non può dimostrare il calcolo distribuito su una costellazione né provare che più processori orbitali possano comportarsi come un unico cluster.
Per chi cerca una spiegazione di Project Suncatcher in una frase, questo lancio pone una domanda circoscritta: l'hardware AI esistente di Google può funzionare in modo affidabile dopo aver raggiunto l'orbita?
Una risposta positiva giustificherebbe l'esperimento successivo. Non dimostrerebbe che un data center spaziale di Google sia commercialmente praticabile.
La data del 1° ottobre rappresenta quindi un'accelerazione nella raccolta delle evidenze. Google ha trovato un modo per testare prima l'hardware di volo senza cancellare il traguardo più ampio del 2027.
Questo è più significativo di una presentazione o di una simulazione. Il volo spaziale crea combinazioni di vibrazioni, radiazioni, vuoto e cicli termici che i test a terra possono approssimare, ma mai riprodurre completamente.
Il lancio offre inoltre a Google l'opportunità di individuare guasti problematici mentre il progetto rimane di piccole dimensioni. Un difetto di memoria, una carenza di raffreddamento o un problema di gestione dell'energia sarebbero meno costosi da studiare su MVP che su decine di satelliti.
Il risultato più prezioso potrebbe non essere un funzionamento ininterrotto. Informazioni dettagliate sulle modalità di guasto aiuterebbero Google a riprogettare processori, schermature, radiatori e programmi dei carichi di lavoro successivi.
Perché Google ha anticipato una parte del calendario
Il calendario rivisto riflette un'opportunità di test più rapida, non la prova che l'AI orbitale sia diventata più semplice.
Google ha annunciato Project Suncatcher nel novembre 2025 come programma di ricerca a lungo termine. La sua roadmap pubblica prevedeva il lancio entro l'inizio del 2027 di due satelliti, costruiti con Planet.
La missione di ottobre è emersa dopo che Google ha scelto di collocare il proprio hardware su un satellite Planet già in fase di sviluppo. Secondo le cronache del lancio, questo approccio ha consentito al team di evitare di attendere entrambi i prototipi personalizzati.
Il satellite subirà circa dieci minuti di intense vibrazioni e accelerazione durante il viaggio verso l'orbita terrestre bassa. Google afferma che il veicolo spaziale può affrontare carichi sostenuti prossimi a dieci volte la gravità terrestre.
I singoli componenti possono incontrare forze comprese tra 50 e 100 volte la gravità. Prima del lancio, gli ingegneri hanno sottoposto il sistema assemblato a vibrazioni lungo tre assi per riprodurre le frequenze rilevanti.
Secondo Google, questi test hanno indicato che l'hardware è rimasto integro. Tuttavia, i test a terra non possono stabilire come connessioni, memoria, materiali di raffreddamento e processori si comporteranno durante un'intera missione orbitale.
Le radiazioni creano una categoria diversa di incertezza. Le particelle ad alta energia possono danneggiare i materiali semiconduttori o creare errori transitori modificando i bit memorizzati.
Google ha esposto le TPU Trillium a un fascio di protoni da 67 megaelettronvolt mentre elaboravano carichi di lavoro AI. L'azienda afferma che la memoria ad alta larghezza di banda ha mostrato irregolarità dopo una dose cumulativa di due kilorad.
Google stima che tale livello sia quasi tre volte la dose di radiazioni schermata prevista durante una missione di cinque anni. Ha inoltre riferito di non aver rilevato guasti permanenti attribuibili alle radiazioni ionizzanti totali alla dose più elevata testata.
Si tratta di risultati di laboratorio incoraggianti, ma restano conclusioni dell'azienda. L'orbita aggiunge condizioni radiative variabili, cicli termici, comportamento dei carichi di lavoro e interazioni tra più sistemi del veicolo spaziale.
MVP può testare queste interazioni fornendo telemetria agli ingegneri sulla Terra. Il team può confrontare gli errori con gli eventi radiativi, l'intensità dei carichi di lavoro, la temperatura dei processori e le variazioni della potenza disponibile.
Anticipare questo esperimento rende inoltre la missione del 2027 meno speculativa. Google può modificare i prossimi satelliti prima del lancio se MVP rivela componenti deboli o ipotesi imprecise.
La data anticipata non significa che Google intenda lanciare una costellazione completa il prossimo anno. I due prototipi del 2027 hanno ancora uno scopo diverso: testare la comunicazione laser ad alta larghezza di banda tra satelliti in movimento.
Google ha bisogno di questi collegamenti perché i moderni sistemi AI dipendono da gruppi di acceleratori che scambiano dati rapidamente. Processori isolati non possono riprodurre il comportamento di un cluster di data center.
Questa separazione dei traguardi rende la roadmap più semplice da interpretare. La missione di ottobre testa la sopravvivenza e il funzionamento locale. La missione del 2027 dovrebbe testare il funzionamento distribuito e la connettività ottica.
Questo approccio graduale protegge inoltre Google dal trattare ogni problema come un unico enorme progetto ingegneristico. Hardware, controllo termico, volo in formazione, reti ed economia possono ciascuno fallire indipendentemente.
Il lancio di Google Project Suncatcher fa avanzare il primo livello di questa sequenza. Lascia le questioni più difficili a livello di sistema alle missioni successive.
Il meccanismo alla base del piano di data center spaziale di Google
Project Suncatcher dipende dalla combinazione di abbondante energia solare orbitale con una rete insolitamente densa di satelliti per il calcolo.
L'attrattiva inizia dalla luce solare. Un satellite in un'orbita eliosincrona adatta può rimanere illuminato per la maggior parte del suo viaggio attorno alla Terra.
Google stima che un pannello solare orbitale possa produrre fino a otto volte più energia di un pannello equivalente sulla Terra. Evita la notte, le nuvole e gran parte del filtraggio causato dall'atmosfera.
Quell'energia potrebbe supportare il calcolo AI senza collegare una struttura a una rete elettrica regionale. I sistemi orbitali eviterebbero inoltre i requisiti locali di acqua, terreno e costruzione associati ai campus terrestri.
Tuttavia, l'energia solare accessibile non crea automaticamente un data center utilizzabile. I processori devono scambiare dati, dissipare calore, comunicare con la Terra, sopravvivere alle radiazioni e rimanere abbastanza vicini per collegamenti ottici a bassa latenza.
Il progetto di sistema di Google immagina satelliti modulari che trasportano TPU e comunicano tramite collegamenti ottici nello spazio libero. Questi collegamenti trasmettono informazioni usando laser anziché cavi fisici.
I grandi carichi di lavoro AI richiedono agli acceleratori di scambiare dati a velocità estremamente elevate. L'analisi di Google afferma che le connessioni orbitali avrebbero infine bisogno di capacità misurate in decine di terabit al secondo.
L'azienda ha dimostrato 800 gigabit al secondo in ciascuna direzione utilizzando una coppia di ricetrasmettitori da laboratorio. Ciò equivale a 1,6 terabit al secondo di capacità bidirezionale combinata.
Il risultato supporta il concetto ottico, ma è avvenuto su un banco di prova. L'hardware di volo deve mantenere collegamenti comparabili mentre entrambi gli estremi si muovono a velocità orbitale.
La risposta proposta da Google è una formazione compatta di satelliti. Il suo modello pubblicato considera 81 satelliti a un'altitudine di circa 650 chilometri.
Il cluster simulato ha un raggio di un chilometro. I veicoli spaziali vicini possono transitare a una distanza di circa 100-200 metri l'uno dall'altro mantenendo la formazione pianificata.
Le brevi distanze riducono la potenza ottica necessaria per sostenere collegamenti ad alta capacità. Aumentano inoltre la precisione richiesta per navigazione, puntamento, prevenzione delle collisioni e mantenimento della posizione.
Ogni veicolo spaziale deve conoscere la propria posizione e quella dei satelliti vicini. Il suo laser deve rimanere puntato su un piccolo bersaglio in movimento mentre l'intera formazione viaggia attorno alla Terra.
Ecco perché il concetto di data center spaziale di Google differisce dal lancio di un server su un normale satellite per comunicazioni. Dipende da molti veicoli spaziali che cooperano come un unico sistema di calcolo distribuito.
La prima missione non testa questo meccanismo. MVP non trasporta un satellite gemello con cui possa stabilire la connessione proposta a corto raggio e ad alta larghezza di banda.
Fornisce invece dati sul modulo di calcolo che sarebbe collocato all'interno di ciascun nodo futuro. Google può studiare se la sua architettura TPU standard rimanga praticabile prima di progettare attorno a essa una grande rete orbitale.
Spiegare Project Suncatcher come un progetto energetico significa cogliere solo metà della storia. La disponibilità di energia solare crea l’opportunità, ma è il networking a determinare se processori distribuiti possano svolgere un lavoro collettivo utile.
Conta anche il carico di lavoro finale. L’orbita favorisce attività in grado di tollerare un funzionamento intermittente e comunicazioni limitate con la Terra.
L’addestramento, l’elaborazione scientifica e alcune forme di inferenza batch potrebbero adattarsi meglio a questo profilo rispetto alle applicazioni interattive. I servizi rivolti agli utenti richiedono latenza prevedibile, disponibilità continua e connessioni terrestri affidabili.
Google non ha annunciato un servizio commerciale, carichi di lavoro dei clienti o una tabella di marcia per il deployment. Project Suncatcher resta una ricerca sui componenti necessari per un futuro sistema.
Questa descrizione prudente è meno spettacolare che definire MVP un data center orbitale. È anche più accurata.
SpaceX e le startup trasformano il test in un segnale competitivo
Il volo iniziale di Google porta il suo hardware AI personalizzato in una competizione definita dall’accesso ai lanci, dalla progettazione termica e dai dati operativi.
Diverse aziende sono già andate oltre le slide di presentazione. Starcloud ha lanciato a novembre 2025 un satellite dotato di un processore AI Nvidia, secondo quanto riportato dall’Associated Press.
Anche Aetherflux ha descritto piani per inviare hardware di calcolo in orbita. SpaceX ha promosso infrastrutture AI orbitali, pur controllando i razzi necessari a molti potenziali concorrenti.
Questo crea per Google un avversario insolito. SpaceX è al tempo stesso un fornitore abilitante e un potenziale rivale nell’infrastruttura.
La missione di ottobre illustra questa relazione. Google si affida a un rideshare Falcon 9 per testare un’architettura che potrebbe infine competere con le ambizioni di SpaceX nel calcolo orbitale.
Il controllo dei lanci offre più del semplice trasporto. Voli frequenti consentono a un operatore di testare nuovo hardware, sostituire satelliti guasti e rivedere più rapidamente i progetti.
Un data center orbitale non può usare tecnici per sostituire processori danneggiati. I componenti guasti devono restare inutilizzati, essere sostituiti da hardware ridondante oppure attendere un altro lancio.
La competizione orbitale premia quindi le aziende che combinano competenza nel calcolo con produzione di veicoli spaziali e accesso economico all’orbita.
Google porta con sé risorse importanti. Progetta TPU, gestisce grandi cluster AI, sviluppa modelli Gemini e conduce ricerche sul calcolo distribuito.
Planet contribuisce con ingegneria satellitare collaudata in volo e una piattaforma spaziale disponibile. SpaceX fornisce il veicolo di lancio e la missione rideshare.
L’accordo consente a Google di apprendere rapidamente senza integrare verticalmente ogni parte della missione. Rivela inoltre quanto il calcolo orbitale iniziale resti dipendente dalle partnership.
La questione competitiva non è semplicemente se le TPU superino in orbita le GPU Nvidia. Nessun test orbitale pubblico rappresenta ancora la scala, il carico di raffreddamento o le esigenze di rete di un campus AI terrestre.
Ogni esperimento mette l’accento su un livello diverso. Alcuni testano la sopravvivenza dei processori. Altri si concentrano sull’inferenza edge, sull’elaborazione dell’osservazione terrestre, sulle comunicazioni o sulla generazione di energia.
La scommessa distintiva di Google è una costellazione di TPU densamente connessa. Se funzionasse, il sistema distribuirebbe compiti di machine learning su numerosi nodi alimentati dal sole.
SpaceX ha un vantaggio nella cadenza dei lanci e nella produzione di veicoli spaziali. Le startup basate su Nvidia possono attingere a un ecosistema software molto diffuso. Google controlla sia il processore sia lo stack di modelli che intende testare.
Questi punti di forza non risolvono l’economia del progetto. Un’azienda deve comunque lanciare pannelli solari, radiatori, hardware per le comunicazioni, schermature, strutture e capacità di sostituzione insieme ai processori.
Il test di ottobre non confronterà questi sistemi completi. Indicherà se Google può abbreviare il proprio ciclo di apprendimento utilizzando veicoli spaziali esistenti e lanci condivisi.
Questa velocità conta perché l’infrastruttura orbitale si sviluppa attraverso missioni fisiche ripetute. Il software può cambiare rapidamente dopo il deployment, ma radiatori, schermature e pannelli solari no.
Un volo MVP riuscito fornirebbe a Google informazioni proprietarie sul comportamento delle TPU in orbita. I concorrenti otterrebbero il risultato pubblico, ma non la telemetria completa né l’analisi ingegneristica.
Anche un fallimento sarebbe informativo. Potrebbe rivelare che gli acceleratori terrestri richiedono più modifiche di quanto suggerissero i risultati dei test di radiazione in laboratorio.
Il lancio di Google Project Suncatcher esercita quindi pressione sia sulle aziende aerospaziali consolidate sia sulle startup del calcolo orbitale. Mostra che Google è disposta a far volare hardware prima che la sua architettura preferita sia completa.
Tuttavia, la missione non stabilisce un vincitore. La corsa resta un insieme di piccoli esperimenti che perseguono definizioni diverse di calcolo orbitale utile.
Raffreddamento e affidabilità restano la prova più difficile
La contraddizione centrale è semplice: l’orbita offre abbondante luce solare, ma ogni watt utilizzato per il calcolo diventa infine calore di scarto.
Lo spazio può essere estremamente freddo, ma il vuoto impedisce al calore di muoversi attraverso la normale convezione. Un veicolo spaziale deve trasferire il calore dei processori ai radiatori, che rilasciano energia sotto forma di radiazione infrarossa.
MVP utilizza materiale di interfaccia termica, heat pipe metalliche e un radiatore. L’interfaccia trasferisce il calore dalle TPU verso le pipe, che lo spostano a una superficie radiante esposta.
Google prevede che il sistema supporti circa 15 minuti di elaborazione Gemini alla volta. I processori devono poi fermarsi mentre il radiatore recupera.
Questo ciclo di lavoro è adatto a un esperimento. Un servizio di produzione richiederebbe un throughput molto più costante oppure un sistema di pianificazione costruito attorno a pause termiche ricorrenti.
Il Government Accountability Office degli Stati Uniti identifica alimentazione e raffreddamento come ostacoli principali ai data center orbitali. La sua valutazione tecnica afferma che deployment di grandi dimensioni richiederebbero pannelli solari superiori a qualunque struttura assemblata nello spazio entro aprile 2026.
Il progetto illustrativo dell’agenzia abbina un array solare di 10.000 piedi quadrati a fino a 5.000 piedi quadrati di radiatori. Anche quel sistema fornirebbe soltanto alcune centinaia di kilowatt.
Un grande data center terrestre può consumare circa 100 megawatt. Riprodurre tale capacità richiederebbe molte unità orbitali, un’intensa attività di lancio e una rete capace di coordinarle.
Il raffreddamento non è l’unico problema di affidabilità. Le radiazioni possono corrompere i calcoli o degradare i componenti nel tempo.
I test di Google con fasci di protoni forniscono evidenze utili, ma la memoria ad alta larghezza di banda è risultata la parte più sensibile del pacchetto TPU. La memoria è essenziale perché i modelli AI spostano continuamente grandi quantità di dati tra archiviazione e processori.
Un sistema può sopravvivere senza subire un guasto permanente del chip e produrre comunque tassi di errore inaccettabili. Google deve determinare se le radiazioni causano errori silenziosi, carichi di lavoro interrotti o un crescente overhead di correzione.
Le vibrazioni del lancio creano un ulteriore punto di guasto. Connessioni elettriche, heat pipe, componenti ottici e pacchetti di memoria devono tutti rimanere allineati dopo aver subito forze intense.
Poi c’è la manutenzione orbitale. Un operatore terrestre può sostituire server guasti, riparare pompe, pulire apparecchiature e aggiungere nuovi acceleratori.
Un cluster orbitale deve affidarsi a ridondanza, manutenzione robotica o lanci programmati per la sostituzione. Ogni opzione aggiunge massa e complessità operativa.
I detriti creano un rischio pubblico più ampio. L’architettura futura di Google colloca numerosi satelliti in una formazione ravvicinata mentre altri veicoli spaziali attraversano l’orbita terrestre bassa.
Un’analisi dei rischi di formazione osserva che grandi array e cluster densi possono complicare la gestione delle collisioni. Un satellite danneggiato può inoltre creare frammenti che minacciano veicoli spaziali non correlati.
Gli astronomi potrebbero sollevare obiezioni separate se grandi costellazioni di calcolo riflettessero luce o interferissero con le osservazioni. Le autorità di regolamentazione avranno bisogno di informazioni sulla posizione orbitale, la manovrabilità, i piani di smaltimento e l’uso radio.
La missione di ottobre è troppo piccola per rispondere a queste domande. Un singolo satellite compatto non riproduce l’impronta dei detriti né le esigenze di coordinamento di un cluster da 81 nodi.
Non può nemmeno convalidare le ipotesi economiche più ottimistiche di Google. Il progetto dipende da costi di lancio inferiori, durate accettabili dell’hardware e un elevato utilizzo dell’intera costellazione.
I processori sottoutilizzati occuperebbero comunque massa, consumerebbero energia e richiederebbero raffreddamento. Un’architettura di successo necessita di carichi di lavoro adatti in quantità sufficiente per mantenere produttivo il costoso hardware orbitale.
Questo è il compromesso essenziale. Lo spazio elimina alcuni vincoli terrestri sostituendoli con vincoli termici, di manutenzione, rete e lancio.
Il lancio di Google Project Suncatcher dovrebbe rendere misurabile una parte di questo compromesso. Non farà scomparire il compromesso.
Tre segnali mostreranno se Suncatcher può scalare
Le prossime tappe devono dimostrare funzionamento sostenuto, calcolo distribuito e una scalabilità credibile, non semplicemente un altro lancio riuscito.
Il primo segnale è il record operativo di MVP dopo il 1° ottobre. Google dovrebbe comunicare se tutte e quattro le TPU si avviano correttamente, con quale frequenza funzionano e se i loro risultati corrispondono a carichi di lavoro equivalenti eseguiti a terra.
I dati termici conteranno quanto la sopravvivenza dei processori. Sessioni più lunghe o frequenti suggerirebbero che il progetto con heat pipe e radiatore si avvicina alle aspettative.
Arresti inattesi non porrebbero fine al progetto, ma identificherebbero il componente che limita i progressi. Errori da radiazione, alimentazione instabile, calore eccessivo o connessioni danneggiate richiedono rimedi diversi.
I lettori dovrebbero inoltre osservare quante informazioni Google renderà pubbliche. Un’affermazione secondo cui il satellite è in buona salute offrirebbe meno evidenze rispetto a risultati sui carichi di lavoro, temperature, tassi di errore e confronti con i modelli pre-volo.
Il secondo segnale è la prevista missione con due satelliti nel 2027. Tale esperimento deve dimostrare un collegamento ottico tra veicoli spaziali che si muovono in modo indipendente.
La sola larghezza di banda non basterà. Google deve dimostrare che i suoi sistemi possono acquisire il collegamento, mantenere un puntamento preciso, riprendersi dalle interruzioni e coordinare un lavoro distribuito utile.
Il transceiver di laboratorio dell’azienda ha raggiunto 800 gigabit al secondo in ciascuna direzione. Riprodurre un throughput elevato tra satelliti sosterrebbe il meccanismo centrale di networking alla base di Suncatcher.
L’incapacità di mantenere un collegamento stabile indebolirebbe il progetto della costellazione densa. Google potrebbe aver bisogno di una spaziatura diversa, sistemi ottici più grandi, maggiore buffering a bordo o carichi di lavoro meno intensivi in termini di comunicazione.
Il terzo segnale è l’evidenza di un percorso oltre i prototipi. Ciò include un carico di lavoro definito, un’architettura termica credibile, una strategia di sostituzione e un piano regolatorio.
Un data center spaziale di Google non deve eguagliare subito un campus terrestre. Deve però offrire un’attività che l’orbita svolga abbastanza meglio da giustificare la complessità aggiunta.
Il lavoro AI batch potrebbe diventare un candidato iniziale perché tollera ritardi nella pianificazione. L’elaborazione di dati già generati nello spazio potrebbe ridurre la necessità di inviare informazioni grezze alla Terra.
Le applicazioni consumer interattive rappresentano un obiettivo più difficile. Richiedono capacità costante, bassa latenza e collegamenti affidabili tra hardware orbitale e reti terrestri.
Google dovrebbe anche spiegare come ritirerà i veicoli spaziali guasti e controllerà il rischio di collisione. Scalare senza un piano di smaltimento trasferirebbe la pressione dell’infrastruttura dei data center in un ambiente orbitale già affollato.
L’esito più credibile nel prossimo anno non è una costellazione commerciale. È una sequenza di misurazioni pubblicate che riduca l’elenco delle incognite.
Guardate la missione con questo spirito. Chiedetevi se le TPU producono risultati corretti, se il sistema di raffreddamento supporta cicli operativi utili e se i satelliti del 2027 scambiano carichi di lavoro reali.
Se Google fornirà queste risposte, Project Suncatcher passerà da un'ambiziosa proposta di ricerca verso un programma ingegneristico. Se offrirà soltanto immagini del lancio e affermazioni generiche, l'ipotesi centrale resterà non dimostrata.
Il volo del 1° ottobre offre a Google un'occasione anticipata per sostituire le proiezioni con prove concrete. Questo è il vero significato del lancio di Google Project Suncatcher e il criterio in base al quale valutarne i progressi.
