AesCode 32B 对比 North Mini Code：权重文件并非承诺

两者都采用 Apache 2.0 许可，都可下载，也都是为一项很窄的任务而打造，但相似之处也就到此为止，再往下比就没有意义了。Aesce 32B是微软用于生成可编辑 HTML 和 CSS 的研究模型：海报、仪表盘和报告。其 Hugging Face 仓库创建于 2026 年 9 月 29 日，标题为“Release Aesce-32B”的版本于 2026 年 10 月 1 日落地；微软没有发布任何公告，模型卡上也完全没有发布日期。North Mini Code是 Cohere 的开放权重智能体编程模型，一个拥有 3B 激活参数的 30B 混合专家模型，发布于 2026 年 6 月，面向软件工程和终端工作。要比较这两者，最显而易见的做法是看它们在任务上的表现，而这行不通：这两个模型从未在同一个任务上被评测过，而且其中只有一个曾被其自家实验室以外的人测过。真正行得通的比较——也是决定你到底能不能把它跑起来的那个比较——是权重文件。

两个检查站，两份截然不同的账单

这是大多数对比都会略过的维度，而对两个自托管模型来说，它恰恰是最重要的维度。

• 参数量 — AesCode 32B：33B，稠密。North Mini Code：总计 30B，激活 3B，混合专家。

• 运行所需内存 — AesCode 32B：该说明建议仅 bf16 参数就需规划约 65 GB 的加速器内存。North Mini Code：经过量化，大约 20–24 GB 就足够，并且参考部署方案中包括 Mac Studio。

• 服务形态 — AesCode 32B：一个视觉语言模型，因此其服务链路既承载文本也承载图像，并且它自己的示例采用了四路张量并行。North Mini Code：文本输入、文本输出；基准测试使用了单个终端工具。

• 许可证——双方均为 Apache 2.0，且包含权重。这一项是平局，并非人们所认为的差异化因素。

• 上下文 — AesCode 32B：在所报告的配置中为 24,576 个 token，训练时的提示词和响应上限为 8,192。North Mini Code：输入 256K，输出 64K。

• 它输出什么——AesCode 32B：一个完整的 HTML 文档，表格以 HTML 表格呈现，图表以 ECharts 规格呈现。North Mini Code：测试框架要求的任何文本或工具调用。

• 独立评测 —— AesCode 32B：未公布任何结果；所有数据均来自 Microsoft。North Mini Code：在 Artificial Analysis 上有评分，该平台也指出了其冗长的问题。

把第二行读两遍。一个需要 65 GB 和四路并行的 32B 稠密视觉语言模型，与一个量化后能装进工作站的、激活参数为 3B 的 MoE，是截然不同的采购决策。如果你考虑开放权重的原因是“我们想把它跑在自己的硬件上”，那么在你连一个提示词都还没跑之前，那一行就已经是答案的大半了。

许可证不是选择其中任何一个的理由

几乎所有开放权重模型的对比都会从许可问题谈起，而在这里这是一条死路：两者都是 Apache 2.0，都发布完整权重，也都不带任何会阻止商业部署的使用限制。没有需要拿来与折扣权衡的数据共享条款，没有贡献者层级，也没有按使用领域划分的例外。无论你在这两者之间是基于什么做选择，都不会是许可。

把许可问题排除在外之后，剩下的就是模型被训练去做的事——而这两者的训练方向恰恰相反。

一个是在终端上训练的，另一个是在画布上训练的

North Mini Code 的模型卡直接点明了其目标：代码生成、智能体软件工程和终端任务。Cohere 在多种智能体框架上训练了它——SWE-Agent、SWE-Agent、OpenCode、Terminus 2——专门为了让它在无论你运行哪一种框架中都能工作，并在 SWE-Bench Verified、SWE-Bench Pro、Terminal-Bench v2 和 Terminal-Bench Hard 上对其进行了评估。它公布的弱点是真实存在的，而且是由外部评估者发现的，而非供应商主动披露的：它输出的 token 数量约为同尺寸级别中位数的三倍。冗长的模型会写出很长的智能体轨迹，而一旦促销定价结束，你就要为这些长轨迹付费。

AesCode 32B 是在完全不同的数据上训练的，而模型卡异常明确地指出，目标就是生成产物本身。这一设计的核心要点在于，代码模型无法看到布局、层级与色彩如何在画布上融为一体，因此 AesCode 使用由同一提示词生成的图像作为美学参考，同时将提示词作为内容的事实来源。监督信号是一个由节点和边构成的“设计图”，包含七个奖励通道——执行、文本、边界、表格/图表、布局、空白、设计——其中六个是确定性验证器，另一个是依据逐样本评分标准工作的视觉语言评判器。候选结果在沙盒化的 Playwright 浏览器中渲染，外部请求被屏蔽，并根据 DOM、计算样式、边界框和屏幕截图进行评分。

那套机制的存在是为了让一件事成立：输出是人类会打开并编辑的渲染后页面，而不是应用到代码仓库的补丁。AesCode 32B 从未被训练使用 shell，而且奖励设计也不会因为它尝试这么做而给予奖励。

证据的不对称性，如实陈述

