Data Centers Espaciais do Google Chegaram à Órbita, mas Precisam de 1.800 Lançamentos da Starship para Escalar

Os data centers espaciais do Google deixaram de ser apenas um artigo de pesquisa em 1º de outubro, quando a empresa enviou quatro chips de IA para a órbita. Ainda assim, o experimento também expôs um conflito muito maior. O modelo econômico do Google pressupõe que a SpaceX consiga lançar a Starship cerca de 1.800 vezes em uma década.

Essa estimativa equivale a aproximadamente 180 lançamentos por ano, supondo que cada missão transporte 200 toneladas métricas. A Starship só alcançou a órbita terrestre pela primeira vez poucos dias antes do lançamento do satélite do Google. Portanto, a SpaceX precisa transformar um foguete ainda em desenvolvimento em uma rede industrial de transporte antes que a economia projetada pelo Google funcione.

O pequeno satélite não resolve essa questão. Ele testa se as Tensor Processing Units, ou TPUs, do Google conseguem sobreviver à radiação, à vibração do lançamento e a variações extremas de temperatura. A missão também examina se esses chips podem operar sem o resfriamento baseado em ar disponível nos data centers terrestres.

O Google chama a iniciativa mais ampla de Project Suncatcher. Seu sistema proposto colocaria satélites de computação movidos a energia solar em órbita baixa da Terra e os conectaria por enlaces ópticos. O atrativo é a abundância de energia solar, mas as barreiras práticas incluem custo de lançamento, dissipação de calor, comunicações, manutenção e coordenação orbital.

A SpaceX é, ao mesmo tempo, a fornecedora essencial e a dependência mais difícil desse plano. O Google pode aprimorar internamente chips, software e projetos de satélites. Mas não pode criar transporte orbital barato sem que um provedor de lançamentos alcance reutilização em uma escala sem precedentes.

Os Data Centers Espaciais do Google Começam com Quatro Chips, Não uma Nuvem Orbital

O Google lançou um experimento de hardware, não um substituto funcional para um data center baseado na Terra.

A primeira espaçonave do Project Suncatcher, chamada MVP, foi lançada da Califórnia na missão compartilhada Transporter-18 da SpaceX. Um Falcon 9 a levou junto com outras 129 cargas úteis, segundo uma visão geral da missão orbital.

O satélite foi construído em parceria com a Planet, empresa de imageamento da Terra. O Google forneceu o hardware de computação, incluindo quatro TPUs. Uma TPU é o acelerador personalizado do Google para treinamento e inferência de aprendizado de máquina.

A espaçonave, do tamanho de uma geladeira, recebe cerca de um quilowatt de seus painéis solares. Esse fornecimento de energia é minúsculo diante das exigências de uma instalação comercial de IA. Grandes sistemas terrestres usam milhares de aceleradores, apoiados por ampla infraestrutura de rede, armazenamento, resfriamento e equipamentos elétricos.

O MVP executará cargas de trabalho do Gemini para testar como o hardware se comporta em órbita. Segundo relatos, o satélite consegue operar seus processadores por cerca de 15 minutos antes de pausar para liberar o calor acumulado. Esse padrão operacional faz dele um instrumento científico, e não um serviço de computação continuamente disponível.

A missão acelerou o cronograma original do Google. A empresa havia descrito anteriormente uma missão de aprendizado com dois satélites, em parceria com a Planet, para o início de 2027. A integração dos chips a uma espaçonave Planet já existente permitiu ao Google coletar dados orbitais mais cedo.

O Google afirma que o satélite avaliará os estresses físicos do lançamento e as condições térmicas e de radiação encontradas no espaço. Essas medições devem fornecer aos engenheiros evidências que as simulações em solo não conseguem reproduzir plenamente.

A distinção é importante porque a expressão “data center espacial” pode sugerir uma instalação madura executando cargas de trabalho de clientes. O MVP está mais próximo de um laboratório compacto. Sua função é identificar modos de falha antes que o Google se comprometa com uma arquitetura de satélites maior.

Ainda assim, esse lançamento altera o status do Project Suncatcher. O projeto agora tem hardware exposto a condições orbitais reais, e não apenas a simulações. Essas evidências podem confirmar premissas, revelar falhas inesperadas ou forçar o Google a redesenhar o sistema.

O teste também ocorreu em um momento significativo para a SpaceX. A Starship alcançou a órbita terrestre pela primeira vez em 28 de setembro e então implantou 26 satélites Starlink. O estágio superior perdeu um motor e retornou antes do planejado, mas a missão estabeleceu uma capacidade necessária.

