A pergunta não é se um modelo pequeno é bom o suficiente. É qual das suas tarefas cabe nele.

Quarto de cinco posts sobre gateway de IA. Antes: por que existe, como montar e quanto custa em latência. Depois: o SLM destilado que custou 36× menos.

Resumo

• Modelo local é a única opção que transforma "combinei por contrato que o meu dado não é retido" em "o meu dado não sai".
• SLM é modelo de 1 a 10 bilhões de parâmetros treinado para um domínio. Entrega perto do mesmo resultado em tarefa estreita, por uma fração do custo.
• A conta de VRAM está na seção 3. O ponto de equilíbrio genérico que circula por aí é enganoso, e a seção 3.2 diz por quê.
• O erro é tratar isso como decisão binária. Não é "local ou API". É qual rota vai para onde — e é por isso que essa decisão mora no gateway.
• As cinco perguntas que decidem se isso fica de pé em produção — latência, concorrência, capacidade, o que fazer quando ela acaba, e infraestrutura — estão na seção 5.

1. O que só o modelo local resolve

Existem três formas de reduzir o risco de mandar dado para um modelo, e elas não são equivalentes.

Anonimização na fronteira remove identificador antes da chamada sair. Funciona bem para dado pessoal — CPF, e-mail, telefone — e é obrigatória se houver dado de cliente no fluxo. Não resolve segredo industrial, porque não existe como anonimizar a lógica de um algoritmo proprietário sem destruir a pergunta.

Contrato com o provedor — retenção zero, cláusula de não-treinamento, região de processamento. Reduz risco de verdade e depende de confiança contratual. O dado sai; você combinou o que acontece com ele.

Modelo local — o dado não sai. É a única das três que transforma a garantia de contratual em técnica.

Essa diferença parece filosófica até você estar numa auditoria. "Temos cláusula de retenção zero" e "o tráfego nunca deixou a nossa rede" são afirmações de natureza diferente, e a segunda não depende do comportamento de terceiro.

Sobre quais restrições tornam isso obrigatório escrevi em Sua política de uso de IA não impede o vazamento.

2. O que é um SLM, e por que ele mudou a conta

SLM é modelo de linguagem pequeno — na prática, de 1 a 10 bilhões de parâmetros, treinado ou ajustado para um domínio específico em vez de competir em generalismo.

O que mudou não foi a existência deles, foi a qualidade. Um modelo de 7 a 14 bilhões de parâmetros hoje resolve tarefa estreita e bem definida num nível que há dois anos exigia modelo de fronteira. E três propriedades vêm junto:

• Custo de inferência muito menor. Estimativas públicas falam em reduções de até 90% em cenário de alta carga.
• Latência menor. Arquitetura compacta, resposta mais rápida — o que importa em fluxo interativo.
• Roda onde você quiser. Laptop, servidor da empresa, edge. É isso que fecha o problema da seção 1.

A ressalva honesta: modelo de 7 a 14 bilhões não entrega a qualidade de um modelo de fronteira em tarefa aberta. Ele empata em tarefa estreita e perde em tarefa que exige raciocínio longo, código complexo ou síntese sobre muito contexto.

Por isso a pergunta certa não é "modelo pequeno é bom o suficiente". É qual das minhas tarefas cabe nele.

3. A conta

3.1 VRAM

Regra prática: cerca de 0,5 GB de VRAM por bilhão de parâmetros em quantização de 4 bits.

Um modelo de 8 bilhões roda em torno de 4 a 5 GB. Um de 14 bilhões, em torno de 7 a 8 GB. Isso cabe numa GPU de consumo, e é a razão pela qual isso deixou de ser assunto de empresa grande.

3.2 A conta não é só custo por token

Circula uma versão simplificada dessa conta que é enganosa:

consumo mensal de tokens × preço do provedor  vs  custo fixo da máquina

Ela dá um número, e o número quase sempre está errado — porque quatro variáveis mudam o resultado mais que o preço do token.

Perfil da carga. Rajada e carga contínua têm contas opostas. Um pipeline que processa lotes ocupa a GPU por algumas horas no mês; um chat interativo precisa dela ligada o tempo todo. A mesma máquina, no mesmo preço, é barata num caso e cara no outro. Foi o que decidiu o resultado que eu medi em Troquei um LLM proprietário por um modelo aberto de 9B.

Throughput e concorrência. Preço por token pressupõe que você extrai do hardware o throughput nominal. Na prática isso depende de batching, de quantas requisições simultâneas você tem e de quanto contexto cada uma carrega. GPU ociosa esperando requisição custa igual a GPU trabalhando.

Disponibilidade. A API tem redundância embutida no preço. Local, você paga por ela: segunda máquina, ou aceitar que a funcionalidade cai quando a GPU cai. Se a resposta for "aceito que caia", ótimo — mas isso é uma decisão de produto, e precisa ser tomada por quem responde pelo produto.

