Como integrar LLM em ERP sem inflar a fatura da OpenAI: 7 padrões de arquitetura (RAG, caching, on-prem)

A história típica: LLM em ERP, fatura explode em 90 dias

Empresa contrata software house, manda "quero ChatGPT no nosso ERP". Software house entrega POC bonita. Tudo funciona. Aprovam. Em 90 dias o fluxo de produção está rodando. Fatura OpenAI no mês 3: R$ 78.000. Diretor pergunta "isso é normal?". Software house diz "é porque escalou". Empresa começa a procurar alternativa.

Esse é o padrão. Integrar LLM em ERP é fácil. Integrar LLM em ERP com custo previsível e escalável é arquitetura séria.

Esse post é o blueprint denso dos 7 padrões de arquitetura que separam integração de LLM "produção amadora" de "produção sustentável", com benchmarks reais de custo, decisões de modelo e exemplos de implementação. Aprofunde também em LLM integrado em sistemas empresariais: como fazemos na Bradata.

A economia básica: por que o custo escala mal por default

Custo de LLM = número de tokens × preço por token. Cada request normal "ingenuamente implementado" consome:

• Prompt do sistema (instruções) — 800 a 3.000 tokens
• Contexto do RAG — 1.500 a 8.000 tokens
• Pergunta do usuário — 50 a 300 tokens
• Resposta — 200 a 1.500 tokens

Total típico: 3.000 a 12.000 tokens por interação. Para Claude Sonnet ou GPT-4o ($3/M input, $15/M output em maio 2026):

• Request médio = $0,015 a $0,06 (R$ 0,08 a R$ 0,34)
• 10.000 requests/dia = R$ 24.000 a R$ 102.000/mês

Para uma empresa com 200 usuários ativos fazendo 5 requests/dia = 30.000/dia = R$ 72k–R$ 306k/mês. E pequeno aumento de uso vira fatura impossível de digerir.

Os 7 padrões abaixo reduzem o custo entre 60% e 95% com perda mínima ou nula de qualidade.

Padrão 1 — RAG com indexação inteligente (não joga PDF inteiro no prompt)

O erro comum: usuário pergunta "qual o prazo do edital 122/2026?". Sistema lê o PDF inteiro (200 páginas, 80k tokens) e joga no prompt. Resposta correta, custo absurdo.

O padrão certo: RAG (Retrieval-Augmented Generation) bem implementado:

1. Chunking inteligente: dividir documento em pedaços semanticamente coesos (não em pedaços de 500 tokens cego). Boas práticas: chunk por seção do documento, com overlap configurável (200 tokens) e metadata (página, seção, tipo).
2. Embeddings: gerar vetor de cada chunk com modelo de embedding barato (text-embedding-3-small da OpenAI, R$ 0,000.10 por 1k tokens, ou voyage-3-lite).
3. Storage vetorial: PostgreSQL com pgvector (open source, performante para até 10M chunks), Pinecone, Qdrant ou Weaviate.
4. Retrieval: pra cada pergunta, recuperar top-K chunks mais similares (K = 4–8 chunks tipicamente).
5. Re-ranking (opcional, em casos sensíveis): aplicar modelo de re-rank (Cohere Rerank, voyage-3-rerank) sobre os K iniciais para escolher os 3–4 melhores.

Resultado: prompt vai de 80k tokens (PDF inteiro) para 4k tokens (chunks relevantes). Custo cai 20x.

Pergunta → Embedding (40 tokens) → Busca vetorial (sub-segundo) → Top-K chunks (3k tokens) → LLM (4k tokens) → Resposta

Esse é o padrão central do VisionApp e do Copilot do Hub.

Padrão 2 — Model routing (modelo certo para tarefa certa)

Maioria das aplicações usa um modelo só para tudo. Erro caro. Modelos diferentes têm custos drasticamente diferentes:

Modelo	Input ($/M tok)	Output ($/M tok)	Bom para...
Claude Haiku 4.5	$0,80	$4	Classificação, sumarização curta, perguntas factuais
GPT-4o-mini	$0,15	$0,60	Tasks rápidas, classificação, JSON estruturado
Llama 3.1 70B (Groq)	$0,59	$0,79	Sumarização, perguntas factuais, code completion
Claude Sonnet 4.6	$3	$15	Raciocínio complexo, escrita longa, análise
GPT-4o	$2,50	$10	Multi-modal, raciocínio, JSON estruturado
Claude Opus 4.7	$15	$75	Casos onde precisa o melhor (estratégia, análise jurídica)

Padrão arquitetural: roteamento explícito por tarefa.

