Mixture-of-Experts（MoE）模型通过只激活部分专家网络，降低了单次推理的计算量，但它并没有自动解决消费级硬件上的内存和调度问题：完整模型权重仍可能无法同时驻留在显存中，专家切换还会带来数据搬运和执行等待。
UC Berkeley 与 MIT 的研究者推出了开源推理引擎 FreeToken，核心思路是动态协同执行（dynamic co-execution）和更高效的权重管理。它关注的不是简单地把模型缩小，而是让计算、权重加载和硬件资源在解码过程中更紧密地配合，从而提高 MoE 模型在边缘设备和消费级硬件上的实用性。
MoE 推理的瓶颈不只在 FLOPs
MoE 模型通常包含多个专家（expert），路由器会为每个 token 选择一个或多个专家。理论上，一个 token 不需要经过全部专家，因此计算量可以低于同等总参数规模的稠密模型。
但在本地推理时，系统仍然需要面对几个现实问题：
- 专家权重的总容量可能超过 GPU 显存。
- 不同 token 选择的专家不同，执行顺序具有动态性。
- 频繁加载和卸载权重会消耗 PCIe 或统一内存带宽。
- GPU、CPU 与内存之间可能出现空转，计算单元并没有持续工作。
因此，MoE 的实际速度不能只用“每个 token 激活了多少参数”来判断。权重是否已经在合适的位置、下一步专家能否及时准备好，以及不同硬件是否能够并行工作，都会影响端到端解码延迟。
FreeToken 的关键方向
FreeToken 将推理过程看成一个动态资源调度问题。系统需要根据当前 token 的专家需求、权重状态和可用硬件资源，决定哪些任务在 GPU 上执行，哪些任务由其他处理单元协同完成，以及什么时候移动专家权重。
这种动态协同执行有两个重要含义。
第一，调度不再只围绕固定的静态执行图展开。每一步解码产生的新 token 可能触发不同的专家组合，调度器需要根据运行时状态做决定。
第二，权重管理成为性能优化的一等公民。并非所有专家都必须同时驻留在显存中，但系统也不能让每次专家调用都变成一次同步的完整权重传输。合理的缓存、预取和淘汰策略，能够减少等待，并提升有限显存的利用率。
这类设计尤其适合自托管推理系统：用户可能只有一张消费级显卡，或者需要在边缘设备上运行推理模型，却不希望每次请求都依赖远程 API。
用一个可运行的小例子理解调度
下面的 Python 示例不是 FreeToken 的 API，而是一个可运行的概念模型，用来演示“专家权重缓存 + 动态调度”的基本思路。它假设 GPU 只能缓存两个专家；如果请求需要的专家不在缓存中，调度器会产生一次加载事件，并淘汰最久未使用的专家。
将代码保存为 toy_scheduler.py 后直接运行即可：
from collections import OrderedDict
class ExpertScheduler:
def __init__(self, capacity=2):
self.capacity = capacity
self.cache = OrderedDict()
self.loads = 0
def ensure_loaded(self, expert):
if expert in self.cache:
self.cache.move_to_end(expert)
return False
if len(self.cache) >= self.capacity:
evicted, _ = self.cache.popitem(last=False)
print(f"evict {evicted}")
self.cache[expert] = True
self.loads += 1
print(f"load {expert}")
return True
def dispatch(self, token_id, experts):
misses = sum(self.ensure_loaded(expert) for expert in experts)
print(
f"token={token_id} experts={experts} "
f"cache={list(self.cache)} misses={misses}"
)
if __name__ == "__main__":
scheduler = ExpertScheduler(capacity=2)
routed_tokens = [
["expert-0", "expert-1"],
["expert-1", "expert-2"],
["expert-1", "expert-2"],
["expert-0", "expert-2"],
]
for token_id, experts in enumerate(routed_tokens):
scheduler.dispatch(token_id, experts)
print(f"total weight loads: {scheduler.loads}")
这个模型非常简化，但能说明几个工程决策：
- 热门专家应该尽量保留在快速存储或显存中。
- 调度器需要区分“专家未加载”和“专家已加载但暂时不可执行”。
- 仅使用 LRU 缓存并不一定足够，实际系统还可以结合路由预测进行预取。
- 评估性能时，应同时统计 token 解码速度、权重加载次数、显存占用和尾延迟。
如何评估本地 MoE 推理方案
如果准备在自己的硬件上尝试 FreeToken 或类似引擎，可以按以下维度建立基线：
# 示例：记录一次本地推理实验的基本环境信息
python --version
nvidia-smi
free -h
# 运行你的推理入口；具体参数取决于模型和引擎
python run_inference.py \
--model /path/to/moe-model \
--prompt "Explain how dynamic expert scheduling reduces memory pressure." \
--max-new-tokens 128 \
--warmup 3 \
--repeat 10
这里的 run_inference.py 和参数名是假设的实验入口，需要替换成实际引擎提供的命令。建议至少记录：
- 首 token 延迟（TTFT）。
- 稳态 token/s。
- GPU 显存峰值和系统内存峰值。
- 权重加载或专家切换次数。
- 长上下文和连续请求下的尾延迟。
短提示词下的结果可能掩盖权重管理成本；更可靠的测试应覆盖不同专家路由模式、不同上下文长度以及连续多轮解码。
采用时需要留意的边界
动态调度会增加运行时控制逻辑，也可能引入额外的数据移动和决策开销。若模型很小、所有专家都能稳定驻留显存，复杂调度未必带来收益。相反，当模型权重明显超过显存、专家访问具有局部性，或者系统需要在 GPU 与 CPU 之间协同执行时，这种方法更值得评估。
FreeToken 的价值也不应只看峰值速度。对于自托管推理，能否在有限硬件上稳定运行、是否容易观察权重交换、请求并发增加后是否出现严重抖动，同样决定了系统是否可用。
落地检查清单
- 先确认模型的专家路由方式和权重规模。
- 测量显存不足时的实际权重搬运成本。
- 区分冷启动、单请求和连续请求的性能。
- 为 GPU、CPU 和内存分别采集利用率。
- 评估缓存策略对吞吐、延迟和稳定性的影响。
- 不要只比较激活参数量，要比较完整的端到端解码表现。
FreeToken 所代表的方向很明确：前沿 MoE 模型能否进入消费级和边缘硬件，关键不只是模型结构本身，也取决于推理引擎能否把动态路由、权重管理和异构硬件协同起来。对于希望运行本地推理系统的开发者，这为突破显存容量限制提供了一个值得验证的工程路径。