Los modelos de decisión están reemplazando silenciosamente al LLM en el bucle del agente

Cloudflare lanzó dos modelos en los primeros días de octubre que no escriben nada. Clef y Clef-flash leen una entrada más un conjunto de preguntas tipadas y devuelven una probabilidad para cada respuesta permitida. Sin prosa, sin cadena de pensamiento, sin tokens generados uno a la vez. Solo una elección estructurada.

Eso suena a un retroceso hasta que miras los números. En BANKING77, un benchmark estándar de clasificación de intenciones, Clef obtiene un macro-F1 de 94,20 frente a 79,74 de Jev, el modelo que introdujo la categoría de modelos de decisión. Clef-flash, la versión más pequeña de 9B, logra 90,93. La diferencia de latencia es aún mayor. Clef-flash devuelve una respuesta mediana en 38,8 milisegundos; Jev tarda 524,1 milisegundos. Cloudflare afirma que Clef supera a Jev en siete de diez benchmarks de decisión.

Ambos modelos se distribuyen bajo Apache 2.0 en Hugging Face, y ambos son compatibles con la API de Jev, así que los equipos ya construidos alrededor de Jev pueden cambiar sin reescribir sus integraciones. El hilo de Hacker News alcanzó 602 puntos y más de 200 comentarios en un día.

Por qué un modelo más pequeño puede ganar en una tarea más acotada

Los modelos de decisión tienen una forma distinta de los chatbots a los que recurren la mayoría de los desarrolladores. Un modelo de lenguaje grande genera texto abierto. Un modelo de decisión lee un estado y una lista de respuestas permitidas, y luego puntúa cada una. Typesafe AI fue pionera de la categoría con Jev, que mostró que las tareas de enrutamiento o clasificación de agentes no necesitan un modelo de propósito general de 400B. Necesitan una salida acotada, barata y rápida.

Clef de Cloudflare está construido sobre Qwen3.8-27B y usa una arquitectura de solo prefill que puntúa las opciones del esquema en paralelo en lugar de generar tokens de forma secuencial. Ahí es donde se va la latencia. Un modelo general tiene que emitir una respuesta token tras token; un modelo de decisión solo tiene que leer la pregunta y decidir.

También hay una diferencia de contexto que vale la pena señalar. Clef acepta entrada multimodal dentro de una ventana de 64k tokens, que abarca texto, JSON, imágenes y video. Jev solo maneja texto, con 32k. Para un agente que enruta a partir de una captura de pantalla o un PDF, eso no es una ventaja menor.

La primera objeción de la comunidad fue la correcta

La réplica más útil en la discusión de Hacker News no cuestionó los benchmarks. Cuestionó la etiqueta. «Pesos abiertos, no código abierto», escribió un comentarista. Los pesos tienen una licencia permisiva, pero los datos de entrenamiento y el pipeline no se publicaron, así que el modelo no se puede reproducir desde cero.

Esa distinción importa para cualquiera que decida dónde ejecutar esto. Clef se entrenó a partir de un punto de partida propietario de Qwen. Los pesos se pueden descargar y alojar gratis, lo que supone un ahorro real de costos, pero no son auditables como el software de código abierto. Los equipos con políticas estrictas de revisión de la cadena de suministro deberían leer la licencia y la tarjeta del modelo antes de asumir que la etiqueta Apache 2.0 resuelve la cuestión.

La misma semana, Amazon puso uno en tu portátil

Cloudflare no estaba solo. Strands Labs de AWS publicó Strands Decider 2B, un modelo de decisión abierto con pesos y scripts de entrenamiento, diseñado para ejecutarse localmente y devolver opciones con puntuación de confianza en decenas o unos pocos cientos de milisegundos. Cloudflare también añadió un servicio de ajuste fino con RL para sus modelos de decisión en Workers AI.

El patrón es un modelo pequeño que hace bien un trabajo y se ejecuta cerca de los datos. Si puedes filtrar una llamada a una herramienta, verificar que una solicitud esté fundamentada o decidir si escalar, con un modelo de 2B en 40 milisegundos, la economía de enrutar un agente a través de un modelo de frontera en cada paso empieza a parecer un desperdicio.

El paradigma que introdujo Jev, y por qué tardó un año en calar

