Métricas que importan para la inferencia de LLM

Los usuarios sienten un retraso antes de ver las palabras. La baja latencia es crucial para una buena experiencia de usuario y para optimizar el rendimiento de un modelo, ya que minimizar los tiempos de respuesta afecta directamente a la percepción de los usuarios sistemas de IA generativa. Los sistemas fallan cuando las colas se alargan y la memoria se agota. Un pequeño conjunto de métricas puede avisarle con antelación e indicar la solución correcta. El seguimiento de estas métricas es crucial para garantizar la confiabilidad del sistema y mantener el rendimiento del modelo. Mantén la lista corta, conéctala bien y haz que las alertas sean aburridas.

En Compute, un VLLM punto final le ofrece una URL HTTPS con rutas al estilo de OpenAI y una capacidad predecible. Colócala cerca de los usuarios y, a continuación, observa el margen de ampliación de TTFT, TPS y caché.

Métricas principales

Estas son las principales métricas de rendimiento para la inferencia de LLM. Diversos factores, como la complejidad de las solicitudes de entrada, el uso de los recursos y la configuración del sistema, influyen en estas métricas. Se utilizan herramientas de supervisión y diferentes métodos para rastrearlos y analizarlos.

Tiempo hasta el primer token (TTFT). Brecha entre el envío de la solicitud y el primer token. El número más importante para los tiempos de respuesta percibidos y la experiencia del usuario. El mecanismo de atención y el tiempo de prellenado contribuyen en gran medida a la demora antes de recibir el primer token, ya que el modelo procesa los tokens de entrada y crea su caché de valores clave antes de generar respuestas. Pista p50 y p95. El símbolo final marca el final de una respuesta.

Tokens por segundo (TPS). Rendimiento una vez que se inician los tokens. Cuanto más alto, mejor para la experiencia de usuario y la capacidad. El TPS se calcula en función del número de solicitudes que se procesan y del número de tokens de salida generados por segundo para todas las solicitudes, que a menudo se miden junto con las solicitudes por segundo. La latencia entre tokens es el tiempo promedio entre tokens consecutivos, y el TPS total es una métrica clave para el rendimiento del sistema. Un cálculo eficiente de la atención puede ayudar a reducir la latencia entre tokens. Rastrea los números p50 y p95.

Longitud de la cola. Solicitudes en espera de un espacio de descodificación. El aumento de longitud con tráfico plano equivale a problemas.

Espacio libre de memoria de la GPU. VRAM libre durante los picos. El bajo margen de maniobra predice las fallas, los arranques lentos y los desalojos. Al supervisar la memoria de la GPU, se deben tener en cuenta las implicaciones en cuanto al uso de los recursos y los costos.

Tasa de aciertos de caché. Estado de la caché KV y de cualquier caché de mensajes. Los índices de aciertos más bajos suelen explicar la fluencia del TTFT.

Tiempo de prellenado frente a tiempo de decodificación. El tiempo de prellenado se ve afectado por la solicitud de entrada y la cantidad de tokens de entrada, ya que estos factores determinan cuánto tiempo pasa el modelo en la fase de prellenado antes de la decodificación.

Porcentaje de errores por tipo. La complejidad y otros factores pueden influir en las tasas de error, por lo que el seguimiento por tipo ayuda a identificar las causas fundamentales.

Nota: Estas métricas pueden variar según la configuración del sistema, la complejidad de la carga de trabajo y el proveedor de servicios.

Start in seconds with the fastest, most affordable cloud GPU clusters.

Launch an instance in under a minute. Enjoy flexible pricing, powerful hardware, and 24/7 support. Scale as you grow—no long-term commitment needed.

Try Compute now

Métricas de apoyo

Tasa de solicitud (RPS). Se empareja con la longitud de la cola para explicar la presión. La tasa de solicitudes se calcula normalmente como solicitudes por segundo, lo que proporciona una medida cuantitativa del rendimiento del sistema.

