Amazon Nova 2 Lite: como calcular o custo real por fluxo entre tokens, cache, níveis de serviço e falhas

Do preço unitário ao custo de um resultado útil

O preço por milhão de tokens é um componente necessário, mas, por si só, não responde à questão operacional relevante: quanto custa concluir uma tarefa com o resultado e a latência de que o sistema precisa. Em um fluxo do Amazon Nova 2 Lite no Amazon Bedrock, entram o volume de entrada e saída, o contexto repetido, as chamadas que falham, a validação da resposta e, conforme o desenho, o nível de serviço selecionado. Portanto, uma previsão defensável deve ser expressa tanto em unidades de consumo quanto em resultados aceitos.

Convém definir desde o início uma unidade de trabalho. Ela pode ser uma solicitação classificada, uma página processada, um documento extraído, uma sessão ou uma automação que produz um objeto estruturado válido. A unidade escolhida deve incluir a condição de aceitação: por exemplo, que o JSON passe no validador, que a ferramenta seja concluída ou que uma revisão humana não seja necessária. Isso evita apresentar como sucesso uma resposta que consumiu recursos, mas foi descartada.

Este guia não fixa valores: as fontes fornecidas descrevem identificação do modelo, modalidades, cache, níveis de serviço, rotas de inferência, cotas e dados de uso faturável, mas não incluem uma tabela de preços vigente. Antes de elaborar um orçamento, a equipe deve registrar a tarifa oficial aplicável fora deste artigo e anotar a data da consulta. Substituir esse dado nas fórmulas é preferível a reutilizar números antigos ou inferir preços a partir de outro modelo.

O identificador-base documentado para o modelo é amazon.nova-2-lite-v1:0. A ficha também documenta perfis de inferência para Estados Unidos, Europa, Japão e Global. Não se deve presumir que dois perfis, rotas ou regiões tenham o mesmo preço, a mesma capacidade ou o mesmo tratamento de dados apenas porque invocam o mesmo modelo-base.

A ficha de cobrança que deve ser congelada antes dos cálculos

Toda planilha deve começar com uma ficha de escopo. Registre a data e a hora de consulta da tarifa, moeda, conta ou ambiente, identificador do modelo, região de origem, perfil de inferência, rota In-Region ou Cross-Region, nível de serviço solicitado e unidade funcional. Acrescente uma versão do prompt, a configuração de saída, o esquema de validação e o período de observação. Esses campos permitem explicar por que duas medições aparentemente iguais terminam com custos diferentes.

A documentação de relatórios de custo e uso do Bedrock diferencia, para o Nova 2 Lite, tipos de uso de entrada, saída, leitura de cache e gravação de cache. Ela também documenta sufixos que permitem distinguir o nível Flex ou Priority e o roteamento Cross-Region. Essa separação importa: uma estimativa que soma apenas tokens de entrada e saída pode omitir operações de cache, e uma reconciliação agregada pode ocultar uma mistura de rotas ou níveis de serviço.

A inferência geográfica Cross-Region pode processar solicitações dentro da geografia escolhida, embora prompts e resultados possam ser movidos da região de origem para uma região de destino nessa geografia. Isso deve ser avaliado como requisito de arquitetura e residência, não apenas como variável de preço. A documentação fornecida não é suficiente para afirmar aqui uma equivalência de preço, cota ou faturamento entre In-Region, Geo Cross-Region e Global Cross-Region.

Variáveis faturáveis e quatro fórmulas auditáveis

Para cada tentativa, separe ao menos tokens de entrada ordinária, tokens de saída, leituras de cache e gravações de cache. Se o fluxo incluir entradas multimodais, ferramentas integradas, raciocínio ou alguma modalidade adicional, adicione colunas específicas somente se a tarifa e o registro de uso aplicáveis as identificarem. Não atribua automaticamente uma cobrança adicional a uma função apenas por usá-la: com as fontes disponíveis, não é possível confirmar o tratamento tarifário de raciocínio, imagens, documentos, ferramentas ou erros de API para este modelo.

Use preços unitários convertidos em custo por token ou mantenha o denominador por milhão de tokens de forma consistente. Chame P_i de preço de entrada, P_o de preço de saída, P_cr de preço de leitura de cache e P_cw de preço de gravação de cache. Para uma tentativa j, os consumos correspondentes são I_j, O_j, CR_j e CW_j. Se houver outros conceitos publicados, incorpore-os como soma de quantidade por preço, sem escondê-los dentro de entrada ou saída.

A primeira fórmula estima o custo de uma chamada individual. A segunda distribui um lote entre os itens processados. A terceira serve para sessões que reutilizam instruções ou contexto. A quarta converte consumo em custo por tarefa concluída corretamente. Em todas elas, o resultado depende de a telemetria contabilizar cada tentativa, inclusive as que terminaram em falha de validação ou foram abandonadas depois de uma espera excessiva.

Cache de prompt: medir a economia líquida, não presumi-la

