AesCode-32B：微软低调的 33B 模型，可将演示文稿写成可编辑的 HTML

AesCode-32B 上的时间戳彼此矛盾，而这一矛盾本身几乎就是全部可报告的内容。Hugging Face 仓库 microsoft/AesCode-32B 创建于 2026 年 9 月 29 日，但其中的所有内容都是在日期为 2026 年 10 月 7 日的单个提交中一次性加入的，提交信息仅是“Release AesCode-32B”——而让该结果可复现的训练栈则于 10 月 8 日被推送到 github.com/microsoft/AesCode。微软没有发布任何公告：没有博客文章，没有 arXiv 预印本，没有排行榜提交，也没有在其自家网站上的模型页面。现有的是：一个 330 亿参数的视觉语言模型，它接收提示并输出一份完整、自包含的 HTML 文档——一页幻灯片、一张海报、一个仪表盘——外加一个规模更小的配套模型 microsoft/AesCode-8B。二者均基于 Qwen3-VL 视觉模型微调而来——分别是 Qwen3-VL-32B-Instruct 和 Qwen3-VL-8B-Instruct——二者均采用 Apache 2.0 许可，且如今均可下载。

该仓库的 id 显示为microsoft/AesCode-32B，而模型卡一开篇就点出了那个窍门：AesCode 会把你的提示词与一张由同一提示词生成的图像配对，把图像当作美学参照，再依照文本确定实际内容。图像生成器能排出一张好看的页面，却会把上面的数字渲染错；代码模型数字算得对，却看不出页面长什么样。AesCode 试图两者兼得，而截至 2026 年 10 月 11 日，对它最诚实的概括是：权重是真实且可核验的，基准测试数字是实验室自己用自研评测框架跑出来的，而微软之外还没有人公布过它的任何数字。本文自始至终都把这三类东西分得清清楚楚。

仓库里实际到底有什么，逐字节地看

从无需相信模型卡上任何一个字就能验证的内容入手。这个 32B 仓库包含十四个 safetensors 分片，总计 66,714,912,704 字节，在 BF16 下大约是 334 亿参数——与模型卡所称的"33B 参数"一致，也与其警告相符：仅权重就需要约 65 GB 的加速器内存。配置声明 Qwen3VLForConditionalGeneration 为架构、qwen3_vl 为模型类型，因此这并不是一个新架构，也不需要是：它可通过 transformers>=4.57 加载，而且模型卡还附带了一条 vLLM 命令，可在四个张量并行 rank 上提供服务，每个提示词允许两张图像，上限为 24,576 个 token。

互动数据是这次发布中最安静的部分。截至本文撰写时，32B 仓库只有两次下载和一个点赞。Hugging Face 的推理服务商映射中没有相关条目，这意味着仓库页面背后没有接入任何托管端点，也没有在任何地方宣传 GGUF、MLX 或 llama.cpp 构建。对于一个挂着微软之名、且在厂商自家表格上成绩超过 GPT-5.5 的模型来说，这样的足迹小得惊人——而这正是最有力的证据，说明它上线时背后并没有一场发布活动。

配套代码仓库补全了时间线的另一半，而也正是在这里，发布日期的问题才真正变得模糊不清。 microsoft/AesCode创建于 2026 年 7 月 23 日——比权重早了十周——包含十四个提交，每一个都由同一位贡献者提交，且每一个的时间戳都落在 2026 年 10 月 8 日彼此相差二十秒的范围内，即 UTC 23:14:04 到 23:14:24 之间。它们包括用于生成提示词和可验证需求的规范、构建设计图和评分问题的数据管道、冷启动 SFT 阶段、GDPO 强化学习循环、基于 Playwright 的渲染验证器、测试，以及记录这一切的 README。该仓库没有发布版本，也没有标签，仓库描述为空，并且只有一个星标。

那么，发布日期到底是哪一天？仓库记录显示的是 9 月 29 日。包含该模型的提交显示的是 10 月 7 日。解释该模型如何制作出来的代码显示的是 10 月 8 日。三个时间戳都落在同一个两周窗口内，却没有一个伴随着 Microsoft 的一句“我们正在发布这个”。把 10 月 7 日至 8 日视为大多数人实际会下载的那些产物的生效日期，而把 9 月 29 日视为仓库被预留的日期。任何告诉你 AesCode-32B 在某一天“发布”的人，都是在替你从这些时间戳中挑一个。

机制：以图像为审美，以图为奖励

这张卡片的技术主张范围狭窄而具体，这一点对它是加分项。该模型先通过冷启动监督微调，在 3,000 条演示上以 1e-5 的学习率进行训练，然后使用 GDPO——一种组相对策略优化变体——在 7,408 条提示上训练 520 步。8B 模型使用了相同的配方，并在 400 步时停止。这次 RL 运行使用了 verl 的 FSDP-vLLM 混合引擎，没有 critic，也没有单独训练的奖励模型；使用 AdamW，恒定 5e-6，无预热；每步 128 条提示，每条提示八次 rollout，并且提示和响应各自上限为 8,192 个 token。

