APIs de lote de LLMs cortam o preço pela metade, mas só para o tráfego que pode esperar

Como funciona o desconto em lote

Entre os descontos disponíveis na precificação de LLMs, a API de lote é o mais simples: as requisições são enviadas como um arquivo em vez de um fluxo, os resultados chegam em até 24 horas em vez de alguns segundos e o preço cai pela metade. Não exige engenharia de prompt, nem migração de modelo, nem perda de qualidade, e quase todos os grandes provedores o oferecem com o mesmo número. Segundo o autor, a questão real não é se funciona, mas se um desconto de 50% deveria ser a primeira alavanca de custo a ser acionada — e, para a maioria das equipes, não deveria. A aritmética a seguir foi calculada a partir do catálogo do site, verificado em 11.11.2026.

50% é um teto, não uma taxa

Dos 18 modelos do catálogo, 16 oferecem uma modalidade em lote, e todos a precificam a exatamente metade da taxa em tempo real, tanto na entrada quanto na saída. Essa uniformidade torna o número principal fácil de ser aplicado incorretamente, pois o desconto alcança apenas o tráfego que realmente pode ser adiado:

economia efetiva = 50% × (parcela de chamadas que podem esperar)

• 100% elegível para lote resulta em 50% de desconto
• 60% elegível para lote resulta em 30% de desconto
• 20% elegível para lote resulta em 10% de desconto

Poucos produtos são totalmente adiáveis. Um chatbot fica em 0% porque há um usuário esperando; um pipeline de RAG fica em 0% no momento da consulta, embora as passagens de embedding e sumarização por trás dele possam não estar. As cargas de trabalho que de fato se qualificam são as rotineiras: processamento noturno de documentos, classificação em massa, backfills, avaliações e geração de dados sintéticos. É por isso que o arquétipo Document processor do site é o único predefinido que ativa o modo em lote por padrão.

Um exemplo concreto

Para 5.000 documentos por dia com 8.000 tokens de entrada e 800 de saída cada, mantendo os demais padrões do motor — taxa de repetições de 8%, taxa de acerto de cache de 40%, overhead de infraestrutura de 15% e calibração de tokenizador por modelo — os custos mensais são:

A economia fica logo abaixo de 50% em vez de atingi-lo exatamente. A diferença vem das repetições: uma chamada que falha ainda consome tokens, e o motor precifica esse overhead a taxas de tempo real — uma margem pequena e deliberadamente conservadora.

Lote e cache não se somam

Esta é a parte que confunde as pessoas, e que causou um bug no próprio motor dos autores. Se o cache economiza cerca de 90% na entrada e o lote economiza 50% em tudo, é tentador somar os dois números — ou, de forma mais razoável, esperar que o lote desconte outros 50% sobre uma fatura já reduzida. Nenhuma das duas coisas acontece.

Os provedores acumulam os dois descontos de forma multiplicativa, e a taxa de lote incide sobre o que é efetivamente cobrado. Uma leitura em cache dentro de um trabalho em lote custa cached_rate × 0.5, de modo que o desconto em lote é aplicado sobre o gasto pós-cache, e não sobre o preço de tabela:

in_spend      = in_cost - cache_savings        # what you're actually billed
batch_savings = (in_spend × 0.5 + out_cost × 0.5) × batch_pct

A consequência é contraintuitiva: com 100% de elegibilidade para lote, a fatura é exatamente a metade, e a taxa de acerto de cache não muda isso. Cache e lote não são alavancas aditivas que se empilham rumo a um desconto maior — o cache determina quanto se gasta, e o lote divide pela metade o que resultar.

Ainda assim, vale conhecer um efeito de segunda ordem. Como o cache encolhe o lado de entrada da fatura, ele desloca onde o desconto em lote atua. Nesta carga de trabalho, a entrada do Claude Sonnet 5.5 representa 67% do custo bruto por chamada, mas depois de uma taxa de acerto de cache de 40%, a entrada ainda paga corresponde a apenas 55% da fatura. Quanto melhor o cache, mais do desconto em lote recai de fato sobre os tokens de saída: trabalho intensivo em saída se beneficia mais do lote do que a tabela sugere, enquanto trabalho intensivo em entrada com bom cache se beneficia menos.

O artigo reconhece que isso foi implementado de forma errada inicialmente: o motor aplicava o desconto em lote sobre o preço de tabela da entrada enquanto subtraía separadamente a economia de cache dos mesmos tokens, descontando-os duas vezes e subestimando os custos do processador de documentos em 10–27%. O erro era maior nos modelos com os maiores descontos de cache. Foi corrigido em 31.08.2026, e a fórmula acima é a que está em produção agora. Os leitores podem definir sua própria parcela elegível para lote e taxa de acerto de cache na calculadora do site.

Descer de nível ainda vence o modo em lote

O lote está limitado a 50%, mas a distância entre níveis de capacidade não. Na mesma carga de trabalho, o Claude Sonnet 5.5 com todas as chamadas em lote custa $2,648 por mês, enquanto o Claude Haiku 5.5 a preço cheio em tempo real — respondendo na hora — custa $262 por mês. O nível mais barato vence por cerca de 90% e devolve a latência. A ordem que o artigo recomenda internalizar: escolher o nível que a tarefa realmente precisa, fazer o cache funcionar e só então decidir o que pode esperar 24 horas. Recorrer primeiro ao lote significa aceitar uma restrição rígida de latência para capturar a menor das três alavancas.

Onde o modo em lote nem existe

Dois dos 18 modelos não têm modalidade em lote: Muse Spark Open 816B e Muse Glimmer 30B. Ambos são modelos de pesos abertos servidos em plataformas de inferência, e o artigo interpreta a ausência como uma decisão de produto, não um descuido — essas plataformas vendem latência, então uma fila lenta e barata significaria competir no eixo que elas deliberadamente recusaram. Se a economia do lote é estrutural para uma arquitetura, essas linhas são eliminadas independentemente do preço.

O desconto da DeepSeek é um relógio, não um endpoint

Há uma exceção genuína que vale conhecer. A DeepSeek não tem API de lote; o que oferece é preço fora de pico, com 50% de desconto em cada token fora das janelas 01:00–04:00 e 06:00–10:00 UTC. O site a modela nos campos de lote porque a aritmética é idêntica, mas o mecanismo é melhor em um aspecto específico: a taxa com desconto chega com latência de tempo real, apenas durante certas horas, algo que nenhuma modalidade em lote oferece. Se o trabalho em massa já roda durante a noite em um fuso europeu ou americano, pode ser que já esteja pagando a taxa com desconto sem mudar nada.

Quando os 50% de desconto realmente valem a pena

• Quando o trabalho é genuinamente assíncrono — não "usuários tolerariam a lentidão", mas ninguém esperando: trabalhos noturnos, backfills, avaliações, classificação em massa.
• Depois de escolhido o nível. Descer de nível normalmente supera todo o desconto em lote e não custa latência, portanto deve vir antes.
• Quando a parcela elegível é a maior parte do volume. Com 20% de elegibilidade, busca-se 10% de economia adicionando uma fila, um loop de polling e um modo de falha — complexidade que precisa ser paga em algum lugar.
• Quando a cauda é tolerável. O SLA é "within 24 hours", não "cerca de uma hora"; qualquer coisa com prazo diário precisa de um caminho de contingência em tempo real, ou seja, um segundo caminho de código para manter.
• Não como substituto do cache. O cache reduz o que se gasta e o lote o divide pela metade, então o primeiro deve estar funcionando antes de aceitar uma restrição de latência pelo segundo.