Tiempo de prellenado frente a tiempo de decodificación. Dividirlos ayuda a aislar las solicitudes largas de la generación lenta. La solicitud de entrada y la cantidad de fichas de entrada son factores clave que afectan al tiempo de prellenado, ya que las solicitudes más complejas o prolongadas pueden aumentar la duración del procesamiento.

Porcentaje de errores por tipo. OOM, tiempos de espera, 4xx/5xx. Agrupe por ruta y modelo. La complejidad y otros factores pueden influir en las tasas de error, por lo que es importante analizar los tipos de error en su contexto.

Latencia de red. RTT de terminales de Client ↔ por región. Los picos aquí pueden simular la lentitud del servidor.

Relojes y térmicas. La aceleración se muestra como un TPS plano y un TTFT en aumento. Supervisar el uso y el costo de los recursos es importante a la hora de evaluar el margen de ampliación de la memoria de la GPU o las tasas de error, ya que pueden afectar tanto al rendimiento como al presupuesto.

Las métricas de apoyo se rastrean mediante herramientas de monitoreo para garantizar una observabilidad integral y la detección oportuna de los problemas.

Instrumentación que vale la pena

La instrumentación eficaz para la observabilidad de la LLM se basa en herramientas de monitoreo y varios métodos para garantizar un seguimiento y un análisis exhaustivos.

• Temporizadores de clientes. Estampa request_start, first_token y last_token. El seguimiento del tiempo de las respuestas es una parte clave del proceso para evaluar el rendimiento del modelo.
• Espacios de servidores. Capture el tiempo de espera, rellene previamente, decodifique y transmita al instante. Se pueden usar diferentes métodos para capturar los datos relevantes en cada etapa.
• Identificaciones estables. Envía un request_id del cliente al servidor y a los registros.
• Contadores de fichas. Registre los tokens de aviso y los tokens de salida por solicitud. Supervisar el uso de los recursos es importante para comprender la eficiencia del sistema. Omita el texto sin procesar a menos que realmente lo necesite.
• Muestreo. Guarda todos los detalles para ver una parte del tráfico y los acumulativos para el resto. Seleccione el método de muestreo adecuado para equilibrar los detalles y la escalabilidad.

Número mínimo de eventos que registrar por solicitud

• marca de tiempo, ruta, modelo
• request_id, identificador de usuario/sesión (con hash)
• prompt_tokens, output_tokens
• ttft_ms, tps_tokens_por_sec
• longitud de cola al inicio
• gpu_mem_free_mb, cache_hit_rate
• estado (ok/tiempo de espera/oom/error_code)
• uso de recursos (p. ej., uso de CPU/GPU, uso de memoria)
• detalles de la respuesta (p. ej., longitud de la respuesta, estado de la respuesta)

Paneles que responden a preguntas reales

Los paneles se crean utilizando herramientas de supervisión para visualizar las métricas clave de rendimiento de los modelos lingüísticos de gran tamaño (LLM).

«¿Los usuarios se sienten lentos en este momento?»
TTFT p50/p95 a lo largo del tiempo con superposición de tráfico. Realice perforaciones por región y modelo. Los tiempos de respuesta y las respuestas son indicadores clave de la experiencia del usuario.

«¿Podemos llevar más carga?»
TPS p50/p95, longitud de cola y margen de memoria de la GPU. TPS plano y cola en aumento = aún no.

«¿Por qué aumentó la latencia?»
Divida la precarga frente a la decodificación, añada la red RTT. Relleno largo → los mensajes son demasiado grandes. Decodificación larga → tapas o forma de lote.

«¿Estamos desperdiciando fichas?»
Distribución de los tokens de salida en función de sus límites. Gran cola = ajustes sueltos.

Nota: Las métricas del panel deben interpretarse en su contexto, ya que las variaciones en las condiciones de medición o las configuraciones del modelo pueden afectar a los resultados.

Alertas y SLO

Establece umbrales que puedas defender. Ejemplos para empezar:

