Deepgram amplia observabilidade de IA no Amazon SageMaker com métricas aprimoradas

O problema clássico de observabilidade em IA de fala auto-hospedada

Quem já operou modelos de inteligência artificial em infraestrutura própria conhece bem um limite frustrante: as métricas padrão de endpoint dizem que o serviço está de pé e quantas requisições foram atendidas, mas as perguntas que realmente importam para planejamento de capacidade e gestão de custos ficam escondidas dentro do contêiner do fornecedor. O que exatamente está sendo cobrado? Quais funcionalidades o tráfego está usando? O que o motor de inferência está fazendo em cada Unidade de Processamento Gráfico (GPU)?

A Deepgram anunciou duas inovações para fechar exatamente essa lacuna em deployments dos seus modelos de fala no Amazon SageMaker AI. As novidades chegam disponíveis hoje para quem utiliza os modelos de Reconhecimento de Fala para Texto (STT) e Síntese de Fala a partir de Texto (TTS) da Deepgram no SageMaker AI.

Como a Deepgram opera no Amazon SageMaker AI

Os modelos de fala da Deepgram estão disponíveis como pacotes de modelo no AWS Marketplace e são implantados como endpoints em tempo real no SageMaker AI, dentro da conta do próprio cliente. Essa arquitetura significa que o áudio e as transcrições ficam dentro da conta AWS do cliente, o que pode apoiar requisitos de residência de dados e conformidade regulatória — sem abrir mão de um plano de controle gerenciado para deploy, escalonamento e monitoramento.

O SageMaker AI já entrega observabilidade básica automaticamente: métricas de invocação como ConcurrentRequestsPerModel e FirstChunkLatency no CloudWatch, logs de contêiner no Amazon CloudWatch Logs e escalonamento automático via alarmes. Os pacotes de modelo do AWS Marketplace rodam com isolamento de rede — o contêiner não faz conexões de saída, o que é justamente o motivo pelo qual clientes com requisitos de segurança mais rígidos escolhem esse modelo de implantação.

O desafio é que esse mesmo isolamento costuma dificultar a telemetria do fornecedor: o contêiner não consegue enviar métricas para um coletor externo, e não há como enxergar o que acontece dentro dele. As duas novidades da Deepgram foram projetadas para funcionar dentro dessa restrição — nenhuma delas exige que o contêiner abra um caminho de rede, e ambas entregam os dados na própria conta CloudWatch do cliente.

Inovação 1 — Transparência de faturamento e uso com Deepgram Enhanced Metrics

As Deepgram Enhanced Metrics respondem duas perguntas que nenhuma métrica padrão de endpoint consegue responder: exatamente o que está sendo cobrado e como o tráfego utiliza as funcionalidades da Deepgram.

Como funciona: métricas que viajam pelo caminho de log

O contêiner da Deepgram escreve registros no formato Formato de Métrica Embarcada do CloudWatch (EMF) no stdout do contêiner. O SageMaker AI já encaminha a saída do contêiner para o grupo de logs do CloudWatch do endpoint, e o CloudWatch Logs extrai os registros EMF em métricas automaticamente.

Esse caminho via EMF traz vantagens práticas importantes:

• Nenhum agente, sidecar ou coletor adicional para implantar.
• Nenhuma permissão de Gerenciamento de Identidade e Acesso (IAM) adicional além do que o endpoint já possui para logging.
• Funciona sob o isolamento de rede do AWS Marketplace, porque as métricas trafegam pelo caminho de logging já existente entre o SageMaker e o CloudWatch.
• São métricas CloudWatch convencionais — aparecem no aws cloudwatch list-metrics e funcionam com dashboards, alarmes e operações matemáticas sobre métricas, sem nenhuma configuração adicional no endpoint.

Todas as dimensões são de baixa cardinalidade e não contêm Informações de Identificação Pessoal (PII): nenhuma transcrição, entrada de TTS ou identificador por requisição. As métricas são agregadas pelos endpoints da Deepgram na conta e região AWS do cliente — as dimensões cobrem categoria, modelo e transporte, mas não o nome do endpoint ou ID da instância.

Reconciliar a fatura do AWS Marketplace: o namespace Deepgram/SageMakerInference

O namespace de faturamento emite um registro por requisição concluída, cobrindo cada sessão de streaming, requisição de áudio pré-gravado e requisição de TTS. A métrica ConsumedUnits carrega os mesmos valores de unidades faturáveis que alimentam o faturamento medido do AWS Marketplace.

As métricas publicadas nesse namespace são:

• ConsumedUnits — Unidades de inferência faturáveis para a requisição. A soma em um período representa o volume total cobrado.
• AudioDurationSeconds — Duração do áudio processado (STT).
• CharCount — Caracteres sintetizados (TTS).

