Software de IA Orbital da Satlyt Seguiu a Rota Aberta Rejeitada pela SpaceX e pelo Google

O software de IA orbital da Satlyt está chegando ao espaço depois que SpaceX e Google rejeitaram as propostas internas do fundador Rama Afullo para computação distribuída em órbita. A Satlyt agora levantou uma rodada seed de US$ 8 milhões e garantiu espaço para seu software em várias missões de satélite.

A reviravolta tornou-se especialmente visível quando o software da Satlyt alcançou a órbita pela SpaceX, ao lado do hardware do Project Suncatcher, do Google. Ambos os ex-empregadores agora apoiam estratégias de computação orbital, mas seguem uma arquitetura diferente da escolhida por Afullo.

A Satlyt quer fornecer uma camada de software que funcione em naves espaciais de diversos fabricantes. A SpaceX representa a rota oposta: uma empresa controlando lançamentos, satélites, conectividade, hardware de computação e grande parte do ambiente operacional.

Essa diferença importa mais do que a coincidência de compartilhar um foguete. Ela delimita uma disputa inicial sobre quem controla a camada de computação acima da Terra: proprietários de naves verticalmente integradas ou uma plataforma independente conectando frotas heterogêneas.

O Software de IA Orbital da Satlyt Foi Além de uma Proposta

A mudança imediata é que a Satlyt agora tem financiamento, experiência de voo e cargas de trabalho reais, em vez de uma proposta interna rejeitada.

Afullo trabalhou na organização de nuvem do Google antes de ingressar no negócio Starlink da SpaceX em 2024. Ele disse ao TechCrunch que propôs computação orbital dentro das duas empresas. Ambas rejeitaram a ideia naquele momento.

Em seguida, ele cofundou a Satlyt, que opera em Sunnyvale, Califórnia, e Nairóbi, Quênia. A empresa desenvolve software que permite aos satélites processar dados localmente e, no futuro, compartilhar tarefas de computação entre naves espaciais.

A rodada seed de US$ 8 milhões da Satlyt foi liderada pela Non Sibi Ventures, sediada em Houston. Entre os sócios da investidora está o ex-astronauta da NASA Bernard Harris, cuja experiência ajudou a empresa a avaliar a proposta técnica e comercial.

O financiamento é apenas uma parte do acontecimento. A Satlyt afirma que seu software já voou em duas missões de demonstração, dando à empresa experiência com computação restrita além dos testes de laboratório.

Sua mais recente implantação divulgada envolve hardware construído pela TakeMe2Space, uma empresa indiana que desenvolve sistemas de computação para satélites. A missão leva três cargas de trabalho distintas de clientes para a nave espacial.

A NASA está pagando para testar protocolos de computação em nuvem no espaço. A Stellerian, que trabalha com vigilância orbital, planeja avaliar o processamento de imagens. A TakeMe2Space quer demonstrar que seu satélite pode hospedar software de empresas externas.

Esses clientes representam três camadas importantes de demanda. Uma agência governamental busca validação técnica, um operador comercial quer análises mais rápidas, e um fabricante de naves espaciais deseja um produto mais flexível.

Essa combinação oferece à Satlyt um teste mais robusto do que uma simples demonstração de software. Sua plataforma precisa suportar cargas de trabalho distintas enquanto opera dentro dos limites de uma única nave em termos de energia, memória, temperatura e comunicações.

A empresa também implantou um modelo Gemma 3 quantizado a bordo de um satélite operado pela Momentus. A quantização reduz a precisão numérica de um modelo, ajudando-o a funcionar com menos memória e poder computacional.

De acordo com os testes do Gemma, o modelo de um bilhão de parâmetros analisou localmente telemetria, logs de aplicações e erros de software. Ele foi executado por meio do llama.cpp, um framework de inferência projetado para execução eficiente de modelos.

Em dois testes de injeção de falhas, o sistema reduziu as cargas de diagnóstico de 1.319 bytes para 469 bytes e de 1.318 bytes para 464 bytes. Essas reduções foram de 64,4% e 64,8%.

O modelo também produziu diagnósticos curtos e ações recomendadas a partir do contexto técnico disponível. Esse resultado não estabelece operações autônomas confiáveis de naves espaciais, mas ilustra um uso imediato para IA a bordo.

