vLLM: de 92% a 100% en precisión de tool calls

Un 92% de esquemas correctos no alcanza para producción

Servir Kimi K2.6 con vLLM 0.28 devolvía el esquema esperado de tool call solo el 92% de las veces, según documenta Ubicloud, proveedor de inferencia que sirve modelos Kimi y DeepSeek, en su blog técnico. Traducido a la práctica: 2 de cada 25 llamadas a herramientas salían malformadas.

Para un founder que está montando un agente, el problema no es el error aislado. Es que el agente reintenta, el mensaje de error entra en la ventana de contexto y el modelo empieza a razonar sobre basura. En cargas de trabajo agénticas, donde las sesiones de varios turnos son la norma, ese ruido se acumula y degrada la calidad de toda la conversación.

La buena noticia: vLLM 0.31 liberó una bandera de servidor que permite llegar al 100% de precisión de esquema con los modelos Kimi y DeepSeek más nuevos.

¿Qué es la precisión de esquema y por qué falla?

Cuando conectas un agente a un modelo, el harness le envía un array JSON con las herramientas disponibles: nombre, parámetros, tipos y cuáles son obligatorios. Ese contrato es el esquema.

El motor de inferencia envuelve ese JSON en tokens específicos del modelo y lo inyecta en el prompt. Cuando el usuario pide algo, el modelo emite tokens que el parser del servidor convierte en un objeto JSON con la llamada a la herramienta. Si esa llamada no respeta el esquema, el harness no puede ejecutarla.

¿Por qué falla si el prompt es claro? Porque un LLM no corre un compilador ni un verificador de tipos: muestrea el siguiente token según probabilidad. Y los modelos se entrenan con muchos datasets de tool calling, cada uno con sus propias convenciones. El resultado típico es que el modelo inventa un nombre que vio durante el entrenamiento: genera search_web cuando la herramienta disponible se llama web_search, o usa city_name cuando el esquema activo espera location.

Moonshot AI publicó el benchmark K2VV ToolCall justamente para medir esto. Son 2000 requests que evalúan dos métricas: trigger similarity (cuándo el servicio decide disparar una herramienta, comparado con el servicio propio de Moonshot) y schema accuracy (qué fracción de las llamadas respeta el esquema y puede ejecutarse).

¿Cómo funciona el constrained decoding?

El constrained decoding cambia el enfoque. En vez de dejar que el modelo muestree libremente y validar después, el motor guía la generación paso a paso: en cada token solo se permiten opciones válidas.

vLLM implementa esto con las etiquetas estructurales de XGrammar. La definición obliga a seguir un camino válido: inicio de tool call, nombre de la herramienta, índice, inicio de argumentos, JSON restringido por esquema y fin de tool call. Cuando la generación llega a la fase del índice, el motor restringe el muestreo a tokens enteros y enmascara todo lo demás.

El resultado: la precisión de esquema deja de ser un mejor esfuerzo y pasa a ser una garantía en tiempo de ejecución. El modelo sigue decidiendo qué token generar, pero lo elige dentro de un conjunto sintácticamente correcto. Y según Ubicloud, el costo de rendimiento es despreciable, porque las máscaras de tokens se precomputan por fase y se aplican de forma eficiente en la GPU.

El paper de referencia es de Dong, Yixin, et al., XGrammar: Flexible and efficient structured generation engine for large language models, publicado en Proceedings of Machine Learning and Systems 7 (2025).

¿Por qué vLLM lo traía desactivado por defecto?

Acá está el detalle que más le sirve a un equipo técnico. Ubicloud primero agregó constrained decoding en su propio fork de vLLM. Cuando vLLM incorporó la función en la v0.25, migraron a la versión upstream. Poco después, su score de precisión volvió a caer, esta vez al 91%.

No era un bug: vLLM había cambiado el comportamiento por defecto para las requests que no activan explícitamente el constrained decoding. La razón es de diseño. vLLM soporta más de 200 arquitecturas de modelos, según el comparativo publicado por MarkTechPost, y el soporte de constrained decoding es una tarea por modelo. Con varios modelos mostrando problemas al activarlo, desactivarlo por defecto era la opción segura para un motor agnóstico. Después agregaron la bandera --tool-strict-level para que cada despliegue decida.

