¿Por qué aumenta la latencia del primer token de un LLM local después de que el servidor permanece inactivo?

La latencia del primer token suele aumentar después de un periodo de inactividad porque la siguiente solicitud debe reconstruir el estado del modelo, la memoria, el acelerador y la energía que las solicitudes en caliente reutilizan.

Un servidor de IA doméstico puede responder rápidamente a solicitudes repetidas y luego parecer lento cuando llega la primera solicitud a la mañana siguiente. Es posible que el modelo siga existiendo en el disco, pero sus páginas, la asignación de la GPU, los kernels y el contexto de ejecución pueden haber dejado de estar activos. La velocidad de almacenamiento, la presión de memoria, la expulsión del entorno de ejecución, la gestión de energía del dispositivo y la longitud del prompt determinan cuánto retraso reaparece.

El tiempo de inactividad elimina varios tipos distintos de estado en caliente

Una solicitud en caliente puede reutilizar pesos que ya residen en la RAM o la VRAM, páginas del sistema de archivos conservadas por el sistema operativo, bibliotecas de aceleradores inicializadas, kernels compilados, grupos de memoria y un proceso de trabajo del modelo activo. La limpieza durante la inactividad puede eliminar solo una capa o desmantelar todo el proceso.

la carga de puntos de control en varios niveles reduce el inicio de modelos serverless al mantener los puntos de control cerca de los aceleradores, cargarlos mediante varios niveles de almacenamiento y programar las solicitudes donde el estado del modelo ya es local. Su diseño muestra que la latencia en frío es una cadena de transferencias y pasos de inicialización, no una única cifra de lectura del disco.

El retraso observable depende de qué capa se enfrió. Un proceso que permaneció activo quizá solo necesite que aumente la frecuencia del dispositivo, mientras que un modelo expulsado debe leer los pesos, asignar memoria del dispositivo, reconstruir las estructuras del entorno de ejecución y después procesar el prompt antes de emitir un token.

La carga del modelo y el prellenado se acumulan antes de que aparezca cualquier token

El tiempo hasta el primer token incluye la espera en cola, la disponibilidad de los pesos, la inicialización del entorno de ejecución, la tokenización y el prellenado de toda la entrada. Una alta velocidad de decodificación no puede ocultar estas etapas porque no existe ningún token de salida hasta que el prellenado produce el primer estado de decodificación.

la reutilización de memoria de GPU conserva los parámetros en la memoria de GPU no utilizada y emplea una programación basada en la afinidad para reducir las transferencias repetidas. Las mejoras notificadas en los arranques en frío muestran por qué conservar una residencia parcial puede ser importante incluso cuando un servicio no puede mantener todos los modelos completamente cargados.

Por tanto, un prompt de sistema largo puede seguir siendo lento después de que los pesos se hayan calentado, mientras que un prompt corto puede seguir bloqueándose durante la carga en frío del modelo. Separar el tiempo de carga, la inicialización, el prellenado y la primera decodificación evita que un único valor promedio de TTFT oculte el componente realmente frío.

El ahorro de energía suele ser una capa menor, pero medible

Las CPU, GPU, unidades NVMe y enlaces PCIe pueden entrar en estados de menor consumo durante la inactividad. El primer impulso debe aumentar las frecuencias y restaurar las rutas activas, lo que añade una breve fase de aumento antes de que comience el procesamiento sostenido; una suspensión agresiva del host puede añadir mucho más al suspender servicios o discos.

la superposición de las etapas del arranque en frío superpone la carga del modelo, la comunicación y el procesamiento para los arranques en frío de LLM en el borde. El trabajo demuestra que ocultar una etapa de inicio requiere coordinarla con las demás, especialmente cuando los pesos y el procesamiento están distribuidos entre dispositivos con recursos limitados.

El error está en atribuir cada primera respuesta lenta al estado de energía. Si el retraso se mide en muchos segundos, la expulsión del modelo, las lecturas de almacenamiento, el inicio del contenedor o el prellenado del prompt suelen dominar una transición de frecuencia de escala milisegundos. Diagnostica la línea de tiempo en lugar de desactivar de forma predeterminada todo el ahorro de energía.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separa el arranque en frío del coste de un prompt en frío

Envía un prompt corto fijo después de 0, 1, 10, 60 y 480 minutos de inactividad. Registra la duración del proceso, la residencia del modelo, el uso de RAM y VRAM, los bytes leídos, las frecuencias del dispositivo, el tiempo en cola, la tokenización, el prellenado, la primera decodificación y el TTFT total para cada intervalo.

Compara la capa de almacenamiento con el almacenamiento para el arranque en frío del modelo y repite la prueba fijando el proceso de trabajo, calentando únicamente la caché del sistema de archivos, manteniendo caliente solo la RAM del host y cambiando la longitud del prompt. Cada ejecución debe modificar una sola capa de estado en lugar de combinar todas las optimizaciones.

Considera que el servidor está caliente únicamente cuando intervalos de inactividad repetidos mantienen el TTFT requerido sin dejar sin recursos a otros servicios. Si fijar el modelo provoca presión de memoria o bloquea cargas de trabajo de mayor prioridad, acepta un arranque en frío acotado y hazlo visible en lugar de ocultar la compensación.