专家混合模型的端侧部署

一句话定义

专家混合（Mixture of Experts，MoE） 把每层里的前馈网络拆成多个「专家」，再加一个路由器，每个 token 只被送进其中少数几个专家计算。

端侧部署指把这套结构放到门店设备、边缘盒子或区域服务器上跑，而不是放在云端机房。

它解决什么问题

MoE 有两个必须分开看的数字：

	总参数	激活参数
含义	所有权重加起来	单个 token 实际参与计算的部分
决定什么	要占多少存储、要读多少字节	要做多少次乘加
例子	Qwen3-235B-A22B 约 2350 亿	每个 token 约 220 亿

这就是它在端侧有吸引力的原因：单 token 的计算量接近一个 20B 级稠密模型，效果却按 235B 的容量来。对算力紧张、又想要「大一点模型」的设备，账面上很划算。

代价在另一侧。路由器每次只挑几个专家，但所有专家都得有地方待着。稠密模型是「用多少算多少、存多少」，MoE 是「算一小部分、存全部」。

关键做法

在消费级硬件上跑这类模型，工程重心基本都在「怎么把专家搬来搬去还不让人等」。开源项目 FreeToken 的做法比较典型，可以当作一套参考：

分层放置：热专家留在显存，冷专家放主机内存甚至本地固态盘，按需换入。它把 GPU、CPU、主机内存和互连当成一个统一平台来调度。
专家缓存：按全局 LRU 之类的策略缓存专家。命中率直接决定速度，而命中率取决于请求有多集中——同类任务反复问，命中就高；问法发散，就一直在换入。
预取与双缓冲：算当前层的时候，把下一层要用的专家提前搬进来，用计算掩盖传输。FreeToken 用的是整层双缓冲的预填充流式加载。
按带宽分配 CPU 与 GPU：不是所有层都值得上 GPU。带宽紧张时，让一部分专家在 CPU 上算反而整体更快（项目里称为带宽自适应的 CPU–GPU 协同执行）。
运行时切分显存：专家缓存和 KV 缓存抢同一块显存，要能动态调整比例，而不是重启进程、重新加载权重。
更低的权重量化格式：MXFP4、NVFP4、FP8 这类格式把专家体积再压一档，是端侧能装下的前提之一。

用不上的时候

存储放不下。 一个 235B 的 MoE，16 位权重约 470GB，压到 4 位仍在 120GB 上下——这是机房四卡机器的量级，不是门店盒子的量级。端侧要谈 MoE，先看总参数，再看设备有多少内存和硬盘。
请求很发散。 每次问的都不同，专家缓存命中率低，大部分时间花在换入上，速度可能不如一个更小的稠密模型。
只有一路请求。 单请求时 GPU 的并行度用不满，MoE 的稀疏计算优势发挥不出来；这类场景里，稠密小模型往往更稳。
并发很高。 多路并发能提高专家复用率，但同时放大显存和带宽压力，需要按真实并发量实测，不能按单路数据乘系数。

常见误区

「激活参数小，所以能塞进门店盒子。」 算力按激活参数算，存储按总参数算。这两笔账经常被混成一句「这个模型只有 22B」。
「MoE 一定比同激活量的稠密模型快。」 单请求、冷缓存时，速度由内存带宽和换入策略决定，和稠密模型的比较要放在同一台设备、同一批问题上做。
「参数量就是效果。」 路由是否训练得好、专家是否被充分利用，决定了这些参数有没有真的起作用。

参考

GitHub 项目 FlashML-org/FreeToken，边缘原生的 MoE 服务引擎，宣称可在消费级显卡上运行 290B 级别的开放权重 MoE 模型；对应论文 arXiv:2608.16157，FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution。

235B 模型 16 位约 470GB、4 位约 120GB 这组数字，来自一篇公开的微调工程记录（blog.vertexcover.io，2026-10-16）。