GPT-6 Astra no Bedrock: o endpoint decide o que você audita
A GA do GPT-6 Astra no Amazon Bedrock, em 8 de setembro de 2026, veio com um número que todo mundo repetiu: 1.050.000 tokens de contexto, e com uma decisão de arquitetura que quase ninguém comentou: o modelo é servido por dois endpoints distintos, bedrock-runtime e bedrock-mantle, e eles não entregam as mesmas garantias. Escolher entre eles não é preferência de SDK. É escolher, dentro da mesma requisição, entre ter cache explícito de prompt e ter log de invocação, porque o model card não dá os dois no mesmo caminho.
O que a GA realmente entregou
O model card é mais informativo que o anúncio. openai.gpt-6-astra tem janela de 1.050.000 tokens de entrada, teto de 128.000 tokens de saída e knowledge cutoff em 30 de abril de 2026. Entrada aceita texto e imagem; saída é só texto, quem esperava geração de imagem ou áudio pelo mesmo model ID vai bater numa parede. EOL não antes de 8 de setembro de 2027, com período legacy de pelo menos 6 meses: isso é um ano de piso contratual para planejar migração, e é o tipo de dado que deveria entrar no seu ADR, não no seu slide.
A superfície de API é menor do que parece. No bedrock-runtime, o modelo responde por Converse, Responses e Chat Completions, e não por InvokeModel. Se o seu wrapper interno padronizou tudo em InvokeModel para ter um único ponto de instrumentação, ele não chama Astra. No bedrock-mantle, só Responses e Chat Completions, servidos em /openai/v1/responses e /openai/v1/chat/completions.
Service tier único. Só Standard. Priority, Flex e Reserved aparecem como não suportados. Não existe throughput reservado para segurar latência de pico, e não existe faixa Flex para amortecer lote noturno. Toda a sua carga divide a mesma fila pay-per-token, e o seu controle sobre latência de cauda é escolher a Região e nada mais.
Uma requisição, dois endpoints, garantias diferentes
O mesmo model ID atravessa dois planos de controle. A coluna da esquerda dá Guardrails e log de invocação; a da direita dá cache explícito e ferramentas server-side, e some do log. O perfil de inferência escolhido decide em qual Região a resposta fica guardada.
- Converse API · única via com Guardrails
- Responses + Chat Completions · sync only, background=400
- Invocation logging · S3/CW, 100 KB inline
- Responses /v1 · server-side tools, async
- Explicit prompt cache · 1.024 tok, 4 breakpoints, TTL 30m
- Fora do invocation log · ação bedrock-mantle:CreateInference
- us.openai.gpt-6-astra · 5 Regiões US/CA
- global.openai.gpt-6-astra · qualquer Região comercial
- openai.gpt-6-astra · 1.050.000 in / 128.000 out
- Faixa 272K · acima disso: 2x input, 1,5x output
- store=true (default) · input+output por 30 dias
- CloudTrail · quem chamou, não o conteúdo
A conta que o roteamento escreve
O preço de Astra não é um par de números; é uma matriz de duas dimensões, e as duas são decisão de arquitetura.
Dimensão 1, o perfil de inferência. Global CRIS custa US$ 10,00 por 1M de tokens de entrada e US$ 50,00 de saída. In-Region e Geo CRIS custam US$ 11,00 e US$ 55,00. Você paga 10% a mais exatamente para ganhar controle sobre onde a inferência acontece. É o preço explícito da residência, e é barato perto de uma multa.
Dimensão 2, o corte em 272K. Acima de 272.000 tokens de entrada, a requisição inteira reprecifica: US$ 20,00 de entrada e US$ 75,00 de saída no global, US$ 22,00 e US$ 82,50 no in-Region. Não é o excedente que muda de faixa, é tudo. Um prompt de 280.000 tokens no global custa US$ 5,60 de entrada; o mesmo prompt cortado para 270.000 custa US$ 2,70. Uma diferença de 3,7% no tamanho vira 107% na fatura.
E você não tem CountTokens. A lista do bedrock-runtime marca CountTokens e structured outputs como não suportados para este modelo. Ou seja: existe um penhasco de preço a 272.000 tokens e não existe API oficial para saber de que lado dele o seu payload caiu antes de enviar. A contagem precisa acontecer no seu código, com o tokenizer certo e uma margem de segurança, e o teto tem que ser um parâmetro, não um número solto no meio da função.
A quota é uma terceira moeda. O burndown é 10x: 1 token de saída consome 10 unidades de TPM. Um run que gera os 128.000 tokens de teto queima 1.280.000 unidades: 4,7 vezes o que custa, em quota, ler 272.000 tokens de entrada. Em agente, saída é o recurso escasso, não contexto.
O cache explícito e a matemática dos 30 minutos
O cache de prompt dos modelos OpenAI no Bedrock não é o mesmo mecanismo dos Claude. Não existe cachePoint no Converse: você marca "prompt_cache_breakpoint": {"mode": "explicit"} num bloco de conteúdo da Responses API, com prefixo mínimo de 1.024 tokens e até 4 breakpoints. O prompt_cache_options.mode decide o comportamento: implicit (padrão) coloca um breakpoint automático na última mensagem além dos seus; explicit desliga o automático, e se você não declarar nenhum breakpoint, a requisição simplesmente não usa cache e nem cobra escrita. TTL mínimo de 30 minutos, controlado por prompt_cache_options.ttl.
A economia é agressiva e o break-even é imediato. Escrita custa 1,25x a entrada não cacheada; leitura custa 10% dela. Num prefixo estável de 40.000 tokens, instruções, definições de ferramenta, documentos de referência, rodando 30 chamadas dentro da mesma janela de 30 minutos no bedrock-mantle: sem cache, 30 × 40.000 × US$ 11,00/1M = US$ 13,20. Com cache, US$ 0,55 de escrita mais 29 leituras de US$ 0,044 = US$ 1,83. Queda de 86%, e a segunda chamada já pagou a escrita.
Tem mais um detalhe que muda capacity planning: tokens lidos do cache não contam contra a quota de input-tokens-por-minuto. Cache aqui não é só desconto, é headroom.
O problema é onde ele mora. Para Astra, o model card lista Implicit e Explicit Prompt Caching apenas no bedrock-mantle, via Responses API. E bedrock-mantle para Astra existe só em us-west-2, sem perfil geográfico e sem perfil global.
O trade-off que ninguém colocou no anúncio
A documentação de model invocation logging é explícita: o log só cobre chamadas feitas pelo endpoint bedrock-runtime, e chamadas às mesmas APIs no bedrock-mantle não são capturadas. Junte com o model card: o cache explícito de Astra existe só no bedrock-mantle; Guardrails existem só no bedrock-runtime, e lá só pela Converse API. O resultado é uma escolha de três vias que ninguém consegue ter inteira, cache de 86% de desconto, filtro de Guardrails, ou prompt e resposta gravados para auditoria. Você escolhe dois, no máximo, e num agente de alto volume os três aparecem no mesmo requisito.
bedrock-runtime x bedrock-mantle para openai.gpt-6-astra
| Dimensão | bedrock-runtime | bedrock-mantle |
|---|---|---|
| APIs para este modelo | Converse, Responses, Chat Completions (sem Invoke) | Responses e Chat Completions, em /openai/v1 |
| Regiões | Nenhuma in-Region; Geo em 5 Regiões US/CA; Global inclusive em sa-east-1 | Só us-west-2, in-Region, sem Geo e sem Global |
| Cache explícito de prompt | Não listado no model card | Implicit e Explicit, só via Responses API |
| Guardrails | Sim, exclusivamente pela Converse API | Não listado |
| Log de invocação | Sim: metadados, input e output até 100 KB inline | Não capturado |
| Tool use server-side e execução assíncrona | Não; background=true volta 400 | Sim, ambos |
| Ação IAM autorizada | bedrock:InvokeModel no alvo e no projeto default | bedrock-mantle:CreateInference |
| Preço por 1M (curto / longo contexto) | Global: 10/50 e 20/75. Geo: 11/55 e 22/82,50 | In-Region: 11/55 e 22/82,50 |
Residência, retenção e o IAM que não cobre o outro endpoint
Aqui a análise deixa de ser sobre custo. A Responses API guarda estado por padrão: com store em true, que é o default, para bater com a especificação da OpenAI, o Bedrock retém a requisição e a resposta por 30 dias, para permitir previous_response_id. E a documentação é direta sobre onde: a resposta fica na Região que processou a requisição. Com perfil global, isso é qualquer Região comercial para onde o perfil roteou.
Traduzindo para quem opera sob BACEN e LGPD: em sa-east-1, Astra existe apenas por perfil global. Não há in-Region, não há Geo. Uma equipe em São Paulo que chame Astra está aceitando roteamento mundial e, no default, retenção de entrada e saída por 30 dias fora do país. O caminho geográfico us.openai.gpt-6-astra cobre cinco Regiões, us-east-1, us-east-2, us-west-1, us-west-2 e ca-central-1, e nenhuma delas é Brasil. Hoje não existe caminho de residência nacional para este modelo. A mitigação é store explicitamente em false em toda requisição, ou o modo de retenção da conta em none, que rejeita store=true. Mas retenção nula custa a conversa multi-turno stateful, que é justamente por que muita gente foi para a Responses API.
E tem uma armadilha de IAM. Os dois endpoints autorizam ações de namespaces diferentes: bedrock:InvokeModel de um lado, bedrock-mantle:CreateInference do outro. Uma SCP escrita como "Action": "bedrock:" para restringir quais modelos a organização pode invocar simplesmente não casa com bedrock-mantle:. Some a isso o comportamento das condition keys: bedrock:ModelArn vale o perfil que a requisição nomeou, nunca os modelos de destino para onde o CRIS roteou. Você não consegue restringir Região de processamento por policy no alvo; consegue só escolhendo o perfil certo.
Anti-padrões que já dá para prever
- Tratar
bedrock-mantlecomo um alias debedrock-runtime: mudar a base URL parece inofensivo porque o SDK da OpenAI funciona nos dois, mas troca a ação IAM, some com o log de invocação e prende a carga emus-west-2. É migração de plano de controle disfarçada de variável de ambiente. - **Escrever guardrail organizacional só sobre
bedrock:*: a SCP que hoje aprova modelos por ARN não alcançabedrock-mantle:CreateInference. O caminho não aprovado continua aberto e não aparece no log de invocação, falha silenciosa nas duas pontas. - Mandar o documento inteiro porque cabe em 1,05M: passar de 272.000 tokens dobra o preço da entrada e multiplica a saída por 1,5 na requisição inteira. Recuperação e chunking não viraram legado com contexto grande; viraram controle de custo.
- Deixar
storeno default em carga regulada:trueretém entrada e saída por 30 dias na Região que processou. Com perfil global e sem cláusula de residência no seu desenho, você acabou de exportar dado de cliente sem uma linha de código que diga isso. - Portar código da OpenAI sem ler as diferenças: no
bedrock-runtime,background=truevolta 400 emodelé obrigatório em toda requisição, inclusive nas que passamprevious_response_id. Os dois erros aparecem em produção, não no teste feliz. - Colocar o breakpoint de cache depois do conteúdo variável: prefixo com qualquer parte dinâmica invalida a cadeia inteira. O sintoma é
cache_write_tokensalto comcached_tokensem zero, chamada após chamada, você paga 1,25x e nunca lê.
Lente Well-Architected sobre esta decisão
Segurança
Guardrails só chegam ao Astra pela Converse API no bedrock-runtime; qualquer outro caminho fica sem filtro gerenciado e você reimplementa detecção de injeção no seu código. Cubra os dois namespaces de ação na SCP e trate store=false como controle de segurança, não como otimização.
Confiabilidade
Só o tier Standard existe: sem Priority para segurar latência de pico e sem Reserved para capacidade garantida. Desenhe timeout, retry com backoff e idempotência assumindo throttling, e mantenha um modelo de fallback com contrato de saída idêntico, não um que você espera que responda parecido.
Eu começaria pelo bedrock-runtime com Converse e perfil geográfico us.openai.gpt-6-astra, aceitando pagar 10% a mais e abrir mão do cache explícito, porque Guardrails e log de invocação são o que eu preciso mostrar numa auditoria, e conversa técnica sobre desconto de cache termina rápido quando o auditor pergunta pelo prompt de uma decisão específica. O bedrock-mantle eu reservaria para carga interna de alto volume em us-west-2, com dado já classificado como não sensível, e com telemetria própria gravando a chamada porque o Bedrock não vai gravar. Em cliente brasileiro sob BACEN, eu não colocaria Astra no caminho de dado de cliente enquanto só existir perfil global em sa-east-1: a lição que eu aprendi caro é que residência de dados não é negociável em revisão de arquitetura, é um pré-requisito que mata a proposta inteira quando aparece no fim. E eu escreveria um ADR de uma página só sobre a escolha de endpoint, porque daqui a seis meses ninguém vai lembrar que a base URL trocou a ação IAM.
Referências
Veredito
GPT-6 Astra no Bedrock é um upgrade real de capacidade com uma superfície de governança irregular, e a irregularidade é o que decide a sua arquitetura. Use bedrock-runtime com Converse e perfil geográfico quando a carga tiver dado de cliente, requisito de auditoria ou filtro de conteúdo obrigatório, os 10% a mais por token compram Guardrails, log de invocação e controle de onde a inferência acontece. Use bedrock-mantle quando o volume for grande, o prefixo for estável, o dado for não sensível e us-west-2 for aceitável, ali o cache explícito derruba 86% do custo de prefixo e libera quota, mas você assume o rastro por conta própria. Não use Astra no caminho de dado regulado brasileiro enquanto sa-east-1 só tiver perfil global: nesse cenário o problema não é preço nem latência, é que você não consegue afirmar onde o dado foi processado, e essa frase encerra qualquer revisão de arquitetura em banco. Reveja a decisão quando aparecer perfil geográfico com Região brasileira, quando o cache chegar ao bedrock-runtime, ou quando o log de invocação passar a cobrir o bedrock-mantle, qualquer um dos três dissolve o trade-off central deste texto.
Continue lendo
Deep dives de arquitetura, AWS, IA e mercado: direto no seu email. Grátis.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este artigo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.