AesCode-8B 悄然发布：微软的 8B 模型能以 HTML 编写幻灯片和仪表板

微软新发布中最有意思的数字是 1.00。不向 AesCode-8B——一个将幻灯片、海报和仪表板编写为可编辑的 HTML 和 CSS 的 80 亿参数模型——提供参考图像，其视觉得分会下降 1 分（满分 100 分）。同样不向 Qwen3-VL-8B-Instruct，即 AesCode-8B 微调所基于的开放权重模型，提供该参考图像，降幅为 19.55 分。对于 GPT-5.5，则为 10.04 分。真正的研究结果就体现在这一对比中，而它位于微软还发布的一个头条结果之下：在其自己的 300 个样本评分标准上，AesCode-8B 的总体得分 82.94 略高于带参考条件的 GPT-5.5 的 81.28 和 Claude Opus 4.8 的 80.39，而其更大的同系列模型，AesCode-32B，为 85.89。

这次发布没有任何公告。Microsoft 于 2026-10-07 在 Hugging Face 上以 Apache 2.0 许可提交了权重——AesCode-8B 以及一个同样基于 Qwen3-VL-32B-Instruct 构建的 32B 配套模型——并在次日将训练和评估代码推送至 GitHub。没有 Microsoft Research 博客文章，没有发布说明，没有产品页面，也没有预印本：模型卡中的引用写的是“审核中”，年份为 2027，这是一个占位符，而不是一个日期。截至 2026-10-11，8B 仓库显示 2 次下载和 1 个点赞；GitHub 仓库显示 1 颗星。下文所有带有数字的内容，要么是你可以自行核验的时间戳，要么是 Microsoft 就其自身评估集报告的数字——而这一区别在这里比通常更重要，因为该模型的任何部分都尚未被其他任何人测量过。

已发货的内容，以及不在包装盒内的物品

三个日期定义了这次发布，而它们也是其中仅有的日期。microsoft/AesCode-8B的 Hugging Face 仓库创建于 2026-09-29，权重以提交信息 "Release AesCode-8B" 于 2026-10-07 03:35 UTC 提交，而microsoft/AesCode代码仓库则在次日，即 2026-10-08 23:14 UTC 公开。32B 权重落在同一个提交时间窗内。其间没有任何地方发布过任何公告。

• 权重——四个 safetensors 分片总计 17,543,339,408 字节，换算下来大约是 88 亿个 bf16 参数。Microsoft 将该模型标为 8B；Hugging Face 的 size 字段则将其四舍五入为 9B。这只是四舍五入，并非数据矛盾。

• 架构 — Qwen3-VL 配方的一次直接微调：Qwen3VLForConditionalGeneration，36 个隐藏层，隐藏维度 4,096，32 个注意力头、8 个键值头，151,936 词元的词表，以及交错式 mrope 位置。它需要 transformers 4.57 或更高版本。

• 上下文与输出——所报告的各次运行使用了 24,576 个 token 的上下文，最多 12,000 个输出 token，在 temperature 0.8 和 top-p 0.95 下生成，每个提示进行三次 rollout，且不进行筛选。vLLM 服务命令允许每个提示包含两张图像：参考图像，除此之外别无其他，因为输出是文本。

• 许可证 — Apache 2.0，据描述沿用了 Qwen3-VL 主干架构。完全宽松，无门控限制，无附加的可接受使用条款。

• 不在盒中——训练与评估数据。该仓库提供了流水线，记录了预期的输入与输出，并提及了它所期望的划分文件，但无论是模型卡还是代码仓库，都未列出任何数据集发布。你拿到的是食谱，而不是食材。

• 同样不在开箱即用的范围内——也没有任何托管端点。我们在任何地方都找不到提供 AesCode-8B 服务的 API，它也不在我们自己的目录中。在有供应商收录它之前，要评估它就意味着把权重加载到你自己的 GPU 上。

