Monitorando Cargas de IA Generativa em Escala
À medida que organizações expandem suas cargas de trabalho de inteligência artificial generativa no Amazon Bedrock, compreender o desempenho da inferência e o consumo de recursos torna-se essencial para manter a confiabilidade operacional. Equipes que executam aplicações sensíveis à latência precisam entender com que rapidez os modelos começam a gerar respostas. Aquelas que gerenciam cargas de alto throughput precisam acompanhar como suas requisições consomem quota para evitar limitações inesperadas.
Até então, obter essa visibilidade exigia instrumentação customizada no lado do cliente ou investigação reativa após problemas ocorrerem. A AWS anunciou duas novas métricas do CloudWatch para o Amazon Bedrock: TimeToFirstToken e EstimatedTPMQuotaUsage. Essas métricas oferecem visibilidade no lado do servidor sobre latência de streaming e consumo de quota, são emitidas automaticamente para cada requisição de inferência bem-sucedida, não geram custos adicionais, não requerem mudanças nas APIs e estão disponíveis agora no namespace AWS/Bedrock do CloudWatch.
O Fundamento: Métricas Existentes do Bedrock
O Amazon Bedrock já fornecia um conjunto de métricas do CloudWatch para monitorar cargas de inferência. O namespace AWS/Bedrock incluía métricas como Invocations, InvocationLatency, InvocationClientErrors, InvocationThrottles, InputTokenCount e OutputTokenCount. Essas métricas ofereciam visibilidade sobre volume de requisições, latência fim-a-fim, taxas de erro e uso de tokens. Estavam disponíveis nas APIs Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream, podendo ser filtradas pela dimensão ModelId.
Embora essas métricas fornecessem uma base operacional sólida, deixavam duas lacunas importantes: não capturavam a rapidez com que uma resposta em streaming começava (tempo até o primeiro token) e não refletiam a quota efetivamente consumida por uma requisição após considerar os multiplicadores de redução de token.
Observabilidade de Aplicações de Inferência em Produção
Em aplicações de inferência com streaming, como chatbots, assistentes de codificação ou geração de conteúdo em tempo real, o tempo que o modelo leva para retornar seu primeiro token afeta diretamente a responsividade percebida pela aplicação. Um atraso no primeiro token impacta a experiência do usuário, mesmo quando o throughput geral permanece dentro de intervalos aceitáveis.
Medir essa métrica no lado do servidor anteriormente exigia instrumentar o código da aplicação para capturar timestamps ao redor das chamadas de API. Isso adicionava complexidade e poderia introduzir imprecisões que não refletiam o comportamento real do lado do serviço.
A gestão de quota apresenta um desafio diferente, mas igualmente crítico. O Amazon Bedrock aplica multiplicadores de redução de token para certos modelos. Isso significa que a quota efetivamente consumida por uma requisição pode diferir dos contadores brutos de tokens vistos nas métricas de faturamento. Por exemplo, modelos Anthropic Claude, incluindo Claude Sonnet 4.6, Claude Opus 4.6, Claude Sonnet 4.5 e Claude Opus 4.5, aplicam um multiplicador de 5x em tokens de saída para fins de quota. Uma requisição que produz 100 tokens de saída consome efetivamente 500 tokens de sua quota de Tokens Por Minuto (TPM). O faturamento ocorre apenas sobre o uso real de tokens.
Sem visibilidade nesse cálculo, a limitação de taxa pode parecer imprevisível, dificultando a definição de alarmes apropriados ou planejamento de aumentos de capacidade antecipadamente. Para clientes usando inferência entre regiões, esses desafios se multiplicam porque é necessária visibilidade por perfil de inferência para compreender desempenho e consumo entre configurações geográficas e globais.
As Novas Métricas: TimeToFirstToken e EstimatedTPMQuotaUsage
TimeToFirstToken: Medindo Latência de Streaming
A métrica TimeToFirstToken mede a latência, em milissegundos, do momento em que o Amazon Bedrock recebe sua requisição de streaming até quando o serviço gera o primeiro token de resposta. É emitida para as APIs de streaming: ConverseStream e InvokeModelWithResponseStream. Por ser medida no lado do servidor, reflete a latência real do serviço sem ruído das condições de rede ou processamento no cliente.
Com essa métrica, é possível:
- Definir alarmes de latência — Criar alarmes do CloudWatch que notifiquem quando o tempo até o primeiro token ultrapassa limites aceitáveis, detectando degradação de desempenho antes que afete usuários.
- Estabelecer baselines de SLA — Analisar dados históricos de TimeToFirstToken entre modelos para definir baselines informados de desempenho para as aplicações.
- Diagnosticar problemas de desempenho — Correlacionar TimeToFirstToken com outras métricas do Amazon Bedrock, como InvocationLatency (Tempo até Último Token), isolando se questões de latência originam-se do tempo de resposta inicial do modelo ou do processamento geral da requisição.
A métrica é publicada com a dimensão ModelId e, opcionalmente, com dimensões ServiceTier e ResolvedServiceTier. Para perfis de inferência entre regiões, o ModelId corresponde ao identificador do seu perfil de inferência (por exemplo, us.anthropic.claude-sonnet-4-5-v1), permitindo monitorar TimeToFirstToken separadamente para cada perfil. É emitida apenas para requisições de streaming completadas com sucesso.
EstimatedTPMQuotaUsage: Entendendo Consumo Real de Quota
A métrica EstimatedTPMQuotaUsage acompanha a quota estimada de Tokens Por Minuto (TPM) consumida por suas requisições. Diferentemente dos contadores brutos de tokens, essa métrica leva em conta os fatores que o Amazon Bedrock considera ao avaliar consumo de quota, incluindo tokens de escrita em cache e multiplicadores de redução de tokens de saída. O nome da métrica inclui “Estimated” para refletir que fornece uma aproximação próxima do consumo de quota para fins de monitoramento e planejamento de capacidade.
As decisões internas de limitação do Amazon Bedrock baseiam-se em cálculos em tempo real que podem diferir ligeiramente dessa métrica, mas EstimatedTPMQuotaUsage foi projetada para fornecer um sinal confiável e acionável. Deve ser precisa o suficiente para definir alarmes, rastrear tendências de consumo e planejar aumentos de quota com confiança. É emitida em todas as APIs de inferência: Converse, InvokeModel, ConverseStream e InvokeModelWithResponseStream.
Fórmulas de Cálculo de Quota
O cálculo da quota estimada depende de seu tipo de throughput:
Para inferência sob demanda:
EstimatedTPMQuotaUsage = InputTokenCount + CacheWriteInputTokens + (OutputTokenCount × burndown_rate)A taxa de redução varia por modelo. Para a lista completa de modelos e suas respectivas taxas, consulte a documentação sobre multiplicadores de redução de token para gestão de quota. Para inferência sob demanda, tokens de leitura em cache não contam para a quota.
Como exemplo, Claude Sonnet 4.5 aplica uma taxa de redução de 5x em tokens de saída. Uma requisição sob demanda com 1.000 tokens de entrada, 200 tokens de escrita em cache e 100 tokens de saída consome 1.000 + 200 + (100 × 5) = 1.700 tokens de quota. Isso é 400 tokens a mais do que se estimasse apenas a partir dos contadores brutos.
Para Throughput Provisionado (camada reservada):
EstimatedTPMQuotaUsage = InputTokenCount + (CacheWriteInputTokens × 1.25) + (CacheReadInputTokens × 0.1) + OutputTokenCountNo Throughput Provisionado, o multiplicador de redução em tokens de saída não se aplica. Contudo, tokens de leitura em cache contribuem com taxa 0.1 e tokens de escrita em cache são ponderados em 1.25. Note que faturamento difere de uso de quota — você é faturado pelo uso real de tokens, não pelos valores ajustados ou ponderados. Para mais detalhes, consulte multiplicadores de redução de token para gestão de quota.
Com essa métrica, é possível:
- Definir alarmes proativos de quota — Criar alarmes do CloudWatch que disparem quando o uso de quota estimado se aproxima do limite de TPM, permitindo agir antes que requisições sejam limitadas.
- Rastrear consumo entre modelos — Comparar uso de quota entre diferentes modelos para entender quais cargas consumem mais capacidade e otimizar adequadamente.
- Planejar aumentos de quota — Usar tendências históricas de consumo para solicitar aumentos de quota através das quotas de serviço da AWS antes que o crescimento de uso cause limitação.
Dimensões e Filtragem de Métricas
Ambas as métricas compartilham as seguintes características:
- Incluem dimensões como ModelId, permitindo filtrar e agregar dados por modelo.
- Ao usar um perfil de inferência entre regiões, seja geográfico (por exemplo, us.anthropic.claude-sonnet-4-5-v1) ou global (por exemplo, global.anthropic.claude-sonnet-4-5-v1), a dimensão ModelId corresponde ao identificador do seu perfil de inferência.
- Isso oferece visibilidade granular sobre desempenho e consumo entre suas configurações de inferência, permitindo visualizar métricas separadas para cada combinação de perfil de inferência entre regiões e modelo.
- Isso é consistente com métricas CloudWatch existentes do Amazon Bedrock como Invocations, InvocationLatency e métricas de contagem de tokens.
| Atributo | TimeToFirstToken | EstimatedTPMQuotaUsage |
|---|---|---|
| Namespace CloudWatch | AWS/Bedrock | AWS/Bedrock |
| Unidade | Milissegundos | Contagem |
| APIs Suportadas | ConverseStream, InvokeModelWithResponseStream | Converse, InvokeModel, ConverseStream, InvokeModelWithResponseStream |
| Frequência de Atualização | Agregação de 1 minuto | Agregação de 1 minuto |
| Escopo | Requisições de streaming completadas com sucesso | Requisições completadas com sucesso |
| Dimensão Principal | ModelId | ModelId |
| Dimensões Opcionais | ServiceTier, ResolvedServiceTier | ServiceTier, ResolvedServiceTier, ContextWindow (para contextos de entrada superiores a 200K tokens) |
| Tipos de Inferência Suportados | Inferência entre regiões (geográfica e global), inferência na mesma região | Inferência entre regiões (geográfica e global), inferência na mesma região |
Começando a Usar as Novas Métricas
Essas métricas já estão disponíveis em seu dashboard do CloudWatch. Quando sua aplicação chama uma API de inferência do Amazon Bedrock, o serviço processa a requisição, invoca o modelo e publica todas as métricas aplicáveis — incluindo TimeToFirstToken e EstimatedTPMQuotaUsage — no namespace AWS/Bedrock em sua conta CloudWatch. Você pode então usar dashboards, alarmes e matemática de métricas do CloudWatch para monitorar, alertar e analisar essas métricas.
Para começar:
- Abra a console do Amazon CloudWatch e navegue para Métricas > Todas as métricas.
- Selecione o namespace AWS/Bedrock.
- Encontre as métricas TimeToFirstToken ou EstimatedTPMQuotaUsage e filtre por ModelId para visualizar dados de modelos específicos.
- Crie alarmes para receber notificações sobre degradação de latência ou consumo de quota aproximando-se de seus limites.
Exemplos Práticos
Gerando Dados de Métrica com Requisições de Inferência
Para gerar pontos de dados de métrica, faça requisições de inferência contra o Amazon Bedrock. Os exemplos a seguir usam o AWS SDK para Python (Boto3) para demonstrar uma requisição sem streaming (que emite EstimatedTPMQuotaUsage) e uma com streaming (que emite TimeToFirstToken e EstimatedTPMQuotaUsage). Nesses exemplos, usamos us-east-1 como a Região AWS e us.anthropic.claude-sonnet-4-6-v1 como um perfil de inferência entre regiões. Substitua pelos seus próprios valores.
Converse (sem streaming):
import boto3
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
response = bedrock.converse(
modelId='us.anthropic.claude-sonnet-4-6-v1',
messages=[
{
'role': 'user',
'content': [{'text': 'What is the capital of France?'}]
}
]
)
print(response['output']['message']['content'][0]['text'])
print(f"Input tokens: {response['usage']['inputTokens']}")
print(f"Output tokens: {response['usage']['outputTokens']}")ConverseStream (com streaming):
import boto3
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
response = bedrock.converse_stream(
modelId='us.anthropic.claude-sonnet-4-6-v1',
messages=[
{
'role': 'user',
'content': [{'text': 'What is the capital of France?'}]
}
]
)
for event in response['stream']:
if 'contentBlockDelta' in event:
print(event['contentBlockDelta']['delta']['text'], end='')
print()As mesmas métricas são emitidas para as APIs InvokeModel (sem streaming) e InvokeModelWithResponseStream (com streaming). A tabela abaixo resume quais métricas cada API emite:
| API | Métricas Emitidas |
|---|---|
| Converse | EstimatedTPMQuotaUsage |
| ConverseStream | EstimatedTPMQuotaUsage, TimeToFirstToken |
| InvokeModel | EstimatedTPMQuotaUsage |
| InvokeModelWithResponseStream | EstimatedTPMQuotaUsage, TimeToFirstToken |
Após fazer essas requisições, aguarde aproximadamente 1 a 2 minutos para que as métricas apareçam. Então navegue até a console CloudWatch em Métricas > Todas as métricas > AWS/Bedrock para verificar que os pontos de dados estão presentes para seu modelo.
Consultando Métricas Usando a AWS CLI
Você pode usar a AWS CLI para verificar que as novas métricas estão disponíveis e recuperar seus valores. Primeiro, confirme que as métricas estão sendo publicadas para seu modelo:
# Listar métricas disponíveis de TimeToFirstToken
aws cloudwatch list-metrics --namespace AWS/Bedrock --metric-name TimeToFirstToken
# Listar métricas disponíveis de EstimatedTPMQuotaUsage
aws cloudwatch list-metrics --namespace AWS/Bedrock --metric-name EstimatedTPMQuotaUsageConclusão
Com as novas métricas TimeToFirstToken e EstimatedTPMQuotaUsage do CloudWatch, o Amazon Bedrock oferece a observabilidade necessária para executar cargas de trabalho de inteligência artificial generativa em produção com confiança.
Pontos principais:
- Medir latência de streaming no lado do servidor — TimeToFirstToken fornece medição precisa de latência no lado do servidor para APIs de streaming sem exigir nenhuma instrumentação no cliente.
- Compreender o verdadeiro consumo de quota — EstimatedTPMQuotaUsage reflete o impacto estimado de quota de suas requisições, incluindo multiplicadores de redução, permitindo prever e prevenir limitação.
- Nenhuma ação necessária para começar — Ambas as métricas são emitidas automaticamente sem custo adicional. Abra seu dashboard do CloudWatch para começar a usá-las.
- Definir alarmes proativos — Use essas métricas para criar alarmes que detectem problemas de desempenho e pressão de quota antes que afetem suas aplicações.
Abra sua console do Amazon CloudWatch hoje mesmo para explorar essas novas métricas e configurar alarmes adaptados aos requisitos de sua carga de trabalho.
Referências
- Documentação de monitoramento do Amazon Bedrock
- Multiplicadores de redução de token para gestão de quota
- Quotas e limites do Amazon Bedrock
- Documentação de alarmes do Amazon CloudWatch
Fonte
Improve operational visibility for inference workloads on Amazon Bedrock with new CloudWatch metrics for TTFT and Estimated Quota Consumption (https://aws.amazon.com/blogs/machine-learning/improve-operational-visibility-for-inference-workloads-on-amazon-bedrock-with-new-cloudwatch-metrics-for-ttft-and-estimated-quota-consumption/)
Leave a Reply