FrogNano-4B-2609 对比 Gemma 4 12B：SWE-bench 得分 61.5%，却无人核实

微软的 FrogNano-4B-2609是一款四十亿级编程智能体，衍生自 Qwen3.5-4B，据称在 SWE-bench Verified 上得分 61.5%。Gemma 4 12B是 DeepMind 的 119.5 亿参数无编码器多模态模型，其模型卡显示在 LiveCodeBench v6 上得分 72.0%。买家会把这两个数字并排放在一起比较，而并排比较本身就是错误。它们来自不同的基准测试、不同的评测框架、不同的实验室，而且——更重要的是——其中只有一个拥有已公开、且被外部人士读过的评测方法。关于这场对比的其他一切，都取决于两个模型各自究竟是什么，而答案是：它们根本不属于同一类东西。

下方的 FrogNano 数据来自 Microsoft 的模型卡及其技术报告，二者自九月起就已公开，且实验室外无人复现过其中任何一份。Gemma 4 12B 的数据来自 Google 的模型卡，这也是一份厂商文档——不同之处在于，Gemma 的数字背后已有二十周以及约 260 万次下载带来的审视，而 FrogNano 只有两周时间，以及一个尚未突破个位数的下载计数器。

每个模型的用途

这是规格表所隐藏的部分。FrogNano-4B-2609 并不是一个碰巧擅长代码的通用模型。它是一个检查点，其整个后训练都是仓库级软件工程，并且它被设计为由执行框架驱动，而不是用来交谈。

它的五个工具是 Read、Write、Edit、Glob和 Bash。它向这些工具发出调用，沙箱执行调用并返回输出，循环持续运行，直到模型不再发出请求。评估配置是在大约 131K 总计 token 内进行 150 个交互步骤，并且它为每个任务生成了一个候选补丁。微软的模型卡明确指出，该模型适用于英语、以 Python 为主的仓库，这些仓库具有可复现的环境和可执行的测试套件，并且从基础模型继承的图像和视频组件从未经过后期训练，也不受支持。

Gemma 4 12B 则完全相反。它是一个 48 层的统一模型，拥有 256K 上下文，且没有独立的视觉或音频编码器——原始图像块和音频波形通过轻量级线性层直接投射到单一解码器的嵌入空间中。它接收文本、图像和音频输入，输出文本。它具备由系统提示中某个 token 触发的思考模式、原生函数调用，而 Google 的模型卡特意将智能体工作流列为其预期用途之一。

所以真正的问题不在于哪一个更聪明。而在于你想要的是一个只能在必须由你来操作的装置里运转的专用组件，还是一个在许多事情上都做得不错、并且能被任何东西调用的通用模型。

逐行说明它们实际存在差异的地方

• 参数——FrogNano-4B-2609 在模型卡上标出一个区间“500M-5B”，而该模型卡自身的描述写着约 46.6 亿；下载后确认其为 9.32 GB 的 BF16 权重。Gemma 4 12B 是 11.95B，只声明一次，绝不含糊。比例约为 2.6 比 1，并直接体现在你必须租用的资源上。

• 背景 — FrogNano 的评测配置合计约 131K 个 token，推理与工具输出共享这一预算。Gemma 4 12B 则拥有 256,000 个 token，并且在自身的长上下文一项上，于 128K 上下文中设置 8 个 needle 时，在 MRCR v2 上得分 43.4%。窗口几乎翻倍，而第二个数字是公开发表的实测结果，而不是能力宣称。

• 模态——FrogNano-4B-2609 是文本输入、文本输出，尽管其检查点中带有一个视觉塔。Gemma 4 12B 则支持文本、图像和音频输入。

• 输出上限 — 经过验证的 FrogNano 配置允许每个助手回合生成 8,192 个 token，其模型卡指出，RL 训练配置也使用了这一相同上限。Gemma 4 12B 没有公布等效的单回合上限；其约束在于 256K 窗口。

• 智能体接口 — FrogNano 发出结构化的 Leaf 调用，需要一个执行框架来运行它们。Gemma 4 12B 的指令微调版本内置了原生函数调用功能，可直接调用。

• 许可证 — Gemma 4 12B 依据 Google 的 Gemma 4 条款采用 Apache 2.0，表述得清清楚楚。FrogNano 的模型卡在前置声明中写的是 MIT，而在其正文中写的却是 Apache 2.0，这种模棱两可最终会进入法律审查，而不是被当作脚注一带而过。

• 数字 — FrogNano 报告 61.5% SWE-bench Verified、37.6% SWE-bench Pro、31.1% Terminal-Bench 2.0 和 47.3% PatchEval-Verified。Gemma 4 12B 报告 77.2% MMLU Pro、72.0% LiveCodeBench v6、Codeforces ELO 为 1659、78.8% GPQA Diamond，以及在 Tau2 上为 69.0%。Google 的模型卡未公布 SWE-bench 一栏，Microsoft 的模型卡未公布 LiveCodeBench。这两个评分榜之间完全没有重叠。

最后那一条要点，正是应当终结“按数字比较”这种本能的一条。两张卡片上没有任何一项基准测试是重合的。读者若把 61.5 和 72.0 摆在一起比较，那是在拿代码仓库问题的解决率去比竞赛编程的通过率——这大致相当于因为马拉松成绩和百米成绩都以秒计，就把两者拿来相提并论。

为什么谷歌在 SWE-bench 上的沉默并非危险信号

从项目符号列表得出的诱人结论是：FrogNano 有一个真实的 SWE-bench 数值，而 Gemma 没有，所以 FrogNano 在编程问题上胜出。这并不能推出，原因值得精确说明。

