AesCode-8B se lanzó sin hacer ruido: el modelo de 8B de Microsoft escribe diapositivas y paneles como HTML

El número más interesante del nuevo lanzamiento de Microsoft es 1,00. Si se omite la imagen de referencia de AesCode-8B —un modelo de 8.000 millones de parámetros que escribe diapositivas, pósteres y paneles como HTML y CSS editables—, su puntuación visual cae un punto sobre cien. Si se omite la misma referencia de Qwen3-VL-8B-Instruct, el modelo de pesos abiertos a partir del cual se ajustó AesCode-8B, la caída es de 19,55 puntos. En GPT-5.5 es de 10,04. Esa única comparación es donde reside el verdadero resultado de la investigación, y se encuentra bajo un titular que Microsoft también publicó: en su propia rúbrica de 300 muestras, la puntuación global de AesCode-8B, de 82,94, supera por poco a la de GPT-5.5 condicionado por referencia, de 81,28, y a la de Claude Opus 4.8, de 80,39, mientras que un hermano mayor, AesCode-32B, alcanza 85,89.

No se anunció nada sobre este lanzamiento. Microsoft subió los pesos a Hugging Face el 2026-10-07 bajo Apache 2.0 —AesCode-8B más un modelo complementario de 32B construido de la misma forma a partir de Qwen3-VL-32B-Instruct— y subió el código de entrenamiento y evaluación a GitHub al día siguiente. No hay publicación de Microsoft Research, ni nota de lanzamiento, ni página de producto, ni preprint: la cita en la tarjeta del modelo dice «En revisión», año 2027, que es un marcador de posición en lugar de una fecha. A fecha de 2026-10-11, el repositorio de 8B muestra dos descargas y un me gusta; el repositorio de GitHub muestra una estrella. Todo lo que aparece a continuación y que lleva un número es o bien una marca de tiempo que puedes verificar tú mismo, o bien una cifra que Microsoft informó sobre su propio conjunto de evaluación; y esa distinción importa más de lo habitual aquí, porque ninguna parte de este modelo ha sido medida por nadie más.

Qué se envió y qué no está en la caja

Tres fechas definen este lanzamiento, y son las únicas fechas que contiene. El repositorio de Hugging Face para microsoft/AesCode-8B se creó el 29 de septiembre de 2026, los pesos se registraron en un commit con el mensaje "Release AesCode-8B" a las 03:35 UTC del 7 de octubre de 2026, y el repositorio de código de microsoft/AesCode se hizo público al día siguiente, el 8 de octubre de 2026 a las 23:14 UTC. Los pesos de 32B llegaron en la misma ventana de commits. No se anunció nada en el ínterin en ningún sitio.

• Pesos — cuatro fragmentos safetensors que suman 17.543.339.408 bytes en total, lo que equivale a unos 8.800 millones de parámetros en bf16. Microsoft etiqueta el modelo como 8B; el campo de tamaño de Hugging Face lo redondea a 9B. Eso es un redondeo, no una discrepancia.

• Arquitectura — un ajuste fino directo de la receta de Qwen3-VL: Qwen3VLForConditionalGeneration, 36 capas ocultas, tamaño oculto de 4.096, 32 cabezas de atención con 8 cabezas de clave-valor, un vocabulario de 151.936 tokens y posiciones mrope intercaladas. Necesita transformers 4.57 o posterior.

• Contexto y salida — lo reportado utilizó un contexto de 24,576 tokens con hasta 12,000 tokens de salida, generado a temperatura 0.8 y top-p 0.95 en tres ejecuciones por prompt sin selección. El comando de servicio vLLM permite dos imágenes por prompt: la de referencia, y ninguna otra, porque la salida es texto.

• Licencia — Apache 2.0, descrita como siguiendo el backbone Qwen3-VL. Totalmente permisiva, sin gating, sin anexo de uso aceptable.

• No incluido — los datos de entrenamiento y evaluación. El repositorio incluye el pipeline y documenta las entradas y salidas esperadas, y menciona los archivos de división que espera, pero no se lista ninguna publicación de conjunto de datos ni en la ficha del modelo ni en el repositorio de código. Obtienes la receta, no los ingredientes.

• Tampoco incluido — ningún endpoint alojado. No pudimos encontrar ninguna API que sirviera AesCode-8B en ningún sitio, y no está en nuestro propio catálogo. Hasta que algún proveedor lo adopte, evaluarlo significa cargar los pesos en tus propias GPU.

