Application Real-Time Monitoring Service:Diagnóstico de aplicaciones vLLM y SGLang con análisis de concurrencia

Por qué necesita una vista de concurrencia

La inference de modelos de lenguaje grandes (LLM) suele tener su cuello de botella en el ancho de banda de memoria y no en el cómputo. Para un LLM, generar cada token exige mover decenas de GB de pesos del modelo desde la memoria de la GPU hacia las unidades de cómputo. La multiplicación de matrices de una sola solicitud usa apenas una fracción mínima de ese cómputo, por lo que la GPU pasa la mayor parte del tiempo esperando datos. El procesamiento por lotes permite que varias solicitudes compartan una misma lectura de pesos y distribuye el costo de acceso a la memoria. Esta técnica suele multiplicar varias veces el throughput de una sola GPU.

El procesamiento por lotes estático no es adecuado para los LLM:

• Espacios desperdiciados: las longitudes de salida varían mucho dentro de un lote. Una solicitud corta que ya terminó de generarse queda inactiva hasta que finaliza la solicitud más larga, y su espacio de cómputo se desperdicia.

• Mayor tiempo hasta el primer token: las solicitudes recién llegadas deben esperar en la cola hasta que se libere todo el lote, lo cual prolonga el tiempo hasta el primer token (TTFT).

  Continuous Batching reduce la unidad de programación de un lote completo a una sola iteración. Después de cada paso de decodificación, el motor revisa la cola, elimina de inmediato las solicitudes terminadas, libera su caché KV y llena los espacios disponibles con las solicitudes en espera. De este modo, el lote se mantiene saturado y la GPU deja de esperar a las solicitudes de cola larga, lo que mejora tanto el throughput como la latencia de cola. Por esta razón, Continuous Batching es la directiva de programación predeterminada en motores de inference modernos como vLLM y SGLang.

La contraparte es que la solución de problemas de una solicitud lenta no puede limitarse a revisar sus propias duraciones por etapa. También necesita conocer las demás solicitudes que compartieron su lote en ese mismo instante: la longitud de sus prompts, si están en Prefill y si la cantidad de solicitudes concurrentes ya alcanzó el límite superior. Engine Concurrency Analysis traza esta información en una sola línea de tiempo y convierte el entorno de lote de una solicitud en algo directamente observable.

Requisitos previos

• El agente de Python de ARMS está instalado según se describe en Observability for vLLM and SGLang.

• El motor de inference se inicia mediante el agente y reporta datos de trace.

Límites

• Las duraciones por etapa son obligatorias: los métodos de diagnóstico de este tema dependen de las duraciones de las etapas Wait, Prefill y Decode de una solicitud.

• Spans secundarios de etapas en vLLM: en vLLM, los spans secundarios de las etapas wait, prefill y decode solo se generan en motores V1 con una granularidad de recopilación de 1 o superior. El valor predeterminado del agente es 1. Cuando la granularidad de recopilación se establece en 0, solo se genera el span llm_request de nivel de solicitud. Para consultar el valor predeterminado y las condiciones efectivas de cada interruptor de recopilación, consulte Configuración de recopilación para vLLM y SGLang.

Abrir Engine Concurrency Analysis

La vista de análisis de concurrencia se muestra por aplicación de servicio de inference. Abra primero la aplicación de destino, cambie a la pestaña Engine Concurrency Analysis y especifique el intervalo de tiempo que desea consultar.

1. Inicie sesión en la consola de Cloud Monitor 2.0 y seleccione el espacio de trabajo de destino. En el panel de navegación izquierdo, elija All Features > Reasoning Services Observability y haga clic en la aplicación de servicio de inference correspondiente.

2. En la barra de navegación superior, haga clic en Engine Concurrency Analysis.

3. En el selector de intervalos de tiempo ubicado en la esquina superior derecha de la página, establezca el intervalo que desea consultar. La vista mostrará las instantáneas de ejecución de todas las solicitudes del motor dentro de ese periodo.

Lectura de la vista de análisis de concurrencia

