Recursive Flint 40B-A2.5B：一个以速度优先为设计理念的编程模型

决定Recursive Flint 40B-A2.5B是否值得占用你磁盘空间的数字并不是 54.9%，而是 2.5。Recursive 的首个开放权重编程模型拥有 398 亿参数，每生成一个 token 会激活其中约 25 亿个，而该版本中几乎其他所有决定——注意力布局、量化方案、自定义 Metal 内核、推理引擎——都源自这一个比例。Flint 于2026 年 10 月 21 日在 Apache 2.0 下发布，这意味着在撰写本文时它才面世一天，仍处在发布还能算新闻而非历史的窗口期内。由于才出炉一天的基准测试表更像承诺而非实测，我们将生产记录单独维护：AI Incident Archive记录了模型和提供商的说法在真正服务实际流量后表现如何。

给现在就要做决定的人一个简短版本：它是一个稀疏混合专家模型，目标是成为笔记本电脑上同重量级里最快的那一个；它公布了三项智能体编程分数，而这些分数全都由厂商报告、未经复现；它是一家公司推出的首个模型，这家公司公开宣称的目标是让构建模型的研究实现自动化。这三件事都很重要，而第三件事在一年后仍会引人关注。

实际发布的内容

四个仓库，而非一个。主 RecursiveSI/flint 仓库包含 BF16 检查点、配置、分词器、聊天模板和一套 SGLang 服务套件，该仓库创建于 2026年10月21日 14:20 UTC。旁边还有三个量化变体，均于同一天下午标注完成：一个 int4 safetensors 构建、一个 int4 GGUF 和一个 NVFP4 GGUF。以下所有大小均取自各仓库自身的文件清单实测得出，而非引自公告。

• BF16 参考 — 共 79.59GB，分布于 37 个文件中，分为 15 个 safetensors 分片，每个约 5.37GB。这是微调产物，也是你不希望在推理时下载的那个。

• NVFP4 GGUF — 单文件 22.86GB，是目前已发布的最小的完整推理构建。

• Int4 GGUF — 25.99GB，一个 q4_1 量化版本，体积却比 NVFP4 文件还大，这与命名顺序恰好相反，在按文件名做选择之前值得了解一下。

• Int4 safetensors — 22.58GB，适用于偏好分片权重而非单个 GGUF 的运行时。

许可证为 Apache 2.0，模型卡还进一步说明：托管 API 的条款与数据实践同权重许可证是分开的——这是常见的区分方式，只是被明确写出，而非藏而不露。

这种架构本质上是一场关于内存带宽的论证。

在笔记本电脑上，解码一个 token 主要不是计算问题。问题在于如何足够快地把权重从内存移动到算术单元，这就是为什么一个 400 亿参数的稠密模型无论芯片有多好都会很慢：每生成一个 token 都要读取全部权重。Flint 的答案是几乎不读取其中任何一个。

• 稀疏性 —— 每个 MoE 层有 256 个路由专家，每个 token 选择其中 6 个，另有一个始终激活的共享专家。49 层中有 2 层为稠密层、47 层为 MoE 层，因此除前两层外，其余各层都在执行条件计算。

• 激活参数——总计 39.8B，计入输出头后每个 token 约有 2.5B 激活参数，这正是“40B-A2.5B”这一命名的由来。仅激活主体部分约为 2.2B。

• 注意力 — 35 个滑动窗口层采用 513 个 token 的窗口（当前 token 加上前 512 个），与 14 个全注意力层交错排列。仅有 32 个查询头和 4 个键值头，头维度为 128，因此 KV 缓存足够小，能让长时间智能体会话保持实用。

• 位置编码——在滑动窗口层上使用旋转嵌入，而在全注意力层上完全不用；模型卡陈述了这一选择，却没有解释原因。逐头 QK RMSNorm 和学习到的逐头注意力汇（attention sinks）承担了通常由位置编码分担的稳定性工作。

• 上下文——文档中记录了 262,144 个 token，而模型卡明确指出，这涵盖了提示词和生成的输出。公告宣称“最高可达 512k”，随后又建议在编码时保持在 256k 以内。这两项声明均出自同一供应商，且相隔仅一个段落。

值得关注的细节在于这个配置是如何选出来的。Recursive 表示，其 Eureka Machine——一个自动化的研究循环，负责提出想法、实现想法、测试想法，并整合行之有效的部分——从一个拥有 350 亿参数、其中 30 亿为活跃参数的基线模型出发，并针对各种专家配置和宽度进行了搜索。最终得到的 40B/2.5B 配置，用公告自己的话说，“预计能在我们的 Eureka Machine 所测试的配置中，提供速度与编码性能的最佳组合”。这是“预计”，而不是通过训练完成的模型之间的对比评测得到证明。在训练成本高昂时，这是选择架构的一种常规方式；但这也是一项可能被后续检查点悄然推翻的说法。

这三个分数，以及与之对应的脚注

