A Satlyt captou US$ 8 milhões em uma rodada inicial para desenvolver software para computadores a bordo de satélites. Seu caso imediato é mais restrito e mensurável que um enorme centro de dados espacial: analisar telemetria, registros e imagens perto da origem e enviar informações mais úteis por uma capacidade limitada de comunicação com o solo.

A ambição maior é tornar o cálculo portátil entre naves de fabricantes diferentes. A Satlyt tem experiência de voo e experimentos de clientes, mas ainda não demonstrou uma nuvem distribuída entre satélites diferentes. Separar esses marcos é essencial para entender tanto o investimento quanto o risco.

Uma proposta interna rejeitada vira empresa financiada

O fundador Rama Afullo trabalhou na organização de nuvem do Google antes de entrar no negócio Starlink da SpaceX em 2024. Disse ao TechCrunch que os dois empregadores rejeitaram suas propostas internas de computação orbital na época. Depois cofundou a Satlyt, com operações em Sunnyvale, Califórnia, e Nairóbi, Quênia.

A Non Sibi Ventures, de Houston, liderou a rodada. Seus sócios incluem o ex-astronauta da NASA Bernard Harris. A Satlyt afirma que seu software voou em duas missões de demonstração; a implantação mais recente relatada usa hardware de computação espacial da indiana TakeMe2Space.

Essa missão leva três cargas diferentes. A NASA paga para testar protocolos de nuvem no espaço. A Stellerian, de vigilância orbital, planeja avaliar processamento de imagens, enquanto a TakeMe2Space quer demonstrar hospedagem de software externo. São experimentos com objetivos diferentes, não prova de um serviço orbital compartilhado maduro.

Afullo quer alcançar 20% dos satélites até o fim da década. A Satlyt também diz ter preparado software para até 50 implantações em naves em 2026. Nem ambição nem capacidade preparada equivalem a instalações ativas, renovações pagas ou participação de mercado confirmada de forma independente.

O resultado inicial mais claro é uma mensagem menor

A Satlyt implantou um Gemma 3 quantizado de um bilhão de parâmetros em um satélite operado pela Momentus usando llama.cpp. A quantização reduz a precisão numérica para exigir menos memória e cálculo. O caso Gemma descreve análise local de telemetria, registros de aplicativos e erros de software.

Em dois cenários de injeção de falha, os dados de diagnóstico caíram de 1.319 para 469 bytes e de 1.318 para 464 bytes, reduções de 64,4% e 64,8%. O modelo produziu diagnósticos curtos e ações recomendadas. As velocidades divulgadas superaram 22 tokens por segundo nesses cenários.

Testes mais amplos da empresa examinaram cerca de 11 watts de potência do processador durante inferência e elevação de temperatura entre três e cinco graus Celsius. São medições da companhia em condições restritas, não um perfil operacional de frota estabelecido independentemente. Reduzir a mensagem tampouco demonstra diagnóstico correto em toda falha.

O mecanismo é simples: resumir a falha antes de uma janela de comunicação, em vez de transmitir todos os registros brutos. As equipes no solo podem receber um relatório menor e mais útil. Processamento de imagens também pode descartar quadros cobertos por nuvens ou priorizar possíveis alvos de vigilância antes do envio.

São aplicações de computação na borda que não exigem primeiro grandes aglomerados orbitais de IA. O valor financeiro depende do contrato de banda, equipe e necessidades de resposta de cada missão. Evidências úteis conectariam bytes poupados a resolução mais rápida, imagens de maior valor ou menos trabalho no solo, medindo também exatidão, energia e memória.

Portabilidade e integração vertical resolvem problemas distintos

Afullo compara a SpaceX a um iPhone orbital e a Satlyt ao Android. A distinção é software sobre hardware variado contra uma pilha coordenada de ponta a ponta. Não significa escala equivalente entre empresas nem que a Satlyt já seja um padrão aberto da indústria.

