Pare de apostar a empresa em CUDA: o playbook de 2026 para CTOs sobre portabilidade de IA

Se o seu roadmap de IA assume NVIDIA para sempre, você está a uma reunião com fornecedor de um incidente no conselho. Desempenho por dólar está melhorando rápido, a disponibilidade é volátil, e até fornecedores de modelos estão explorando seus próprios chips. Fala-se que a Anthropic discute um acelerador personalizado com a Samsung; enquanto isso, uma nova leva de posts mostra desempenho por dólar melhorando quase todo mês. A questão não é quem “vence”. A questão é que você não pode se dar ao luxo de se importar. Seu stack precisa rodar onde estiver o silício barato e disponível no próximo trimestre.

O mercado de hardware deixou de ser commodity — de novo

Dois anos atrás, “GPU” significava CUDA, e CUDA significava NVIDIA. Em 2026, você tem opções — e é exatamente por isso que precisa de um plano de portabilidade.

• NVIDIA H100: Padrão-ouro em throughput e maturidade de ecossistema. 80–94 GB de HBM, kernels maduros (FlashAttention, Triton), ampla disponibilidade em nuvem. Nós 8x sob demanda costumam custar entre dezenas altas e centenas baixas de USD/hora, dependendo da região e do compromisso.
• AMD MI300X: 192 GB de HBM por GPU é o grande diferencial. Essa folga de memória permite batches maiores, contextos mais longos e menos malabarismo de sharding de tensores. ROCm amadureceu o suficiente para que stacks mainstream de inferência sejam viáveis — não projetos de laboratório.
• Intel Gaudi (Gaudi2/3): Surpreendentemente competitivo em preço/desempenho em algumas nuvens, forte throughput em BF16, uma história alternativa de interconexão e um fornecedor motivado a dar desconto.
• Google TPU (v5e/v5p): Continua sendo uma boa opção para treinamento em escala e para inferência se você puder viver dentro do GCP e mirar bem no XLA.
• Borda e on-device: Apple Silicon (Metal), GPUs classe Vulkan e CPUs com AVX-512 ou AMX. Não são seu cavalo de batalha para treinamento — mas são críticos para inferência privada e de baixa latência quando os dados não podem sair do dispositivo.

Memória, não flops, costuma ser o gargalo na inferência. Os 192 GB do MI300X podem manter o serving multi-tenant honesto ao evitar sharding “Frankenstein”. A maturidade de kernels do H100 vence em tokens/segundo bruto em muitos casos. TPUs podem parecer ótimas até você bater em uma operação não suportada. Seus custos oscilam com tamanho de batch, comprimento de contexto e a presença (ou ausência) de um bom kernel de atenção fundida para o seu modelo exato. É por isso que portabilidade vence partidarismo de fornecedor.

O que “portável” realmente significa para um CTO

A maioria dos times acha que portabilidade é “conseguimos exportar ONNX”. Isso é o passo um, não o destino. Portabilidade de verdade abrange seis camadas. Audite cada uma.

• Formato de pesos: safetensors para segurança e velocidade; ONNX ou caminhos de compilação OpenXLA para atingir alvos amplos; GGUF para CPU/borda via llama.cpp.
• IR de grafo: ONNX ou StableHLO/XLA permitem retarget sem viver para sempre no PyTorch eager. TVM/IREE podem compilar para Vulkan/Metal/ROCm/CUDA em caminhos não-NVIDIA.
• Runtime: vLLM, Text Generation Inference (TGI), llama.cpp ou MLC LLM. Escolha pelo menos dois com dependências de backend diferentes.
• Kernels: FlashAttention, Triton, MLPs fundidos. Frequentemente são CUDA-first. Você precisa de equivalentes em ROCm ou HIP, ou de um compilador de IR que faça fusões de ops boas o bastante sem CUDA sob medida.
• Quantização e layout de memória: FP16/BF16 como denominador comum; INT8/INT4 (AWQ, GPTQ, SmoothQuant) aumentam o throughput, mas estreitam a portabilidade a menos que você escolha métodos suportados em múltiplos backends.
• Camada de serving e scheduler: Batching contínuo e paged attention (por exemplo, no vLLM) reduzem o custo, mas podem ser sensíveis ao backend. Sua camada de serving deve expor a mesma API em qualquer hardware.