Localidade e operação. Onde a máquina fica, quem faz a manutenção, quem atualiza driver e modelo, quem é chamado às três da manhã. Isso não aparece em nenhuma planilha de comparação e é custo real.

A conclusão prática: não use ponto de equilíbrio genérico para decidir. Meça o seu perfil de carga primeiro — as horas de GPU que você realmente consome, não as que a fórmula sugere. E se o número não fechar, o modelo local ainda pode ser a decisão certa: só que aí é decisão de conformidade, não de economia, e precisa ser aprovada como tal. O erro é vender internamente como redução de custo algo que é decisão de risco, porque aí o projeto é cobrado por um resultado que ele nunca ia entregar.

3.3 Ollama ou vLLM

• Ollama para prototipar e para carga baixa. Sobe em um comando, e é onde você descobre quais tarefas cabem.
• vLLM para produção. O PagedAttention entrega throughput muito superior sob concorrência, que é exatamente onde o Ollama para de servir.

O caminho normal é começar no Ollama para responder a pergunta da seção 4, e migrar para vLLM quando a resposta for "cabem várias".

4. Quais tarefas cabem

Depois de rodar isso em alguns times, o padrão é consistente. Cabem bem:

• Classificação — roteamento de ticket, análise de sentimento, triagem
• Extração de campo — pegar CNPJ, valor e vencimento de um documento
• Reescrita com formato fixo — normalizar descrição, padronizar nomenclatura
• Embedding e busca semântica — aqui o modelo pequeno é o padrão, não a exceção
• Redação de rascunho curto com estrutura definida

Não cabem:

• Código em base grande, com contexto de múltiplos arquivos
• Raciocínio de várias etapas com ferramentas
• Síntese sobre muito contexto — relatório longo, análise comparativa
• Qualquer coisa aberta, onde a qualidade da resposta é o produto

Repare que a lista que cabe é, na maioria das empresas, a lista de maior volume. Classificação e extração rodam milhares de vezes por dia; raciocínio complexo roda dezenas. É por isso que a economia aparece mesmo quando o modelo pequeno cobre só uma parte das tarefas.

5. As cinco perguntas operacionais

Escolher o modelo é a parte fácil. Estas cinco decidem se ele fica de pé em produção, e nenhuma delas se responde com benchmark publicado.

5.1 Qual latência você precisa entregar, e medida como?

Dois números diferentes, e confundir os dois é o erro mais comum.

Time to first token é o que o usuário sente em fluxo interativo. Throughput em tokens por segundo é o que decide quanto tempo leva uma resposta longa ou um lote.

Um modelo de 8B numa GPU dedicada responde o primeiro token rápido com uma requisição só. Com trinta simultâneas, o mesmo modelo na mesma GPU entrega o primeiro token muito mais devagar, porque a requisição entra em fila.

Meça o que importa para o seu caso: se é chat, TTFT sob a concorrência que você espera no pico. Se é lote, tokens por segundo agregados. Número de requisição única não prevê nenhum dos dois.

5.2 Quantas requisições simultâneas, e o que limita

Aqui está a variável que quase ninguém dimensiona: o limite não são os pesos, é o cache de KV.

Os pesos ocupam um valor fixo — a conta de VRAM da seção 3.1. O cache de KV cresce com concorrência × tamanho do contexto, e com frequência passa dos pesos. Um modelo de 8B em 4 bits ocupa cerca de 5 GB; trinta sessões simultâneas com contexto longo somam vários gigabytes em cima disso.

Quando o cache enche, as requisições não ficam lentas — elas entram em fila. A latência não degrada suavemente, ela salta.

É por isso que o vLLM ganha do Ollama em produção: o PagedAttention é, na prática, um gerenciador de memória de cache de KV. Não é preferência de marca.

Dimensione pela concorrência de pico, não pelo tamanho do modelo.

5.3 Qual é a capacidade real da máquina

O número que você precisa não está em tabela nenhuma: tokens por segundo na sua concorrência alvo, com o seu tamanho de contexto.

Levanta em uma tarde: suba o modelo, dispare carga sintética no formato das suas requisições reais, e aumente a concorrência até a latência sair do aceitável. O ponto onde ela sai é a sua capacidade.

Faça isso antes de prometer SLA, não depois.

5.4 O que acontece quando a capacidade acaba

Essa é a pergunta que separa protótipo de produção, e ela tem três respostas legítimas — a escolha depende do que a rota faz.

Enfileirar. Cabe em processamento de lote, onde ninguém está esperando. Não cabe em fluxo interativo.

