Lista de verificación para actualizar SGLang v0.5.20: CUDA 12, response store, TTFT

El build lane determina si fijas o migras

La decisión es binaria: mantener el build lane actual o migrar el build y asumir el coste de flags y benchmarks. En ROCm, SGLang v0.5.20 redujo el tiempo de carga de GLM-5.2 con paralelismo de tensores 4 en cuatro GPUs MI355X de 505,7 segundos a 40,4 segundos. SGLang v0.5.19 fue la última versión con artefactos CUDA 12 -cu12x, y SGLang v0.5.20 cerró ese build lane. La cuenta: un build lane bloqueado implica fijar o migrar; un build lane abierto implica una lista de cinco puntos. El trabajo es el build de la imagen, el contrato de API y la ejecución del benchmark.

Comprueba la etiqueta de la imagen antes de tocar el servidor. Una flota que depende de un build lane estrecho no puede dar por sentado que la actualización mantenga el mismo camino. La jugada segura es fijar el build actual para ese lane o validar el nuevo lane primero en un clúster de staging. Las matrices de build compartidas necesitan un pin explícito en el manifiesto de despliegue para que la actualización no se desvíe a producción por accidente.

El almacenamiento de respuestas cambia el contrato de API

SGLang v0.5.20 modifica /v1/responses para que ya no conserve las salidas anteriores en memoria a menos que el servidor se inicie con --enable-response-store; sin ese flag, las búsquedas, el encadenamiento de respuestas y las llamadas en segundo plano fallan con 400, y los despliegues PD no pueden activar el store. El encadenamiento de respuestas necesita el flag antes del rollout. Sin encadenamiento, el valor por defecto deja una superficie de API más pequeña. Prueba la ruta de llamada exacta antes del rollout. El código del cliente debe fallar de forma explícita cuando el store está desactivado, porque un fallback silencioso puede ocultar una integración rota hasta que el tráfico sea lo suficientemente alto como para importar.

El serving desagregado endurece la restricción. Cuando la forma del despliegue no puede activar el store, el endpoint de respuestas no es un reemplazo directo del comportamiento anterior. Planifica el lado del cliente en torno a las llamadas que devolverán un error y mantén el build fijado disponible para la porción de tráfico que aún necesita encadenamiento. Documenta el comportamiento del cliente en la nota de versión, porque el próximo incidente será más fácil de depurar cuando el error esperado ya esté escrito.

Ejecuta la lista de cinco puntos antes de conmutar la flota

Ejecútalos en orden. Cada uno corresponde a un cambio rompedor o a un número que necesitas volver a medir. Los puntos cubren la ruta de build, el contrato de API, los flags eliminados, el benchmark de caché y la ruta de carga del acelerador.

• Fija CUDA 12: mantén la ruta de build -cu12x o migra antes de actualizar.
• Reactiva el almacenamiento de respuestas: establece --enable-response-store para las rutas de llamada afectadas de /v1/responses.
• Elimina los flags de prefill CP v1: quita las opciones v1 antiguas. SGLang v0.5.20 eliminó el runtime de paralelismo de contexto de prefill v1 y sus opciones de línea de comandos, dejando el enfoque basado en estrategia como la única ruta de prefill CP y bloqueando el prefill CP en HIP, NPU y MUSA hasta que se porte.
• Benchmark del árbol radix unificado: vuelve a medir la tasa de acierto de tokens y el TTFT medio con la forma de tráfico que ejecutas. En el caso reportado de system prompt compartido, la caché de puntos de ramificación del árbol radix unificado de SGLang v0.5.20 elevó la tasa de acierto de tokens de DeepSeek-V4-Flash del 43,8% al 60,8% y redujo el tiempo medio hasta el primer token de 1,57 segundos a 1,07 segundos.
• Valida el tiempo de carga en ROCm: vuelve a medir el tiempo de carga en tu flota ROCm y compáralo con el build fijado.

El scheduler añade otro número: SGLang v0.5.20 introdujo una política de scheduling HRRN, una regla de colas, cuyo tiempo medio hasta el primer token fue un 69% menor que el first-come-first-served en una traza de producción de GLM-5.2. El tráfico con picos necesita una ejecución de reproducción antes de que el resultado se confíe. El tráfico estable debe apoyarse en el build lane y el benchmark de caché.

Usa los números como puerta, no como rumor

Ejecuta la lista en staging antes de tocar producción. Mantén el build fijado disponible para rollback. Mantén el canary pequeño y la ruta de rollback caliente. Captura la misma forma de traza que usas en producción y luego compara la latencia del primer token, la tasa de acierto de caché y el tiempo de carga. Un build lane bloqueado pide fijar. Las ganancias de caché y scheduler en la traza respaldan una actualización. Una traza plana respalda mantener el pin y revisarlo más adelante.

Mantén las comprobaciones separadas: un pin de build lane es una decisión de cadena de suministro, y una ganancia de caché es una señal de rendimiento. La flota solo debe moverse cuando la traza de staging coincida con la forma de producción y la ruta de rollback siga disponible. Escribe la decisión en la nota de versión. Nombra la traza, el comando de rollback y el responsable.