AesCode-32B: el discreto modelo de 33B de Microsoft que escribe presentaciones como HTML editable

Las marcas de tiempo de AesCode-32B no concuerdan entre sí, y esa discrepancia es prácticamente todo lo que hay que informar. El repositorio de Hugging Face microsoft/AesCode-32B se creó el 29 de septiembre de 2026, pero todo lo que contiene llegó en un único commit fechado el 7 de octubre de 2026 cuyo mensaje es simplemente "Release AesCode-32B" — y el stack de entrenamiento que hace reproducible el resultado se subió a github.com/microsoft/AesCode el 8 de octubre. Microsoft no ha anunciado nada: ni entrada de blog, ni preprint en arXiv, ni envío a ninguna tabla de clasificación, ni página del modelo en su propio sitio. Lo que existe es un modelo de visión y lenguaje de 33 mil millones de parámetros que recibe un prompt y emite un documento HTML completo y autocontenido — una diapositiva, un póster, un panel — además de un acompañante más pequeño, microsoft/AesCode-8B. Ambos están ajustados a partir de modelos de visión de Qwen3-VL — Qwen3-VL-32B-Instruct y Qwen3-VL-8B-Instruct respectivamente — ambos son Apache 2.0, y ambos pueden descargarse hoy mismo.

El id del repositorio dice microsoft/AesCode-32B y la ficha comienza con el truco: AesCode empareja tu prompt con una imagen generada a partir de ese mismo prompt, usa la imagen como referencia estética y sigue el texto para el contenido real. Los generadores de imágenes componen una página atractiva y reproducen mal los números que aparecen en ella; los modelos de código aciertan con los números y no pueden ver cómo se ve la página. AesCode es un intento de tener ambas cosas, y el resumen honesto de ello a fecha de 11 de octubre de 2026 es que los pesos son reales y verificables, las cifras de benchmark son del propio laboratorio en un arnés que el laboratorio escribió, y nadie fuera de Microsoft ha publicado todavía una cifra al respecto. Este artículo mantiene esas tres categorías separadas de principio a fin.

¿Qué hay realmente en el repositorio, byte por byte?

Empieza por lo que puedes verificar sin confiar en una sola palabra de la tarjeta del modelo. El repositorio de 32B contiene catorce fragmentos safetensors que suman 66.714.912.704 bytes, lo que en BF16 equivale a aproximadamente 33,4 mil millones de parámetros — coherente con «33B params» de la tarjeta y con su advertencia de que solo los pesos necesitan unos 65 GB de memoria del acelerador. La configuración declara Qwen3VLForConditionalGeneration como la arquitectura y qwen3_vl como el tipo de modelo, por lo que no se trata de una arquitectura nueva ni necesita una: se carga con transformers>=4.57, y la tarjeta incluye un comando de vLLM que lo sirve en cuatro rangos de paralelismo tensorial, con dos imágenes permitidas por prompt y un límite de 24.576 tokens.

Los contadores de interacción son la parte más silenciosa del lanzamiento. Dos descargas y un me gusta en el repositorio de 32B en el momento de escribir esto. No hay ninguna entrada en el mapeo de proveedores de inferencia de Hugging Face, lo que significa que no hay ningún endpoint alojado conectado detrás de la página del repositorio, y no se anuncia en ninguna parte una compilación de GGUF, MLX o llama.cpp. Para un modelo que lleva el nombre de Microsoft y que obtiene resultados que superan a GPT-5.5 en la propia tabla del proveedor, esa es una huella llamativamente pequeña, y es la evidencia más sólida disponible de que esto se publicó sin un lanzamiento detrás.

El repositorio de código complementario completa la otra mitad de la línea temporal, y es donde la cuestión de la fecha de lanzamiento se vuelve genuinamente ambigua. microsoft/AesCode se creó el 23 de julio de 2026 —diez semanas antes de los pesos— y contiene catorce commits, todos ellos creados por el mismo colaborador y todos ellos con marcas de tiempo que no distan más de veinte segundos entre sí el 8 de octubre de 2026, entre las 23:14:04 y las 23:14:24 UTC. Incluyen la especificación para generar prompts y requisitos verificables, el pipeline de datos que construye grafos de diseño y preguntas de rúbrica, una etapa de SFT de inicio en frío, el bucle de aprendizaje por refuerzo GDPO, un verificador de renderizado basado en Playwright, pruebas y el README que documenta todo ello. No hay lanzamientos ni etiquetas, la descripción del repositorio está vacía y tiene una estrella.