Um framework de decisão para 2026: escolha sua pista de portabilidade

Pista 1: Inferência dual-source (CUDA + ROCm) para 80% dos casos

Se você roda modelos classe 7B–70B para chat, RAG e código, este é o padrão pragmático. Mantenha NVIDIA em primeiro lugar pela maturidade dos kernels e mantenha AMD como segunda fonte totalmente validada e pronta para produção.

• Runtime: vLLM como stack principal de serving. Suporta CUDA e, cada vez mais, ROCm; entrega batching contínuo forte e integra bem com tokenizers e APIs estilo OpenAI.
• Fallback: TGI ou llama.cpp para modelos específicos ou fallbacks em CPU/Metal.
• Quantização: Mantenha duas variantes “oficiais” por modelo: BF16/FP16 e INT8. Trate INT4 como oportunista até que seu backend não-CUDA prove estabilidade.
• Infra: Mantenha duas imagens “golden”: uma com CUDA e libs do fornecedor, outra com ROCm. Congele versões de driver-toolkit e publique SBOMs.

Quando escolher: Você quer comprar o que estiver no mercado spot no próximo trimestre, não o que seu roadmap assumiu no ano passado. Precisa reduzir 20–40% do custo de inferência sem retreinar modelos nem reescrever a lógica de negócio.

Pista 2: Compilação IR-first (ONNX/OpenXLA + IREE/TVM) para edge e aceleradores exóticos

Se você entrega inferência móvel ou embarcada, ou quer opcionalidade entre TPU e futuros silícios sob medida, invista em IR-first. Você trocará um pouco de throughput absoluto pela liberdade de retarget rápido.

• Stack de compilador: Exporte para ONNX ou StableHLO e compile com IREE ou TVM para Vulkan, Metal, CUDA ou ROCm.
• Runtime: MLC LLM para um caminho “baterias inclusas” rumo a phones e desktops; ele usa TVM para múltiplos backends.
• APIs: Congele sua API pública na camada de serving. Mantenha as escolhas de compilador invisíveis aos times de produto.

Quando escolher: Você precisa rodar on-device por privacidade ou latência, ou prevê aceleradores não-GPU no seu funil de compras. Quer um único caminho de código para Vulkan/Metal/ROCm/CUDA.

Pista 3: Rede de segurança com CPU-first para SLOs e DR

Haverá dias em que você não conseguirá uma GPU. Um caminho robusto em CPU mantém seus P99s e SLAs honestos durante choques de oferta de GPU, upgrades ou incidentes de segurança.

• Runtime: llama.cpp ou MLC LLM mirando CPU, com pesos GGUF. Mire AVX-512 ou AMX onde estiver disponível.
• Escopo: Modelos menores (3B–7B) com fine-tunes específicos por tarefa para qualidade “boa o suficiente” quando GPUs estiverem indisponíveis.
• Uso: Capacidade canário e de emergência, além de inferência privada on-device para segmentos regulados.

Os únicos dois números que importam: custo por 1K tokens e latência do primeiro token

Ignore comparações genéricas de “TFLOPs”. Seus compradores vão sentir duas coisas: quanto tempo até aparecer o primeiro token e quanto cada mil tokens lhe custa entregar nos seus SLOs.

• Custo por 1K tokens: Aproximar como (preço da instância $/hora) dividido por (tokens/segundo × 3600) para um contexto/profundidade de batch fixos. Batching contínuo pende essa conta a seu favor; prompts minúsculos e interativos não.
• Latência do primeiro token (FTL): Impulsionada pelo scheduler, tamanho do modelo, kernels fundidos e movimento de memória. Um stack CUDA com FlashAttention maduro pode vencer em FTL uma pilha ROCm com mais memória, mesmo com throughput total comparável.

Eis o ponto: com o batching e os kernels certos, o custo interno por 1K tokens para um modelo 7B pode cair abaixo de um centavo tanto em H100 quanto em MI300X. As APIs de nuvem ainda cobram um prêmio por 1K tokens pela simplicidade e disponibilidade. Seu plano de portabilidade é a alavanca que permite capturar o delta — quando outro fornecedor estiver mais barato naquele trimestre.

Audite seu stack para suposições de CUDA em uma tarde

Antes de falar em multivendor, prove que você não está hardcoded em CUDA. Designe um sênior para rodar este checklist e reportar até o fim do dia.