Em vez de transmitir cada log bruto para a Terra, um satélite pode resumir um erro antes de usar uma janela limitada de downlink. Os controladores em terra recebem então uma mensagem menor e mais útil.

O progresso da Satlyt, portanto, se baseia em uma carga de trabalho prática, e não apenas na ideia distante de enormes centros de dados orbitais. A empresa está começando com diagnósticos de software, análise de telemetria e processamento de imagens em hardware que já segue rumo à órbita.

Isso cria a tensão central do artigo. SpaceX e Google podem buscar computação orbital por meio de sistemas rigidamente controlados, enquanto a Satlyt precisa provar que um software compartilhado pode funcionar nas máquinas de outras empresas.

O Mercado de Curto Prazo É o Processamento a Bordo, Não Grandes Centros de Dados Espaciais

A Satlyt não precisa de uma nuvem orbital em escala total para criar valor, mas precisa que os operadores de satélites tratem o software como uma decisão de compra independente.

A maioria dos satélites ainda depende fortemente de estações terrestres. Eles coletam imagens, leituras de sensores, dados operacionais e logs de erros, depois transmitem informações selecionadas durante janelas programadas de comunicação.

Esse modelo cria um gargalo. Uma nave espacial pode gerar mais dados do que consegue enviar economicamente para a Terra, especialmente quando as janelas de contato são curtas ou a largura de banda é disputada.

O processamento a bordo aproxima parte da decisão do sensor. Um satélite pode descartar imagens inutilizáveis, priorizar objetos suspeitos, resumir falhas ou comprimir observações antes da transmissão.

A ideia se assemelha à computação de borda na Terra. A computação de borda executa análises perto da fonte dos dados, reduzindo a necessidade de enviar tudo para uma nuvem centralizada.

O espaço torna essa troca mais severa. Um dispositivo terrestre remoto pode recuperar uma conexão de rede em minutos. Uma nave espacial pode enfrentar cobertura limitada, orçamentos rígidos de energia, radiação e nenhuma possibilidade de reparo físico.

É por isso que o exemplo de diagnóstico da Satlyt importa. Reduzir um relatório de erro em mais de 60% parece modesto diante das visões de clusters de IA em órbita. Mas isso enfrenta um custo que os operadores já têm.

A empresa afirma que a análise local pode reduzir o trabalho de processamento em terra e encurtar as respostas a anomalias. A economia financeira exata variará conforme o satélite, a missão, o modelo de equipe e o contrato de comunicações.

O processamento de imagens oferece outro caso imediato. Um satélite de observação da Terra pode identificar quadros cobertos por nuvens antes de enviá-los por downlink, ou priorizar imagens que contenham uma condição-alvo.

As cargas de trabalho de vigilância espacial seguem a mesma lógica. Um satélite pode filtrar imagens em busca de objetos potenciais ou movimentos incomuns e, em seguida, transmitir primeiro os dados mais relevantes.

Essas aplicações não exigem um centro de dados do tamanho de um armazém em órbita. Elas exigem modelos pequenos que se comportem de maneira previsível em computadores restritos e produzam resultados úteis dentro de orçamentos rigorosos de recursos.

Essa distinção também atraiu o principal investidor da Satlyt. O sócio da Non Sibi, Kent Lucas, disse ao TechCrunch que a empresa não precisa de gigantescos centros de dados espaciais para ter sucesso. O crescimento dos satélites, por si só, pode expandir seu mercado endereçável.

O argumento faz sentido, mas ainda depende de várias premissas. Mais naves espaciais precisam levar processadores de uso geral, os operadores precisam permitir software de terceiros, e os projetistas de missões precisam alocar energia escassa para cargas de trabalho de IA.

Afullo espera que processadores avançados se tornem comuns nos satélites. Ele estabeleceu a meta ambiciosa de alcançar 20% dos satélites até o fim desta década.

Essa meta continua sendo uma aspiração da empresa, não uma previsão independente. As frotas de satélites diferem amplamente, e muitas naves usam computadores especializados projetados para uma missão cuidadosamente validada.

