Idea para llevarse: Un cambio de runner predeterminado exige pruebas de equivalencia por modelo y función; las excepciones y las nuevas rutas forman parte del alcance, no son notas al margen.
El cambio de predeterminado de septiembre
Las notas de vLLM 0.29.0, del 9 de septiembre, indican que Model Runner V2 pasó a ser el runner predeterminado para todos los modelos. La misma publicación matiza que MRV1 seguía en ciertos modelos ROCm y en funciones que MRV2 todavía no soportaba, y anuncia su intención de retirar MRV1 en una versión posterior. Ese matiz evita una lectura demasiado simple: «predeterminado para todos» no significaba que cada combinación ya ejecutara el mismo código ni que desaparecieran las rutas antiguas.[2]
Qué añadió vLLM 0.30
Trece días después, vLLM 0.30.0 detalló dual-batch overlap en modo eager y con CUDA graphs para pasos microbatch, métodos de decodificación especulativa bajo paralelismo de pipeline y verificación adaptativa para draft-model speculators. También describió trabajo de memoria y captura de grafos. Estas funciones muestran que la migración no consiste únicamente en cambiar un nombre interno: afecta a planificación, memoria, paralelismo y rutas especulativas que una aplicación puede activar de forma desigual.[3]
La matriz que sí debe probarse
Un inventario de aceptación debería cruzar modelo, hardware, runner, tipo de paralelismo, longitudes de entrada y salida, y funciones de generación. Si se usa decodificación especulativa, hay que incluir el drafter y la verificación; si se usa pipeline parallelism, la prueba debe activar esa configuración. Las cargas no generativas también merecen una fila cuando forman parte del servicio. Un único prompt de cortesía no detecta regresiones en esas combinaciones. La matriz debe limitarse a lo realmente desplegado para seguir siendo ejecutable y útil.[2][3]
Rendimiento: atribuir antes de comparar
Las notas de 0.30 incluyen mediciones concretas en determinadas PR y hardware, como una reducción del tiempo de captura e inicialización en H200. No las trasladamos a otros entornos. Su valor para este análisis es señalar qué fases conviene medir: captura, arranque, memoria reservada y pasos de ejecución. Una comparación propia debe fijar carga y concurrencia, registrar la configuración y separar calentamiento de estado estable. Sin esa disciplina, una mejora de arranque podría confundirse con una mejora sostenida del servicio.[1]
Compatibilidad y reversión
El período de transición descrito por las notas hace prudente conservar una configuración anterior conocida y comprobar que la reversión no dependa de artefactos incompatibles. Los equipos deberían registrar qué excepciones les afectan y evitar activar el cambio junto con otras migraciones de dependencias. Si una función queda fuera de MRV2, el informe debe decirlo explícitamente en lugar de declarar éxito global. La reversión forma parte del ensayo, no un apéndice para cuando producción ya falla.[2][3]
Límites de la evidencia
No hemos ejecutado vLLM 0.29 ni 0.30 en esta retrospectiva, ni verificado qué combinaciones concretas quedaban fuera más allá de lo expresado en las notas. Tampoco inferimos que MRV2 sea siempre más rápido o más eficiente. La evidencia sustenta el cambio anunciado y las nuevas áreas de comportamiento; la matriz y los criterios de aceptación son la aportación práctica para decidir una migración con riesgo acotado.[2][3]
Fuentes, fechas y alcance
Publicación real: 2 de noviembre de 2026. Periodo analizado: 9–22 de septiembre de 2026. Versión de evidencia: conserva el texto editorial y aporta extractos focalizados y claims explícitos para MRV1, captura de grafos y la medición H200. No altera la fuente primaria ni el rechazo anterior.