A IA está faminta por energia — e o Google decidiu testar uma solução que parece ficção científica: colocar chips em órbita para aproveitar a luz solar quase ininterrupta do espaço. Segundo o Olhardigital.com.br, o Projeto Suncatcher vai levar TPUs para um satélite em órbita baixa da Terra na próxima semana. Mas o que isso significa, de verdade, para quem trabalha com machine learning no dia a dia?
O que o Projeto Suncatcher está tentando resolver
Treinar e servir modelos grandes consome megawatts. Em 2024, data centers do Google já operavam com picos de 200 MW dedicados a workloads de IA, e a curva não para de crescer. O problema não é só energético — é também térmico. Cada watt dissipado em silício vira calor que precisa sair de algum lugar.
A ideia por trás do Suncatcher é elegante: no espaço, um painel solar recebe entre 5 e 10 vezes mais irradiação efetiva do que no solo (sem nuvens, sem noite em certas órbitas), e a temperatura ambiente para radiadores é brutalmente baixa. Em tese, é o lugar perfeito para data centers — se você ignorar radiação cósmica, vácuo e a impossibilidade de mandar um técnico para trocar uma placa.
Os números do lançamento
- 4 TPUs a bordo (provavelmente v5e ou Trillium/v6e)
- Voo Transporter-18 da SpaceX, em parceria com a Planet Labs
- Órbita baixa (LEO) — entre 500 e 600 km de altitude
- Foco em três variáveis: precisão das inferências, comportamento térmico e taxa de erros induzida por radiação
Por que TPUs e não GPUs?
Na minha experiência com workloads de deep learning, a escolha entre TPU e GPU depende muito do framework. As TPUs do Google brilham em JAX e TensorFlow, especialmente em multiplicação de matrizes massivas. A arquitetura é systolic array — otimizada para operações de tensor, com memória HBM de altíssima largura de banda.
Em órbita, três fatores pesam a favor das TPUs:
- Eficiência energética por operação: uma TPU v5p entrega cerca de 459 TFLOPs por kW, contra ~150 TFLOPs/kW de uma H100 em workload sustentado.
- Footprint térmico menor por chip: menos watts para dissipar em vácuo.
- Padronização: o Google controla o silício e o compilador XLA, então pode ajustar o chip para tolerância a radiação se necessário.
O monstro do vácuo: dissipação térmica sem ar
Aqui está o calcanhar de Aquiles que muita gente ignora. Em terra, a dissipação de calor acontece por convecção — o ar quente sobe, ventiladores empurram. No espaço, convecção simplesmente não existe. O vácuo é o melhor isolante térmico que existe.
Para tirar calor de um chip em órbita, sobram duas opções:
- Condução + radiação: calor passa do die para uma placa metálica, que irradia para o espaço profundo (~3 K). É eficiente, mas exige área de superfície grande.
- Heat pipes de amônia ou sódio: two-phase cooling, funciona em microgravidade se projetado corretamente.
A HPE fez algo parecido no Spaceborne Computer (2017), usando water cooling passivo com radiadores externos. O chip sobreviveu 530 dias na ISS. O Google, segundo reportagem do NYT referenciada pelo Olhardigital.com.br, está testando um sistema proprietário — provavelmente uma variação de cold plate com fluido dielétrico.
Radiação cósmica: o inimigo silencioso
Um bit flip em um peso de modelo pode passar despercebido por semanas — até gerar uma inferência errada em produção. Em LEO, a blindagem do escudo magnético terrestre é forte, mas não total. Prótons e elétrons de alta energia ainda atravessam o silício.
A taxa de erros esperada para COTS (Commercial Off-The-Shelf) em LEO gira em torno de 1 a 10 SEU (Single Event Upset) por GB por dia. Para uma TPU com ~32 GB de HBM, estamos falando de ~100 a 300 flips diários. É por isso que o Suncatcher precisa testar ECC agressivo e, idealmente, redundância modular tripla (TMR) nos registradores críticos.
Na Prática: como usar TPUs (e o que aprendi fazendo isso)
Se você está pensando em treinar em TPUs — seja no espaço daqui a 10 anos ou na cloud do Google amanhã —, o setup é mais simples do que parece. Aqui está um exemplo real que rodei semana passada:
import jax
import jax.numpy as jnp
from jax import pmap, random
# Verifica dispositivos disponíveis (TPU, GPU ou CPU)
devices = jax.devices()
print(f"Dispositivos detectados: {devices}")
# Forward pass minimalista para teste de inferência
def forward(params, x):
return jnp.dot(x, params['w']) + params['b']
params = {
'w': random.normal(random.PRNGKey(0), (1024, 1024)),
'b': jnp.zeros((1024,))
}
# pmap paraleliza automaticamente entre chips
parallel_forward = pmap(lambda p, x: forward(p, x))
replicated_params = jax.tree_map(lambda x: x[None, ...], params)
x = random.normal(random.PRNGKey(1), (8, 1024))
output = parallel_forward(replicated_params, x)
print(f"Output shape: {output.shape}") # (8, 1, 1024)
O detalhe que pega muita gente: TPUs não são GPUs. Se você vem de CUDA, vai estranhar. Não tem alocação manual de memória, não tem kernels customizados em primeira ordem, e a compilação é eager no PyTorch/JAX. O XLA compila tudo antes de executar — ótimo para performance, infernal para debug.
Passo a passo para testar se seu código roda em TPU
- Suba um notebook no Google Colab com runtime TPU v2-8 ou v3-32.
- Troque todas as chamadas
.cuda()porjax.devices(). - Substitua
torch.compileporjax.jit. - Verifique shapes: TPUs exigem batching fixo (dynamic shapes custam caro).
- Use
pmappara paralelismo entre chips,vmappara batches internos.
Erros comuns que devs cometem (e que vão doer no espaço também)
1. Ignorar determinismo do treinamento. Em TPU, operações como jax.random.split exigem chaves explícitas. Esquecer isso gera runs não-reprodutíveis — fatal quando você precisa auditar pesos em órbita.
2. Subestimar o custo de dynamic shapes. Em GPU você paga um pouco; em TPU, paga recompilação total. Padronize seus batch sizes.
3. Misturar precision sem critério. bfloat16 é nativo nas TPUs e mais estável que fp16. Mas se sua loss explodir, o problema quase sempre é dtype, não arquitetura.
4. Achar que ECC de HBM resolve tudo. Resolve SEUs na memória, não nos registradores do systolic array. Para inferência crítica, você precisa de TMR no nível de aplicação.
5. Esquecer que latência importa. Um data center em LEO está a 550 km de altitude. Round-trip de luz: ~3,7 ms mínimo. Se você está servindo um chatbot, o usuário não vai notar. Se está fazendo controle de foguete, é tempo demais.
Implicações reais para quem programa IA hoje
Esse teste do Google não vai mudar sua rotina amanhã. Mas vai moldar a próxima década. Algumas apostas minhas:
- Hiperescala vai migrar para órbita em 10–15 anos: o custo de lançamento caiu 90% em uma década com SpaceX e segue caindo.
- Modelos de borda vão consumir inferência orbital: imagine um satélite decidindo, sozinho, o que filmar, com um LLM de 7B rodando locally.
- Certificação vai virar problema de dev: aerospace software exige DO-178C e AS9100. Se você quer trabalhar nisso, comece a estudar formal verification hoje.
FAQ — Perguntas que devs reais vão fazer
1. O satélite vai processar IA em tempo real ou só testar?
Testar. O Suncatcher ainda é protótipo. O objetivo é coletar telemetria — precisão de inferência, temperatura do die, taxa de erros — durante meses. Não há workload produtivo em jogo.
2. Qual a diferença entre TPU e GPU em termos de radiação?
Nenhuma diferença arquitetural fundamental — ambas são COTS. A diferença está no uso: TPUs e GPUs ficam em data centers climatizados. Nenhuma foi projetada para o ambiente espacial, e o Google está justamente descobrindo se sobrevivem.
3. Por que órbita baixa e não geoestacionária?
LEO oferece latência menor e ambiente de radiação menos hostil. GEO (35.786 km) tem cinturões de Van Allen mais intensos e custo de lançamento muito maior. Para protótipo, LEO é o sweet spot.
4. Quando data centers orbitais serão economicamente viáveis?
Estimativas variam. A NASA e a ESA projetam 2035–2040 para primeiros clusters operacionais. O gargalo não é tecnologia — é seguro, regulação e o modelo de manutenção (que em órbita é zero humano).
5. Posso rodar meus modelos locais em TPUs caseiras?
Não diretamente — TPUs são fechadas. Mas você pode treinar em Google Cloud e exportar para Coral Edge TPU (a versão pequena, para inferência em borda). Para desenvolvimento, Colab com TPU gratuita é o caminho.
Veredito
O Suncatcher é ambicioso, mas está no lugar certo da curva. A energia solar em órbita é praticamente infinita para efeitos práticos — uma órbita sincronizada com o sol recebe ~99% de iluminação contínua. O gargalo real é térmico e radiativo, exatamente o que o Google vai medir agora.
Se isso funcionar, em 15 anos vamos olhar para centros de dados em órbita como hoje olhamos para cloud computing: uma decisão óbvia que parecia loucura em 2010.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.