Pergunta entrante
    ↓
Classificador (Haiku, $0,001)
    ↓
- Pergunta simples factual → Haiku ($0,01)
- Sumarização → Llama 3.1 70B ($0,02)
- Análise complexa → Sonnet ($0,15)
- Decisão jurídica crítica → Opus ($0,50)

Em produção, 70–85% das requests caem em "simples" + "sumarização" e só 3–8% precisam de modelo top. Custo médio cai 60–80% vs "tudo em Opus/GPT-4o".

Padrão 3 — Prompt caching (até 90% de desconto em conteúdo repetido)

Claude e GPT-4o agora suportam prompt caching — você marca partes do prompt que se repetem (instruções do sistema, contexto fixo do cliente, documentação do produto) e o provider cacheia internamente. Acesso ao cache custa 10% do custo normal.

Aplicação típica: prompt do sistema do seu ERP tem 4.000 tokens (instruções de comportamento, exemplos, regras de negócio). Esse prompt vai em toda interação. Sem caching, custa 4.000 tokens × milhares de calls.

Com caching:

• Primeira request: 4.000 tokens normais
• Próximas: 4.000 tokens × 10% (R$ 0,002 vs R$ 0,02 por request)
• Cache vive 5 minutos no Claude, 5–60 minutos no OpenAI

Para sistema de produção com 10k requests/dia, esse único otimização economiza R$ 1.500–R$ 8.000/mês.

Padrão 4 — Batching para tarefas não-interativas

Muitas tarefas de LLM em ERP não são interativas — são jobs em background: classificar 500 novos editais, extrair atributos de 2.000 produtos novos do catálogo, gerar resumo de 1.000 emails.

Para esses, use Batch API (Anthropic e OpenAI oferecem):

• Você manda batch de até 50.000 requests em um arquivo
• Provider processa em até 24 horas (geralmente em 2–6h)
• Custo é 50% do preço normal

Para um processamento batch de 10.000 docs:

• Interativo: R$ 240
• Batch: R$ 120

50% off é só o headline. Combinado com Model Routing + Caching, batch processing pode ficar 75–88% mais barato que interativo.

Padrão 5 — Self-hosting para queries de alta frequência

Para uso interno, alta frequência e em casos onde privacidade importa (dados sensíveis, regulatório), self-hosting de modelos open-source vira competitivo.

Em 2026, modelos abertos confiáveis para produção:

Modelo	Tamanho	GPU mínima	Performance
Llama 3.1 8B (Q4)	4.6GB	A10 / RTX 4090	Bom para tasks simples
Llama 3.1 70B (Q4)	40GB	2x A100 80GB	Próximo a GPT-4o-mini
Qwen 2.5 72B	41GB	2x A100 80GB	Excelente para chinês, bom em geral
Llama 3.1 405B	230GB	8x H100	Comparável a Claude Sonnet
DeepSeek V3 671B	380GB	8x H100	Comparável a Claude Sonnet, ainda mais barato

Custo para servir Llama 3.1 70B em produção:

• AWS p4d.24xlarge (8x A100): US$ 32,77/hora = R$ 134k/mês rodando 24/7
• vs OpenAI: equivalente uso passa de R$ 200k/mês com igual volume

Break-even: quando uso > 30M tokens/dia, self-hosting compensa. Abaixo disso, API gerenciada é melhor (custo + ops).

Implementação prática: Ollama para desenvolvimento, vLLM para produção (alta throughput, batching automático), TGI (Text Generation Inference) da Hugging Face como alternativa.

Para clientes Bradata em segmentos regulados (saúde, governo, financeiro), oferecemos modelo plugável: o cliente escolhe se usa API ou self-hosting baseado em compliance e budget. Veja LLM integrado em sistemas empresariais.

Padrão 6 — Function calling estruturado em vez de prompt em texto

LLM sabe usar tools/functions estruturadas. Em vez de pedir resposta em texto e dar parse depois (caro, erro-prone), você define functions e o LLM chama exatamente o que precisa.

Erro comum:

Prompt: "Responda em JSON com {nome, cnpj, valor}. Não inclua texto adicional. Pergunta: qual o cliente do edital X?"

Padrão correto:

tools = [{
  "name": "consultar_cliente",
  "parameters": {
    "type": "object",
    "properties": {
      "cnpj": {"type": "string"},
      "incluir_historico": {"type": "boolean"}
    }
  }
}]

response = llm.create(messages=[...], tools=tools)
# resposta vem como tool_call estruturado, garantia de schema

Function calling tem garantia de schema (Anthropic e OpenAI validam). Menos tokens (sem instruções de formato), zero parse error, mais barato.

