La calidad que obtienes de un modelo open-source depende de más que del modelo en sí

Cuando Ubicloud comenzó a servir Kimi K2.6 con el motor de inferencia vLLM, los números parecían razonables a primera vista: el modelo respondía rápido, consumía GPUs de forma eficiente y entregaba resultados coherentes. Pero había un problema silencioso que solo aparecía bajo presión — solo el 92% de las llamadas de herramientas eran válidas. Eso significa que, cada 25 intentos, dos fallaban porque el modelo generaba un JSON malformado, un nombre de parámetro incorrecto o un schema que simplemente no coincidía con lo que el código de orquestación esperaba.

Para una aplicación de chat tradicional, el 92% suena a éxito. Para un agente de IA autónomo que necesita ejecutar múltiples llamadas en secuencia, es un fallo crítico. Cada llamada de herramienta inválida genera contexto incorrecto, lo que lleva a más llamadas erradas, y el modelo entra en espiral de confusión — lo que los ingenieros de Ubicloud llaman "acumulación de contexto nonsensical".

Lo que Ubicloud descubrió, y publicó el 20 de octubre de 2026, es que el motor de inferencia importa tanto como el modelo para la experiencia final del usuario. Y la solución — una técnica llamada constrained decoding, que vLLM introdujo como función oficial en la versión 0.31 — podría cambiar la relación entre los proveedores de modelos open-weight y los modelos que sirven.

Por qué las llamadas de herramientas fallan tan frecuentemente

Aquí está la paradoja: modelos como el Kimi K2 fueron entrenados específicamente para hacer tool calls con alta fidelidad. Durante el entrenamiento, vieron miles de ejemplos de llamadas de herramientas sintéticas en diversos formatos. Cuando ejecutas el modelo en la API original de Moonshot AI, la tasa de éxito es cercana al 100%. Pero cuando ejecutas el mismo modelo con vLLM — uno de los motores de inferencia más populares para modelos open-source — la tasa cae significativamente.

Ubicloud aisló el problema hasta el nivel del token. Lo que sucede es que el modelo, al generar una llamada de herramienta, necesita seguir un schema JSON que fue proporcionado en el prompt. Pero como los LLM son probabilísticos — no ejecutan un compilador ni un type checker — el modelo puede generar un nombre de herramienta que existe en el conjunto de entrenamiento, pero no está en la lista actual. Un campo llamado `city_name` cuando el schema espera `location`. Un bloque JSON envuelto en markdown code blocks cuando el parser no lo espera.

El problema se complica cuando combinas modelos. El blog de vLLM documentó un caso similar al testear el Kimi K2 en su propio motor: la tasa de éxito inicial cayó por debajo del 20%. Se identificaron tres problemas: el parámetro `add_generation_prompt` siendo descartado silenciosamente porque el tokenizer del Kimi lo declaraba vía `**kwargs`, que vLLM ignora por seguridad; un campo `content` vacío rompiendo la formatación del prompt; y un parser de tool-call IDs tan rígido que rechazaba IDs válidos en edge cases.

Cada uno de estos problemas fue corregido individualmente — con contribuciones directo al equipo de Moonshot AI y PRs enviados a vLLM. El resultado final fue de 83,57% de puntuación F1, lejos del 100% de la API nativa. Pero aún no era suficiente para workloads agênticos de producción.

Qué es constrained decoding y por qué importa

El constrained decoding es una técnica de decodificación que fuerza al modelo a generar solo tokens que sean sintácticamente válidos de acuerdo con un schema. En lugar de dejar que el modelo genere libremente y luego intentar validar el resultado, el constrained decoding actúa a nivel del tokenizer: en cada paso, restringe el vocabulario de tokens permitidos a lo que es compatible con el schema JSON de la herramienta.

Imagina que estás dictando algo a alguien, pero en lugar de dejar que la persona diga cualquier cosa, le das una lista exacta de palabras que puede usar en cada posición. Eso es exactamente lo que el constrained decoding hace con el JSON: en lugar de "genera un objeto JSON válido", dice "la siguiente palabra debe ser esta, y esta, y esta".

Ubicloud testó el constrained decoding con Kimi K2.6 y DeepSeek V4 Flash en el benchmark K2VV ToolCall de Moonshot AI — un benchmark de 2.000 requests que mide tanto cuándo el modelo decide llamar a una herramienta como si la llamada es sintácticamente correcta. Con el constrained decoding activado, ambos modelos alcanzaron 100% de schema accuracy. El número exacto que la API nativa alcanzaba.

Esto no es solo una victoria técnica. Es un cambio de paradigma en la forma en que pensamos sobre la calidad de los modelos open-source. Históricamente, la suposición era que la diferencia entre la API de un proveedor y la versión open-weight era marginal. Pero Ubicloud muestra que, para workloads agênticos, la diferencia es visible y medible.

Qué significa esto para el ecosistema

La historia del tool-calling en vLLM revela algo que pocos estaban dispuestos a admitir: la infraestructura de inferencia no es neutra. Dos deployments del mismo modelo, con los mismos weights, pueden producir resultados drásticamente diferentes dependiendo del motor de inferencia, del parser de tool-calls y de las configuraciones de decoding.

Para empresas que están construyendo agentes de IA con modelos open-source, esto es una lección práctica de que la elección del engine de inferencia es tan crítica como la elección del modelo. Si estás sirviendo el Kimi K2.6, el DeepSeek V4 Flash o cualquier otro modelo con capacidades agênticas robustas, rodar sin constrained decoding puede estar costando hasta 8% de éxito en llamadas de herramienta — y eso es solo la primera ronda.

El constrained decoding aún tiene limitaciones: hay bugs de interacción con otros recursos del vLLM, y no todos los modelos soportan la función nativamente. Pero la trayectoria es clara — a medida que los engines de inferencia maduran, la línea entre la API nativa y el deploy open-weight debería volverse cada vez más indistinguible.

Lo que queda es la constatación de que, en el mundo de los LLM, la calidad que llega al usuario final es producto del modelo, del engine, del parser y del schema — y optimizar solo uno de esos elementos ya no es suficiente.

Fuentes: Ubicloud, vLLM Blog, GitHub — vLLM Issue

✓ Fuentes independientes cruzadas y verificadas antes de la publicación