North Mini Code 已由第三方运行。Artificial Analysis 在其 Coding Index 上给它打出 33.4 分，在其 Intelligence Index 上打出 27.6 分，并公布了关于冗长性的发现。Cohere 自己给出的头条数字——SWE-Bench Verified 上 61.0% 的 pass@1——是厂商报告的，但可以对照任何人都能下载的模型进行核验，而且这张模型卡对其测试框架的选择十分坦诚，甚至指出对于 Terminal-Bench Hard，它遵循了 Artificial Analysis 自己的方法论，以保持比较公平。

AesCode 32B 没有对等竞品。它的 300 样本信息图评测——每个提示生成三次且不做筛选——得出总分 85.89，而 GPT-5.5 为 81.28，Claude Opus 4.8 为 80.39，全部是在微软的测试框架内、用微软的样本、经由微软训练该模型时所针对的评分通道测得的。这些数字很可能确实公平；这套设计比大多数厂商表格更透明，验证器栈和评分标准构建器均已开源，而且模型卡还公开了一个事实：对比中没有任何模型在其风格维度上超过 60 分。但没有任何外部实验室复现过其中任何一项，也没有竞技场收录、没有排行榜名次，也没有独立的吞吐量测试。如果一个恰好偏袒厂商自家基准的厂商基准——一项信息图任务——在你的决策中占了很大分量，那么你被要求接受的，就是唯一可得的那个读数。

特别注意这对这场对比具体意味着什么：不存在共同的数字。一个都没有。一个模型的评分依据是软件工程任务是否通过，另一个则是文本是否清晰可读、布局是否不会溢出画布。任何把 33.4 和 85.89 并排放在一起的页面，都是在拿 Coding Index 与信息图的 Overall 得分作比较，而两个模型都不知道对方测试的是什么。

两者都不是通用模型，而这才是真正的代价

这个对比的两半都存在同一个陷阱。采用其中任何一个模型，都意味着要为一个专才维护一条自托管服务路径：负责渲染页面的那个需要 65 GB 显存和一套多模态技术栈；负责处理终端任务的那个则需要一个 3B 激活参数的 MoE 槽位。两者各擅其职，却都无法胜任对方的工作，这意味着一个想同时拥有这两种能力的团队，如今要跑两套推理部署——而对于介于两者之间的一切，也就是那个既不是页面渲染器、也不是终端代理的模型，他们还得再跑第三套。

这正是路由层凭实力赢得一席之地、而非硬生生加装上来的场景。只需一个密钥即可按提供商标价使用 200 多个模型，且没有加价，这意味着专业工作会留在你自己的硬件上，因为在那里经济性和数据处理都说得通，而常规工作则交给那一周最适合它的任何托管模型。Qwen3-VL 主干模型系列很好地说明了这条界线可以有多细：微软基于 Qwen3-VL-32B-Instruct 构建了 AesCode 32B，而 该系列的视觉语言成员可在 OrcaRouter 目录中调用——Qwen3-VL 235B A22B Instruct 每百万输入 token 0.40 美元、输出 1.60 美元，或更小的 Qwen3-VL 8B Instruct 为 0.18 美元和 0.70 美元。这两者都不是 AesCode 32B：该微调模型属于微软，没有任何提供商提供它。但如果你想从 AesCode 32B 得到的是一个能读取截图并编写代码的模型，而你并不特别需要那个美学设计微调，那么可调用的选项是存在的，成本只是 GPU 的零头。同一端点底层的自动故障转移，正是“试一试它”和“把生产路径押在它上面”之间的区别。

如何真正做出决定

先把许可证排除在外，因为这是平局，它决定不了任何事情。

然后问自己想要输出什么。如果答案是可渲染、可编辑的页面——演示文稿、报告、仪表盘——North Mini Code 帮不了你，而 AesCode 32B 是两者中唯一针对这个问题的那一个。要清楚地认识到 65 GB、24K 上下文、缺乏独立评估，以及这是一个下载量只有两位数的未公布模型。它是一次研究性质的发布，而研究性质的发布会奖励那些有资本保持好奇的团队。

如果答案是改动一个仓库——一次迁移、一个修复、一项多步骤终端任务——那么 North Mini Code 就是那个具备 harness 训练、256K 窗口、3B 激活部署配置，并且其质量和冗长程度都经过外部评测的模型。要按 token 数量做预算，而不是看标称费率。

并且，如果您本季度的待办事项清单中同时包含设计工件和代码库迁移，不要将其视为双模型决策，而它实际上是六模型决策。在能产生效益的地方运行专家模型，其余则进行路由。

未公布模型的问题

最后还有一点将两者区分开来，而这一点无关技术。North Mini Code 背后有一家厂商，发布了模型卡、一篇博客文章、一个可供试用的 Hugging Face Space，以及一套你可以与之争论的基准测试方法文献记录。AesCode 32B 则有一个代码仓库、一份 README，以及一行写着“Under review, 2027”的引用信息。Microsoft 尚未表示它存在。

当你能够采用它时，情况就会改变。对于 North Mini Code，悬而未决的问题是它的冗长是否会让它在大规模应用时不经济——而这个问题你可以通过实际运行它来回答。对于 AesCode 32B，悬而未决的问题是 Microsoft 打算拿它做什么：这是一个研究产物、一条产品线的首次发布，还是某种会在六周内被 70B 版本悄然取代的东西。仓库里没有任何内容能回答这个问题，读再多模型卡也无济于事。留意三个信号——官方公告、对 85.89 的独立复现，或有推理服务商采纳该检查点——并把三者全部缺席视为当前证据的状态，而不是这个模型不值得关注的理由。