Como a Adobe Firefly Acelerou a Observabilidade de GPUs em 28x com Amazon Managed Service for Prometheus

Observabilidade: O Gargalo Invisível no Treinamento de IA

Escalar infraestrutura de treinamento de IA não é só adicionar mais GPUs. O verdadeiro herói por trás de um desenvolvimento eficiente é a observabilidade. Sem uma visão clara da utilização de GPU, consumo de memória e throughput de rede, os engenheiros trabalham às cegas, sem conseguir identificar gargalos ou otimizar a alocação de recursos.

A Adobe Firefly, suíte de IA generativa que hoje alimenta ferramentas criativas no Photoshop e Illustrator, enfrentou exatamente esse desafio. A infraestrutura de treinamento, construída sobre Amazon EKS, gera uma quantidade massiva de telemetria. Com jobs rodando em milhares de nós e dezenas de milhares de GPUs, o volume de métricas rapidamente sobrecarregou a configuração inicial de observabilidade.

Vamos mergulhar na evolução da Adobe, que saiu de uma implantação self-managed de Prometheus para uma arquitetura híbrida com o Amazon Managed Service for Prometheus. O resultado? Queries 28x mais rápidas e uma janela de observabilidade 4x maior — uma mudança fundamental na forma como times de infraestrutura podem suportar workloads de IA.

O Desafio: Métricas de Alta Cardinalidade em Escala Massiva

Clusters de treinamento de GPU não são workloads de TI comuns. A telemetria gerada é de alta cardinalidade, ou seja, abrange múltiplas dimensões simultaneamente. Um único job de treinamento pode precisar monitorar saúde da GPU, utilização de computação, pressão de memória e I/O de rede ao mesmo tempo.

Para entender a escala, considere: um job rodando em 2.000 nós com 16.000 GPUs, com coleta a cada 30 segundos, pode gerar mais de 1 bilhão de pontos de dados em uma única janela de query. Abordagens tradicionais de monitoramento, mesmo com Prometheus self-managed, têm dificuldade de entregar resultados rápidos nessa escala.

A infraestrutura original da Adobe usava Prometheus self-hosted, enviando dados para armazenamento remoto. Conforme a adoção do Firefly crescia, essa arquitetura começou a mostrar limitações:

• Timeouts em queries: Queries complexas frequentemente excediam o limite de 60 segundos.
• Overhead operacional: Manter Prometheus em escala exigia recursos dedicados de engenharia.
• Visibilidade limitada: A janela prática de monitoramento era de apenas 6 horas, insuficiente para jobs longos.

"O desafio não era só armazenar mais dados; era conseguir consultá-los rápido o suficiente para tomar decisões em tempo real durante o treinamento."

A Evolução para Serviços Gerenciados

A jornada da Adobe para o Amazon Managed Service for Prometheus foi iterativa, não uma reescrita completa. Essa estratégia é valiosa para qualquer pessoa considerando migrações similares. Eles não removeram a infraestrutura existente. Em vez disso, usaram coletores do Amazon Managed Service for Prometheus (managed scrapers) junto com a configuração self-managed.

Essa abordagem incremental oferece vantagens importantes:

1. Zero disrupção: Workflows de monitoramento existentes continuaram funcionando.
2. Migração direcionada: Apenas métricas críticas foram movidas inicialmente.
3. Comparação direta: O time pôde medir as melhorias de performance lado a lado.

# Exemplo: Configurando um managed scraper junto com o Prometheus existente
apiVersion: v1
kind: ConfigMap
metadata:
  name: managed-scraper-config
  namespace: observability
data:
  scrape_configs: |
    - job_name: 'gpu-training-metrics'
      kubernetes_sd_configs:
        - role: pod
      relabel_configs:
        - source_labels: [__meta_kubernetes_pod_label_app]
          regex: 'training-.*'
          action: keep
      metric_relabel_configs:
        # Encaminha apenas métricas críticas para o workspace gerenciado
        - source_labels: [__name__]
          regex: '(gpu_utilization|gpu_memory_used|network_transmit_bytes_total)'
          action: keep

Resultados Mensuráveis e Considerações Importantes

A migração para o Amazon Managed Service for Prometheus trouxe melhorias dramáticas, especialmente na performance de queries. A tabela abaixo compara o serviço gerenciado versus a infraestrutura self-managed:

O Impacto no Mundo Real

Esses números se traduzem em benefícios operacionais tangíveis:

• Visibilidade estendida: Usuários de infraestrutura agora visualizam métricas em janelas de 24 horas, comparado ao limite anterior de 6 horas. Isso é crucial para jobs longos com 256+ nós, onde identificar quando a performance degradou exige ver o ciclo de vida completo.
• Automação habilitada: Queries rápidas e confiáveis permitem construir sistemas automatizados que respondem a eventos de infraestrutura em tempo real.
• Menos sobrecarga operacional: Com componentes totalmente gerenciados, recursos de engenharia são liberados para desenvolvimento de infraestrutura.

Limitações e Cuidados

Apesar dos benefícios, é importante considerar possíveis limitações:

• Estrutura de custos: É um serviço pago, baseado em métricas ingeridas, armazenadas e consultadas. Organizações com volumes massivos precisam estimar custos antes da migração.
• Estratégia de migração: Migração completa não é um processo de um passo. A abordagem incremental da Adobe funcionou bem, mas exige manter dois sistemas durante a transição.
• Limites do workspace: Cada workspace suporta até 50 milhões de séries temporais ativas. Organizações próximas desse limite precisarão considerar estratégias de sharding.

Próximos Passos na Sua Jornada de Observabilidade

Se você gerencia infraestrutura de treinamento de GPU ou outros workloads de alta cardinalidade, considere:

1. Audite suas métricas: Identifique quais são realmente críticas para tomada de decisão.
2. Teste com um piloto: Siga o exemplo da Adobe movendo um conjunto específico de métricas primeiro.
3. Meça antes e depois: Estabeleça métricas de performance iniciais para quantificar as melhorias.

O Futuro da Observabilidade em Infraestrutura de IA

A experiência da Adobe mostra que a infraestrutura de observabilidade precisa evoluir junto com as capacidades de treinamento de IA. A melhoria de 28x na performance de queries e as janelas de monitoramento estendidas não são apenas métricas técnicas — representam uma mudança fundamental no que é possível para times de infraestrutura que suportam workloads de IA.

Conforme os modelos de IA ficam mais complexos, a demanda por observabilidade sofisticada só aumenta. A colaboração entre Adobe e AWS para estender o Prometheus gerenciado para outras camadas de métricas sinaliza um movimento em direção a stacks de observabilidade multi-tenant e altamente disponíveis.

Para times construindo infraestrutura de IA, a lição é clara: invista em arquitetura de observabilidade com a mesma seriedade que investe em computação. A capacidade de ver e entender o que acontece em milhares de GPUs não é um luxo — é essencial para o desenvolvimento eficiente de modelos.

Se você se interessa por desafios de infraestrutura relacionados, veja como a Pantone construiu uma fundação de dados preparada para IA para criatividade agêntica, ou explore a abordagem do Spotify para escalar experiência de desenvolvimento num mundo aumentado por IA.