• TTFT p95 > 1000 ms durante 5 minutos con un RPS constante.
• El TPS p50 cae un 30% con RPS plano.
• Sin GPU < 10% durante 5 minutos.
• Tiempos de espera superiores al 1% o HABITACIÓN > 0.2% más de 10 minutos.

Defina un objetivo de nivel de servicio (SLO), como «TTFT p95 ≤ 800 ms y tasa de error ≤ 1% en 28 días». Un SLO suele formar parte de un acuerdo de nivel de servicio (SLA), que es un contrato formal entre el proveedor de servicios y el usuario en el que se especifican los estándares de rendimiento y calidad. Rastrea el presupuesto de error y página cuando la grabas demasiado rápido.

Utilice herramientas de supervisión y diferentes métodos para realizar un seguimiento de los SLO y las métricas de rendimiento. Para las alertas, seleccione el método que mejor se adapte a sus necesidades operativas.

Nota: Los SLO deben adaptarse a las necesidades del proveedor de servicios y de los usuarios para garantizar que sean significativos y procesables.

Pruebas de carga que realmente deberías ejecutar

Estas son métodos comunes para las pruebas de carga:

• Prueba de rampa. Este método aumenta la simultaneidad paso a paso; a medida que aumentan las solicitudes simultáneas, el TPS total aumenta hasta que se alcanza un punto de saturación, después del cual el rendimiento puede disminuir. Continúa hasta que TTFT p95 supere tu objetivo.
• Prueba de ráfaga. Lanza una ola repentina igual al pico esperado y observa el TPS total bajo carga.
• Indicaciones contradictorias. Combine solicitudes cortas y largas; observe el comportamiento del programador.
• Cancela la tormenta. Detenga muchas transmisiones a mitad de generación; compruebe la limpieza.
• Conmutación por error. Reiniciar un nodo; comprobar la recuperación y los reintentos del cliente.

Nota: Los resultados pueden variar según el método utilizado y la configuración del sistema.

Dificultades comunes

• Persiguiendo la velocidad de una sola solicitud. La concurrencia gana con más frecuencia.
• Salidas sin límite. Las generaciones largas matan de hambre a todos los demás, aumentando el uso de los recursos y aumentando los costos.
• Indicaciones del sistema verbosas. Es costoso y, a menudo, el modelo lo ignora, lo que lleva a un uso innecesario de recursos y a un mayor costo.
• Sin estrategia regional. Las llamadas entre regiones añaden una latencia evitable.
• Contar las fichas de forma incorrecta. Mantenga el tokenizador y el modelo alineados.

Nota: Estas dificultades pueden provocar un aumento de los costos operativos y un uso ineficiente de los recursos si no se administran adecuadamente.

Últimos pensamientos

Centrarse en las métricas esenciales es más eficaz que hacer un seguimiento de demasiadas. Métricas pequeñas y estables superaron una pared de listas. Vea TTFT y TPS, mantenga las colas cortas y deje espacio libre en la memoria. Corrija las instrucciones y las mayúsculas antes de cambiar el hardware.

Nota: La simplicidad es clave: priorice las métricas esenciales para evitar una complejidad innecesaria.

Prueba Compute hoy

¿Prefieres operaciones predecibles? ¿Lanzar un VLLM punto final activado Calcular en Francia o los Emiratos Árabes Unidos, limite los tokens y realice un seguimiento de TTFT/TPS desde el primer día.

PREGUNTAS MÁS FRECUENTES

¿Qué es TTFT?

Tiempo hasta el primer token: la demora antes de que comience la salida del modelo, específicamente el tiempo que lleva crear el primer token nuevo. Los usuarios lo perciben más que cualquier otra métrica.

¿Qué es un buen TPS?

Suficiente para mantener un chat fluido y tener pocas colas para el tráfico. Mida con sus indicaciones. El TPS total (tokens por segundo) refleja el rendimiento de todas las solicitudes y depende del número de solicitudes que se gestionen a la vez. Optimice la forma y los límites de los lotes para aumentarlos.

¿Cuántas métricas necesitamos realmente?

