AesCode-8B 对比 Gemma 4 12B：两个小型视觉模型，两种截然不同的输出

AesCode-8B 和 Gemma 4 12B两者都接收一张图像和一句话，并且都是 Apache-2.0 检查点——你可以下载，而不是租用；这就是为什么搜索引擎会乐于把它们并排放在一起。这种相似是真实的，同时也是浅层的。Gemma 4 12B 返回的是一个答案——一段描述、一份转录、一个代码片段、一条推理轨迹。AesCode-8B 返回的是一个渲染好的页面：一份幻灯片、一张海报或一个仪表盘，形式是完整的 HTML 和 CSS 文档，你可以在浏览器中打开并手动编辑。相同的输入形态，大致相同的权重级别，而输出却几乎毫无共同之处。正是这一处差异，决定了下面几乎所有实际问题，包括你明天可以把哪一个放到用户面前。

值得一开始就说明，因为它决定了这些数字能承载多少分量：Gemma 4 12B 由 DeepMind 于 2026 年 6 月 3 日发布，附带了模型卡、文档和生态系统，并且此后经过了独立测试。AesCode-8B 则根本没有发布。微软为其创建的仓库于 2026 年 9 月 29 日建立，权重落在 2026 年 10 月 7 日 03:35 UTC 一个标题为“发布 AesCode-8B”的提交中，训练和评估代码于次日出现在 GitHub 上。没有微软研究院的博文，没有产品页面，没有发布说明，也没有预印本——模型卡的引用显示为“审阅中”，并带有占位年份 2027。截至本文撰写时，8B 仓库显示两次下载和一个点赞。因此，关于 AesCode-8B 的一切量化信息都来自微软自己，并且没有任何内容被其他人复现过。

这两种模型，各按其自身的逻辑

Gemma 4 12B 是一个中等规模的开源模型，一个拥有 119.5 亿参数的稠密检查点，其标志性设计选择在于它没有独立的视觉或音频编码器：图像图块和音频波形直接进入 transformer。它具备 256K token 的上下文，需要约 16 GB 显存，BF16 权重约 27 GB，量化版本则低于 7 GB。厂商自家的模型卡——由厂商自行报告，本文也如此标注——在 thinking 模式下列出了 DocVQA 94.9、InfoVQA 88.4、MMLU-Pro 77.2、GPQA Diamond 78.8、AIME 2026 77.5 和 LiveCodeBench v6 72.0。独立评测才是更重要的部分：Artificial Analysis 给该推理配置打出的 Intelligence Index 为 14，测得约每秒 114 个 token，并将一次典型服务调用的价格定在每百万输入 token 约 0.10 美元、每百万输出 token 约 0.30 美元。它背后已有三个半月的部署历史。

AesCode-8B 是基于 Qwen3-VL-8B-Instruct 的微调模型，发布时包含四个 safetensors 分片，总计 17,543,339,408 字节——约 88 亿个 bf16 参数，这就是为什么 Hugging Face 取整后的大小字段显示为 9B，而厂商说是 8B。发布的配置是标准 Qwen3-VL 配方：36 个隐藏层，隐藏维度为 4,096，32 个注意力头，配有 8 个键值头，151,936 个 token 的词汇表，以及要求使用 transformers 4.57 或更新版本。Microsoft 报告中的运行使用了 24,576 个 token 的上下文，最多 12,000 个输出 token，temperature 0.8、top-p 0.95，并且每个提示生成三次且不进行选择。许可证为 Apache 2.0，不设门控，没有可接受使用附加条款。模型包中未包含的是训练和评估数据，以及任何托管端点——我们在任何地方都找不到 AesCode-8B 的托管服务，它也不在我们自己的产品目录中。

这些模型实际上被训练来做什么

设计简报在模型卡中被引用，值得完整读一读，因为它就是整篇论点：代码模型“看不到布局、层级与色彩如何在画布上融为一体”，而图像生成器“能组合出视觉上引人入胜的页面，却常常错误渲染文本、数字和逻辑关系”。AesCode 正是试图同时保留构图感与可验证性。

这一机制在某一个特定方面显得不同寻常。每一条训练提示都配有一张由同一条提示生成的参考图像，它提供布局与风格，而文本提示始终是内容方面的权威依据。而在推理时，模型几乎不需要这张图：对 AesCode-8B 扣留参考图，其 Visual 分数在一百分中仅下降 1.00 分。对 Qwen3-VL-8B-Instruct 扣留参考图，降幅为 19.55。对在同一测试框架下评估的 GPT-5.5 扣留参考图，则为 10.04。视觉先验最终进入了权重之中，而非留在输入里，而这正是标题之下真正的研究成果。

Gemma 4 12B 的训练目标就是普通的多模态目标，这么说并不是批评：读图、回答问题、遵循指令、调用工具。它的模型卡中没有任何内容表明它曾被用于产出渲染成品，也没有任何已发布的 Gemma 4 12B 评测去衡量文档版式质量、画布溢出或设计一致性，因为这些都不是该模型的指标。

记分牌，以及它是谁的评分标准

• 参数 — AesCode-8B：8.8B bf16，稠密模型。Gemma 4 12B：11.95B 稠密模型。

• 输入 — AesCode-8B：文本加可选的参考图像。Gemma 4 12B：文本、图像、音频和视频。

• 输出 — AesCode-8B：一份完整的 HTML 和 CSS 文档。Gemma 4 12B：文本，包括工具调用。

• 上下文 — AesCode-8B：在所报告的配置中为 24,576 个 token。Gemma 4 12B：256K 个 token。

• 许可证 — 均为 Apache 2.0，无门控限制，包含模型权重。