El enfoque que utiliza Microsoft merece ser citado porque es todo el brief de diseño: los modelos de código "no pueden ver cómo se combinan la disposición, la jerarquía y el color en el lienzo", mientras que los generadores de imágenes "componen páginas visualmente atractivas, pero a menudo representan mal el texto, los números y las relaciones lógicas". AesCode es el intento de tomar la capacidad de composición de uno y la verificabilidad del otro.

El resultado de 1,00 puntos, explicado

Aquí está el mecanismo detrás del número en el primer párrafo. Durante el entrenamiento, cada prompt se empareja con una imagen generada a partir de ese mismo prompt — las propias ejecuciones de Microsoft usaron GPT-Image-2 para la imagen y GPT-5.5 para expandir una idea breve en el prompt de contenido detallado. La referencia no contiene contenido; el prompt de texto sigue siendo la fuente de verdad. Lo que proporciona la referencia es el diseño y el estilo, y la recompensa está construida para mantener esas dos cosas separadas.

La consecuencia es que el prior visual acaba en la política en lugar de en la entrada. AesCode-8B pierde 1.00 punto Visual cuando se elimina la referencia durante la inferencia. Su propio backbone, evaluado con condicionamiento por referencia en 44.72 Visual, pierde 19.55 puntos sin una. GPT-5.5 pierde 10.04. La versión destilada de eso: el modelo dejó de necesitar la imagen.

La segunda mitad del resultado es la que es fácil pasar por alto. Microsoft informa que las recompensas basadas en referencias elevaron el Visual de solo prompt de 25.17 a 69.71: el modelo que nunca ve una referencia en el momento de la inferencia sigue beneficiándose de haber sido entrenado contra ellas. Si estabas planeando omitir el paso de generación de referencias en tu propio pipeline, ese es el número que dice que tampoco deberías molestarte en omitirlo durante el entrenamiento.

La advertencia honesta sobre todo esto: esta es la rúbrica de Microsoft, sobre las 300 muestras de infografía de Microsoft, puntuada tres veces por prompt sin seleccionar los mejores resultados. La mitad de la puntuación proviene de verificadores deterministas, que cualquiera podría reproducir; la otra mitad, las dimensiones de la lista de verificación, la juzga un modelo de visión-lenguaje cuya identidad la documentación no nombra. No puedes reproducir la segunda mitad sin saber qué juez la produjo.

Donde el gusto se mete en los pesos

El método de entrenamiento es la parte de este lanzamiento con las ideas más transferibles, y es más mecánico de lo que sugiere el resultado.

• Todo es primero un grafo. Cada objetivo se representa como un grafo de diseño: nodos para texto, gráficos, tablas, tarjetas, regiones y espacios de imagen, y aristas para contención, alineación, orden y conexión. El propósito del grafo es la atribución: cada propiedad del lienzo pertenece a un elemento con nombre, de modo que cada propiedad puede puntuarse por sí sola.

• Siete canales de recompensa. Seis verificadores deterministas comprueban las cosas analizables —ejecución, texto exacto, límites, datos de tablas y gráficos, maquetación semántica, espacios en blanco—, y una Rúbrica de Grafo Visual específica para cada muestra, construida como preguntas de sí/no vinculadas al grafo sobre geometría y ubicación, puntúa el resto. Los canales son ejecución, texto, límite, tablagráfico, maquetación, espacios en blanco y diseño.

• Los canales se normalizan antes de combinarse. GDPO normaliza cada canal dentro de su grupo de rollout, de modo que una señal densa basada en reglas no puede ahogar a la señal visual dispersa. Microsoft mide esto en 5,12 puntos Visual frente al GRPO escalar simple con la misma configuración —reportado por el proveedor, pero una ablación concreta en lugar de una simple afirmación.

• La puntuación se realiza mediante renderizado.El HTML candidato se renderiza en un navegador Playwright en sandbox con solicitudes externas bloqueadas, y el arnés recupera el DOM, los estilos computados, los cuadros delimitadores, el estado de la consola y una captura de pantalla. Las tablas deben ser tablas HTML; los gráficos deben ser especificaciones de ECharts. Esa restricción hace un trabajo real — obliga a que la salida adopte una forma que un verificador pueda analizar.

• La receta en sí. Ajuste fino supervisado con arranque en frío sobre 3.000 demostraciones a una tasa de aprendizaje de 1e-5, luego GDPO sobre 7.408 prompts durante 400 pasos en el motor híbrido FSDP-vLLM de verl, sin crítico y sin un modelo de recompensa entrenado por separado. AdamW con una tasa constante de 5e-6, sin warmup, decaimiento de peso 0,01, 128 prompts por paso con 8 rollouts cada uno, coeficientes de KL y entropía, ambos 0,001, tanto el prompt como la respuesta limitados a 8.192 tokens cada uno. Las ejecuciones publicadas usaron un solo nodo con ocho NVIDIA B200. AesCode-32B usa la misma receta durante 520 pasos.