微软采用的这一表述值得引用，因为它其实就是完整的设计纲要：代码模型“无法看到布局、层级和颜色如何在画布上融为一体”，而图像生成器“能组合出视觉上引人注目的页面，却常常错误呈现文本、数字和逻辑关系”。AesCode 正是试图从前者取构图感，从后者取可验证性。

1.00 分结果详解

第一段中那个数字背后的机制是这样的。在训练过程中，每条提示词都会与一张由它本身生成的参考图像配对——微软自己的运行使用 GPT-Image-2 生成图像，并使用 GPT-5.5 把简短的构想扩写成详细的内容提示词。参考图像不具备内容上的权威性；文本提示词始终是唯一的事实来源。参考图像所提供的是版式与风格，而奖励函数的设计正是为了让这两者保持分离。

结果是，视觉先验最终存在于策略中，而不是输入中。AesCode-8B 在推理时移除参考后会损失 1.00 个 Visual 分。它自己的主干网络在以参考为条件评估时达到 44.72 Visual，而若没有参考，则会损失 19.55 分。GPT-5.5 损失 10.04。归结起来就是：模型不再需要图片了。

结果的后半部分才是那个容易被忽略的地方。Microsoft 报告称，基于参考的奖励将仅提示的 Visual 从 25.17 提升到 69.71——这个在推理时从未见过参考的模型，仍然受益于曾针对这些参考进行训练。如果你原本打算在自己的流程中跳过参考生成这一步，那么这个数字说明，你在训练中也不该费心去跳过它。

关于这一切，诚实的提醒是：这是微软的评分标准，基于微软的300个信息图样本，每个提示评分三次，没有择优挑选。一半的分数来自确定性验证器，任何人都可以复现；另一半，即清单维度，由一个视觉语言模型评判，文档没有指明其身份。不知道是哪个评判者给出分数，你就无法复现另一半。

品味融入权重的所在

训练方法是本次发布中可迁移理念最多的部分，而它比输出所展现的更为机械。

• 一切首先都是一张图。每个目标都表示为一个设计图：节点代表文本、图表、表格、卡片、区域和图像槽位，边代表包含、对齐、顺序和连接。这张图的意义在于归属——画布上的每一个属性都属于一个具名元素，因此每一个属性都可以单独评分。

• 七个奖励通道。六个确定性验证器检查可解析的内容——执行、精确文本、边界、表格与图表数据、语义布局、空白——而一个针对具体样本的视觉图谱评分标准（Visual Graph Rubric）则对其余部分打分，该标准由围绕几何与位置、与图绑定的是/否问题构成。这些通道是执行、文本、边界、表格图表、布局、空白和设计。

• 各通道在合并之前会先进行归一化。GDPO 会在其 rollout 组内对每个通道分别归一化，因此密集的基于规则的信号不会淹没稀疏的视觉信号。在相同设置下，微软测得它相比普通标量 GRPO 高出 5.12 个 Visual 分——这虽是厂商自报的数据，但它是一项具体的消融实验，而非空口断言。

• 评分通过渲染完成。候选 HTML 会在沙箱化的 Playwright 浏览器中渲染，同时阻断外部请求，随后由测试框架回读 DOM、计算样式、边界框、控制台状态和一张截图。表格必须是 HTML 表格；图表必须是 ECharts 规格。这一约束确实在发挥实际作用——它迫使输出变成验证器可解析的形式。

• 配方本身。在 3,000 条演示数据上以 1e-5 的学习率进行冷启动监督微调，然后在 verl 的 FSDP-vLLM 混合引擎上针对 7,408 个提示进行 400 步的 GDPO，不使用 critic，也不单独训练奖励模型。AdamW 以恒定的 5e-6 运行，无预热，权重衰减为 0.01，每步 128 个提示、每个提示 8 次 rollout，KL 和熵系数均为 0.001，提示和响应均上限为 8,192 个 token。发布的运行使用了单节点八张 NVIDIA B200。AesCode-32B 使用相同配方运行 520 步。

