一张生成的标题卡,标题为“FrogNano-4B-2609 vs LFM2.5 2.6B Base”,副标题为“一个已完成的 4B 智能体对比一个 2.69B 预训练检查点”,三个标签分别为“强化学习后训练已完成”“仅预训练,2.69B 稠密模型,30 层”和“无指令微调”,页脚为“两列数据均由厂商报告;尚无第三方对任一模型进行过评分”,右下角合成有 OrcaRouter 标志。
Engineering & Research

FrogNano-4B-2609 与 LFM2.5 2.6B Base:一个训练完成的专家模型与一堆预训练权重

作者

Elias Hawthorne

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

把一个问题输入LFM2.5 2.6B Base,它就会续写你的句子,而不是回答它。这不是缺陷——Liquid AI 发布它时,是将其作为 LFM2.5 家族底层的预训练检查点,并刻意把指令微调留给了它的非 Base 姊妹模型,而模型卡也明确说明它本就是为重度的微调而设计的。Microsoft 的 FrogNano-4B-2609则展现了这条流水线另一端的样子:同类型的小型语言模型,在合成代码仓库任务上经过五轮强化学习,直到它能通过一套五工具 harness 输出结构化的工具调用和候选补丁。两者都没有公开发布的独立基准测试。区别在于,其中一个已经完成了后训练,而搞清楚是哪一个,就是做出决定的全部依据。

下文的 FrogNano 数据来自微软的模型卡和技术报告。LFM 的数据来自 Liquid AI 的模型卡、其架构配置和许可证文件。归属于任一厂商的每个数字都被标注为厂商报告,而且这两个模型都没有经过第三方评估——对于 LFM2.5 2.6B Base 来说,这在很大程度上是设计使然,因为一个未经指令微调的检查点并不是聊天基准测试的公平目标。

只有当你知道自己比较的是什么时,比较才有效。

把两份规格表并排放在一起,最先出问题的就是参数数量。LFM2.5 2.6B Base 在 30 层中拥有 26.9 亿稠密参数——22 个双门控短卷积块和 8 个分组查询注意力层,在 16 种语言上使用约 34 万亿个 token 训练,词表规模为 128,000 个 token,上下文长度为 131,072 个 token。其量化版本在 Q4_K_M 下约为 1.67 GB。

FrogNano-4B-2609 的模型卡将其参数字段标为 "500M-5B" 区间,而模型摘要称其约为 46.6 亿。下载文件一锤定音:两个 safetensors 分片,总计 9.32 GB 的 BF16 权重、738 个张量,位于一套继承而来的稠密 32 层混合 Gated DeltaNet 与门控注意力堆栈上。检查点中还包含一个 24 层视觉塔,且从未进行过后训练。

所以大小比例大约是 1.7 比 1,而一旦把量化也算进来,内存比例就更接近 5.6 比 1。这个差距比参数规模那条线更重要,因为这两个模型都是自托管候选对象,而不是端点——这也是它们唯一有理由出现在同一篇文章里的原因。

• 预期用途 —— LFM2.5 2.6B Base 是用于微调训练的原材料。FrogNano-4B-2609 则是在 Leaf 框架内进行仓库级软件工程任务的成品策略模型。

• 指令遵循 — LFM2.5 2.6B Base 开箱即用时完全不具备这一能力;Liquid AI 的模型卡建议将其用于需要大量微调的任务。FrogNano-4B-2609 能够遵循任务描述并输出结构化的工具调用,因为这正是其强化学习目标所训练的内容。

• 上下文 — LFM2.5 2.6B Base 为 131,072 个 token,而 FrogNano 经评估的配置合计约为 131K 个 token。名义上完全相同,但 FrogNano 的窗口必须容纳工具结果、shell 输出和测试日志,而不仅仅是一个提示。

• 输出上限 — FrogNano 经过验证的配置允许每个助手回合生成 8,192 个 token。LFM2.5 2.6B Base 未公布对应的数值,因为它并非为结束回答而构建。