O Nova 2 Lite aceita cache explícito com mínimo de 1.000 tokens por checkpoint, até quatro checkpoints, tempo de vida de cinco minutos e máximo de 20.000 tokens de cache. Esses limites definem quais desenhos podem se beneficiar: uma instrução longa e estável, compartilhada por solicitações próximas no tempo, é uma candidata mais clara do que um contexto pequeno, muito variável ou espaçado.

A comparação correta não é “com cache versus sem cache” de forma abstrata. Meça tokens gravados, tokens lidos, número de solicitações elegíveis, percentual de acertos, intervalo entre chamadas, complexidade adicional e alterações na taxa de sucesso. A gravação inicial pode ter custo diferente de uma leitura, e o relatório de custo e uso permite distinguir as duas categorias. A economia líquida só aparece se as leituras reutilizadas compensarem as gravações e a manutenção do desenho.

Um cache também pode piorar a economia se aumentar a complexidade de segmentação, reduzir a personalização necessária, provocar expirações frequentes ou incentivar a inclusão de contexto irrelevante. O fato de um bloco poder ser armazenado não prova que ele reduzirá a fatura. A decisão deve basear-se em uma coorte comparável e em custos por tarefa aceita, não somente em tokens de entrada observados.

Standard, Flex e Priority: uma decisão de custo esperado

A documentação de níveis de serviço descreve o Flex para cargas tolerantes a atrasos e o Priority como uma opção solicitada por chamada. Ela também indica que as cotas sob demanda são compartilhadas entre Priority, o comportamento padrão e Flex. Portanto, escolher um nível não elimina a necessidade de medir a demanda agregada nem garante, por si só, que o fluxo opere dentro de seus limites de cota.

O nível efetivamente atendido pode ser observado na resposta da API, no CloudTrail e no CloudWatch, conforme a documentação. Guarde esse dado junto com o nível solicitado. Isso é essencial para detectar diferenças entre a intenção e o serviço efetivamente fornecido, bem como para reconciliar análises de latência, consumo e tipos de uso do relatório de custos.

A alternativa mais barata por unidade pode ser mais cara por resultado útil se aumentar o abandono, os timeouts ou a repetição de trabalho. De modo inverso, um nível orientado à prioridade só justifica seu custo adicional se reduzir perdas operacionais que o fluxo de fato sofre. Esta é uma conclusão de análise econômica, não uma afirmação sobre preços ou desempenho garantido de um nível específico.

Falhas, novas tentativas e respostas descartadas: o multiplicador que deve ser contabilizado uma vez

Um fluxo robusto deve registrar todas as tentativas: primeira chamada, nova tentativa automática, reparo de JSON, nova chamada após timeout e encaminhamento para revisão humana. Para evitar dupla contagem, atribua um identificador de tarefa raiz e um identificador de tentativa. Cada custo de modelo pertence a uma tentativa; o custo por tarefa aceita é obtido agregando as tentativas da tarefa uma única vez e dividindo pelo número de tarefas aceitas.

Diferencie erros anteriores à invocação do modelo, que podem não produzir consumo de inferência, de respostas ou falhas posteriores a uma invocação. Não é seguro tratar todo erro HTTP como gratuito nem toda nova tentativa como idêntica à primeira tentativa. A reconciliação deve usar os dados de resposta, os registros operacionais e os tipos de uso do Bedrock disponíveis no relatório de custos. Se faltar correlação por solicitação, documente essa limitação em vez de atribuir todo o gasto à última etapa visível.

As cotas publicadas incluem limites de solicitações por minuto e tokens por minuto para a inferência Cross-Region do Nova 2 Lite, e algumas cotas podem ser ajustadas por meio do Service Quotas. Meça rejeições, esperas e novas tentativas vinculadas a limites. Uma mudança de cota ou de padrão de chegada pode modificar a taxa de sucesso e o custo efetivo sem que o preço unitário varie.

Orçamento mensal substituível e reconciliação com o gasto

Para elaborar um orçamento, comece com uma previsão de tarefas iniciadas por mês, uma distribuição esperada de tentativas por tarefa e consumos médios por tipo de tentativa. Calcule cada segmento separadamente: solicitações simples, documentos, sessões com contexto repetido e automações estruturadas. Multiplique o custo médio por tentativa de cada segmento por suas tentativas previstas; em seguida, some o custo de operações auxiliares e de revisão humana, se fizerem parte do custo operacional que se pretende decidir.

Como exemplo de estrutura, uma planilha pode ter uma linha por segmento e colunas para tarefas iniciadas, taxa de aceitação, tentativas por tarefa, entrada, saída, gravação e leitura de cache por tentativa, preços vigentes, custo estimado e custo por aceito. As células de preço devem permanecer vazias até que a tarifa verificada seja copiada para a configuração específica. Não convém preenchê-las com valores ilustrativos, pois eles poderiam ser interpretados como tarifa atual.

Ao fechar o período, compare previsão e realidade por modelo, rota, nível de serviço e tipo de uso. Explique a variação por mudanças na mistura de entradas, comprimento da saída, acertos de cache, novas tentativas e aceitação antes de atribuí-la a uma alteração de preços. Recalcule quando mudarem o modelo, a região ou o perfil, o prompt, a política de cache, o nível de serviço, a mistura multimodal, o volume, as cotas ou as regras de validação.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.