¿Qué es la cardinalidad de las métricas y por qué la observabilidad de la IA puede volverse costosa?
La cardinalidad de las métricas es el número de combinaciones de etiquetas distintas almacenadas como series temporales, y las etiquetas de IA sin límites pueden multiplicar inesperadamente el uso de recursos.
Una métrica de latencia parece inofensiva hasta que se etiqueta por modelo, ruta, usuario, herramienta, estado, cuantización e ID de solicitud sin procesar. Cada combinación observada se convierte en una serie independiente con costes de indexación, memoria, consultas y retención. Las pilas de IA generan muchos identificadores naturalmente únicos, por lo que el gasto en observabilidad puede crecer más rápido que el volumen de solicitudes incluso en un servidor autoalojado sin factura de la nube.
Cada conjunto de etiquetas distinto crea otra serie temporal
Un nombre de métrica más un conjunto completo de valores de etiquetas identifica una serie. Diez modelos, cinco rutas, cuatro estados y veinte herramientas pueden crear miles de combinaciones posibles antes de añadir cualquier identificador de usuario o solicitud. El recuento real depende de las combinaciones observadas, no solo de las etiquetas declaradas.
La guía de cardinalidad de etiquetas de Prometheus señala que cada conjunto de etiquetas añade costes de RAM, CPU, disco y red, y recomienda investigar las métricas cuya cardinalidad aumenta considerablemente. Advierte específicamente contra las etiquetas con valores ilimitados, como los ID de usuario o las direcciones de correo electrónico.
La cardinalidad es diferente de la frecuencia de muestreo. Una serie consultada cada segundo puede contener muchas muestras, mientras que un millón de series actualizadas raramente siguen imponiendo una gran sobrecarga de índices y metadatos porque el backend debe realizar el seguimiento de la identidad de cada una.
Los flujos de trabajo de IA contienen etiquetas atractivas pero peligrosas
El nombre del modelo, el punto de conexión, la clase de herramienta, el estado de respuesta y un nivel de hardware acotado pueden permitir una agregación útil. El texto de las indicaciones, la ruta del documento, el ID de traza, el ID de sesión, los argumentos generados de las herramientas y los mensajes de error completos son, en la práctica, ilimitados y convierten las métricas en un almacén de eventos accidental.
El panel de cardinalidad de Grafana explica que los paneles de alta cardinalidad inspeccionan las series activas y la distribución de etiquetas para que los operadores puedan relacionar las métricas sin uso con el coste de ingesta. El mismo método puede revelar si una nueva etiqueta de agente provocó una explosión repentina de series.
El contexto de diagnóstico único debe incluirse en trazas muestreadas o registros estructurados, vinculados mediante ejemplares cuando sean compatibles. Las métricas deben responder a preguntas agregadas con dimensiones acotadas intencionadamente, en lugar de conservar cada solicitud como un valor de etiqueta. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
Las combinaciones se multiplican antes de que las consultas se ralenticen visiblemente
Varias etiquetas individualmente moderadas pueden formar un gran producto cartesiano. La rotación de series empeora el problema cuando los contenedores, las versiones de los modelos o las rutas normalizadas crean continuamente nuevas identidades que permanecen durante el periodo de retención después de que cambia la carga de trabajo activa.
Un ejemplo de picos de cardinalidad de Grafana define la cardinalidad mediante valores de etiquetas distintos y muestra cómo los picos aumentan el número de series almacenadas. Esto explica por qué un pequeño cambio en la instrumentación puede incrementar el trabajo de ingesta y consultas sin cambiar el tráfico de inferencia.
El límite de fallo se alcanza cuando la observabilidad consume suficiente memoria, E/S o CPU como para afectar al servicio de IA que mide. Eliminar una etiqueta después de la ingesta puede reducir el crecimiento futuro, pero no borra inmediatamente las series históricas ni repara los paneles que dependían de ella.
Establece un presupuesto de cardinalidad antes de añadir etiquetas
Haz un inventario de cada métrica y estima el límite superior de cada etiqueta y de las combinaciones habituales. Reproduce un día representativo, mide las series activas, la rotación de series, los bytes ingeridos, el tiempo de consulta y la memoria, y después clasifica las etiquetas según su valor de diagnóstico y el número incremental de series.
Compara esos resultados con las señales de observabilidad más amplias descritas en la observabilidad de IA local. Mueve el contexto único de las solicitudes a los registros o las trazas, normaliza las rutas dinámicas y expón las categorías de modelos o herramientas solo cuando un panel o una alerta tenga un uso definido.
Establece presupuestos y alertas para las series activas y la tasa de creación antes del despliegue. La instrumentación solo se considera válida cuando responde a las preguntas operativas objetivo sin cambiar de forma significativa la latencia de inferencia ni agotar el almacenamiento de retención durante el uso doméstico máximo.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Puede un LLM local reanudar la generación después de que se reinicie su proceso?
Una explicación de la reanudación de la generación de LLM desde el mecanismo, sus concesiones en recursos compartidos, tres preguntas frecuentes sobre la ramificación...
¿Puede un servidor doméstico ejecutar embeddings y transcodificación de vídeo en la misma GPU integrada?
Una explicación centrada en el mecanismo de las representaciones vectoriales compartidas de la iGPU y la transcodificación, sus ventajas y desventajas en cuanto a...
¿Cómo afecta la duración de los tokens de acceso a la seguridad y las molestias en el hogar?
Una explicación centrada en el mecanismo sobre la duración de los tokens de acceso, sus ventajas y desventajas respecto a los recursos compartidos, tres...
