llama.cpp 开始实验性支持 MoE 专家扩容：不重训也能多激活专家

2026 年 9 月 6 日，llama.cpp 社区出现了一项值得关注的实验性改动：在不修改模型权重、不重新训练、也不做微调的前提下，让稀疏混合专家模型（MoE）在推理时激活更多专家。

这项改动由社区开发者 vagrillo 移植到 llama.cpp，核心思路是把原本固定的路由 Top-K 从“模型训练时决定的硬限制”，变成“运行时可以调节的计算预算”。目前该方案已经在 Qwen 3.6 35B A4B+ 上进行测试，并支持 llama.cpp 的不同计算后端。不过，它还不是 ggml-org/llama.cpp 主线中的稳定功能，不能把它理解成官方已经完成的 MoE 架构升级。

更准确地说，这是一次对 MoE 推理机制的工程实验：模型原本每个 token 只选择少数专家，现在可以在运行时把候选专家范围扩大，再对新增专家的贡献进行衰减。它可能带来更完整的知识组合和更强的复杂任务表现，但代价是更多矩阵计算、更高显存带宽压力，以及尚未充分验证的输出稳定性。

先说结论：这不是“白捡”的参数，而是用速度换计算覆盖面

MoE 是一种按输入动态选择部分神经网络参数的架构。 与每个 token 都经过全部参数的稠密模型不同，MoE 会通过路由器从多个专家网络中选出少数几个参与计算，因此可以在保留较大总参数量的同时控制单 token 的计算量。

例如，一个 MoE 模型可能拥有 32 个路由专家，但原生设置是每个 token 只激活其中 8 个。传统推理实现会对路由分数排序，取最高的 8 个专家，然后对这 8 个专家的输出加权求和。模型的总容量是 32 个专家，但一次实际计算只覆盖 8 个。

这项实验性实现做的事情，是允许运行时把激活数量从 8 扩展到更多，例如 16、24，甚至接近全部候选专家。开发者在 Reddit 的说明中将其概括为“8→x”：原生 Top-K 是 8，运行时可以扩展到 x 个专家。

但这里有一个关键区别：它不是简单地把 Top-K 改成更大的 K，然后让所有新增专家以同等权重参与。新增专家会根据路由分数和衰减策略降低影响，方案还支持自适应阈值与按层设置范围。也就是说，它更像是给模型增加一圈“低权重的辅助意见”，而不是强行把所有专家变成同等重要。

原生 Top-K 为什么可能不够用

Top-K 路由是 MoE 中决定计算稀疏度的机制，它规定每个 token 最终交给多少个专家处理。 Top-K 越小，单 token 计算量通常越低；Top-K 越大，模型能够综合的信息路径越多，但推理成本也随之增加。

固定 Top-K 的优势很明显：训练和推理行为一致，计算图容易优化，显存和吞吐量也更可控。但它也有局限。

第一，路由器的分数并不总是足够“尖锐”。某个 token 的第一名专家得分可能明显领先，另一个 token 的前 12 名专家却可能分布得很接近。统一采用 Top-8，意味着后者的第 9 至第 16 名专家会被直接丢弃，即使它们仍然包含有价值的信息。

第二，复杂任务往往横跨多个能力域。代码、数学、长上下文检索和多语言混合问题，可能同时需要语法、规划、事实召回和格式控制等不同专家的贡献。固定的少量专家可以减少计算，但也可能让路由结果过于激进。

第三，训练阶段确定的稀疏路由不一定等同于所有推理场景的最优路由。模型训练通常在固定的 Top-K 约束下学习，推理时如果面对分布外输入，允许更多候选专家参与，理论上可能提高鲁棒性。

当然，这些只是动机，不等于效果已经被证明。扩大激活专家数也可能把不相关甚至互相冲突的输出混在一起，造成回答变得啰嗦、格式不稳定，或者仅仅增加延迟而没有质量收益。

这项实现具体改变了什么

MoE 专家扩容是一种仅发生在推理阶段的路由策略：它不改变 GGUF 中保存的专家权重，而是改变运行时参与加权聚合的专家集合。

从目前公开的说明看，这个实现包含几个值得注意的组件：

