¿Por qué la expulsión de modelos provoca picos de latencia en los servidores de IA domésticos?

La expulsión del modelo crea un pico de latencia porque el modelo que manejó la solicitud anterior ya no está residente en memoria rápida. La siguiente solicitud debe recargar los pesos, restaurar el estado de tiempo de ejecución y procesar el prompt antes de que pueda comenzar la generación normal de tokens. Una vez que el modelo está caliente de nuevo, las solicitudes posteriores pueden sentirse rápidas.

Si tu asistente de IA doméstico responde rápido durante una conversación activa pero se pausa después de estar inactivo, cambiar de modelo o compartir la GPU con otro servicio, el modelo en sí puede no ser lento. La pregunta útil es si el tiempo se está gastando en cargar el modelo o en generar la respuesta. Esa distinción determina qué cambiar.

La expulsión del modelo cambia la primera solicitud, no todas las solicitudes.

Un tiempo de ejecución de inferencia local mantiene los pesos del modelo en la memoria GPU, memoria unificada o RAM del sistema mientras el modelo está activo. La expulsión ocurre cuando el tiempo de ejecución elimina parte o todo ese estado residente. Puede hacerlo después de un tiempo de inactividad, cuando otro modelo necesita la misma memoria o cuando el servicio se reinicia.

Una solicitud caliente puede pasar directamente al procesamiento del prompt porque los pesos ya están disponibles para el motor de inferencia. Una solicitud después de la expulsión sigue un camino más largo: localizar los archivos del modelo, leer los pesos, colocarlos en el nivel de memoria requerido, inicializar la ruta de ejecución y luego evaluar el prompt.

Por eso la expulsión suele aparecer como una pausa aislada en lugar de una reducción permanente en tokens por segundo. La primera respuesta después de un período de inactividad es lenta, mientras que la segunda solicitud al mismo modelo es normal. Si cada solicitud sigue siendo lenta, el cuello de botella probablemente sea la generación, descarga de CPU, ancho de banda de memoria, colas o límites térmicos.

La latencia de IA es toda la cadena, no solo la velocidad de generación.

Los usuarios a menudo describen toda la espera como “latencia de inferencia”, pero una solicitud de IA local tiene varias etapas. Puede esperar en una cola, cargar un modelo, procesar el prompt de entrada y generar tokens de salida. Por lo tanto, un servidor puede reportar una velocidad de generación saludable y aún así sentirse poco receptivo antes de que aparezca el primer token.

La expulsión del modelo principalmente aumenta el tiempo hasta el primer token. No necesariamente cambia la velocidad de los tokens que siguen. Por eso, un benchmark solo de tokens por segundo puede no detectar el problema: el benchmark puede comenzar después de que la carga ya haya terminado o puede reutilizar un modelo que se ha mantenido caliente.

Cuando el tiempo de ejecución expone campos de temporización, compárelos en lugar de confiar en la intuición. Los tiempos separados de carga del modelo y evaluación muestran si el retraso ocurre antes del procesamiento del prompt o durante este. Un componente de carga grande en la primera solicitud y uno pequeño en la siguiente es una fuerte evidencia de un modelo frío en lugar de una decodificación lenta.

Por qué los servidores de IA domésticos expulsan modelos

La causa más simple es una política de inactividad. Un entorno de ejecución libera modelos inactivos para que la memoria pueda volver al sistema operativo u otras aplicaciones. En Ollama, los modelos permanecen cargados por defecto durante cinco minutos, mientras que las configuraciones de mantener activo pueden extender la residencia. Una pausa que sigue consistentemente el mismo intervalo de inactividad apunta a la política más que a un fallo de hardware.

La presión de memoria crea un patrón menos predecible. Dos modelos de lenguaje, un modelo de incrustación, un generador de imágenes o un servicio de video pueden competir por RAM o VRAM. Los sistemas que comparten un servidor entre Plex y IA local son especialmente vulnerables porque una transcodificación o trabajo en segundo plano puede desplazar un modelo aunque el servicio de IA en sí no haya estado inactivo.

El cambio de modelo puede causar la misma inestabilidad. Si solo un modelo grande cabe cómodamente, solicitar el Modelo B puede forzar la expulsión del Modelo A. Volver al Modelo A entonces desencadena otra carga. El servidor parece aleatoriamente lento, pero los picos en realidad siguen el orden en que se usan los modelos.