Leído en su conjunto, este es un artículo de diseño de recompensas disfrazado de lanzamiento de modelo —y eso es coherente con que la cita diga «en revisión» en lugar de apuntar a un preprint.

El marcador, y quién lo avala

Todo lo siguiente es la evaluación propia de Microsoft, reportada en la ficha del modelo, sobre 300 muestras de infografías. Rule promedia las comprobaciones programáticas de Texto, Límite y Gráfico; Visual promedia las dimensiones de la lista de comprobación de Contenido, Diseño y Estilo; General es la media de las dos. Las puntuaciones son porcentajes promediados sobre tres generaciones por prompt, sin selección. «Ref.» indica si se proporcionó al modelo una referencia generada junto con el prompt.

• AesCode-8B con referencia — 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; General 82.94.

• Frente a su propio backbone — el Qwen3-VL-8B-Instruct condicionado por referencia obtiene 44,72 en Visual y 44,72 en Overall. Eso supone una ganancia de 31,1 puntos en Visual y de 31,0 puntos en Overall, y es la comparación menos sorprendente de la tabla, ya que todo el objetivo del entrenamiento es la mitad visual.

• Frente a GPT-5.5, condicionado por referencia — Global 81,28; Contenido 82,44; Maquetación 89,93; y Estilo 57,91.

• Frente a Claude Opus 4.8, condicionado por referencia — General 80.39, Contenido 86.42, Diseño 89.76.

• AesCode-32B, condicionado por referencia — Texto 95.34, Límite 97.27, Gráfico 90.37, Regla 94.33, Diseño 90.58, Visual 77.44, General 85.89. Veintidós punto cuatro puntos de Visual por encima de su propio backbone de 32B.

• El techo en Estilo — ningún modelo de la tabla supera los 60, y el 57.91 de GPT-5.5 es el mejor de todos. AesCode-8B está en 53.21. La propia definición de Microsoft es implacable: dar estilo a un diseño solo cuando este no necesita ninguna revisión visual antes de la entrega. Así que, en la única dimensión que mide si un humano realmente entregaría la página sin editar, el modelo 8B no es el líder.

• Fallos de límites — un fallo grave de desbordamiento del lienzo se repite en el 4,3% de las 300 muestras, frente al 34,7% de GPT-5.5. El desbordamiento es el modo de fallo que hace que el HTML generado sea inutilizable, y no simplemente feo.

Ahora, la parte que importa tanto como la tabla. Todas las cifras anteriores son reportadas por el proveedor y no han sido reproducidas. AesCode-8B no aparece en ninguna tabla de clasificación independiente que hayamos podido encontrar, y la comparación con GPT-5.5 y Claude Opus 4.8 se está realizando con la rúbrica de Microsoft, en una tarea para la que esos modelos no fueron ajustados, con una definición de "Layout" que premia el mero hecho de producir una página. Una puntuación de Texto de 94.06 no significa que este modelo supere a GPT-5.5 en texto. Significa que coloca etiquetas sin contradecir el prompt en páginas de infografía, lo cual es una afirmación mucho más modesta. El resultado de Estilo es la señal de que la rúbrica no está amañada a favor de AesCode: la mayor victoria en el marcador viene acompañada del mayor número poco halagüeño justo al lado.

Qué está confirmado, y qué no

Como esto se lanzó discretamente, vale la pena separar los dos explícitamente.

• Confirmado — los pesos existen y se pueden descargar bajo Apache 2.0; las dos marcas de tiempo de publicación están en los repositorios; la arquitectura, el número de parámetros, la longitud de contexto y la configuración de muestreo están todos en la configuración publicada y la tarjeta del modelo; la receta de entrenamiento y el diseño de recompensas están documentados con suficiente detalle como para debatirlos; el código, la pila de verificación y el generador de rúbricas son públicos; existe una versión acompañante de 32B.

• Sin confirmar — cualquiera de las cifras de benchmark, por parte de alguien distinto del proveedor. El artículo, que la propia documentación describe como en revisión. La identidad del evaluador de visión-lenguaje que está detrás de la mitad visual de las puntuaciones. Si algún proveedor lo alojará. Si el contexto de 24.576 tokens se sostiene en presentaciones reales de varias diapositivas, dado que la evaluación reportada es sobre páginas infográficas individuales. Y absolutamente cualquier cosa sobre el comportamiento fuera del inglés — la etiqueta de idioma de la tarjeta del modelo es "en" solamente.