Padrão 7 — Observabilidade e gatekeeping de custo

Sem observabilidade, custo descontrola sem alerta. Stack mínima:

Métricas obrigatórias

• Requests por dia, por usuário, por tipo de tarefa
• Tokens consumidos (input + output) por modelo
• Custo em USD/BRL por dia
• Latência p50, p95, p99
• Taxa de erro (timeouts, rate limits, modelo retornou nada)

Ferramentas

• Langfuse (open source, self-hosted) — observabilidade LLM completa, traces, evals
• Helicone (SaaS) — proxy + observabilidade
• PostHog (já existente em muitas empresas) — eventos LLM mais analytics geral

Gatekeeping

• Rate limit por usuário (10 calls/minuto, 200/dia)
• Budget cap por tenant (mensal)
• Alerta de custo (notifica se passar limite diário)
• Kill switch se custo dispara (LLM "fica off" temporariamente até intervenção humana)

Sem isso, um bug ou uso abusivo pode gerar R$ 50k de fatura em uma noite.

Cenário comparativo: cada padrão somado

ERP médio brasileiro com 200 usuários, 5 requests/dia médio = 30k requests/dia. Custo evoluindo conforme padrões aplicados:

Cenário	Custo/mês estimado	Performance
Naïve (GPT-4o pra tudo, sem RAG, sem cache)	R$ 232.000	OK, mas lento
+ RAG	R$ 92.000 (-60%)	Igual
+ Model routing	R$ 38.000 (-58%)	Igual ou melhor
+ Prompt caching	R$ 22.000 (-42%)	Igual
+ Function calling	R$ 18.000 (-18%)	Melhor (menos erros)
+ Batching de jobs background	R$ 13.000 (-28%)	Igual (latência batch ok)
+ Self-hosting para Llama 3.1 70B em queries volumosas	R$ 9.500 (-27%)	Igual
TOTAL com todos os padrões	R$ 9.500/mês (-96%)	Igual ou melhor

R$ 232k para R$ 9,5k. 24x mais barato com arquitetura disciplinada.

A pegadinha: cuidado com sobre-engenharia

Antes de implementar os 7 padrões de uma vez, calibre pelo volume:

Volume diário	Padrões mínimos
< 100 requests	Use API só. Modelo único OK. Observability.
100–1.000	+ RAG + Caching. Model routing opcional.
1.000–10.000	Todos exceto self-hosting (custo já cabe em API)
10.000–50.000	Todos, considerar batching agressivo
> 50.000	Todos + self-hosting para queries de alta freq

Empresa começa com 200 requests/dia e implementa "Padrão 5 — self-hosting com 8x A100" no começo? Não faz sentido. Espera o volume justificar.

Compliance e privacidade — onde o padrão muda

Para clientes em saúde (LGPD dado sensível), financeiro (Bacen), governo (sigilo), e jurídico (segredo profissional), a equação muda:

• Dados não podem sair para OpenAI/Anthropic (sem acordo de processamento)
• Modelos com acordo de não-treinamento (Anthropic Enterprise, OpenAI Enterprise via Azure) podem servir
• Self-hosting vira preferência mesmo quando não é o mais barato

Para clientes Bradata nesses segmentos, oferecemos:

• Azure OpenAI (modelo OpenAI rodando no Azure brasileiro, dados não saem do tenant)
• Anthropic via Bedrock (dados ficam na conta AWS do cliente)
• Self-hosting Llama/Qwen/DeepSeek em GPUs dedicadas
• Pseudonimização antes de qualquer chamada externa quando aplicável

Conclusão

Integrar LLM em ERP sem arquitetura é fácil. Integrar de forma sustentável exige disciplina técnica. Os 7 padrões acima reduzem custo entre 60% e 96% com mesma ou melhor qualidade.

Se você está pensando em integrar LLM no seu sistema corporativo, fale conosco. A Bradata desenvolve sistemas com IA integrada desde 2023 — conheça nossas soluções (VisionApp, Hub, PDV) e o nosso post sobre como aplicamos LLM em sistemas empresariais reais.

A Bradata é uma software house brasileira com profundidade em desenvolvimento de sistemas empresariais com IA integrada. Veja cases e nossa abordagem de ERP sob medida.

---

Fontes: Anthropic API Pricing (May 2026), OpenAI API Pricing (May 2026), Groq Cloud Pricing, AWS GPU Instance Pricing (May 2026), Hugging Face Open LLM Leaderboard, projetos internos Bradata, "Building LLM Applications for Production" — Chip Huyen 2024, MLPerf Inference Benchmark 2025.