Qwen local en una RTX 5080 pasa del 33% al 88,5% en un test de cuaderno de laboratorio

Cuando una red neuronal local pierde frente a una en la nube, lo habitual es culpar al hardware: se supone que falta memoria de vídeo. El autor de una serie de artículos en Habr comprobó si es así. Su estación de trabajo, con una sola RTX 5080 (16 GB de memoria de vídeo y 62 GB de RAM), obtuvo un resultado modesto en pruebas anteriores.

En las preguntas sobre un cuaderno de laboratorio electrónico, la primera versión de Qwen 3.8 IQ2_XS respondió correctamente solo 8 de 24, es decir, el 33%. Tras los ajustes, en el mismo ordenador Qwen 3.

8 IQ3_XXS logró 23,0 puntos de 26 posibles (88,5%) en un conjunto actualizado de 26 tareas y compartió el primer puesto con Claude Opus 5.5. Imagine que ha puesto en marcha un modelo local para analizar código o datos y que "se comporta de forma torpe".

La causa puede ser que el servidor haya desactivado en silencio la caché de conversaciones y que el límite de tokens corte el razonamiento en mitad de una frase. A continuación se detalla qué hubo que corregir.

Versión completa en lugar de la recortada

La versión Qwen 3.8 Coder IQ1_M se había reducido a 23,4 GB de dos maneras. Los pesos se comprimieron hasta aproximadamente 1,6 bits, y de cada capa se eliminó la mitad de los expertos enrutables: quedaron 256 de 512. Los "expertos" son aquí bloques independientes del modelo entre los que este reparte el trabajo. En ediciones sencillas de código apenas se notan pérdidas. Aparecen cuando hay que tener presentes varios subsistemas a la vez: transacciones anidadas de FireDAC, recálculo de la interfaz, reempaquetado de los archivos del proyecto y comprobación de actualizaciones en segundo plano con verificación de SHA-256. En esos casos, el modelo recortado fallaba una y otra vez.

El autor utilizó la versión completa de 512 expertos, Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS, del laboratorio ISTA-DASLab (2,84 bits por peso, 40 GiB de expertos). Según las tablas de conservación de precisión, solo supera en 2,3 puntos porcentuales a IQ2_XS: 87,3% frente a 85,0% del modelo sin comprimir. Pero en un agente multipaso con un contexto de unos cien mil tokens, las pequeñas imprecisiones se acumulan de un paso a otro y la diferencia se hace visible.

Dos trampas en la configuración del servidor

Al principio, el agente seguía chocando con el tiempo de espera de 45 minutos. En los registros del motor Strata aparecieron dos causas.

La primera: una doble reserva de memoria. El servidor cargaba en la memoria de vídeo los slots de expertos más usados (7,0 GiB) y, al mismo tiempo, intentaba fijar en la RAM los 40 GiB de expertos. Quedaban libres 0,7 GiB de RAM, así que el servidor desactivaba en silencio la caché de conversaciones. Sin ella, en cada paso de una sesión larga el agente volvía a leer entre 60 y 100 mil tokens de historial y perdía un minuto por paso. El flag --resident-experts fija en la RAM solo la parte que complementa a la memoria de vídeo, es decir, 33,5 GiB. Los 5,4 GiB liberados pasaron a la caché de sesiones.

La segunda: el corte del razonamiento. Antes de editar el código, el modelo escribe en la etiqueta think un plan de entre 6 y 9 mil tokens. El agente tenía un tope de maxTokens 8192 y el servidor tenía activado el modo answer_room.

Cuando el razonamiento llegaba a 6144 tokens, el servidor cerraba la etiqueta a la fuerza y dejaba 2048 tokens para la respuesta. La idea quedaba cortada a media frase, el modelo emitía un comentario sin llamar a ninguna herramienta y todo volvía a empezar. El autor subió el límite a maxTokens 16384 y configuró answer_room: false.

Los ciclos en vacío desaparecieron y el modelo pasó a mantener entre 70 y 81 tokens por segundo con un contexto de 131 072 tokens.

Un detalle para Windows: fijar 33,5 GiB de memoria al arrancar lleva unos 30 segundos. Por eso conviene mantener el servidor como un único proceso permanente durante toda la serie de tareas.

Resultados

En las 20 tareas de Delphi, una tarea se daba por resuelta si el proyecto se compila en RAD Studio sin nuevas advertencias del compilador y supera las pruebas ocultas de DUnitX. Qwen completa, sin ninguna skill adicional, resolvió 19 de 20 (95%), igual que Claude Sonnet 5.5, y superó todas las pruebas ocultas. Resolvió las tres tareas en las que tropezaba la versión recortada. Con la skill delphi-development conectada, el resultado bajó a 17 de 20. El autor atribuye la caída a la dispersión estadística de ejecuciones únicas: un modelo potente lee los módulos vecinos y adopta el estilo del proyecto incluso sin pistas.

En el test ELN Suite 1.1 (26 tareas, servidor MCP en funcionamiento), el modelo local obtuvo 23,0 puntos (88,5%) y terminó en 46 minutos. Claude Sonnet 5.5 y Gemini 4 consiguieron 21,0 cada uno, y DeepSeek V4.1 Flash, 19,0. La primera ejecución dio 22,0: el único cero lo recibió el modelo en una pregunta de calentamiento, al pasar un parámetro booleano como la cadena "True" en lugar de true. La capa agéntica OMP lo tolera, pero no así el validador estricto del propio autor ni uno de los cinco analizadores de parámetros duplicados del servidor Delphi.

Conclusiones prácticas y salvedades

• No use versiones recortadas en expertos para tareas agénticas complejas.
• Vigile el equilibrio entre la RAM y la caché de conversaciones: desactivar la caché en silencio convierte la sesión en una relectura interminable del contexto.
• Deje a un modelo que razona un margen en maxTokens y no active el cierre forzado de think.
• Haga que las herramientas toleren "True" y null en los campos opcionales.

Las salvedades son importantes. Los tests son del propio autor, se hicieron sobre proyectos cerrados y parte de las configuraciones se ejecutó una sola vez. El 33% anterior se obtuvo con un conjunto de 24 preguntas; el nuevo 88,5%, con un conjunto actualizado de 26 tareas. El modelo local es notablemente más lento: 46 minutos frente a 17 de Opus 5.5 y 11 de Sonnet 5.5. A cambio, la ejecución cuesta $0 frente a $5,37 de Opus. Si las tareas no son urgentes y los datos no pueden salir del laboratorio, es un argumento de peso a favor de tener hardware propio.