IA local ou na nuvem: onde está a real vantagem?

“Coloca uma IA pra fazer isso.” Ando lendo essa frase — e ouvindo em reunião — cada vez mais. Quase sempre dita sem a menor noção do que ela representa em custo, em infraestrutura e em manutenção. No papel parece trivial: é só plugar um modelo e pronto. Na conta do fim do mês, principalmente aqui no Brasil, a história é bem diferente.

A pergunta que quase ninguém faz antes é: rodar esse modelo, onde? Localmente, na sua própria máquina? Ou na nuvem, via API ou por uma instância que você mesmo sobe? A resposta honesta é a que ninguém gosta de ouvir — depende —, mas “depende” não é desculpa para não decidir. Depende de variáveis concretas, que dá para colocar na mesa e pesar. É isso que eu quero fazer aqui, inclusive com números.

O que está realmente em jogo

Antes de escolher um lado, vale separar as dimensões que de fato importam. A discussão costuma travar em “qual é mais barato” ou “qual é mais inteligente”, quando na prática o que decide é o conjunto:

• Custo — nuvem é despesa recorrente (por token ou por assinatura); local é investimento inicial em hardware mais energia.
• Privacidade e soberania dos dados — na nuvem, seus dados saem da sua infraestrutura; localmente, nada trafega para fora.
• Latência e disponibilidade — local funciona offline e sem depender de rede; nuvem depende de conexão e de limites de uso.
• Controle e customização — localmente você escolhe o modelo, o quant, o contexto, o prompt de sistema, tudo; na nuvem você opera dentro do que o provedor permite.
• Teto de qualidade — os modelos de fronteira ainda vivem na nuvem. Nenhum modelo aberto rodando em uma GPU de consumo empata com o topo de linha comercial.
• Manutenção — na nuvem, o provedor cuida de tudo; localmente, o time de operações é você.

Repare que quase nenhuma dessas dimensões é puramente técnica. A maioria é uma decisão de negócio disfarçada de decisão de infraestrutura.

A favor da nuvem

O argumento mais forte da nuvem é simples: você acessa o melhor modelo disponível sem manter nada. Sem GPU, sem driver, sem atualização, sem térmica. Você paga, chama a API e escala de zero a milhares de requisições sem tocar em hardware.

Para tarefas que exigem o máximo de capacidade — raciocínio complexo, código não trivial, análises longas — a diferença de qualidade ainda justifica o custo. E para quem está validando uma ideia, a nuvem elimina o atrito inicial: dá para testar hoje, sem comprar nada.

O preço disso vem em três formas: custo recorrente que cresce com o uso, dependência de um fornecedor (e da política de preços dele) e o fato de que seus dados saem de casa — o que, dependendo do setor, é um problema regulatório, não uma preferência.

A favor do local

Rodar localmente inverte quase todos esses pontos. O custo é de uma vez (a placa) mais energia; os dados nunca saem da sua máquina; você funciona offline; e você tem controle total sobre o modelo e o comportamento dele.

O preço aqui é o oposto: você assume o teto de qualidade do que cabe no seu hardware, engole a complexidade de operação e aceita que vai rodar mais devagar do que uma API otimizada em datacenter.

A boa notícia é que esse teto subiu muito. E é aí que entra um exemplo concreto.

Um exemplo prático: dá para rodar, e dá para produzir

A Soraya é um app jurídico desenvolvido pela code.py. Como boa parte do trabalho envolve documentos sensíveis — peças, contratos, dados de clientes —, ela é um caso em que manter tudo local não é luxo, é requisito: no jurídico, sigilo e LGPD pesam tanto quanto desempenho. Foi nesse contexto que testei rodá-la inteiramente em uma máquina modesta.

O setup: Gemma 4 26B-A4B em uma única RTX 3050, de apenas 6 GB de VRAM. Sim: um modelo de 26 bilhões de parâmetros em uma placa de entrada. Isso só é possível por causa da arquitetura — o Gemma 4 26B-A4B é um modelo Mixture-of-Experts (MoE) que, apesar dos 26 bilhões de parâmetros totais, ativa apenas cerca de 4 bilhões por token. Na prática, ele pensa como um modelo grande, mas processa cada token como um modelo pequeno.