As dimensões são publicadas em três granularidades ([Category], [Category, Model] e [Category, Model, Transport]), permitindo responder tanto “quanto o STT em streaming custou este mês” quanto “quanto disso foi com o modelo nova-3”.

Exemplo de consulta para total de unidades consumidas por hora no STT em streaming:

aws cloudwatch get-metric-statistics \
  --namespace Deepgram/SageMakerInference \
  --metric-name ConsumedUnits \
  --dimensions Name=Category,Value=stt_streaming \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Sum SampleCount \
  --region YOUR_AWS_REGION

O SampleCount representa o número de requisições faturadas. Por serem métricas CloudWatch convencionais, é possível construir um dashboard de faturamento para times financeiros ou configurar um alarme de orçamento sobre as unidades consumidas.

Entender como o endpoint é utilizado: o namespace Deepgram/SelfHosted

Um segundo fluxo de métricas, emitido pelo próprio servidor da API Deepgram, detalha o uso bruto por método, nível de modelo e funcionalidade habilitada — independente do faturamento. Ele responde perguntas de produto: quanto do tráfego é streaming versus pré-gravado, quais camadas de modelo processam mais áudio, e quais funcionalidades (diarização, formatação inteligente, redação, prompting por termos-chave) as aplicações realmente habilitam.

As métricas desse namespace incluem:

• AudioMs, Requests — Volume por streaming comparado a pré-gravado.
• TierAudioMs — Áudio processado por nível de modelo (ex: nova-3, flux).
• FeatureAudioMs, FeatureTokens — Utilização por funcionalidade habilitada (ex: diarize, smart_format, redact).
• TtsCharacters, Tokens, VoiceAgentMs — Volume de TTS, funcionalidades de inteligência e agente de voz.

Exemplo: quanto áudio rodou com diarização habilitada nas últimas 24 horas:

aws cloudwatch get-metric-statistics \
  --namespace Deepgram/SelfHosted \
  --metric-name FeatureAudioMs \
  --dimensions Name=Deployment,Value=sagemaker Name=Feature,Value=diarize \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Sum \
  --region YOUR_AWS_REGION

O fluxo de uso está habilitado por padrão e pode ser desativado com uma variável de ambiente na configuração do endpoint (DEEPGRAM_API_01: emf.enabled=false). O fluxo de faturamento não pode ser desativado — ele faz parte do pipeline de medição.

Inovação 2 — Visibilidade em nível de engine e por GPU com Prometheus e OpenTelemetry

Os contêineres da Deepgram servem um endpoint de métricas Prometheus, e a observabilidade detalhada do SageMaker AI executa um Coletor OpenTelemetry gerenciado pela AWS em cada instância que sustenta o endpoint. Esse coletor faz o scrape do contêiner e exporta os resultados para o CloudWatch, além de exportar métricas por GPU e do host.

Com a observabilidade detalhada habilitada, três fontes de métricas publicam no armazenamento de métricas compatível com OpenTelemetry (OTel) do CloudWatch:

• GPU (exportador DCGM) — Métricas como DCGM_FI_DEV_GPU_UTIL e DCGM_FI_DEV_FB_USED. Em instâncias com múltiplas GPUs, cada GPU reporta separadamente — um dispositivo saturado não consegue se esconder por trás de um número de utilização somado ou médio.
• Host (node exporter) — Métricas padrão do node-exporter Prometheus, como node_cpu_seconds_total e node_memory_MemTotal_bytes, para cada instância.
• Engine Deepgram — O coletor faz scrape diretamente do endpoint Prometheus do contêiner Deepgram. Exemplos: engine_active_requests{kind="stream"} e engine_estimated_stream_capacity. São as mesmas métricas de API e Engine que os clientes self-hosted da Deepgram usam para planejamento de capacidade, agora disponíveis no SageMaker AI sem precisar rodar nenhum coletor próprio. Consulte o Guia de Métricas da Deepgram para a referência completa.

A métrica engine_estimated_stream_capacity é a estimativa do próprio motor Deepgram de quantos streams simultâneos a instância consegue sustentar. Comparar esse valor com engine_active_requests fornece um sinal de headroom reportado pelo engine para decisões de escalonamento.

Cada série carrega rótulos de recurso do SageMaker, incluindo aws.sagemaker.endpoint.name, o nome da variante e o ID da instância — o que permite filtrar por endpoint específico, isolar uma instância em uma frota escalada ou comparar GPUs dentro de uma mesma instância. Como o coletor roda no host, fora do contêiner do modelo, isso funciona mesmo sob o isolamento de rede do AWS Marketplace.

Como habilitar a observabilidade detalhada

A observabilidade detalhada vem habilitada por padrão em endpoints criados recentemente, publicando a cada 60 segundos. Para configurar explicitamente — por exemplo, em um endpoint criado antes do lançamento do recurso, ou para alterar a frequência de publicação — use o MetricsConfig na configuração do endpoint:

