Cache de prompts LLM #4: o melhor modelo para chat, RAG e agentes

TL;DR — Escolher o «melhor» LLM não é uma única questão de benchmark: depende de você estar entregando um chatbot, uma API de RAG/batch ou um agente de IA. Cada formato tem uma estrutura de prompt, um perfil de taxa de acertos, uma adequação de TTL e uma tolerância à latência diferentes, o que dita um emparelhamento ótimo distinto de modelo + estratégia de cache. Este guia se baseia nos números medidos na Parte 3 — o mesmo gateway, o mesmo SDK da OpenAI, trocando apenas o campo model em cada chamada.

Série: Parte 4 de 4 · Anteriormente: Parte 1 — Princípios do cache · Parte 2 — Comparação e avaliação de provedores · Parte 3 — Tutorial de código funcional

0. A fórmula universal de custo

Antes de mergulharmos nos casos de uso, eis a equação que toda escolha deveria 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

Quatro alavancas:

1. Baixar o preço unitário (P_in / P_out) → escolher um modelo mais barato.
2. Aumentar a taxa de acertos → reestruturar seu prompt; alinhar o TTL à cadência do seu tráfego.
3. Baixar o coeficiente de desconto do cache → escolher um provedor com cache mais robusto.
4. Escolher um provedor cujo prefill em cache seja o mais rápido → a latência importa para a UX.

Cada caso de uso a seguir aciona essas alavancas 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 multiturno + nova mensagem do usuário.
• Contexto médio: 4K–20K tokens.
• Os usuários são extremamente sensíveis ao tempo até o primeiro token (>2 s parece travado).
• Dentro de uma sessão, as requisições chegam com segundos a minutos de intervalo — bem dentro do TTL de cache de qualquer provedor.

Por que o chat faz cache quase sozinho

O chat é a carga de trabalho mais propícia ao 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 os intervalos entre mensagens ficarem abaixo do TTL (alguns minutos em todos os provedores), a parte do prompt de sistema ultrapassa 90 % de taxa de acertos sem esforço. Você não precisa de keep-alives.

Recomendações de modelos (medido em 2026-05)

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

Código de produção mínimo

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 para todos os modelos listados acima; nenhum marcador é necessário. Leia resp.usage.prompt_tokens_details.cached_tokens para confirmar os acertos durante o desenvolvimento.

Armadilhas em chatbots

• ❌ Não embuta o carimbo de data/hora atual no prompt de sistema ("Today is 2026-05-25 14:30:25"). A precisão em segundos invalida todo o cache.
• ❌ Não recomponha o histórico a cada turno — mantenha a ordem do array de mensagens idêntica byte a byte e em modo append-only.
• ✅ 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 contamina o prefixo compartilhado.
• ✅ Para sessões que esfriam além do TTL, envie um ping keep-alive de 1 token (veja a Parte 3 §8.2) antes de a próxima mensagem do usuário chegar.

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

Perfil de tráfego