A SpaceX controla lançamentos, fabricação de satélites, conectividade e grande parte do ambiente operacional. A integração pode simplificar interfaces e coordenar energia, enlaces e processadores. Clientes podem aceitar dependência de um roteiro, calendário de lançamentos ou preços em troca de implantação e suporte mais simples.

A Satlyt não pretende fabricar satélites. Compara sua abstração à VMware e à Snowflake: aplicativos devem depender menos de máquinas físicas específicas. Mais fabricantes compatíveis podem atrair desenvolvedores, e mais aplicativos atrair fabricantes. Por enquanto, precisa resolver o começo em que ambos os lados esperam pelo outro.

O Project Suncatcher do Google começa com TPUs próprios e satélites interligados movidos a energia solar. Seu protótipo com a Planet testa efeitos de lançamento, radiação e temperatura. O Google informou que o protótipo chegou à órbita na missão Transporter-18 da SpaceX em 1º de outubro de 2026, estabeleceu contato e iniciou testes.

Compartilhar acesso ao lançamento não torna as arquiteturas iguais. O Google testa hardware especializado no espaço; a Satlyt verifica se clientes externos conseguem usar software entre computadores que ela não possui. Não são necessariamente concorrentes diretos hoje e podem se complementar no futuro.

A segurança da nave limita a camada compartilhada

Servidores terrestres contam com interfaces padrão, redes confiáveis e manutenção física. Satélites enfrentam radiação, ciclos térmicos, enlaces intermitentes, movimento orbital e limites rígidos de energia. Processadores, sistemas operacionais e prioridades variam; muitas naves não têm enlaces próprios para trocar grandes cargas de processamento.

O Google compara o apontamento de futuros enlaces laser a acertar um alvo móvel do tamanho de uma moeda a quilômetros de distância. Componentes podem enfrentar 50 a 100 vezes a gravidade no lançamento; radiação pode alterar dados, e o vácuo impede resfriamento comum por fluxo de ar. Software só consegue programar em torno desses limites com telemetria confiável e acesso operacional suficiente.

Uma tarefa externa não pode consumir memória, energia ou comunicação necessárias à navegação ou carga principal. Isolamento, atualizações assinadas, controle de acesso, auditoria e autoridade de parada emergencial são requisitos de aceitação, não extras. Gerenciar vários operadores também cria um alvo atraente para ataques.

A IA pode diagnosticar mal uma falha ou classificar uma imagem incorretamente. Recomendar uma ação ao solo é diferente de comandar a nave. A Satlyt diz que operadores manterão o comando ao ampliar detecção de anomalias e decisões multiagente; essa fronteira precisa ser validada nas integrações reais.

Os incentivos comerciais podem ser tão difíceis quanto a tecnologia. Tempo de processador livre não justifica automaticamente responsabilidade por carga externa ou condições de divisão de receita. Sem interfaces comuns, cada integração vira engenharia sob medida e enfraquece a economia repetível do software.

Os próximos testes precisam provar mais que um lançamento

A Satlyt espera tentar processamento entre duas naves diferentes no próximo ano. Uma divulgação relevante identificaria plataformas e mostraria processamento coordenado, latência, recursos e recuperação, não apenas troca de mensagens. Duas máquinas idênticas podem provar distribuição sem demonstrar interoperabilidade ampla.

Clientes recorrentes e fabricantes independentes fortaleceriam o caso comercial. Acordos, hardware lançado, cargas ativas e renovações pagas são níveis diferentes de evidência. Os dados mais fortes viriam de clientes ou parceiros de pesquisa, além de testes internos, enquanto o Google avança em enlaces entre satélites e a SpaceX conserva a escala.

Relatórios de missão, definições de testes e contratos podem ser acompanhados numa base de conhecimento de documentos de engenharia. A Satlyt superou a proposta, mas sua promessa principal continua adiante: cálculo portátil, seguro e economicamente repetível em frotas mistas. Isso, não outra analogia com Android, transformaria ferramentas a bordo em plataforma orbital.

Fontes

Explorar diretório de ferramentas →