Usei o quant Q8_0, com janela de contexto de 32K. Nessa precisão o modelo tem quase 28 GB — muito mais do que cabe nos 6 GB da placa —, então a maior parte dos pesos vive na RAM do sistema e a GPU cuida do caminho ativo. Justamente por ser MoE, com poucos parâmetros ativos a cada passo, esse arranjo não derruba o desempenho como derrubaria em um modelo denso equivalente.

Não é veloz. Mas é utilizável — e, para o dia a dia jurídico, suficiente: resumir peças, comparar cláusulas, rascunhar minutas, consultar uma base de documentos que não pode sair da máquina. Nada disso exige a velocidade nem o teto de qualidade de um modelo de fronteira. Precisa estar ali, funcionando, privado e sem custo por chamada. 16 tok/s, bem ajustado, já rende ganho de produtividade real — modesto, mas real.

Os dois extremos que saem caro

Entre uma 3050 rodando um MoE e a API de um modelo de fronteira existe um espectro inteiro — e é fácil escorregar para um dos dois extremos, cada um com sua própria armadilha e sua própria fatura.

Extremo 1: o rig superdimensionado. É tentador montar uma máquina parruda o bastante para rodar modelos de 100B, 120B localmente. O problema não é a capacidade — é o que vem junto. Uma placa capaz de segurar um modelo desse porte sozinha, como a RTX PRO 6000 Blackwell de 96 GB, não sai por menos de US$ 8 mil a US$ 13 mil hoje; montar com várias RTX 5090 de 32 GB (cada uma já rondando os US$ 4 mil, o dobro do preço de lançamento) não fica muito mais barato. Some CPU, RAM, fonte e placa-mãe e você chega fácil a um rig de US$ 10 mil a US$ 15 mil. No Brasil, com o dólar na casa dos R$ 5 e os impostos de importação sobre eletrônicos — que quase dobram o preço de tabela —, isso vira um investimento na faixa dos R$ 100 mil a R$ 150 mil.

E esse capital começa a depreciar no dia seguinte à compra. Aqui mora o risco maior: a evolução do hardware está rápida demais para imobilizar dinheiro nele. O rig de ponta de hoje é intermediário em dois anos — é risco real de obsolescência sobre capital parado. Some ainda backup e redundância (uma máquina só é ponto único de falha), o desafio de servir requisições em paralelo quando o time inteiro usa ao mesmo tempo, além de energia, refrigeração e manutenção. No fim, você paga — em dinheiro e em risco — por uma capacidade que talvez use raramente.

Extremo 2: tudo na nuvem, sem olhar a fatura. O oposto é igualmente caro, só que em forma de despesa recorrente. Os modelos de fronteira custam, em meados de 2026, por volta de US$ 5 por milhão de tokens de entrada e US$ 25 a US$ 30 por milhão de saída. Parece pouco — até você notar que um time fazendo trabalho de verdade queima milhões de tokens por dia. Uma equipe modesta em uso intenso passa fácil de US$ 3 mil a US$ 5 mil por mês (algo como R$ 15 mil a R$ 25 mil), todo mês, para sempre.

E se a saída for subir a sua própria instância na nuvem em vez de usar a API, o risco muda de forma mas não de tamanho: uma instância com GPU de porte para hospedar um modelo grande — uma p4d da AWS, por exemplo — roda perto de US$ 33 por hora, o que dá mais de US$ 20 mil por mês se ficar ligada o tempo todo. Esquecer uma dessas ligada num fim de semana já custa mais de US$ 1.500. É a depreciação do rig local virada do avesso: em vez de capital parado, opex sangrando — muitas vezes por capacidade ociosa.

