El Tool Calling de DeepSeek V4.1 Flash llega a vLLM: qué rompieron las etiquetas con espacios

DeepSeek V4.1 Flash está disponible de forma general desde el 10 de septiembre de 2026, y durante los primeros doce días de su vida el modelo tuvo una carencia de la que nadie escribió: podía razonar, podía ver imágenes, podía sostener un millón de tokens de contexto, y no podía llamar a una herramienta de forma fiable a través del stack de serving abierto más utilizado. Esa carencia ya está resuelta en vLLM — no con una flag de configuración, sino con una reescritura del parser. Dos pull requests llevan el trabajo, y la razón por la que eran necesarios es la parte interesante.

La versión corta: DeepSeek V4.1 Flash emite sus llamadas a herramientas en un formato de etiquetas que el detector existente de DeepSeek V4 no reconoce, así que en una implementación estándar de vLLM el marcado de las llamadas a herramientas llega como texto normal en lugar de como salida estructurada. Nada da error. El modelo parece simplemente haberse negado a llamar a la función. Si has estado probando bucles de agentes con un DeepSeek V4.1 Flash autoalojado y llegando a la conclusión de que el modelo es malo con las herramientas, esto es muy probablemente lo que estabas viendo.

¿Qué cambió realmente en la pila de servicio?

El análisis de llamadas a herramientas de vLLM para los modelos DeepSeek ha residido durante un tiempo en dos lugares: un frontend de Python y un frontend de Rust más reciente, con el trabajo a nivel de gramática delegado en el proyecto XGrammar. Incorporar la compatibilidad con V4.1 Flash implicó portar la conversión de C++ deepseek_xml dentro de XGrammar al constructor de Rust, y luego conectar la codificación propia del modelo al directorio de tokenizadores de vLLM.

• El trabajo del frontend de Rust es el PR #56235, que porta la conversión de XGrammar C++ deepseek_xml al builder de Rust. Incluye 18 pruebas nuevas específicamente para V4.1, y las suites existentes completas —472 pruebas en vllm-parser y 326 en vllm-chat— se mantienen en verde.

• El trabajo en el frontend de Python es el PR #56408, que todavía es un borrador. Depende de que primero se integre un cambio upstream en XGrammar (mlc-ai/xgrammar#885), y reporta 110 pruebas superadas con esa dependencia aplicada.

• El nuevo módulo de codificación es vllm/tokenizers/deepseek_v41_encoding.py — un archivo separado en lugar de una rama dentro de la codificación V4, lo que indica que la gramática de etiquetas difiere genuinamente en lugar de simplemente extenderse.

• La invocación es explícita: --tool-parser deepseek_v41. No existe un mecanismo de reserva con detección automática que haga lo correcto en silencio.

Las etiquetas espaciadas son toda la historia.

La razón por la que existe un nuevo analizador en lugar de una expresión regular ampliada son los espacios en blanco. DeepSeek V4.1 Flash escribe sus etiquetas de herramienta DSML con espacios entre los tokens. El patrón del detector de V4 espera la forma sin espacios, por lo que no coincide, y una coincidencia fallida en un analizador de llamadas a herramientas es silenciosa por diseño: el texto se deja pasar como contenido en lugar de lanzar una excepción.

Ese modo de fallo merece que nos detengamos en él porque es el tipo más costoso. Un analizador que lanza una excepción se arregla en una tarde. Un analizador que devuelve una cadena bien formada que contiene marcado que quien llama nunca pidió parece un problema de calidad del modelo, y los equipos responden a él como responderían a un problema de calidad del modelo: prueban distintos prompts, añaden ejemplos, cambian de modelo. Doce días son tiempo suficiente para que mucho de eso haya ocurrido en privado.

También significa que la solución no es una simple perilla de ajuste. No puedes salir del problema a base de prompts si el detector no coincide con el formato de salida de tu modelo, y no puedes arreglarlo en el cliente mediante posprocesamiento, porque para cuando el texto llega a tu cliente la estructura ya se ha perdido. Tiene que ocurrir en la pila de servicio, que es exactamente donde está ahora.

Por qué esto importa más para V4.1 Flash de lo que importaba para V4

La llamada a herramientas no es un simple extra opcional para este modelo en concreto. DeepSeek V4.1 Flash es un modelo de mezcla de expertos de 552.000 millones de parámetros, con 8.000 millones de parámetros activos en la entrada y 16.000 millones activos en la salida, una ventana de contexto de 1M de tokens y una salida máxima de 384K tokens. El reparto de activación es la clave: el modelo está construido para tomar una entrada grande —un repositorio, un conjunto de documentos, un rastro de herramientas extenso— y emitir una respuesta estructurada y larga. Esa es la forma de un agente, no la de un chat.

