Flint v1.0 对比 North Mini Code：两个开源编程 MoE 模型争夺你的笔记本电脑

本站大多数“对比”页面配对的，都是从未真正互为对手的东西。这一篇不同。Recursive Flint v1.0和Cohere North Mini Code属于同一类对象：稀疏混合专家代码模型，以 Apache 2.0 许可发布，小到足以在开发者已经拥有的硬件上运行，而且两者都被定位为本地选择，而非前沿选择。Flint 于 2026 年 10 月 21 日发布，总参数 398 亿，每个 token 约 25 亿激活参数。North Mini Code 于 2026 年 6 月 9 日发布，总参数 300 亿，激活参数 30 亿。这已经足够接近，以至于选择归结为文件中有什么以及实际测量了什么——而在这两点上，答案都不是发布报道所暗示的那个。

这两个文件，逐维度来看

先从开箱即得的东西说起，因为对于两个自托管模型而言，这才是经得起现实检验的对比。

• 总参数 — Flint：39.8B。North Mini Code：30B。

• 每个 token 的激活参数量——Flint：约 2.5B，其中 2.2B 在主干中，其余在输出头。North Mini Code：3B。两者几乎相同，而这个数字决定了推理成本。

• 专家路由 — Flint：256 个路由专家，每个 token 选择 6 个，外加 1 个共享专家，分布于 47 个 MoE 层和 2 个稠密层。North Mini Code：128 个专家，每个 token 激活 8 个。

• 注意力机制——Flint：滑动窗口层与全局层混合，并带有注意力汇点。North Mini Code：滑动窗口层与全局层按 3:1 的比例搭配。两者押的是同一个注：大多数 token 只需要局部注意力，少数才需要整个窗口。

• 上下文 — Flint：模型卡中记录了 262,144 个 token，公告称最高可达 512K，并建议使用 256K。North Mini Code：输入 256K，最大输出 64K。

• 模态 — Flint：文本输入，文本输出。North Mini Code：文本输入，文本输出。两者都不接受图像，如果你的工作涉及截图，这一点很重要。

• 许可证 — 两者均为 Apache 2.0，包含权重，无收入门槛。

• 已发布格式 — Flint：BF16、int4 safetensors、int4 GGUF、NVFP4 GGUF。North Mini Code：BF16、FP8 和 W4A16。

• 磁盘和内存——Flint：BF16 格式下为 79.59 GB，NVFP4 格式下为 22.86 GB，运行约需 24 GB 内存。North Mini Code：量化后约为 20 到 24 GB，Cohere 自己的演示在 Mac Studio 上运行约占用 20 GB。

内存是第一处被削减的地方，而它比参数量所暗示的更为接近。

直观来看，39.8B 对 30B 意味着 Flint 需要多三分之一的内存。其实并非如此，因为两者都是稀疏模型，而且都发布了激进的量化版本。你实际要在 22.86 GB 的 NVFP4 文件与约 20 GB 的量化版本之间做选择——两者足够接近，同一张 24 GB 显卡都能运行；也足够接近，单看占用空间，两者都不是显而易见的选择。

不同之处在于余量。据报道，North Mini Code 曾在搭载 32 GB DDR4 的 Ryzen 7 上运行 4 位 GGUF——那是一台真正普通的台式机，而非工作站。Flint 关于笔记本电脑的说法则更为具体：Recursive 的吞吐量数据是在 M4 Pro MacBook Pro 和配备 64 GB 的 RTX Spark 上测得的，这两者都是高端机器。那个 22.86 GB 的文件可以在 24 GB 显存的显卡上加载。至于它能否以你能容忍的速度运行，则是另一个问题，而且这在很大程度上取决于引擎。

如果你的限制条件是“我已经拥有的那台机器”，那么 North Mini Code 有更多在普通硬件上运行的报告。如果你的限制条件是“我拥有的最好机器”，那么 Flint 是更新的架构，并且在短上下文下更快。

其中一个带有独立的记分牌

这是大多数评述文章在比较时会跳过的部分，也正是应当决定采购的部分。

North Mini Code 已由 Artificial Analysis 进行测量。它在 AA Coding Index 上得分为 33.4，在 AA Intelligence Index 上得分为 27.6；SWE-bench Verified 的 pass@1 为 67.6、pass@10 为 80.2，mini-SWE-Agent 上为 61.0。这些是第三方在一致协议下产出的测量结果，这意味着它们可以与同一指数上的其他模型进行比较，而无需附加关于评测框架的脚注。

Flint 没有 Artificial Analysis 条目。其公布的成绩——SWE-bench Verified 上 74.2、SWE-bench Pro v2 上 89.7、Terminal-Bench 2.1 上 54.9——来自 Recursive 自家的测试框架，且无人重新运行过。方法细节是公开的，这一点值得肯定：SWE-bench 各次运行使用不联网的 mini-swe-agent；Terminal-Bench 使用联网的 Terminus 2，但任何通过网络获取的解法都计为失败；pass@1 取至少五次尝试的平均值。公开方法并不等于经过验证的方法。