Promover para modelo remoto. A requisição que não cabe na GPU vai para a API. Resolve o pico sem provisionar hardware para ele — e só é válido se aquela rota puder sair da rede. Se o modelo local existe por conformidade, promover é vazamento, não elasticidade. Deixe isso explícito na configuração e no code review.

Recusar. Devolver erro é melhor que responder errado ou que violar a política de dado. Em rota regulada, é a única resposta certa.

O gateway é onde essa escolha vira configuração em vez de decisão de código — e por isso ela fica revisável em pull request.

5.5 Que infraestrutura isso exige de verdade

A GPU é o item mais visível e o menos trabalhoso. O que costuma faltar no plano:

• Onde a máquina fica. Nuvem com GPU, colocation ou servidor próprio. Cada uma tem uma conta e um contrato diferentes.
• Cold start. O Ollama descarrega o modelo após um tempo ocioso e a primeira requisição depois disso paga segundos de carregamento do disco. O vLLM mantém residente. Quem demonstra com Ollama e reporta latência baixa se surpreende na segunda-feira de manhã.
• Atualização de modelo. qwen3:8b é uma tag móvel. Fixe o digest e rode a sua bateria de avaliação a cada atualização, senão você troca o modelo em produção sem saber.
• Quem opera. Driver, versão de runtime, disco, monitoramento de VRAM, e quem é chamado quando a GPU cai às três da manhã. É custo recorrente e raramente entra na comparação com a API.

Nada disso inviabiliza modelo local. Mas se a justificativa foi economia e essas linhas não estavam na conta, a economia era menor do que parecia.

6. Como isso entra no roteamento

E aqui as quatro partes da série se encontram.

A decisão "esta tarefa vai para o modelo local, aquela vai para o de fronteira" não deve morar dentro de cada aplicação. Se morar, você tem a mesma dispersão de antes, agora com mais provedores.

Ela mora no gateway, como alias de tarefa:

  - model_name: rapido            # alto volume, tarefa estreita
    litellm_params:
      model: openai/gpt-5-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: local             # o que não pode sair da infraestrutura
    litellm_params:
      model: ollama/qwen3:8b
      api_base: http://host.docker.internal:11434

  - model_name: profundo          # raciocínio, código, tarefa aberta
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

A aplicação pede local e não sabe qual modelo está atrás. Trocar o Qwen por um Llama ajustado no seu domínio é uma linha de YAML, sem tocar em aplicação nenhuma.

E a régua de conformidade fica versionada: qual rota pode sair da empresa e qual não pode vira revisão de pull request, em vez de decisão espalhada em código.

E o aviso que vale mais que tudo nesta seção: o alias local não pode ter fallback. Se ele existe porque o dado não pode sair da rede, um fallback que o socorra numa falha não é resposta degradada — é violação de conformidade, silenciosa, no exato momento em que o sistema estava com problema. A config que eu publico não põe fallback no local de propósito. Se você adicionar um fallback global depois, confira que ele não pega essa rota.

6.1 O detalhe de latência que quase ninguém antecipa

Aqui é onde o overhead do gateway deixa de ser irrelevante.

Contra uma chamada de API que leva 2 segundos, os ~10 ms da camada são 0,5% — ruído. Contra um modelo local que responde em 80 ms, os mesmos 10 ms são 12%.

Não é motivo para tirar o gateway do caminho. É motivo para saber disso antes de prometer latência, e para considerar um gateway em Go se o seu volume local for alto.

7. Por onde começar

Se você não tem restrição contratual ou regulatória sobre onde o código roda, não monte infraestrutura local. Contrato com retenção zero e configuração versionada resolvem a maior parte do risco, e você economiza o custo operacional.

Se você tem volume alto numa tarefa estreita, faça a conta da seção 3.2 antes de qualquer coisa. Se o volume não passa do ponto de equilíbrio, a decisão é de conformidade e precisa ser aprovada como tal.

Se o requisito é que o dado não saia, aí é modelo local, e o trabalho vira mapear quais tarefas cabem — o que se faz em uma semana com Ollama e um conjunto de casos reais.

Em qualquer um dos três, o passo anterior é o mesmo: saber quantas aplicações chamam modelo hoje e o que cada uma faz. Tem um script que responde isso em minutos.

Como ajudamos times a adotar IA

Trabalhamos com times de engenharia que buscam incorporar IA ao dia a dia de desenvolvimento — não como experimento, mas como parte real do fluxo de trabalho.

Isso passa por escolher as ferramentas certas para o contexto do time, configurá-las de forma que façam sentido para a política de dados da empresa e garantir que os desenvolvedores saibam usá-las de um jeito que realmente aumente a produtividade, em vez de gerar mais fricção.

Se você tem um time de desenvolvimento e está tentando colocar IA para trabalhar de forma séria, fale com a gente.