AesCode-8B vs MathForm-8B: ambos son fine-tunes de 8B cuya salida puede comprobar una máquina

AesCode-8B y MathForm-8Baparecieron con ocho semanas de diferencia, ambos desde repositorios en lugar de comunicados de prensa, y la coincidencia es más interesante de lo que parece a primera vista. Ambos parten de un checkpoint de la familia Qwen3. Ambos dedican todo su presupuesto de entrenamiento a una forma de salida estrecha. Y ambos se construyeron en torno a un verificador: MathForm-8B se entrena contra el veredicto de un compilador de Lean 4, y AesCode-8B se puntúa renderizando cada página candidata en un navegador aislado y leyendo de vuelta el DOM, los estilos calculados y una captura de pantalla. Ninguno es un chatbot y ninguno intenta convertirse en uno. Lo que los separa es lo que una máquina puede verificar y lo que no — y, en el caso del más nuevo de los dos, qué ocurre cuando la mitad de la puntuación llega de un juez que nadie ha nombrado.

Los registros de publicación no son simétricos. MathForm-8B proviene de OpenBMB y su tarjeta de modelo fecha el lanzamiento el 2026-08-14; está construido sobre Qwen3-8B y entrenado con FormalVerse, un corpus de aproximadamente 367.000 ejemplos verificados de Lean 4, con ajuste fino supervisado seguido de aprendizaje por refuerzo que utiliza la compilación de Lean y las comprobaciones de consistencia semántica como señal de recompensa. AesCode-8B no incluye ninguna fecha de lanzamiento en ninguno de sus archivos. Microsoft creó el repositorio de Hugging Face el 2026-09-29, confirmó los pesos a las 03:35 UTC del 2026-10-07 con el mensaje "Release AesCode-8B" y publicó el código de entrenamiento en GitHub el 2026-10-08. Ningún anuncio acompañó a ninguno de los dos eventos, la cita de la tarjeta del modelo dice "Under review, 2027" y el repositorio mostraba dos descargas en el momento de escribir esto. Es un ajuste fino de Qwen3-VL-8B-Instruct, lo cual vale la pena señalar precisamente porque no es el mismo ancestro que el de MathForm-8B.

La ascendencia explica la mayor parte de la división

Qwen3-8B y Qwen3-VL-8B-Instruct comparten una generación y un nombre de familia, pero no una función. Qwen3-8B es un generalista solo de texto: aproximadamente 8,2 mil millones de parámetros totales, unos 7 mil millones de ellos no de embedding, atención de consultas agrupadas, un contexto nativo de 32 000 tokens extensible a 131 000 mediante YaRN, y entrenamiento en 119 idiomas y dialectos. Qwen3-VL-8B-Instruct es el modelo hermano de visión y lenguaje, y es el checkpoint del que parte AesCode-8B: la configuración publicada de AesCode es una receta directa de Qwen3-VL con 36 capas ocultas, tamaño oculto de 4096, 32 cabezas de atención con 8 cabezas de clave-valor y un vocabulario de 151 936 tokens.

Esa bifurcación determina el lado de entrada de ambos especialistas antes de que se entrenara cualquiera de los dos. MathForm-8B recibe texto y emite texto en una sintaxis formal. AesCode-8B recibe texto más una imagen de referencia opcional y emite un documento.

• Base — MathForm-8B: Qwen3-8B, solo texto. AesCode-8B: Qwen3-VL-8B-Instruct, admite imagen y texto.

• Parámetros — MathForm-8B: alrededor de 8,2B. AesCode-8B: alrededor de 8,8B en bf16 repartidos en cuatro shards, que Hugging Face redondea a 9B.

• Datos de entrenamiento — MathForm-8B: FormalVerse, aproximadamente 367K ejemplos verificados de Lean 4. AesCode-8B: 3.000 demostraciones de arranque en frío y, a continuación, aprendizaje por refuerzo GDPO sobre 7.408 prompts durante 400 pasos.

• Qué verifica la salida — MathForm-8B: un compilador de Lean 4, más una comprobación de consistencia semántica con el problema original. AesCode-8B: un render de Playwright en entorno aislado con seis verificadores deterministas y una rúbrica puntuada por el modelo.

• Licencia — ambos Apache 2.0, ambos sin restricciones, ambos heredan de la arquitectura base de la familia Qwen3.

• Alojado en cualquier lugar — ninguna de las dos, hasta donde hemos podido averiguar.

Dos significados diferentes de «verificable»

Esta es la distinción que merece que uno se detenga, porque «verificable por máquina» se usa para ambas cosas y no significa lo mismo.