• Q&A de RAG: entrada = sistema estável + documentos recuperados variáveis + consulta variável.
• Geração de conteúdo (textos 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 domina.

O problema difícil: a recuperação reordena seu prefixo

O problema central de cache do RAG: os documentos recuperados mudam entre chamadas, quebrando 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 ─────────↑

Três correções, em complexidade crescente:

Correção A — Empurre os documentos recuperados para o final, não para o 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 system (os ~3,5K tokens estáveis) entra em cache. Apenas a parte voltada ao usuário falha em cada chamada. Isso basta para a maioria dos RAG em produção. Taxa de acertos medida nesse padrão com gpt-5.4-mini: mais de 80 % nos tokens de sistema.

Correção B — Ordenação de recuperação determinística. Ordene os chunks recuperados por uma chave estável (doc_id crescente) em vez do score de relevância. Os chunks de alta frequência permanecem em posições consistentes e o prefixo coincide com mais frequência. Custa uma pequena perda de precisão no ranqueador; geralmente irrelevante.

Correção C — Marcadores de cache explícitos nativos via SDKs diretos do provedor. Se você está diretamente no Anthropic Claude (não via este gateway), o padrão multi-cache_control permite cachear «nunca muda» + «raramente muda» + «muda por tarefa» como pontos de quebra separados. Excelente para RAG complexos quando você pode carregar um SDK adicional.

Considerações de TTL para cargas de trabalho de API

• Tráfego contínuo (endpoint de RAG 24/7): TTLs de 5 min funcionam bem — sempre há uma próxima requisição dentro da janela.
• Em rajadas / cron (batch diário às 09:00): use um provedor com TTL longo (deepseek-v4-flash é o mais longevo do nosso conjunto de testes) ou execute um ping keep-alive de 1 token a cada TTL/2 durante a janela de execução. Padrão na Parte 3 §8.2.

Recomendações de modelos por tarefa

† Os marcadores multi-cache_control do Claude são imbatíveis para RAG em camadas — use o SDK anthropic apontando para o gateway, veja a Parte 3 §2.

Esboço de custo de RAG (100K consultas/dia)

3K de sistema + 5K de documentos recuperados + consulta de 200 tokens + saída de 300 tokens. Os números são escalados a partir dos custos por chamada única medidos na Parte 3 §6 — single-tenant, sem carga concorrente.

Trate como ordem de grandeza. A produção real tem chamadas concorrentes, rajadas, e a distribuição do comprimento dos seus documentos recuperados dominará o cálculo.

Armadilhas de RAG / API

• ❌ Não ordene os chunks recuperados por score de relevância dinâmico — cada requisição recebe um prefixo único.
• ❌ Não perca os logs de uso ao fazer streaming — sua atribuição de custos desmorona. Passe stream_options={"include_usage": True} e armazene prompt_tokens_details.cached_tokens e usage.cost.
• ✅ Para tarefas em lote, empilhe as Batch APIs dos provedores (OpenAI Batch, Anthropic Message Batches) sobre o cache para mais ~50 % de desconto — feito fora deste gateway, chamando o provedor diretamente.

Caso de uso 3: agentes de IA (raciocínio multietapa, uso de ferramentas, cadeias longas)

Perfil de tráfego

• Uma tarefa de agente = muitas chamadas LLM, intercaladas com resultados de ferramentas.
• Contexto muito longo (sistema + ferramentas + histórico acumulado): tipicamente 30K–100K tokens na etapa 10.
• Prompts altamente estruturados: prefixo estável longo, pequena cauda variável.
• Tanto a latência quanto o custo importam — cada segundo extra de prefill adiciona uma espera visível, e um agente de 15 etapas multiplica isso por 15.

Por que os agentes dependem do cache

Cada etapa se anexa à chamada de ferramenta e ao resultado da etapa anterior. Sem cache, cada etapa repaga o prefill sobre 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 crítica: as chamadas de ferramentas e seus resultados devem ser append-only e idênticos byte a byte ao longo das etapas. Qualquer reescrita ou reordenação mata o cache a partir daquele ponto. O bug de agente mais comum de longe é «limpei o resultado da ferramenta antes de reenviar» → a taxa de cache cai a zero → o custo e a latência se multiplicam.

Adequação de TTL — o único caso de uso em que importa

Uma tarefa de agente típica leva de 10 a 60 segundos; dentro de uma única tarefa, os TTLs padrão de 5 min são suficientes. Mas agentes que esperam uma aprovação humana («revise este plano e responda») podem ficar ociosos por minutos. Se o humano pausa por 10 minutos e o cache esfriou, sua etapa seguinte repaga o prefill sobre 50K tokens. Para esses fluxos de trabalho, ou:

• Use um provedor com TTL mais longo (deepseek-v4-flash é o mais longevo do nosso conjunto de testes), ou
• Envie um ping keep-alive a cada TTL/2 enquanto espera (veja a Parte 3 §8.2).

Recomendações de modelos para agentes

Os agentes exigem capacidade de raciocínio — escolha primeiro pela qualidade, depois otimize o custo.

† O padrão de 4 marcadores cache_control do Claude continua sendo a configuração mais forte para cache de agentes (desconto cumulativo de prefixo ao longo de mais de 10 etapas). Use o SDK anthropic apontando para o gateway — veja a Parte 3 §2 para o formato exato do payload e as opções de TTL.

Estimativa de custo real: uma tarefa de agente de 15 etapas

Suponha 5K de sistema + 3K de ferramentas + ~3K anexados por etapa, 15 etapas no total. Custo por chamada da Parte 3 §6 escalado ao formato do agente:

Mais uma vez, números aproximados. A variável dominante é se você realmente mantém o prefixo idêntico byte a byte de etapa para etapa.

Armadilhas de agentes

• ❌ Não reconstrua a lista de mensagens a cada etapa — mantenha o array idêntico byte a byte, apenas anexando.
• ❌ Não corte nem reformate os resultados de ferramentas — qualquer mudança de byte invalida o cache a jusante.
• ❌ Não compartilhe uma chave de cache entre instâncias de agentes concorrentes — suas sequências de etapas divergem e se contaminam mutuamente.
• ✅ Monitore cache_creation_tokens : cache_read_tokens por tarefa — uma proporção saudável é 1:50 ou melhor na etapa 10.

A matriz mestra de decisão

                            ┌─ 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 definir as expectativas com honestidade:

Se você precisa hoje de algum dos itens do lado direito, faça-o na sua camada de aplicação ou diretamente contra o SDK do provedor. O gateway é um proxy leve mais uma camada de precificação; tudo relacionado ao cache acontece na camada do modelo, upstream.

Conclusão final

A série de quatro partes se condensa em quatro linhas:

O cache traz duas vitórias, não uma. Custo E latência. Conteúdo estável primeiro, conteúdo volátil por último. A disciplina de prefixo é gratuita, faça em toda parte. Alinhe modelo + comportamento de cache ao caso de uso. Chat ≠ RAG ≠ Agentes. Meça no seu próprio tráfego. Benchmarks de execução única são um ponto de partida, não a resposta.

O caminho mais rápido a partir daqui: escolha na matriz acima o caso de uso mais próximo do seu, aplique as mudanças estruturais (prefixo estável primeiro, recuperação determinística, estado de agente idêntico byte a byte), registre cached_tokens e usage.cost por uma semana e então reavalie.

Perguntas frequentes

Qual LLM é o mais barato para um chatbot em idioma chinês? deepseek-v4-flash e qwen3.5-flash são uma ordem de grandeza mais baratos que os modelos ajustados para inglês em texto em chinês no nosso conjunto de testes, igualando o gpt-5.4-mini em qualidade em cargas de chat típicas.

Qual é o melhor LLM para RAG em 2026? Para inglês: gpt-5.4-mini com o layout de prompt da Correção A (tokens de sistema no início, referências no fim) dá mais de 80 % de taxa de acertos na porção estável. Para chinês: deepseek-v4-flash. Para documentos muito longos consultados com frequência: gemini-2.5-pro (lida nativamente com contextos de mais de 1 milhão de tokens).

Devo usar GPT ou Claude para agentes? Ambos são fortes; a escolha depende de quanta disciplina de cache você quer investir. O padrão de 4 marcadores cache_control do Claude (via o SDK anthropic contra o gateway) é excepcionalmente poderoso para prefixos cumulativos de agentes — ~90 % de redução do custo de entrada quando o prefixo está quente, ao longo de mais de 10 etapas. Se você preferir ficar no cliente no formato OpenAI e aceitar ~50 % de economia de cache sem nenhum marcador, gpt-5.4-mini ou gpt-5.5-pro é a opção de menor atrito.

Quanto posso economizar de forma realista ao migrar de um uso «ingênuo» para um «otimizado» do LLM? Nas execuções medidas nesta série: 50–88 % de redução de custo e 30–60 % de redução de TTFT com o mesmo modelo. A maior parte do ganho vem de levar sua taxa de acertos acima de 80 %, não de escolher um modelo diferente.

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

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

← Voltar ao blog