O satélite do Google não voou na Starship. O Falcon 9 realizou a missão. No entanto, o Falcon 9 não oferece a economia de carga útil nem o volume que o Google espera que uma rede completa de computação orbital exija.

É por isso que o pequeno experimento aponta imediatamente para uma questão de infraestrutura muito maior. Quatro chips podem compartilhar uma missão compartilhada. Milhares de satélites carregando sistemas de computação densos exigem uma operação de lançamento radicalmente diferente.

Por que o Project Suncatcher Precisa da Economia da Starship

O Project Suncatcher depende de preços de lançamento em queda graças à repetição, reutilização e a um enorme volume cumulativo de carga útil.

A pesquisa do Google estima que o transporte para a órbita baixa da Terra poderia se aproximar de US$ 200 por quilograma em meados da década de 2030. A estimativa vem de uma curva de aprendizado baseada nos preços históricos de lançamento da SpaceX e na massa cumulativa de carga útil.

Uma curva de aprendizado relaciona experiência de fabricação à queda do custo unitário. Os pesquisadores do Google estimam que a SpaceX alcançou uma redução de cerca de 20% no preço por quilograma sempre que sua massa lançada acumulada dobrou.

Estender esse padrão à Starship produz o número mais surpreendente do projeto. A SpaceX precisaria entregar cerca de 370.000 toneladas métricas adicionais em órbita para sustentar a trajetória presumida.

Com 200 toneladas métricas por missão, isso equivale a aproximadamente 1.800 lançamentos da Starship. Em uma média de dez anos, a exigência se torna cerca de 180 missões anuais. Os primeiros anos provavelmente ficariam abaixo dessa média, obrigando as operações posteriores a avançar ainda mais rápido.

Esses números vêm do artigo sobre computação orbital do Google. Os pesquisadores enfatizam que seu trabalho não é um estudo completo de viabilidade econômica. Em vez disso, o cálculo mostra o que precisa acontecer para que os preços de lançamento deixem de dominar a justificativa comercial.

O limite de US$ 200 importa porque o Google compara os custos de entrega orbital com a despesa recorrente de energia dos data centers terrestres. Nesse preço de lançamento, os custos de transporte ajustados ao longo da vida útil de satélites eficientes poderiam entrar na ampla faixa dos custos de eletricidade na Terra.

Essa comparação tem limites. Ela exclui várias despesas que determinam se um serviço real é competitivo. Os satélites precisam ser projetados, fabricados, segurados, operados, conectados, reparados por meio de redundância e, por fim, substituídos.

O artigo também pressupõe que as melhorias históricas de preço possam continuar durante uma grande mudança no projeto do veículo. Falcon 9 e Starship não compartilham sistemas de produção, padrões operacionais nem perfis de risco idênticos. Uma tendência extraída de foguetes anteriores não pode garantir o desempenho futuro da Starship.

A análise do Google reconhece essa incerteza. Ela afirma que a estimativa depende de alta reutilização, volume cumulativo, execução técnica, concorrência de mercado e condições regulatórias. Portanto, uma projeção de preço é um resultado condicional, não uma oferta comercial cotada.

A empresa também examina um caminho de menor volume. Se o crescimento da carga útil ficar cerca de 70% abaixo da estimativa central, os preços de lançamento ainda poderiam chegar a aproximadamente US$ 300 por quilograma. Esse resultado poderia melhorar a economia orbital sem cumprir o cenário completo de 1.800 lançamentos.

No entanto, preços de lançamento mais baixos, por si só, não criam demanda. A SpaceX precisa de clientes com carga útil suficiente para preencher missões repetidas da Starship. A computação orbital poderia se tornar um desses clientes, mas somente se lançamentos baratos primeiro tornarem os sistemas de computação plausíveis.

Isso cria uma dependência circular. Os data centers espaciais precisam de capacidade de lançamento barata para escalar. A Starship precisa de enorme demanda por lançamentos para percorrer a curva de custo projetada.

O Google não está apenas esperando por foguetes mais baratos. O próprio Project Suncatcher poderia fornecer parte da massa necessária para tornar esses foguetes mais baratos. Essa possibilidade coloca Google e SpaceX em uma relação de dependência mútua, e não em um contrato convencional de fornecedor.