El verificador de MathForm-8B es un asistente de demostración. Lean 4 acepta o no acepta un enunciado, y el veredicto no es cuestión de opinión, una rúbrica o el gusto de un juez. El bucle de entrenamiento apunta a esa señal: la etapa de SFT sobre FormalVerse enseña la correspondencia entre un problema informal y un enunciado de teorema formal con una cabecera de imports y un teorema con nombre, y la etapa de RL lo perfecciona usando compilación más una comprobación de consistencia que pregunta si la formalización sigue diciendo lo que decía el problema original. La compilación es binaria y reproducible por cualquiera con la misma versión de Lean. La comprobación de consistencia es la mitad más blanda, y es la mitad en la que los números reportados se vuelven débiles, que es exactamente lo que muestran los resultados publicados.

El verificador de AesCode-8B es un renderizador. Los candidatos se renderizan en un navegador Playwright en sandbox con las peticiones externas bloqueadas, y el arnés lee de vuelta el DOM, los estilos computados, las cajas delimitadoras, el estado de la consola y una captura de pantalla. Seis canales deterministas puntúan las cosas analizables —ejecución, texto exacto, comportamiento en los límites, datos de tablas y gráficos, diseño semántico, espacios en blanco— y un séptimo, la Visual Graph Rubric, puntúa la geometría y la colocación mediante preguntas de sí/no ligadas a grafos. Las tablas deben ser tablas HTML reales y los gráficos deben ser especificaciones de ECharts, lo cual es una restricción que hace un trabajo real: obliga a que la salida adopte una forma que un verificador pueda analizar. La mitad determinista es genuinamente reproducible. La mitad visual la juzga un modelo de lenguaje y visión cuya identidad la documentación no nombra, lo que significa que nadie fuera del laboratorio puede reproducirla.

Así que la comparación honesta no es "uno está verificado y el otro no". Es que la señal principal de MathForm-8B es un compilador y su señal secundaria es una comprobación de consistencia, mientras que la señal principal de AesCode-8B es un conjunto de aserciones DOM deterministas y su señal secundaria es la opinión de un modelo, empaquetadas dentro de la misma puntuación global.

Qué informa cada uno, y cuánto vale eso

MathForm-8B reporta un Pass@8 promedio de 88.06 % bajo la comprobación de sintaxis y 72.37 % bajo la comprobación de consistencia en seis benchmarks. La variación por benchmark es la parte interesante: 95.06 % de consistencia en FormalIMATH y 94.83 % en ProverBench, luego 63 % en FATE-H y 37 % en FATE-X. Esos dos últimos son los enunciados difíciles y realistas, y la caída desde mediados de los noventa hasta mediados de los treinta es la forma honesta de la capacidad. Todas estas cifras son reportadas por el proveedor y no han sido reproducidas, y la combinación de benchmarks está sesgada hacia los conjuntos más fáciles.

AesCode-8B reporta 82.94 General en la rúbrica de infografías de 300 muestras de Microsoft — Texto 94.06, Límite 88.36, Gráfico 87.79, Regla 90.07, Contenido 86.41, Diseño 87.80, Estilo 53.21, Visual 75.80 — con tres generaciones por prompt y sin selección. Microsoft también reporta que supera a GPT-5.5 condicionado por referencia con 81.28 y a Claude Opus 4.8 con 80.39 en la misma rúbrica, que un fallo grave de desbordamiento del lienzo se repite en el 4.3% de las 300 muestras, y que 22.4 puntos Visual separan al acompañante de 32B de su propio modelo base. Cada número es del proveedor, en la tarea del proveedor, puntuado contra canales que el proveedor diseñó.

Los dos conjuntos de números no se pueden comparar entre sí en absoluto. No hay una tarea, una métrica ni un juez en común. Poner 88.06% junto a 82.94 sería comparar una tasa de aprobación de formalización en Lean con una puntuación general de una infografía, y ninguno de los modelos fue evaluado alguna vez en lo que hace el otro.

Vale la pena nombrar una asimetría porque va en contra del modelo más reciente. La métrica principal de MathForm-8B tiene incorporado un árbitro externo: cualquiera puede instalar Lean, cargar los mismos benchmarks y comprobar si las afirmaciones compilan. La métrica principal de AesCode-8B no lo tiene —los verificadores deterministas podrían ser vueltos a ejecutar por un externo decidido, pero la mitad visual de la puntuación depende de un juez que el artículo no ha identificado. Una tasa de aprobación del compilador no reproducida es una afirmación más débil que una tabla de benchmarks, y aun así más fuerte que una puntuación de rúbrica no reproducida con un calificador anónimo dentro.

Ejecutarlos es una cuestión distinta de cualquiera de las dos puntuaciones.