Ainda assim, a oportunidade é mais fácil de entender do que a ampla narrativa da nuvem orbital. A Satlyt pode vender processamento útil a bordo antes que os satélites passem a compartilhar as maiores cargas de trabalho de IA.

Os desenvolvedores devem encarar essa fase como um teste de portabilidade de software. A questão central é se uma camada operacional pode suportar processadores, cargas úteis, sistemas de comunicação e requisitos de segurança de naves espaciais variados.

Os compradores corporativos devem se concentrar em resultados, não em retórica. Redução do volume de downlink, resposta mais rápida a anomalias e imagens de maior valor são benefícios mensuráveis, mesmo que o sistema subjacente nunca se torne um gigantesco centro de dados.

Essas medidas práticas também explicam por que empresas estabelecidas de naves espaciais enfrentam pressão. Se os clientes valorizarem software portátil, os fornecedores de hardware perderão parte do controle sobre as aplicações executadas em seus satélites.

A SpaceX Constrói o iPhone Enquanto a Satlyt Quer Construir o Android

A disputa principal não é Satlyt versus SpaceX em tamanho; é uma camada de software aberta contra uma pilha de computação fechada e verticalmente integrada.

Afullo usa uma analogia familiar para explicar a diferença. Se a SpaceX se tornar o iPhone dos centros de dados orbitais, ele quer que a Satlyt se torne o Android.

A comparação é imperfeita, mas captura a divisão estratégica. A Apple combina hardware, software operacional, serviços e distribuição em um sistema rigidamente gerenciado. O Android oferece suporte a dispositivos de muitos fabricantes.

A SpaceX já controla uma parcela maior da infraestrutura física do que a maioria dos concorrentes em potencial. Ela constrói foguetes, opera infraestrutura de lançamento, fabrica satélites, gerencia uma constelação de comunicações e atende clientes de conectividade.

Essa integração pode reduzir custos de coordenação. Os engenheiros podem otimizar hardware e software em conjunto, manter interfaces consistentes e avançar rapidamente sem negociar padrões entre fornecedores de naves não relacionados.

Ela também cria dependência. Um cliente que constrói sobre uma plataforma orbital proprietária pode ficar vinculado ao cronograma de lançamentos, ao roteiro técnico, aos preços, às interfaces e às decisões de acesso de uma única empresa.

A Satlyt aposta no oposto. Ela não planeja fabricar satélites. Seu software é destinado a funcionar em naves espaciais de diferentes operadores e transformar seus recursos computacionais em um serviço compartilhado.

A empresa compara seu papel ao da VMware e da Snowflake. A VMware separou aplicações de servidores físicos específicos, enquanto a Snowflake ofereceu aos clientes uma camada de dados gerenciada em infraestrutura de nuvem.

Em órbita, essa abstração é muito mais difícil. Servidores de nuvem terrestres usam processadores, redes, fontes de alimentação, sistemas de armazenamento e práticas de manutenção relativamente padronizados.

Satélites são máquinas personalizadas expostas à radiação, ciclos térmicos, energia limitada, conexões intermitentes e movimento orbital. Até reiniciar um processo com falha pode ter consequências para toda a missão.

Portanto, uma plataforma orbital aberta precisa fazer mais do que instalar o mesmo pacote em computadores diferentes. Ela deve acomodar diferenças de hardware sem enfraquecer controles de segurança ou interferir em funções essenciais da nave espacial.

A plataforma também precisa de um método seguro para agendar tarefas. Uma aplicação de terceiros não pode consumir energia, memória ou capacidade de rede necessárias para navegação, comunicações ou a carga útil principal.

Esses desafios reforçam o argumento a favor da integração vertical. A SpaceX pode projetar seu hardware de computação, links entre satélites, ambiente operacional e sistemas de energia como um único produto coordenado.

No entanto, a integração não garante que os clientes prefiram um sistema fechado. Fabricantes e operadores de satélites podem querer acesso a vários provedores de lançamento, processadores, modelos e fornecedores de análises.

Uma camada de software independente torna-se valiosa quando a diversidade aumenta. Cada espaçonave compatível adicional amplia o potencial conjunto de recursos computacionais sem exigir que a Satlyt financie uma frota de satélites.