El resto de la especificación de lanzamiento apunta en la misma dirección. Pesos con licencia MIT, 890 bytes de caché KV por token, 45 billones de tokens de preentrenamiento, visión nativa. La cifra de la caché KV es la que importa operativamente con un contexto de 1M: es lo que hace que mantener residente una transcripción larga de agente sea asequible, y es la razón por la que el modelo es plausible como el trabajador barato en un bucle que supervisa un modelo más caro.

Lo que convierte la brecha de doce días en las llamadas a herramientas en un costo real y no en una nota al pie. Un modelo cuyo argumento económico se basa en ser el ejecutor de gran volumen de un pipeline de agentes vale muy poco si el pipeline no puede obtener de él una llamada estructurada.

¿Qué sigue abierto?

El estado real de las cosas, a 22 de septiembre de 2026:

• La ruta del frontend de Rust (PR #56235) es la que tiene cobertura de pruebas completa tanto en los nuevos casos de V4.1 como en las suites preexistentes. Si usas una build de vLLM que lo incluye, el parser está disponible para ti hoy.

• La ruta del frontend de Python (PR #56408) es un borrador y tiene una dependencia externa. Si tienes fijada una compilación anterior al cambio de XGrammar, el frontend de Python aún no te proporcionará el parseo de herramientas de V4.1.

• Como la invocación es explícita, un despliegue que actualice vLLM pero no cambie sus opciones de lanzamiento mantendrá el comportamiento anterior. Que el parser exista y que el parser se utilice son dos cosas distintas.

• Todavía no hay evidencia pública de que se haya ejecutado una prueba comparativa independiente de invocación de herramientas contra V4.1 Flash con el nuevo parser ya implementado. Lo que sabemos es que la infraestructura funciona y que las pruebas pasan. Que la calidad de invocación de herramientas del modelo sea buena es una cuestión aparte que la fusión no responde.

Ese último punto es el que hay que retener. Una corrección del parser hace pasar al modelo de «no se puede evaluar» a «se puede evaluar». Es un requisito previo para un veredicto, no el veredicto.

Si no quieres ejecutar tú mismo la pila de servicio

Hay un camino más corto. DeepSeek V4.1 Flash está disponible a través del endpoint de OrcaRouter para ello, lo que significa que el comportamiento de llamada a herramientas llega como una llamada API normal en lugar de como un problema de compilación: sin una versión de XGrammar que emparejar, sin un frontend que elegir, sin una bandera de inicio que recordar. La razón por la que eso importa aquí en concreto es que la corrección se implementó en dos lugares con distinta madurez, y un endpoint alojado reduce esa decisión a nada.

La misma clave también llega a el resto de los modelos con los que estarías comparando, que es la propiedad útil cuando la pregunta no es "¿es correcto este analizador?" sino "¿es este modelo lo suficientemente bueno para mi bucle?". Puedes poner DeepSeek V4.1 Flash detrás de una regla de enrutamiento como el ejecutor barato y transferirlo a un modelo más potente cuando la llamada falle, sin un segundo contrato ni un segundo SDK. Probar un modelo cuyo soporte de llamada a herramientas tiene dos semanas de antigüedad es exactamente la situación para la que existe la conmutación por error automática.

Qué ver a continuación

Tres cosas convertirían esto de una historia de fontanería en un veredicto:

• El PR #56408 sale del borrador, lo que haría real la ruta del frontend de Python y pondría fin a la situación de soporte de dos niveles.

• Una evaluación independiente de agente o de llamada a herramientas ejecutada contra V4.1 Flash en un stack de servicio fijo. El modelo lleva doce días disponible y el parser ha sido utilizable durante menos tiempo que eso, así que cualquier puntuación de llamada a herramientas que veas citada para él en este momento merece que se pregunte al respecto — la configuración importa tanto como el modelo.

• Si otros stacks de servicio siguen su ejemplo. vLLM es el que tiene PRs públicos; el problema de las etiquetas con espacios no es específico de vLLM, así que cualquier stack que haya adoptado el detector V4 sin volver a derivarlo de la salida de V4.1 tiene el mismo fallo silencioso presente en él.

Hasta que llegue el primero de ellos, el resumen preciso es limitado y vale la pena decirlo sin rodeos: DeepSeek V4.1 Flash es un modelo GA con pesos MIT, un contexto de 1M y un techo de salida de 384K, y sus llamadas a herramientas ahora funcionan en la ruta de Rust en vLLM con un flag de parser explícito. Eso es un paso real y todavía no es un resultado.