Si quieres ejecutarlo, y cuánto cuesta eso

Qwen3-VL-8B-Instruct — el modelo a partir del cual se ajustó AesCode-8B, y la comparación individual más sólida disponible hasta que alguien publique un resultado independiente de AesCode — es otro asunto:

La ruta de servicio para AesCode-8B en sí es corta, y la tarjeta del modelo la proporciona directamente: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, con transformers 4.57 o posterior para la ruta sin vLLM, y un fragmento de Python que acepta una imagen de referencia opcional antes del mensaje de texto.

La aritmética que tienes que hacer tú mismo es la memoria. Los 17,5 GB de pesos bf16 tienen que caber junto con una caché KV para un contexto de 24.576 tokens y hasta dos imágenes, así que una sola tarjeta de 24 GB es técnicamente suficiente para los pesos e incómodamente ajustada para todo lo demás; 40-48 GB, o dos tarjetas de 24 GB, es el mínimo realista. El acompañante de 32B es un problema de otro orden: sus fragmentos suman 66,7 GB, así que necesita paralelismo de tensores y un nodo multi-GPU. Presupuesta también un renderizador: el modelo emite un documento HTML completo, y toda afirmación sobre su calidad se hace renderizando ese documento, así que puntuar tus propias salidas implica levantar Playwright con las solicitudes externas bloqueadas.

No necesitas generar una imagen de referencia en el momento de la inferencia —eso es exactamente lo que te aporta el resultado de 1,00 puntos—, pero la documentación deja claro que la calidad sigue siendo máxima cuando se proporciona una, así que la configuración honesta es con referencia opcional en lugar de sin referencia.

AesCode-8B no es algo que OrcaRouter enrute, y tampoco pudimos encontrarlo alojado en ningún otro sitio, así que una evaluación actualmente significa pesos en tu propio hardware. Su backbone es otra historia. Qwen3-VL-8B-Instruct sí se puede enrutar a través de OrcaRouter hoy a $0.18 por millón de tokens de entrada y $0.70 por millón de salida, con un contexto de 131.072 tokens — lo que lo convierte en la forma barata de ver qué hace la versión sin ajustar de esta arquitectura con tus propios prompts de infografías antes de gastarte una semana de GPU reproduciendo la receta de otro. OrcaRouter transfiere el precio de lista del proveedor con un 0 % de margen y hace failover automáticamente entre proveedores, así que esa comparación cuesta una sola clave y ningún segundo contrato; si AesCode-8B alguna vez llega a un proveedor que enrutemos, estará en el catálogo ese mismo día. Y si lo autoalojas, los modelos a los que recurrirías en producción son los que ya están detrás de ese único endpoint — que es la postura razonable para un modelo lanzado discretamente y con cero evaluación independiente.

Qué ver

Dos cosas, y ninguna es otra tabla de benchmarks.

El primero es el artículo. "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" se cita como en revisión para 2027, lo que se lee como un marcador de posición escrito en una entrada de BibTeX más que como una fecha programada. Hasta que aparezca un preprint o una versión final para publicación, la explicación del canal de recompensa anterior es un resumen de un abstract que nadie fuera del laboratorio puede leer —y las preguntas interesantes, como cómo maneja el Visual Graph Rubric un grafo de diseño que en sí mismo es incorrecto, solo se responden en el texto completo.

Lo segundo es el hosting. Un modelo de 8,8B con licencia Apache-2.0 que emite HTML estructurado y verificable es justo la forma que una plataforma adopta, porque la salida es inspeccionable de una manera en la que un JPEG no lo es. En el momento en que alguien lo sirve, esto deja de ser una decisión de autoalojamiento y se convierte en una decisión de enrutamiento, y la comparación de costos deja de girar en torno a las horas de GPU.

Lo que no hay que esperar es un veredicto limpio. Style es el techo para todos los sistemas de esa tabla, incluido este, y Style es la única dimensión que pregunta si una persona publicaría la página tal cual. La interpretación defendible de AesCode-8B es estrecha y real: es muy bueno en las partes del diseño visual que puede comprobar una máquina, es mediocre en la parte que no se puede comprobar, y es el primer modelo de pesos abiertos en este nicho en el que la brecha entre esas dos cosas es lo central del lanzamiento y no una casualidad de este.