Quando li no Olhardigital.com.br que Tesla e SpaceX confirmaram a construção da Terafab, uma megafábrica de chips no Texas com investimento inicial de US$ 16,8 bilhões (cerca de R$ 86 bilhões), minha primeira reação não foi admiração — foi uma pergunta técnica: por que duas empresas que historicamente não fabricam silício resolveram assumir uma das operações mais caras e complexas do planeta? A resposta curta envolve soberania computacional, gargalos de NVIDIA e uma mudança estrutural que vai atingir diretamente quem programa modelos de IA nos próximos cinco anos.
O que a Terafab realmente significa — além do hype bilionário
Antes de qualquer coisa, vamos traduzir os números. US$ 16,8 bilhões é o investimento inicial divulgado agora, abaixo dos US$ 25 bilhões originalmente mencionados. Em documentos anteriores, a SpaceX chegou a citar um plano de expansão dividido em fases que poderia envolver até US$ 119 bilhões. São números que beiram o obsceno até para padrões de semicondutores — uma fábrica avançada da TSMC custa entre US$ 20 e US$ 30 bilhões. O que a SpaceX está propondo, portanto, não é uma fábrica: é um cluster fabril comparável, em escala, ao que Taiwan opera para alimentar o mundo.
A unidade ficará em Grimes County, perto de Houston, com mais de 100 milhões de pés quadrados dedicados à fabricação de semicondutores. Empregará pelo menos 3 mil pessoas da região. Mas o detalhe mais importante para nós, devs, está no modelo operacional: a Terafab concentrará fabricação, empacotamento e testes de componentes avançados em uma única operação. Isso elimina o gargalo clássico da cadeia — onde TSMC fabrica wafers, ASE ou Amkor empacota, e a NVIDIA valida — em uma estrutura verticalizada.
A SpaceX afirma que a instalação será criada para “construir novos recursos de computação em uma escala e velocidade sem precedentes”. Os chips produzidos ali serão usados nos robôs Optimus, nos veículos autônomos Cybercab e nos futuros data centers espaciais. Na minha leitura, isso descreve três workloads distintos: inferência embarcada de baixa latência (Optimus), treinamento distribuído com restrição energética (Cybercab) e computação tolerante a radiação e latência variável (data centers espaciais). Um único processo fabril tentando servir três domínios radicalmente diferentes é, no mínimo, ambicioso.
Por que Tesla e SpaceX estão fazendo isso (e por que você deveria se importar)
Três motivos técnicos explicam a decisão, e todos afetam diretamente quem desenvolve com IA.
1. Gargalo de NVIDIA. Hoje, qualquer pessoa ou startup tentando treinar modelos grandes depende da fila da H100, H200 ou B200. A NVIDIA vende tudo o que produz e ainda assim há escassez. Para Musk, esperar a NVIDIA é aceitar que o roadmap da Optimus e do Cybercab fique refém da capacidade de fabricação de terceiros. Faz sentido verticalizar quando o fornecedor é gargalo absoluto.
2. Custo total de propriedade. Comprar uma H100 custa cerca de US$ 30 mil. Um cluster de 10 mil H100 custa US$ 300 milhões só em hardware. Em cinco anos, Musk queimaria centenas de bilhões em GPUs que poderia fabricar a um custo marginal muito menor. Já vi clientes meus chegarem à mesma conclusão ao calcular TCO de inference em larga escala.
3. Otimização workload-specific. Chips de uso geral (como GPUs) são compromissos. A Tesla já demonstrou isso com o D1 (Dojo) e o HW3/HW4 para inference veicular. Uma fábrica própria permite iterar arquiteturas em ciclos de 12 a 18 meses em vez de esperar o roadmap da TSMC e da NVIDIA. Para nós, devs, isso significa SDKs novos, toolchains proprietários e, provavelmente, frustração inicial — porque migrar de CUDA para um stack customizado não é trivial.
O que 100 milhões de pés quadrados produzem em chips?
Para dimensionar: uma fábrica moderna de 300mm (wafer) produz entre 50 mil e 100 mil wafers por mês. A TSMC Fab 18, que fabrica chips de 3nm, opera em escala semelhante. Se a Terafab realmente atingir esse porte, ela poderá produzir algo na casa de 1 milhão a 1,2 milhão de wafers por ano — capacidade suficiente para alimentar centenas de milhões de chips de IA por ano, dependendo do die size e do yield.
A pergunta que ninguém responde: em qual node? Se for 3nm ou 2nm (TSMC N3E, N2), o custo por wafer ultrapassa US$ 20 mil. Se for 7nm ou 5nm, mais barato, mas defasado. Apostar bilhões em uma fábrica sem node definido seria suicídio técnica. Suspeito que veremos licenças cruzadas com Samsung ou TSMC, ou aquisição de IP da ARM e do ecossistema RISC-V, como já fizeram outros players.
Na Prática: o que muda no seu workflow de dev
Vamos supor que você trabalha com inferência de modelos de visão para um projeto de robótica ou automação. Hoje, seu pipeline provavelmente roda em uma stack NVIDIA — CUDA, cuDNN, TensorRT. Amanhã, com chips proprietários da Terafab, você terá que lidar com toolchains diferentes. Prepare-se desde já.
Passo a passo para se adaptar a um cenário de chips customizados:
- Abstraia seu modelo do hardware. Use compiladores como Apache TVM, MLIR ou OpenXLA. Eles já suportam múltiplos backends (CUDA, ROCm, Metal, e targets customizados).
- Quantize agressivamente. INT8 e FP8 já são padrão em inferência. Familiarize-se com ferramentas como ONNX Runtime quantization, TensorRT-LLM e llama.cpp, que suportam backends não-NVIDIA.
- Teste em hardware alternativo. Um Mac com chip M-series ou um Raspberry Pi com Hailo-8 já são ambientes válidos para validar que seu modelo não está acoplado ao CUDA.
- Adote ONNX como formato intermediário. ONNX está se tornando o “LLVM dos modelos de IA” — compila uma vez, roda em qualquer hardware com runtime compatível.
Exemplo concreto: exportando um modelo PyTorch para ONNX e validando que ele não depende de CUDA:
import torch
import torch.nn as nn
class SimpleClassifier(nn.Module):
def __init__(self, input_dim=128, hidden=256, output=10):
super().__init__()
self.net = nn.Sequential(
nn.Linear(input_dim, hidden),
nn.ReLU(),
nn.Linear(hidden, hidden),
nn.ReLU(),
nn.Linear(hidden, output),
)
def forward(self, x):
return self.net(x)
model = SimpleClassifier()
model.eval()
dummy = torch.randn(1, 128)
torch.onnx.export(
model,
dummy,
"model.onnx",
opset_version=17,
input_names=["input"],
output_names=["logits"],
dynamic_axes={"input": {0: "batch"}, "logits": {0: "batch"}},
)
print("Modelo exportado para ONNX com sucesso.")
import onnxruntime as ort
import numpy as np
session = ort.InferenceSession("model.onnx", providers=["CPUExecutionProvider"])
input_data = np.random.randn(4, 128).astype(np.float32)
result = session.run(None, {"input": input_data})
print(f"Inferencia CPU funcionou. Shape: {result[0].shape}")
Esse snippet roda em qualquer máquina, sem CUDA. Se seu modelo funciona aqui com performance aceitável, migrar para um chip proprietário da Terafab será trivial. Se só funciona com CUDA, você tem um problema de acoplamento — e a Terafab vai multiplicar esse tipo de problema no mercado.
Erros comuns que devs cometem ao planejar IA em escala
Trabalho com clientes que estão comprando clusters de GPU para treinar e servir modelos. Os erros se repetem:
- Acoplar tudo ao CUDA. Escrever kernels customizados em CUDA sem fallback. Quando o hardware muda (e vai mudar), o custo de migração é brutal.
- Ignorar o custo de memória. Comprar GPUs pela FLOPS sem olhar para HBM. Em inferência, largura de banda de memória importa mais que poder de cálculo bruto.
- Subestimar o custo de empacotamento e teste. Musk está verticalizando justamente porque essa etapa — packaging — virou gargalo. Em software, devs ignoram a “última milha” do deploy (otimização, quantization, serving) e depois sofrem em produção.
- Confundir training e inference. Chips de training (alta precisão, alta memória) e chips de inference (quantizado, baixa latência) têm perfis completamente diferentes. A Terafab promete servir os dois — promessa difícil de cumprir com um único processo.
- Não versionar modelos e pesos. Quando o hardware muda, muitas vezes é preciso re-exportar ou re-quantizar. Sem versionamento, vira caos.
Comparação com o cenário atual
Hoje, o ecossistema é dominado por três players: TSMC fabrica, NVIDIA/AMD projetam, e hyperscalers (AWS, Azure, GCP) operam. A Terafab quebra esse tripé ao introduzir um player verticalizado — quem projeta o chip é também quem fabrica e quem consome. Isso é disruption real, comparável ao que a Apple fez ao migrar para Apple Silicon.
Outros projetos semelhantes: a Intel Foundry Services tenta algo parecido (IDM 2.0), a Amazon já tem Trainium e Inferentia (mas terceiriza a fábrica), e a Google tem as TPUs fabricadas pela Broadcom. Nenhum, porém, na escala proposta pela SpaceX/Tesla.
Perguntas frequentes
A Terafab vai competir diretamente com a NVIDIA? Em produtos finais (robôs, carros, data centers espaciais), sim. No mercado geral de GPUs para terceiros, provavelmente não — Musk não tem histórico de vender commoditie de hardware. Será consumo interno majoritariamente.
Quando esses chips vão chegar ao mercado? Fábricas de semicondutor levam entre 3 e 5 anos para entrar em produção plena após o anúncio inicial. Considerando que o investimento inicial foi divulgado agora,第一批 chips de produção provavelmente só aparecerão entre 2028 e 2030.
Isso afeta o preço das GPUs NVIDIA? Indiretamente, sim. Mais competição vertical reduz demanda por GPUs em nichos específicos, o que pode pressionar margens da NVIDIA em médio prazo. Mas no curto prazo, a NVIDIA continua vendendo tudo o que fabrica.
Vale a pena devs já se prepararem para chips não-NVIDIA? Na minha experiência, sim. Adotar ONNX, TVM, MLIR e testar em backends alternativos (CPU, Apple Silicon, ROCm) é investimento que paga dividendo independente da Terafab dar certo ou não.
A SpaceX tem competência para operar uma fábrica de chips? Essa é a pergunta mais difícil. Operar uma foundry exige know-how que nenhuma das duas empresas possui hoje. Musk provavelmente vai precisar de parcerias ou aquisições estratégicas — talvez até uma foundry estabelecida. Apostar em construção greenfield é arriscadíssimo.
No fim das contas, a Terafab é um sinal claro de onde a indústria está indo: compute virou commodity estratégica, e os grandes consumidores não querem mais depender de terceiros para crescer. Para nós, devs, isso significa um futuro próximo com mais diversidade de hardware — e mais responsabilidade em escrever código portável desde o dia um.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.