• 模态——两者均为纯文本。FrogNano 的视觉组件是继承而来的,且明确不受支持;LFM2.5 2.6B Base 在设计上即为文本输入、文本输出。

• 许可证 — LFM2.5 2.6B Base 采用 LFM Open License v1.0,该许可证在年收入低于 1000 万美元时免费,达到或超过这一门槛则需另行获得许可证,衍生作品也继承这一上限。FrogNano 的模型卡在前言中写的是 MIT,在正文中写的是 Apache 2.0。

微软买单的东西,以及你得自掏腰包的东西

这是承重部分,因为正是在这里,规格对比会产生误导。

FrogNano-4B-2609 的全部价值增量都在后训练,而微软已经公开了该方法。从 Qwen3.5-4B 开始,它作为通用模型通过 Leaf harness 在 SWE-bench Verified 上得分 39.4%。从真实快照生成候选仓库任务,从当前检查点运行 rollout 以找出它有时能解决的任务,保留这些任务,训练,然后重复——共五轮迭代,总计约 1,500 个经过验证的合成环境,并且全程任何时候都不从更大的模型进行蒸馏。微软自己模型卡上的结果是:SWE-bench Verified 上 61.5%,SWE-bench Pro 上 37.6%,Terminal-Bench 2.0 上 31.1%,PatchEval-Verified 上 47.3%。论文的效率附录把同一攀升过程报告为各轮迭代的 48.2%、53.4%、58.3%、58.6% 和 61.6%,这提醒我们,即便是该实验室自己对同一实验的两张表,也没有就这些台阶达成一致。

现在,把这一点对照 LFM2.5 2.6B Base 来看。它是那项工作开始之前的检查点。它的模型卡自身的建议——对它进行微调——正是 FrogNano 所记录的工作:一个任务环境、一个可执行奖励、一个运行更久的测试框架,以及针对不断变化的策略进行的若干轮训练。论文并未声称这很容易。它报告称,随着推理轨迹变长,中间检查点的训练成本逐步升高;必须加入日志长度惩罚以阻止漂移;并且后续迭代失去了基础模型原本具备的并行工具调用能力,最终并发调用率降至 1.71%。任何计划在不同的 2.6B 基础模型上运行 FrogNano 配方的人,都应专门为这三个问题做好预算。

LFM2.5 2.6B Base 带来的是另一种先发优势:34 万亿 token 的预训练预算、有文档记录的混合架构、现有的量化构建,以及有文档记录的 131,072 token 上下文,而这一切的体量小到可运行在 9.32 GB BF16 检查点无法装下的硬件上。如果你的任务足够狭窄,以至于小型微调模型能胜过通用模型,那确实是一种可行的定位——如果不是,你就省去了一次训练运行。

A generated two-column scoreboard titled 'FrogNano-4B-2609 vs LFM2.5 2.6B Base'. The left column reads State RL post-training complete, Params approx 4.66B with the card saying 500M-5B, Weights 9.32 GB BF16, Context about 131K evaluated, Licence MIT in front matter and Apache 2.0 in body, Independent scores none. The right column reads State pretrained checkpoint only, Params 2.69B dense, Weights 1.67 GB in Q4_K_M, Context 131,072 tokens, Licence LFM Open License v1.0, Independent scores none. A footer reads 'Both columns vendor-reported; no third party has scored either model.'

无论哪种方式你都必须构建的东西

这两个都不是网络调用,这一点对实际比较的影响比任何规格表中的一行都更大。

LFM2.5 2.6B Base 需要一套推理运行时和一次训练跑批。Liquid AI 的模型卡列出了原生格式、GGUF、ONNX 和 MLX 构建,所以服务这一半已经覆盖得不错——在笔记本电脑上跑 llama.cpp 对量化检查点是切实可行的选择。训练这一半归你:数据、目标、评估,以及一种判断结果是变好了还是只是变得不一样的方法。

