Corte os custos da API LLM com trabalhos em lote e cache de prompt: um manual prático

Muitas equipes pagam demais pelas APIs LLM porque enviam todas as solicitações pelo mesmo caminho síncrono. Isso é apropriado para bate-papo, assistentes de codificação, agentes de suporte, fluxos de pagamento e qualquer coisa que esteja aguardando um usuário. É um desperdício de avaliações, marcação, enriquecimento, varreduras de moderação, incorporação de preenchimentos, relatórios noturnos e pré-processamento de conteúdo.

A questão prática não é “Qual modelo é mais barato?” É: qual trabalho realmente precisa de uma resposta imediata e qual trabalho pode esperar? Depois de responder a isso, o controle de custos da API de IA se torna um fluxo de trabalho de engenharia: classificar o tráfego, enviar trabalhos tolerantes à latência para processamento em lote onde houver suporte, estruturar prompts repetidos para armazenamento em cache e medir a economia real após falhas, novas tentativas e sobrecarga operacional.

Comece com uma auditoria de custos por carga de trabalho, não por modelo

Antes de alterar a arquitetura, exporte uma amostra do uso recente da API e agrupe-a por carga de trabalho. Uma tabela de auditoria útil deve incluir:

• Endpoint e modelo: conclusões de bate-papo, respostas, incorporações, moderação ou endpoints específicos do provedor.
• Média de tokens de entrada e saída: separe prompts longos de tarefas de classificação curtas.
• Forma do prompt: instruções estáveis do sistema, exemplos reutilizáveis, esquemas, contexto de recuperação e dados dinâmicos do usuário.
• Requisito de latência: segundos, minutos, horas ou próximo dia útil.
• Visibilidade do usuário: se uma pessoa está aguardando o resultado.
• Taxa de novas tentativas e falhas: solicitações malformadas, falhas de validação, tempos limite do provedor, trabalhos expirados e envios duplicados.
• Propriedade: projeto, equipe, cliente, chave de API ou conta de parceiro.
• SLA comercial: o último horário em que o resultado ainda é útil.

Esta auditoria geralmente revela que o “tráfego LLM” não é uma carga de trabalho. É uma combinação de recursos de produtos interativos, automação interna, relatórios, preparação de dados e avaliação de qualidade. Tratá-los como um centro de custo esconde as economias mais fáceis.

Use um classificador de carga de trabalho de três vias

Um classificador simples evita que as equipes movam o tráfego errado para o lote e sejam surpreendidas por expectativas perdidas.

Faixa 1: solicitações interativas em tempo real

Mantenha-os sincronizados. Eles incluem UX de bate-papo, copilotos, agentes de suporte, revisão humana, pesquisa ao vivo ou fluxos de recuperação e chamadas de ferramentas com efeitos colaterais imediatos. Se um usuário estiver esperando, o valor de uma resposta mais barata poderá ser apagado pela latência.

Recomendação: otimize essa via com seleção de modelo, corte imediato, gerenciamento de limite de taxa, armazenamento em cache quando aplicável e novas tentativas cuidadosas. Não envie-o para uma fila em lote de 24 horas, a menos que o produto o apresente explicitamente como uma tarefa em segundo plano.

Faixa 2: solicitações nearline que podem esperar minutos

Esses trabalhos não precisam bloquear o carregamento de uma página, mas ainda podem ter uma expectativa de mesma sessão ou mesma hora. Os exemplos incluem análise de documentos pós-upload, enriquecimento de CRM após o envio do formulário ou um relatório que pode notificar o usuário quando estiver pronto.

Recomendação: coloque o trabalho quase imediato atrás de uma fila com estados de status explícitos. Dependendo do suporte e do prazo do provedor, execute-o em pequenos lotes ou em trabalhadores síncronos com prioridade mais baixa. Essa via se beneficia de IDs de tarefas, webhooks e progresso visível ao usuário.

Faixa 3: solicitações em lote off-line que podem esperar até 24 horas

Esta é a principal via de otimização de custos. Bons candidatos incluem:

• avaliações em larga escala;
• rotulagem do conjunto de dados;
• enriquecimento de catálogo ou CRM;
• resumo noturno;
• filas de revisão de conformidade;
• incorporar preenchimentos;
• varreduras de moderação;
• geração de relatórios periódicos;
• pré-processamento de conteúdo antes da indexação ou publicação.

