Melhor LLM por caso de uso (2026): matriz de custos para chat, RAG e agentes

TL;DR — Não existe um único LLM “melhor” em todos os benchmarks. A escolha depende do que você está colocando em produção: um chatbot, uma API de RAG ou processamento em lote ou um agente de IA. Cada formato tem sua própria estrutura de prompt, taxa de acerto de cache, compatibilidade com TTL e tolerância a latência. Isso leva a combinações diferentes de modelo e estratégia de cache. Este guia parte dos números medidos na Parte 3 — mesmo gateway, mesmo SDK da OpenAI; basta trocar o campo model em cada chamada.

Série: Parte 4 de 5 · Anteriores: Parte 1 — Princípios de cache · Parte 2 — Comparação e avaliação de provedores · Parte 3 — Tutorial prático com código · Próxima: Parte 5 — Integração com LangChain

0. A fórmula universal de custo

Antes de entrar nos casos de uso, esta é a equação que toda escolha deve otimizar:

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

Há quatro variáveis:

1. Reduzir o preço unitário (P_in / P_out) → escolher um modelo mais barato.
2. Aumentar a taxa de acerto → reestruturar o prompt e alinhar o TTL ao ritmo do tráfego.
3. Reduzir o coeficiente de desconto do cache → escolher um provedor com condições melhores para cache.
4. Escolher um provedor com prefill em cache mais rápido → latência afeta diretamente a experiência do usuário.

Cada caso de uso abaixo combina essas variáveis de forma diferente.

Caso de uso 1: chatbots, atendimento ao cliente e assistentes

Perfil de tráfego

• Cada requisição = prompt de sistema longo (persona + conhecimento + regras) + histórico de várias interações + nova mensagem do usuário.
• Contexto médio: 4K–20K tokens.
• Os usuários são muito sensíveis ao tempo até o primeiro token (>2 s dá a impressão de que o sistema travou).
• Dentro de uma sessão, as requisições chegam em intervalos de segundos ou minutos, bem abaixo do TTL de cache de qualquer provedor.

Por que o chat quase se beneficia do cache sozinho

Chat é a carga mais favorável ao uso de cache. Dentro de uma única sessão:

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

Se o intervalo entre mensagens ficar abaixo do TTL — alguns minutos em todos os provedores — a parte do prompt de sistema alcança mais de 90% de taxa de acerto sem trabalho adicional. Não é necessário enviar keep-alives.

Modelos recomendados (medições de 2026-05)

* Medido com um prompt de sistema estável de 7.300 tokens, em uma única execução sequencial e sem carga concorrente. Consulte a Parte 3, §6 para ver a tabela completa.

Código mínimo para produção

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

Só isso. O cache é automático em todos os modelos listados acima; não é preciso usar nenhum marcador. Durante o desenvolvimento, leia resp.usage.prompt_tokens_details.cached_tokens para confirmar os acertos.

Armadilhas em chatbots

• ❌ Não inclua o timestamp atual no prompt de sistema ("Today is 2026-05-25 14:30:25"). A precisão de segundos invalida o cache em todas as chamadas.
• ❌ Não remonte o histórico a cada interação — preserve a ordenação do array de mensagens byte a byte e apenas acrescente novos itens.
• ✅ Coloque os dados de persona do usuário na primeira mensagem do usuário, não no prompt de sistema. Assim, a variação por usuário não compromete o prefixo compartilhado.
• ✅ Em sessões que ficam inativas além do TTL, envie um ping de keep-alive de 1 token (consulte a Parte 3, §8.2) antes da próxima mensagem do usuário.

Caso de uso 2: cargas de API (RAG, geração de conteúdo e processamento em lote)

Perfil de tráfego

• Perguntas e respostas com RAG: entrada = sistema estável + documentos recuperados variáveis + consulta variável.
• Geração de conteúdo (texto de marketing, código, tradução): template estável, dados variáveis.
• Processamento em lote (classificação de documentos, limpeza de dados): a mesma tarefa em alto volume.
• A latência é secundária; o custo por chamada é o principal fator.

O problema central: a recuperação reordena o prefixo

O principal problema de cache em RAG é que os documentos recuperados mudam entre as chamadas e quebram o prefixo no meio do prompt.

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

Há três soluções, em ordem crescente de complexidade:

Solução A — Coloque os documentos recuperados no fim, não no início.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

Resultado: toda a parte de system — os ~3,5K tokens estáveis — entra no cache. Apenas a parte voltada ao usuário não acerta o cache em cada chamada. Isso basta para a maioria das implementações de RAG em produção. Com esse padrão, medimos uma taxa de acerto superior a 80% nos tokens de sistema usando gpt-5.4-mini.

