¿Qué causa los picos de latencia del primer token después de que un servicio de IA local cambia de modelo?

La latencia del primer token suele dispararse después de cambiar de modelo porque el modelo recién seleccionado debe reconstruir el estado residente antes de poder procesar el prompt.

Un servidor de IA doméstico puede responder rápidamente con un modelo activo, cambiar a un modelo de visión o de programación y, entonces, hacer una pausa antes del primer token. El retraso puede incluir la lectura de pesos, la descuantización, la transferencia al dispositivo, la compilación de kernels, la captura de gráficos CUDA, la asignación de caché y el prellenado del prompt. La etapa dominante depende del almacenamiento, la memoria disponible del acelerador, la política del entorno de ejecución y de si el modelo anterior se desalojó por completo.

La carga en frío de los pesos es la primera familia de causas

Si el siguiente modelo no está en la RAM o la VRAM, el servidor debe leer uno o más fragmentos del checkpoint, validarlos o mapearlos, construir los tensores y transferir los pesos utilizables al dispositivo de ejecución. Un archivo más grande o una ruta NAS más lenta alarga la pausa antes de que pueda comenzar la inferencia.

Las mediciones de la latencia de activación en frío de LLM muestran que el inicio puede dominar el TTFT cuando el estado del modelo está frío. Este síntoma aparece como lecturas intensivas del almacenamiento y tiempo del cargador del modelo antes de que se ejecute cualquier kernel de prellenado del prompt. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.

Si cambiar entre dos modelos que permanecen residentes produce el mismo pico, la carga de pesos no es la explicación completa. La observación determinante es si los bytes leídos y el estado de los modelos residentes cambian con la solicitud lenta.

La inicialización del entorno de ejecución crea una segunda ruta en frío

Un modelo cargado aún puede estar operativo pero frío. El entorno de ejecución puede inicializar un contexto del dispositivo, seleccionar kernels, compilar formas, capturar gráficos, asignar bloques KV o crear cachés del tokenizador y de las plantillas de prompt en la primera solicitud después de la activación.

Un análisis de ingeniería sobre la transmisión y el calentamiento de modelos separa la transmisión desde el almacenamiento de la inicialización y el calentamiento. El patrón de esta etapa consiste en una E/S moderada del checkpoint seguida de compilación, asignación o actividad del acelerador antes del procesamiento del prompt. El resultado intermedio debe seguir siendo inspeccionable antes de continuar con la automatización.

La forma del modelo, el backend de cuantización, el límite de contexto, los perfiles de lote y el estado del controlador determinan qué artefactos pueden reutilizarse. Volver a cambiar rápidamente puede ser veloz si las cachés sobrevivieron, mientras que un desalojo por presión de memoria vuelve a enfriar la misma ruta.

La espera en cola y el prellenado pueden parecer un retraso de carga del modelo

La solicitud de cambio puede esperar detrás del apagado del modelo, la recuperación de memoria, otro usuario o un prompt largo. Una vez admitida, la fase de prellenado procesa todos los tokens de entrada antes de la decodificación, por lo que los historiales más extensos aumentan el TTFT sin cambiar el tiempo de carga del modelo. Ese límite debe medirse por separado en condiciones operativas realistas.

El diseño de servicio con admisión de caché KV paginada explica cómo las secuencias activas consumen bloques KV paginados y cómo la admisión depende de la capacidad disponible de la caché. Por tanto, un cambio que modifique las reservas de caché puede alterar el tiempo en cola independientemente del tamaño del checkpoint.

El límite del fallo es un modelo residente y activo, con una inicialización estable y un pico de latencia que sigue la longitud del prompt o la concurrencia. En ese caso, el cambio de modelo solo está correlacionado; la causa directa es el prellenado o la planificación.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Divide el TTFT en carga, calentamiento, espera en cola y prellenado

Reproduce prompts fijos mientras registras el desalojo del modelo, los bytes del checkpoint, el rendimiento del almacenamiento, la transferencia del host al dispositivo, la creación del contexto del dispositivo, la compilación de kernels, la captura de gráficos, la asignación de KV, la espera en cola, la duración del prellenado y el primer paso de decodificación en un único reloj monotónico. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.

Compara el registro con el enrutamiento de modelos según la memoria y, después, prueba por separado el cambio en frío, el cambio inmediato de vuelta, el enrutamiento con dos modelos residentes, un prompt corto y un prompt largo. Mantén el muestreo, el cliente y la concurrencia para que solo cambie el estado previsto. Esta dependencia debe seguir siendo explícita en la interfaz final.

Asigna el pico a la primera etapa que se expanda. Mantén los pesos residentes cuando domine la carga, conserva los artefactos compatibles cuando domine la inicialización y cambia la política de admisión o de contexto cuando la espera en cola o el prellenado -no el cambio en sí- determinen el TTFT.