Che cos'è la cardinalità delle metriche e perché l'osservabilità dell'IA può diventare costosa?
La cardinalità delle metriche è il numero di combinazioni distinte di etichette memorizzate come serie temporali e le etichette AI non vincolate possono moltiplicare in modo imprevisto l'uso delle risorse.
Una metrica della latenza sembra innocua finché non viene etichettata in base a modello, percorso, utente, strumento, stato, quantizzazione e ID della richiesta originale. Ogni combinazione osservata diventa una serie separata, con costi di indicizzazione, memoria, query e conservazione. Gli stack AI producono molti identificatori naturalmente univoci, quindi la spesa per l'osservabilità può crescere più rapidamente del volume delle richieste anche su un server self-hosted senza costi cloud.
Ogni set distinto di etichette crea un'altra serie temporale
Il nome di una metrica più un set completo di valori delle etichette identifica una serie. Dieci modelli, cinque percorsi, quattro stati e venti strumenti possono creare migliaia di combinazioni possibili prima ancora di aggiungere un identificatore dell'utente o della richiesta. Il numero effettivo dipende dalle combinazioni realmente osservate, non solo dalle etichette dichiarate.
Le linee guida di Prometheus sulla cardinalità delle etichette indicano che ogni set di etichette aggiunge costi in termini di RAM, CPU, disco e rete e raccomandano di analizzare le metriche la cui cardinalità diventa elevata. Avvertono in particolare di evitare etichette con valori non vincolati, come gli ID utente o gli indirizzi email.
La cardinalità è diversa dalla frequenza di campionamento. Una serie campionata ogni secondo può contenere molti campioni, mentre un milione di serie aggiornate raramente impone comunque un notevole sovraccarico di indici e metadati, perché il backend deve tenere traccia di ogni identità.
I flussi di lavoro AI contengono etichette allettanti ma pericolose
Il nome del modello, l'endpoint, la classe dello strumento, lo stato della risposta e un livello hardware limitato possono supportare aggregazioni utili. Il testo del prompt, il percorso del documento, l'ID della traccia, l'ID della sessione, gli argomenti generati per gli strumenti e i messaggi di errore completi sono di fatto non vincolati e trasformano le metriche in un archivio di eventi accidentale.
La dashboard sulla cardinalità di Grafana spiega che le dashboard ad alta cardinalità analizzano le serie attive e la distribuzione delle etichette, consentendo agli operatori di collegare le metriche inutilizzate ai costi di acquisizione. Lo stesso metodo può rivelare se una nuova etichetta dell'agente ha causato un'improvvisa esplosione delle serie.
Il contesto diagnostico univoco appartiene alle tracce campionate o ai log strutturati, collegati tramite esemplari quando supportati. Le metriche dovrebbero rispondere a domande aggregate con dimensioni intenzionalmente limitate, invece di conservare ogni richiesta come valore di un'etichetta. Questa distinzione rimane visibile durante i successivi test in ambiente domestico.
Le combinazioni si moltiplicano prima che le query diventino visibilmente lente
Diverse etichette singolarmente moderate possono formare un grande prodotto cartesiano. Il ricambio delle serie peggiora il problema quando container, versioni dei modelli o percorsi normalizzati creano continuamente nuove identità che rimangono nella conservazione anche dopo il cambiamento del carico di lavoro attivo.
Un esempio di picchi di cardinalità di Grafana definisce la cardinalità attraverso i valori distinti delle etichette e mostra come i picchi aumentino il numero di serie memorizzate. Questo spiega perché una piccola modifica alla strumentazione possa aumentare il lavoro di acquisizione e delle query senza modificare il traffico di inferenza.
Il limite critico si raggiunge quando l'osservabilità consuma abbastanza memoria, I/O o CPU da compromettere il servizio AI che sta misurando. Eliminare un'etichetta dopo l'acquisizione può ridurre la crescita futura, ma non cancella immediatamente le serie storiche né corregge le dashboard che dipendevano da essa.
Definisci un budget per la cardinalità prima di aggiungere etichette
Inventaria ogni metrica e stima il limite superiore di ciascuna etichetta e delle combinazioni più comuni. Riproduci una giornata rappresentativa, misura le serie attive, il ricambio delle serie, i byte acquisiti, il tempo delle query e la memoria, quindi classifica le etichette in base al valore diagnostico e al numero incrementale di serie.
Confronta questi risultati con i segnali di osservabilità più ampi descritti nell'osservabilità dell'AI locale. Sposta il contesto univoco delle richieste nei log o nelle tracce, normalizza i percorsi dinamici ed esponi le categorie di modelli o strumenti solo quando una dashboard o un avviso ne ha un uso definito.
Imposta budget e avvisi per le serie attive e il tasso di creazione prima della distribuzione. La strumentazione supera il test solo quando risponde alle domande operative stabilite senza modificare in modo significativo la latenza di inferenza né esaurire lo spazio di conservazione durante il picco di utilizzo domestico.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Un LLM locale può riprendere la generazione dopo il riavvio del processo?
Una spiegazione della ripresa della generazione degli LLM incentrata sui meccanismi, dei compromessi relativi alle risorse condivise, tre domande frequenti sul fan-out delle query...
Un server domestico può eseguire embedding e transcodifica video sulla stessa GPU integrata?
Una spiegazione basata innanzitutto sui meccanismi degli embedding condivisi della iGPU e della transcodifica, dei compromessi legati alle risorse condivise, tre domande frequenti sul...
In che modo la durata del token di accesso influisce sulla sicurezza e sulle difficoltà per le famiglie?
Una spiegazione della durata dei token di accesso basata prima di tutto sul meccanismo, dei compromessi legati alle risorse condivise, di tre domande frequenti...
