Ornith-1.0-35B：超快的MoE模型

我已经在本地运行Qwen3.6–27B好几个月了。它一直是我处理编码、推理和智能体任务的主力模型。这是个可靠的模型，但27B的密集参数需要强大的硬件支持。

今天Ornith-1.0–35B在HuggingFace上发布了，我忍不住要试试看。

让我惊讶的是：一个350亿参数的模型，每个token只激活约30亿参数，就能在消费级硬件上流畅运行，并且在编码和工具使用方面达到了密集27B模型的水平。

无需升级llama.cpp，无需特殊的服务栈。只需下载GGUF文件即可运行。

它非常快，真的非常快。

1、什么是Ornith-1.0–35B？

Ornith-1.0是DeepReinforce基于Qwen 3.5预训练权重并使用其"自脚手架"RL方法微调的一系列模型。35B变体是一个 混合专家（MoE）模型——总参数量为350亿，但每个token仅激活约30亿参数。

可以这样理解：你的模型拥有350亿规模的"大脑"，但对于任何一个特定的想法，它只激活相关的30亿神经元。其余的保持空闲，节省算力。

结果是？在约30亿活跃算力下，达到接近270亿密集模型的质量。

对于本地AI来说，这正是我们一直在等待的最佳平衡点。

2、关键数据

我运行了Weschera的spark-bench——一个涵盖10个领域57个场景的综合能力基准测试。以下是它与Qwen3.6系列的对比：

Model                     Overall   Coding   Math   Tool Use   Reasoning
Ornith-1.0-35B            41.07     62.26    47.29  58.14      38.92
Qwen3.6-27B (dense)       43.12     64.18    49.87  56.32      41.05
Qwen3.6-35B-A3B (MoE)     39.84     59.47    44.12  52.88      37.21

几点值得注意：

Ornith全面超越Qwen3.6–35B-A3B。 这是它与最具直接可比性的模型——两者都是35B MoE，活跃参数约3B。但Ornith的自脚手架RL训练使其在编码（+2.8分）、工具使用（+5.3分）和推理（+1.7分）方面具有明显优势。

Ornith与Qwen3.6–27B的差距微乎其微。 密集27B模型在总体得分上仍然领先（+2.05分），但在编码方面的差距急剧缩小（+1.92分），而工具使用方面Ornith实际上已经反超（+1.82分）。在数学和纯推理方面，密集模型仍有优势——但对于智能体编码工作来说，Ornith极具竞争力。

3、MacBook实战测试：真实硬件，真实速度

接下来就有意思了。我把Ornith-1.0–35B接入MacBook上的AZ PAL，运行了真实的智能体工作流程——网页搜索、代码生成、文件编辑，全套流程。

体验如何？几乎与Qwen3.6–27B相同，但更快。

Ornith的MoE架构意味着每个token只激活约30亿参数。在llama.cpp的Q4_K_M量化下，这意味着每个token的计算量远低于密集27B模型，尽管总参数量更高。

Model                     Q4_K_M Size   Active Params   Est. tok/s (M4 Max 64GB)
Ornith-1.0-35B (MoE)      21.2 GB       ~3B             ~75-85 tok/s
Qwen3.6-27B (dense)       16.5 GB       27B             ~15-18 tok/s
Qwen3.6-35B-A3B (MoE)     20.5 GB       ~3B             ~65-75 tok/s

Ornith的GGUF文件在Q4_K_M下为21.2 GB，略大于Qwen3.6–27B的16.5 GB，但每个token的活跃算力大约低9倍。这就是MoE的魔力：你需要预先支付内存成本来加载所有专家，但每个token只需30亿参数的计算量。

在我的M4 Max 64GB上，Ornith在Q4_K_M下舒适运行，总VRAM使用约25 GB（权重+KV缓存+运行时），为上下文和其他应用留下了充足的空间。

4、无需升级llama.cpp

这一点值得强调：Ornith-1.0–35B可直接与当前版本的llama.cpp配合使用。

该模型使用与Qwen模型相同的<think> / </think>思考标签。llama.cpp原生支持MoE路由。无需自定义补丁、无需专门构建版本、无需等待上游支持。

我只需下载GGUF文件，将其指向Agent，它就能正常工作。思考标签解析正确，工具调用正常，模型处理多轮智能体循环也没有问题。

5、Ornith的亮点与局限

编码和工具使用： 这是Ornith的主场。自脚手架RL训练专门针对智能体编码工作流程设计。在我的测试中，它生成的代码干净整洁，能很好地处理多文件编辑，并能以良好的判断力使用工具（网页搜索、Shell命令）。

推理： 不错，但尚未达到Qwen3.6–27B的水平。对于纯数学或复杂逻辑推理，密集27B模型仍有优势。但对于编码中重要的推理（调试、架构决策、代码审查），Ornith已经绰绰有余。

长上下文： 该模型支持200K以上的上下文窗口。我尚未将其推向极限，但在32K-64K范围内，它处理大型代码库和多文档RAG没有问题。

它不是： 如果你需要最大的推理深度或数学能力，它无法替代Qwen3.6–27B。但如果你的主要工作是编码、工具使用和智能体工作流，Ornith以极低的计算成本提供了90%的质量。

6、结束语

Ornith-1.0–35B是那种让你重新思考参数数量军备竞赛的模型。

350亿总参数。每token活跃30亿。编码和工具使用接近270亿密集模型质量。在消费级硬件上运行。无需特殊服务栈。

对于MacBook上的本地AI来说，这就是最佳平衡点。

如果你正在本地运行Qwen3.6–35B-A3B，升级到Ornith。如果你正在运行Qwen3.6–27B并希望在不大幅牺牲质量的前提下获得更快的推理速度，试试Ornith。GGUF文件在HuggingFace上，与llama.cpp的集成无缝衔接，结果不言自明。

本地开源AI在不断进步，MoE模型能这样改进仍然令人惊讶，而且似乎还有很大的提升空间。期待Qwen3.7–27B。

原文链接: Ornith-1.0–35B: The MoE Model That Runs Like 3B, Thinks Like 27B

汇智网翻译整理，转载请标明出处