Entonces, ¿cuál es la fecha de lanzamiento? El registro del repositorio dice 29. El commit que contiene el modelo dice 7. El código que explica cómo se creó el modelo dice 8. Tres marcas de tiempo dentro de una única ventana de dos semanas, ninguna de ellas acompañada de una frase de Microsoft que diga "vamos a publicar esto". Considera el 7–8 de octubre como la fecha operativa para los artefactos que la mayoría de la gente descargará realmente, y el 29 de septiembre como la fecha en que se reservó el repositorio. Cualquiera que te diga que AesCode-32B "se lanzó" en un día concreto está eligiendo una de esas marcas de tiempo por ti.

El mecanismo: una imagen como guía estética, un gráfico como la recompensa

La afirmación técnica de la tarjeta es acotada y específica, lo cual es un punto a su favor. El modelo se entrena con ajuste fino supervisado de arranque en frío sobre 3.000 demostraciones con una tasa de aprendizaje de 1e-5, y luego con GDPO —una variante de optimización de políticas relativa a grupos— sobre 7.408 prompts durante 520 pasos. El modelo de 8B usó la misma receta y se detuvo a los 400 pasos. La ejecución de RL usó 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 y sin warmup, 128 prompts por paso con ocho rollouts cada uno, y tanto el prompt como la respuesta limitados a 8.192 tokens cada uno.

Lo que hace inusual a la recompensa es que no es un único escalar. Cada objetivo de entrenamiento se describe como un grafo de diseño que cubre todo el lienzo, de modo que las propiedades individuales se pueden atribuir por separado. De ese grafo provienen siete canales — ejecución, texto, límite, gráfico de tabla, maquetación, espacio en blanco y diseño —, cada uno normalizado dentro de su grupo de rollout antes de la agregación, de modo que una señal dominante no pueda opacar a las demás. Los verificadores deterministas puntúan lo que se puede analizar sintácticamente del código y su renderizado; un juez de visión y lenguaje puntúa lo que no, utilizando una rúbrica vinculada a los propios elementos y relaciones del grafo. El HTML candidato se puntúa renderizándolo en un navegador Playwright en espacio aislado con las solicitudes externas bloqueadas, lo que exporta el DOM, los estilos computados, los cuadros delimitadores, el estado de la consola y una captura de pantalla.

La consecuencia de ingeniería merece mencionarse porque se manifiesta en la salida que recibes: el modelo está entrenado para emitir tablas como estructuras de tabla HTML reales y gráficos como especificaciones de ECharts, de modo que ambos se pueden inspeccionar directamente en lugar de estar incrustados en píxeles. Esa es la diferencia entre una presentación que puedes entregar a un diseñador y una presentación que puedes entregar a un linter. Los requisitos de reproducción son correspondientemente exigentes — el README pide Python 3.10, CUDA 12.6 y un nodo de ocho GPU B200, fija un commit específico de verl y afirma claramente que se requiere un parche sobre él porque la versión estándar de verl carece de soporte para Qwen3-VL, y advierte que, sin las bibliotecas de sistema de Playwright, el navegador falla al iniciarse y las páginas obtienen cero, y que, sin el stack de OCR fijado, el canal de recompensa correspondiente devuelve cero en lugar de abstenerse y corrompe silenciosamente la señal.

La tabla de referencia, y las cuatro razones para no aferrarse a ella

Las cifras destacadas de AesCode-32B provienen de 300 muestras de infografías, tres generaciones por prompt con temperatura 0,8 y top-p 0,95, de hasta 12.000 tokens de salida cada una, sin selección entre las generaciones. Las puntuaciones son porcentajes. Con referencia, el modelo de 32B reporta Texto 95,34, Límite 97,27, Tabla/Gráfico 90,37 y un promedio de reglas de 94,33; en el lado visual, Contenido 85,76, Diseño 90,58, Estilo 55,99, para un promedio visual de 77,44 y una puntuación global de 85,89. En la misma tabla, GPT-5.5 con una referencia obtiene una puntuación global de 81,28 y Claude Opus 4.8 con una referencia obtiene una puntuación global de 80,39, mientras que el modelo base Qwen3-VL-32B-Instruct, a partir del cual se entrenó el modelo, obtiene 61,10.