Fato: os principais provedores agora oferecem APIs em lote assíncronas para cargas de trabalho adequadas. A API Batch da OpenAI lê solicitações de um arquivo carregado, grava os resultados em um arquivo de saída e direciona o processamento em 24 horas. A OpenAI afirma que o uso compatível da API em lote é oferecido com um desconto de 50% no custo em comparação com APIs síncronas. A API Message Batches da Anthropic foi projetada para grandes volumes de solicitações de mensagens, processamento assíncrono, maior rendimento e custo 50% menor. A API Gemini Batch do Google foi projetada para solicitações assíncronas de grande volume a 50% do custo padrão, com tempo de resposta alvo de 24 horas.

Compensação: “até 24 horas” é excelente para preenchimentos e avaliações, mas inaceitável para fluxos de trabalho interativos. O lote é uma estratégia de agendamento, não um substituto universal para a inferência síncrona.

Projete o caminho do lote como um ciclo de vida do trabalho

O erro de implementação a evitar é tratar o lote como uma única chamada de API. É um ciclo de vida: aceitar o trabalho, validá-lo, persisti-lo, submetê-lo, pesquisá-lo, reconciliá-lo e expor os resultados.

Arquitetura de referência

1. Aceite uma solicitação normalizada: mantenha o formato da solicitação próximo ao formato de API existente compatível com OpenAI sempre que possível. Adicione metadados como projeto, equipe, cliente, chave de idempotência, prazo solicitado e centro de custo.
2. Classifique a carga de trabalho: atribua a solicitação a lote em tempo real, quase linear ou off-line. Isso deve ser baseado em políticas e não oculto no código do aplicativo.
3. Crie um ID de trabalho: retorne um identificador de trabalho imediatamente para trabalho quase on-line e off-line.
4. Validar compatibilidade: verifique se o provedor e o modelo selecionados suportam lote para o endpoint solicitado, modalidade, tamanho do arquivo, ferramentas, formato de resposta e outros recursos.
5. Persistir linhas de solicitação: armazena linhas JSONL normalizadas ou cargas específicas do provedor. Inclua um ID de linha estável para reconciliação.
6. Enviar o lote: faça upload do arquivo de solicitação ou da carga útil do lote in-line, dependendo dos limites do provedor e do tamanho do trabalho.
7. Status da pesquisa: rastreie os estados do provedor, como validação, em andamento, concluída, com falha, expirada, cancelada e cancelada quando aplicável.
8. Armazene linhas de saída: escreva respostas bem-sucedidas, erros em nível de linha, uso de token, contagens de token em cache quando disponíveis e identificadores de provedor.
9. Notifique os consumidores: exponha um endpoint de recuperação, webhook, notificação de painel ou alerta do Telegram.
10. Reconciliar o faturamento: atribua o custo ao projeto original, à equipe, ao cliente, à chave de API e ao ID do trabalho.

Esse padrão mantém o aplicativo simples. As equipes de produto enviam trabalhos e recebem estados de trabalho. A camada de gateway ou orquestração lida com diferenças de provedores, arquivos em lote, novas tentativas e contabilidade.

Use estados de trabalho explícitos

Defina estados internos mesmo que cada provedor use nomes diferentes:

• enfileirado: aceito, mas não enviado;
• validando: provedor ou gateway está verificando o arquivo;
• em execução: enviado e sendo processado;
• concluído: todos os resultados disponíveis coletados;
• completed_with_errors: algumas linhas falharam na validação ou execução;
• expirado: prazo expirado antes de todas as linhas serem concluídas;
• cancelado: interrompido pelo usuário, sistema ou política;
• failed: falha no nível do trabalho que requer intervenção.

Fato: OpenAI documenta status de lote, incluindo validação, falha, em andamento, concluído, expirado, cancelado e cancelado. Ele também observa que se um lote expirar, o trabalho já concluído será devolvido e cobrado, enquanto o trabalho restante será cancelado.

Recomendação: nunca presuma que os trabalhos em lote são tudo ou nada. Crie a manipulação de status em nível de linha desde o início.

Calcular economias após falhas e despesas gerais

Um modelo simples de economia é suficiente para a maioria das equipes:

baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = desconto_batch_input_cost + desconto_batch_output_cost
custo_de_batch ajustado = custo_de_batch + custo_de orquestração + custo_de_armazenamento + custo_de reexecução
estimativa_economia = custo_base - custo_batch_ajustado