Consequentemente, a contagem de lançamentos é mais do que uma estatística chamativa. Ela é o mecanismo que conecta um experimento com quatro chips à economia de uma futura rede orbital.

Google Versus a Realidade da Cadência de Lançamentos

O principal adversário não é outro provedor de nuvem. É a distância entre as ambições de lançamento da SpaceX e uma cadência operacional de 180 missões anuais.

O primeiro voo orbital da Starship foi um marco importante, mas alcançar a órbita uma vez é diferente de operar centenas de vezes por ano. A SpaceX precisa repetir lançamentos com segurança, reutilizar ambos os estágios do veículo, reduzir o trabalho de reforma e manter vários locais de lançamento.

A missão de setembro ilustrou essa diferença. A Starship implantou sua carga útil com sucesso, mas um motor do estágio superior parou de funcionar. A SpaceX também encurtou o voo planejado e trouxe o veículo de volta após cerca de três horas.

Voos de desenvolvimento são concebidos para revelar problemas. Uma falha de motor não invalida o veículo nem a pesquisa do Google. Mas mostra por que uma cadência confiável não pode ser inferida apenas da capacidade de carga útil.

Um sistema que voe 180 vezes por ano tem uma média de quase um lançamento a cada dois dias. Essa média precisa incluir o tempo necessário para inspeções, integração de carga útil, atrasos climáticos, aprovações regulatórias, manutenção das plataformas e respostas a anomalias.

O número também pressupõe que cada voo consiga entregar 200 toneladas métricas. A carga útil real depende da configuração do veículo, da órbita, dos planos de recuperação e dos requisitos da missão. Uma carga útil média menor exigiria mais lançamentos para entregar a mesma massa cumulativa.

A SpaceX descreveu taxas de voo de longo prazo muito mais altas. Elon Musk já discutiu a possibilidade de, no futuro, realizar milhares de voos anuais da Starship. Essas declarações estabelecem a ambição da empresa, mas não fornecem evidências de que o sistema operacional já exista.

O progresso recente reforça o argumento de que a Starship pode se tornar um lançador comercial. Sua missão orbital implantou 26 satélites Starlink V3, enquanto o propulsor completou um pouso simulado próximo à costa. A SpaceX está desenvolvendo o veículo em torno de reutilização rápida, em vez de hardware descartável.

A Starlink oferece à SpaceX uma fonte interna de demanda. A empresa pode lançar seus próprios satélites de comunicação enquanto aprimora as operações da Starship. Essa integração vertical ajudou o Falcon 9 a acumular experiência de voo e poderia apoiar a cadência inicial da Starship.

Os data centers orbitais imporiam exigências diferentes. Satélites de computação transportam hardware de gerenciamento térmico, grandes painéis solares, equipamentos de comunicação óptica e processadores caros. Eles precisam alcançar formações orbitais precisas, em vez de simplesmente integrar uma constelação de banda larga.

O Google também é investidor da SpaceX, o que alinha alguns interesses. Ainda assim, o investimento não elimina a dependência técnica. O cronograma do Google continua vinculado a um sistema de transporte que ele não projeta nem controla.

Outros provedores de lançamento poderiam reduzir essa exposição no futuro. Blue Origin, Rocket Lab e futuros concorrentes de lançamentos pesados podem pressionar os preços para baixo. Nenhum oferece atualmente um substituto comprovado que iguale a combinação pretendida pela Starship de volume de carga útil e reutilização total.

O Falcon 9 continua confiável para protótipos, mas o modelo do Google identifica limites de volume que o tornam inadequado para uma implantação massiva. Isso cria uma transição desconfortável. O foguete existente pode testar a ideia, enquanto o foguete inacabado precisa torná-la econômica.

A estimativa de 1.800 lançamentos foi inicialmente informada de forma incorreta como 1.600 na manchete e na URL da fonte. A correção publicada confirma 1.800 como o número calculado no estudo.

Essa correção importa porque reforça a escala do desafio. Duzentos lançamentos adicionais representam mais de um ano na cadência média exigida.

A evidência decisiva virá das operações, não das projeções. A SpaceX precisa demonstrar tempos menores de preparação entre voos, reutilização repetida de veículos, entrega confiável de cargas úteis e expansão da capacidade dos locais de lançamento. Até lá, a curva de custos do Google permanece um cenário tecnicamente fundamentado.

Um Cluster de IA com 81 Satélites Precisa Se Comportar Como Um Computador

