AesCode-8B 与 Qwen3-8B：看似父子，实则不然

这些名字容易让人犯错。AesCode-8B是一个以 Qwen3-VL-8B-Instruct 为骨干的 8B 模型，Qwen3-8B是厂商自家的 8B 模型，而最直观的解读是：前者是后者的微调版。事实并非如此。AesCode-8B 公开的配置声明Qwen3-VL-8B-Instruct为基座——它是视觉语言的兄弟模型，一个承担不同任务的、不同的检查点——而 Hugging Face 元数据将其列为该模型的微调版，而非纯文本的 Qwen3-8B 的微调版。在这个权重级别中，两个 AesCode 模型是表亲，而非父子；这一区别正是本页之所以有用的全部原因：它告诉你，当 Microsoft 从一个视觉语言检查点起步时买到了什么，这在文本侧付出了什么代价，以及为什么与该家族中普通的 8B 通用模型进行比较，最终衡量的是一个分支，而不是一次升级。

两者均采用 Apache 2.0 许可，也都可下载，但它们的发布记录可谓天差地别。Qwen3-8B 于 2025 年 4 月发布，属于该厂商 Qwen3 代产品线的一部分，背后有配套文档、生态集成以及他人长达十八个月的部署经验。AesCode-8B 的文件中遍寻不见任何发布日期。微软于 2026-09-29 创建了 Hugging Face 仓库，于 2026-10-07 03:35 UTC 以“Release AesCode-8B”为提交信息提交了权重，并于次日将训练代码放到 GitHub 上。没有微软研究院的博文，没有发布说明，没有产品页面，也没有论文——模型卡的引用一栏写着“审稿中”，年份是占位符 2027，而截至本文撰写时，该仓库显示只有两次下载。下文关于 AesCode-8B 的一切量化数据均出自微软自己，无人复现。

名字所隐藏的家谱

Qwen3 系列包含若干个 8B 级别的检查点，它们同源，除此之外共同点并不多。Qwen3-8B 是纯文本通用模型：总参数量约 82 亿，其中约 70 亿为非嵌入参数，采用分组查询注意力，原生上下文为 32K token，可通过 YaRN 扩展至 131K，并在 119 种语言和方言上训练。它能推理、聊天、编码和调用工具，正因如此，它也是开放生态中自托管最广泛的 8B 模型之一。Qwen3-VL-8B-Instruct 是多模态成员：属于同一代模型家族，在其之上配有专用视觉塔，输入图像和文本，输出文本。

微软是从第二个开始的。AesCode-8B 的配置显示为 Qwen3VLForConditionalGeneration，具有 36 个隐藏层、隐藏维度 4,096、32 个注意力头和 8 个键值头，词表大小为 151,936 个 token，并采用交错的 mrope 位置，而且需要 transformers 4.57 或更新版本。这些分片总计 17,543,339,408 字节，约 88 亿个 bf16 参数，这就是为什么 Hugging Face 四舍五入后的大小字段显示为 9B，而厂商说的是 8B。这是四舍五入，而不是矛盾；参数数量并不是关键的分叉点——输入模态和 24,576-token 的服务上下文才是。

所以，诚实的说法不是“通用模型对它的微调版”。而是：一个拥有长上下文和十八个月生产历史的文本通用模型，对比一个能输出文档、且从未经过独立评估的多模态研究检查点。

微软把训练预算花在了什么上

设计说明被引用在模型卡上，它解释了这个分岔：代码模型“看不到布局、层级和色彩如何在画布上融为一体”，而图像生成器“能组合出视觉上引人入胜的页面，却常常把文字、数字和逻辑关系渲染错”。AesCode 试图从前者取来构图感，从后者取来可验证性，而它的配方在某个特定方面颇为不同寻常。

每个训练提示词都与一张由同一提示词生成的参考图像配对——微软自己的运行使用 GPT-Image-2 生成图像，并使用 GPT-5.5 将简短说明扩写为详细的内容提示词。参考图像只承载布局和风格；文本提示词在内容上仍具有权威性。那么到了推理阶段，模型几乎不需要它：对 AesCode-8B 不提供参考图像，其 Visual 分数仅下降 1.00 分（满分一百），相比之下主干模型下降 19.55 分，GPT-5.5 下降 10.04 分。一个相关结果是，基于参考的奖励将仅提示词的 Visual 分数从 25.17 提升到 69.71，因此视觉先验被移入权重之中，而不是停留在输入里。