Em seguida, calcule isso por carga de trabalho, não globalmente. Uma suíte de avaliação noturna pode economizar substancialmente. Um fluxo de trabalho quase linear com muitas linhas malformadas, substitutos urgentes ou repetições repetidas pode economizar menos do que o esperado.

Acompanhe pelo menos estas métricas:

• sincronização versus gasto com token em lote;
• tokens de entrada e saída por modelo;
• contagem de trabalhos em lote e média de linhas por trabalho;
• taxa de falha em nível de linha;
• taxa de trabalho expirada;
• custo de nova execução;
• custo de substituição para sincronização;
• custo por equipe, projeto, chave, cliente e conta de parceiro.

Recomendação: trate o substituto síncrono automático como uma exceção, não como o padrão. Protege os prazos, mas se for utilizado em demasia pode anular as poupanças esperadas. Adicione uma política como “substituição somente se o prazo comercial for dentro de duas horas e o trabalho ainda não tiver sido iniciado”.

Adicionar cache de prompt para prefixos longos repetidos

O processamento em lote reduz o preço unitário do trabalho qualificado. O cache de prompts reduz o custo efetivo e a latência de prompts longos e repetidos quando o comportamento do provedor oferece suporte.

Fato: o cache de prompts OpenAI se aplica automaticamente a prompts com mais de 1.024 tokens em modelos compatíveis, armazena em cache o prefixo mais longo calculado anteriormente e informa cached_tokens nos detalhes de uso da API. A OpenAI diz que os caches de prompt normalmente são limpos após 5 a 10 minutos de inatividade e removidos dentro de uma hora após o último uso, e que os caches de prompt não são compartilhados entre organizações.

O padrão de implementação é simples: coloque o conteúdo estável em primeiro lugar e o conteúdo volátil por último.

Melhor estrutura de prompt para armazenamento em cache

Instruções do sistema
Texto de política estável
Esquema de saída estável
Exemplos estáveis
Contexto de referência reutilizável
---
Entrada específica de registro dinâmico
Metadados dinâmicos de usuário ou linha

Por exemplo, um trabalho de enriquecimento de catálogo pode reutilizar a mesma taxonomia, esquema de saída, regras de marca e exemplos em 50.000 produtos. Cada linha altera apenas o título, a descrição e os atributos do produto. Colocar o prefixo reutilizável primeiro dá ao provedor uma chance melhor de reutilizar a computação em cache quando houver suporte.

Compensação: o cache não é um armazenamento permanente e não deve ser tratado como garantido. As janelas de cache, o isolamento, o tamanho mínimo do prompt e os relatórios variam de acordo com o provedor. Meça os tokens armazenados em cache em vez de presumir a economia.

Valide o suporte do provedor antes do envio

As APIs em lote são diferentes. O gateway deve validar a elegibilidade antes de enviar uma vaga.

Fatos: a API OpenAI Batch não oferece suporte a streaming e tem limites de taxa de lote separados. Limitações de lote de documentos da Anthropic, incluindo um limite de 100.000 solicitações ou tamanho de lote de 256 MB, expiração em 24 horas, disponibilidade de resultados em 29 dias, limites de taxa e a possibilidade de que os lotes possam exceder ligeiramente os limites de gastos do espaço de trabalho configurados. O Google oferece suporte a solicitações em lote in-line para trabalhos menores com menos de 20 MB e arquivos de entrada JSONL para solicitações em lote maiores.

Use uma lista de verificação de compatibilidade:

• O modelo solicitado está disponível por meio da API em lote desse provedor?
• O endpoint é compatível?
• A solicitação requer streaming? Se sim, rejeite o lote.
• Ele usa ferramentas ou efeitos colaterais que devem acontecer imediatamente?
• O arquivo em lote excede os limites do provedor?
• O resultado esperado ainda é útil dentro da janela de conclusão do provedor?
• As saídas estão disponíveis por tempo suficiente para que os sistemas downstream as recuperem?
• A carga de trabalho pode tolerar a conclusão parcial?

Recomendação: falhar na validação antecipadamente com um motivo claro. Um candidato em lote rejeitado é mais barato do que um trabalho expirado ou malformado que precisa ser retrabalhado posteriormente.

Proteções para equipes, agências e parceiros

Os sistemas em lote podem gastar muito dinheiro silenciosamente porque processam arquivos grandes em segundo plano. Adicione controles antes da implementação ampla:

