> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Ornith-1.0-35B：超快的MoE模型 - URL: https://www.hubwiz.com/blog/ornith-1-0-35b-a-super-fast-moe-model/ - Published: 2026-07-02T02:16:05.000Z - Updated: 2026-07-02T02:16:05.000Z - Description: DeepReinforce的Ornith-1.0–35B MoE模型以极低的计算量提供了接近27B密集模型的质量。我在llama.cpp上测试了它——无需任何升级。 - Author: admin - Tags: MODEL-ZOO, ORNITH-1.0-35B, #Import 2026-10-14 14:41 我已经在本地运行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](https://github.com/Weschera/spark-bench?ref=hubwiz.com)——一个涵盖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模型相同的`` / ``思考标签。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](https://xhinker.medium.com/ornith-1-0-35b-the-moe-model-that-runs-like-3b-thinks-like-27b-1e7a0fe5a64e?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处