Los reinicios son otro límite. Una actualización del contenedor, un fallo del servicio, un reinicio del host o una detención manual borran el estado residente sin importar el valor de mantener activo. La primera solicitud después de ese evento es un inicio en frío por diseño. Tratarlo como un error de expulsión puede llevar a configuraciones agresivas que consumen memoria sin mejorar la operación normal.

Dónde se acumula el retraso por expulsión

El primer costo es mover el modelo. Cargar los pesos del modelo en la memoria GPU normalmente requiere leerlos desde el almacenamiento hacia la memoria CPU antes de transferirlos a la GPU. Archivos más grandes y rutas de almacenamiento más lentas extienden esa parte de la espera.

La ruta de datos importa tanto como la etiqueta del disco. Los pesos pueden cruzar el almacenamiento, la memoria del sistema y una ruta PCIe o de memoria unificada antes de que comience la inferencia. Durante esa transferencia, el ancho de banda limitado de la memoria puede aumentar la latencia de la IA, especialmente cuando otra carga de trabajo está moviendo grandes cantidades de datos al mismo tiempo.

Cargar los bytes no siempre es el final del camino en frío. Dependiendo del tiempo de ejecución, el servidor también puede crear un contexto GPU, asignar grupos de memoria, preparar kernels o capturar gráficos de ejecución. Los sistemas que preservan el estado CUDA inicializado pueden despertarse más rápido que un reinicio completo porque esos pasos de configuración no tienen que repetirse todos.

Luego el prompt debe evaluarse de nuevo. La expulsión normalmente descarta la caché activa del modelo, por lo que un prompt largo del sistema, contexto recuperado o historial de chat debe pasar por el prellenado antes de que aparezca el primer token nuevo. Ese retraso no es la carga de pesos, pero los usuarios experimentan ambos costos como una pausa silenciosa.

Lo que suelen significar los diferentes patrones de latencia

El patrón de tiempo revela más que una sola prueba de velocidad. Compare cuándo ocurre la pausa, qué métrica crece y qué sucede en la solicitud inmediata repetida.

La firma de expulsión más característica es la primera fila: una solicitud costosa seguida de respuestas normales del mismo modelo. Las otras filas evitan que se fije un modelo en memoria cuando el problema real está en otra parte de la ruta de la solicitud.

Cómo probar si la expulsión es la causa

Comience con un modelo y un prompt fijo. Envíe el prompt dos veces con solo un breve intervalo, luego repita la prueba después de que el servidor haya estado inactivo el tiempo suficiente para superar su política actual de descarga. Mantenga la longitud del prompt y la configuración del modelo sin cambios para que la comparación aísle la residencia.

Registra el tiempo total de respuesta, tiempo de carga del modelo, tiempo de evaluación del prompt y tiempo de generación donde el tiempo de ejecución los exponga. Si solo el tiempo de carga se expande después del período de inactividad, la evidencia apunta a expulsión. Si en cambio crece la evaluación del prompt, la longitud del contexto o la reutilización de caché es la pista más adecuada.

Observa la memoria al mismo tiempo. Un modelo debería aparecer en RAM o VRAM después de la primera solicitud y permanecer allí durante la prueba de calentamiento. Si su huella desaparece antes de la solicitud lenta, tienes confirmación directa de que el tiempo de ejecución u otra carga de trabajo lo liberó.

Finalmente, cambia una condición. Extiende el tiempo de mantenimiento, detén temporalmente servicios GPU en competencia o precarga el modelo antes de la solicitud de prueba. Un diagnóstico real de expulsión debería responder al cambio. Si la latencia permanece sin cambios, vuelve a cuellos de botella de cómputo, memoria, almacenamiento o red en lugar de asumir que el modelo fue descargado.

Configuraciones prácticas que reducen los picos de expulsión

Mantén el modelo que atiende solicitudes interactivas residente durante un período que coincida con el uso real. Un asistente doméstico usado cada pocos minutos puede beneficiarse de una ventana de mantenimiento más larga. Un modelo grande usado una vez al día puede no hacerlo. La configuración debe proteger el camino crítico, no convertir cada modelo descargado en un consumo permanente de memoria.