• Orçamentos em lote por equipe: limites separados de gastos on-line e off-line.
• Tamanho máximo de arquivo e contagem de linhas: imponha limites do provedor e seus próprios limites operacionais.
• Fila de mensagens mortas: preserva linhas inválidas com erros de validação para revisão.
• Chaves de idempotência: evitam cobranças duplicadas devido ao reenvio acidental.
• Revisão de PII: arquivos em lote podem criar novas obrigações de retenção de dados e privacidade.
• Política de retenção: defina por quanto tempo os arquivos de solicitação, arquivos de saída e registros serão armazenados.
• Política de notificação: alertar os proprietários quando os trabalhos falharem, expirarem ou excederem o orçamento.
• Atribuição: registre projeto, equipe, cliente, chave de API, modelo, provedor, ID do trabalho e ID da linha.

Para agências e revendedores, a atribuição é especialmente importante. Se um parceiro executar trabalhos de enriquecimento ou avaliação para muitos clientes, o sistema deverá relatar o custo por cliente e por trabalho, não apenas por fatura do fornecedor.

Como isso é mapeado para um gateway de API de IA

Um gateway de API de IA é um local natural para implementar isso porque já fica entre aplicativos e provedores de modelos. O gateway pode preservar uma superfície de API compatível com OpenAI para desenvolvedores e, ao mesmo tempo, adicionar agendamento com reconhecimento de custo.

Recursos úteis de gateway incluem:

• Faturamento unificado: compare gastos síncronos, em lote, em cache e substitutos em um só lugar.
• Análise de uso de IA: divida o uso por modelo, provedor, endpoint, equipe, projeto e chave de API.
• Controles de equipe: defina orçamentos separados para cargas de trabalho interativas e off-line.
• Atribuição de chave de API: identifique qual serviço ou cliente criou cada trabalho.
• Notificações de status: envie alertas quando trabalhos em lote forem concluídos, falharem, expirarem ou se aproximarem do prazo.
• Fluxos de trabalho da API de parceiros: permitem que agências ou revendedores criem empregos e recuperem resultados em nome dos clientes, preservando a contabilidade no nível do cliente.

Previsão: mais equipes gerenciarão os custos do LLM com políticas de agendamento, e não apenas com substituições de modelos. À medida que o suporte em lote amadurece entre os provedores, a arquitetura vencedora será roteada por urgência, compatibilidade de recursos e requisitos contábeis antes de ser roteada por preço de modelo.

Lista de verificação de implementação

• Exporte 30 dias de uso da API LLM.
• Classifique cada carga de trabalho como em tempo real, quase linear ou off-line.
• Escolha uma carga de trabalho off-line com propriedade clara e um prazo flexível.
• Valide o suporte em lote do provedor para o endpoint e modelo necessários.
• Defina estados de trabalho internos e status em nível de linha.
• Adicione chaves de idempotência, IDs de trabalho e IDs por linha.
• Armazene registros normalizados de solicitações e respostas com controles de retenção.
• Envie o primeiro lote com uma sinalização de recurso.
• Avalie o custo da linha de base síncrona versus o custo do lote ajustado.
• Reestruture prompts longos e repetidos para colocar os prefixos estáveis em primeiro lugar.
• Rastreie tokens armazenados em cache, linhas com falha, jobs expirados e gastos substitutos.
• Expanda somente depois que as economias e o comportamento operacional estiverem visíveis nas análises.

Conclusão acionável

Não comece o controle de custos da API de IA pedindo a cada equipe que use um modelo mais barato. Comece separando o trabalho urgente do trabalho que pode esperar. Mantenha as solicitações interativas síncronas. Mova avaliações, enriquecimento, marcação, preenchimentos, varreduras de moderação e relatórios para lote quando o suporte do provedor e os prazos de negócios forem adequados. Estruture prompts longos repetidos para armazenamento em cache. Em seguida, meça a economia real após falhas, novas execuções, armazenamento e custos de fallback.

A melhor implementação é enfadonha de propósito: IDs de trabalho, validação, status em nível de linha, orçamentos, análise de uso e propriedade clara. Essa camada operacional é o que transforma descontos de fornecedores em economias confiáveis.

Leitura relacionada

• Atribuição de chave de API e controles de gastos da equipe
• políticas de roteamento, novas tentativas e fallback para APIs LLM
• notas de implementação relacionadas ao Model Gate