• 原生 Top-K 之外继续选择专家：模型仍然先按照路由器分数找到原生专家，随后从剩余候选中加入更多专家。
• 自适应阈值：不完全依赖一个固定的扩容数量，而是根据路由分数或候选分布决定哪些额外专家值得保留。
• 影响力衰减：新增专家的权重会被压低，公开描述中提到从约 99% 到 50% 的线性或分层衰减区间。这里的百分比应理解为扩容专家相对于原始路由贡献的控制系数，而不是模型准确率提升 99% 或下降 50%。
• 按层控制：不同 Transformer 层可以采用不同的专家扩容策略。某些层维持原生 Top-K，另一些层增加专家数量。
• 后端无关：该方案目标是覆盖 llama.cpp 支持的不同后端，而不是只为 CUDA GPU 写一套特殊实现。

“按层控制”尤其重要。MoE 模型并不是每一层都以同样方式使用专家。有些层的路由分布比较集中，Top-8 已经足够；有些层的候选分数更平坦，增加专家可能更有价值。全模型统一从 8 扩到 16，容易把成本浪费在不需要扩容的层上；分层策略则允许用户把计算预算投向更敏感的部分。

目前 llama.cpp 主线的相关功能请求也在讨论“per-layer active expert count”，即为每一层设置独立的 active expert count。讨论中的方向包括通过命令行参数提供层范围与专家数量，或从 GGUF 元数据读取逐层配置。需要注意的是，功能请求不代表已经合并，相关参数名称和数据结构仍可能变化。

与传统 MoE 推理的差别

| 项目 | 原生 MoE 推理 | 专家扩容实验方案 | |---|---|---| | 专家数量 | 按模型配置固定 | 运行时可高于原生 Top-K | | 是否修改权重 | 不修改 | 不修改 | | 是否需要重训 | 不需要 | 不需要 | | 路由方式 | 选择最高分 Top-K | 原生专家加额外候选专家 | | 新增专家权重 | 不存在 | 通过阈值与衰减降低影响 | | 层间策略 | 通常全局一致 | 可按层设置扩容范围 | | 计算成本 | 较低且稳定 | 随激活专家数增加 | | 适合场景 | 日常低延迟推理 | 复杂问题、质量优先、离线实验 | | 稳定性 | 与训练设定一致 | 需要额外评估 |

它也不同于把 MoE 模型转换成稀疏模型的后训练方法。后训练 MoE 通常要重新组织权重，并通过持续预训练或微调让专家形成稳定分工；本次 llama.cpp 改动没有训练过程，模型本身并不知道推理阶段会额外引入专家。因此，扩容后的收益更依赖原有路由器和专家之间已经存在的潜在互补关系。

对 Qwen 3.6 35B A4B+ 的测试意味着什么

Qwen 3.6 35B A4B+ 是目前该实验分支公开提到的测试对象，名称中的 35B 与 A4B 通常分别指总参数规模约 35B、单 token 激活参数规模约 4B。 这里应以模型官方架构和具体 GGUF 文件元数据为准，不要把 A4B 直接等同于每一层的专家数量或实际显存占用。

如果一个模型原生只激活少量专家，那么它的主要优势是“总参数很大，但每次只算一小部分”。专家扩容会削弱这种优势：激活更多专家意味着更多专家权重需要被读取，GPU 上会增加矩阵乘法和显存带宽压力；CPU 推理则可能受到缓存命中率和线程调度影响。

不过，MoE 的瓶颈并不总是 FLOPs。对于小批量、单用户交互式生成，专家权重搬运和路由调度往往比理论计算量更敏感。新增专家如果分散在不同内存区域，实际延迟可能比“激活专家数增加一倍”更糟。相反，在批量较大、专家调用能够合并时，额外计算的边际成本可能没有想象中高。

因此，不能只看模型的 4-bit 文件大小或理论激活参数量。真正需要测量的是：

1. 首 token 延迟是否增加；
2. 生成阶段 tokens/s 下降多少；
3. GPU 显存峰值和显存带宽占用如何变化；
4. 长上下文下的路由和 KV Cache 是否成为新的瓶颈；
5. 质量是否在固定成本下得到改善。

截至目前，公开材料没有给出覆盖 GSM8K、MMLU、HumanEval、长上下文和多语言任务的系统性对比数据，也没有证明“扩容一定提升准确率”。所以更合理的表述是：它提供了一个新的推理调参维度，而不是已经确认的质量升级。

如何尝试：先编译实验分支，再确认实际参数

llama.cpp 的实验性功能通常会随着分支更新而改变，使用者应以对应仓库中的 docs/moe-expansion.md 和命令行帮助为准。 下面只给出获取和编译思路，不把尚未稳定的参数名称写死。