Transporte barato resolve apenas o primeiro problema, porque a IA distribuída também exige voo em formação preciso e comunicações de nível de data center.

A arquitetura proposta pelo Google usa grupos de 81 satélites. Um cluster ilustrativo orbitariam a uma altitude média próxima de 650 quilômetros e caberia em um raio de um quilômetro.

Os satélites manteriam separações de aproximadamente 100 a 200 metros em relação aos parceiros próximos. Essa geometria precisa permanecer estável enquanto cada espaçonave viaja ao redor da Terra em velocidade orbital.

Cargas de trabalho de aprendizado de máquina envolvem trocas frequentes entre aceleradores. Treinar um modelo grande exige que os processadores sincronizem dados e resultados intermediários com baixa latência. Conexões lentas ou inconsistentes podem deixar chips caros aguardando informações.

Data centers terrestres resolvem isso com fibra óptica e switches especializados. O Project Suncatcher substitui essas conexões fixas por enlaces ópticos no espaço livre, que transmitem dados por feixes de laser direcionados com precisão.

O Google demonstrou 800 gigabits por segundo em uma direção em um curto percurso de laboratório. A capacidade bidirecional chegou a 1,6 terabits por segundo. Esse teste sustenta o conceito subjacente de comunicações, mas não reproduziu uma formação orbital completa em movimento.

Uma constelação real precisa apontar múltiplos feixes com precisão enquanto os satélites mudam de posição. O sistema precisa lidar com vibrações, variações de temperatura, degradação de componentes, desvio de detritos orbitais e falhas dentro do cluster.

O Google propõe modelos de aprendizado de máquina para ajudar a prever o movimento orbital e controlar a formação. Essa abordagem poderia manter satélites vizinhos dentro do alcance de comunicação. Ela também acrescenta requisitos de garantia de software a um sistema físico já complexo.

A conectividade com o solo apresenta outra limitação. A largura de banda entre satélites não elimina a necessidade de transportar entradas e saídas entre a Terra e a órbita. Turbulência atmosférica, nuvens, rastreamento de feixes e disponibilidade de estações terrestres podem restringir as comunicações ópticas.

Algumas cargas de trabalho se adaptam melhor a essa arquitetura do que outras. Processar dados já coletados em órbita poderia reduzir o volume transmitido à Terra. A análise de imagens de satélite é um exemplo óbvio, pois as informações brutas começam perto dos processadores.

Grandes trabalhos de treinamento terrestres representam um caso mais difícil. Seus conjuntos de dados podem se originar em sistemas de armazenamento baseados no solo. Enviar esse material, coordenar milhares de processadores e recuperar os resultados pode eliminar parte das vantagens da energia solar abundante.

As cargas de trabalho de inferência podem se mostrar mais tolerantes. Inferência significa executar um modelo treinado para produzir uma resposta, classificação ou previsão. Essas tarefas podem ser menores e exigir menos sincronização do que longas execuções de treinamento.

Os testes de radiação do Google sustentam essa distinção. Seus pesquisadores afirmam que as TPUs Trillium suportaram uma dose ionizante equivalente a uma missão de cinco anos sem falha permanente. Ainda assim, partículas de alta energia podem causar erros computacionais temporários.

Um pesquisador disse ao TechCrunch que uma inferência típica poderia encontrar um erro aproximadamente a cada milhão de operações. A mesma taxa se torna mais preocupante quando milhares de chips coordenam uma execução de treinamento que dura vários meses.

O software pode detectar e repetir alguns cálculos defeituosos. Processadores redundantes também podem substituir a capacidade que falhou. Ambas as respostas consomem energia, hardware ou tempo, enfraquecendo o argumento econômico.

Portanto, o cluster proposto não é simplesmente um rack de servidores colocado acima da Terra. Trata-se de um supercomputador distribuído cuja rede, fonte de energia, sistema de resfriamento e disposição física permanecem em movimento constante.

Explicado nesse nível de sistemas, o Project Suncatcher se parece menos com a transferência de uma região convencional de nuvem. Ele se assemelha ao projeto de uma nova plataforma de computação em torno das restrições da mecânica orbital.

Resfriamento e Manutenção Podem Comprometer o Caso de Negócio

Os riscos mais difíceis continuam sendo a remoção de calor e a manutenção, porque o espaço oferece luz solar sem fornecer ar, água ou técnicos.

A energia solar é o maior atrativo do Project Suncatcher. O Google afirma que satélites em órbitas baixas da Terra adequadas podem receber até oito vezes mais energia solar do que painéis em locais comparáveis na Terra.

