AesCode-8B 与 North Mini Code：同样的许可证，同样的下载按钮，相反的问题

这场对比中最有用的数字是 150,000。这是 Cohere 在 North Mini Code 上标注的下载量，时间为 2026-08-14，距该模型于 2026-06-09 发布已过两个月；正是这个数字，让与 AesCode-8B 的对比变得清晰可辨。AesCode-8B 是微软对 Qwen3-VL-8B-Instruct 的微调版本，其 Hugging Face 仓库显示下载量为两次。两者都采用 Apache 2.0，均无门禁，今天下午都可以下载；而其中一个已在生产环境中被使用了一个季度，另一个却还没有离开实验室。这一差距并非质量定论——没有人独立测评过 AesCode-8B，所以双方都没什么可自鸣得意的——但它是诚实的起点，因为它告诉你哪一个拥有可以提问的社区。

两者的发布方式截然不同，这也决定了你能验证什么。North Mini Code 是 Cohere 与 Cohere Labs 的开放权重发布，附带模型卡、背后的博客文章、一整套关于测试框架选择的文档记录，以及一个在发布期间以每百万 token 0.00 美元提供服务的随附 API。AesCode-8B 则完全没有发布公告：微软于 2026 年 9 月 29 日创建了该仓库，在 2026 年 10 月 7 日 03:35 UTC 以“Release AesCode-8B”为提交信息提交了权重，并于 2026 年 10 月 8 日将训练代码推送到 GitHub。没有微软研究院的帖子，没有发布说明，没有产品页面，引用信息一栏写着“Under review”，并带有占位年份 2027。这个 8B 模型以 HTML 和 CSS 输出幻灯片、海报和仪表盘；North Mini Code 则在智能体框架内编写代码。与其说它们是竞争对手，不如说是产品目录中的邻居，而这本身就是一种发现。

每一个被训练来输出的内容

弄清楚这两者并不做同样的工作，最清楚的方法就是看看它们各自输出什么。

• 输出 — AesCode-8B：一份完整的 HTML 和 CSS 文档，每次请求渲染一个页面。Mini Code：文本和工具调用，在实践中意味着补丁、shell 命令和智能体轨迹。

• 大小 — AesCode-8B：8.8B bf16 稠密模型，分为四个 safetensors 分片，总计 17,543,339,408 字节。North Mini Code：总计 30B 参数，其中激活参数 3B，是一个稀疏混合专家模型，包含 128 个专家，每个 token 激活 8 个。

• 上下文 —— AesCode-8B：在所报告的配置中为 24,576 个 token，训练时的提示词与响应各自上限为 8,192。North Mini Code：输入 256K，最大生成 64K。

• 输入 — AesCode-8B：文本外加一张可选的参考图像。North Mini Code：仅文本，其余一切均由测试框架提供。

• 训练数据 — AesCode-8B：先使用 3,000 条冷启动演示，随后在 7,408 条提示上以 GDPO 强化学习训练 400 步，每条候选输出都会在沙盒浏览器中渲染，再由六个确定性验证器加一套视觉评分标准进行打分。North Mini Code：兼容多种智能体框架 —— SWE-Agent、mini-SWE-Agent、OpenCode 和 Terminus 2 —— 因此无论你原本用哪一套，它都能直接在其中运行，而不会把你绑定到某一个框架上。

• 许可证——两者均为Apache 2.0，包含模型权重，无使用领域限制，无贡献者层级。在这一维度上，它们完全相同，无法作为决策依据。

• 证据 — AesCode-8B：微软自有的 300 样本信息图评分细则，未被复现。North Mini Code：一个厂商数据加上一项独立测量。

证据不对称，其实比看起来要小

这次对比的东侧有一个局外者，而这比基准差距更有价值。Artificial Analysis 自己运行了 North Mini Code，并在其 Coding Index 上给出 33.4 分，在 Intelligence Index 上给出 27.6 分——与同等规模的开放模型相比具有竞争力或更高。Cohere 报告称，在 SWE-Bench Verified 上 pass@1 为 61.0%，输出吞吐量最高可达 Mistral 的 Devstral Small 2 的 2.8 倍，两者均为厂商数据。独立运行才发现了问题所在：North Mini Code 完成同一套基准测试时，输出的 token 数量大约是其同规模类别中位数的三倍，约为 7500 万至 7700 万输出 token，而中位数为 2500 万至 3800 万。在发布期价格为零时，这不会产生任何现金成本。它付出的是延迟代价，并预示着一旦促销费率结束，账单会是什么样。

AesCode-8B 在测量之外没有对应物。微软在其自有的 300 样本信息图评估中报告 Overall 为 82.94，每个提示生成三次且不做选择，领先于参考条件化的 GPT-5.5（81.28）和 Claude Opus 4.8（80.39），并比自身骨干模型高出 31.1 个 Visual 分。它还报告称，参考条件化奖励将仅提示的 Visual 从 25.17 提升到 69.71，并且在推理时不给参考图像，只让该模型损失 1.00 个 Visual 分，而骨干模型则损失 19.55 分。这些是异常具体的声明，而且测试框架已开源，这比大多数厂商表格所提供的更多。这一切都还没有被任何人复现。没有竞技场列表，没有排行榜排名，没有吞吐量测量，也没有第三方对评分标准的审核。

特别注意这对比较意味着什么：两者没有共同的数值。一个模型的评分依据是软件工程任务能否通过以及消耗多少 token；另一个模型的评分依据则是信息图的文字是否保持清晰可读、版面是否始终不超出画布。把 33.4 和 82.94 并列在一起，等于拿一个编程指数去比一个信息图综合得分。

每个分别部署在哪里，以及这样做的成本是多少

