¿Por qué las respuestas de los LLM locales se vuelven más cortas bajo carga simultánea?

Las respuestas de los LLM locales se vuelven más cortas bajo carga cuando la capa de servicio intercambia presupuesto de generación por concurrencia mediante límites, plazos, desalojo o solicitudes fallidas.

El modelo no decide inherentemente ser conciso porque haya llegado otro usuario. Con un prompt y un estado de muestreo fijos, la concurrencia debería cambiar principalmente los tiempos de espera en cola y de generación de tokens. Las respuestas más cortas indican que el entorno de ejecución, la puerta de enlace, el cliente o el administrador de memoria modificaron una condición de detención efectiva, cancelaron el trabajo o devolvieron un flujo parcial después de que la presión superara un umbral.

La concurrencia amplía la memoria KV y activa límites del servicio

Cada secuencia activa mantiene bloques de caché KV que crecen con el contexto retenido y los tokens generados. Cuando varias solicitudes comparten un acelerador, el entorno de ejecución puede reducir la salida máxima, rechazar la admisión, desalojar una secuencia o intercambiar bloques para mantener el lote dentro de los límites de memoria.

Un diseño de servicio basado en la asignación paginada de la caché KV utiliza bloques KV paginados para reducir la fragmentación y permitir una mayor concurrencia. Su mecanismo mejora la capacidad, pero también deja claro que cada secuencia activa consume una asignación de memoria creciente hasta completarse o ser desalojada.

Una puerta de enlace puede imponer un presupuesto de tokens independiente por solicitud o global. Si ese presupuesto se deriva de la capacidad disponible, la prioridad o la profundidad de la cola, los prompts idénticos reciben una salida máxima diferente aunque los pesos del modelo y los parámetros de muestreo parezcan no haber cambiado.

Los plazos y el desalojo pueden devolver una respuesta parcial con apariencia válida

Los sistemas interactivos suelen imponer plazos de tiempo real, tiempos de espera por inactividad del flujo o cancelaciones del cliente. La menor velocidad de entrega entre tokens bajo carga alcanza esos límites antes dentro de la respuesta semántica, y algunas API devuelven los tokens ya emitidos en lugar de mostrar un error evidente.

El método de prefill fragmentado divide el procesamiento del prompt en fragmentos más pequeños para evitar que los prefills largos bloqueen la decodificación. Este trabajo demuestra cómo los cambios de planificación afectan al tiempo hasta el primer token y a la latencia entre tokens bajo una presión de solicitudes mixta. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.

El desalojo puede conservar una solicitud para reanudarla más tarde, reiniciarla o cancelarla, según el motor. Si el cliente se desconecta durante la pausa, el servidor puede registrar una cancelación mientras la interfaz muestra un prefijo gramatical pero incompleto como si fuera una respuesta terminada.

El muestreo por sí solo no debería correlacionarse de forma fiable con la carga

La decodificación estocástica produce naturalmente longitudes variables cuando difieren la temperatura y la semilla aleatoria. Esa variación puede coincidir con la carga en muestras pequeñas, pero la concurrencia no tiene ninguna señal semántica directa a menos que un estado compartido, una política adaptativa o un defecto de software cambie la ruta de decodificación.

La investigación sobre la planificación consciente de los SLO modela el enrutamiento y la planificación mientras protege los objetivos de tiempo entre tokens. La separación entre rendimiento, TTFT y plazos de decodificación muestra por qué la política de capacidad debe medirse por separado de la calidad de salida del modelo. El resultado intermedio debe seguir siendo inspeccionable antes de continuar con la automatización.

El límite del diagnóstico consiste en culpar al planificador antes de comprobar los metadatos de detención. Los tokens de fin de secuencia, los límites de longitud explícitos, las cancelaciones del cliente, los plazos del servidor, los errores de falta de memoria y las desconexiones del transporte son causas diferentes. Solo los cambios de longitud repetidos y controlados, acompañados de motivos de detención coincidentes, respaldan la existencia de un mecanismo relacionado con la carga.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Compara la longitud y el motivo de detención con niveles de concurrencia fijos

Reproduce prompts y semillas fijos con una, dos, cuatro y ocho solicitudes simultáneas. Registra los tokens máximos solicitados, los tokens de salida reales, el motivo de finalización, el tiempo en cola, el TTFT, la latencia entre tokens, el plazo de tiempo real, la desconexión del cliente, el número de desalojos, los bytes de KV, la VRAM libre y el error del servidor.

Relaciona el comportamiento de la memoria con los límites de carga de trabajo simultánea y repite las pruebas sin tiempos de espera de la puerta de enlace y con un límite de admisión fijo. Conserva los prompts, las plantillas, el muestreo y el código del cliente para que el único cambio previsto sea la concurrencia. Ese límite debe medirse por separado en condiciones operativas realistas.

Considera la salida más corta un defecto del servicio cuando la tasa de finalización o la cobertura semántica disminuyan antes de alcanzar el presupuesto anunciado. Si solo aumenta la latencia mientras los motivos de finalización siguen siendo EOS, recopila más pruebas con semillas fijas; si predominan los tiempos de espera o los límites, expón y dimensiona esas políticas explícitamente.