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

Muitas equipes pagam caro 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 para 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 IA API se torna um fluxo de trabalho de engenharia: classifica o tráfego, envia tarefas tolerantes à latência para processamento em lote onde houver suporte, estrutura solicitações repetidas de armazenamento em cache e mede 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 de API uso recente 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: separa prompts longos de tarefas de classificação curtas.
• Forma do prompt: instruções de sistema estáveis, 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, jobs expirados e envios duplicados.
• Propriedade: projeto, equipe, cliente, API chave 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 oculta 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 síncronos. 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 pode ser apagado pela latência.

Recomendação: otimize esta pista 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

Essas tarefas 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 linear 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 de conjunto de dados;
• enriquecimento de catálogo ou CRM;
• resumo noturno;
• filas de revisão de conformidade;
• incorporando 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. O lote API de OpenAI lê solicitações de um arquivo carregado, grava resultados em um arquivo de saída e direciona o processamento em 24 horas. OpenAI afirma que o uso compatível do Lote API é oferecido com um desconto de 50% no custo em comparação com APIs síncronas. Os lotes de mensagens API do Anthropic foram projetados para grandes volumes de solicitações de mensagens, processamento assíncrono, maior rendimento e custo 50% menor. O Gemini lote API de Google foi projetado para solicitações assíncronas de grande volume a 50% do custo padrão, com um 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 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 API chamada. É um ciclo de vida: aceitar o trabalho, validá-lo, persisti-lo, enviá-lo, pesquisá-lo, reconciliá-lo e expor os resultados.

Arquitetura de referência

1. Aceitar uma solicitação normalizada: mantenha o formato da solicitação próximo ao seu formato OpenAIcompatível API existente 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 on-line 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 de 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: fazer 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. Armazenar linhas de saída: escreve 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. Notificar consumidores: exponha um endpoint de recuperação, webhook, notificação de painel ou Telegram alerta.
10. Reconciliar faturamento: atribua o custo ao projeto original, equipe, cliente, API chave e 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 provedor, arquivos em lote, novas tentativas e contabilidade.

Use estados de trabalho explícitos

Defina estados internos mesmo que cada provedor use nomes diferentes:

• queued: aceito, mas não enviado;
• validating: provedor ou gateway está verificando o arquivo;
• running: enviado e sendo processado;
• completed: todos os resultados disponíveis coletados;
• completed_with_errors: algumas linhas falharam na validação ou execução;
• expired: prazo expirou antes de todas as linhas serem concluídas;
• cancelled: 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, in_progress, 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.

Calcule 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 = discounted_batch_input_cost + discounted_batch_output_cost
adjusted_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
estimated_savings = baseline_cost - adjusted_batch_cost

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 falhas em nível de linha;
• taxa de tarefas expiradas;
• 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: OpenAI o cache de prompt se aplica automaticamente a prompts com mais de 1.024 tokens em modelos suportados, armazena em cache o prefixo mais longo calculado anteriormente e relata cached_tokens em API detalhes de uso. 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 é direto: 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

System instructions
Stable policy text
Stable output schema
Stable examples
Reusable reference context
---
Dynamic record-specific input
Dynamic user or row metadata

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 onde houver suporte.

Compensação: o armazenamento em cache não é 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 tarefa.

Fatos: OpenAI O lote API não suporta streaming e tem limites de taxa de lote separados. Anthropic documenta limitações de lote, incluindo um limite de 100.000 solicitações ou de 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. Google suporta 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 do lote API 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: falha na validação antecipadamente por 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:separe limites de gastos on-line e off-line.
• Tamanho máximo de arquivo e contagem de linhas: impõe 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 causadas por 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: define por quanto tempo os arquivos de solicitação, arquivos de saída e registros são armazenados.
• Política de notificação: alerta os proprietários quando os trabalhos falham, expiram ou excedem o orçamento.
• Atribuição: registre projeto, equipe, cliente, API chave, 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 IA API

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

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: detalha o uso por modelo, provedor, endpoint, equipe, projeto e API chave.
• Controles da equipe: defina orçamentos separados para cargas de trabalho interativas e off-line.
• API-atribuição de chave: identifica qual serviço ou cliente criou cada tarefa.
• Notificações de status: envia alertas quando tarefas em lote são concluídas, falham, expiram ou se aproximam do prazo.
• Fluxos de trabalho do parceiro API: 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, 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 do LLM API.
• Classifique cada carga de trabalho como em tempo real, quase on-line 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 atrás de uma sinalização de recurso.
• Meça o custo da linha de base síncrona versus o custo do lote ajustado.
• Reestruture prompts longos e repetidos para colocar prefixos estáveis primeiro.
• 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 de IA API 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 se adequarem. Estruture prompts longos repetidos para armazenamento em cache. Em seguida, meça as economias reais após falhas, novas execuções, armazenamento e custos de fallback.

A melhor implementação é enfadonha de propósito: IDs de tarefas, 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

• API atribuição de chaves e controles de gastos da equipe
• políticas de roteamento, novas tentativas e substitutos para APIs LLM
• relacionadas Model Gate notas de implementação