从整体来看，这是一篇披着模型发布外衣的奖励设计论文——这与引文标注为“审稿中”而非指向预印本是一致的。

记分牌，以及谁为它背书

以下全部内容均为 Microsoft 在模型卡中报告的自身评估，基于 300 个信息图样本。Rule 对程序化的 Text、Bound 和 Chart 检查取平均；Visual 对 Content、Layout 和 Style 检查清单维度取平均；Overall 是这两者的均值。分数是每个提示词三次生成结果的平均百分比，且未进行任何挑选。“Ref.” 表示模型是否随提示词一起获得了一个生成的参考。

• AesCode-8B（带参考） — 文本 94.06、边界 88.36、图表 87.79、规则 90.07；内容 86.41、布局 87.80、风格 53.21、视觉 75.80；总体 82.94。

• 与其自身基座相比——经过参考条件化的 Qwen3-VL-8B-Instruct 在 Visual 上得分 44.72，Overall 得分 51.93。这意味着 Visual 提升了 31.1 分，Overall 提升了 31.0 分，而这也是表中结果最不出人意料的对比，因为整个训练的意义就在于视觉这一半。

对比 GPT-5.5，参考条件下的表现——总体 81.28，内容 82.44，布局 89.93，风格 57.57。

• 对比 Claude Opus 4.8，参考条件 — 总体 80.39，内容 86.42，布局 89.76。

• AesCode-32B，参考条件化—— 文本 95.34，边界 97.27，图表 90.37，规则 94.33，布局 90.58，视觉 77.44，总体 85.89。视觉得分比其自身的 32B 主干高出二十二点四分。

• 风格上限——表中没有一款模型能突破 60，而 GPT-5.5 的 57.91 是其中最高的。AesCode-8B 为 53.21。微软自己的定义毫不留情：只有当设计在交付前无需任何进一步的视觉修改时，风格才会为其计分。因此，在这项衡量人类是否会真正将页面未经编辑地直接上线的维度上，这款 8B 模型并非领先者。

• 边界失败——严重的画布溢出失败在 300 个样本中的复发率为 4.3%，而 GPT-5.5 为 34.7%。溢出这一失败模式会使生成的 HTML 无法使用，而不只是难看。

现在说和表格同样重要的部分。上面每一个数字都是厂商自报的，且无法复现。在我们能找到的任何独立排行榜上，都看不到 AesCode-8B 的身影；而它与 GPT-5.5 和 Claude Opus 4.8 的对比，是在微软的评分标准上跑的，任务本身也不是这些模型调优过的方向，其中"Layout"的定义更是只要产出一个页面就算数。Text 拿到 94.06 并不意味着这个模型在文本上胜过 GPT-5.5，它的意思是：在信息图页面上，它放置标签时不会与提示词相矛盾——这实在是个小得多的结论。Style 这一项的结果恰恰说明，评分标准并没有被做手脚偏向 AesCode——最大的榜单胜绩旁边，紧挨着最难看的那个数字。

哪些是已确认的，哪些不是

因为这个功能是悄悄上线的，所以有必要把两者明确区分开来。

• 已确认——权重确实存在，且可在 Apache 2.0 许可下下载；两个发布的时间戳都在代码仓库中；架构、参数规模、上下文长度和采样设置均见于已发布的配置与模型卡片；训练配方和奖励设计有足够详细的文档记录，可供质疑辩驳；代码、验证器栈和评分标准构建器均为公开；此外还存在一个 32B 的配套版本。

• 未经确认——任何基准测试数字，除供应商外无人证实。那篇论文，文档本身称其仍在评审中。评分中视觉部分背后的视觉语言评判者的身份。是否有任何提供商愿意托管它。24,576 token 的上下文在真实的多幻灯片演示文稿中是否站得住脚，因为所报告的评估是在单页信息图上进行的。以及任何关于英语之外行为的信息——模型卡的语言标签只有“en”。

