Was ist metrische Kardinalität, und warum kann KI-Observability teuer werden?
Die Metrikkardinalität ist die Anzahl der unterschiedlichen Labelkombinationen, die als Zeitreihen gespeichert werden. Unbegrenzte KI-Labels können den Ressourcenverbrauch unerwartet vervielfachen.
Eine Latenzmetrik wirkt harmlos, bis sie nach Modell, Route, Benutzer, Tool, Status, Quantisierung und roher Anfrage-ID beschriftet wird. Jede beobachtete Kombination wird zu einer eigenen Zeitreihe mit Kosten für Indizierung, Speicher, Abfragen und Aufbewahrung. KI-Stacks erzeugen viele von Natur aus eindeutige Bezeichner, sodass die Observability-Kosten selbst auf einem selbst gehosteten Server ohne Cloud-Rechnung schneller als das Anfragevolumen wachsen können.
Jede unterschiedliche Labelmenge erzeugt eine weitere Zeitreihe
Ein Metrikname plus eine vollständige Menge von Labelwerten identifiziert eine Zeitreihe. Zehn Modelle, fünf Routen, vier Statuswerte und zwanzig Tools können Tausende möglicher Kombinationen erzeugen, bevor Benutzer- oder Anfragebezeichner hinzukommen. Die tatsächlich erreichte Anzahl hängt von den tatsächlich beobachteten Kombinationen ab, nicht nur von den deklarierten Labels.
Die Hinweise zur Labelkardinalität von Prometheus weisen darauf hin, dass jedes Labelset zusätzlichen RAM-, CPU-, Festplatten- und Netzwerkaufwand verursacht, und empfehlen, Metriken mit hoher Kardinalität zu untersuchen. Insbesondere wird vor Labels mit unbegrenzten Werten wie Benutzer-IDs oder E-Mail-Adressen gewarnt.
Die Kardinalität unterscheidet sich von der Abtastfrequenz. Eine Zeitreihe, die jede Sekunde erfasst wird, kann viele Samples enthalten, während eine Million selten aktualisierter Zeitreihen dennoch einen hohen Aufwand für Index und Metadaten verursachen, da das Backend jede Identität nachverfolgen muss.
KI-Workflows enthalten attraktive, aber gefährliche Labels
Modellname, Endpunkt, Toolklasse, Antwortstatus und begrenzte Hardwareklasse können nützliche Aggregationen ermöglichen. Prompttext, Dokumentpfad, Trace-ID, Sitzungs-ID, generierte Toolargumente und vollständige Fehlermeldungen sind praktisch unbegrenzt und verwandeln Metriken in einen unbeabsichtigten Ereignisspeicher.
Das Kardinalitätsdashboard von Grafana erklärt, dass Dashboards mit hoher Kardinalität aktive Zeitreihen und die Labelverteilung untersuchen, damit Betreiber ungenutzte Metriken mit den Kosten der Datenerfassung in Verbindung bringen können. Mit derselben Methode lässt sich erkennen, ob ein neues Agentenlabel eine plötzliche Explosion der Zeitreihen verursacht hat.
Eindeutiger Diagnosekontext gehört in stichprobenartig erfasste Traces oder strukturierte Logs, die bei entsprechender Unterstützung über Exemplare verknüpft werden. Metriken sollten aggregierte Fragen mit bewusst begrenzten Dimensionen beantworten, statt jede Anfrage als Labelwert zu speichern. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.
Kombinationen vervielfachen sich, bevor Abfragen sichtbar langsam werden
Mehrere einzeln moderate Labels können ein großes kartesisches Produkt bilden. Zeitreihenwechsel verschärfen das Problem, wenn Container, Modellversionen oder normalisierte Pfade fortlaufend neue Identitäten erzeugen, die nach einer Änderung der aktiven Auslastung weiterhin in der Aufbewahrung verbleiben.
Ein Beispiel zu Kardinalitätsspitzen von Grafana definiert die Kardinalität anhand unterschiedlicher Labelwerte und zeigt, wie Spitzen die Anzahl der gespeicherten Zeitreihen erhöhen. Das erklärt, warum eine kleine Änderung an der Instrumentierung den Aufwand für Datenerfassung und Abfragen erhöhen kann, ohne den Inferenzverkehr zu verändern.
Die kritische Grenze ist erreicht, wenn die Observability genügend Speicher, I/O oder CPU verbraucht, um den von ihr gemessenen KI-Dienst zu beeinträchtigen. Das Verwerfen eines Labels nach der Datenerfassung kann das künftige Wachstum reduzieren, löscht jedoch historische Zeitreihen nicht sofort und repariert keine Dashboards, die davon abhängig waren.
Erstelle ein Kardinalitätsbudget, bevor du Labels hinzufügst
Erfasse jede Metrik und schätze die Obergrenze jedes Labels sowie gängiger Kombinationen. Spiele einen repräsentativen Tag nach, messe aktive Zeitreihen, den Zeitreihenwechsel, die erfassten Bytes, die Abfragezeit und den Speicherverbrauch und ordne die Labels anschließend nach Diagnosewert und zusätzlicher Anzahl an Zeitreihen.
Vergleiche diese Ergebnisse mit den umfassenderen Observability-Signalen, die in der lokalen KI-Observability beschrieben werden. Verschiebe eindeutigen Anfragekontext in Logs oder Traces, normalisiere dynamische Pfade und stelle Modell- oder Toolkategorien nur dann bereit, wenn ein Dashboard oder ein Alarm dafür einen definierten Nutzen hat.
Lege vor der Bereitstellung Budgets und Alarme für aktive Zeitreihen und die Erstellungsrate fest. Die Instrumentierung ist nur dann erfolgreich, wenn sie die angestrebten betrieblichen Fragen beantwortet, ohne die Inferenzlatenz wesentlich zu verändern oder während der Spitzenlast im Haushalt den Speicher für die Aufbewahrung zu erschöpfen.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Können Heimkameras Ereignisse ohne Cloud-Zeitdienste synchronisieren?
Eine mechanismusorientierte Erklärung der Kamera-Zeit ohne Cloud, ihrer Zielkonflikte bei gemeinsam genutzten Ressourcen, drei FAQs zur Abfrageweiterleitung und eines praktischen Verifizierungsprotokolls.
Kann ein lokaler KI-Dienst beschädigte Modellschichten vor der Inferenz erkennen?
Eine mechanismusorientierte Erklärung der Erkennung korrupter Modellebenen, ihrer Zielkonflikte bei gemeinsam genutzten Ressourcen, drei FAQs zur Abfrageverteilung und eines praktischen Verifizierungsprotokolls.
Kann ein RAG-System wiederhergestellt werden, ohne jede Einbettung neu zu generieren?
Eine mechanismusorientierte Erklärung zur RAG-Wiederherstellung ohne erneute Einbettung, zu den Zielkonflikten gemeinsamer Ressourcen, drei FAQs zur Abfrage-Fan-out-Strategie und einem praktischen Verifizierungsprotokoll.