aws sagemaker create-endpoint-config \
  --endpoint-config-name YOUR_CONFIG_NAME \
  --production-variants file://production-variants.json \
  --metrics-config '{"EnableDetailedObservability": true, "MetricPublishFrequencyInSeconds": 60}' \
  --region YOUR_AWS_REGION

Para um endpoint já em serviço, basta criar uma nova configuração de endpoint e executar update-endpoint. A atualização é um deploy blue/green — o endpoint permanece em serviço durante a transição.

Consultas com PromQL a partir do CloudWatch, Grafana ou qualquer ferramenta compatível

As métricas ficam no armazenamento de métricas OTel do CloudWatch e são consultadas com PromQL. No editor PromQL do console do CloudWatch, é possível filtrar a utilização por GPU para um endpoint específico:

DCGM_FI_DEV_GPU_UTIL{"aws.sagemaker.endpoint.name"="YOUR_ENDPOINT_NAME"}

O CloudWatch também expõe uma API HTTP padrão compatível com Prometheus para essas métricas, autenticada com SigV4:

awscurl --service monitoring --region YOUR_AWS_REGION \
  "https://monitoring.YOUR_AWS_REGION.amazonaws.com/api/v1/query?query=engine_active_requests"

Para equipes que já padronizaram em Grafana ou outra stack de observabilidade nativa do Prometheus, é possível apontar as ferramentas existentes para a frota do SageMaker AI — sem uma stack de monitoramento paralela, sem pipeline de exportação.

Qual fluxo de métricas usar para cada situação

As duas inovações complementam as métricas nativas do SageMaker AI, sem substituí-las. O mapeamento de perguntas para o fluxo correto é o seguinte:

• O endpoint está saudável? As requisições estão com erro ou lentidão no início? → Métricas padrão do SageMaker (ConcurrentRequestsPerModel, FirstChunkLatency, Invocation5XXErrors).
• Qual será minha fatura no Marketplace e quais modelos a geraram? → Deepgram Enhanced Metrics (namespace Deepgram/SageMakerInference, nível de conta).
• Quais funcionalidades e camadas de modelo meu tráfego realmente usa? → Deepgram Enhanced Metrics (namespace Deepgram/SelfHosted, nível de conta).
• Qual é a saturação de cada GPU? Quanto de capacidade de stream resta em cada instância de um endpoint específico? → Prometheus/OTel via observabilidade detalhada (métricas DCGM e engine Deepgram, por endpoint/instância/GPU).

Como começar

As Deepgram Enhanced Metrics não exigem nenhuma configuração: elas fluem para a conta CloudWatch do cliente a partir do momento em que um endpoint Deepgram no SageMaker AI começa a servir tráfego. A observabilidade detalhada já vem habilitada por padrão em novos endpoints e requer apenas uma mudança na configuração do endpoint para ser adicionada aos existentes.

Para começar, os recursos disponíveis são:

• Implante a Deepgram a partir do AWS Marketplace e siga o guia Deploy Deepgram on Amazon SageMaker.
• Referência: Deepgram Enhanced Metrics, Prometheus & OpenTelemetry Metrics e o Guia de Métricas para a lista completa de métricas de API e Engine da Deepgram.
• Documentação AWS: Observabilidade detalhada para endpoints do SageMaker AI.

Vale destacar que rodar modelos Deepgram no SageMaker AI gera cobranças pela hospedagem do endpoint (incluindo instâncias GPU), pelos logs e métricas do Amazon CloudWatch e pelos recursos de rede associados. O trial de 14 dias dos modelos Deepgram não tem custo adicional, mas os custos de infraestrutura AWS se aplicam desde o início do deploy. Recomenda-se revisar a precificação do SageMaker AI e usar o AWS Cost Explorer para monitorar os gastos.

Conclusão

A Deepgram fecha uma lacuna que existia há muito tempo: a distância entre os contadores de requisição do serviço e a fatura do fornecedor. Com as Enhanced Metrics, os valores exatos que alimentam o faturamento do AWS Marketplace chegam diretamente na conta CloudWatch do cliente, sem infraestrutura adicional. O detalhamento de uso por funcionalidade também fica disponível no mesmo lugar.

Com o suporte a Prometheus e OpenTelemetry via observabilidade detalhada do SageMaker AI, as métricas de capacidade e carga do próprio motor Deepgram — junto com a utilização por GPU — ficam a uma consulta PromQL de distância, nas ferramentas que o time já utiliza. Essas capacidades seguem o investimento da Deepgram no SageMaker AI como opção preferencial de deploy para IA de fala auto-hospedada, após a introdução da Delegação Temporária IAM para acesso de suporte.

Fonte

Deepgram deepens Amazon SageMaker AI observability with Enhanced Metrics (https://aws.amazon.com/blogs/machine-learning/deepgram-deepens-amazon-sagemaker-ai-observability-with-enhanced-metrics/)