Ubicloud tomó la decisión opuesta: como su foco es servir Kimi y DeepSeek con la calidad de un proveedor de primera parte, activó el constrained decoding, volvió a correr el K2VV ToolCall y verificó 100% de precisión de esquema en todas las versiones de modelo que sirve antes de desplegar a producción.

Qué significa esto para tu startup

La lección central es incómoda: la calidad que ves no depende solo del modelo, depende del motor de inferencia y de su configuración. Cambia el motor o sus flags y cambia la calidad del output. Si tu agente falla de forma intermitente y culpas al modelo, puede que el problema esté una capa más abajo.

Acciones concretas:

• Mide antes de opinar. Si sirves Kimi, corre el K2VV ToolCall (2000 requests) y anota tu schema accuracy real. Un 92% suena alto hasta que lo multiplicas por el volumen de llamadas de un agente en producción.
• Activa el modo estricto y verifica. En vLLM, revisa la bandera --tool-strict-level y confirma en tu configuración que el constrained decoding está encendido para los modelos que lo soportan. No asumas que el default te conviene: está pensado para un motor agnóstico, no para tu caso de uso.
• Trata los errores de tool call como deuda de infraestructura, no como ruido. Cada reintento consume tokens, ensucia el contexto y baja la calidad del turno siguiente. Si tu agente reintenta en silencio, estás pagando por contexto contaminado.
• Si usas un proveedor de inferencia, pregúntale por su schema accuracy. Es una métrica medible y comparable. Un proveedor que no la conoce está sirviendo modelos abiertos sin verificar la calidad que promete el benchmark.

El contexto: servir modelos abiertos con calidad de primera parte

El caso de Ubicloud no es aislado. La brecha entre que el modelo sea bueno en los benchmarks y que funcione en tu producto se está convirtiendo en un negocio en sí mismo.

DeepSeek abrió el código de DeepInfer, el framework de inferencia que corre sus servicios en producción y que es el motor detrás de DeepSeek-V4.1-Flash, bajo licencia Apache 2.0, según reportó MarkTechPost el 20 de octubre. El detalle interesante para quien sirve modelos: DeepInfer se construyó originalmente sobre vLLM, con ideas de SGLang y TensorRT-LLM, y soporta salidas estructuradas con regex, JSON schema y gramáticas EBNF. La propia DeepSeek reporta más de 25.000 tokens de salida por segundo por GPU y un clúster que sirve 155 billones de tokens por día. La limitación: es solo inferencia offline, sin sistema de KV cache, sin disaggregación prefill/decode ni balanceador.

Del otro lado, los modelos abiertos chinos siguen empujando el piso de calidad. Moonshot AI presentó Kimi K3, un modelo abierto de 2,8 billones de parámetros, y once días después publicó los pesos completos en Hugging Face, según TechTarget. Ese mismo artículo recuerda que el lanzamiento de DeepSeek R1 en enero de 2025 fue el punto de inflexión que cambió las expectativas sobre lo que un laboratorio chino podía publicar.

Para un founder, la lectura práctica es que la capa de serving dejó de ser un detalle de infraestructura. Es donde se gana o se pierde la calidad que el benchmark promete.

Conclusión

Pasar del 92% al 100% en precisión de esquema no requiere cambiar de modelo: requiere activar una función que ya existe en vLLM y verificar el resultado con un benchmark. Ubicloud lo hizo, lo midió y lo desplegó.

Si estás construyendo agentes sobre modelos abiertos, la pregunta ya no es solo qué modelo usas, sino quién lo sirve, con qué configuración y con qué evidencia de precisión. Esa es la diferencia entre un agente que funciona en la demo y uno que aguanta producción.

Fuentes

• Fixing Tool-Call Accuracy in vLLM (fuente original)
• DeepSeek Open-Sources DeepInfer, the Inference Framework Behind DeepSeek-V4.1-Flash
• Kimi K3, Chinese open-weight models challenge AI status quo

Artículos relacionados:

vLLM: Anatomía del sistema de inferencia LLM que reduce costos 50% vLLM EAGLE 3.1: 2x más eficiencia en inferencia de LLM Motores IA 2026: vLLM vs TensorRT-LLM vs llama.cpp – Guía founder DeepSeek V4-Pro: 75% descuento hasta 31 mayo – Ahorra $190K EEUU ordena eliminar DeepSeek de agencias federales