O Amazon Bedrock roda inferência em lote a 50% do preço de token sob demanda, e a única coisa que você abre mão é a imediatidade. Você envia um arquivo de requisições, o job roda de forma assíncrona quando há capacidade, e você coleta os resultados depois. Para qualquer carga de trabalho onde nenhum humano está sentado esperando a resposta, pagar o preço cheio por inferência em tempo real é deixar metade do dinheiro na mesa por uma velocidade que ninguém precisava.

O erro é fazer toda chamada de modelo por padrão passar pelo caminho síncrono, em tempo real, porque foi assim que o primeiro protótipo foi escrito. Chat interativo tem que ser em tempo real. Um job noturno que classifica os tickets de suporte de ontem não precisa. Essas são exigências de latência diferentes, e o Bedrock as precifica de forma diferente. A pergunta de engenharia é simplesmente quais das suas cargas de trabalho realmente precisam de uma resposta agora versus quais precisam de uma resposta eventualmente.

Como o lote funciona no Bedrock

Inferência em lote é um job, não uma chamada. O fluxo é deliberadamente enfadonho:

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

Cada registro de entrada carrega um ID de registro e a mesma entrada de modelo que você enviaria em tempo real. A saída é escrita de volta no S3, um resultado por entrada, indexado por aquele ID de registro para que você consiga juntar resultados a entradas. Não há endpoint para manter aquecido, nenhuma concorrência para ajustar, nenhum throttling para capturar. Você troca o loop de requisição-resposta por um loop de enviar-e-coletar, e ganha a taxa com desconto por aceitar que o job termina no cronograma do serviço, não no seu.

Onde a latência genuinamente não importa

As cargas de trabalho que se encaixam são as que o resultado alimenta um processo, não uma pessoa esperando na tela:

  • Classificação e etiquetagem em massa. Categorize um backlog de documentos, tickets ou produtos. A resposta cai em um banco de dados, não na frente de um usuário.
  • Pipelines de enriquecimento. Resumos, extrações ou embeddings gerados antecipadamente e armazenados, para que o caminho em tempo real apenas leia um valor pré-computado.
  • Avaliação offline. Pontuar uma mudança de modelo ou prompt em milhares de casos de teste. É um relatório, e relatórios podem esperar uma hora.
  • Relatórios periódicos. Qualquer coisa que roda em uma agenda e produz uma saída que um humano lê depois, não instantaneamente.

O fio condutor: o prazo é medido em horas, e o volume é grande o suficiente para que reduzir o preço de token pela metade seja dinheiro real, não arredondamento.

A matemática do custo

A troca é gritante quando você coloca no papel. Pegue um job de um milhão de registros, cada um com um custo de token médio fixo:

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

A coluna do lote é metade da conta de tokens e menos superfície operacional, porque não há endpoint ao vivo para proteger de um pico. O ponto de equilíbrio não é sobre volume, é sobre o prazo. Se a resposta pode esperar, o lote vence em custo e em simplicidade. Se não pode, nenhum desconto torna um job assíncrono aceitável.

Quando o lote é a ferramenta errada

Não force onde o formato não encaixa. O lote está errado quando um usuário está esperando pela saída, quando uma requisição depende do resultado da anterior, ou quando o job é pequeno o suficiente para que o desconto seja trivial e o encanamento assíncrono não valha a pena. Também está errado como um workaround para throttling: se seu tráfego em tempo real está sofrendo throttling, o conserto é planejamento de capacidade e cache de prompt, não empurrar requisições interativas por um job que retorna horas depois. O lote é para trabalho que sempre seria adiado, não para esconder um problema de latência.

A conclusão

Metade de uma conta grande de tokens vale uma arquitetura que a maioria dos times já tem por aí: escrever no S3, enviar um job, ler os resultados depois. O desconto não é sofisticado, é apenas pagar por capacidade adiada em vez de capacidade sob demanda. Audite suas chamadas de modelo e as classifique por quem está esperando. Tudo com um humano do outro lado permanece em tempo real. Tudo mais, a classificação, o enriquecimento, a avaliação e os relatórios que alimentam um pipeline em vez de uma pessoa, pertence a um job em lote com 50% de desconto. As economias estão sentadas nas cargas de trabalho que você nunca questionou.

Leia isso a seguir

Para o playbook mais amplo de otimização de custos e pipelines na AWS, as notas de campo sobre cloud estão em ercan.cloud, e o hub está em ercanermis.com.