• Code grep: Procure imports explicitamente apenas de CUDA (torch.cuda, cupy, kernels triton), strings de dispositivo hardcoded e imagens base nvidia/cuda em Dockerfiles.
• Wheel lock: Liste os wheels fixados. Se você fixou torch e xformers em builds CUDA, anote os equivalentes ROCm e se seu resolvedor Python consegue trocá-los sem atrito.
• Custom ops: Faça inventário de extensões Triton ou CUDA. Para cada uma, identifique a paridade em ROCm/HIP ou uma alternativa via compilador de IR.
• Kernels: Confirme sua história de kernels de atenção dos dois lados. Paridade tipo FlashAttention existe em ROCm hoje, mas nem toda variante de modelo está coberta.
• Serving: Seu binário de serving roda em ROCm hoje? Se não, o que falta — kernel, driver ou empacotamento?
• CI: Você tem ao menos um job com ROCm? Se a resposta for “não”, você já respondeu à sua pergunta sobre portabilidade.

Construa um harness de portabilidade — uma vez

Portabilidade não é um slide; é uma suíte de testes. Trate como engenharia de release.

• Bundle padrão de modelo: Compacte pesos (safetensors), tokenizer, templates de prompt e um manifesto registrando quantização e saídas esperadas para prompts “golden”.
• Prompts “golden”: 100–200 prompts que exercitem seus workloads reais: chats curtos, contextos de 8–32K, RAG com contextos longos, autocompletar de código, streaming.
• Métricas: Para cada backend, registre tokens/segundo em steady-state, latência do primeiro token, VRAM e utilização de vCPU. Derive $/1K tokens usando seus preços reais de instância.
• Containers: Publique imagens artefatadas por backend: CUDA, ROCm, CPU/Metal. Faça pin de combinações driver-toolkit. Inclua SBOMs e varreduras de CVEs conhecidos.
• Gates por números: Um PR falha se qualquer backend regredir >10% em custo ou FTL sem uma exceção. Incorpore esses gates no seu CD.

Stacks de serving que sobrevivem entre hardwares

Escolha dois, não um.

• vLLM: Batching de alto throughput, trajetória multi-backend (CUDA primeiro, ROCm cada vez mais viável) e uma API estilo OpenAI. Excelente padrão para inferência em servidor.
• TGI: Caminho sólido em CUDA, história razoável em ROCm para muitos modelos, forte integração com Hugging Face. Boa segunda fonte.
• llama.cpp: O canivete suíço. Backends CPU, Metal, Vulkan com GGUF. Menor throughput, mas inestimável como fallback e para a borda.
• MLC LLM: Melhor forma de entregar para mobile e GPUs diversas de desktop via TVM. Útil quando seu roadmap de produto requer on-device.

Seja o que for que você escolha, estabilize sua API pública e a autenticação na frente deles. Seu app não deve saber — nem se importar — qual backend está ativo nesta semana.

Quantização sem surpresas

Quantização traz desempenho e também é um campo minado de portabilidade.

• Padronize em BF16/FP16 como baseline e INT8 para throughput. Trate INT4 como um tier de otimização com testes de aceitação explícitos para acurácia e taxas de alucinação.
• Escolha métodos que “viajem”: SmoothQuant e AWQ são amplamente suportados; variantes de GPTQ podem ser frágeis por backend.
• Teste contextos longos: A quantização interage mal com atenção de contexto longo em alguns kernels. Inclua testes de 32K+ no seu harness se o produto suportar.

Treinamento e fine-tuning: seja honesto sobre o escopo

Portabilidade para pré-treinamento completo é orçamento de pesquisa. Para startups e scale-ups, foque em inferência e tuning eficiente em parâmetros.

• LoRA/QLoRA fine-tunes em CUDA e ROCm são viáveis em 2026. Planeje rodá-los onde houver capacidade, mas mantenha seu serving portável primeiro.
• Gaudi e TPU podem ser excelentes jogadas para treinamento. Só não deixe a vitória no treinamento forçar você a servir exclusivamente neles se a sua unit economics preferir H100 ou MI300X depois.

Segurança e operabilidade não têm salvo-conduto

Multi-backend significa exposição a múltiplos drivers e runtimes. Aperte a higiene.