如果你想运行它，以及这需要多少成本

Qwen3-VL-8B-Instruct——AesCode-8B 微调所基于的模型，也是在有人发布独立 AesCode 结果之前可用的最强单一对比对象——则另当别论：

AesCode-8B 本身的服务路径很短，模型卡直接给出了它：vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576；非 vLLM 路线则需要 transformers4.57 或更新版本，以及一段 Python 代码片段，它会在文本提示之前接受一个可选的参考图像。

你要自己算的那笔账是内存。17.5 GB 的 bf16 权重必须与 24,576 个 token 上下文以及最多两张图像的 KV cache 一起装下，所以单张 24 GB 显卡在技术上够放权重，但对其他所有东西来说都紧得难受；40–48 GB，或者两张 24 GB 显卡，才是现实的下限。32B 的配套模型则是另一个量级的问题——它的分片总计 66.7 GB，因此需要张量并行和多 GPU 节点。还要把渲染器也计入预算：该模型会输出一份完整的 HTML 文档，而关于它的每一项质量结论都是通过渲染该文档得出的，所以给自己的输出打分就意味着要搭建起屏蔽外部请求的 Playwright。

你不需要在推理时生成参考图像——这正是 1.00 分的结果为你换来的——但文档明确指出，在提供参考图像时质量仍然最高，因此诚实的设定是参考可选，而非无需参考。

AesCode-8B 并不是 OrcaRouter 会路由的模型，我们在其他地方也找不到它被托管，所以目前要评估它，就意味着得把权重部署到你自己的硬件上。它的主干网络则是另一回事。Qwen3-VL-8B-Instruct 如今可通过 OrcaRouter 路由，输入每百万 token 0.18 美元、输出每百万 token 0.70 美元，上下文长度为 131,072 个 token——这使它成为一种低成本方式，让你在花上一整周 GPU 时间复现别人的配方之前，先看看这个架构未经调优的版本在你自己的信息图提示词上表现如何。OrcaRouter 以 0% 加价透传提供商的目录价，并在提供商之间自动故障转移，所以这种比较只需一个密钥，无需再签一份合同；如果 AesCode-8B 将来出现在我们路由的某个提供商上，它当天就会进入目录。而如果你确实要自行托管它，你在生产环境中会回退使用的模型，正是已经位于那一个端点背后的模型——对于一款悄然发布、没有任何独立评估的模型来说，这是合理的姿态。

看什么

有两件事，而两者都不是另一张基准测试表。

第一项是那篇论文。“AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards”被标注为 2027 年处于审稿中，这读起来更像是随手填进 BibTeX 条目里的占位符，而不是一项日程安排。在预印本或最终定稿版出现之前，上面关于奖励通道的解释，不过是对一份实验室之外没人能读到的摘要的概括——而真正有趣的问题，比如 Visual Graph Rubric 如何处理一个本身就有误的设计图，只有在全文里才能得到解答。

第二点是托管。一个 8.8B 的 Apache-2.0 模型，能够输出结构化、可验证的 HTML，而这恰恰是平台会接手的形态，因为它的输出可以被审查，JPEG 则做不到这一点。一旦有人把它部署为服务，这就不再是一个自托管的决定，而变成了一个路由决策——成本比较也不再围绕 GPU 小时展开。

不该期待的是干脆利落的结论。Style 是那张表中每个系统的上限，包括这个系统，而 Style 是唯一一个追问人类是否会原样发布该页面的维度。对 AesCode-8B 站得住脚的解读既狭窄又真实：它非常擅长视觉设计中可由机器检查的部分，在无法由机器检查的部分则表现平平；而且在这个细分领域中，它是首个开放权重模型，其中这两者之间的差距是本次发布的核心，而非偶然。