Esse é o mesmo efeito de rede que ajudou plataformas de software a crescer na Terra. Uma base maior de hardware atrai desenvolvedores, enquanto mais aplicações tornam a plataforma subjacente mais atraente para fornecedores de hardware.

A órbita impõe um difícil problema de arranque. A Satlyt precisa de satélites compatíveis antes que desenvolvedores invistam, mas os construtores de espaçonaves precisam de aplicações úteis antes de alocar recursos à Satlyt.

Suas primeiras missões tentam resolver esse problema com cargas de trabalho concretas. A NASA fornece um caso de uso para validação, a Stellerian fornece uma aplicação e a TakeMe2Space fornece o hardware de hospedagem.

A abordagem do Google oferece outro contraste. O Project Suncatcher imagina satélites interconectados equipados com Tensor Processing Units, ou TPUs, do Google, alimentados por abundante energia solar.

Os primeiros passos do programa concentram-se no próprio hardware computacional do Google. Seu protótipo, construído com a Planet, foi projetado para medir como as TPUs respondem às forças do lançamento, à radiação e ao ambiente térmico do espaço.

O Google confirmou que o protótipo alcançou a órbita na missão Transporter-18 da SpaceX em 1º de outubro de 2026. O satélite estabeleceu contato e iniciou seu programa de testes.

Portanto, o Google está testando se seus chips especializados conseguem sobreviver e operar no espaço. A Satlyt está testando se o software pode tornar úteis, para clientes externos, computadores orbitais variados.

Hoje, as empresas não são concorrentes diretas. Suas arquiteturas podem até se tornar complementares caso uma plataforma independente venha, futuramente, a executar cargas de trabalho em processadores projetados pelo Google ou em outros processadores especializados.

Ainda assim, suas prioridades revelam centros de controle concorrentes. O Google começa com hardware que possui e compreende. A Satlyt começa com portabilidade entre hardwares que não controla.

Se a computação orbital crescer, essa distinção moldará margens, escolha dos clientes e acesso de desenvolvedores. O vencedor final talvez não possua o maior número de satélites, mas influenciará como as aplicações se movem entre eles.

A Nuvem Orbital Aberta Ainda Precisa Sobreviver à Realidade

O argumento mais forte da Satlyt é a flexibilidade, mas a flexibilidade se torna um passivo quando as espaçonaves diferem demais ou os clientes se recusam a compartilhar recursos.

A empresa demonstrou que um pequeno modelo de linguagem pode processar dados de diagnóstico a bordo de hardware limitado. Isso não é o mesmo que operar uma nuvem distribuída entre satélites.

O próximo grande objetivo técnico da Satlyt é conectar capacidade computacional entre duas espaçonaves diferentes. A empresa espera tentar essa demonstração no próximo ano.

Um teste bem-sucedido seria importante porque a computação distribuída exige coordenação entre máquinas. O software precisa dividir o trabalho, transferir dados, lidar com atrasos, recuperar-se de interrupções e confirmar que os resultados permanecem corretos.

Essas tarefas são rotineiras em data centers terrestres com energia confiável e redes de alta velocidade. Elas se tornam mais difíceis quando ambos os computadores orbitam a Terra e se comunicam apenas sob condições orbitais específicas.

A latência não é o único problema. Os satélites podem ter processadores, sistemas operacionais, requisitos de segurança, energia disponível e prioridades de missão diferentes.

Os enlaces entre satélites também podem variar muito. Algumas espaçonaves têm comunicações a laser, outras usam enlaces de rádio, e muitas nunca foram projetadas para trocar grandes cargas computacionais com satélites vizinhos.

O Google descreveu a precisão necessária para suas conexões a laser planejadas como equivalente a acertar um alvo do tamanho de uma moeda a quilômetros de distância enquanto ambos os pontos se movem.

Seus testes também ilustram o desafio do hardware. O Google afirma que os componentes de lançamento podem enfrentar forças de 50 a 100 vezes a gravidade, enquanto a radiação pode alterar dados armazenados em sistemas eletrônicos.

O controle térmico continua igualmente importante. Um processador produz calor, mas uma espaçonave não pode resfriá-lo com fluxo de ar comum porque o espaço é um vácuo.

