Cuando los benchmarks no cuentan toda la historia
Durante las últimas semanas he estado probando diferentes modelos de lenguaje con un objetivo bastante concreto: encontrar modelos que pueda ejecutar en mi propia infraestructura y que sean realmente útiles en el trabajo diario, especialmente cuando desarrollo software.
Dos de los que más me han llamado la atención han sido Qwen3.8 27B y Ornith 1.5 35B-A3B. Sobre el papel son modelos bastante diferentes y, después de utilizarlos durante un tiempo, esas diferencias se perciben todavía más en el uso real.
No pretendo hacer aquí un benchmark científico ni decidir cuál de los dos es objetivamente mejor. Lo que quiero contar es algo que para mí resulta bastante más interesante: cómo se comportan cuando realmente intento trabajar con ellos.
Qwen3.8 27B: mucha capacidad, quizá demasiada reflexión
Mi primera impresión con Qwen3.8 27B fue excelente y, en términos de capacidad, sigue pareciéndome un modelo realmente bueno.
Comprende bien instrucciones relativamente complejas, analiza código con bastante solvencia y es capaz de desenvolverse en tareas que requieren planificación, razonamiento o trabajar con bastante contexto.
Es uno de esos modelos que, por momentos, hacen olvidar que se están ejecutando de forma local.
Sin embargo, después de utilizarlo durante más tiempo empecé a encontrar un comportamiento que en determinadas situaciones termina perjudicando mi experiencia de uso: su tendencia a razonar demasiado.
Cuando una tarea realmente necesita análisis profundo, esta característica puede ser una ventaja. Qwen puede estudiar alternativas, revisar decisiones y dedicar bastante tiempo a comprender un problema antes de actuar.
Pero no todas las tareas de programación necesitan ese nivel de reflexión.
Muchas veces simplemente quiero modificar una función, corregir un pequeño error, generar una consulta SQL, localizar dónde introducir un cambio o realizar una modificación concreta en un proyecto.
En esos casos he llegado a encontrar desproporcionada la cantidad de razonamiento respecto a la complejidad del problema.
Y aquí aparece una paradoja interesante: un modelo puede ser técnicamente muy capaz y, al mismo tiempo, resultar menos cómodo para determinadas formas de trabajo.
Más razonamiento no significa necesariamente una mejor experiencia de usuario.
Ornith 1.5: una sorpresa muy agradable
Después empecé a trabajar con Ornith 1.5 35B-A3B y la experiencia ha sido bastante diferente.
Ornith utiliza una arquitectura Mixture-of-Experts (MoE). Aunque el modelo dispone de un número elevado de parámetros totales, solo una fracción de ellos participa activamente en el procesamiento de cada token.
Este planteamiento resulta especialmente interesante para inferencia porque permite combinar una capacidad global elevada con un coste computacional mucho menor que el que cabría esperar de un modelo denso de tamaño equivalente.
Lo primero que me llamó la atención fue su velocidad.
- TTFT: 1,74 segundos
- Velocidad de generación: 129 tokens/s
- Rendimiento total observado: 46,8 tokens/s
Son cifras obtenidas en mis propias pruebas y dependen, por supuesto, de la configuración utilizada, pero sirven para transmitir la sensación general: Ornith responde rápido.
Sin embargo, después de utilizarlo durante más tiempo, la velocidad ha dejado de ser lo que más valoro del modelo.
Lo que realmente me está gustando es lo cómodo que resulta trabajar con él.
Comprende bien lo que quiero hacer, se comporta de forma razonable trabajando con código y no tengo constantemente la sensación de estar esperando una larga reflexión antes de que empiece a resolver una tarea relativamente sencilla.
También he ido cambiando mi opinión sobre su comportamiento en español. Mis primeras impresiones fueron algo más prudentes, pero después de utilizarlo durante más tiempo no estoy encontrando problemas relevantes para trabajar normalmente en español.
La comprensión de instrucciones es suficientemente buena como para utilizarlo directamente sin necesidad de adaptar constantemente los prompts o cambiar al inglés.
Para mí esto es importante porque busco un modelo con el que pueda trabajar de forma natural, no solamente uno que obtenga buenas puntuaciones en pruebas de programación.
El comportamiento del modelo importa tanto como su capacidad
Esta comparación me está haciendo prestar cada vez más atención a algo que normalmente queda fuera de los benchmarks: la personalidad operativa del modelo.
Dos modelos pueden ser capaces de resolver correctamente el mismo problema y, sin embargo, ofrecer experiencias completamente diferentes durante el proceso.
Uno puede analizar durante mucho tiempo antes de actuar. Otro puede identificar rápidamente lo necesario y empezar a trabajar. Uno puede ser especialmente útil cuando necesitas explorar un problema complejo y otro resultar mucho más cómodo cuando estás realizando cambios iterativos sobre un proyecto.
Cuando utilizas un modelo esporádicamente estas diferencias pueden parecer pequeñas.
Cuando trabajas con él durante horas, dejan de serlo.
La latencia, la velocidad, cuánto razona, cómo utiliza las herramientas y la forma en la que sigue las instrucciones terminan siendo parte fundamental de la calidad percibida.
Denso frente a MoE
También resulta interesante comparar las dos arquitecturas.
Qwen3.8 27B es un modelo denso. Durante la inferencia participa el conjunto de parámetros del modelo, lo que permite aprovechar toda su capacidad en cada token pero también implica un coste computacional elevado.
Ornith 1.5 35B-A3B, por el contrario, utiliza una arquitectura MoE donde solamente una parte de sus expertos permanece activa para cada token.
Eso ayuda a explicar una de las características que más me atraen de Ornith: la relación entre capacidad y velocidad.
No significa que un modelo MoE sea automáticamente mejor que uno denso. La inferencia depende de muchos factores: memoria disponible, ancho de banda, cuantización, contexto, implementación utilizada, distribución entre GPUs y características del propio hardware.
Pero para quienes experimentamos con modelos locales, este tipo de arquitecturas resulta especialmente interesante porque ofrece una forma diferente de obtener mucha capacidad sin asumir necesariamente el mismo coste de cómputo en cada token.
Los benchmarks no cuentan toda la historia
Cuanto más pruebo modelos diferentes, menos me interesa saber cuál ocupa la primera posición de una clasificación.
Los benchmarks son útiles. Permiten comparar modelos bajo unas condiciones determinadas y descubrir rápidamente cuáles merece la pena probar.
Pero existe una diferencia enorme entre obtener una buena puntuación en un benchmark y ser agradable de utilizar durante varias horas.
Una prueba puede decirme si un modelo resuelve un determinado problema de programación. No necesariamente me dice cuánto tardará en empezar a responder, cuánto razonamiento generará antes de actuar, cómo se desenvolverá dentro de un agente, cómo utilizará herramientas o cuánto tendré que corregirlo mientras trabajo con él.
Y precisamente esas son algunas de las cosas que más terminan importándome.
¿Con cuál me quedaría?
Después de utilizar ambos modelos, no creo que exista un ganador absoluto.
Qwen3.8 27B me sigue pareciendo un modelo extremadamente capaz, especialmente cuando una tarea necesita bastante análisis, planificación o razonamiento.
Pero en determinadas situaciones esa misma tendencia a profundizar puede hacer que el flujo de trabajo resulte más lento o pesado de lo que necesito.
Ornith 1.5 35B-A3B, en cambio, me está resultando especialmente cómodo para trabajar con código y agentes. Es rápido, responde bien, comprende correctamente las instrucciones y mantiene una relación entre capacidad y coste de inferencia que me parece muy interesante.
Si tuviera que elegir únicamente en función de mi experiencia de uso cotidiana en este momento, probablemente Ornith sería el modelo con el que me sentiría más cómodo trabajando durante horas.
Eso no significa necesariamente que sea mejor que Qwen.
Significa que encaja mejor con determinadas tareas y, sobre todo, con mi forma de trabajar.
El mejor modelo depende de lo que estés haciendo
Durante mucho tiempo he buscado cuál era el mejor modelo.
Cada vez tengo más claro que esa pregunta probablemente está mal planteada.
El mejor modelo depende del trabajo.
Para analizar un problema complejo puedo preferir un modelo que dedique más tiempo a razonar. Para trabajar iterativamente sobre código puedo preferir otro que responda más rápido y actúe de manera más directa.
Incluso modelos que sobre el papel parecen inferiores pueden terminar ofreciendo una experiencia mejor en determinadas tareas.
Los benchmarks sirven para decidir qué modelos merece la pena probar, pero solo después de utilizarlos durante horas empiezas realmente a descubrir cuál encaja con tu forma de trabajar.
Y precisamente esa es una de las cosas que más me atraen de ejecutar modelos localmente: poder probarlos, compararlos, entender sus diferencias y comprobar por mí mismo qué hay realmente detrás de los números.