Ambos son decisiones de autoalojamiento hoy en día. MathForm-8B es el más económico por un amplio margen: un checkpoint de solo texto de unos 8,2B con un presupuesto de generación de alrededor de 16K tokens de salida de Lean, que se cuantiza en una única tarjeta de gama media. AesCode-8B es un modelo de visión-lenguaje de 8,8B cuya ruta de servicio transporta imágenes además de texto; el propio comando de la tarjeta es vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, y 17,5 GB de pesos bf16 más una caché KV para 24.576 tokens y dos imágenes significa que una tarjeta de 24 GB queda ajustada y que 40-48 GB es el mínimo realista. Presupuesta también una pila de renderizado si quieres evaluar tus propias salidas, porque así es como se hizo cada afirmación de calidad sobre el modelo.

El mayor coste oculto es que ambos modelos son especialistas que adoptarías de forma permanente. Un equipo que necesita formalización y generación de documentos ahora ejecuta dos rutas de servicio de 8B, dos conjuntos de formatos de prompt, dos perfiles de fallo, y ninguno de los modelos puede absorber el trabajo del otro. Ese es el caso para el que existe una capa de enrutamiento: mantener a los especialistas donde la economía y la gestión de datos justifican tener una GPU, y enviar el tráfico general a algo alojado detrás del mismo endpoint. En concreto, los hermanos generalistas de estas dos bases son invocables — Qwen3-VL-8B-Instruct a $0.18 por millón de tokens de entrada y $0.70 por millón de tokens de salida en un contexto de 131,072 tokens, junto con la familia Qwen 3.8 y otros checkpoints abiertos — todo a través de la única API de OrcaRouter que cubre más de 200 modelos, con el precio de lista del proveedor trasladado tal cual con un 0% de margen y conmutación por error automática entre proveedores. Ninguno de los dos especialistas puede enrutarse aquí ni en ningún otro lugar que podamos encontrar; lo que sí puede enrutarse es el generalista al que recurres cuando el trabajo concreto ha terminado, que es la diferencia entre probar un checkpoint de investigación y convertirlo en una dependencia que soporta la carga.

A la hora de elegir entre ellos, si de verdad tienes que hacerlo

Elige MathForm-8B cuando el artefacto tenga que compilar. Conversión de bancos de problemas, corpus formales para un demostrador, preformateo de enunciados para herramientas basadas en Lean: esa es toda la descripción del trabajo, y es el único de los dos que fue entrenado para ello. Toma en serio los números de FATE cuando definas el alcance: en los enunciados realistas más difíciles, aproximadamente un tercio resulta consistente, y tendrás que construir un paso de revisión humana de todos modos.

Elige AesCode-8B cuando el artefacto tenga que renderizarse. Entra un brief, sale un documento HTML editable, las tablas son tablas y los gráficos son especificaciones de gráficos, y todo el conjunto se compara con diff en Git. Acepta el techo de Estilo —53,21, una dimensión definida como la que no necesita más revisiones visuales antes de la entrega— como la medida honesta de cuánta edición queda, y acepta que el contexto de 24.576 tokens solo se ha validado en páginas de infografía individuales y no en las presentaciones de varias diapositivas que la gente realmente quiere.

La elección a la que la mayoría de los equipos se enfrentará en realidad no es ninguna de estas dos, sin embargo. Es si vale la pena desplegar siquiera a uno de estos especialistas de nicho, o si el generalista que está detrás, invocado a través de una API, es lo bastante bueno para el volumen que tienes. Eso es una tarde de pruebas de prompts en lugar de comprar una GPU, y los propios números de ambas tarjetas te dan la razón para hacerlo: la consistencia en el conjunto difícil de MathForm-8B se sitúa en el 37%, y la puntuación de estilo de AesCode-8B se sitúa en el 53%, así que ninguno es un modelo que pondrías en un pipeline sin supervisión.

Lo que ambos lanzamientos te dicen sobre cómo se lanzan los modelos ahora

Dos modelos ajustados de 8B, con ocho semanas de diferencia, de dos laboratorios distintos, lanzados sin anuncio, sin página de producto y sin evaluación independiente, ambos construidos en torno a un bucle de verificación, ambos Apache 2.0, y ninguno servido por nadie. Ese patrón es más la historia que cualquiera de los dos modelos. El método de investigación se ha trasladado a la función de recompensa —la señal de compilador de OpenBMB, los canales transmodales desacoplados de Microsoft— y los artefactos publicados se han convertido en la receta de entrenamiento más los pesos, con el artículo llegando después, si es que llega.

Lo que eso significa para cualquiera que lea una comparación como esta es que los números del propio proveedor son todo lo que tendrás durante un tiempo, y la pregunta útil no es qué tan altos son, sino qué tan verificables son. La tasa de desbordamiento de AesCode-8B y su techo de Style son afirmaciones verificables disfrazadas de fallos. La cifra de consistencia FATE-X de MathForm-8B es lo mismo. Esos son los números que hay que leer, y los que hay que volver a ejecutar uno mismo en cuanto los verificadores sean reproducibles de principio a fin.