Solução B — Ordenação determinística da recuperação. Ordene os chunks recuperados por uma chave estável (doc_id em ordem crescente), não pela pontuação de relevância. Chunks acessados com frequência permanecem em posições consistentes, aumentando a chance de correspondência do prefixo. Isso reduz um pouco a precisão do ranker, mas normalmente sem impacto relevante.

Solução C — Marcadores nativos de cache explícito usando diretamente os SDKs dos fornecedores. Se você usa Anthropic Claude diretamente, fora deste gateway, o padrão com vários cache_control permite armazenar em cache, como breakpoints separados, as partes que “nunca mudam”, “mudam raramente” e “mudam a cada tarefa”. É uma excelente opção para RAG complexo quando você pode manter mais um SDK.

Considerações de TTL para cargas de API

• Tráfego contínuo (endpoint de RAG 24/7): TTLs de 5 minutos funcionam bem — sempre haverá outra requisição dentro dessa janela.
• Tráfego em rajadas / cron (lote diário às 09:00): use um provedor com TTL longo (deepseek-v4-flash teve a maior duração entre os modelos testados) ou envie um keep-alive de 1 token a cada TTL/2 durante a janela de execução. O padrão está na Parte 3, §8.2.

Modelos recomendados por tarefa

† Os vários marcadores cache_control do Claude são a melhor opção para RAG em camadas — use o SDK anthropic apontando para o gateway; consulte a Parte 3, §2.

Estimativa de custo de RAG (100 mil consultas/dia)

3K de sistema + 5K de documentos recuperados + consulta de 200 tokens + saída de 300 tokens. Os números foram dimensionados a partir dos custos por chamada medidos na Parte 3, §6 — tenant único e sem carga concorrente. Para sua própria carga, estime a fatura com a calculadora de custos de LLM e consulte os valores atuais na comparação de preços de modelos.

Considere esses valores apenas como ordem de grandeza. Em produção há chamadas concorrentes e rajadas de tráfego, e a distribuição do tamanho dos documentos recuperados será o principal fator no cálculo.

Armadilhas em RAG / API

• ❌ Não ordene os chunks recuperados por uma pontuação dinâmica de relevância — cada requisição terá um prefixo diferente.
• ❌ Não descarte os logs de uso ao fazer streaming — isso inviabiliza a atribuição de custos. Passe stream_options={"include_usage": True} e armazene prompt_tokens_details.cached_tokens e usage.cost.
• ✅ Em tarefas em lote, combine as Batch APIs dos fornecedores (OpenAI Batch, Anthropic Message Batches) com cache para obter mais aproximadamente 50% de desconto. Isso é feito fora deste gateway, chamando o provedor diretamente.

Caso de uso 3: agentes de IA (raciocínio em várias etapas, uso de ferramentas e cadeias longas)

Perfil de tráfego

• Uma tarefa de agente = várias chamadas ao LLM, intercaladas com resultados de ferramentas.
• Contexto muito longo (sistema + ferramentas + histórico acumulado): normalmente 30K–100K tokens por volta da etapa 10.
• Prompts muito estruturados: prefixo longo e estável, seguido de uma parte pequena e variável.
• Latência e custo importam — cada segundo adicional de prefill aumenta a espera perceptível, e um agente com 15 etapas multiplica esse impacto por 15.

Por que agentes dependem de cache

Cada etapa acrescenta a chamada e o resultado da ferramenta à etapa anterior. Sem cache, todas as etapas pagam novamente pelo prefill de dezenas de milhares de tokens.

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

Regra essencial: as chamadas de ferramentas e seus resultados devem ser somente anexados e permanecer idênticos byte a byte entre as etapas. Qualquer reescrita ou reordenação invalida o cache daquele ponto em diante. O erro mais comum em agentes é: “limpei o resultado da ferramenta antes de reenviá-lo” → a taxa de acerto cai para zero → custo e latência se multiplicam.

Compatibilidade com TTL — o único caso de uso em que isso faz diferença

Uma tarefa típica de agente dura de 10 a 60 segundos. Dentro da mesma tarefa, o TTL padrão de 5 minutos é suficiente. Mas agentes que aguardam aprovação humana (“revise este plano e responda”) podem ficar ociosos por vários minutos. Se a pessoa levar 10 minutos e o cache expirar, a etapa seguinte pagará novamente pelo prefill de 50K tokens. Para esses fluxos, há duas opções:

• Usar um provedor com TTL mais longo (deepseek-v4-flash teve a maior duração entre os modelos testados), ou
• Enviar um ping de keep-alive a cada TTL/2 durante a espera (consulte a Parte 3, §8.2).

Modelos recomendados para agentes

Agentes exigem capacidade de raciocínio. Escolha primeiro pela qualidade e depois otimize o custo.