FrogNano-4B-2609 想要一个兼容 OpenAI 的端点,并配有正确的解析器,以及一个拥有管理 Pod 和网络策略权限的 Kubernetes 集群。微软的 README 异常直白地指出,测试框架是依赖项,而不是便利项;模型卡也说明,要获得完全相同的分数,需要匹配的检查点、分词器、服务配置、任务镜像和评估协议。配置在这里不是细节——如果没有 Qwen3 推理解析器和 Qwen3 coder 工具调用解析器就提供服务,模型就会在测试框架期望工具调用时写出散文。

这就是这场对决的格局:一边是一个训练项目,只带有一个很小的服务问题;另一边是一个服务项目,带有一个很大的评估问题,而且已经没有训练要做。两者都是几个晚上的工作量。但只有其中一个是那种可能以“模型不够好”收场、而这并非你的过错的几个晚上工作量。

A screenshot of the Hugging Face model card for microsoft/FrogNano-4B-2609 showing the model summary table with the Parameters row reading 500M-5B, the Context length row reading approximately 131K tokens in the evaluated coding-agent configuration, the Training Dates row reading Jun 2026 to Aug 2026, the Release date row reading 22-SEP-2026, the License row reading Apache License 2.0, the Qwen/Qwen3.5-4B model dependency, and the model overview naming the dense 32-layer hybrid Gated DeltaNet and gated-attention architecture.

路由器在这样一套配置中如何占有一席之地

这两个模型最终都处在一个同样会调用托管服务的流水线里。FrogNano 自己的评估装置就是证明:Leaf 测试框架与一个 OpenAI 兼容端点通信,这意味着被测模型以及你用来与之比较的任何模型,都是通过同一个接口访问的。即便原因只是出于整洁规范,这也是一个值得复制的模式,而这也正是单个端点发挥具体作用的地方。

OrcaRouter 通过一个兼容 OpenAI 的密钥,提供 200 多个模型,零加价,因此提供商的标价原样透传,供应商调价当天就会在我们这边生效——而当你判断自托管专用模型在每任务成本上是否胜过托管通用模型时,真正会左右判断的正是这个数字。自动故障转移覆盖的是这一对比中的托管部分,而不是你自己正在服务的检查点。我们不托管 FrogNano-4B-2609 或 LFM2.5 2.6B Base;两者都是下载项。路由层所省去的,是每当你的基准测试中托管侧发生变化时,都要进行的第二次集成。

说实话,选一个

如果你的任务范围较窄、硬件规模较小,并且准备自行承担训练运行,就选择 LFM2.5 2.6B Base——营收低于 1000 万美元时许可证免费,量化构建为 1.67 GB,Liquid AI 自己的模型卡也正是为此推荐它。代价在于,你得到的是一个起点,而不是一项现成能力:该发布中没有任何内容能说明,在其之上进行一次 FrogNano 形态的 RL 运行会得到什么分数,而且也没有人公布过这样的结果。

如果任务是仓库级软件工程,并且你希望后训练已经完成,就选择 FrogNano-4B-2609。61.5%、37.6%、31.1% 和 47.3% 是来自一个详细描述其方法的实验室的真实已发表结果——而且此刻它们也是一个闭环:同一实验室、同一评测框架、同一基础模型基线。9.32 GB 的下载量、对评测框架的依赖以及复合授权,就是你跳过原本不得不自行运行的训练项目所付出的代价。

A generated pipeline card headed 'The same pipeline, two positions' showing three stages connected by arrows: 'Pretrained checkpoint' captioned LFM2.5 2.6B Base, 'RL on synthetic tasks, 5 iterations' captioned Microsoft's loop, and 'Finished agent' captioned FrogNano-4B-2609, with a footer reading 'Neither model has been independently evaluated; both appear as vendor-reported figures only.'

有用的重新理解是:这两者并非竞争关系。LFM2.5 2.6B Base 是某个流程的上游,而该流程产出了类似 FrogNano-4B-2609 的东西。如果你发现自己要在两者之间做选择,真正的问题在于你的问题是否值得为之自己跑一次训练——而如果答案是否定的,那么那个带有评测框架、公开方法和厂商报告 SWE-bench 阶梯的 4B 检查点,就是到手即完成的那一个。