其余部分是一个关于奖励设计的故事。监督是一张由节点和边构成的“设计图”——文本、图表、表格、卡片、区域、图像槽位，以包含、对齐、顺序和连接作为边——这样选择是为了让画布上的每个属性都属于某个具名元素，从而能够单独评分。七个通道对结果进行评分：六个确定性验证器分别负责执行、文本、边界、表格与图表数据、语义布局和留白，再加上一个由视觉语言模型评判的、针对具体样本的 Visual Graph Rubric。候选方案会在沙箱化的 Playwright 浏览器中渲染，外部请求被拦截，测试框架会回读 DOM、计算样式、边界框和一张截图，这就是为什么表格必须是 HTML 表格，图表必须是 ECharts 规范。训练先是基于 3,000 条演示的冷启动监督微调，然后在 7,408 条提示上运行 GDPO，训练 400 步，使用单个由八块 NVIDIA B200 组成的节点，每个奖励通道都在其 rollout 组内进行归一化，这样密集的基于规则的信号就不会淹没稀疏的视觉信号。微软测得，这种归一化相比纯标量 GRPO 带来 5.12 个 Visual 点的提升。

那套机制的存在，并不是为了让 AesCode-8B 成为更好的通用助手。它的存在是为了让输出可核查，而这就是该模型上下文之所以如此的原因。

并排显示，并标注数字

• 基础—— AesCode-8B：Qwen3-VL-8B-Instruct，一个视觉语言检查点。Qwen3-8B：同代的纯文本通用模型。

• 参数 — AesCode-8B：四个分片合计约 8.8B（bf16）。Qwen3-8B：总计约 8.2B，非嵌入部分约 7B。

• 输入 — AesCode-8B：文本以及可选的参考图像。Qwen3-8B：文本。

• 输出 — AesCode-8B：完整的 HTML 和 CSS 文档。Qwen3-8B：文本、工具调用、代码。

• 上下文 — AesCode-8B：在报告的配置中为 24,576 个 token。Qwen3-8B：原生 32K，通过 YaRN 扩展至 131K。

• 语言 — AesCode-8B：该卡片的标签仅为“en”。Qwen3-8B：119 种语言和方言。

• 证据——AesCode-8B：微软自有的 300 个样本的信息图评分标准，每个提示词生成三次，无外部复现。Qwen3-8B：十八个月的独立基准测试、量化工作与生产部署。

• 许可证——两者均为 Apache 2.0，不设门槛。双方打平，而这并不是人们以为的那种差异化因素。

证据缺口才是真正的比较

微软报告称，AesCode-8B 在其评分标准下综合得分（Overall）为 82.94，领先于以参考为条件的 GPT-5.5（81.28）和 Claude Opus 4.8（80.39），并在视觉（Visual）得分上比自身的参考条件主干模型高出 31.1 分。那张表里有三个数字比这则头条更值得玩味。第一个是风格（Style）项，AesCode-8B 为 53.21，而对比中没有任何模型突破 60——微软对风格的定义是交付前无需再做任何视觉修改的设计，因此，在"人类是否会不经修改就发布该页面"这唯一一个维度上，该模型并非领先者。第二个是边界失效：在 300 个样本中有 4.3% 反复出现严重的画布溢出，而 GPT-5.5 为 34.7%。第三个是，评分中视觉的那一半来自一位未具名的视觉语言评判者，这意味着确定性的那一半可由外部人士复现，而另一半则不能。

Qwen3-8B 的数字完全来自另一个来源，而这一点比哪一组数字更高更重要。长达十八个月的独立评估、社区量化版本、推理服务基准测试和生产部署，构成了另一类证据：它不是一种说法，而是一份实绩记录。你可以查到 Qwen3-8B 在特定显卡上采用 4 位量化时的表现，因为已经有人公布了结果。但对 AesCode-8B，你做不到这一点，因为截至本周，Microsoft 之外还没有人在任何硬件上运行过它。

而且两个表格之间没有共同的指标。Qwen3-8B 没有信息图布局得分；AesCode-8B 根本没有已发布的通用推理基准。这种比较谈不上接近或不接近——而是无法进行。

实际运行每一个需要什么

