Idea para llevarse: El endurecimiento también exige migración: comprobar runtime, orígenes, formatos de entrada y límites de generación permite adoptar defensas sin romper clientes por sorpresa.
Los bordes que cambió v0.32
Las notas de vLLM 0.32.0, del 18 de octubre, recogen varios cambios que afectan al contrato de operación. Python 3.10 deja de estar soportado y el mínimo pasa a 3.11. Los orígenes CORS ya no permiten todos por defecto. Las imágenes no confiables se limitan a formatos raster mediante una allowlist y los JSON Schema con más de 64 niveles se rechazan. La versión también cambia dependencias, con transformers>=5.16.1,<5.20.0. Son cambios declarados por el proyecto, no una auditoría independiente del código.[1][2][4]
CORS: una defensa que puede romper un cliente
CORS controla qué orígenes pueden leer respuestas desde navegadores; no es autenticación, un firewall ni un bloqueo general de solicitudes o del tráfico servidor a servidor. Una aplicación legítima que dependiera del comodín anterior necesita configurar --allowed-origins con sus orígenes concretos. La migración correcta no consiste en volver a abrir todo para recuperar compatibilidad, sino en inventariar qué clientes web necesitan leer la respuesta y permitir solo esos.[4]
Validación de entrada y disponibilidad
La allowlist raster excluye EPS/PostScript y WMF de las imágenes no confiables; el límite de profundidad de esquemas devuelve 400 cuando supera 64 niveles. Ambas reglas sitúan una frontera explícita entre documento aceptado y rechazado. Antes de desplegar, conviene probar no solo los formatos válidos sino la respuesta de error que recibirá el usuario. Un cliente que reintente indiscriminadamente un 400 puede convertir una defensa del servidor en una tormenta de peticiones fallidas.[2]
max_tokens deja de reservar contexto
La nota indica que max_tokens pasa a tratarse como una cota superior de salida, no como una reserva dentro de la ventana de contexto. Así, prompts largos que antes podían rechazarse por esa reserva tienen otro comportamiento. La mejora de flexibilidad necesita pruebas de límites: la aplicación debe medir entrada y salida reales, revisar sus propias comprobaciones y evitar que una solicitud grande desplace recursos sin control. La nueva semántica no elimina la necesidad de cuotas ni de políticas de admisión.[3]
Runtime y dependencias en el preflight
Un preflight útil debe verificar el intérprete antes de construir imágenes, resolver el rango de Transformers y ejecutar el conjunto de modelos usado. Si el entorno aún depende de Python 3.10, actualizar vLLM sin migrar el runtime detiene el despliegue antes de cualquier prueba funcional. El rango acotado de Transformers también puede entrar en conflicto con otro componente. Fijar y probar el conjunto completo es más seguro que instalar cada paquete por separado y descubrir la incompatibilidad en arranque.[1]
Endurecer no equivale a certificar
Las notas incluyen correcciones de seguridad y controles adicionales, pero su presencia no demuestra que una instalación sea segura ni que todos los vectores estén cubiertos. No hemos reproducido advisories ni auditado esta versión. El valor práctico de la retrospectiva es una checklist de contrato: runtime, orígenes, entrada, esquemas, tokens y dependencias. Cada punto necesita evidencia del despliegue propio antes de afirmar que la migración está completa.[2]
Fuentes, fechas y alcance
Publicación real: 2 de noviembre de 2026. Periodo analizado: 18 de octubre de 2026. Versión de evidencia: conserva el texto y liga runtime, formatos, profundidad, CORS y max_tokens a extractos primarios específicos. Las cuatro instantáneas proceden de una sola fuente y no son fuentes independientes. Conserva las objeciones anteriores.
- vllm-project/vllm v0.32.0: runtime y dependencias. Consulta: .
- vllm-project/vllm v0.32.0: validación de imágenes y esquemas. Consulta: .
- vllm-project/vllm v0.32.0: max_tokens. Consulta: .
- vllm-project/vllm v0.32.0: CORS. Consulta: .