vLLM Semantic Router: colaboración entre modelos como primitiva de servicio abierta

vLLM Semantic Router plantea que la siguiente capa clave en la inferencia de IA no es el modelo frontera, sino el router que tiene delante. Un router puede reducir costes eligiendo el modelo adecuado para cada petición, aplicar políticas de seguridad enviando dominios sensibles a modelos más estrictos, y coordinar nube y edge manteniendo la latencia baja cuando conviene. El artículo va más allá: sostiene que el router puede hacer que el modelo sea mejor sin cambiar pesos ni obligar a cada aplicación a montar un agent graph propio, convirtiendo una llamada a la API en una colaboración acotada dentro de la capa de servicio. Inspirado por propuestas como Sakana Fugu, Conductor y Trinity, el proyecto lo lleva al terreno abierto. Detrás de una identidad de modelo estable, el router selecciona una receta, reparte el trabajo entre varios modelos, recoge respuestas, mide el desacuerdo, sintetiza la respuesta final y devuelve una respuesta compatible con OpenAI. El runtime, llamado looper, ejecuta micro-agentes acotados con cinco patrones principales: Confidence (escalado secuencial según confianza), Ratings (conjunto en paralelo con tope de concurrencia), ReMoM (mixto repetido con cuórum y síntesis), Fusion (panel de jueces con desacuerdo como señal) y Workflows (planificador, parcheador, verificador y finalizador con presupuesto y topología fijos). El usuario sigue viendo un único nombre de modelo, vllm-sr/auto, mientras el router elige el bucle adecuado según dificultad, riesgo, contrato de salida, latencia y coste. La conclusión central es que el mejor bucle depende de la tarea: GPQA-Diamond se beneficia de ReMoM con respuesta estricta, LiveCodeBench requiere detección de restricciones y robustez ante tests ocultos, y Humanity's Last Exam necesita resolución de desacuerdos y formato exacto. La receta correcta siempre está moldeada por el problema.