Ejecuta esta puerta de PyTorch 2.13 antes de tu próxima actualización del stack de serving

Estás decidiendo si una actualización del stack de serving merece el riesgo. vLLM 0.28.0 publicó 584 commits de 270 contribuidores, incluidos 76 nuevos. El intercambio es latencia por riesgo de entorno: 584 commits repartidos entre 270 contribuidores, con 76 nuevos, representan una amplia superficie de compatibilidad, por lo que una flota pequeña debe aplicar una puerta al stack antes de perseguir las nuevas cifras. Lee el release como una lista de verificación de compatibilidad.

Las diferencias de pins fallan antes del tráfico

El PR #48155 actualizó las versiones del ecosistema PyTorch de PyTorch 2.11.0 a 2.13.0, torchvision 0.26.0 a 0.28.0 y Triton 3.6.0 a 3.7.1. Un pin obsoleto puede fallar en el momento de la importación, no en el de la solicitud, cuando la imagen aún lleva el trío antiguo. Compara el manifiesto de la imagen, no solo la lista de paquetes, y coloca la diferencia de pins al inicio del registro de despliegue.

ABI y deriva fallan después del arranque

La actualización a PyTorch 2.13 requirió un workaround en la prueba de CPU multi-imagen de Qwen2-VL, limitando max_tokens y ampliando la tolerancia de logprob debido a la deriva numérica. La misma actualización deshabilitó la verificación de importación de nixl_ep como fallo esperado mientras una incompatibilidad de ABI en una extensión precompilada aguardaba una recompilación. Estos son modos de fallo posteriores al arranque. Realiza una prueba de humo de la ruta de importación en el entorno de serving y mide la deriva con un conjunto fijo de prompts antes y después del bump. Cuando la tolerancia de logprob necesite ampliarse, registra la diferencia junto con la línea base.

Las compilaciones específicas de hardware conllevan el mismo riesgo. vLLM Ascend v0.26.0rc1 fue un release candidate con restricciones de modelo alineado con vLLM v0.26.0 upstream. Sus modelos completamente validados incluían Kimi K3, GLM-5.2, DeepSeek V4 Flash 0731 y DeepSeek V4 Pro 0813. El anterior vLLM Ascend v0.23.0 fue un release oficial alineado con vLLM v0.23.0 upstream. Compara tu modelo con la lista validada antes de depender de él. Si tu modelo no aparece en la lista, trátalo como no validado hasta que tu propia comprobación de drift indique lo contrario, y guarda ese resultado junto con la línea base.

Línea base antes de medir la ganancia de latencia

vLLM 0.28.0 publicó sparse MLA para DeepSeek V4, offloading de KV cache a nivel de disco, madurez de Model Runner V2 y aceleraciones de kernel de 1.5-3x para Kimi-K3. Establece la línea base de TTFT y throughput antes de habilitar los nuevos kernels. Captura las cifras por modelo, no por imagen, porque una aceleración de kernel para un modelo puede ocultar una regresión en otro. Incluye solicitudes de contexto largo para cualquier modelo que use offloading de KV cache a nivel de disco, y registra el conjunto de prompts, la seed y el número de GPUs en una sola nota.

El PR #48155 se fusionó en vLLM main el 23 de julio de 2026. Registra esa fecha en el change log para que el cambio de entorno quede separado del cambio de funcionalidad. Para la desagregación de prefill decode, la puerta debe cubrir cada worker. Un bump de pin puede cambiar un worker y dejar el otro con la ABI antigua, así que prueba el par de workers, no solo el endpoint de serving.

La puerta convierte la medición en una decisión

Ejecuta la siguiente lista como puerta previa a la actualización antes de que la imagen llegue a producción. Los primeros elementos detectan fallos de entorno; los posteriores convierten la medición en una decisión. Mantén la puerta lo suficientemente corta para completarla antes de la ventana de despliegue, pero lo suficientemente completa para capturar los modos de fallo anteriores.

• Verifica que los pins de PyTorch, torchvision y Triton coincidan con el nuevo stack.
• Realiza una prueba de humo de la ruta de importación sensible a ABI antes del tráfico.
• Mide la deriva numérica con un conjunto fijo de prompts, usando el workaround de CPU de Qwen2-VL como señal de alerta.
• Establece la línea base de TTFT y throughput para cada modelo objetivo antes de habilitar los nuevos kernels.
• Configura un disparador de rollback ante fallo de importación, deriva de tokens o una regresión de TTFT que supere tu SLO.

Cualquier fallo en un elemento detiene el despliegue. Conserva la etiqueta de imagen antigua, el archivo de pins antiguo y la línea base antigua en el registro de cambios, con la fecha y el nombre del modelo. El nuevo stack puede pasar la importación y la deriva pero no alcanzar tu objetivo de TTFT; decide con datos en lugar de suponer. Un disparador activado exige rollback antes de la siguiente solicitud del cliente.