Qwen3-8B 是更省心的那个。一个 8.2B 的文本模型可以量化到单张消费级显卡上，背后有十八个月的工具体系支持，覆盖所有服务框架和本地运行时，而且表现可预测。上下文扩展到 131K 是有文档记载的，而非坊间传说，而 119 种语言的覆盖正是它出现在如此多 multilingual 流水线中的原因。

AesCode-8B 是一个推理服务项目。模型卡自身给出的命令是 vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，并搭配 transformers 4.57 或更新版本（用于非 vLLM 路径）。17.5 GB 的 bf16 权重必须与 24,576 个 token、最多两张图像的 KV 缓存并存，因此单张 24 GB 显卡在技术上够用，但会紧张得令人不适；40–48 GB 或两张 24 GB 显卡才是现实的最低门槛。还要把渲染器也列入预算，因为关于该模型质量的每项说法，都是通过在沙箱化浏览器中渲染其 HTML 输出来得出的——如果你想判断自己的输出是否足够好，那就必须搭建这套测试装置。另请注意，24,576 token 的上下文是在单张信息图页面上实际测试的，而不是该模型所主打的跨多页幻灯片演示文稿，因此真实演示文稿上的上下文压力仍是未经检验的领域。

可用性是同一个论点的另一半。AesCode-8B 并不是 OrcaRouter 路由的模型，我们也找不到其他地方提供它；今天要评估它，就意味着要把权重放在你自己的硬件上。它的前身则完全是另一回事——Qwen3-VL-8B-Instruct 现在可以通过 OrcaRouter 调用，在 131,072 token 的上下文中，每百万输入 token 0.18 美元、每百万输出 token 0.70 美元，这使它成为最便宜的方式，让你在自己的信息图提示词上看看这一确切架构的未经调优版本表现如何。沿着同一系列再往上，Qwen3.8-27B 可按 0.33 美元和 2.40 美元的价格路由。提供商目录价原样透传，不添加任何加价，且提供商之间的故障转移是自动的，因此针对托管骨干模型对提示词进行原型验证只需一个密钥，而不是耗费一个 GPU 周，只有真正渲染效果好的提示词才值得投入复现工作。

你依赖的是哪一个工件

当交付物是一个页面、而且必须可编辑时，就选 AesCode-8B。结构化的 HTML 输出能在 Git 里做 diff，表格是真正的表格，图表是 ECharts 规格——这与一段文字是真正不同的产物，再多的通用能力也替代不了它。要明知代价地接受这笔交易：一个未公开宣布的研究检查点，下载量只有两位数，24K 上下文，仅支持英文，没有独立评测，其自家厂商公布的 Style 天花板，以及以数十 GB 计的推理服务账单。

其他一切场景都选 Qwen3-8B——而对大多数团队来说，其他一切就是全部。在这个权重级别上，它是久经考验的通用型选手：上下文更长，支持一百一十九种语言，能在你已有的硬件上运行，而且你即将做出的那些决定背后，有他人十八个月的生产环境经验作为支撑。如果你没有渲染页面的特定需求，这场比较只有一个答案。

想要两者兼得的理由确实成立，而且这不是一个平局决胜的问题。一条读取文档并生成演示文稿的流水线会用到两个模型，它们产出两种真正不同的输出类型；而有用的做法是，把页面渲染器留在能够承载它的硬件上，并将阅读与推理工作路由到与其它一切共用同一端点的东西上。

怎样才能让这个页面更能促成成交？

三件事，其中只有一件与基准测试有关。对 82.94 和 1.00 个百分点的参考下降进行独立复现，将让 AesCode-8B 从厂商宣称变成实测结果，并让 8B 对 8B 的规模问题能够凭事实来回答。如果有提供商采用这个检查点，就会让部署这一栏消失，并把“一个 GPU 周”变成“一次 API 调用”。而模型卡引用为审稿中的那篇论文——"AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards"——将回答模型卡无法回答的问题：当它据以评分的设计图本身就有错时，视觉评分标准会如何表现。

在其中之一真正落地之前，站得住脚的解读是更狭义的那个。AesCode-8B 是这两个模型中更有意思的那个，也是更不好用的那个。它很擅长视觉设计中机器能检查的部分，在无法自动化的部分表现一般，并且它与被拿来对比的模型同属 Qwen3 这一代模型家族，但并非由后者衍生而来。Qwen3-8B 才是你今天下午就能放进流水线的那个。