• Drivers: Use contêineres de driver mantidos pelo fornecedor ou módulos de kernel com acompanhamento de CVEs conhecidos. Não instale drivers ad hoc nos hosts.
• Reprodutibilidade: Builds herméticas com compiladores fixados (Triton, TVM) e wheels verificados. Gere SBOMs e atestações.
• Isolamento: Para nós multi-tenant, use MIG na NVIDIA e cgroup em todo lugar. Não deixe panics de kernel em um runtime derrubarem outro.
• Observabilidade: Exporte contadores de hardware (largura de banda de HBM, ocupação de SM), não apenas tokens/seg. Alerta para regressões de latência do primeiro token, não apenas para throughput no 95º percentil.

Quem toca isso? Monte um time de compiladores “duas pizzas”

Se você centraliza todo trabalho de IA nos times de features, a portabilidade morre por mil TODOs. Aloque 2–3 engenheiros cuja missão é fazer os modelos rodarem em qualquer lugar.

• Habilidades: PyTorch 2.x graph capture, Triton, FlashAttention, fundamentos de ROCm/HIP, ONNX/XLA e um compilador de IR (TVM ou IREE).
• Mandato: Ser dono do harness de portabilidade, bundles “golden” de modelos, imagens de contêiner e gates de performance. Ser dono dos benchmarks de fornecedores e insumos para compras.
• Cadência: “Dia de futuros” trimestral para testar novos SKUs e clouds, com recomendação escrita de comprar/não comprar baseada em $/1K tokens e FTL.

Ângulo nearshore: use a geografia a seu favor

Se você está nos EUA, um pod nearshore no Brasil dá 6–8 horas de sobreposição e acesso a capacidade alternativa. Em 2026, MI300X e Gaudi frequentemente aparecem primeiro em regiões fora dos EUA e em nuvens regionais. Use essa arbitragem.

• Topologia: Mantenha tráfego interativo na região (US-East/West) para proteger a latência P95. Direcione inferência em lote e fine-tunes para a região mais barata — América do Sul, Europa, onde o mercado spot sorrir.
• Ops: O time nearshore roda o harness de portabilidade e certifica novas regiões/hardwares enquanto seu time central entrega features.

A provocação

Portabilidade não é ideal acadêmico. É o mecanismo que permite comprar o que for barato e disponível no próximo trimestre sem reescrever seu produto ou renegociar SLAs. NVIDIA talvez continue sendo sua melhor opção na maior parte do tempo. Ótimo — um plano de portabilidade facilita provar isso para compras com números. E quando não for, você não será a empresa pagando 30% a mais porque seu codebase não sabe escrever ROCm.

Um plano de ação de 30 dias

• Semana 1: Rode a auditoria de CUDA. Produza uma página com lacunas. Coloque de pé um segundo backend (ROCm ou CPU) no CI.
• Semana 2: Construa o harness de portabilidade: bundles de modelos “golden”, prompts e gates de performance. Containerize imagens CUDA e ROCm com SBOMs.
• Semana 3: Certifique dois runtimes (por exemplo, vLLM em CUDA e ROCm, llama.cpp em CPU/Metal). Gere o primeiro relatório de $/1K tokens e FTL nos hardwares que você consegue alugar nesta semana.
• Semana 4: Apresente um brief de compras com três opções: “Ficar”, “Migrar 25% para AMD” e “Adicionar fallback em CPU”. Inclua custo, risco e cronograma. Tome a decisão e execute.

Principais lições

• Desempenho por dólar muda trimestralmente; não amarre sua curva de custos ao roadmap de um único fornecedor.
• Portabilidade real abrange pesos, IR, runtime, kernels, quantização e serving — não só “conseguimos exportar ONNX”.
• Escolha dois stacks de serving e dois backends. vLLM + CUDA/ROCm, com llama.cpp como rede de segurança em CPU/Metal, cobre a maioria das necessidades.
• Meça o que importa: custo por 1K tokens e latência do primeiro token nos seus workloads reais.
• Quantize com cuidado: mantenha FP16/BF16 e INT8 como tiers “oficiais”; trate INT4 como opcional até a paridade fora de CUDA estar provada.
• Monte um pequeno “time de compiladores” para ser dono do harness de portabilidade, gates em CI e benchmarks de fornecedores.
• Use capacidade nearshore para qualificar novo hardware e explorar arbitragem regional de preços sem sacrificar a latência de usuários nos EUA.