Deja margen real en la memoria. La VRAM instalada no es idéntica a la memoria disponible para los pesos del modelo porque la pantalla, el tiempo de ejecución, la caché de contexto y otras aplicaciones también la consumen. Comprobar la memoria usada y restante con nvidia-smi te permite medir la VRAM libre real antes de elegir el tamaño y la cuantización del modelo.

Reduce el conjunto de trabajo residente cuando el modelo activo apenas cabe. Una cuantización más pequeña, un límite de contexto más corto o un modelo predeterminado más pequeño pueden crear suficiente margen para evitar la expulsión rutinaria. Las elecciones de modelo y contexto deben seguir los requisitos de RAM y acelerador de la carga de trabajo en lugar de solo el conteo de parámetros.

Controla el cambio de modelo. Dirige las solicitudes comunes a un modelo predeterminado y reserva un modelo especialista más grande para tareas que justifiquen la recarga. Si varios modelos deben permanecer disponibles, verifica que sus pesos combinados, cachés y sobrecarga en tiempo de ejecución encajen en lugar de aumentar ciegamente el límite de concurrencia.

Use almacenamiento local rápido para archivos de modelos y precargue el modelo interactivo después de un reinicio planificado. El almacenamiento más rápido no puede eliminar la inicialización o el trabajo de prellenado del prompt, pero puede acortar la etapa de transferencia. La precarga traslada ese costo a un momento controlado en lugar de hacer esperar a la primera persona que haga una pregunta.

Cuando la expulsión sigue siendo la compensación adecuada

La expulsión no es automáticamente un fallo. En un servidor doméstico con memoria limitada, previene que una carga de trabajo ocasional de IA monopolice recursos necesarios para compartir archivos, contenedores, servicios multimedia u otro modelo. El servidor renuncia al tiempo de activación instantáneo a cambio de capacidad y estabilidad.

La política correcta sigue la carga de trabajo. Mantenga caliente un asistente usado frecuentemente y sensible a la latencia. Permita que los modelos por lotes, modelos de imagen y experimentos poco usados se descarguen. Si dos modelos interactivos se desplazan constantemente, las opciones duraderas son modelos más pequeños, más memoria o aceleradores separados, no un valor infinito de mantenimiento activo.

Un límite práctico es la frecuencia de repetición. Si los usuarios suelen volver antes de que el modelo se descargue, extender la residencia elimina la fricción visible a un costo modesto de memoria. Si las solicitudes están separadas por horas y la máquina tiene otros trabajos, aceptar un inicio en frío puede ser el diseño de sistema más limpio.

Preguntas frecuentes

¿La expulsión del modelo empeora las respuestas de la IA?

La expulsión cambia la disponibilidad, no los pesos almacenados del modelo. Recargar el mismo modelo con el mismo prompt y configuraciones no debería reducir su capacidad. Sin embargo, una conversación descartada o caché de prefijo puede cambiar cuánto contexto debe procesarse de nuevo, y el estado de la aplicación faltante puede afectar la continuidad si no se almacenó por separado.

¿Puede un disco NVMe más rápido eliminar el pico de latencia?

Puede acortar la etapa de lectura de pesos, especialmente cuando la ruta de almacenamiento anterior era lenta o estaba ocupada, pero no puede eliminar la configuración de la GPU, la asignación de memoria, la preparación del kernel o el prellenado del prompt. Si el almacenamiento es solo una pequeña parte del tiempo de carga medido, una actualización a NVMe no eliminará toda la pausa.

¿Debería mantenerse cargado cada modelo local?

No. Fijar todos los modelos puede crear la misma presión de memoria que causó la rotación, mientras reduce la capacidad para cachés y otros servicios. Mantenga caliente el pequeño conjunto de modelos sensibles a la latencia, permita que los modelos ocasionales se descarguen y confirme la huella combinada residente bajo la carga real del servidor.

La regla más simple es comparar la primera solicitud con la repetición inmediata. Una gran diferencia en el tiempo de carga indica expulsión; una generación lenta en ambas solicitudes apunta a otro problema. Mida ese límite primero, luego ajuste la residencia, el tamaño del modelo y los recursos compartidos según lo que los usuarios del modelo realmente necesiten para sentir inmediatez.