git clone https://github.com/vagrillo/llama.cpp.git
cd llama.cpp
git branch -a
git log --oneline -10

# CUDA 用户示例；其他后端按本机环境调整
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# 先查看该分支实际暴露的专家相关参数
./build/bin/llama-cli --help | grep -i -E "expert|moe|layer"

如果仓库已经切换到包含扩容功能的提交，再按照文档中给出的参数设置原生 Top-K 以上的激活数量、阈值、衰减区间和层范围。不要直接把主线版本的 llama-cli 与实验分支的参数混用：二进制、GGML 图构建逻辑和模型架构支持需要保持一致。

建议从最保守的配置开始：

• 只在少数中间层增加专家；
• 扩容数量先从原生 Top-K 增加 25% 到 50%；
• 保留自适应阈值，不要一开始把所有候选专家都纳入；
• 使用固定 prompt、固定上下文长度和固定随机种子进行对比；
• 同时记录速度、显存与输出质量，而不是只看回答是否“感觉更聪明”。

一个实用的测试矩阵可以这样设计：原生 Top-K、扩容 1.5 倍、扩容 2 倍，以及只对指定层扩容四组配置。每组至少运行代码生成、数学推理、事实问答、长文总结和中英混合五类任务。对于每个任务，记录首 token 延迟、平均生成速度、输出长度、格式遵循率和人工评分。

什么时候值得打开

专家扩容更适合质量优先、吞吐量要求不高的离线推理，而不适合作为默认的交互式配置。

适合尝试的场景包括：

• 对复杂代码进行多轮分析，希望减少单一路由造成的信息遗漏；
• 运行批量评测，愿意牺牲生成速度换取更高的候选专家覆盖；
• 在本地调试 MoE 路由，观察不同层和不同 token 的专家选择；
• 研究模型在分布外问题上的鲁棒性；
• 有足够显存和带宽，且生成延迟不是第一优先级。

不适合直接打开的场景包括：

• 单卡低显存设备上的长上下文对话；
• 对首 token 延迟极其敏感的实时应用；
• 需要稳定吞吐量的批处理服务；
• 没有基准集、无法判断质量变化的生产环境；
• 依赖严格 JSON、代码格式或工具调用格式的任务。

这里还要特别注意专家负载不均衡。MoE 本身就可能出现热门专家被频繁调用的问题，扩容并不自动解决负载倾斜；它甚至可能因为更多候选专家参与，让内存访问和调度更加复杂。如果不同层的扩容比例差异过大，也可能导致计算图优化空间下降。

它真正有价值的地方：把“模型能力”与“推理预算”解耦

这项实验最有意思的地方，不是简单增加一个 K，而是尝试把 MoE 的推理成本从固定常数变成可调预算。

动态专家路由是根据输入难度和路由分布，为不同 token 分配不同计算量的机制。 简单 token 可以继续使用原生少量专家，路由分数接近、任务结构复杂的 token 则允许更多专家参与。若这一方向最终成熟，MoE 模型就不再只有“低成本模式”和“高成本换模型”两种选择，而可能拥有一条连续的质量—延迟曲线。

这与当前 MoE 的发展趋势是吻合的。Mixtral 采用较少的大专家和 Top-2 路由，部署逻辑相对直接；DeepSeek、Qwen 等路线更强调大量细粒度专家、共享专家和更灵活的路由空间。模型训练阶段已经在扩大专家池，推理阶段进一步探索激活预算，属于同一条技术路线的延伸。

但它能否成为通用方案，还取决于三个问题：

1. 收益是否可重复：不同模型、不同量化格式、不同任务上，额外专家是否稳定带来收益；
2. 收益是否值得成本：如果速度下降 50%，准确率只提高 1%，大多数在线用户不会买账；
3. 路由是否可解释和可控制：用户需要知道哪些层扩容、哪些 token 触发扩容，以及新增专家到底贡献了什么。

目前最稳妥的判断是：llama.cpp 的这次移植值得开发者关注，但不值得普通用户立刻替换稳定版本。它更像是给本地推理系统加了一根“计算预算旋钮”，能让研究者验证“更多专家是否等于更好的推理”，却还没有提供足够的公开基准来证明这根旋钮应该拧到哪里。

对于深度用户，推荐把它当作一个可复现实验：固定模型、固定量化、固定提示词，分别比较原生 Top-K 与扩容配置，再用真实任务测量延迟和质量。只有当新增专家在目标任务上带来的收益超过额外计算成本时，专家扩容才真正有部署价值。