Cuatro salvedades deben mencionarse junto con esas cifras, y ninguna de ellas desprestigia el trabajo. Primero, cada fila, incluidas las de GPT-5.5 y Claude Opus 4.8, fue ejecutada por Microsoft en el arnés de Microsoft con la rúbrica de Microsoft: esas no son las cifras de los otros laboratorios, son mediciones que Microsoft hizo de los modelos de sus competidores, y la propia ficha llama a la rúbrica «específica de la muestra» para cada grafo de diseño. Segundo, la rúbrica es producida por el mismo pipeline que generó los datos de entrenamiento, que es exactamente la configuración en la que un benchmark puede desviarse hacia las fortalezas de un modelo; la ficha es sincera sobre los límites de esa rúbrica: a Estilo, que exige que un diseño no necesite ninguna revisión visual adicional antes de la entrega, se le llama «el techo compartido para todos los sistemas», y ningún modelo de la tabla supera los 60. Tercero, no hay ninguna medición independiente de este modelo en ningún lugar: ninguna entrada en una tabla de clasificación de terceros, ninguna reproducción y, dadas dos descargas, casi con certeza nadie fuera del laboratorio lo está ejecutando todavía. Cuarto, la comparación es sutilmente asimétrica de una manera que vale la pena notar: las filas de AesCode-32B están todas condicionadas por referencia, así que el modelo se está midiendo en la configuración para la que fue entrenado, lo cual la ficha reconoce al mostrar que la calidad sigue siendo la más alta cuando se proporciona una referencia.

El único resultado de la tabla que se sostiene mejor que el titular es una afirmación de robustez, no de calidad. Omitir la imagen de referencia en inferencia le cuesta a AesCode-8B solo 1,00 punto Visual, frente a 19,55 de su modelo base Qwen3-VL-8B-Instruct y 10,04 de GPT-5.5. El argumento de la tarjeta es que el entrenamiento condicionado por referencias internaliza la planificación visual en la política en lugar de enseñar al modelo a copiar lo que ve. Eso lo reporta el proveedor y no se ha reproducido, y además es el tipo de afirmación que una sola ejecución independiente resolvería —y el tipo que más importa en producción, donde no siempre tendrás una imagen de referencia a mano.

Cuánto cuesta ejecutarlo y qué significa eso para la comparación

Nada en este modelo es barato de autoalojar. Entre diez y doce mil tokens de salida es el tamaño de trabajo de un solo artefacto, y un documento HTML completo con una especificación de ECharts está más cerca del extremo superior de ese rango que del inferior, así que cada generación es una decodificación larga. La propia receta de servicio de la tarjeta exige cuatro GPUs en paralelismo de tensores para sostener aproximadamente 65 GB de parámetros BF16, y la receta de entrenamiento exige ocho B200. Eso es una máquina real, no un despliegue de aficionado, y establece los términos de la comparación: los modelos con los que se mide AesCode-32B se alquilan por token, y el modelo en sí se alquila por GPU-hora, ya sea que poseas el hardware o no.

La forma práctica de esa comparación es precisamente la razón por la que existe una capa de enrutamiento, y vale la pena ser exactos sobre lo que alojamos y lo que no. AesCode-32B no está en el catálogo de OrcaRouter y no lo servimos: no hay ningún endpoint alojado para él en ningún sitio que yo pueda verificar, incluido el de Microsoft. Lo que sí está en el catálogo es el otro lado de la balanza: los modelos alojados con los que compararías un generador de artefactos autoalojado, incluidos GPT-5.5 y los modelos de visión Qwen3-VL más pequeños, accesibles a través de una sola clave de API al precio de lista del proveedor con un 0% de margen, lo que significa que un cambio de precio del proveedor se refleja en nuestro lado el mismo día. Comparar un endpoint alquilado con un modelo que ejecutas tú mismo no necesita un segundo contrato ni un segundo SDK, y un DSL de enrutamiento permite que una llamada autoalojada se sitúe junto a las alojadas detrás de un único endpoint. Si resulta que AesCode-32B es bueno en eso único que afirma su ficha, el coste de averiguarlo es una factura de GPU, y el coste de las alternativas con las que lo comparas es una clave que probablemente ya tienes.

Lo que puedes hacer con ello hoy, y lo que no

• Descárgalo y ejecútalo — los pesos son Apache 2.0, siguiendo el backbone Qwen3-VL, con catorce fragmentos BF16 y un transformers funcional a partir de la versión 4.57 y una receta de vLLM en la ficha.

• Reproduce el entrenamiento — el código tiene licencia MIT y es lo bastante completo como para ser significativo: el verificador de recompensas, el generador de rúbricas, las etapas de SFT y GDPO, un commit de verl fijado más el parche que añade compatibilidad con Qwen3-VL, y un README que enumera los modos de fallo en lugar de ocultarlos.