Los cinco principales cubren la mayoría de los problemas: TTFT, TPS, longitud de cola, margen de memoria de la GPU y tasa de aciertos de caché. Estas son las métricas de rendimiento esenciales para supervisar los LLM. Existen varios métodos para rastrear estas métricas, según su infraestructura y sus necesidades de evaluación. Agregue la tasa de solicitudes y los tipos de error para tener en cuenta el contexto.

¿Cómo probamos las alertas sin despertar a las personas?

Utilice tráfico sintético en un entorno de ensayo o aumente temporalmente los umbrales de producción y dispare una ráfaga controlada. Se pueden usar herramientas de monitoreo y varios métodos para probar los sistemas de alertas de manera eficaz.

¿Necesitamos un rastreo distribuido?

Es útil cuando se ejecutan varios nodos o una puerta de enlace. El rastreo distribuido es una de las diversas herramientas y métodos de monitoreo para la observabilidad del sistema. Comience con los ID de solicitud y borre los intervalos; añada el rastreo a medida que vaya creciendo.

¿Qué es TTFT?

El TTFT, o Time to First Token, mide el retraso desde que se envía una solicitud hasta que se recibe el primer token de la salida del modelo. Esta métrica incluye el tiempo de prellenado, durante el cual el mecanismo de atención procesa la entrada y crea la caché de valores clave necesaria para crear el primer token. Es una métrica fundamental para la percepción de la capacidad de respuesta.

¿Cómo medir el TTFT?

El TTFT se calcula midiendo el tiempo que lleva crear el primer token nuevo. Esto implica registrar la marca de tiempo cuando se envía una solicitud y la marca de tiempo cuando llega el primer token de salida, y luego calcular la diferencia.

¿Qué es la métrica TPOT?

El TPOT (tiempo por token de salida) es el tiempo promedio que se tarda en generar cada token después del primero, lo que refleja la velocidad de generación del token en estado estacionario. En concreto, el TPOT mide la latencia entre los tokens entre los tokens consecutivos producidos por el modelo. Un cálculo eficiente de la atención puede ayudar a reducir esta latencia entre los tokens, lo que mejora la eficiencia general de la decodificación.

¿Qué es el TPS en LLM?

TPS son las siglas de Tokens Per Second e indica cuántos tokens puede generar un modelo por segundo durante la inferencia, midiendo el rendimiento. El TPS está estrechamente relacionado con las solicitudes por segundo, ya que ambas métricas ayudan a evaluar el rendimiento del sistema. El TPS total mide el rendimiento general de todas las solicitudes que se gestionan simultáneamente, lo que refleja la capacidad del sistema para generar señales de salida por segundo para todas las solicitudes combinadas.

¿Qué es un token por segundo?

Un token por segundo es una unidad que mide la cantidad de tokens producidos por el modelo cada segundo durante la generación de la salida. Esta métrica se calcula dividiendo la cantidad de tokens generados por el tiempo transcurrido.

¿Cuántos tokens por segundo tiene ChatGPT?

Por lo general, ChatGPT genera tokens a una velocidad de entre 20 y 30 tokens por segundo, según la carga del servidor y la versión del modelo.

Nota: El TPS puede variar según las métricas de rendimiento, como la latencia y el rendimiento, así como las condiciones del sistema.

¿Cuántas palabras son 1000 fichas?

Aproximadamente 750 palabras corresponden a 1000 fichas, ya que una ficha tiene un promedio de alrededor de 0,75 palabras en inglés. La proporción entre palabras y fichas se calcula en función de la longitud media de las palabras y del proceso de tokenización.

¿Son buenas 7 fichas por segundo?

Siete tokens por segundo son relativamente lentos para muchas aplicaciones en tiempo real, pero pueden ser aceptables para generaciones más largas y menos urgentes.

¿Cómo medir la inferencia?

La inferencia se mide mediante diferentes métodos, que incluyen el seguimiento de las métricas de rendimiento, como la latencia (TTFT, tiempo total de generación) y el rendimiento (TPS).