• 证据——AesCode-8B：微软自有的 300 样本信息图评分标准，每个提示生成三次，无独立复现。Gemma 4 12B：一张厂商卡片，外加 Artificial Analysis 上独立测得的智能指数 14 分与实测吞吐量。

现在说说记分板无法承载的那部分。微软报告称，AesCode-8B 在那组 300 个样本上总体得分 82.94，领先于以参考图为条件的 GPT-5.5（81.28）和 Claude Opus 4.8（80.39），并比它自己的 Qwen3-VL-8B 底座高出 31.1 个视觉分。请把这一切都视为厂商自报且未经复现，依据的是厂商自己制定的评分标准、厂商自己挑选的样本，并由厂商针对该模型训练过的评测框架打分。这张成绩单倒是足够诚实，公开了一个对比中没有任何模型能超过 60 分的维度——风格，AesCode-8B 在该项为 53.21，GPT-5.5 以 57.91 领先——而微软对这一维度自己的定义是：交付前无需进一步视觉修改的设计。在唯一一个追问人类是否会不经编辑就直接发布页面的维度上，这个 8B 模型并不是领先者。当有人引用 82.94 时，这才是应该记住的那个数字。

在它们真正重叠的地方

只有一个共享的架子，而且它比看上去要窄。如果你正在为文档密集型的流水线评估小型开源视觉模型，那么两者都是候选——一个用于读取文档，另一个用于生成文档。一个以HTML生成内部仪表板、同时还需要从上传的PDF中提取图表数据的团队，会在同一周内接触到这两个产品。

那个重叠部分内部的分工很清晰。Gemma 4 12B 是你在收到文档时要使用的模型。AesCode-8B 是在交付物为页面时用来处理简报的模型。两者不能互相替代，而想同时拥有两者的流水线就是双模型流水线，而不是二选一。

部署，才是这种不对称性真正显现威力的地方

Gemma 4 12B 的推理服务这件事已经尘埃落定。你把它下载下来，愿意的话就量化一下，在 16 GB 显存上运行，而且已经有庞大的工具生态可以做到这一点。如果你根本不想自己运行，也有价格低廉、独立定价的选项。

AesCode-8B 的部署故事就是一条命令行加上一点算术。vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，非 vLLM 路径则需要 transformers 4.57 或更新版本。17.5 GB 的 bf16 权重必须与一个支持 24,576 个 token、最多两张图像的 KV 缓存并存，所以单张 24 GB 显卡在技术上够用，但紧得令人难受；40–48 GB，或者两张 24 GB 显卡，才是现实中可行的下限。还要把渲染器的开销算进去，因为这个模型的所有质量声明都是通过在沙盒浏览器中渲染其 HTML 输出来得出的，所以想给自己的结果打分，就意味着得搭起一套类似 Playwright 的东西，并屏蔽外部请求。

接下来要谈的是关于可用性的真实状况。我们并不对 AesCode-8B 做路由，而且就我们所能查到的而言，其他人也都不做；今天若要评估它，就意味着要把权重跑在你自己的硬件上。最接近可调用状态的，是这个模型微调时所基于的架构。Qwen3-VL-8B-Instruct是目前可在 OrcaRouter 上路由的，价格为每百万输入 token 0.18 美元、每百万输出 token 0.70 美元，上下文长度为 131,072 个 token，而我们实际提供的两个 checkpoint 也采用同样的计价方式——Gemma 4 26B-A4B 为 0.06 美元和 0.33 美元，Gemma 4 31B 为 0.13 美元和 0.38 美元。供应商标价原样传导，不额外加价，且供应商之间的故障转移会自动进行，因此，想弄清你的提示词到底能不能跑出好效果，最省钱的办法就是先测试未经微调的骨干模型，只把那一周 GPU 时间花在能通过考验的提示词上。

你到底想要哪一个？

如果交付物是一个页面，就选 AesCode-8B。该模型会输出结构化、可编辑的 HTML——表格以 HTML 表格呈现，图表以 ECharts 规格呈现——这意味着输出结果能在 Git 中做差异对比，设计师无需重新生成即可为其重新设计样式。接受这样的取舍：一个未对外公布的研究检查点，下载量只有两位数，没有独立评估，没有托管端点，24K 上下文仅在单个信息图页面上验证过，而且模型卡上只有英语语言标签。

其他一切场景都选 Gemma 4 12B。它阅读文档的能力胜过大多数规模是它两倍的模型，能处理音频，能遵循工具指令，有 25 万 token 的上下文，而且背后有其他人三个半月的使用经验。如果你要从这两个中选一个作为你的小型视觉模型，并且没有被明确要求以代码形式生成幻灯片，那么这就是答案。

而如果诚实的答案是需要两者兼得，就不要把它当作平局来裁决。把阅读的工作交给托管模型，而渲染的工作则留在任何能装得下这些权重的机器上。

什么会改变这个页面

三个信号。对 82.94 和 1.00 点参考降幅的独立复现，将使 AesCode-8B 从厂商宣称变成一项结果，也会让 8B 与 12B 的尺寸问题真正有意思，而不只是名义上如此。一家推理服务提供商采用该检查点，就会让部署这一栏塌缩掉，而它目前正是全部的实际差别。而微软引述为正在审稿中的论文——“AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards”——将回答模型卡无法回答的问题，首先就是当设计图本身出错时，视觉评估标准会如何表现。在其中任何一项落地之前，站得住脚的解读既狭窄又真实：AesCode-8B 在机器可检查的视觉设计部分非常出色，在机器无法检查的部分则表现平平，而 Gemma 4 12B 是一件做着不同工作的成品。