Qu’est-ce que la cardinalité des métriques et pourquoi l’observabilité de l’IA peut-elle devenir coûteuse ?

La cardinalité des métriques correspond au nombre de combinaisons distinctes de libellés stockées sous forme de séries temporelles, et des libellés IA non bornés peuvent multiplier l'utilisation des ressources de manière inattendue.

Une métrique de latence semble inoffensive jusqu'à ce qu'elle soit étiquetée par modèle, route, utilisateur, outil, statut, quantification et identifiant de requête brut. Chaque combinaison observée devient une série distincte, avec des coûts d'indexation, de mémoire, de requête et de rétention. Les piles IA produisent naturellement de nombreux identifiants uniques ; les dépenses liées à l'observabilité peuvent donc augmenter plus vite que le volume de requêtes, même sur un serveur auto-hébergé sans facture cloud.

Chaque ensemble de libellés distinct crée une nouvelle série temporelle

Un nom de métrique associé à un ensemble complet de valeurs de libellés identifie une série. Dix modèles, cinq routes, quatre statuts et vingt outils peuvent créer des milliers de combinaisons possibles avant même d'ajouter un identifiant utilisateur ou de requête. Le nombre réel dépend des combinaisons effectivement observées, et pas seulement des libellés déclarés.

Les recommandations de Prometheus sur la cardinalité des libellés indiquent que chaque ensemble de libellés augmente les coûts en RAM, en CPU, sur disque et sur le réseau, et recommandent d'analyser les métriques dont la cardinalité devient élevée. Elles mettent notamment en garde contre les libellés aux valeurs non bornées, comme les identifiants utilisateur ou les adresses e-mail.

La cardinalité diffère de la fréquence d'échantillonnage. Une série interrogée chaque seconde peut contenir de nombreux échantillons, tandis qu'un million de séries rarement mises à jour impose malgré tout une importante surcharge d'indexation et de métadonnées, car le backend doit suivre l'identité de chacune.

Les workflows IA contiennent des libellés séduisants mais dangereux

Le nom du modèle, le point de terminaison, la catégorie d'outil, le statut de réponse et un niveau matériel borné peuvent permettre des agrégations utiles. Le texte des prompts, le chemin des documents, l'ID de trace, l'ID de session, les arguments générés des outils et les messages d'erreur complets sont pratiquement non bornés et transforment les métriques en magasin d'événements accidentel.

Le tableau de bord de cardinalité de Grafana explique que les tableaux de bord à forte cardinalité examinent les séries actives et la répartition des libellés afin que les opérateurs puissent relier les métriques inutilisées au coût d'ingestion. La même méthode peut révéler si un nouveau libellé d'agent a provoqué une explosion soudaine du nombre de séries.

Le contexte de diagnostic unique doit être placé dans des traces échantillonnées ou des journaux structurés, reliés par des exemplars lorsque ceux-ci sont pris en charge. Les métriques doivent répondre à des questions agrégées au moyen de dimensions volontairement bornées, plutôt que conserver chaque requête comme valeur de libellé. Cette distinction reste visible lors des tests ultérieurs à domicile.

Les combinaisons se multiplient avant que les requêtes ne ralentissent visiblement

Plusieurs libellés individuellement modérés peuvent former un produit cartésien considérable. La rotation des séries aggrave le problème lorsque les conteneurs, les versions de modèles ou les chemins normalisés créent continuellement de nouvelles identités qui restent conservées après l'évolution de la charge active.

Un exemple de pics de cardinalité de Grafana définit la cardinalité à partir des valeurs de libellés distinctes et montre comment les pics augmentent le nombre de séries stockées. Cela explique pourquoi une petite modification de l'instrumentation peut accroître le travail d'ingestion et de requête sans modifier le trafic d'inférence.

Le seuil critique est atteint lorsque l'observabilité consomme suffisamment de mémoire, d'E/S ou de CPU pour perturber le service IA qu'elle mesure. Supprimer un libellé après l'ingestion peut réduire la croissance future, mais n'efface pas immédiatement les séries historiques et ne répare pas les tableaux de bord qui en dépendaient.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Définissez un budget de cardinalité avant d'ajouter des libellés

Inventoriez chaque métrique et estimez la limite supérieure de chaque libellé et des combinaisons courantes. Rejouez une journée représentative, mesurez les séries actives, la rotation des séries, les octets ingérés, le temps des requêtes et la mémoire, puis classez les libellés selon leur valeur diagnostique et le nombre supplémentaire de séries qu'ils créent.

Comparez ces résultats avec les signaux d'observabilité plus larges décrits dans l'observabilité de l'IA locale. Déplacez le contexte unique des requêtes vers les journaux ou les traces, normalisez les chemins dynamiques et n'exposez les catégories de modèles ou d'outils que lorsqu'un tableau de bord ou une alerte a un objectif défini.

Définissez des budgets et des alertes pour les séries actives et le taux de création avant le déploiement. L'instrumentation n'est validée que si elle répond aux questions opérationnelles ciblées sans modifier sensiblement la latence d'inférence ni épuiser le stockage de rétention lors des pics d'utilisation domestique.