Gemma 4 12B 报告 Tau2 达到 69.0% —— 一项经过三次运行的智能体工具使用基准测试 —— 同时还有其函数调用支持以及明确面向智能体工作流的定位。一个在 Tau2 上得分 69.0 的模型并不是一个无法完成智能体工作的模型；而是一个其供应商选择报告工具使用性能而非代码仓库问题解决能力的模型。Google 也没有为 26B 或 31B 报告 SWE-bench 结果行，这是整个模型系列的编辑选择，而非 12B 的弱点。

与此同时，微软自己论文中那个反直觉的结果，是 Gemma 买家应该仔细阅读的。FrogNano 从 Qwen3.5-4B 这个通用模型起步，该模型通过 Leaf 测试框架在 SWE-bench Verified 上得分 39.4%。在约 1,500 个合成任务上进行五轮强化学习后，其得分提升至 61.5%。这个教训不是“小模型不能写代码”——而是，当有人在合格的智能体循环中运行一个通用 4B 检查点时，它在 39.4% 的得分下已经解决了一个困难、经人工验证的问题集中超过三分之一的问题。Gemma 4 12B 的规模是它的三倍，并且成熟了二十周。还没有人通过 Leaf 运行它，而在有人这样做之前，“Gemma 不是代码仓库代理”只是一个假设，而不是一个发现。

排行榜完全掩盖的测试框架税

这就是实际的不对称性，而决定是否购买的正是它。

Gemma 4 12B 是一个模型。下载 11.95B 的权重，让 Transformers、vLLM 或 SGLang 指向它们，输入文本，得到文本。Google 公布了服务路径，许可证明确无误，而 260 万次下载量所代表的人们已经踩过那些坑，并记录了下来。如果任务是“总结这个堆栈跟踪”、“看这张截图并告诉我哪里坏了”，或者“用这些参数调用这个函数”，那么它今天就能用。

FrogNano-4B-2609 是一个模型，外加一套评测框架（harness），而微软自己的 README 明确表示这套框架并非可选。github.com/microsoft/FrogNano该仓库是 Leaf 的评测装置，而非训练代码——它需要 Kubernetes 集群、一个已存在的命名空间、管理 pod 与网络策略的权限、拉取基准容器镜像的访问权限，以及一个配置了正确推理与工具调用解析器的 OpenAI 兼容端点。微软的模型卡直言其匹配条件：要让分数完全一致，就必须有匹配的检查点、分词器、服务配置、任务镜像和评测协议。这次发布中真正产出分数的那一半，正是模型卡指向一个 GitHub 链接的那一半。

这其中有真正的价值，值得点明，而不是轻易否定。FrogNano 的贡献是一个任务合成循环，它会根据当前策略的能力重新生成训练问题——论文声称，一个小型智能体可以在合成任务上被训练到具有竞争力的水平，完全无需蒸馏，这为任何负担不起前沿教师模型的人开辟了一条路径。它的 API 是公开的。它的方法原则上可复现。这比又一个渐进式检查点更有价值，而且其工作量也超出了大多数团队愿意投入的程度。

如果你要选一个，就根据任务来选。

如果工作涉及多种模态，如果任何环节需要查看图像或收听音频，如果上下文必须同时容纳庞大的文件树和冗长的转录文本，或者如果你想要一个任何框架都能加载、无需背后再有第二个系统的模型，那就选 Gemma 4 12B。它的 69.0 Tau2 分数和原生函数调用能力，使其成为智能体流水线中站得住脚的选择，而且不必只听某家实验室的一面之词——该模型已经过数千人的评估，结果并非秘密。

如果你已经在运行一个沙箱化的智能体，并且想要一个 4B 级别的检查点直接放进去，那就选 FrogNano-4B-2609；如果驱动这一决定的是一个 9.32 GB、能装进普通硬件的下载包，也是如此。要清醒地看待这个选择：你买的不是一个分数，而是在赌一种方法，而你首先会弄清楚的，就是你的轮询循环和工具调用解析器是否足够像 Leaf。有些团队会在第三个下午就得到 61.5% 的行为表现，有些则会花上两周，才发现自己的评估集比 SWE-bench Verified 更容易；而实验室之外还没有人能告诉你，你属于哪一种。

如果这个决定确实势均力敌，那么最省钱的实验，就是在同一个测试框架里、用你自己的问题把两者都跑一遍，而不是去争论那些毫无共同基准的公开数字。OrcaRouter 能在一个与 OpenAI 兼容的密钥 之下以 0% 加价承载 200 多个模型，因此各提供商的标准挂牌价原样透传——这样你在做决定的同时，就能把某个托管通用模型与候选项中的其余模型放在同一个端点、同一条账单线下。FrogNano 不在我们的路由之列，也没有上线日期；其权重需要你自己下载、自行托管。我们能消除的，是这场对比另一侧的摩擦：在你自己的测试框架里更换候选模型，而无需第二份合同、第二个 SDK 或第二套凭证。

诚实的总结是：61.5 这个数字是做出它的实验室完成的真实工作，而且它目前是在编程方面更青睐 FrogNano 的唯一理由。当 Microsoft 之外的某个人在同样的 500 个任务上复现出 61.5——或者复现失败——时，这场对比才会得到真正的答案。在那之前，对大多数团队来说，更稳妥的默认选择是那个拥有干净许可证、已公布的长上下文测量结果，并且其文档已经吸收了二十周以来其他人所犯错误的 11.95B 模型。