¿Cuáles son los 5 ejemplos de una inferencia?

Los ejemplos incluyen la finalización de textos, la respuesta a preguntas, la traducción, el resumen y la generación de código. Todos estos son ejemplos de respuestas generadas como resultado del modelo.

¿Cuáles son los 5 pasos principales de la inferencia?

El proceso de inferencia comienza con la solicitud de entrada, que se tokeniza en fichas de entrada. El mecanismo de atención procesa estos tokens de entrada durante el tiempo de prellenado, creando la caché de valores clave necesaria para que el modelo genere una respuesta. Esta fase de prellenado es crucial para crear el primer token nuevo, que marca el inicio de la generación del token de salida. Luego, el modelo continúa decodificando y generando los tokens de salida hasta que se complete la respuesta.

¿Qué significa inferencia en los tribunales?

En los tribunales, la inferencia se refiere a una conclusión a la que se llega basándose en pruebas y razonamientos en lugar de declaraciones explícitas.

¿Qué quieres decir con observabilidad?

La observabilidad es la capacidad de comprender el estado interno de un sistema mediante el análisis de sus resultados, como registros, métricas y rastreos, utilizando herramientas de monitoreo y varios métodos para evaluar e interpretar el proceso y los resultados.

¿Qué es la observabilidad frente a la monitorización?

La supervisión utiliza métricas y alertas predefinidas y, a menudo, se basa en herramientas de supervisión y métodos específicos para realizar un seguimiento del estado del sistema. Tanto la observabilidad como el monitoreo utilizan herramientas y métodos de monitoreo, pero la observabilidad permite el análisis exploratorio sin conocimientos previos, lo que ofrece una comprensión más profunda del proceso y proporciona información más profunda.

¿Cuáles son los tres pilares de la observabilidad?

Las métricas, los registros y los rastreos son los tres pilares que proporcionan una visibilidad integral del sistema, respaldada por varias herramientas y métodos de monitoreo.

¿Qué es la observabilidad en DevOps?

En DevOps, la observabilidad ayuda a los equipos a detectar, diagnosticar y resolver problemas de forma proactiva mediante la recopilación y el análisis de datos de telemetría. La observabilidad se basa en herramientas de monitoreo y varios métodos para analizar el proceso y garantizar la detección y resolución efectivas de los problemas.

¿Qué es una caché KV?

Una caché KV (clave-valor) almacena pares clave-valor intermedios durante la inferencia del modelo para acelerar la generación de fichas y permite un cálculo eficiente de la atención durante la inferencia.

¿Qué es la caché GPU KV?

La caché KV de la GPU se refiere al almacenamiento de pares clave-valor en la memoria de la GPU para optimizar los cálculos de atención durante la inferencia de LLM, lo que permite un cálculo de atención eficiente.

¿Qué es la caché KV en LLM?

La caché KV contiene claves de atención y valores previamente calculados para evitar cálculos redundantes al generar nuevos tokens. Esta caché es esencial para un cálculo eficiente de la atención, ya que permite un procesamiento más rápido y óptimo durante la generación de los tokens.

¿Qué es la caché de almacenamiento de valores clave?

Una caché de almacenamiento de valores clave es una estructura de datos que almacena datos indexados mediante claves únicas para una recuperación rápida.

¿Qué quieres decir con rendimiento?

El rendimiento es una métrica clave de rendimiento que representa la cantidad de trabajo realizado o la producción producida por un sistema en un tiempo determinado, como los tokens generados por segundo. Por lo general, el rendimiento se calcula dividiendo la producción entre el tiempo y se puede medir con diferentes métodos según el enfoque de evaluación.

¿Qué es el rendimiento frente al ancho de banda?

El rendimiento mide los datos procesados reales a lo largo del tiempo, mientras que el ancho de banda es la velocidad máxima de transferencia de datos posible. Tanto el rendimiento como el ancho de banda son métricas de rendimiento importantes a la hora de evaluar la eficiencia del sistema.

¿Qué es un ejemplo de rendimiento?