那么，你能把 67.6 和 74.2 拿来比较吗？不能负责任地比较。它们由不同组织在不同的测试框架上、依据不同规则得出，而 6.6 分的差距完全落在仅凭测试框架选择就能造成的分数波动范围内。你能说的更窄，但仍然有用：North Mini Code 的数字经过了并非该模型构建者的人核查，而 Flint 的数字没有。如果你是根据证据而不是规格来做选择，那才是真正重要的不对称。

North Mini Code 这一栏里还有一个不光彩但值得了解的数据点：Artificial Analysis 指出它异常冗长，测试中消耗了约 7500 万个输出 token，而同类中位数接近 2500 万。在智能体循环中，冗长是成本乘数。一个把思考过程多说三倍的模型，可能每个 token 更便宜，但每个任务更昂贵。

在长上下文场景下，速度表现会截然不同。

两个模型在短提示下都很快，而当上下文填满时都会变慢。区别在于变慢的程度。

• Flint——Recursive 声称，在 M4 Pro MacBook Pro 上每秒可处理 125 个以上 token，在 64 GB RTX Spark 上超过每秒 150 个 token；这些数据是在短上下文、不计预填充的情况下测得的。独立测试报告称，短提示下约为每秒 110 个 token，而在接近 115,000 token 上下文时降至约每秒 9 个 token。这才是你设计智能体时应围绕的数字，因为智能体编程大部分时间都处在长上下文状态。

• North Mini Code — 在 Cohere 的 API 上，输出速度约为每秒 199 至 210 个 token，首 token 耗时约 0.25 秒，在同一测试中吞吐量约为同类小模型的 2.8 倍。在本地硬件上，具体数字完全取决于你使用的推理引擎和量化方式，但规律是一致的：短上下文时速度快，随着上下文窗口被填满而变慢。

诚实的比较不是“哪个更快”，而是“对智能体实际工作方式而言哪个更快”。一个在 4K 上下文下用 8 毫秒写一个 token、在 115K 上下文下用 110 毫秒写一个 token 的模型，与一个性能衰减更平缓的模型，是两种不同的产品。两家厂商都没有公布曲线。如果长上下文智能体工作是您的使用场景，请在决定采用之前在自己的代码库上测量——这只需一个下午就能完成，而且它告诉您的信息会比任何一篇发布博文都多。

势头与新鲜度

到2026年8月中旬，North Mini Code在发布两个月后下载量突破15万次。这是一个真实的信号：一个拥有如此多采用量的模型，已经在作者从未测试过的硬件上运行过，在社区中积累了不少修复，其粗糙之处也被那些没有理由口下留情的人记录在案。Cohere报告了这一数字，因此应将该数字视为供应商提供的数据，但其趋势得到了流通中的大量衍生量化版本佐证。

Flint 才四天大。它拥有更好的主要规格、更快的短上下文解码、更长的有文档记录的上下文窗口，以及更有趣的开发故事。它在 llama.cpp 的 GGUF 路径中还有一个已知的聊天模板错误，在长上下文处存在没人解释的吞吐量断崖，而且基本上没有社区历史。早期采用一个四天大的模型，是对其发展轨迹下注，而不是对这件成品进行评估。

周一该下载什么

• 如果你想要一款附带独立评分的模型、硬件配置不算高、任务属于普通软件工程且所在仓库能轻松容纳于上下文之中，并且比起更新的架构更看重两个月的社区缺陷报告积累，那就选 {{KEEP}}North Mini Code{{/KEEP}}。记得为它的冗长输出预留预算。

• 如果你拥有高端笔记本电脑或 24 GB 显卡，如果你想要更长的上下文窗口，如果你的工作流实际考验的是短上下文速度，并且如果你愿意成为早期采用者，以换取一个一个月后很可能更优的模型，那就选择 Flint。

• 不要只选其中任何一个作为唯一选项。两者都是活跃参数为 2.5 到 3B 的模型。它们在限定范围内的任务上表现出色，但并非前沿编程助手，Recursive 对自己模型的评价也是如此。两者都无法胜任的，是需要托管的前沿模型来完成的工作——而合理的架构是以本地模型为默认、并配有升级路径，而不是让一个模型包揽一切。

这种升级路径正是路由发挥价值的地方。OrcaRouter 并不提供这两个模型中的任何一个，因此这里并不是在为通往它们的路由做宣传。路由层为本地优先架构所做的是另一个方向的事：它让你可以把需要更大托管模型的任务组合进同一条调用路径，并配以回退链，用于本地模型停滞或上下文溢出的请求。配置得当的话，本地模型处理例行工作，只有真正需要时才会用到昂贵的模型——这是这种架构唯一能省钱的版本。

无聊的答案才是正确的答案。两个文件都是免费的，都能在你很可能已经拥有的硬件上运行，而想知道哪一个适合你的仓库，唯一的办法就是在你的仓库上把两个都试一遍。它们之间的基准测试差距，比它们中任何一个与你的实际工作负载之间的差距都要小。