Ornith-1.5 纯编程能力横评：9B 打 35B，是实力还是数据游戏？
摘要：本文基于官方 Benchmark 数据，对 Ornith-1.5 的 9B、35B 与 397B 三个版本进行纯编程能力横评，并与 Ornith-1.0、Qwen、Gemma、DeepSeek 及 Claude Opus 4.8 逐项对比。结果显示：9B 在编码任务上大面积超越 30B+ 模型，35B MoE 全面压制同尺寸竞品，397B 首次进入 Claude Opus 4.8 的对话圈；而全文最关键的信号是 DeepSWE 从 8.0 涨到 56.0（+48 分），证明自生成任务训练带来了质的飞跃。文章同时指出 Benchmark 分数、Agentic 组合分与官方自测背后的三个隐藏前提，并给出不同硬件场景下的版本选型建议。
Ornith-1.5 纯编程能力横评：9B 打 35B，是实力还是数据游戏？
上一篇我们问了"自改进是不是自欺欺人"，这一篇只谈数字——把 Ornith-1.5 放到一张表上，跟 Ornith-1.0、Qwen、Gemma、DeepSeek 逐项对比。
数字会说真话，但前提是你看懂它们背后的口径。
一、先看一张总表：9B vs 35B vs 旗舰
在进入横向对比前，先把三个尺寸的定位说清楚：
| 尺寸 | 架构 | 激活参数 | 适用场景 | Ollama 命令 |
|---|---|---|---|---|
| 9B Dense | 稠密 | 全 9B | 笔记本/手机/轻量 Agent | ollama run ornith-1.5:9b |
| 35B MoE | MoE | 每 token 3B | 单卡工作站（RTX 4090） | ollama run ornith-1.5:35b |
| 397B MoE | MoE | 未公开 | 多卡服务器/集群 | 需 vLLM + 多 GPU |
⚠️ 关键提醒：MoE 模型的"激活参数"才是决定推理速度和显存占用的关键。35B 总参数听起来吓人，但每次只激活 3B——所以它跑起来更像一个 3B 模型，但知识密度接近 35B。
二、9B 级别横评：小身材 vs 大块头
这是最让人困惑的对比组：Ornith-1.5-9B 只有 9B 参数，但它在编码任务上大面积超越 30B+ 模型。
| Benchmark | Ornith-1.5-9B | Ornith-1.0-9B | Qwen3.5-9B | Qwen3.6-35B-A3B | Gemma-4-31B |
|---|---|---|---|---|---|
| Terminal-Bench 2.1 | 47.0 | 40.6 | 18.9 | 49.2 | - |
| SWE-Bench Verified | 70.6 | 69.4 | 53.2 | 73.4 | 52.0 |
| SWE-Bench Pro | 47.5 | 42.9 | 31.3 | 49.5 | 35.7 |
| SWE-Bench Multilingual | 54.4 | 52.0 | 39.7 | 67.2 | 51.7 |
| NL2Repo | 32.4 | 27.2 | 16.2 | 29.4 | 15.5 |
| GPQA Diamond | 86.4 | 82.5 | 81.7 | 86.0 | 84.3 |
| MCP-Atlas | 54.2 | 49.4 | 46.8 | 62.8 | 55.0 |
| Toolathlon-Verified | 41.2 | 33.4 | 29.6 | 41.7 | 52.8 |
| WideSearch | 59.5 | 55.8 | 53.6 | 60.1 | 54.2 |
| BrowseComp | 56.4 | 44.8 | 41.5 | 62.0 | - |
| ClawEval | 66.5 | 63.1 | 53.2 | 68.7 | 48.5 |
9B 级别的三个关键发现：
-
Ornith-1.0 → 1.5 的升级是实打实的。不是"换个壳又发一次"——Terminal-Bench 从 40.6 涨到 47.0（+6.4），SWE-Bench Verified 从 69.4 到 70.6（+1.2），NL2Repo 从 27.2 到 32.4（+5.2）。这些涨幅来自训练方法的改变，不是调参。
-
9B 打 35B-A3B 有来有回。在 SWE-Bench Verified 上，9B 的 70.6 距离 35B-A3B 的 73.4 只差 2.8 分；在 GPQA Diamond 上甚至反超（86.4 vs 86.0）。但在 MCP-Atlas 和 BrowseComp 上，35B-A3B 明显更强——说明 35B 的工具调用和检索能力仍是优势。
-
对 Gemma-4-31B 是碾压。9B 在所有编码任务上大幅领先 31B 的 Gemma-4。这不是"小模型优化得好"能完全解释的——Gemma-4 的 backbone 本身就不是以 coding 见长，但差距幅度（如 SWE-Bench Verified 70.6 vs 52.0）已经超出"模型定位不同"的范畴。
三、35B 级别横评：甜点位的真本事
35B MoE（激活 3B）是本地开发者最该关注的尺寸。它比 9B 贵不了多少（显存 24GB vs 8GB），但能力上限更高。
| Benchmark | Ornith-1.5-35B | Ornith-1.0-35B | Qwen3.6-35B-A3B | Gemma-4-31B |
|---|---|---|---|---|
| Terminal-Bench 2.1 | 68.5 | 64.2 | 52.5 | 43.4 |
| SWE-Bench Verified | 79.0 | 75.6 | 73.4 | 52.0 |
| SWE-Bench Pro | 59.6 | 44.6 | 49.5 | 35.7 |
| SWE-Bench Multilingual | - | 60.3 | 67.2 | 51.7 |
| NL2Repo | 46.2 | 34.6 | 29.4 | 15.5 |
| ClawEval | - | 65.4 | 65.4 | 48.5 |
35B 级别的关键发现：
-
全面压制 Qwen3.6-35B-A3B。Terminal-Bench 68.5 vs 52.5（+16），SWE-Bench Verified 79.0 vs 73.4（+5.6），NL2Repo 46.2 vs 29.4（+16.8）。这是同尺寸 direct competition，Ornith 的训练方法优势完全显现。
-
Ornith-1.0 → 1.5 的升级幅度比 9B 更大。SWE-Bench Verified +3.4，NL2Repo +11.6——自改进闭环在更大模型上反而释放了更多增益，因为大模型有更强的"出题能力"。
-
对 Gemma-4-31B 仍是碾压。但要注意：Gemma-4-31B 是 Dense 31B，Ornith 是 MoE 35B（激活 3B）。从激活参数看，Ornith 用 1/10 的计算量赢了 2 倍以上的分数，这是 MoE 架构的效率红利。
四、旗舰对比：397B vs Claude Opus 4.8
| Benchmark | Ornith-1.5-397B | Claude Opus 4.8 | DeepSeek-V4-Flash | GLM-5.2 |
|---|---|---|---|---|
| Terminal-Bench 2.1 | 86.1 | 85.0 | 82.7 | 82.7 |
| DeepSWE | 56.0 | 59.0 | 54.4 | 46.2 |
| SWE-Bench Verified | 86.0 | 85.8 | - | - |
397B 级别的结论：
- Terminal-Bench 反超 Claude Opus 4.8（86.1 vs 85.0），但差距极小（1.1 分），在 benchmark 误差范围内
- DeepSWE 仍落后 Claude（56.0 vs 59.0），但领先 DeepSeek-V4-Flash（+1.6）和 GLM-5.2（+9.8）
- SWE-Bench Verified 几乎持平（86.0 vs 85.8），这是最接近工业级真实编码能力的指标
一句话：397B 是开源模型第一次在编码能力上正式进入 Claude Opus 4.8 的对话圈，但还没到"碾压"的程度。
五、真正的信号：看涨幅，不看绝对值
Ornith 官方最有说服力的数据不是"我们比谁高"，而是Ornith-1.0 → 1.5 的涨幅：
| Benchmark | 1.0 → 1.5 涨幅 | 说明 |
|---|---|---|
| DeepSWE | 8.0 → 56.0 (+48) | 真实工程项目，最难刷分 |
| Terminal-Bench 2.1 | 77.5 → 86.1 (+8.6) | 第三方 benchmark，可信度较高 |
| SWE-Bench Verified | 82.4 → 86.0 (+3.6) | 接近 Claude Opus |
| NL2Repo | 48.2 → 56.0?（9B 32.4，35B 46.2） | 从零构建仓库的能力 |
DeepSWE 的 +48 分是全文最重要的数字。它不是"调参优化"能解释的——DeepSWE 的多样性太高，需要模型真正理解项目结构、定位 bug、写补丁。+48 分的唯一合理解释是：自生成任务训练产生了质的飞跃。
六、数据背后的三个隐藏前提
在看表的时候，必须记住三个"不等于"：
-
Benchmark 分数 ≠ 日常编码能力
- SWE-Bench 测的是"给一个 issue，生成能通过测试的补丁"
- 不等于"给你一个 10 万行代码库，你能读懂并重构"
- 不等于"你能跟产品经理聊清楚需求再写代码"
-
Agentic 分数是"模型 + Harness"的组合分
- Ornith-1.5 的 benchmark 大多用 OpenHands / Terminus-2 / Claude Code 等 harness
- 换一个 harness，分数可能完全不同
- 你本地用 Ollama 跑，没有这些 harness，分数会打折扣
-
官方自测 ≠ 第三方复现
- 截至本文截稿，Ornith-1.5 的所有 benchmark 均为官方自测
- 社区对 Ornith-1.0 的质疑（"benchmaxxed Qwen"）仍在延续
- 独立评测尚未到来，这是最大的未知数
七、结论：谁该用 Ornith-1.5 的哪个版本？
基于纯 benchmark 数据，给出三个具体建议：
| 你的场景 | 推荐版本 | 理由 |
|---|---|---|
| 笔记本 / 8GB 显存 / 手机 | 9B | 6.6GB 就能跑，GPQA 86.4 接近 Claude 级别，编码能力超越 30B 模型 |
| RTX 4090 / 24GB 显存工作站 | 35B MoE | 激活 3B 参数，推理速度接近 9B，但 SWE-Bench 79.0 接近 Claude 级别 |
| 多卡服务器 / 追求极致 | 397B MoE | Terminal-Bench 86.1 超越 Claude Opus 4.8，但需 8×80GB GPU |
最关键的一句话：如果你只信一个数字，信 DeepSWE 的 +48 分——它最有说服力地证明了"自改进训练"不是营销话术，而是真的改变了模型的能力边界。
但如果你要决定"要不要把 Ornith-1.5 用到生产环境"，等下一篇——实测篇会告诉你，benchmark 的 70.6 分和日常 coding agent 的体验之间，还隔着一个鸿沟。
本文基于 Ornith AI 官方公告（ornith.ai/ornith_1_5.html）、HuggingFace 模型卡（ornith-ai/Ornith-1.5-9B / Ornith-1.5-35B-A3B）、Ollama 库、Byteiota 及 AI Beat 分析整理。所有 Benchmark 数据均为官方自测，尚未经独立第三方复现。截稿于 2026-08-20。
这是 Ornith-1.5 系列第二篇。上一篇讲了自改进机制与质疑，下一篇会讲实际部署体验——看看 70.6 分的 SWE-Bench 在真实 coding agent 场景里兑不兑现。
附：核心信源
| 事项 | 来源 |
|---|---|
| 9B 完整 Benchmark | HuggingFace: ornith-ai/Ornith-1.5-9B |
| 35B Benchmark | HuggingFace: ornith-ai/Ornith-1.5-35B-A3B |
| 1.0 vs 1.5 涨幅 | ornith.online、Byteiota、AI Beat |
| 397B vs Claude Opus | ornith.ai 官方博客、Byteiota |
| 部署与硬件要求 | Ollama 库、SaaSCity、dev.classmethod.jp |
| 社区质疑 | RuntimeWire、Hacker News、MIT Tech Review |
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
19
0- 0
已为社区贡献2条内容
所有评论(0)