El Jev de Typesafe AI hizo una afirmación que era fácil de descartar cuando se lanzó: la mayor parte de lo que los agentes le piden a un modelo no es generación, es clasificación. Enruta este ticket, elige esta herramienta, decide si esta acción necesita aprobación. Para esos trabajos, un modelo que escribe párrafos hace mucho más trabajo del que requiere la tarea.

Jev demostró que el enfoque específico podía superar a un modelo general en sus propios benchmarks. Lo que no pudo hacer fue que la categoría pareciera urgente. Un solo proveedor que vende un modelo de decisión es una curiosidad. Que Cloudflare lance una versión Apache 2.0 compatible con la API de Jev es una situación distinta, porque ahora cualquiera puede alojarla, inspeccionar la licencia e integrarla sin reescribir nada. Que Amazon llegue la misma semana con su propio decisor abierto convierte una curiosidad en una categoría.

El momento coincide con cómo se están construyendo realmente los agentes. La primera generación de frameworks de agentes enrutaba cada paso a través de un único modelo grande porque era lo más simple. A medida que esos sistemas pasan a producción, los costos de enrutamiento se convierten en lo que los equipos notan. Dividir el bucle en un modelo de lenguaje para las partes que necesitan lenguaje y un decisor para las que no lo necesitan es la solución obvia, y hizo falta el lanzamiento abierto de un buen decisor para que fuera práctico.

El ángulo del ajuste fino

Cloudflare también añadió un servicio de ajuste fino con RL para sus modelos de decisión en Workers AI, lo que señala hacia dónde se dirige la categoría después. Un decisor genérico es útil. Un decisor ajustado con tu propio historial de enrutamiento, tus propias reglas de escalado y tu propia noción de alcance es más útil, porque aprende el límite que le importa a tu negocio.

Esa es también la parte que debería hacer que los equipos tengan cuidado. Un decisor ajustado codifica tus decisiones pasadas, incluidas las malas. Si tu equipo solía aprobar reembolsos que debería haber escalado, el modelo aprenderá ese patrón y lo aplicará más rápido de lo que un humano podría jamás. La calibración tiene doble filo.

Dónde encaja esto en un pipeline de agentes

Imagina un agente de soporte que gestiona un reembolso. Antes de que pueda llamar a la herramienta de reembolso, algo tiene que responder preguntas como: ¿esta solicitud está dentro del alcance?, ¿la cuenta del cliente lo permite?, ¿esto necesita a un humano? Esas son preguntas de decisión con un conjunto fijo de respuestas. Un modelo de decisión puede devolver las probabilidades, y el agente actúa según un umbral.

El perfil de costos es lo importante. Enrutar cada una de esas comprobaciones a través de un modelo de 400B cuesta dinero por llamada y añade cientos de milisegundos de latencia. Descargarlas a un decisor local de 2B o 9B reserva el modelo de frontera para las partes que realmente necesitan lenguaje: escribir la respuesta, resumir un hilo largo, manejar un caso ambiguo. Los presupuestos y los presupuestos de latencia se reducen.

Hay una trampa. Un modelo de decisión devuelve una probabilidad, y las probabilidades pueden estar equivocadas con confianza. Si automatizas la aprobación de un reembolso con una puntuación de 0,92, has trasladado el riesgo de la redacción del modelo a tu umbral. La calibración, no la precisión bruta, se convierte en el número a vigilar. La latencia y el costo son fáciles de medir; un 0,9 bien calibrado es más difícil.

Qué observar a continuación

Las herramientas ya están siguiendo a los modelos. llama.cpp añadió soporte para modelos de decisión, y Perplexity y Hugging Face están apostando en la misma dirección. Si la categoría se mantiene, la pregunta interesante deja de ser qué modelo de decisión gana un benchmark y pasa a ser qué decisiones estás dispuesto a entregar a una probabilidad.

Para quienes construyen agentes, el movimiento práctico es auditar el bucle y encontrar los pasos que nunca necesitaron texto fluido. La clasificación, el enrutamiento, la selección de herramientas y las comprobaciones previas a la acción son los candidatos habituales. Esos son los pasos donde una respuesta de 40 milisegundos sobre un conjunto fijo de opciones puede reemplazar una generación lenta y costosa. El resto del agente puede quedarse con el modelo que ya usa.