Actualiza vLLM 0.29 sin romper tu flota: prueba MRV2, fallbacks y límites de cola primero

Estás a punto de apuntar una flota compartida de vLLM a 0.29.0, y lo primero que debes verificar es qué runner utiliza realmente cada pod. vLLM 0.29.0 establece Model Runner V2 como la ruta predeterminada para todos los modelos, mientras que Model Runner V1 queda en desuso y está programado para su eliminación en v0.32. La liberación contiene 594 commits de 277 contribuidores, incluidos 91 contribuidores nuevos. Una flota compartida tiene una ventana corta para demostrar cada modelo, flag y ruta de cola antes de que desaparezca el fallback. Si algunos endpoints caen a fallback, la proporción afectada es el número de fallbacks dividido entre el total de endpoints, y esa proporción ejecuta una ruta de ejecución diferente. El equilibrio está entre la cobertura del runner y el riesgo de eliminación: el nuevo runner es el predeterminado, pero el antiguo se va.

El runner predeterminado obliga a una prueba en toda la flota

El cambio de runner obliga a una prueba en toda la flota. Modifica la ruta de ejecución de toda la flota y cómo la flota absorbe la carga. Para un stack compartido, un cambio de configuración puede alterar la latencia, la memoria y el comportamiento de cola entre tenants. La proporción de fallback puede tener prioridades de cola, límites de memoria y comportamiento de batch diferentes. La matriz de pruebas debe separar el soporte de modelos, el soporte de funciones y el comportamiento de admisión.

Los fallbacks ocultan la actualización

Cuando un pod mantiene una capacidad no soportada, puede parecer saludable mientras ejecuta la ruta antigua. El plan declarado es cerrar esas brechas de capacidad de Model Runner V2 en 2-3 semanas. Para una flota, trátalo como una auditoría de compatibilidad en lugar de un despliegue rutinario. Un solo pod puede estar bien, pero una flota con runners mixtos puede mostrar latencia de cola desigual y presión de memoria.

Un fallback es útil para un solo pod y peligroso para una flota. Permite que un despliegue mantenga una función mientras el resto de la flota avanza. Eso crea perfiles de memoria, comportamientos de batch y modos de fallo diferentes. Tu monitoreo debe mostrar qué runner está activo, no solo que las solicitudes están teniendo éxito. Si el log indica que el runner antiguo está activo, trátalo como un hallazgo. Usa el plan de cierre de brechas para establecer una fecha de re-prueba. Esos flags es fácil dejarlos activados por accidente.

Los controles de admisión y las arquitecturas eliminadas cambian el comportamiento sin provocar fallos

La liberación también añade controles de admisión y elimina arquitecturas de modelos, lo que cambia el comportamiento del stack compartido sin siempre provocar fallos. Los controles de admisión son donde reside la política de rechazo. El comportamiento de cola decide si la sobrecarga se convierte en latencia o en rechazos. Un modelo que funcionaba antes puede fallar en el momento de la carga. El dimensionamiento de memoria y la configuración de batch-size necesitan una revisión tras los cambios de runner.

La lista de verificación de actualización está ordenada por severidad. Inventario primero, porque un bloqueo total es un bloqueo total. Verificaciones de fallback en segundo lugar, porque una ruta oculta puede parecer saludable. Verificaciones de admisión y cola al final, porque cambian el comportamiento sin provocar fallos.

• Inventario de cada arquitectura de modelo y flag de runner en la flota.
• Confirma si cada despliegue usa Model Runner V2 o cae a Model Runner V1.
• Desactiva o aísla las capacidades que Model Runner V2 aún no cubre, porque un pod aún puede usar Model Runner V1 cuando las activa, incluidos procesadores de logits personalizados, paralelismo de secuencia, superposición de doble batch, paralelismo elástico de expertos y algunas rutas de decodificación especulativa.
• Realiza benchmark de all-reduce de paralelismo tensorial y caché de prefijo en Model Runner V2.
• Configura los flags de control de admisión y los límites de cola, y luego verifica las solicitudes rechazadas.
• Valida max_num_batched_tokens y el dimensionamiento de la caché KV.

No trates un arranque exitoso como un aprobado. Un modelo puede cargarse, servir algunas solicitudes y aun así encontrarse con un rechazo de admisión bajo carga. Compara el canary contra la versión anterior con la misma mezcla de tráfico, mezcla de modelos y mezcla de colas de tenants, y luego verifica las solicitudes rechazadas, la profundidad de cola, la latencia de cola y el margen de memoria. Registra el runner activo, los flags y la profundidad de cola en las notas del canary. Mantén el runner antiguo visible en métricas, logs y etiquetas de pod durante el canary. Detente ante un fallback y decide si esa función es necesaria. Planifica un cambio de modelo o un backend diferente ante un bloqueo total. Ajusta el flag ante un rechazo antes de que la flota lo vea.