Amazon substituiu Claude Sonnet 4.6 por Strands Decider, um modelo de decisão, em um de seus maiores sistemas internos de tickets, e o custo por ticket caiu cerca de 98 por cento: de 0,0222 para cerca de 0,0005 dólares, aproximadamente 44 vezes menos. Os números vêm dos próprios engenheiros que fizeram a mudança, em um post de 9 de novembro de 2026, e são autorrelatados.
O que torna valioso esse post não é o número da manchete. Carr Onstott e Mehul Jaiswal, os dois engenheiros da Amazon por trás da mudança, são incomumente francos sobre o que tiveram que reconstruir para chegar lá e sobre os casos em que não o fariam. Essa é a parte que um CTO deveria ler duas vezes.
Quanto custa Claude Sonnet em relação a um modelo de decisão?
Nessa tarefa, Sonnet custava aproximadamente 44 vezes mais por ticket e cada chamada levava quase cinco vezes mais tempo. A tarefa consiste em etiquetar cada ticket que chega em uma das 20 categorias: escalações de clientes, solicitações de capacidade, alarmes automáticos, descobertas de segurança, etc. Antes da mudança, Sonnet 4.6 lia um prompt do sistema longo em cada ticket e gerava uma etiqueta em JSON com seu raciocínio.
| Métrica | Claude Sonnet 4.6 | Strands Decider E4B |
|---|---|---|
| Tempo médio por chamada | 4.215 ms | 897 ms |
| Tokens de entrada por ticket | 6.554 | 2.009 |
| Tokens de saída por ticket | 170 | 1 |
| Tokens totais por ticket | 6.724 | 2.010 |
| Custo por ticket | 0,0222 USD | ~0,0005 USD |
| Custo por 1 milhão de tickets | ~22.200 USD | ~500 USD |
Como os números foram construídos: Sonnet 4.6 em Bedrock a preço de tabela (3 dólares por milhão de tokens de entrada e 15 por milhão de saída), em relação a uma instância ml.g5.xlarge do SageMaker a 1.408 dólares por hora. A cifra de 500 dólares por milhão inclui margem para picos e exclui o custo de Lambda. A duração média de Lambda caiu 74 por cento no dia em que Sonnet foi desligado. O post fala de “milhões de dólares” economizados por ano, mas não detalha esse total.
O que o post não fornece é uma cifra de precisão. Diz que o modelo E4B superou o Sonnet de produção em um conjunto separado de tickets e que em produção teve um desempenho igualmente bom. Eu tomaria isso como uma afirmação de engenharia confiável, não como um benchmark publicado.
O que é Strands Decider?
Strands Decider é um modelo de decisão pequeno, o que seus autores chamam de system one model, que pontua um conjunto fixo de opções em vez de gerar texto. Você fornece um estado (o ticket) e um conjunto de opções (o catálogo de etiquetas), e retorna uma probabilidade por opção mais uma confiança calibrada (calibrated confidence). É um projeto do Strands Labs, o braço experimental do Strands Agents, lançado sob licença Apache 2.0.
Vem em vários tamanhos. O modelo de referência é um 2B baseado em Qwen3.5; a família Gemma 4 soma as versões E2B, E4B, 12B e 26B-A4B. Os números da Amazon saem do E4B, que o time escolheu porque superou claramente o 2B em seu conjunto de teste.
Se modelos de decisão (decision models) são novos para você, explicamos o conceito e como as principais opções se comparam em Microsoft-Decision-1 vs Jev.
SLM vs LLM: por que um modelo de fronteira perde em classificação de texto?
Porque você está pagando por palavras que ninguém lê. Veja a linha de saída: 170 tokens por ticket com Sonnet, um com Decider. Esses 170 tokens eram raciocínio e formato JSON, cobrados na tarifa de saída em cada ticket, para uma decisão que tem exatamente 21 respostas possíveis.
Este é o padrão que eu procuraria em qualquer portfólio de cargas de trabalho com LLM. Um modelo de fronteira é a ferramenta correta quando a resposta é aberta: escrever, planejar, programar. Quando a resposta é uma escolha fechada dentro de uma lista conhecida, como em classificação de texto (text classification), um modelo generativo está fazendo o trabalho de um classificador a preço de generalista. E além disso é mais lento, porque tem que gerar texto até chegar a uma resposta que um modelo de pontuação lê em uma única passada. Em alto volume, essa diferença deixa de ser uma otimização e passa a ser uma linha do orçamento.
A confiança importa tanto quanto o preço. Amazon aplica uma etiqueta apenas quando a confiança supera um limiar que o time ajustou, então os tickets duvidosos não recebem uma etiqueta errada. Uma etiqueta gerada com um parágrafo de raciocínio não lhe dá nada equivalente sobre o qual colocar um limiar.
Se quiser ver a mesma lógica de custos aplicada dentro da família Claude, comparamos turno a turno em Claude Haiku 5.5 vs Sonnet 5.5 vs Opus 5.5.
O que a Amazon teve que mudar para passar de Sonnet para um modelo de decisão?
Muito mais que o modelo. O post enumera seis mudanças:
- Reformularam a tarefa como uma pergunta de escolha única: as 20 etiquetas mais uma opção “nenhuma”.
- Reescreveram cada descrição de etiqueta. As descrições de produção não cabiam na janela de 4.096 tokens do modelo, então cada uma passou a ser um critério de uma ou duas frases.
- Cortaram os tickets longos, descartando os comentários mais antigos para que coubessem na janela.
- Ordenaram as chaves do JSON em cada solicitação. Apenas a ordem das chaves movia as probabilidades de saída em até 0,19.
- Ajustaram o limiar de confiança antes de aplicar etiquetas.
- Adicionaram um interruptor de desdobramento de três posições no AWS AppConfig:
BEDROCK(apenas Sonnet),DUAL(ambos em paralelo, comparando resultados) eDECIDER(apenas Decider). Voltar atrás levava uma mudança de configuração de 45 segundos.
O ponto 4 é o que eu destacaria para qualquer time que planeje algo parecido. Um modelo cuja saída se move 0,19 conforme a ordem das chaves é sensível ao formato de entrada, e isso você só descobre medindo. O modo DUAL é o que tornou segura a mudança: ambos os modelos rodaram sobre tráfego real e suas respostas foram comparadas antes de desligar Sonnet.
A arquitetura é AWS sem surpresas: eventos de tickets para uma fila SQS, uma Lambda que chama um endpoint de SageMaker com o modelo, AppConfig para o interruptor e CloudWatch para métricas e alarmes, tudo definido em CDK com estágios Beta, Gamma e Prod. O endpoint escala automaticamente, roda isolado da rede e copia os pesos do modelo do S3 ao iniciar. Uma instância atende aproximadamente 640 ms por solicitação, mais ou menos 5.600 tickets por hora em plena carga, com o modelo usando uns 19 GiB em uma A10G de 24 GB.
Como se instala Strands Decider?
Instale o pacote do PyPI:
pip install strands-decider
No momento da publicação desta nota (10 de novembro de 2026), os modelos Gemma 4, incluindo o E4B que está por trás dos números da Amazon, ainda não estavam no PyPI. Para usá-los, instale a partir da branch main do repositório:
pip install "strands-decider @ git+https://github.com/strands-labs/strands-decider"
O quickstart do README faz ao modelo de referência 2B uma pergunta de escolha, uma de sim/não e uma de pontuação em um único comando:
strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
--state "Help! My payouts have been failing for 3 days! " \
--choice "Which team should handle this?=billing,sales,retail" \
--noul "Does this convey urgency?" \
--score "How frustrated is the writer?=calm,frustrated,depressed"
Também pode rodar como servidor HTTP:
strands-decider serve StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --port 8000
O servidor incluído escuta em 127.0.0.1 sem autenticação, e a documentação o descreve como pensado para experimentos locais. Amazon não o expôs: rodou o modelo em um endpoint de SageMaker isolado da rede. Você não precisa de GPU, porque os quatro modelos Gemma 4 rodam em CPU, mas a memória soma: o E4B precisa de uns 15 GB em bf16 em GPU.
Quando não convém um modelo de decisão?
Os próprios autores definem os limites, o que é um bom sinal. Um modelo de decisão é a escolha errada quando:
- as etiquetas precisam de um texto explicativo;
- o catálogo de opções muda a cada semana;
- o contexto necessário para decidir não cabe em alguns milhares de tokens.
E só compensa quando o volume é alto e a latência importa. Dois matizes a mais sobre os números: os custos são a preço de tabela e sem Lambda, e a cifra por ticket assume que a instância trabalha perto de sua capacidade, com margem para picos. Uma carga de baixo volume sobre uma GPU quase sempre ociosa não veria um 98 por cento.
Minha leitura: a pergunta correta para um líder de engenharia não é “deveríamos substituir nosso LLM?”. É “quais de nossas chamadas a um LLM são na verdade classificações?”. A maioria dos times tem mais do que acredita (roteamento, triagem, etiquetagem, moderação, detecção de intenção) e cada uma é candidata para a mesma auditoria que fez Amazon.
E você? Qual tarefa do seu time ainda está pagando preços de LLM de fronteira quando, na verdade, é uma classificação?
- Um LLM de fronteira (Claude, GPT, Gemini)
- Um modelo pequeno ou de decisão
- Um classificador clássico (regras ou ML tradicional)
- Prefiro outra opção (nos diga qual)
Comente abaixo ou, se este artigo chegou para você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: O que é Flide? O motor que serve modelos de decisão tipo Jev até 9,5 vezes mais rápido que vLLM