SGLang v0.5.17: reduce los costes de reinicio y expulsión

El coste operativo compra el comportamiento de reinicio y expulsión

Antes de activar la caché de sesión o el demonio de pesos de SGLang v0.5.17, calcule el coste operativo. Para Qwen3-235B FP8 en 4 GPUs, el reinicio de modelo grande medido es de aproximadamente 6,5 minutos. SGLang v0.5.17 añade una Unified Radix Cache con conciencia de referencia de sesión y un demonio de caché de pesos por GPU. La compensación es operativa: una bandera, un proceso persistente por GPU y una memoria que debe vigilarse. Con esa línea base, cada reinicio adicional añade aproximadamente 6,5 minutos de tiempo de inactividad. No active ninguno por defecto.

Cada palanca solo compensa para una carga de trabajo compatible

Recorra la lista de verificación en orden antes de cambiar las banderas de producción. Para el servicio de agentes, la caché de sesión ayuda con el contexto repetido que ya está en la caché radix bajo presión de expulsión. El demonio ayuda con la latencia de reinicio de modelos que domina el coste. Ninguno es una corrección general de fiabilidad.

• Perfile la frecuencia de reinicios y la forma de las sesiones. Registre reinicios por día, reutilización mediana de contexto y presión de expulsión; deténgase ante reinicios raros y sesiones cortas. Guarde el perfil en el libro de operaciones.
• Active la caché de sesión solo para sesiones estables. Inicie SGLang con --enable-session-radix-cache para que las solicitudes de despliegue de agentes o de aprendizaje por refuerzo puedan llevar un session_id estable. Llame a /close_session al final de la sesión.
• No trate una referencia de sesión como un anclaje. Cambia el orden de expulsión de la caché KV, pero no mantiene residente el KV referenciado ni el estado recurrente. Verifique que el orden de expulsión refleje las sesiones activas sin asumir un límite de memoria.
• Inicie el demonio de caché de pesos solo para reinicios frecuentes de modelos grandes con paralelismo de tensores. Mantiene un proceso persistente en cada GPU que almacena el fragmento de paralelismo de tensores tras la cuantización, y un motor nuevo reutiliza esa memoria física de GPU a través de CUDA IPC, un mecanismo de compartición de memoria de GPU, con coordinación mediante sockets de dominio Unix. Confirme que el motor de reemplazo reutiliza el fragmento en caché antes de ampliar el despliegue.
• Mida el tiempo de reinicio p95, la tasa de aciertos KV, la memoria de GPU y los fallos de L3 respaldados en almacenamiento. Registre la línea base antes de activar cualquiera de las dos palancas. Compare antes y después, y considere cualquiera de las palancas como corrección de fiabilidad solo si la latencia de cola y la memoria se mantienen dentro del presupuesto.

En el cambio publicado de v0.5.17, la caché L3 respaldada en almacenamiento no está incluida en la ruta del ciclo de vida de sesión. Compruebe si esa ruta está cubierta antes de depender de referencias de sesión para una caché radix respaldada en almacenamiento.

La cifra de menos de un segundo es una fase, no un tiempo de recuperación

La fase de mapeo de pesos tiene una duración medida de menos de un segundo. El reinicio en frío de menos de 10 segundos y el estado de espera caliente de menos de un segundo siguen siendo objetivos del mapa de ruta, no tiempos de recuperación de motor completo publicados. Planifique en torno a la línea base de reinicio medida para SLO que dependan de la recuperación de motor completo.

Un despliegue canario mantiene la ruta de reversión corta

Coloque la bandera de sesión primero en un grupo pequeño, no en toda la flota. Mantenga el canario lo suficientemente pequeño para que una mala expulsión o un fallo del demonio sea visible antes de que afecte a la flota. Observe si las referencias de sesión activas afectan a la expulsión como se espera y si la memoria se mantiene dentro del presupuesto. Revierta la bandera cuando la expulsión de la caché radix perjudique a otro tráfico. Para el demonio, comience con un conjunto limitado de GPUs y confirme que el motor de reemplazo reutiliza el fragmento en caché antes de ampliar el despliegue. El motor debe volver a la ruta normal de reinicio ante un fallo del demonio sin dejar memoria de GPU huérfana.

La caché de sesión es útil para el contexto repetido ya residente, pero puede aportar poco valor para una caché radix mayoritariamente en frío. El demonio mantiene un fragmento por GPU en memoria física de GPU, por lo que un reinicio posterior puede reutilizarlo. Un límite de memoria convierte al fragmento persistente en un riesgo de capacidad. En ambos casos, la decisión es una cuestión de presupuesto, no de funcionalidad.

Asigne un responsable a la ruta de reinicio y otro a la ruta de caché. El responsable del reinicio debe conocer la línea base medida, el estado del demonio y el plan de contingencia ante un fallo del demonio. El responsable de la caché debe saber qué sesiones están activas, qué prefijos están referenciados y qué ocurre al final de la sesión. Documente la transición en el libro de operaciones para la propiedad entre equipos. Un reinicio no debe esperar a una decisión de caché. Una expulsión de caché no debe confundirse con el cierre de sesión.