La vista de análisis de concurrencia es una instantánea de ejecución de todas las solicitudes del motor de inference durante un periodo determinado. El eje horizontal representa la línea de tiempo y cada bloque corresponde al intervalo de ejecución de una solicitud de inference dentro del motor. Elija un momento en la línea de tiempo y trace una línea vertical: cada bloque que cruce esa línea es una solicitud de inference que se estaba ejecutando en ese instante. Pase el cursor sobre una solicitud para consultar la duración de cada una de sus etapas, incluidas Wait, Prefill y Decode.

La cantidad de bloques concurrentes en la vista está limitada por el número máximo de solicitudes concurrentes del motor. Por ejemplo, cuando el número máximo de solicitudes concurrentes se establece en 8, se ejecutan como máximo 8 solicitudes al mismo tiempo, por lo que la vista muestra un máximo de 8 bloques. Para comprobar si el motor está completamente cargado en un momento dado, cuente los bloques que cruza la línea vertical.

Engine Concurrency Analysis admite tanto despliegues desagregados PD (Prefill/Decode) como despliegues no desagregados PD. La distribución de la vista de análisis de concurrencia difiere entre ambos tipos de despliegue:

• Despliegue no desagregado PD: todas las solicitudes del motor se trazan en una sola línea de tiempo.

• Despliegue desagregado PD: los workers de Prefill y los workers de Decode se muestran en paneles separados. Las dos etapas de una misma solicitud se vinculan mediante una línea discontinua. Siga esa línea para ubicar la solicitud de Prefill correspondiente desde el lado de Decode y evalúe por separado la duración en la cola y la duración de ejecución de cada lado.

Diagnosticar un aumento de TPOT causado por un Prefill grande que bloquea Decode

Una solicitud de Prefill grande bloquea las solicitudes de Decode del mismo lote. La duración de Decode de ese lote aumenta de forma notable respecto a su comportamiento previo a la llegada de dicha solicitud, lo cual se refleja en las métricas como un incremento en el tiempo por token de salida (TPOT). Ubique el origen del bloqueo en la vista de análisis de concurrencia de la siguiente manera:

1. Localice la ventana de tiempo en la que aumenta la duración de Decode y alinee las etapas de Decode extendidas con las demás solicitudes de esa misma ventana.

2. Compare los recuentos de tokens de prompt de estas solicitudes. Si el recuento de una solicitud de Prefill es notablemente mayor que el de las demás, esa solicitud de Prefill grande es el origen principal del bloqueo.

   En un despliegue desagregado PD, siga la línea discontinua desde el lado de Decode para ubicar la solicitud de Prefill que corresponde a cada solicitud de Decode bloqueada y compare después los recuentos de tokens de prompt.

Ejemplo: en un despliegue no desagregado PD con un máximo de 8 solicitudes concurrentes, una solicitud de Prefill presenta un recuento de tokens de prompt notablemente mayor que el de las demás solicitudes del mismo periodo. La duración de las etapas de Decode que se superponen con esta solicitud de Prefill aumenta, y dicho incremento comienza justo cuando entra al lote.

Diagnosticar la acumulación de solicitudes en cola por un pico de concurrencia

Si la etapa Wait del trace de una solicitud es inusualmente larga, revise la vista de análisis de concurrencia del mismo periodo:

1. Localice la ventana de tiempo donde la etapa Wait es inusualmente larga y compare la cantidad de solicitudes concurrentes de esa ventana con la de periodos anteriores.

2. Si la cantidad de solicitudes concurrentes aumenta de forma repentina y al mismo tiempo aparecen etapas Wait largas, un pico de tráfico superó la capacidad de procesamiento del motor de inference en ese momento y las nuevas solicitudes entraron a la cola.

3. Use el número máximo de solicitudes concurrentes para acotar la causa. Si la cantidad de bloques concurrentes se mantiene en el límite durante mucho tiempo, la capacidad del motor es insuficiente. Si aumenta de forma repentina solo dentro de una ventana de tiempo, la causa es un pico de tráfico.

   En un despliegue desagregado PD, evalúe por separado la duración en la cola del lado de Prefill y del lado de Decode.