• Evalúalo sin referencia — el modelo acepta prompts con o sin la imagen de referencia, y la afirmación más comprobable de la tarjeta reside en esa configuración.

• Conseguir una API para ello — no puedes. No hay un endpoint alojado, ni una asignación de proveedor de inferencia en el repositorio, ni una compilación para GGUF o MLX; ejecutar esto significa ejecutar el hardware.

• Lee el artículo — todavía no puedes. La ficha enlaza un artículo titulado AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, y su propia entrada de BibTeX indica que el lugar de publicación es "en revisión" y que el año es 2027. Una búsqueda en arXiv no devuelve ningún artículo con ese título. Existe un artículo anterior y diferente de Microsoft con un nombre casi idéntico — Code Aesthetics with Agentic Reward Feedback de octubre de 2025, que publicó un modelo AesCoder-4B y un conjunto de datos AesCode-358K — y nada en la ficha de AesCode-32B lo cita ni declara una relación con él. Si buscas lecturas de contexto y terminas en ese otro, estarás leyendo sobre un modelo diferente creado por autores que se solapan.

• Compararlo en una tabla de clasificación pública: todavía no. Ningún índice de terceros parece haberlo evaluado, lo cual no sorprende para un repositorio con dos descargas.

¿Quién debería preocuparse y quién debería esperar?

El público para esto es más reducido de lo que sugiere la tabla del titular y más específico que «cualquiera que construya con modelos». Si tu producto convierte prompts en presentaciones, pósteres, informes o paneles que alguien tiene que editar después, ya has descubierto la disyuntiva a la que apunta este modelo: la generación de imágenes te da un rectángulo precioso que no puedes cambiar, y la generación de código te da algo editable que parece ensamblado por un compilador. Un modelo abierto de 33B que emite un documento HTML completo con tablas reales y especificaciones de ECharts, que se mantiene a aproximadamente un punto de su calidad condicionada por referencia cuando no tienes ninguna referencia que darle, y que puedes afinar con tu propio estilo de la casa bajo Apache 2.0, es algo genuinamente útil de que exista. Ningún otro modelo hace exactamente ese trabajo a este tamaño y con estas condiciones.

En contra de eso: todo lo que sabes sobre la calidad proviene de una tabla que el proveedor construyó, la rúbrica detrás de ella fue producida por el mismo pipeline que creó los datos de entrenamiento, y el único techo que la tarjeta admite —Style por debajo de 60 para cada sistema probado— es precisamente la dimensión que un producto sensible al diseño valoraría más. Un equipo con una razón de cumplimiento para mantener la generación en casa y un nodo de repuesto de ocho GPU tiene suficiente para empezar hoy. Un equipo que elija un modelo para producción la próxima semana no tiene un número independiente en el que basarse, y no debería leer el 85.89 frente al 81.28 como un resultado definitivo.

¿Qué convertiría esto en una historia?

Cuatro cosas, ninguna de las cuales existe todavía. Un anuncio — Microsoft no ha dicho nada, y el artículo que cita la tarjeta está explícitamente en revisión, así que un informe técnico con detalles de entrenamiento más allá del resumen de la tarjeta podría aparecer en cualquier momento. Una ejecución independiente — la afirmación de robustez sin referencia y la puntuación Boundary, que según la tarjeta cae a un fallo grave en el 4,3 % de las muestras frente al 34,7 % de GPT-5.5, son ambas baratas de probar y ambas merecen ser probadas. Soporte de serving fuera de la receta del proveedor — una compilación GGUF o una entrada en un runtime convencional cambiaría la historia del hardware más que cualquier benchmark. Y un segundo punto de datos sobre la cuestión del tamaño: un modelo 8B que obtiene 82,94 en Overall frente al 85,89 del 32B en la misma tabla es una diferencia de dos puntos con un cuarto de los parámetros, que es el tipo de cosa que o bien se reproduce o bien deja de mencionarse en silencio.

Hasta que uno de esos se materialice, la descripción precisa de AesCode-32B es esta: pesos reales bajo una licencia permisiva, una pila de entrenamiento lo bastante detallada como para ser reproducida por un laboratorio bien equipado, un benchmark que es la medición de una empresa de su propio modelo y de dos competidores, y un historial de repositorio que no te permite llamar a ningún día concreto la fecha de lanzamiento. Es un artefacto más interesante de lo que sugiere su contador de dos descargas, y uno menos probado de lo que implica su 85.89. Ambas mitades de esa frase son la lectura honesta el 11 de octubre de 2026.