简介：混合专家稀疏大模型正成为端侧推理的重要方向。本文以一类35B总参数、3B激活参数的MoE模型为例，系统解释其定义、工作原理、显存与内存协同机制、CPU-GPU卸载策略、量化上下文缓存等关键概念，帮助开发者在有限硬件上实现可用推理速度，并理解这类模型与稠密模型的本质区别。
近年来，大语言模型在参数规模与推理能力上持续提升，但完整加载并运行一个数百亿参数的稠密模型，对普通开发者的硬件条件提出了极高要求。于是，混合专家（Mixture of Experts，MoE）架构重新回到主流视野。这类模型虽然拥有很大的“总参数规模”，但每次推理只激活其中一小部分参数，从而显著降低单次推理的计算量与显存带宽需求。
本文讨论的对象，可以定义为一类“总参数量约35B、每次推理激活参数量约3B的混合专家稀疏大模型”。这里的“35B-A3B”并不是一个标准型号名称，而是一种结构特征描述：模型总参数约350亿，但在一次前向计算中，真正参与运算的激活参数约30亿。其余专家网络处于“待命”状态，不会全部被加载进显存，也不参与当次计算。
这类模型解决的问题非常明确：如何在显存容量有限、内存带宽有限的消费级硬件上，获得接近更大规模稠密模型的推理效果与可用速度。换句话说，它用“大而稀疏”的总容量换取知识覆盖度，用“小而激活”的计算路径换取推理效率。
从技术视角看，它属于稀疏激活模型；从业务视角看，它适合本地化推理、低延迟交互和隐私敏感场景；从使用视角看，它可以被看作一种“类27B稠密模型能力、但计算代价更接近3B模型”的折中方案。
传统稠密模型面临一个核心矛盾：参数规模越大，表达能力越强，但推理成本也几乎线性上升。30B以上稠密模型在消费级硬件上往往难以流畅运行，而3B级别小模型虽然快，但知识与推理能力明显不足。
混合专家架构尝试在两者之间取得平衡。模型内部包含多个专家网络，但每次推理只由路由器选择少量专家参与计算。这样，模型可以拥有非常大的总参数规模，用来存储更丰富的知识与模式，同时把单次推理的激活参数量控制在一个较小范围。
在实际部署中，这种设计带来两个直接收益：
这也解释了为什么有开发者会在8GB显存、16GB内存的设备上尝试运行35B总参数的模型：因为真正“活跃”的参数只有3B级别，关键在于如何调度那些“不活跃”的参数。
要理解这类模型如何工作，需要先拆解其关键模块。
路由是MoE模型的核心。每次输入Token进入模型后，会经过一个路由网络，该网络为当前Token分配一个或多个专家。路由通常输出一组专家索引及其对应权重。这意味着不同Token可能激活不同专家，甚至同一个Token的不同层也可能选择不同专家。
在工程上，路由网络本身参数很少，但它的选择逻辑决定了哪些专家被加载到高速存储中。因此在端侧部署时，路由相关的权重通常会优先放入GPU显存，以确保路由判断的低延迟。
有些MoE模型会设置“共享专家”，即无论路由如何选择，都会有少量专家始终参与计算。共享专家用于捕捉跨领域的通用模式或基础语言能力。由于它们每次都被激活，部署时也会优先放入GPU显存，与路由参数一起构成“常驻显存部分”。
其余大量专家属于“稀疏专家”，它们只会在被路由选中时才参与计算。这部分参数规模最大，但单次使用率很低。在端侧部署中，稀疏专家不需要常驻显存，可以按需加载，甚至直接从磁盘读取。
这样，整个模型被天然地分成三类：路由参数、共享专家、稀疏专家。三者的访问频率依次递减，正好对应GPU显存、内存、磁盘三级存储的访问速度与容量特性。
当用户输入一段文本后，模型按层进行前向计算。每一层中，输入先经过注意力模块，然后进入MoE模块。MoE模块的执行过程可以概括为以下步骤：
在上述过程中，只有被选中的专家参数被实际读取并参与矩阵乘法。对于端侧部署，系统会尽量把路由参数和共享专家常驻在GPU显存中，而稀疏专家则按需从内存或磁盘加载。
“CPU-MoE卸载”正是这一思路的工程实现。它并不是把整个模型放入内存，而是将部分层或部分专家卸载到CPU内存，GPU只保留最常访问的部分。当GPU需要某个稀疏专家时，数据从内存传输到显存；如果该专家不在内存中，则从磁盘读取到内存，再传输到显存。
因此，真正制约生成速度的往往不是GPU算力，而是内存带宽与磁盘I/O。开发者观察到，在一次约23000 token上下文的4轮对话中，16 token/s的速度“勉强可用”，这恰好反映了该调度机制下的典型表现：计算量已不是瓶颈，参数搬运与上下文缓存才是主要开销。
要在有限硬件上跑通这类模型，需要理解三个关键配置维度。
GPU卸载是指将多少层模型参数直接放入显存。原则是“能放多少放多少”，因为GPU访问速度远高于内存。对于MoE模型，应优先将路由参数和共享专家放入GPU，然后再尽可能多地放入部分稀疏专家。实际操作中，通常将GPU卸载层数设置为很高的值，让GPU尽量承载常驻参数。
CPU卸载决定多少层参数从内存中调度。由于稀疏专家数量庞大，很难全部放入内存，因此需要设置一个合理的CPU卸载层数。该值不是越大越好，而是需要根据实际显存占用进行调整。目标是让显存占用保持在80%左右，剩余空间用于上下文缓存。
一位开发者在8GB显存设备上反复测试后，发现将CPU卸载到33层时效果最佳。此时观察到内存占用仅约3GB，显存占用约7.3GB。这说明真正进入内存的参数并不多，大部分稀疏专家仍停留在磁盘上，仅在需要时被读取。这也说明，部署这类模型的瓶颈是内存带宽，而非绝对内存容量。
上下文长度直接影响显存占用。长上下文场景下，键值缓存会迅速膨胀。通过将键值缓存量化为较低比特表示，例如Q4级别，可以大幅降低上下文缓存体积，从而为模型参数腾出更多显存空间，也间接提升可支持的上下文长度。
这三者需要协同调整：GPU卸载决定常驻显存参数规模，CPU卸载决定内存中转策略，上下文量化决定缓存占用。它们共同影响最终可用性与生成速度。
混合专家稀疏模型在端侧部署中适合以下几类场景：
相比之下，需要极致并发吞吐或超大规模批处理的场景，仍更适合使用云端集中式推理资源。
MoE模型与稠密模型：稠密模型每次推理所有参数都参与计算；MoE模型总参数大，但激活参数少。因此MoE在同等显存下可以承载更多知识，但部署复杂度更高，对调度策略更敏感。
CPU卸载与模型量化：量化通过降低参数精度减少模型体积与计算量；CPU卸载则通过分层调度决定参数放在哪里。两者可以叠加使用，例如参数用低比特量化，同时将稀疏专家卸载到内存或磁盘。
上下文量化与参数量化：上下文量化针对的是键值缓存，参数量化针对的是模型权重。两者目标不同，但都服务于降低显存占用。
CPU-MoE卸载与单卡全量加载：单卡全量加载要求显存足够大，能把模型完整放入GPU。CPU-MoE卸载则是针对显存不足场景的折中方案，牺牲一定速度换取可运行性。
部署这类模型时，需要关注以下几点：
内存带宽比内存容量更关键。由于稀疏专家需要频繁从内存传输到显存，内存频率对生成速度影响显著。双通道DDR4与DDR5在高频下的表现差异可能较明显。
显存预留要合理。如果GPU卸载过满，上下文缓存空间会被压缩，导致可支持的最大序列长度下降。建议留出约20%显存用于缓存动态数据。
上下文量化有精度损失风险。量化键值缓存虽能节省空间，但可能在某些长文本检索或细节敏感任务上产生轻微影响。实际使用中需要根据任务类型权衡。
磁盘I/O会成为隐藏瓶颈。当某些稀疏专家长时间未激活、已被换出内存时，再次调用会产生磁盘读取延迟。如果模型被频繁切换主题或上下文跨度大，可能出现间歇性卡顿。
启动参数需要按硬件实测调整。没有一套参数能适配所有设备。合理做法是固定GPU卸载到最大，然后逐步增加CPU卸载层数，观察显存占用与生成速度变化，找到平衡点。
混合专家稀疏大模型，特别是“35B总参数、3B激活参数”这一结构类型，代表了在有限硬件条件下获得较强推理能力的可行路径。它的核心思想是用稀疏激活降低单次计算代价，用路由调度管理大规模专家参数，用多级存储协同解决显存不足问题。
从定义上看，它既不是简单的大模型，也不是单纯的小模型，而是一套“大容量知识库 + 小激活计算路径 + 智能参数调度”的组合。理解这一本质，就能理解为什么它可以在8GB显存、16GB内存的设备上跑起来，也能理解为什么内存带宽、CPU卸载层数与上下文量化会成为部署成败的关键变量。
对于开发者而言，掌握这类模型的部署与调优方法，意味着可以在消费级硬件上获得更接近云端大模型的使用体验，同时保留数据本地化、低延迟和离线可用的优势。随着模型压缩、动态调度和硬件带宽的不断演进，混合专家稀疏模型有望在端侧推理中扮演更加重要的角色。