这种奖励的不同寻常之处在于，它不是单个标量。每个训练目标都被描述为覆盖整个画布的设计图，因此各个属性可以分别归因。从该图衍生出七个通道——执行、文本、边界、表格图表、布局、留白和设计——每个通道在聚合前都会在其 rollout 组内进行归一化，以免某一个占主导的信号淹没其他信号。确定性验证器对可从代码及其渲染中解析出的内容进行评分；视觉语言评判器则对无法解析的内容进行评分，它使用与图自身元素和关系相关联的评分标准。候选 HTML 的评分方式是在一个沙箱化的 Playwright 浏览器中渲染它，并阻止外部请求；该过程会导出 DOM、计算样式、边界框、控制台状态和一张截图。

其工程上的影响值得说明，因为它会体现在你收到的输出中：该模型被训练为将表格输出为真正的 HTML 表格结构、将图表输出为 ECharts 规范，因此二者都可以直接检查，而不是固化在像素之中。这就是你能交给设计师的演示文稿，与你能交给 linter 的演示文稿之间的区别。相应地，复现要求也很重——README 要求 Python 3.10、CUDA 12.6 和一个配备八块 B200 GPU 的节点，锁定了一个特定的 verl 提交，并明确说明必须针对它打补丁，因为原版 verl 缺少 Qwen3-VL 支持；还警告说，如果没有 Playwright 系统库，浏览器会在启动时失败，页面得分为零；如果没有锁定版本的 OCR 栈，相应的奖励通道会返回零而不是弃权，并悄悄污染信号。

基准表，以及不宜对其过于执着的四个理由

AesCode-32B 的主要数据来自 300 个信息图样本，每个提示生成三次，温度为 0.8、top-p 为 0.95，每次最多输出 12,000 个 token，且不对各次生成结果进行挑选。分数均为百分比。在参考条件下，32B 模型报告文本 95.34、边界 97.27、表格/图表 90.37，规则平均分为 94.33；在视觉方面，内容 85.76、布局 90.58、风格 55.99，视觉平均分为 77.44，总体得分为 85.89。在同一张表格中，有参考时 GPT-5.5 的总体得分为 81.28，有参考时 Claude Opus 4.8 的总体得分为 80.39，而该模型训练所基于的 Qwen3-VL-32B-Instruct 主干模型得分为 61.10。

这四个附加说明应当与那些数字放在一起看，而它们都不是对这项工作的抹黑。第一，包括 GPT-5.5 和 Claude Opus 4.8 在内的每一行，都是由微软在微软的测试框架上、用微软的评分标准运行的——这些不是其他实验室的数字，而是微软对竞争对手模型的测量结果，并且评估卡本身也指出该评分标准对每个设计图都是“样本特定的”。第二，该评分标准是由生成训练数据的同一流程产出的，而这恰恰是基准可能向模型强项漂移的典型情形；评估卡坦率地说明了该评分标准的局限——Style，即要求设计在交付前无需进一步视觉修改，被称为“每个系统的共同上限”，而表中没有任何模型超过 60。第三，对该模型没有任何独立测量：没有第三方排行榜条目，没有复现，而且考虑到两次下载量，几乎可以肯定实验室之外还没有人运行过它。第四，这一比较存在一种微妙的不对称，值得注意——AesCode-32B 的各行全都是参考条件化的，因此该模型是在它为训练而设定的配置下被测量的，评估卡也承认这一点，因为它显示出在提供参考时质量仍然最高。

表格中唯一比标题更站得住脚的结果，是一项关于鲁棒性的说法，而不是关于质量的说法。在推理时扣留参考图像，AesCode-8B 在 Visual point 上仅损失 1.00，而它的 Qwen3-VL-8B-Instruct 主干损失 19.55，GPT-5.5 则损失 10.04。模型卡给出的论点是：参考条件训练把视觉规划内化进了策略之中，而不是教模型去照抄它所看到的东西。这属于厂商自报、且未经复现的说法，同时也是那种只要有一次独立运行就能定论的说法——而在生产环境中，这类说法最为重要，因为你并不总是手边就有参考图像。

运行成本是多少，以及这对比较意味着什么

这个模型的自托管成本一点都不低。单个产物的常规规模就是一万到一万两千个输出 token，而带 ECharts 配置的完整 HTML 文档更接近这个区间的上限而非下限，所以每次生成都是一次漫长的解码。该模型自身的部署方案要求用四块 GPU 做张量并行，才能容纳约 65 GB 的 BF16 参数，而训练方案则要求八块 B200。这是一台实打实的机器，不是业余部署，也正因此划定了对比的前提：AesCode-32B 所对标的那几个模型是按 token 租用的，而模型本身则是按 GPU 小时租用的，无论硬件是不是你自己的。

