SpaceX IPO: como Starlink banca o prejuízo da divisão de IA

Acabou de sair o primeiro balanço da SpaceX depois do IPO de junho, e o que mais me chamou atenção não foi o número de receita, e sim o que ele revela sobre como empresas de tecnologia realmente bancam suas apostas em IA. A Starlink virou o motor financeiro da casa, faturando US$ 4,2 bilhões no trimestre com lucro operacional de US$ 1,6 bilhão, enquanto o restante do negócio — incluindo data centers e infraestrutura de IA — segue afundando em prejuízo. Para quem programa, isso diz muito sobre economia real de GPU, latência em regiões remotas e por que “verticalização” voltou a ser estratégia de quem quer sobreviver ao ciclo da IA.

Os números que o mercado ignorou (mas devs não deveriam)

Segundo o Olhar Digital, a SpaceX fechou o segundo trimestre com US$ 7,8 bilhões de receita — 92% acima do mesmo período do ano passado. O lucro por ação veio negativo em US$ 0,09, mas analistas esperavam perda de US$ 0,26. Parece ruim? É. Mas é “menos ruim” do que o mercado apostava, e isso, em economia de inovação, é praticamente uma vitória.

O detalhe que passa batido é a separação clara entre as duas operações:

• Starlink (conectividade): US$ 4,2 bi de receita, US$ 1,6 bi de lucro operacional. Única divisão lucrativa.
• Demais operações (incluindo IA): prejuízo significativo, sustentado por capex pesado em infraestrutura de treinamento.

Traduzindo para o vocabulário de quem escreve código: a SpaceX tem um produto SaaS de infraestrutura madura (Starlink) vendendo assinatura recorrente, e está queimando caixa em um projeto de P&D de longo prazo que ainda não tem product-market fit validado. Soa familiar? É o mesmo filme da AWS bancando a Amazon Retail por uma década.

Por que a Starlink segura o balanço — e o que isso ensina sobre infraestrutura

A Starlink é lucrativa porque virou commodity de conectividade com barreira de entrada absurda. Lançar uma constelação de milhares de satélites em órbita baixa não é algo que um concorrente replica em 18 meses — exige aprovação regulatória multi-país, lançadores próprios (Falcon 9, Starship) e economia de escala em antenas. Enquanto isso, ela cobra mensalidade que o mercado aceita pagar.

Para nós, devs, isso é interessante por três motivos práticos:

1. Deploy em locais remotos virou viável. Se você roda um cluster Kubernetes em uma fazenda, em um barco ou em uma estação de pesquisa na Antártida, Starlink virou a única opção com latência aceitável (20–60 ms na maioria das regiões).
2. Latência determinística é o novo luxo. Fibra continua ganhando em jitter, mas Starlink ganhou cobertura global em poucos anos — coisa que fibra nunca vai entregar.
3. Banda larga como feature, não como produto. Aplicações SaaS que assumem “internet sempre disponível” agora podem assumir também “internet em qualquer lugar”.

Na minha experiência, o ponto crítico para quem pensa em Starlink para ambiente de produção não é a banda — é o handover entre satélites, que causa micro-interrupções. Em workloads HTTP idempotentes isso é invisível. Em conexões longas (WebSocket, SSH, RDP), prepare-se para reconexões.

A divisão de IA no vermelho: o custo real de treinar modelos

A outra metade do balanço mostra o oposto. A SpaceX está perdendo dinheiro pesado com IA porque o capex envolvido é brutal: data centers, GPUs H100/H200, sistemas de resfriamento, contratos de energia, equipe de pesquisa. Isso é o que pouca gente fala quando discute “democratização da IA”. Treinar frontier models custa caro de verdade, e mesmo com receita subindo, a margem ainda é negativa.

Fazendo uma comparação direta com hyperscalers:

O padrão é claro: toda empresa séria de IA em 2025 está queimando caixa, e quem tem outra divisão lucrativa (SpaceX com Starlink, Microsoft com Office/Windows, Google com Ads) banca o jogo. Quem não tem, levanta capital ou morre. É economia básica.

Na Prática: medindo se Starlink serve para o seu deploy

Antes de trocar fibra por Starlink em qualquer ambiente de produção, eu sempre rodo um teste simples de latência, jitter e perda de pacotes ao longo de 24 horas. Esse é o script que uso em bash + ping + awk, fácil de colar em qualquer VPS ou edge device:

#!/bin/bash
# starlink-healthcheck.sh
# Mede latência média, jitter e packet loss ao longo de 24h
# Uso: ./starlink-healthcheck.sh 1.1.1.1

TARGET=${1:-1.1.1.1}
DURATION=86400  # 24h em segundos
INTERVAL=60     # ping a cada 60s
LOG=/tmp/starlink_health.log

echo "Iniciando monitor de $TARGET por $((DURATION/3600))h..."
echo "timestamp,latency_ms,loss_pct" > $LOG

START=$(date +%s)
COUNT=0
LOSS_TOTAL=0
LAT_SUM=0

while [ $(($(date +%s) - START)) -lt $DURATION ]; do
  RESULT=$(ping -c 5 -W 2 $TARGET 2>/dev/null | tail -1)
  AVG=$(echo "$RESULT" | awk -F'/' '{print $5}')
  LOSS=$(echo "$RESULT" | awk -F',' '{print $3}' | grep -o '[0-9]*')

  if [ -z "$AVG" ]; then
    AVG=0
    LOSS=100
  fi

  TS=$(date +%s)
  echo "$TS,$AVG,$LOSS" >> $LOG
  LAT_SUM=$(echo "$LAT_SUM + $AVG" | bc)
  LOSS_TOTAL=$((LOSS_TOTAL + LOSS))
  COUNT=$((COUNT + 1))
  sleep $INTERVAL
done

# Relatório final
echo "----- RELATÓRIO -----"
echo "Amostras: $COUNT"
awk -F',' 'NR>1 && $2>0 {sum+=$2; n++} END {if(n>0) printf "Latência média: %.2f ms\n", sum/n}' $LOG
awk -F',' 'NR>1 {sum+=$3} END {printf "Perda média: %.2f%%\n", sum/NR}' $LOG
awk -F',' 'NR>1 && $2>0 {if($2>max || max=="") max=$2; if(min=="" || $2