O que é a cardinalidade das métricas e porque pode a observabilidade de IA tornar-se dispendiosa?
A cardinalidade das métricas é o número de combinações distintas de etiquetas armazenadas como séries temporais, e as etiquetas de IA sem limites podem multiplicar inesperadamente a utilização de recursos.
Uma métrica de latência parece inofensiva até ser etiquetada por modelo, rota, utilizador, ferramenta, estado, quantização e ID de pedido bruto. Cada combinação observada torna-se uma série separada, com custos de indexação, memória, consultas e retenção. As pilhas de IA produzem muitos identificadores naturalmente únicos, pelo que os custos de observabilidade podem crescer mais depressa do que o volume de pedidos, mesmo num servidor autoalojado sem custos de cloud.
Cada Conjunto Distinto de Etiquetas Cria Outra Série Temporal
Um nome de métrica mais um conjunto completo de valores de etiquetas identifica uma série. Dez modelos, cinco rotas, quatro estados e vinte ferramentas podem criar milhares de combinações possíveis antes de ser adicionado qualquer identificador de utilizador ou pedido. A contagem efetiva depende das combinações realmente observadas, não apenas das etiquetas declaradas.
As orientações de cardinalidade das etiquetas do Prometheus indicam que cada conjunto de etiquetas acrescenta custos de RAM, CPU, disco e rede, e recomendam investigar métricas cuja cardinalidade se torna elevada. Advertem especificamente contra etiquetas com valores sem limites, como IDs de utilizador ou endereços de e-mail.
A cardinalidade é diferente da frequência de amostragem. Uma série recolhida a cada segundo pode conter muitas amostras, enquanto um milhão de séries atualizadas raramente continuam a impor uma grande sobrecarga de índice e metadados, porque o backend tem de acompanhar a identidade de cada uma.
Os Fluxos de Trabalho de IA Contêm Etiquetas Atrativas mas Perigosas
O nome do modelo, o endpoint, a classe da ferramenta, o estado da resposta e um nível de hardware limitado podem permitir uma agregação útil. O texto do prompt, o caminho do documento, o ID do trace, o ID da sessão, os argumentos gerados da ferramenta e as mensagens de erro completas são, na prática, ilimitados e transformam as métricas num armazenamento acidental de eventos.
O painel de cardinalidade do Grafana explica que os painéis de elevada cardinalidade analisam as séries ativas e a distribuição das etiquetas, permitindo aos operadores associar métricas não utilizadas ao custo de ingestão. O mesmo método pode revelar se uma nova etiqueta de agente provocou uma explosão repentina do número de séries.
O contexto de diagnóstico único deve pertencer a traces amostrados ou a registos estruturados, associados através de exemplars quando houver suporte. As métricas devem responder a perguntas agregadas com dimensões intencionalmente limitadas, em vez de preservarem cada pedido como um valor de etiqueta. Esta distinção continua visível durante os testes domésticos posteriores.
As Combinações Multiplicam-se Antes de as Consultas Ficarem Visivelmente Lentas
Várias etiquetas individualmente modestas podem formar um grande produto cartesiano. A rotatividade das séries agrava o problema quando os contentores, as versões dos modelos ou os caminhos normalizados criam continuamente novas identidades que permanecem na retenção depois de a carga de trabalho ativa mudar.
Um exemplo de picos de cardinalidade do Grafana define a cardinalidade através de valores de etiquetas distintos e mostra como os picos aumentam o número de séries armazenadas. Isto explica por que motivo uma pequena alteração na instrumentação pode aumentar o trabalho de ingestão e de consulta sem alterar o tráfego de inferência.
O limite de falha ocorre quando a observabilidade consome memória, E/S ou CPU suficientes para perturbar o serviço de IA que monitoriza. Remover uma etiqueta após a ingestão pode reduzir o crescimento futuro, mas não elimina imediatamente as séries históricas nem repara os painéis que dependiam dela.
Crie um Orçamento de Cardinalidade Antes de Adicionar Etiquetas
Faça um inventário de cada métrica e estime o limite superior de cada etiqueta e das combinações comuns. Reproduza um dia representativo, meça as séries ativas, a rotatividade das séries, os bytes ingeridos, o tempo das consultas e a memória, e depois classifique as etiquetas pelo valor de diagnóstico e pelo número incremental de séries.
Compare esses resultados com os sinais de observabilidade mais abrangentes descritos em observabilidade de IA local. Transfira o contexto único dos pedidos para registos ou traces, normalize os caminhos dinâmicos e exponha categorias de modelos ou ferramentas apenas quando existir uma utilização definida num painel ou alerta.
Defina orçamentos e alertas para as séries ativas e a taxa de criação antes da implementação. A instrumentação só passa quando responde às questões operacionais pretendidas sem alterar materialmente a latência de inferência nem esgotar o armazenamento de retenção durante a utilização doméstica de pico.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Um LLM local pode retomar a geração depois de o seu processo reiniciar?
Uma explicação da retoma da geração de LLM baseada primeiro no mecanismo, das suas concessões em termos de recursos partilhados, de três perguntas frequentes...
Pode um servidor doméstico executar embeddings e transcodificação de vídeo na mesma GPU integrada?
Uma explicação baseada primeiro no mecanismo dos embeddings partilhados da iGPU e da transcodificação, das suas cedências em termos de recursos partilhados, três perguntas...
Como é que o tempo de vida do token de acesso afeta a segurança e o atrito no agregado familiar?
Uma explicação baseada primeiro no mecanismo da duração dos tokens de acesso, os compromissos relativos aos recursos partilhados, três perguntas frequentes sobre a propagação...
