别只盯 Qwen：这个 35B 本地模型每次只动 3B，有人跑得飞快，也有人被它想崩了

结论

本地 Coding Agent 圈最近冒出一个不太像“榜单模型”的名字：Ornith-1.5-35B-A3B。

它的总参数约 35B，但官方称每个 Token 只激活约 3B 参数。模型卡给出的 Terminal-Bench 2.1 结果是 67.8（Terminus-2）和 68.5（Claude Code），SWE-bench Verified 为 79.0，SWE-bench Pro 为 59.6，NL2Repo 为 46.2。对照表里的 Qwen3.6-35B-A3B 分别是 52.5、49.2、73.4、49.5 和 29.4。

分数很高，社区也没有立刻把它判成纸上谈兵：有人拿量化版做了三个真实开发任务，称一次完成且速度约为 Qwen3.8-27B 的两倍；另一套 RTX 4070 测试把修复 MTP head 的版本跑到约 63.7 tok/s。但也有人遇到严重过度思考，甚至在长任务中被更大的 Ornith 版本拖垮。

我的判断是：它值得本地玩家拿自己的仓库跑一遍，暂时不值得宣布“全面击败 Qwen 或 DeepSeek”。这次真正值得看的，是低 active 参数、训练脚手架、量化和 Agent harness 叠在一起后，能不能让本地模型一直干活。

官方成绩为什么会让人怀疑

Ornith 1.5 是 MoE 模型。35B 是总参数量，约 3B 是每个 Token 的激活量。激活量低，通常意味着在相同上下文和运行时下，推理成本有机会低于完整激活的 dense 模型；它不等于显存只需要装 3B。

官方模型卡列出的编码和 Agent 结果很漂亮：

• Terminal-Bench 2.1（Terminus-2）：67.8；
• Terminal-Bench 2.1（Claude Code）：68.5；
• SWE-bench Verified：79.0；
• SWE-bench Pro：59.6；
• NL2Repo：46.2。

官方还说明，这些结果使用了明确的 harness、上下文、温度和超时设置，部分结果是五次独立运行的平均值；SWE-bench 评测关闭网络并移除 Git 历史，避免直接取到外部答案。这些信息让分数更容易复核，但它们仍然是模型团队选定配置下的结果。

所以“假跑分”现在没有证据，“无条件相信”也没有理由。最合理的做法是把官方结果当作需要独立测试的强信号。

第一批本地用户没有给出同一个答案

LocalLLaMA 一条讨论里，有用户用 Ornith-1.5-35B-A3B 的 Q4_K_M 量化版做了三个任务：给现有客户实体增加字段并补 API/UI、审计大型 B2B 应用权限漏洞、把 ninfer 移植到 Windows Native。他称三个任务都完成了，整体速度约为 Qwen3.8-27B 的两倍。

这只是三项任务、一个用户、一个配置，不能证明模型全面超过 Qwen。但真实代码库、跨前后端改动和平台移植，确实比再贴一张厂商榜单更接近日常使用。

另一位用户则说，Ornith 是自己测试过最严重的 overthinking 模型之一，一次回答能烧掉两三万 reasoning token，甚至碰到 32K context 墙仍未结束。模型每个 Token 激活得少，不代表它不会生成更多 Token。

这就是本地 Agent 最容易被忽略的账：速度要看 decode，也要看模型为了完成一个任务到底想了多久。

4070 上的 63.7 tok/s，前提比数字更重要

独立测试仓库记录了一版修复 MTP head 的 Ornith 量化版本。作者认为官方 MTP head 没有训练好，替换为继续训练过的 head 后，在 RTX 4070 上测到约 63.7 tok/s；12 项标准测试通过 11 项，平均任务延迟 15.3 秒。

对比同一作者此前的记录，调过参数的 Ornith 1.5 约 23.1 秒，Qwen3.6 vanilla 约 41.5 秒。这个结果很有价值，但不能写成“4070 普遍 63.7 tok/s”：硬件、量化、上下文、采样参数和是否使用 MTP 都不同，测试电池也由作者维护。

它反而说明了一件更重要的事：开源模型的最终体验不只由 checkpoint 决定。MTP head、量化格式、runtime、采样参数和 Agent harness，可能共同决定你觉得它是黑马还是麻烦。

更大的版本也可能在长任务里输掉

社区还有一个反方向案例：有人测试 Ornith-1.5-397B Q8，在自己的复杂任务上没有完成；同样的任务里，DeepSeek V4 和 Qwen3.8-27B 能从错误中恢复并完成。

这不是一次可推广的模型排名，也不是对 397B 的系统评测。但它提醒我们，Agent 的难点不是某一步答对，而是走偏以后能不能发现、回滚和继续。参数量更大、单题能力更强，并不自动等于长任务体验更好。

真正新的是训练路线

Ornith 1.5 官方强调的重点，不只是 MoE，而是 end-to-end self-improvement。团队描述的路线是：联合优化任务生成、脚手架构建和解决过程，让模型持续生成新的训练任务、寻找解决策略，再用强化学习更新策略。

这和固定题库加固定 harness 的训练思路不同。它更像是在训练模型如何面对一类任务，以及如何为自己搭建工作流程。

如果这条路线有效，未来本地 Coding Agent 的竞争可能不只看参数规模，还要看谁能生成更像真实工作的轨迹，谁能更好地记住上下文、调用工具、重试和恢复。

现在值不值得下载

如果你已经在用 Qwen3.8-27B、Qwen3.6-35B-A3B，或者手上有 4070、4090、5090、Mac Studio 和高内存 Mac，我认为值得试一遍。官方模型卡给出 262,144 Token 上下文，建议使用近期版本的 Transformers、vLLM 或 SGLang；量化生态也已经出现。

不要只跑一道 LeetCode。拿最近真实做过的五个任务，记录：完成率、总耗时、生成 Token、返工次数、是否需要人工纠正，以及失败后能否恢复。然后用同一套任务跑 Qwen 或 DeepSeek。

仍然要观察

• 更大规模、不同作者的独立 Coding Agent 测试；
• Ornith 1.5 在默认参数与调优参数下的差距；
• MTP head 修复是否会进入主流量化和 runtime；
• overthinking 对长任务总耗时和上下文预算的影响；
• 397B 与 35B 版本在失败恢复上的稳定性；
• Ollama、llama.cpp、vLLM 等运行时对工具调用和 reasoning parser 的支持。

常见问题

35B-A3B 是不是只需要 3B 模型的显存？

不是。约 3B 是每个 Token 的激活量，权重仍然包含约 35B 参数。官方模型卡给出的 bf16 权重约 70GB，量化后才适合更小的本地设备。

官方分数能证明它已经超过 Qwen 吗？

不能。它证明 Ornith 在官方配置和这些基准上很强；独立测试样本仍小，真实体验受到量化、runtime、采样和 harness 影响。

MTP 修复版 63.7 tok/s 是所有 RTX 4070 都能达到吗？

不是。这是一个作者在特定 RTX 4070、量化和运行参数下的结果，适合当作潜力信号，不是硬件承诺。

我们的判断

Ornith 1.5 现在最值得写的地方，不是它已经成为本地模型新王，而是它把一个很具体的路线摆到了桌面上：35B 的知识容量、3B active 的计算路径，再加上自我改进训练和本地 Agent 工具链。

如果它能解决过度思考、失败恢复和运行时适配，低 active MoE 可能会成为本地 Coding Agent 很实际的方向。现在最好的动作不是替它封王，而是拿自己的仓库跑一轮，看看它究竟是快、聪明，还是只是更快地想太多。