35B 总参数只激活 3B：Ornith 稀疏激活"偷工减料"却更快的秘密

2026 年 8 月，Ornith-1.5 系列开源模型正式发布。在家族三个规模（397B MoE、35B MoE、9B Dense）里，最让社区兴奋的并不是旗舰 397B，而是这位"中间档选手"——Ornith-1.5-35B-A3B。理由很直白：它的名字里藏着两个数字，35B 是总参数，3B 是每个 token 实际激活的参数。社区里有用户戏称这是"35B 总参数，推理只激活 3B 到 8B"，也有人把它视为"小显存部署大模型的新答案"。

"偷工减料"却更快的模型，听起来像是营销话术，但在稀疏激活（Sparse Activation）的技术框架下，这恰恰是 MoE 架构最核心的工程红利。本文从源码仓库与官方评测出发，拆解三个问题：稀疏激活到底省了什么、为什么省了算力反而更快、这份效率又付出了怎样的代价。

从"全员上场"到"按需点将"：稀疏激活到底做了什么

先回顾一个常识。传统 Dense（稠密）模型处理任意一个 token 时，网络里的每一层、每一个参数都要参与计算——35B 参数就是 35B 计算量，没有任何讨价还价的余地。而 MoE（Mixture-of-Experts，专家混合）架构把每个 Transformer 块中的前馈网络（FFN）替换为一组并行的"专家"子网络，由一个轻量的路由器（Router）根据当前 token 的特征，动态挑选最合适的少数几位专家参与计算。

这就是稀疏激活的本质：把"总参数"当作知识容量，把"激活参数"当作单步计算预算。35B 的总参数保证模型拥有接近 35B 级模型的记忆与推理储备，但每一步前向计算只动用其中约 3B 参数的算力，其余专家处于待机状态，等待下一个 token 的召唤。

Ornith-1.5 系列延续了 Ornith-1.0 的路线——后者基于 Qwen3.5 与 Gemma 4 继续预训练而来，因此 A3B（Active 3B）这套 MoE 配置天然继承了该家族成熟的设计语言。官方模型卡对它的定位是一句话总结："It activates only ~3B parameters per token, yet significantly outperforms its similar-sized peer Qwen 3.6-35B across all coding and agentic benchmarks"，即每 token 仅激活约 3B 参数，却在全部编码与智能体基准上显著超越同体量的 Qwen 3.6-35B。仓库 README.md 中这句话，正是全文的题眼。

一份"偷工减料"的评测成绩单

"省"了算力的模型，能力上会不会打折扣？官方在 README.md 中给出了完整对比表，选取几组最有冲击力的数据：

• Terminal-Bench 2.1（Terminus-2 框架）：67.8，同体量 Qwen 3.6-35B 为 52.5，稠密模型 Gemma 4-31B 仅 42.1，Muse-Glimmer-30B 为 51.7——而 Qwen 3.5-397B 也只有 53.5。激活 3B 参数的模型，在真实终端任务上跑赢了总参数 397B 的对手；
• SWE-bench Verified：79.0，对比 Qwen 3.6-35B 的 73.4、Gemma 4-31B 的 52.0、Qwen 3.5-397B 的 76.4；
• DeepSWE：22，前代 Ornith-1.0-35B 与 Qwen 3.6-35B 均为 0，Qwen 3.5-397B 也只有 1；
• NL2Repo（从自然语言生成完整仓库）：46.2，Qwen 3.6-35B 为 29.4，Gemma 4-31B 为 15.5；
• GPQA Diamond：89.2；HLE（no tools）：25.6；MCP-Atlas：70.2；ClawEval：72.5。

数字背后的结论很反直觉：稀疏激活不是"能力换效率"的零和博弈。官方博客解释，这份成绩单的底气来自训练阶段的端到端自我改进循环（Self-Improvement Loop）——模型自己生成训练任务、自己构造求解脚手架（Scaffold）、自己产出解决轨迹（Rollout），再由 GRPO 强化学习联合优化三个阶段，任务奖励由有效性、前沿难度与新颖性三者的乘积决定。换句话说，"省"下来的不是知识，只是单步的算术量。

3B 激活参数，为什么能换来更快的推理

要理解"更快"，必须区分推理的两个阶段，因为 MoE 在两个阶段吃到的是完全不同的红利。

Prefill（预填充）阶段是计算密集型。模型要并行处理整个 prompt 的 token，此时每 token 的 FLOPs 与激活参数成正比。激活参数从 35B 降到 3B，意味着每个 token 的乘加运算量下降约一个数量级，prompt 解析、首 token 延迟（TTFT）因此显著缩短。这也是 MoE 在长上下文、长 prompt 场景下最直观的提速来源。

Decode（解码）阶段是内存带宽密集型。自回归生成是逐 token 串行的，每一步都要把权重从显存搬运到计算单元。问题在于：无论激活多少专家，服务器仍必须把全部 35B 权重驻留在显存里（因为路由器无法预知下一个 token 会点将哪位专家），每一步的权重读取量取决于模型文件大小，而不是激活参数量。所以单流生成的峰值速度主要受显存带宽约束，MoE 并不能把单 token 生成速度放大十倍。