Repare que os dois extremos falham pelo mesmo motivo: dimensionamento errado. Um super-investe em capacidade parada; o outro sangra pagando por capacidade que não aproveita.

Não é 8 ou 80

Se os dois extremos erram pelo mesmo motivo, o acerto é dimensionar de propósito. Na prática, local e nuvem não são exclusivos: convivem, e a melhor arquitetura costuma ser híbrida.

A lógica é de roteamento: o que é sensível, repetitivo e não exige o topo de qualidade fica local — uma base enxuta, como a própria 3050 do exemplo; o que é pontual, difícil e vale o custo vai para a nuvem. Você usa o modelo local como primeira linha e escala para a API só quando o problema justifica. Você é dono da base e aluga os picos. Assim protege dados, corta o custo recorrente nas tarefas de rotina, não imobiliza capital num rig que vai envelhecer — e ainda tem acesso ao melhor modelo quando realmente precisa dele.

Como decidir, na prática

Os três cenários, lado a lado:

E um guia rápido para não travar na análise:

Prefira local quando: os dados não podem sair da sua infraestrutura, o volume de uso é alto e constante (o custo recorrente da nuvem dói), você precisa funcionar offline, ou quer controle total sobre o modelo.

Prefira nuvem quando: você precisa do máximo de qualidade, o uso é esporádico ou imprevisível, você não quer manter hardware, ou está validando uma ideia e quer velocidade para começar.

Vá de híbrido quando: — e esse é o caso da maioria — você tem tarefas de rotina que cabem localmente e tarefas críticas que merecem a nuvem.

Fechando

A pergunta certa não é “local ou nuvem?”. É “qual tarefa, em qual lugar?”. A infraestrutura de IA madura não escolhe um lado — ela distribui a carga de acordo com custo, sensibilidade e exigência de cada trabalho.

E o recado que fica do experimento com a Soraya é esse: rodar um modelo capaz, de forma privada, em hardware de consumo, deixou de ser proeza de laboratório. É modesto, exige ajuste, mas já entrega valor. Para muita gente, isso muda a conta inteira.

E você — já testou rodar um modelo localmente, ou ainda está 100% na nuvem? Curioso para saber onde essa linha está caindo para vocês.

Apêndice técnico — como reproduzir

Para quem quiser tirar a prova, esse é o setup exato por trás da Soraya.

Máquina: Intel Core i7 (20 threads), 32 GB de RAM, RTX 3050 (6 GB). Backend: llama.cpp (llama-server).

bash

llama-server \
  --hf-repo ggml-org/gemma-4-26B-A4B-it-GGUF \
  --hf-file gemma-4-26B-A4B-it-Q8_0.gguf \
  --jinja \
  --alias gemma-4-26B-A4B \
  --flash-attn on \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --parallel 1 \
  -ngl 99 \
  --n-cpu-moe 29 \
  --temp 1.0 --top-p 0.95 --top-k 64 --min-p 0.0 --repeat-penalty 1.0 \
  --threads 20 \
  --host 0.0.0.0 --port 8080 \
  --metrics

O que faz um modelo de ~28 GB caber em 6 GB de VRAM:

• --n-cpu-moe 29 — o pulo do gato. Mantém os pesos dos especialistas (a maior fatia do modelo) na RAM do sistema, deixando a GPU responsável só pela atenção e pelo cache. É isso que torna 6 GB suficientes.
• -ngl 99 — manda todas as camadas para a GPU; o --n-cpu-moe é quem “puxa de volta” os especialistas para a CPU.
• --flash-attn on + --cache-type-k/v q8_0 — enxugam o cache de contexto (KV cache), essencial para segurar os 32K sem estourar a memória.
• --threads 20 — como os especialistas rodam na CPU, o número de threads pesa direto no desempenho; casei com os 20 threads do i7.
• --temp / --top-p / --top-k / --repeat-penalty — os valores recomendados pelo Google para o Gemma 4.

Nesse arranjo, o teto ficou em ~16 tok/s a 32K de contexto. Modesto, mas suficiente para trabalhar.