Observando uma frota efêmera de inferência de IA
A descoberta dinâmica do Prometheus manteve os workers de GPU e os pods de inferência visíveis à medida que seus endereços de provedor mudavam.
Cinco targets estavam UP no snapshot do rollout. Esta entrega adicionou visibilidade; as regras de paging foram um trabalho de acompanhamento à parte.
Contribuição em resumo
- Minha responsabilidade
- Inventário dinâmico de targets, integração com a descoberta do Prometheus e dashboards da frota.
- Escopo
- Workers de inferência efêmeros; a descoberta era atualizada a cada 30 segundos.
- Colaboração & limites
- Conectei as camadas de inventário e de monitoramento. As regras de paging foram um trabalho de acompanhamento à parte.
- Resultado
- Cinco targets estavam UP no snapshot do rollout; os redeployments de workers deixaram de exigir uma lista estática mantida manualmente.
O problema
Pods de GPU alugados recebem novos endereços de provedor após o redeployment. Uma lista estática de targets do Prometheus quebra à medida que esses endereços mudam, e uma visualização web restrita ao operador não oferece o histórico nem a visibilidade compartilhada necessários para o diagnóstico.
Minha contribuição
Expus um inventário dinâmico de targets a partir do router, conectei-o à descoberta de serviços via HTTP do Prometheus e construí uma visão no Grafana da frota de inferência. O router já acompanhava os heartbeats dos workers, então era o lugar certo para descrever a topologia ativa.
Como a descoberta funcionava
O Prometheus consultava o inventário via HTTPS a cada 30 segundos. A lista incluía o router, os workers ativos e os pods de inferência; workers obsoletos desapareciam automaticamente. O endpoint de inventário usava autenticação bearer, e as métricas dos workers eram protegidas antes de serem anunciadas para scraping.
O dashboard reunia os streams ativos, a utilização dos workers e os tokens de inferência por segundo. Mantive os identificadores de stream de alta cardinalidade fora dos gauges em nível de router e preservei as métricas detalhadas de stream na camada dos workers.
Resultados e medição
O rollout verificou cinco targets UP: um router, dois workers e dois pods de inferência. O dashboard mostrava dados de stream e de inferência ao vivo. Esses números descrevem o snapshot de validação, não o tamanho máximo da plataforma.
O limite operacional
Esta entrega estabeleceu a observabilidade, com os limiares de alerta e a responsabilidade pelo on-call deixados como uma decisão à parte. O endpoint de métricas agregadas do engine de inferência manteve uma exceção de autenticação documentada; a integração de descoberta não tornou, por si só, todos os endpoints privados.
A definição do dashboard era versionada, mas a importação continuava sendo um passo manual. O provisionamento automático era uma melhoria futura, não uma capacidade reivindicada para este rollout.
Por que isso importava
A abstração útil era a frota, não um pod alugado individual. Reutilizar o inventário do router disponibilizou essa abstração para o sistema de monitoramento sem adicionar uma segunda fonte da verdade mantida manualmente.
Trabalho relacionado: servindo modelos multimodais entre engines e nuvens.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e seus limites. A próxima melhoria é uma proposta, não um resultado entregue.
Alternativa e justificativa
Targets estáticos são simples, mas se degradam após os redeployments. Um inventário de propriedade do router acompanha o componente que já conhece os workers ativos.
Trade-off
A descoberta depende do endpoint de inventário; labels de stream de alta cardinalidade podem tornar as métricas em nível de frota custosas.
O que eu melhoraria a seguir
Próxima melhoria: adicionar verificações de atualidade da descoberta e testar o comportamento dos alertas quando o inventário ou um worker desaparece.