Investigación · 2026-10-24 · Toda la investigación

Partimos por la mitad un modelo de programación de 321B para ejecutarlo en un PC doméstico. Esto es lo que se rompió, y cómo lo arreglamos.

GLM-5.3-Flash tiene 288 expertos en cada capa. Conservamos 152, elegidos mediante optimización, y publicamos el resultado como pesos abiertos. Por el camino, nuestra primera versión rompió la aritmética, y los archivos más pequeños caían en un bucle de razonamiento que un solo ajuste elimina.

Photo: Jakub Pabis / Pexels

GLM-5.3-Flash es uno de los modelos de pesos abiertos más potentes para programación y trabajo agéntico. También tiene 321 mil millones de parámetros: 341 GB a 8 bits. Casi nadie puede ejecutarlo en casa.

Es un modelo de mezcla de expertos. Cada capa contiene 288 expertos, y para cada token el enrutador usa solo unos pocos. La mayoría de los expertos rara vez se necesitan para código. Así que la pregunta es sencilla: ¿cuántos podemos quitar, y cuáles, antes de que el modelo deje de ser el mismo modelo?

Nuestra respuesta es GLM-5.3-Flash-Coder-RCO-152E: 152 de los 288 expertos en cada capa, publicado como pesos abiertos con la misma licencia MIT que el original. El archivo de 3 bits ocupa 75 GB y funciona en una GPU de 24 GB con 64 GB de RAM.

El primer intento, y por qué lo sustituimos

Nuestra primera versión conservaba 144 expertos por capa, elegidos con una puntuación de relevancia publicada (REAP) medida en sesiones de agente en Python. En tareas de agente en Python se comportaba bien.

Luego ejecutamos una prueba de regresión más amplia, y falló de formas que un benchmark de programación no muestra. Podía equivocarse en 17 x 23. Entraba en bucle con preguntas en otros lenguajes de programación. La causa era la calibración: los expertos que se ocupan de la aritmética, de otros lenguajes y del razonamiento general apenas se usaban en las sesiones de agente en Python, así que la puntuación los clasificó bajo y los eliminamos.

Lo dijimos en la página del modelo, retiramos los archivos y lo reconstruimos. La lección es general: un modelo podado conserva aquello con lo que lo mides, y pierde en silencio el resto. Si el conjunto de prueba no cubre una habilidad, la poda no la protegerá.

Cómo elegimos los expertos esta vez

Dos cambios.

Los datos de calibración. En lugar de un solo tipo de sesión, una mezcla: sesiones de programación agéntica escritas por el modelo completo, código en 21 lenguajes de programación, matemáticas y un 15% de texto general. Todo ello fuera de nuestros conjuntos de evaluación.

El método de selección. En lugar de puntuar cada experto por separado, usamos RCO, un método de optimización de IST Austria. Trata el conjunto de expertos conservados como una única decisión y minimiza directamente la diferencia entre la salida del modelo podado y la del modelo completo sobre los datos de calibración.

Con los mismos 152 expertos, la máscara optimizada igualó a la máscara basada en puntuaciones en código y texto agéntico, tuvo un error un 22% menor en texto general y produjo muchos menos bucles: 4 problemas en nuestra prueba de bucles de 30 ejecuciones, frente a 22 de la primera versión.

Después vino un breve paso de recuperación: un pequeño adaptador sobre los pesos de atención y del experto compartido, entrenado para reproducir la distribución de salida del modelo completo.

Qué conserva

A 8 bits, frente al modelo completo con los mismos prompts y el muestreo por defecto:

BenchmarkRCO-152EModelo completo
AIME 2025 (20 problemas)1920
Subconjunto de MATH-5006/66/6
Subconjunto de LiveCodeBench6/66/6

La aritmética, el código ejecutado y las llamadas a herramientas funcionan en todos los tamaños publicados.

ArchivoTamañoFunciona en (GPU + RAM)Diferencia respecto a 8 bits (KLD)
Q8_0180 GBvarias GPU0
Q4_K_M103 GB24 GB + 96 GB0.024
Q3_K75 GB24 GB + 64 GB0.045
Modelo completo341 GBQ8_0180 GBQ4_K_M103 GBQ3_K75 GB

El bucle que solo aparece tras la cuantización

El modelo de 8 bits estaba limpio. Los archivos de 4 y 3 bits no, y nos costó un tiempo entender el fallo.

En ejercicios de programación más difíciles, el modelo empezaba a razonar con normalidad, dudaba, escribía "hmm" y ya no dejaba de escribir "hmm" hasta agotar los tokens. Ni una línea de código. Peor aún, una vez que un intento había entrado en bucle, los siguientes intentos, que ven el razonamiento anterior en su historial, volvían a entrar en bucle en pocos miles de caracteres.

En Aider Polyglot, con hasta diez intentos por ejercicio, los ejercicios en los que cada archivo entró en bucle:

ArchivoEjercicios con bucle
8 bits0 de 19
4 bits2 de 15
3 bits4 de 14
8 bits0%4 bits13%3 bits29%

Las soluciones obvias no funcionaron. Una penalización por presencia detuvo la repetición, pero entonces el modelo seguía razonando sin terminar nunca. Un límite a la longitud del razonamiento ayudó en uno de cada tres ejercicios, porque el bucle a menudo empezaba mucho antes del límite.

Lo que funcionó fue algo mucho más acotado: prohibir los tres tokens de "hmm" de este tokenizador. Con ese único ajuste, el modelo de 3 bits resolvió los tres ejercicios en los que había entrado en bucle, dos de ellos al primer intento. El ajuste exacto está en la página del modelo; es un único flag --logit-bias en llama.cpp.

Creemos que la causa de fondo es que el modelo cuantizado nunca se entrenó con sus propias salidas: una vez que deriva hacia un estado de duda, nada lo hace volver. Eso es lo que vamos a probar a continuación, entrenando la versión de 2 bits con sus propias generaciones y con el modelo completo como profesor.

Pruébalo

Esta investigación utilizó cómputo de asignaciones de la EuroHPC JU AI Factory en el superordenador LUMI. RCO y GSQ son métodos de IST Austria; REAP es de Lasby et al., 2025.

¿Quieres un modelo especializado como este, privado, en tus propios servidores?

Ajustamos, podamos y evaluamos modelos abiertos para tu código, tus documentos o tu sector, y los desplegamos en una infraestructura que tú controlas.

Habla con nosotros
Usamos cookies para que el sitio funcione. Política de cookies