Dos modelos de decisión, una interfaz
Clef-Flash y Jev son dos modelos de decisión. Cada uno recibe un estado —la situación sobre la que debe razonar— más un esquema de preguntas tipadas, y devuelve una probabilidad para cada opción permitida en una sola pasada. Ninguno es un chatbot, y ninguno escribe prosa para explicarse. Ambos puntúan un espacio de respuestas que tú defines de antemano.
Clef-Flash es el modelo de latencia de 9B, entrenado a partir de Qwen3.5-9B y publicado bajo la licencia Apache 2.0, con un contexto de 64k tokens y un codificador de visión integrado. Jev es otro modelo de decisión construido sobre la misma interfaz conceptual: entra un estado, entran preguntas tipadas, salen probabilidades. Los nombres cambian, pero el contrato contra el que programa un desarrollador es del mismo tipo.
Ese contrato compartido es la razón por la que merece la pena compararlos. Si un sistema devolviera prosa y el otro probabilidades, estarías comparando dos productos distintos. Aquí comparas dos modelos que responden al mismo tipo de pregunta de la misma manera, lo que traslada la conversación a las diferencias operativas.
Por qué la comparación es justa
Muchas comparaciones de modelos no son justas, porque los dos sistemas aceptan entradas distintas, producen salidas distintas u optimizan objetivos distintos. Esta se acerca a la justicia por construcción. Ambos modelos leen un estado, ambos aceptan un esquema de preguntas tipadas y ambos devuelven una probabilidad por cada opción permitida en una sola pasada.
Como la forma de la salida es la misma, el mismo código de aplicación puede llamar a cualquiera de los dos. Escribes tu esquema una vez, lo validas una vez y después tratas el modelo como una opción de configuración en lugar de una decisión de arquitectura. Eso reduce de forma notable el coste de cambiar, y es lo que hace práctica una evaluación en paralelo.
Hay una advertencia honesta. Una interfaz compartida no garantiza un comportamiento idéntico. Dos modelos pueden devolver probabilidades y aun así diferir en lo bien calibradas que están, en cómo tratan opciones ambiguas y en cómo se comportan con estados largos o poco habituales. La interfaz hace justa la comparación; no hace que los resultados sean intercambiables en cualquier carga de trabajo.
La cuestión de la latencia
La latencia suele ser lo primero que nota un equipo. Las cifras publicadas sitúan a Clef-Flash en torno a 39 ms de latencia mediana y unos 122 ms en el p95, y se reporta que Clef-Flash es más de diez veces más rápido que Jev en tareas de decisión comparables. Son cifras publicadas, y describen los modelos en las cargas que midió el editor, no en cada carga que puedas ejecutar tú.
La latencia importa sobre todo cuando la decisión se encuentra en una ruta síncrona. Una elección de enrutado dentro de un bucle de agente, una barrera de moderación delante de un botón de publicar o una etiqueta de clasificación mostrada mientras el cliente espera: todas se acumulan. Si una petición se dispara repetidamente dentro de una interacción, una diferencia de unos cientos de milisegundos por llamada se convierte en segundos por sesión.
La latencia absoluta también depende de cosas que controlas. La longitud del contexto, el tamaño del esquema, la composición del lote, la concurrencia y el hardware mueven el número. Trata cualquier mediana publicada como evidencia orientativa sobre la familia de modelos, no como una promesa sobre tu despliegue. Mide p50, p95 y p99 con tu propio tráfico antes de comprometerte.
Cómo pensar en precisión y exactitud
Más rápido no es automáticamente mejor. Una decisión equivocada devuelta en 40 ms puede costar mucho más que una correcta devuelta en 400 ms, sobre todo cuando la decisión controla dinero, seguridad o acceso. La pregunta correcta nunca es simplemente qué modelo es más rápido; es qué modelo es lo bastante rápido y a la vez lo bastante exacto para esta decisión concreta.
La salida probabilística es lo que hace esto medible. Como cada llamada devuelve una probabilidad por opción permitida, puedes aplicar umbrales conservadores, enviar los casos de baja confianza a una cola de revisión o escalar solo los inciertos a un modelo mayor. Clef, el modelo de precisión de 27B, es un destino de escalado evidente dentro de la misma familia.
Cuidado con una suposición que parece natural pero no está garantizada. Un modelo más grande o más lento no es automáticamente más exacto en tu tarea, y la comparación de latencia publicada no dice nada sobre qué modelo toma mejores decisiones con tus datos. La calidad es una propiedad del emparejamiento entre un modelo y una carga de trabajo, y solo tu propia evaluación puede establecerla.
Despliegue y VRAM
Si ejecutas en local, la memoria es una restricción dura antes que cualquier otra cosa. Clef-Flash necesita unos 41 GB de VRAM, mientras que el modelo Clef, más grande, necesita alrededor de 85 GB. Los requisitos de Jev dependen de sus propios pesos y de su pila de servicio, así que consulta su documentación para las cifras actuales en lugar de suponer un número.
La distribución también condiciona la decisión. Clef y Clef-Flash están disponibles a través de Workers AI, Ollama, Hugging Face —incluidas las versiones MLX de 4 bits— y OpenRouter. La instalación con Ollama es un solo comando, como ollama pull clef-flash. Usar un endpoint alojado elimina por completo la cuestión de la VRAM, a un precio publicado de unos 0,09 dólares por millón de tokens de entrada para Clef-Flash.
Dónde vive la decisión importa tanto como el modelo. Los equipos con requisitos de residencia de datos o de cumplimiento pueden verse obligados a ejecutar la inferencia dentro de su propio perímetro, lo que convierte la huella local en el factor decisivo. La cuantización puede hacer que un modelo entre en el rango de hardware más pequeño, pero también puede alterar tanto la velocidad como la exactitud, así que merece su propia evaluación en lugar de tratarse como una ventaja gratuita.
Un esquema compartido significa portabilidad
El esquema de preguntas tipadas es la parte más portable de todo el diseño. Como ambos modelos aceptan el mismo tipo de esquema, puedes evaluar las mismas preguntas contra los dos sin escribirlas dos veces. Eso reduce el coste de la comparación a un banco de evaluación y un interruptor de configuración en lugar de una reescritura.
De ahí se desprende un patrón práctico. Define tu esquema una vez, toma una muestra de unos cientos de estados reales y ejecuta ambos modelos sobre las mismas muestras. Guarda las probabilidades por opción junto a las respuestas correctas conocidas y compáralas. El esquema no cambia entre ejecuciones, así que cualquier diferencia que observes es una diferencia entre los modelos, no entre dos formatos de pregunta.
La portabilidad también te protege con el tiempo. Si tu carga empieza siendo crítica en latencia y luego pasa a ser crítica en precisión, puedes cambiar de modelo sin reescribir la validación, el enrutado ni el registro. La frontera de la decisión se mueve; la aplicación que la rodea no.
Cómo evaluar tu propia carga de trabajo
Las evaluaciones publicadas son un punto de partida, no un veredicto. La única evaluación que responde a tu pregunta es la que se construye con tus propios estados, tu propio esquema y tu propia definición de una buena decisión. Empieza reuniendo una muestra representativa y etiquetando la opción correcta de cada estado, incluidos los casos ambiguos que de verdad aparecerán en producción.
Mide más de una cosa. La latencia debe capturarse como una distribución —p50, p95 y p99 bajo concurrencia realista—, no como una única media. La calidad debería ir más allá de la exactitud bruta: las probabilidades por opción te permiten calcular métricas de calibración como la puntuación de Brier o el error de calibración esperado, que indican si una confianza de 0,9 significa de verdad nueve veces de cada diez.
Vigila las interacciones que una prueba pequeña puede ocultar. Los contextos largos tienden a aumentar la latencia, las opciones ambiguas o solapadas tienden a perjudicar la exactitud, y las clases desequilibradas pueden hacer que una puntuación agregada parezca sana mientras falla una clase rara pero importante. Prueba con tu distribución real, reserva un conjunto de validación que no ajustes y vuelve a ejecutar la evaluación cada vez que cambie el esquema.
Cuándo elegir Clef-Flash
Clef-Flash es la opción natural cuando la decisión se encuentra en una ruta crítica en latencia y de alto volumen. El enrutado en tiempo real, la clasificación de primera pasada, las barreras de moderación y las experiencias interactivas se benefician de que el modelo responda en decenas de milisegundos en lugar de cientos, porque el coste de la latencia se multiplica en cada petición.
También encaja en cargas donde importa el coste por decisión y una pequeña diferencia de exactitud es tolerable. Con un precio publicado cercano a 0,09 dólares por millón de tokens de entrada, ejecutar una primera pasada de forma amplia y reservar la revisión humana o de un modelo mayor para los casos de baja confianza suele salir más barato que enrutar todo por un modelo más pesado.
Por último, Clef-Flash es un buen punto de partida cuando todavía estás descubriendo la forma del problema. Como el esquema es portable, puedes prototipar con el modelo rápido, aprender qué decisiones son fáciles y cuáles no, y escalar los casos difíciles después sin cambiar tu aplicación.
Cuándo elegir Jev
Jev puede ser la mejor opción cuando tu propia evaluación muestra que cumple tu nivel de exactitud con una latencia y un coste aceptables. Si supera los requisitos, la comparación de velocidad publicada deja de ser relevante para tu carga, y la decisión debe recaer en aquello que tu evaluación mide directamente.
La familiaridad operativa es un factor legítimo. Si tu equipo ya ejecuta Jev, entiende su comportamiento de servicio y tiene herramientas a su alrededor, el coste de migrar puede superar una ganancia de latencia que no necesitas estrictamente. El encaje con la infraestructura forma parte del coste total de propiedad.
Jev también merece consideración cuando la carga no está limitada por la latencia. El procesamiento por lotes, el análisis fuera de línea y la clasificación nocturna pueden tolerar respuestas más lentas, lo que desplaza el equilibrio hacia el modelo que produce las mejores decisiones en lugar de las más rápidas.
Una forma práctica de elegir
Empieza por la carga de trabajo, no por el modelo. Anota si la decisión es síncrona o por lotes, qué presupuesto de latencia permite la experiencia que la rodea, cuánto cuesta un error y si la inferencia debe ejecutarse dentro de tu propio perímetro. Esas cuatro respuestas eliminan la mayor parte del espacio antes de ejecutar ninguna evaluación.
Después mide ambos modelos con el mismo esquema y los mismos estados etiquetados. Compara distribuciones de latencia, calibración y exactitud en paralelo. Recurre al modelo más rápido cuando domina la latencia y la diferencia de exactitud es aceptable; recurre al modelo que favorece tu evaluación cuando domina la precisión. Ninguno es universalmente mejor, y la respuesta honesta depende de la carga que tengas delante.
Puedes explorar la propia interfaz en el playground, donde un estado y unas pocas preguntas tipadas producen una probabilidad para cada opción permitida en una sola pantalla. Si prefieres leer primero, la documentación cubre la forma de la petición y de la respuesta, y el artículo sobre las evaluaciones explica cómo se producen las cifras publicadas.