Flint 在 Terminal-Bench 2.1 上得分 54.9%，在 SWE-bench Pro v2 上得分 89.7%，在 SWE-bench Verified 上得分 74.2%。这些数字作为发布评估出现在模型卡中，而没有任何第三方公布过对该模型的测量结果——Artificial Analysis 模型指数是这类发布通常的独立裁判，但截至 10 月 22 日根本没有 Flint 条目。所以下面的一切都是 Recursive 在衡量 Recursive。

该厂商确实披露的关于其自身方法论的信息，比大多数发布文章主动提供的还要多，而这会改变这些数字应如何解读：

• Terminal-Bench 2.1——使用 Terminus 2 运行框架运行，并启用互联网访问，且通过网页检索获得的解决方案计为失败。最后一项调整是刻意设置的不利条件，模型卡指出，其他开发者公布的分数可能并未采用这一调整，这使得与第三方数字进行同类比较变得更加困难，而不是更容易。

• SWE-bench Pro v2 和 SWE-bench Verified —— 在完全无网络访问的情况下使用 mini-swe-agent 运行，这比那些能在任务中途搜索文档的智能体所处的设置更为艰难。

• 尝试次数与超时——在至少五次尝试上取 pass@1 平均值，智能体超时上限为五小时。对五次尝试取平均是合理的方案；五小时超时意味着这些分数对应的是一个你愿意让它持续运行的智能体，而不是自动补全。

• 采样——在每次评估中，temperature 均为 1.0、top-p 均为 0.95、top-k 均为 20；当请求省略这些参数时，服务套件会应用这些默认值。

厂商的基准测试表也说明了它选择了哪些同行作为对比对象。Recursive 自己的图表将 Flint 与 Qwen 3.5、Qwen 3.6、Qwen 3.8、Laguna XS 21、Muse Glimmer 和 Gemma 4 进行对比——这些本地模型适配相似硬件，对笔记本模型而言是诚实的同类对比组，同时也是经过挑选、能让稀疏性论点显得更有说服力的一组。所提出的主张范围狭窄且站得住脚：在智能体编程方面，Flint 在总参数低于 500 亿的 MoE 模型中领先，并能与 250 亿至 400 亿参数的稠密模型竞争，同时运行速度快得多。这并不是关于前沿编程模型的主张，Recursive 也没有提出这样的主张——公告直言，Flint“可能比你惯用的大型闭源编程模型需要更多引导。”

速度：2× 究竟是以什么为基准衡量的

Recursive 在 M4 Pro MacBook Pro 上报告每秒超过 125 个 token，在 64GB NVIDIA RTX Spark 上短上下文时每秒超过 150 个 token，并称这比同类模型快至多两倍，比参数量在 250 亿到 400 亿之间、编码分数相近的稠密模型快五倍以上。速度图表下方的方括号方法说明才是值得细读的部分：整个 128,000 token 会话期间的平均每秒 token 数，不计预填充，其中一个竞品只测到 124k，而非完整长度。

排除预填充（Prefill excluded）是解码基准测试的标准做法，而且在这里仍然重要，因为当编码智能体把代码仓库塞进上下文窗口时，预填充正是它耗时的地方。一个只衡量 128k 会话中解码那一半的数字，会让任何采用稀疏激活的模型显得更好看，而 Flint 的整个设计就是稀疏激活。这些都不会让这个数字出错，只是让它成为一个解码数字；它应该与其他解码数字比较，而不是与你的智能体完成任务所需的时间比较。

量化配方是最具可迁移性的部分

大多数关于量化的文章讨论的都是损失了多少精度。这篇讲的则是一个与惯例背道而驰的决定。

Recursive 将输出层——即 lm_head——递归量化到了 4 位。这有悖于常见做法，原因则特定于稀疏模型：由于只有 25 亿活跃参数，输出层在每生成一个 token 所读取的权重中占很大一部分，因此若将其保持在 16 位，就会限制模型所能达到的速度上限。为了恢复准确率，需要一个离线蒸馏阶段：让量化后的模型用其自身从一个它自己发现的核心集中预先采样出的响应进行训练，并以 16 位模型作为教师——Recursive 表示，与它的量化感知训练基线相比，这一设置几乎将训练步数减半。

公布的结果是，最终的 NVFP4 模型在整个基准测试套件中的得分与 16 位模型相差在 0.7 分以内。这是厂商的说法，而这类说法事后很容易核查、造假成本却很高，因此是一个可以用来要求他们兑现的有用依据。实际影响就是上面的文件大小：一次 22.86GB 的下载，就能在一台拥有 48GB 统一内存的机器上运行一个 398 亿参数的模型。

在 Apple Silicon 上，这还有第二层含义。Recursive 的 Eureka Machine 为低位宽投影、MoE 运算、注意力和提示词处理生成了专用内核，其中包括一个 Metal 超级内核，它在 M4 和 M5 芯片上将整个解码前向通路融合为一次调度。融合解码通路这类优化，只有当你同时掌控模型架构、量化格式和内核时才能见效——这正是本次发布的核心主张，其意义超过任何单个基准测试数字。

你如何运行它，以及每条路径会让你付出什么代价

有两种不同的部署方案，二者不可互换。