El rendimiento es una métrica de rendimiento que se calcula en fichas por segundo. Por ejemplo, la generación de 100 tokens por segundo durante la inferencia del LLM demuestra el rendimiento.

¿Cuál es el sinónimo de rendimiento?

Velocidad de salida o velocidad de procesamiento.

¿Es buena la latencia del 95%?

Una latencia del percentil 95 inferior a 500 milisegundos generalmente se considera buena para las aplicaciones en tiempo real.

¿Qué es la latencia de cola de p95?

La latencia final de P95 es el valor de latencia por debajo del cual se completa el 95% de las solicitudes, lo que indica el peor rendimiento para la mayoría de los usuarios.

¿Qué es la latencia P50?

La latencia P50 es la latencia media, lo que significa que la mitad de las solicitudes se completan más rápido y la otra mitad más despacio que este valor.

¿Es el p95 un promedio?

No, p95 es una métrica de percentil que representa el valor por debajo del cual cae el 95% de las observaciones, no un promedio. Tanto el p95 como el promedio son tipos de métricas de rendimiento que se utilizan para evaluar y comparar el rendimiento del sistema.

¿Qué es el concepto de presupuesto de error?

Un presupuesto de errores define el umbral permitido de errores o brechas de latencia dentro de un período de servicio para equilibrar la confiabilidad y la innovación. Los presupuestos de errores suelen formar parte de un acuerdo de nivel de servicio (SLA) entre el proveedor de servicios y el usuario, y se basan en métricas de rendimiento, como la latencia y el rendimiento.

¿Cómo se calcula el presupuesto de error?

El presupuesto de errores se calcula mediante las siguientes métricas de rendimiento: presupuesto de errores = (1 - objetivo de SLO) × el total de solicitudes o el período de tiempo.

¿Cuál es la diferencia entre el presupuesto de error y el SLO?

El SLO (objetivo de nivel de servicio) establece el objetivo de rendimiento como parte de un acuerdo de nivel de servicio entre el proveedor de servicios y el usuario, y se basa en las métricas de rendimiento; el presupuesto de errores cuantifica las desviaciones permitidas con respecto a ese objetivo.

¿Qué es un error presupuestario?

Se produce un error presupuestario cuando se supera el presupuesto de error, lo que indica problemas de confiabilidad del servicio y posibles problemas con las métricas de rendimiento, como la latencia, el rendimiento u otros resultados de la evaluación comparativa.

¿Qué es una memoria de GPU?

La memoria de la GPU es la RAM dedicada de una unidad de procesamiento de gráficos que se utiliza para almacenar datos y cálculos durante el procesamiento. Es un aspecto clave del uso de los recursos, ya que la supervisión de la memoria de la GPU ayuda a realizar un seguimiento de la utilización general de los recursos y las métricas de rendimiento en las soluciones de observabilidad de LLM.

¿Cuánta memoria de GPU necesito?

La memoria GPU necesaria depende del tamaño del modelo, el tamaño del lote, la precisión y el uso de los recursos y de varios factores, como el rendimiento, la latencia y la calidad de respuesta; los modelos y lotes más grandes requieren más memoria.

¿Qué es el uso de la memoria de la GPU?

El uso de la memoria de la GPU se refiere a la asignación de la RAM de la GPU para los parámetros del modelo, los datos intermedios y el cálculo durante la inferencia. Esta es una forma de uso de los recursos, ya que el seguimiento del uso de la memoria de la GPU es esencial para comprender el rendimiento y la eficiencia generales del sistema.

¿Cómo compruebo la memoria de la GPU?

Puedes comprobar el uso de la memoria de la GPU con herramientas como nvidia-smi en las GPU de NVIDIA, software de supervisión del sistema o herramientas de supervisión especializadas diseñadas para una observabilidad avanzada. Las herramientas de supervisión pueden ayudarte a controlar el uso de la memoria de la GPU, avisarte de los problemas y proporcionar métricas detalladas para una administración eficaz del sistema.

‍