REAP20 acelera un Qwen local un 42 % sin perder precisión en DS1000

Al elegir un LLM local para código, es fácil montar un torneo vistoso y acabar con un ganador inútil. Basta con tomar el conjunto de prompts de otro, olvidarse del límite de razonamiento o comparar los modelos en modos distintos. El autor del material hizo casi todo esto él mismo y luego gastó cientos de horas de GPU para entender dónde se había torcido el experimento.

El valor práctico de la historia está precisamente en los errores. Con una RTX 4070 Ti Super de 16 GB de memoria de vídeo, el autor probó la familia Qwen en DS1000, un conjunto de mil tareas de Pandas, NumPy, SciPy, Scikit-learn, Matplotlib, PyTorch y TensorFlow. El código del modelo se insertaba en una plantilla, se ejecutaba y el resultado se comparaba con una referencia. Esto se parece más al trabajo real de un especialista en datos que otra prueba de crear una landing page o un juego en el navegador.

Primera ejecución: velocidad sin largas deliberaciones

En la prueba inicial el razonamiento estaba desactivado. Los mejores por número de tareas resueltas fueron REAP20-28B y Qwen3.6-35B-A3B. REAP20 se comportó de forma especialmente interesante: con una precisión comparable, generaba la respuesta un 42 % más rápido que el modelo original, aunque se le había eliminado el 20 % de los pesos.

Para el trabajo diario es un resultado de peso. Si una persona espera el siguiente fragmento de código NumPy, la latencia importa más que la capacidad del modelo de reflexionar durante varios minutos. Por eso el autor propuso una división práctica: un modelo MoE rápido ayuda en modo interactivo, y uno dense más lento ejecuta de noche tareas que no requieren control constante, por ejemplo una revisión preliminar de código.

Pero el resultado no debe convertirse en un ranking universal. DS1000 salió en 2023 y parte de sus tareas pudo acabar en los datos de entrenamiento de modelos nuevos. Una sola ejecución no muestra la dispersión de los resultados, y las distintas cuantizaciones y ajustes de decodificación dificultan aún más una comparación justa. Por último, la elección de bibliotecas debe corresponder al trabajo real: al autor le importaban NumPy, SciPy, Scikit-learn y PyTorch, así que más tarde redujo el conjunto de 1000 a 509 tareas.

El límite de tokens rompió el segundo experimento

En la segunda ejecución el autor activó thinking, pero dejó 4096 tokens para el razonamiento. Esa decisión dio la vuelta a la tabla. La precisión de REAP20 cayó a menos de la mitad, mientras que la versión completa del mismo modelo apenas cambió su resultado. La causa fue prosaica: en aproximadamente dos de cada tres casos, REAP20 chocaba con el techo y no lograba terminar la respuesta.

Un ejemplo sencillo: el modelo sabe cómo escribir la solución con Scikit-learn, traza un plan correcto, pero se corta antes del código final. El sistema de verificación pone cero, igual que ante una respuesta totalmente errónea. Si solo se mira la precisión final, se puede concluir que el modelo empeoró. En realidad, lo que está roto es el circuito de medición.

Es una lección importante para cualquier benchmark interno: guarda el motivo de finalización de la respuesta, el número de tokens usados, el tiempo de generación y la proporción de cortes. Los resultados con finish_reason=length deben analizarse por separado; de lo contrario, una limitación de la infraestructura se hace pasar por debilidad del modelo.

Qué pasó tras la corrección

El autor empezó a subir el límite de forma gradual y a continuar los razonamientos interrumpidos. Qwen3.8-27B en modo de máximo esfuerzo acabó resolviendo 252 de 509 tareas, frente a las 173 iniciales. La mejora fue de 79 soluciones, pero el precio resultó desagradable: la serie de iteraciones llevó unas 153 horas. En precisión final, el modelo solo se acercó al más rápido Qwen3.6-MoE sin razonamiento.

En una RTX 6000 Pro profesional, el modelo Qwen3.8-Flash-Next-NVFP4 logró un 58,1 % en el DS1000 completo en 8,5 minutos. Sin embargo, este resultado no puede trasladarse a una tarjeta gráfica de gaming: otro hardware, otro formato de pesos y otra configuración cambian la economía de la ejecución.

La conclusión práctica es aburrida, pero útil. Primero, reúne un pequeño conjunto de tareas propias, fija las versiones de las bibliotecas y usa parámetros de ejecución idénticos. Después mide la precisión, la latencia, los cortes por límite y el coste de una solución exitosa. Para un asistente diurno, elige el modelo por velocidad con calidad suficiente; para las tareas nocturnas, puedes dar más tiempo y tokens. Y, sobre todo, no cures un diseño de experimento débil con cientos de horas de GPU adicionales.