O software da Satlyt não pode eliminar esses limites físicos. Ele só pode programar em torno deles quando as espaçonaves expõem telemetria precisa e concedem à plataforma controle operacional suficiente.

A cibersegurança cria outra barreira. Um software que gerencia cargas de trabalho em vários satélites pode se tornar um alvo valioso, porque uma invasão pode afetar múltiplos operadores.

Os clientes exigirão isolamento entre aplicações, atualizações assinadas, controles de acesso, registros de auditoria e autoridade clara sobre desligamentos de emergência. Essas proteções consomem recursos computacionais adicionais.

As saídas de IA acrescentam um risco diferente. Um modelo pode resumir um erro incorretamente ou classificar uma imagem de forma equivocada, especialmente quando suas entradas diferem dos dados de treinamento e dos testes.

Por esse motivo, o uso atual da Satlyt para diagnósticos parece mais seguro do que o comando autônomo. Um modelo pode recomendar uma ação a operadores em terra sem receber autoridade para alterar o comportamento da espaçonave.

A empresa afirma que os operadores manterão a autoridade de comando à medida que ela avança para detecção de anomalias e decisões multiagente. A fronteira prática entre assistência e controle exigirá validação cuidadosa.

Os incentivos comerciais são igualmente incertos. Um proprietário de satélite pode ter tempo ocioso de processamento, mas emprestá-lo a uma carga de trabalho externa pode introduzir responsabilidade sem gerar receita suficiente.

O proprietário também precisa reservar capacidade para sua missão principal. Um satélite de observação da Terra não pode atrasar imagens de clientes porque outra aplicação consumiu energia ou preencheu o armazenamento.

A estratégia “Android” da Satlyt só funciona se os fabricantes de espaçonaves oferecerem suporte a interfaces comuns. Sem uma padronização significativa, cada integração se torna um projeto de engenharia personalizado.

Isso enfraqueceria a economia de uma plataforma independente. As margens de software dependem de repetir o mesmo produto para muitos clientes, e não de reconstruí-lo para cada satélite.

A concorrência também pode vir de empresas que possuem hardware. SpaceX, Google, Starcloud e outros empreendimentos de computação orbital podem disponibilizar interfaces para desenvolvedores mantendo seus sistemas subjacentes proprietários.

Uma plataforma fechada e gerenciada pode ser mais fácil de adquirir do que uma rede aberta. Clientes frequentemente aceitam a dependência de um fornecedor quando um único provedor oferece implantação mais simples, suporte mais sólido e desempenho previsível.

Portanto, a Satlyt ainda não estabeleceu que o modelo Android prevalecerá. Ela estabeleceu que a rota aberta é suficientemente crível para receber financiamento e chegar a missões reais.

A próxima fase precisa demonstrar repetibilidade. Um modelo em um satélite prova a viabilidade, enquanto cargas de trabalho portáteis entre espaçonaves diferentes sustentariam a alegação mais ampla da plataforma.

Três Sinais Mostrarão se a Satlyt Pode se Tornar uma Plataforma Orbital

As próximas evidências precisam vir de computação entre satélites, clientes recorrentes e valor operacional mensurável, e não de outra comparação ambiciosa.

O primeiro sinal é a demonstração planejada pela Satlyt de uma nuvem com dois satélites. Esse é o teste mais direto de sua principal alegação técnica.

Observadores devem procurar confirmação de que as espaçonaves vêm de plataformas diferentes. Dois satélites idênticos sob um único operador testariam a computação distribuída, mas não a ampla interoperabilidade.

A demonstração também deve revelar que trabalho se move entre os satélites. Uma pequena troca de mensagens é menos significativa do que processamento coordenado com latência, uso de recursos e comportamento de recuperação documentados.

Uma execução bem-sucedida fortaleceria o argumento da Satlyt de que ela consegue abstrair as diferenças de hardware. Um atraso ou uma demonstração mais limitada mostraria que a plataforma aberta permanece em estágio mais inicial do que seu marketing sugere.

O segundo sinal é a recorrência de clientes. NASA, Stellerian e TakeMe2Space oferecem à empresa cargas de trabalho iniciais úteis, mas pilotos não estabelecem uma demanda duradoura.

Um sinal mais forte seria um cliente expandir de um experimento para várias espaçonaves. Isso indicaria que o software criou valor suficiente para sobreviver à revisão de missão e ao orçamento.

