Flint v1.0 与 Flint 40B-A2.5B：它们是同一个模型，而名称很重要

Flint v1.0和Flint 40B-A2.5B并不是两个模型。它们是同一个文件的两个名称。Recursive 的首个开放权重代码模型是一个混合专家网络，总参数量为 398 亿，每个 token 约 25 亿激活参数，于 2026 年 10 月 21 日以 Apache 2.0 许可证发布；根据你所处的技术栈层级，它在实际使用中至少以三个独立标签出现。API 标识符是 flint-v1.0。权重文件名是 Flint 40B-A2.5B。上游仓库是 RecursiveSI/flint。

这一点值得直白地写下来，因为互联网已经开始把它们当作一场对决。模型目录列出其中一种形式。量化仓库列出另一种。基准测试页面则把结果归档在其来源所使用的那个字符串下。把“Flint v1.0”和“Flint 40B-A2.5B”放进比较工具，它会欣然生成一个暗示存在选择的页面。并不存在选择。只有一个模型和一个命名问题。

三个标签，一个检查点

每个名称之所以存在，是因为技术栈的不同部分需要不同的字符串；一旦你知道是哪个部分，大约一秒钟就能判断出你看到的是什么。

• Flint v1.0——服务标识符，以厂商命名空间写成类似 recursive/flint-v1.0 的形式。“v1.0”是由运营该端点的人额外加上的版本标记，以便他们日后发布 1.1 时不会破坏所有已经指向它的客户端。你会在托管 API、模型下拉菜单以及读取 model="recursive/flint-v1.0" 的代码中看到这种形式。有些条目会带有 :free 后缀，它描述的是该特定端点的价格层级，而不是另一个模型。

• Flint 40B-A2.5B —— 架构名称，也是三者中唯一能让你了解该文件任何信息的名称。“40B”是总参数量，“A2.5B”是每个 token 的激活参数量，而带连字符的形式是稀疏专家混合模型已经固定采用的惯例。这种形式会出现在上游模型卡、量化仓库名称中，以及任何涉及该事物规模的讨论中。它也是最有可能在事实上正确的形式，因为它源自配置，而不是由目录指定的。

• RecursiveSI/flint——上游 Hugging Face 仓库路径，包含 BF16 检查点、配置、分词器、聊天模板以及 SGLang 服务套件。其他一切都源自于此。如果某个衍生仓库无法追溯到RecursiveSI/flint，那它就不是 Flint。

社区构建版本遵循同样的逻辑。面向 Apple silicon 或 GGUF 运行时的转换版本和量化包往往会采用描述性名称，因为下载一个 22 GB 文件的人想知道里面是什么，而不是托管平台分配了哪个目录版本号。每种情况下，底层检查点都是 Recursive 于 2026 年 10 月 21 日发布的同一个检查点。

为什么这会让人们付出真金白银

命名混乱通常只是令人烦恼。在这里，它却有两个重要的后果。

第一个是不成立的比较。人们拿 Flint 与其他模型比较，依据的是登记在其中一个名称下的数字；而读者若在一处看到“Flint v1.0 在 SWE-bench Verified 上得分 74.2”，又在另一处看到“Flint 40B-A2.5B 在 SWE-bench Verified 上得分 74.2”，就没有理由断定这些是同一个结果。但它们确实是同一个结果。没有人在另一个标签下发布过第二份不同的评估——该模型才问世四天，而且根本没有任何标签下的独立评估。

第二点是账单上的意外。因为一个名称是服务标识符，所以有可能按每 token 费率为一个模型付费，而这个模型你本可以下载一次，然后只花电费就能运行。这是一笔合理的交易——你买的是别人的硬件、正常运行时间和运营——但它应该是一笔深思熟虑的交易。Recursive 以 Apache 2.0 发布权重，没有收入门槛，也没有商业限制。如果你在为托管的 Flint 端点付费，值得问的是你到底在为什么付费，而答案不应该是对该模型的访问权。

还有第三种更隐蔽的代价：许可证洗白。Apache 2.0 并不会因为下游托管方给端点改了个名字，就变成别的东西。如果某个衍生仓库自称是另一个模型，那就核实一下它到底是不是。

如何判断你正在看的是哪一个

三个快速测试，按可靠性排序。

• 字符串是否带有供应商前缀和斜杠？如果有，那它就是服务标识符。应将其视为地址，而不是规范。它背后的模型可能被固定为比上游当前发布的检查点更旧的检查点，而且通常仅凭 ID 无法判断。

• 字符串中是否包含 B-A 模式，例如 40B-A2.5B 或 30B-A3B？那么它就是描述性架构名称，其中的数字是模型的真实规模。这是唯一能携带你可据以采取行动的信息的形式。

• 它是否是一条以纯模型 slug 结尾的两段式路径，例如 RecursiveSI/flint？那么它就是检查点本身，其文件列表才是权威依据。仓库中的文件大小——BF16 为 79.59 GB，NVFP4 GGUF 为 22.86 GB，int4 GGUF 为 25.99 GB，int4 safetensors 为 22.58 GB——才是规划硬件时可信的数字。

如果一个页面给了你版本字符串和基准测试分数，却从不提及参数数量，那是一个警示信号。这意味着该页面描述的是一个端点，而不是一个模型。

真正摆在你面前的决定

一旦你不再拿 Flint 与它自身作比较，真正的问题就在于分发形态：是下载它，还是在某处调用它。

下载意味着你能拿到检查点，能够进一步量化它、微调它，而且没有按 token 计费。但同时也带来了运维工作——磁盘上 22.86 GB、大约 24 GB 内存才能让它舒适运行、需要配置推理引擎，以及在信任输出之前还要验证聊天模板。对于已经在本地跑模型的团队来说，这只是寻常的周二。对于还没这么做的团队来说，这是一个项目。

调用托管端点能让你得到一个与 OpenAI 兼容的客户端，以及别人提供的正常运行时间。它还会引入对某个特定检查点的特定部署的依赖，而这正是版本字符串存在的首要原因。

大多数团队最终两者都想要，而真正该由我们说明的一点是：如果你已经通过一个 API 路由托管模型，那么一次托管调用的边际成本就应当恰好是提供商的标价。OrcaRouter 会原样传递提供商定价，不添加任何加价，因此供应商价格变动会在当天体现，而不是等到下一次合同续签。OrcaRouter 并不提供 Flint —— 这是下载内容，不是我们的端点之一 —— 所以那句话针对的是你技术栈的其余部分，而不是这个模型。

命名能告诉你关于此次发布的哪些信息

之所以有两个名字，是因为存在两条分发渠道，而这正是命名中真正值得关注的地方。Recursive 在同一天发布了开放权重和一个服务套件，因此这个模型既会以你可以拥有的文件形式出现，也会以你可以调用的字符串形式出现。只以单一方式发布的模型只会得到一个名字。

实际结论并不光鲜。当你想知道这个模型是什么、是否适合你的机器时，搜索“Flint 40B-A2.5B”。当你接入客户端、需要知道某个端点叫什么时，搜索版本字符串。而当你看到两者被拿来比较时，关掉标签页——你只是被展示了同一个模型两次。