• 服务器 GPU —— BF16 检查点附带一套 SGLang 服务工具包，每个副本面向一块 B300 或一块 H200，在端口 30000 上暴露兼容 OpenAI 的端点，模型名称为 flint，并包含一个用于推理和工具调用的示例客户端。这是全精度权重唯一受支持的路径；模型卡已明确说明目前尚未包含 Transformers 建模代码。

• 本地设备——llama.cpp、Ollama、Unsloth、LM Studio、vLLM 和 SGLang 均被列为支持，这对一款发布首日的模型而言广泛得非同寻常，也正是“一个检查点”与“一件可用产物”之间的差别。

• rec 引擎——Recursive 自有的推理引擎，安装到 ~/.local/bin，要求配备 M4 Pro、M5 Pro 或 M5 Max，且至少有 48GB 统一内存和约 30GB 可用磁盘空间，并在本地提供兼容 OpenAI 的 API。其 README 声称，在配备 4 位权重的 M4 Pro 上，其 token 吞吐量是 llama.cpp 的 1.4 倍到 2.6 倍；测试覆盖 1,000 到 252,000 token 的提示词、1,024 个输出 token，每个上下文长度运行五次，且不包含预填充。它明确针对单会话使用进行了优化——如果同时运行多个 agent，文档会指引你另寻他处。

决定一次会话是否顺利的实用注意事项：上下文窗口由提示和输出共享，难题需要至少 32,768 个 token 的输出预算（包括推理），并且返回的 reasoning_content 必须保留在对话历史中，否则多轮工具使用会退化。Recursive 对复杂任务的自身指导是把工作拆分成更小的子任务，并给出明确指令；这是诚实的建议，读起来也像是对模型能力上限的描述。

什么是真正未经证实的？

三件事，按它们对决策应有的影响程度从大到小排列。

第一项是独立测评。目前没有。不是排行榜上的低分，也不是有争议的分数——Flint 尚不存在任何第三方评估，流通中的唯一数字来自厂商，是由厂商选择的测试框架以及厂商针对网络检索所做的调整得出的。方法论披露得足够充分，可供审计，这在第一天已是你所能要求的极限，但披露不等于验证。

第二点是，一个拥有25亿活跃参数的模型，能否胜任编程智能体真正要处理的长周期工作。基准测试协议允许五次尝试和五小时超时，这是一个相当宽松的边界；一个需要多次尝试和很大自主空间的模型，可以取得不错的 pass@1 成绩，但在编辑器中却会让人觉得不可靠。Recursive 自己关于它比更大的闭源模型需要更多引导的提醒，也指向同一件事。

第三个是架构搜索本身。在自动系统测试过的配置中，被预测为最佳的那个配置，是对一次训练运行的假设，而不是关于一个已完成模型的结果。如果 Eureka Machine 的预测是对的，这就会成为其他小团队会照搬的模板。如果它大致正确，那么下一个检查点就会变动，比例也会随之改变。

当你的 agent 技术栈只有一半是本地部署时，这适用于哪些场景

像 Flint 这样的模型之所以重要，是因为它只是从账单中去掉一项费用，而不是全部。本地推理能处理你可以在自己机器上运行的工作，却对你无法运行的工作无能为力——装不下的长上下文任务、超出一台笔记本电脑承受能力的突发负载，以及更大模型就是更胜一筹的任务。这让大多数团队只能运行两套系统。

OrcaRouter 是这种安排中托管服务的那一半，而且为了明确边界：我们不提供 Flint 服务，本文也绝不是为我们在托管的某个检查点做宣传。Flint 是从 Recursive 下载的，不是我们的端点。我们所做的是在 200 多个托管模型前面放一个 API，按提供商自己的标价，不附加任何加价，通过基于配置的故障转移链在这些模型之间路由，并自动故障转移——当提供商在请求中途出问题时。如果你想比较本地运行 Flint 的价值与规模相近的托管混合专家模型——Qwen3.6-35B-A3B 和 Gemma 4 26B-A4B 都能通过那一个密钥调用——那么这种比较的代价是一次请求，而不是一次部署。

合理的解读

Flint 是一个正式发布版本，具有明确且不同寻常的重心。Recursive 并未推出其所能打造的最强编码模型；它推出的是能在适合笔记本电脑的规模下打造出的最快模型，随后又发布了一套量化与内核栈，旨在让这一优势在接触 4 位权重后仍能保留。对于 400 亿参数的稀疏模型而言，Terminal-Bench 2.1 上的 54.9% 和 SWE-bench Pro v2 上的 89.7% 是很强的数字，而且目前这些仅是厂商单方面公布的数据。

让它值得关注而不只是下载的，是其背后的方法。一个声称自动化研究循环选定了架构、量化方案和内核的团队，是在对流程而非模型作出主张，而流程的可检验方式不同于发布基准：下一次发布要么来得更快、更好，要么并非如此。Flint 是这一论证中的第一个数据点，其发布许可证足够宽松，任何人都可以自行检查权重。

如果你有一台配备 48GB 统一内存的 Apple Silicon 机器，那么弄清这一点的代价就是一次 22.86GB 的下载和一个下午的时间。如果你没有，诚实的立场是等待首个独立评测，因为一份才出炉一天的基准测试表只是一个承诺，而不是一次实测。