North Mini Code 的部署故事，正是它突破 15 万次下载的原因。一个激活参数为 3B 的 MoE 量化后约占 20–24 GB 内存，Cohere 团队通过 MLX 在 Mac Studio 上进行了演示，而 3B 的激活占用正是让本地推理具备经济性的关键。在完整精度下，它可在单张 H100 上运行。在发布期内，Cohere 一直以每百万输入和输出 token 0.00 美元的价格提供服务，并针对生产规模提供托管式按实例部署方案。这个数字本身是 Cohere 自己给出的数据，汇总了所有分发渠道，但没有按平台细分；而 Hugging Face 上公开的月度数字要小一个数量级，这与该汇总数据涵盖 API、托管网关、包管理器和本地拉取的情况是一致的。应把它解读为势头，而非遥测数据。

Aces-8B 的命令行是。模型卡给出的是——vllm serve microsoft/Aces-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 才是现实的下限。如果你想按照作者的方式给输出打分，还需要一套渲染栈，因为关于这个模型的所有质量主张，都是通过在阻止外部请求的浏览器中渲染其 HTML 得出的。我们找不到任何托管端点，它也不在我们的目录中。

最后一点对任何比较这两者在可用性方面的人来说都很实际。North Mini Code 既通过供应商自己的 API 和多个第三方平台提供，也提供权重本身。AesCode-8B 只存在于 Hugging Face 和 GitHub 上。如果你的限制条件是“我明天就需要从某个服务中调用它”，那么这两者中只有一个的答案是可以。

两个模型都解决不了的构图问题

这个对比的两半里都有陷阱，而且是同一个陷阱。采用其中任何一个，都意味着要为一个专才维护一条自托管服务路径。AesCode-8B 需要一套多模态技术栈和一个渲染器，才能被妥善评估。North Mini Code 需要为 3B 激活参数的 MoE 留出位置，还要在它周围配一套智能体运行框架，而它的啰嗦意味着轨迹成本高于 token 数所暗示的水平。一个同时想要这两种能力——页面生成器和仓库智能体——的团队，现在要运行两套推理部署，而对于两者都不是的一切，还得再上第三套。

这就是在多个模型之前放置一个端点真正发挥作用、而非仅为图方便的场合。把专用模型留在你自己的硬件上，只要经济性和数据处理方式证明这样做合理，而把常规流量路由到本周最适合它的任何托管模型，这一切都通过一个密钥实现，按提供商目录价传递、零加价，并在提供商出现波动时自动故障转移。Qwen3 系列主干很好地说明了这条界线能有多模糊：微软基于 Qwen3-VL-8B-Instruct 构建了 AesCode-8B，而该系列的视觉语言成员可通过 OrcaRouter 调用——Qwen3-VL-8B-Instruct 在 131,072 token 上下文下，每百万输入 token 为 $0.18、输出为 $0.70，Qwen3-VL 235B A22B 则为 $0.40 和 $1.60。这两者都不是 AesCode-8B；该微调版属于微软，没有提供商提供它。但如果你想要的是能读取截图并编写代码的模型，而且你并不特别需要那种美学设计微调，那么可调用选项的成本只是 GPU 的一小部分，试一下只需一个下午，而不是一个采购周期。

既然两者都不是通用的，该如何决定？

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

先问清楚你想要的输出是什么。如果答案是渲染好的、可编辑的页面——一份演示文稿、一份报告、一个仪表板——那么 North Mini Code 帮不了你，而 AesCode-8B 是这两者中唯一针对该问题的。要清醒地看待：一个未事先公布的研究检查点、仅有两次下载、一个仅在单张信息图页面上验证过的 24K 上下文、一个仅限英语的语言标签，以及在任何地方都没有独立评估。微软自己的表格中，Style 上限为 53.21，而该维度的定义是交付前无需再做进一步视觉修改，这等于供应商在告诉你，输出仍然需要人工编辑。

如果答案是仓库变更——一次迁移、一个修复、一项多步骤终端任务——那么 North Mini Code 就是那个具备测试框架训练、256K 窗口、3B 活跃部署配置、可用的厂商 API，并且对其质量和冗长程度都有外部测量的选择。要按 token 数量做预算，而不是按标称费率，因为独立发现表明：为了达到同样结果，它的输出量约为同类产品的三倍。

如果你的一个季度里既有设计产物又有仓库迁移，不要把这当成一个双模型决策。在专家模型确实值回其 GPU 成本的地方运行它，其余的请求路由出去，并停止维护你并不需要的服务路径。

比基准测试更持久的差异

最后还有一点把这两者区分开来，而这与技术无关。North Mini Code 背后有厂商，发布了模型卡、一篇博文、一个可供试用的 Space，以及一套你可以去争论的方法论，此外还有 15 万次下载所代表的他人经验。而 AesCode-8B 只有一个代码仓库、一份 README，以及一条写着“审核中”的引用信息。

这改变了悬而未决的问题本身。对 North Mini Code 来说，当前真正的问题是：一旦促销费率结束，它的冗长性是否会让它在大规模使用时变得不经济——而你可以通过运行它来回答这个问题，因为很多其他人已经这么做了。对 AesCode-8B 来说，当前真正的问题是微软打算拿它做什么：研究产物、产品线的首个版本，还是六周内被悄悄取代的东西。代码仓库里没有任何内容能回答这个问题，读再多模型卡也无济于事。留意三个信号——官方公告、对 82.94 的独立复现，或某家提供商接入该检查点——并把三者全都缺席视为当前证据的状态，而不是这个模型不值得关注的理由。它值得关注的原因在于那 1.00 个百分点的参考下降，而这个数字仍然摆在那里，等待微软以外的人去核实。