这种对比的实际形态，正是一个路由层存在的意义所在，而精确说明我们托管什么、不托管什么，是值得的。AesCode-32B 并不在 OrcaRouter 的目录中，我们也不提供它——在我能核实的任何地方，都没有它的托管端点，微软的也算在内。目录里的是牌桌的另一边：你会用来对自托管产物生成器做基准测试的那些托管模型，包括 GPT-5.5 和 更小的 Qwen3-VL 视觉模型，只需一个 API 密钥即可访问，按提供商目录价、零加价，这意味着供应商调价当天就会在我们这边生效。把租用的端点与你自己运行的模型作比较，不需要第二份合同或第二个 SDK，而路由 DSL 能让自托管调用与托管调用并排置于同一个端点之后。如果 AesCode-32B 真如它的卡片所宣称的那样擅长那一件事，那么验证的代价就是一张 GPU 账单，而你所对比的替代方案的代价，则是你大概早已拥有的一个密钥。

你今天可以用它做什么，以及哪些尚不存在

• 下载并运行它——权重采用 Apache 2.0 许可，遵循 Qwen3-VL 主干，包含十四个 BF16 分片，并有一条可用的 transformers 4.57 以上版本的路径，以及卡片中提供的 vLLM 配方。

• 复现训练过程——代码采用 MIT 许可，且完整到足以真正发挥作用：奖励验证器、评分标准构建器、SFT 与 GDPO 阶段、一个固定版本的 verl 提交以及为其添加 Qwen3-VL 支持的补丁，还有一份 README，其中列出而非掩盖各种失败模式。

• 以无参考方式评估它——该模型接受带或不带参考图像的提示，而卡片中最可验证的说法正存在于该配置中。

• 为它获取 API——你做不到。没有托管端点，仓库上也没有推理提供商映射，也没有 GGUF 或 MLX 构建；运行它就意味着运行硬件。

• 阅读论文——你现在还做不到。卡片链接了一篇题为AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards的论文，而它自己的 BibTeX 条目把发表场所写为“Under review”，年份写为 2027。在 arXiv 上搜索，找不到任何以此为题目的论文。另有一篇更早的、名称几乎相同的微软论文——Code Aesthetics with Agentic Reward Feedback，发表于 2025 年 10 月，发布了 AesCoder-4B 模型和 AesCode-358K 数据集——而 AesCode-32B 的卡片中没有任何内容引用它，也没有说明与它有何关系。如果你去找背景资料，结果却翻到了那一篇，那你读到的就是另一个模型，只是作者有所重叠。

• 在公开排行榜上进行比较——还没有。似乎没有任何第三方索引对其做过评估，考虑到这是一个只有两次下载的代码仓库，这并不令人意外。

谁应该关注，谁应该等待

这个模型的受众比标题表格所暗示的要窄，也比“任何拿模型来做东西的人”更具体。如果你的产品把提示词变成幻灯片、海报、报告或仪表板，而之后还得有人去编辑，那你已经发现了这个模型所针对的那个取舍：图像生成给你一个漂亮但改不动的矩形，代码生成给你一个可编辑、但看起来像是编译器拼装出来的东西。一个 33B 开放权重模型，能输出带有真实表格和 ECharts 配置的完整 HTML 文档，在你没有参考可提供时，其质量仍能保持在与有参考条件时相差约一个百分点的范围内，而且你可以在 Apache 2.0 下按自家的风格对它进行微调——这样的东西存在，确实很有用。没有别的模型能在这个规模上、以这些条款做到这件确切的事。

与此相对：你对质量的所有了解都来自供应商自建的一张表，其背后的数据由与生成训练数据相同的流程产出，而它所承认的唯一上限——所有被测系统的风格得分均为60——恰恰是对设计敏感的产品最关心的维度。一个有合规理由将生成保留在内部、并有一台备用八GPU节点的团队，今天就有足够条件开始。一个下周就要为生产选择模型的团队，则没有独立数据可作为选择依据，也不应把85.89对81.28解读为已成定论的结果。

什么能让它变成一个故事？

四件事，目前一件都还不存在。一项公告——微软什么都没说，而卡片引用的论文明确处于评审中，因此一份包含超出卡片摘要的训练细节的技术报告随时可能出现。一次独立运行——无参考的鲁棒性声明和 Boundary 分数（卡片称其在 4.3% 的样本上跌至严重失败，而 GPT-5.5 为 34.7%）测试起来都很便宜，也都值得测试。厂商配方之外的服务支持——一个 GGUF 构建或主流运行时条目对硬件叙事的影响会比任何基准测试都大。以及在规模问题上的第二个数据点：同一张表上，8B 模型 Overall 得分 82.94，而 32B 为 85.89，用四分之一的参数换来两分的差距，这种事要么被复现，要么悄悄不再被提及。

在其中任何一项成为现实之前，对 AesCode-32B 的准确描述是这样的：以宽松许可证发布的真实权重，一套详尽到足以让装备齐全的实验室复现的训练栈，一张基准测试表——内容是某家公司对自家模型以及两个竞争对手模型的测量结果，以及一份仓库历史，让你无法把任何单独一天称为发布日。它是一件比其两次下载计数器所显示的更有趣的产物，也是一件比其 85.89 所暗示的更缺乏验证的产物。这句话的两半，都是对 2026 年 10 月 11 日的诚实解读。