† O padrão do Claude com 4 marcadores cache_control continua sendo a configuração mais eficiente para cache de agentes, com desconto cumulativo do prefixo em mais de 10 etapas. Use o SDK anthropic apontando para o gateway — consulte a Parte 3, §2 para ver o formato exato do payload e as opções de TTL.

Estimativa de custo real: tarefa de agente com 15 etapas

Considere 5K de sistema + 3K de ferramentas + cerca de 3K acrescentados por etapa, totalizando 15 etapas. O custo por chamada da Parte 3, §6 foi dimensionado para esse formato de agente:

Novamente, são valores aproximados. A principal variável é manter ou não o prefixo idêntico byte a byte entre as etapas.

Armadilhas em agentes

• ❌ Não reconstrua a lista de mensagens a cada etapa — preserve o array byte a byte e apenas acrescente novos itens.
• ❌ Não corte nem reformate os resultados das ferramentas — qualquer alteração de byte invalida o cache das etapas seguintes.
• ❌ Não compartilhe uma chave de cache entre instâncias concorrentes do agente — a ordem das etapas diverge e uma instância contamina a outra.
• ✅ Monitore cache_creation_tokens : cache_read_tokens por tarefa — na etapa 10, uma proporção saudável é 1:50 ou melhor.

Matriz de decisão completa

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

Referência rápida de TTL por caso de uso

O que este gateway faz e o que não faz

Para deixar as expectativas claras:

Se você precisa hoje de algum item da coluna da direita, implemente-o na camada da aplicação ou use diretamente o SDK do fornecedor. O gateway é um proxy leve com uma camada de preços; tudo relacionado a cache acontece no modelo upstream.

Conclusão

Toda a série pode ser resumida em quatro linhas:

Cache traz dois ganhos, não um. Custo E latência. Conteúdo estável primeiro, conteúdo variável por último. Manter o prefixo estável não custa nada; faça isso sempre. Combine o modelo e o comportamento do cache com o caso de uso. Chat ≠ RAG ≠ agentes. Meça com o seu próprio tráfego. Benchmarks de uma única execução são apenas um ponto de partida, não a resposta final.

O caminho mais rápido daqui é escolher na matriz acima o caso de uso mais próximo do seu, aplicar as mudanças estruturais — prefixo estável primeiro, recuperação determinística e estado do agente idêntico byte a byte —, registrar cached_tokens e usage.cost durante uma semana e então reavaliar.

Perguntas frequentes

Qual LLM é mais barato para um chatbot em chinês? deepseek-v4-flash e qwen3.5-flash custam uma ordem de grandeza menos que modelos otimizados para inglês ao processar texto em chinês no nosso conjunto de testes, com qualidade equivalente à do gpt-5.4-mini em cargas típicas de chat.

Qual é o melhor LLM para RAG em 2026? Para inglês, gpt-5.4-mini com o layout da Solução A — tokens de sistema no início e referências no fim — alcança mais de 80% de acerto na parte estável. Para chinês, deepseek-v4-flash. Para documentos muito longos consultados com frequência, gemini-2.5-pro, que aceita nativamente contextos com mais de 1M de tokens.

Devo usar GPT ou Claude para agentes? Os dois são fortes. A escolha depende do quanto você pretende investir em disciplina de cache. O padrão do Claude com 4 marcadores cache_control — usando o SDK anthropic com o gateway — é especialmente eficiente para prefixos cumulativos de agentes: reduz em cerca de 90% o custo de entrada depois que o prefixo aquece, ao longo de mais de 10 etapas. Se você preferir continuar no cliente compatível com OpenAI e aceitar uma economia de cache de cerca de 50% sem usar marcadores, gpt-5.4-mini ou gpt-5.5-pro exigem menos trabalho.

Quanto posso economizar de forma realista ao trocar um uso “ingênuo” de LLM por um uso otimizado? Nas execuções medidas nesta série: redução de 50–88% no custo e de 30–60% no TTFT com o mesmo modelo. A maior parte do ganho vem de elevar a taxa de acerto acima de 80%, não de trocar de modelo.

Por onde começo? Escolha na matriz o caso de uso mais próximo do seu. Aplique as mudanças estruturais no prompt. Meça cached_tokens e usage.cost durante uma semana de tráfego em produção. Só depois considere trocar de modelo.

Como comparar preços de APIs de LLM entre provedores? A página de modelos da Synthorai compara preços em tempo real: filtre por provedor e ordene pelo preço de entrada ou saída por milhão de tokens. Os valores permanecem sincronizados com os preços efetivamente publicados no gateway. A matriz acima indica o perfil de modelo adequado ao seu caso de uso; a página de modelos mostra quanto ele custa hoje.

Fontes e verificação: números medidos na Parte 3, §6, https://synthorai.io/v1 em 2026-05-25, SDK openai 2.38.0. Páginas de preços dos fornecedores: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Voltar ao blog