O acesso à luz solar evita algumas restrições das redes terrestres. Novos data centers baseados na Terra podem esperar anos por atualizações de transmissão, acordos de geração de energia, licenças e aprovação local. Sistemas orbitais gerariam eletricidade diretamente ao lado de seus processadores.

No entanto, a energia que entra em um chip acaba se transformando em calor. Na Terra, as instalações removem esse calor com ar, água, refrigerantes, bombas, torres de resfriamento e trocadores de calor. Um vácuo não tem ar capaz de transportar o calor.

As espaçonaves precisam, em vez disso, conduzir o calor dos processadores até radiadores. Essas superfícies liberam energia como radiação infravermelha. A área necessária cresce com a quantidade de calor gerada e com as temperaturas que o hardware consegue tolerar.

O MVP do Google destaca essa limitação. Seus quatro chips podem operar apenas por breves intervalos antes de o sistema pausar para resfriamento. Escalar de experimentos de 15 minutos para operação comercial contínua exige hardware térmico muito maior ou mais eficiente.

Radiadores acrescentam massa e área de superfície. Mais massa aumenta os requisitos de lançamento, enquanto estruturas maiores complicam a implantação e a prevenção de colisões. A blindagem protetora cria a mesma penalidade quando engenheiros a usam contra a radiação.

Uma avaliação térmica independente identifica essa troca em várias propostas de computação orbital. Aceleradores convencionais de IA fornecem o desempenho necessário, mas não foram projetados como componentes de espaçonaves resistentes à radiação.

Blindar chips acrescenta peso. Deixá-los expostos aumenta os erros e possíveis falhas. Hardware redundante melhora a confiabilidade, mas enviar processadores sobressalentes à órbita eleva novamente os requisitos de massa, energia e resfriamento.

A manutenção é igualmente implacável. Técnicos substituem rotineiramente unidades de armazenamento defeituosas, equipamentos de rede, fontes de alimentação e placas aceleradoras em instalações terrestres. Um cluster orbital não pode depender de visitas humanas de manutenção de rotina.

O artigo do Google propõe o provisionamento redundante como a resposta mais simples. Isso significa lançar mais capacidade do que o sistema precisa inicialmente e, depois, contornar as falhas.

A redundância mantém um serviço em funcionamento, mas altera a utilização. O hardware sobressalente ainda envolve custos de fabricação e lançamento. Alguns componentes podem permanecer ociosos até que outro componente falhe.

A vida útil dos satélites introduz outra limitação. O Google avalia a exposição à radiação ao longo de cinco anos. Uma instalação terrestre pode substituir processadores em etapas, enquanto um satélite pode reunir computação, energia, resfriamento e comunicações em um único ativo de vida limitada.

Os rápidos ciclos do hardware de IA complicam esse modelo. Um satélite lançado com processadores atuais pode se tornar menos eficiente do que chips terrestres mais novos muito antes de a radiação encerrar sua missão. Substituí-lo exige outro lançamento, em vez de uma troca de servidor.

A desorbitação de equipamentos antigos também precisa fazer parte do projeto do sistema. Um cluster de 81 satélites é administrável apenas se unidades com falha puderem deixar a órbita com segurança. A implantação em grande escala multiplica as preocupações com colisões e detritos.

Esses problemas não provam que a computação orbital seja impossível. Eles mostram por que um único teste bem-sucedido de chip não pode validar um serviço comercial. O Google precisa medir taxas de erro, desempenho térmico sustentado, disponibilidade de energia e degradação dos componentes ao longo do tempo.

A missão MVP é valiosa justamente porque uma falha seria informativa. Descobrir agora um limite de temperatura ou padrão de radiação custa menos do que encontrá-lo após implantar um cluster inteiro.

O enquadramento público do Google permanece apropriadamente cauteloso. Sua atualização do Project Suncatcher chama o satélite de teste inicial e identifica o resfriamento como um desafio crucial de pesquisa.

Essa prudência separa o programa de pesquisa de alegações mais agressivas sobre capacidade de nuvem orbital no curto prazo. O teste fornece evidências, mas ainda não estabelece cargas de trabalho contínuas, custos competitivos ou uma estratégia de manutenção implantável.

Três Sinais Decidirão se a Computação Espacial Pode Escalar

As próximas evidências precisam conectar um experimento bem-sucedido à computação repetível, a lançamentos reutilizáveis e a um caminho crível além de um satélite.

