Spots 
Un modelo de lenguaje de decenas de miles de millones de parámetros tarda demasiado, y cuesta demasiado, solo para resolver una clasificación zero-shot como decidir a qué cola de soporte va un ticket. Jeff, un proyecto independiente publicado en GitHub, resuelve esa misma decisión con un modelo de apenas 0.8B de parámetros en 22 milisegundos sobre una RTX PRO 6000.
El modelo nunca vio esas categorías exactas durante el entrenamiento, y aun así elige entre ellas con una probabilidad calibrada, en una sola pasada hacia adelante.
Jeff-Qwen3.5-0.8B responde en 22 ms sobre una RTX PRO 6000 y 28 ms en Apple M4 Max con MLX.- Un fine-tune de navegación por voz subió la precisión de 31,7% a 95,8% en menos de media hora sobre una GPU.- El endpoint /v1/systemone acepta preguntas tipo choice, noul y score en una sola petición HTTP.- Todo el entrenamiento corre en hardware local: sin GPUs en la nube ni salidas de modelos cerrados en los datos sintéticos.- Jeff-Qwen3.5-2B alcanza 83,1 de puntaje promedio, por encima del 83,0 publicado por Jev. ¿Qué es la clasificación zero-shot?
La clasificación zero-shot es la capacidad de un modelo de asignar una entrada a una categoría que nunca formó parte de su entrenamiento, describiendo las opciones en lenguaje natural al momento de la consulta. Jeff aplica esto a decisiones cerradas: devuelve una probabilidad calibrada por opción en una sola pasada del modelo.
El nombre de su endpoint, /v1/systemone, no es casual. Los tres tipos de pregunta que acepta (choice, noul y score) imitan lo que en psicología se conoce como sistema 1, la respuesta rápida e intuitiva, frente al razonamiento lento y deliberado de un modelo grande como Jev. Jeff no genera una explicación paso a paso, compara las opciones descritas y entrega un número por cada una. Jeff responde en 22 ms sobre una RTX PRO 6000, sin salir del servidor local. Por qué un modelo tan chico compite con los grandes
Los números publicados en el repositorio son el argumento central. Sin fine-tune, Qwen3.5-0.8B saca un promedio de 45.3 puntos en cinco benchmarks públicos. Con el fine-tune de Jeff, el mismo modelo base sube a 79.1, casi el doble, y se acerca al 83.0 que reporta Jev, un modelo bastante más grande.
La ganancia no es pareja. En Financial PhraseBank, un benchmark de clasificación de sentimiento financiero, Jeff-Qwen3.5-0.8B llega a 96.4 puntos, por encima del 77.0 publicado por Jev. Pero en BBH (Big-Bench Hard), un benchmark de razonamiento, Jeff se queda en 64.0 frente a los 94.3 de Jev. El patrón se repite en JudgeBench y en la versión difícil de JevBench, ahí es donde el tamaño sí pesa.
La elección tiene un argumento de costo además del de velocidad. Cada llamada a un modelo grande vía API suma latencia de red y un cobro por token de entrada y salida. Un modelo de 0.8B corriendo en el mismo servidor que la aplicación elimina la llamada de red por completo y solo consume el cómputo local de una pasada del modelo, al precio de perder la profundidad de razonamiento de un modelo más grande.
Esa distinción importa para decidir cuándo usarlo. Un clasificador sin ejemplos previos como Jeff funciona bien cuando la tarea es discriminar entre opciones bien descritas, no cuando hace falta razonar sobre una cadena de pasos. Jeff no es un reemplazo de Jev, sino un especialista rápido para decisiones cerradas. Cómo funciona Jeff por dentro
Todo el entrenamiento ocurre en hardware local, sin depender de GPUs en la nube. Los datos sintéticos de entrenamiento los escribe un modelo abierto, Qwen3.8-Flash-Next, corriendo en dos DGX Sparks. Un modelo cerrado se usó únicamente para revisar la calidad de una muestra de esos datos sintéticos, nunca para generar contenido que terminara en el set de entrenamiento.
Un modelo de lenguaje de decenas de miles de millones de parámetros tarda demasiado, y cuesta demasiado, solo para resolver una clasificación zero-shot como decidir a qué cola de soporte va un ticket.