Outra medida importante é o número de construtores independentes de espaçonaves que integram a Satlyt. A analogia com o Android exige múltiplos fabricantes, não várias missões no hardware de um único parceiro.

A Satlyt diz que tem software preparado para até 50 implantações em espaçonaves em 2026. Capacidade preparada não é o mesmo que implantações ativadas, portanto instalações concluídas importam mais.

Os leitores devem distinguir entre acordos assinados, sistemas lançados, cargas de trabalho ativas e renovações pagas. Cada etapa traz um nível diferente de evidência comercial.

O terceiro sinal é o desempenho operacional. A redução de downlink oferece uma métrica inicial, mas os clientes também se importarão com precisão, uso de energia, consumo de memória e tempo de resposta.

Os testes com Gemma oferecem uma referência útil. A Satlyt relatou cargas de diagnóstico aproximadamente 64% menores e velocidades de geração acima de 22 tokens por segundo em dois cenários.

Seus testes mais amplos examinam aproximadamente 11 watts de potência do processador durante a inferência e um aumento de temperatura entre três e cinco graus Celsius. Essas são medições fornecidas pela empresa em condições de teste restritas.

Divulgações futuras devem conectar esses resultados técnicos aos resultados de missão. Os operadores resolveram falhas mais rapidamente, transmitiram por downlink imagens mais valiosas ou reduziram a carga de trabalho em solo?

Uma confirmação independente teria mais peso do que outro benchmark interno. Dados de voos espaciais fornecidos por clientes ou parceiros de pesquisa esclareceriam se os benefícios persistem fora de testes controlados.

É improvável que SpaceX e Google esperem. O Google já está coletando dados de seu protótipo orbital de TPU, incluindo desempenho sob radiação e temperaturas extremas.

Seu próximo marco planejado envolve testar a comunicação entre dois satélites. O progresso nesse ponto fortaleceria o modelo coordenado verticalmente, mesmo que o Google não ofereça uma plataforma comercial ampla.

A SpaceX tem uma vantagem diferente: escala de implantação. Seu controle sobre lançamento e fabricação de satélites permite iterar sem esperar que fornecedores não relacionados de espaçonaves adotem uma interface comum.

A Satlyt não consegue igualar esses recursos de capital. Sua oportunidade vem de fazer o restante do mercado funcionar mais como uma base computacional compartilhada.

Esse padrão funcionou em outros setores. O software independente torna-se valioso quando os clientes querem escolha e nenhum fornecedor de hardware consegue controlar todo o mercado.

O espaço não é um mercado normal de software, porém. Padrões de confiabilidade, restrições físicas, preocupações de segurança nacional e longos ciclos de compras desaceleram a adoção de plataformas.

Os desenvolvedores devem observar as interfaces que surgem das primeiras missões. Um modelo estável de aplicações tornaria mais fácil desenvolver uma vez e implantar em várias espaçonaves.

Compradores de satélites devem perguntar quem controla atualizações, agendamento de cargas de trabalho, acesso à telemetria e recuperação de falhas. Esses detalhes determinam se “aberto” significa portável ou apenas compatível por meio de trabalho personalizado.

As equipes que avaliam as evidências também precisam de registros disciplinados entre relatórios de missão, resultados de testes, contratos e decisões de engenharia. Uma base de conhecimento pesquisável pode manter essas alegações conectadas aos documentos que as sustentam.

O software de IA orbital da Satlyt atingiu um limiar importante. Agora possui capital, experiência de voo, experimentos de clientes e um claro oponente arquitetural.

A empresa ainda não construiu uma nuvem orbital que abranja satélites diferentes. Também não demonstrou que os fabricantes abrirão mão de controle suficiente para que uma plataforma independente ganhe escala.

É isso que torna a história digna de acompanhamento. A ideia antes rejeitada já não é hipotética, mas sua promessa central continua sem comprovação.

Nos próximos meses, acompanhe o teste com dois satélites, as implantações repetidas e os dados de desempenho em nível de missão. Em conjunto, eles mostrarão se a Satlyt está criando o Android para a órbita ou uma ferramenta especializada para um pequeno número de espaçonaves.