O primeiro sinal são os dados de operação sustentada do MVP. O Google precisa divulgar com que frequência as TPUs operam, com que rapidez o calor se acumula e como a radiação afeta a precisão da inferência.

Sessões curtas bem-sucedidas confirmariam que aceleradores convencionais podem operar em órbita. Sessões mais longas com resfriamento previsível forneceriam evidências mais fortes. Desligamentos frequentes ou erros inexplicáveis enfraqueceriam o argumento para clusters orbitais densos.

Os leitores também devem acompanhar se o Google publica resultados de inferência do Gemini, em vez de apenas medições da integridade do hardware. Um chip funcional é necessário, mas o desempenho útil em cargas de trabalho é o marco mais significativo.

O segundo sinal é o progresso rumo à missão multissatélite planejada pelo Google. Duas ou mais espaçonaves podem testar enlaces ópticos, coordenação e cargas de trabalho distribuídas que um único satélite não consegue reproduzir.

O Google havia anteriormente definido o início de 2027 como meta para dois satélites protótipos com a Planet. Qualquer cronograma, projeto ou objetivo de missão atualizado mostrará como as lições do MVP afetam esse plano.

Uma demonstração multissatélite deve revelar a estabilidade das conexões, a precisão do rastreamento de feixes e o efeito do movimento orbital sobre a coordenação das cargas de trabalho. Essas medições começariam a testar o Project Suncatcher como um sistema.

O terceiro sinal é a cadência real de lançamentos e o histórico de reutilização do Starship. A economia do Google se torna mais crível quando a SpaceX voa repetidamente com hardware recuperado, reduz os tempos de preparação entre voos e expande as operações de carga útil.

Uma missão orbital não estabelece uma curva de custos. Uma sequência de voos comerciais confiáveis forneceria a evidência relevante. Reutilizar ambos os estágios importaria mais do que atingir outro marco isolado de voo.

A capacidade de carga útil também precisa passar de uma meta de projeto para desempenho operacional. O cálculo de 1.800 lançamentos do Google pressupõe 200 toneladas métricas por voo. Uma capacidade demonstrada menor altera o número de missões necessárias.

Esses sinais devem ser avaliados em conjunto. Chips melhores não podem compensar transporte inacessível. Transporte barato não pode remover calor dos processadores. Um resfriamento robusto não pode criar a largura de banda necessária para treinamento distribuído.

Concorrentes oferecerão comparações úteis. A SpaceX propôs sua própria rede de computação orbital, enquanto a Starcloud e outras startups estão testando arquiteturas diferentes. Seus resultados podem revelar se o projeto de cluster do Google é excepcionalmente conservador ou otimista.

Os primeiros usos comerciais também podem diferir da visão mais ampla do Google. O processamento nativo no espaço, incluindo a análise de dados de sensores ou imagens antes da transmissão, exige menos largura de banda em solo. Isso o torna um mercado inicial mais plausível.

A computação em nuvem geral para usuários na Terra enfrenta requisitos mais rigorosos. Os clientes esperam acesso confiável, latência previsível, tratamento seguro dos dados, substituição rápida de hardware e garantias claras de nível de serviço. A infraestrutura orbital precisa atender a essas expectativas enquanto gerencia a sobrecarga de deslocamento.

A conclusão mais importante não é que o Google precise exatamente de 1.800 lançamentos. Esse número vem de um modelo cujas premissas mudarão à medida que Starship, os projetos de satélites e os mercados evoluírem.

Sua importância está no que revela. Os data centers espaciais do Google exigem um sistema industrial que abrange foguetes, fábricas de espaçonaves, redes ópticas, engenharia térmica, operações autônomas e hardware de IA.

O Project Suncatcher começou agora a testar um elo dessa cadeia. O satélite pode informar ao Google se seus chips suportam condições reais no espaço. Ele não pode determinar se a SpaceX realizará centenas de lançamentos anuais.

O experimento merece atenção porque transforma uma ideia especulativa em um programa de engenharia mensurável. Ele também torna mais difícil ignorar a distância que ainda falta percorrer.

Observe o que o Google relata sobre o MVP, se sua missão com múltiplos satélites segue o cronograma e com que frequência a Starship realiza missões comerciais reutilizáveis. Esses três sinais mostrarão se a IA orbital está se tornando infraestrutura ou permanecendo um ambicioso projeto de pesquisa.