那 MoE 的"快"到底体现在哪？答案是并发与吞吐。激活参数少意味着单 token 计算量小，在批量请求场景下，计算不再是瓶颈，模型可以在同一带宽下支撑更高的并发，等效吞吐（TPS）随之抬升。社区在 Ornith-1.0 时代的 16GB 显存实测也印证了这个判断：RTX 4080 上 4-bit 量化后，Ornith 35B 约 18.2 tokens/s，同配置 Qwen 35B 约 16.8 tokens/s——单流只是小幅领先，真正的差距发生在服务端并发压测里。

打开仓库：GGUF 量化矩阵与多模态投影器

本仓库是 Ornith-1.5-35B-A3B 的 GGUF 分发镜像，共包含五个量化等级权重与一个多模态投影器，文件清单如下（大小为 LFS 指针中的真实字节数）：

这份清单本身就在讲述"总参数的成本"：即使每 token 只激活 3B 参数，BF16 全量权重依旧高达 71.1GB，与 README 中"约 70GB in bf16"的描述吻合。同时，mmproj 投影器的存在说明 35B 并不仅是编码模型，它同时具备视觉理解能力，配合 llama.cpp 的-mmproj参数即可启用多模态推理。README 给出了最轻量的启动方式：

llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144

量化与稀疏激活是两条完全正交的优化路径：稀疏激活削减的是计算量，量化压缩的是权重体积。两者叠加，才真正让 35B 级模型具备了消费级硬件的落地可能。

效率的账本：省下的算力，换来了什么代价

"偷工减料"从来不是免费的，稀疏激活的账本上写满了代价，也写满了意外之喜。

代价一：显存门槛由总参数决定，与 A3B 无关。这是最容易被忽略的一点。21.7GB 的 Q4_K_M 权重意味着 16GB 显存已无法直接容纳（社区在 Ornith-1.0 时代用更紧凑的 4-bit 格式实测 16GB 显存占用约 13.2GB，而 1.5 的 Q4_K_M 已膨胀到 21.7GB），24GB 级别显卡才是现实起点。

代价二：KV Cache 依然按注意力层全额计费。KV Cache 只由注意力层的层数、隐藏维度与上下文长度决定，与激活参数量无关。README 明确建议用 2×80GB GPU 来承载 bf16 版本并留出 256K 上下文的头部空间；若想进一步扩展到约 1M token，则需要启用 YaRN（rope_scaling，factor 4.0）——但官方也特别提醒，开源运行时的 YaRN 是静态实现的，对普通长度输入有轻微质量损耗，属于"按需启用"的开关。

代价三：单流速度不能兑现算力折扣。如前所述，decode 的带宽瓶颈让"快"主要沉淀在 prefill 与并发上。如果是单用户、单请求的本地交互场景，MoE 相比同代 dense 模型的体验提升幅度有限，切不可期待 10 倍加速。

意外之喜：能力不减反增。DeepSWE 从 0 分跃升至 22 分、NL2Repo 达到 46.2、Frontier-Bench v0.1 拿到 5.1——这些正是自我改进循环在稀疏架构上兑现的增量。它说明"省算力"与"提能力"并非互斥：当计算预算被稀疏激活压到 1/10 时，同样的训练算力可以换来更深的推理打磨。

部署决策：把 A3B 翻译成显存与吞吐

基于上述权衡，A3B 模型的选型逻辑可以总结为一张简明的决策表：

• 本地单机、个人交互：选 Q4_K_M 或 Q5_K_M，配合 llama.cpp / Ollama（ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF），把 35B 级知识与视觉能力装进 24GB 级显卡，接受单流速度受带宽约束的现实；
• 并发服务、agent 集群：MoE 的吞吐红利在此兑现，推荐 Q8_0 乃至 BF16，配合 vLLM（≥0.19.1）或 SGLang（≥0.5.9）部署 OpenAI 兼容端点，并开启 reasoning parser 与 tool-call parser——README 中的--tool-call-parser qwen3_xml、--reasoning-parser qwen3即可将模型的<think>链与<tool_call>块解析为标准字段；
• 超长上下文：在 vLLM/SGLang 中按需启用 YaRN 将窗口扩展到约 1M token，同时为 KV Cache 预留充足显存。

归根结底，"35B 总参数只激活 3B"是一次算力经济学上的精准调仓：把总参数视为知识的仓储成本，把激活参数视为每次推理的边际成本。Ornith-1.5-35B-A3B 证明了当仓储足够大、点将足够准时，模型可以用十分之一的算力，跑出超越 397B 级对手的成绩——而它付出的显存与带宽代价，也被量化和调度优化精准地兜住了。对每一个被显存预算卡住、却又不愿放弃大模型能力的开发者来说，这就是最值得抄的那份作业。