FreeToken: 高效边缘原生 MoE 服务(24分钟阅读)

TLDR AI 论文

摘要

FreeToken 是一个边缘原生的 Mixture of Experts 服务系统,通过自适应管理异构边缘设备的资源,高效地在消费级硬件上运行大型开源权重模型。

FreeToken 持续重新映射专家、模型状态、CPU/GPU 工作以及智能体状态复用,以适配个人机器上实际可用的带宽和内存。作者报告支持超过 20 种 MoE 模型,从在 8GB 笔记本 GPU 上运行的 35B 模型到在一台工作站 GPU 上运行的 753B GLM 模型。
查看原文
查看缓存全文

缓存时间: 2026/08/19 15:36

# FreeToken:面向带宽自适应执行的高效边缘原生MoE服务
来源:https://arxiv.org/html/2608.16157
Xiaoze Fan, Melissa Pan, Haocheng Xi, Zhe Wang, Shanlin Sun, Kurt Keutzer, Song Han, Matei Zaharia, Chenfeng Xu†\\dagger, Ion Stoica†\\dagger
隶属机构:\###### 摘要

前沿开源权重模型日益普及,但其服务部署仍主要依赖数据中心基础设施。我们提出FreeToken——一个边缘原生的混合专家(MoE)服务系统,它将个人设备视为一个统一的弹性推理平台,而非仅是一个小型GPU。FreeToken围绕本地AI的两大现实情况协同设计完整的服务栈,包括模型布局与加载、专家驻留策略、CPU-GPU协同执行、智能体状态复用以及运行时内存管理:其一,智能体工作负载的执行模式持续变化;其二,边缘硬件暴露的异构资源平衡因设备而异。FreeToken不依赖固定卸载策略,而是持续将计算和模型状态映射到实际可用的资源上。该系统支持超过20种MoE模型及真实编码与工具使用智能体,覆盖从8GB笔记本GPU到单个工作站GPU的多种硬件。更重要的是,它扩展了这些设备实际可服务的模型规模:从笔记本上的35B模型,到游戏台式机上的284B模型,再到单个工作站GPU上的753B GLM-5.2。FreeToken将开源权重转化为可部署的本地软件,使用户已拥有的设备成为运行前沿规模智能的实用平台。

## 1引言

近期发布的开源权重模型,如Kimi-K3(Kimi团队,2026年)【参考文献17】、GLM-5.2(Z.ai,2026年)【参考文献45】和DeepSeek-V4-Flash-0731(DeepSeek-AI,2026年)【参考文献4】,正在迅速缩小与最强大闭源系统的能力差距。然而,发布模型参数仅决定了谁能获取模型,而非谁能负担得起运行它。前沿开源模型仍依赖于稀缺的数据中心级GPU集群,其成本可能高达数百万美元;尽管托管API可能比同类闭源产品更便宜,但长期使用仍然昂贵。随着智能体应用急剧增加推理需求【Presenc AI Research,2026年【参考文献29】;Anthropic,2026年【参考文献2】】,这种成本对个人用户和小团队变得尤为沉重。因此,开源与闭源模型之间的能力差距缩小速度,远快于那些能获取前沿模型与能大规模使用它们的人之间的可及性差距。

乍看之下,这种可及性差距似乎是硬件问题。但事实上,已有超过一亿台消费级设备内置独立GPU,涵盖游戏台式机、工作站和高性能笔记本。仅Steam平台就报告超过2亿月活用户,其中约72%的受访系统配备NVIDIA独立GPU(Simon Carless报道于gHacks(2026年)【参考文献33】;Valve公司,2026年【参考文献37】)。这些设备共同构成了一个庞大但未被充分利用的算力资源池。因此,缺失的并非硬件本身,而是一个能将每台异构消费设备视为统一推理平台,并自动将其GPU、CPU、内存和互连资源映射到可高效运行的最强模型配置的服务系统。

MoE架构为在边缘设备上服务前沿规模的开源权重模型开辟了新路径。一个MoE层包含数百个专家,但每个令牌仅通过其中一小部分子集进行路由。例如,DeepSeek-V4-Flash在其43层中,每层激活256个路由专家中的6个,因此其284B参数中仅有13B参与单个令牌的处理。在部署精度下,这一活跃参数集可容纳在RTX 5090的32GB显存容量内。然而,稀疏性减少了每令牌计算量,却并未按比例减少完整专家池所需的内存。完整模型可能仍远超GPU内存容量,迫使非活跃专家驻留在主机内存或二级存储中,并在需要时进入执行路径。因此,MoE为个人硬件上的前沿推理带来了机遇与核心系统挑战:稀疏激活使计算可行,而完整专家池则使高效服务变得困难。

图1:FreeToken在消费级硬件上以交互速度服务处于成本-能力帕累托前沿的模型。(a)代表性托管模型的混合API列表价格(9:1输入:输出比例,遵循基于真实编码智能体轨迹测量的令牌经济学【Zhu等人,2026年【参考文献49】】)与代码竞技场Elo评分(LMArena,2026年【参考文献22】)对比。蓝色方块标记FreeToken服务的模型,并标注提供服务的消费级GPU类别;从DeepSeek-V4-Flash到GLM-5.2的前沿部分正是此集合。Kimi-K3发布开源权重但超出消费级内存(594GB);Qwen3.5-35B代表其后续版本Qwen3.6-35B,后者尚无竞技场评分。(b)在真实智能体工作负载上,每个硬件层级所能承载的最强模型的平均解码吞吐量(前两级为编码智能体,第三级为数学智能体),并与积极维护的边缘引擎对比。虚线表示生产轨迹中Codex的中位解码速度(33 tok/s【Zhu等人,2026年【参考文献49】】);×标记表示引擎无法服务的配置。一个日益增长的服务系统生态系统已开始将强大的开源权重模型引入个人硬件,包括llama.cpp(Gerganov等人,2023年【参考文献11】)、KTransformers(KVCache-AI团队,2025年【参考文献18】)和Ollama(Ollama团队,2023年【参考文献25】)。然而,现有系统仅解决了边缘MoE服务问题的片段,并在三个维度上存在不足,阻碍了边缘服务达到其理论容量:

- •首先,预填充基本破坏了MoE的工作集稀疏性。尽管每个令牌仅激活少数专家,但长提示中的路由并集通常覆盖每层的大多数专家,使专家工作集有效变为密集。这带来了计算和内存搬运挑战,因为超出VRAM的专家必须反复从主机内存流式传输。该问题在智能体工具调用工作负载中尤为严重,因为长且持续增长的上下文会触发频繁预填充;然而,现有边缘服务系统几乎不支持隐藏专家搬运或跨回合复用循环状态。
- •其次,解码呈现相反情形:每个令牌仅激活稀疏专家子集,但缓存未命中要求专家被反复加载、驱逐或从主机内存执行。现有系统缺乏服务这些未命中项的合理策略。静态放置无法跟随令牌级路由变化,而预测和预取虽可能降低未命中率,但未决定不可避免的未命中项如何在PCIe传输、GPU执行和直接CPU执行之间分配。
- •第三,边缘资源的多样性和可变性放大了上述问题。与数据中心部署不同,消费级硬件在GPU容量、PCIe带宽、主机内存带宽、CPU能力和可用VRAM方面差异巨大。这些资源也极少专用于模型服务:用户可能同时运行浏览器、游戏和其他应用,导致可用内存和计算预算随时间波动。因此,没有单一的静态放置或调度策略能在不同设备、工作负载阶段和变化的运行条件下均表现良好。

我们提出FreeToken,一个基于两项执行原则和一项弹性资源管理策略构建的系统。(1)带宽自适应执行将有限的边缘带宽从固定瓶颈转变为运行时调度信号。在预填充期间,FreeToken通过双缓冲将专家搬运与计算重叠:当GPU评估当前层时,下一层的专家通过PCIe流式传输。解码需要更细粒度的分配,因为PCIe传输和直接CPU专家执行共享相同的主机内存带宽。因此,FreeToken采用q⋆策略,在GPU缓存填充和直接CPU执行之间分配每一步的缓存未命中项(第3.2节),以匹配部署设备可持续支持的带宽。(2)语义感知缓存在稀缺内存中决定保留什么。跨智能体回合中,智能体框架在语义边界(如思考段和工具调用)编辑上下文。在预填充期间,FreeToken在这些边界处锚定循环状态检查点,以便编辑后仅重新计算新的后缀。在解码期间,相邻令牌常路由到重叠专家。FreeToken通过共享LRU专家缓存捕获这种令牌间路由局部性,允许大多数路由访问命中VRAM,仅将剩余未命中项交给q⋆策略处理。(3)弹性边缘资源管理使FreeToken适应个人硬件变化的内存条件。在调度器安全点,FreeToken可在修订的内存预算下动态调整和重建GPU专家缓存,无需重启引擎或重新加载主机驻留的专家池。FreeToken进一步通过将专家直接加载到其最终主机布局,再固定已填充内存,来减少启动延迟。

FreeToken支持超过20种MoE模型,覆盖广泛的消费级和工作站级硬件。在实验部分,我们主要评估FreeToken在三个代表性前沿模型上的表现,包括Qwen3.6-35B-A3B、DeepSeek-V4-Flash和GLM-5.2;六台设备,从8GB RTX 4060笔记本到单台RTX PRO 6000工作站;使用四种真实智能体工作负载;并与llama.cpp、Ollama、KTransformers和MoE-Infinity对比。具体而言,在RTX 5090上,FreeToken在Qwen3.6-35B-A3B上保持77–83 tok/s,在DeepSeek-V4-Flash上保持22–25 tok/s,在所有工作负载上实现了比最先进边缘服务1.5–2.3倍更高的解码吞吐量。随着工作负载日益智能化,其性能也保持显著稳定:解码速率保持在单回合设置的12%以内,而竞争系统则大幅下降。优势在尾延迟中更为明显。FreeToken在所有工作负载中将最坏情况TTFT保持在44秒以下,而每个基线在至少一种设置下超过150秒——这在实际智能体客户端中足以触发超时。在五种消费级系统上,FreeToken将解码吞吐量提高了1.3–2.1倍。在8GB RTX 4060笔记本上,它以39.3 tok/s服务35B模型,超过Codex的33 tok/s中位解码速度。在32GB游戏台式机上,它可交互式服务284B模型。在单台RTX PRO 6000工作站GPU上,它以两倍于llama.cpp的吞吐量服务753B GLM-5.2。

这些进展共同将开源权重转化为开放访问,将前沿智能从数据中心基础设施带到用户已拥有的设备。FreeToken推动了本地推理的速度和能力前沿,使个人硬件能够交互式地服务此前仅在数据中心实际可行的模型。我们在flashml.ai(https://flashml.ai/)发布该系统。

## 2边缘MoE服务的挑战

MoE是边缘服务的天然架构。一个典型的MoE层存储E个专家,但每个令牌仅路由到其中k≪E个专家,因此单个解码步骤触及的权重仅是该层总参数的一小部分。然而,实践中,现有边缘服务引擎(Gerganov等人,2023年【参考文献11】;KVCache-AI团队,2025年【参考文献18】;Xue等人,2024年【参考文献39】)远未达到硬件理论上可支持的水平,且在智能体工作负载上缺口更严重:首次令牌时间(TTFT)随每次工具调用增长,解码速度远低于设备的内存带宽。本节探讨缺口背后的三个挑战:预填充成本(第2.1节)、解码成本(第2.2节)以及两者之下的资源可变性(第2.3节);第3节的三个小节将依次回应它们。

### 2.1预填充阶段的挑战:传输与重计算成本

预填充决定了每个智能体回合的TTFT。在边缘硬件上,预填充时间主要由两部分构成:专家传输(与完整模型而非激活路径成比例)和上下文重计算(智能体会话触发频率远高于当前系统能承受的水平)。

专家传输在每次预填充上增加数秒。尽管解码将每个令牌仅路由到k个专家,但预填充过程涉及每层数千个令牌。因此,这些路由令牌激活了几乎全部专家集。预填充过程因此几乎将整个专家池通过CPU-GPU互连流式传输。这引入了严重的I/O开销,而VRAM驻留部署则完全不会执行此操作。以DeepSeek-V4-Flash的FP4部署为例,它需要传输约140GB专家权重,在RTX 5090系统(PCIe 5.0 x16,∼60 GB/s)上增加约两秒,在RTX 4090和3090级别台式机(PCIe 4.0 x16,∼25 GB/s)上增加约五秒,在笔记本常见的x8链路上增加十秒或更长时间。按需获取专家的引擎会将此整个窗口暴露为GPU空闲时间。这种多秒延迟在智能体服务中通常不可接受。

智能体工具调用触发频繁重预填充。第二个挑战是重复计算模型已完成的工作。许多前沿模型采用混合注意力架构,交替使用全注意力与滑动窗口注意力(例如DeepSeek-V4-Flash【DeepSeek-AI,2026年【参考文献4】】和GPT-OSS【OpenAI,2025年【参考文献26】】)或循环层(例如Qwen3.6-35B-A3B中的门控DeltaNet【Yang等人,2024b【参考文献42】】和Kimi-K3中的Kimi Delta Attention【Kimi团队,2025年【参考文献16】】)。与标准注意力不同,这些层将过去上下文压缩为单个状态或最近窗口的KV条目。因为每个保存的状态占用相当于数百个令牌KV缓存的内存,服务引擎仅保留少量检查点。智能体工作负载几乎在每个回合修改上下文。例如,工具调用常移除旧输出并删除思考段。由于这些修改,修改位置之后的任何检查点都变得无效。引擎必须回退到修改前的最后一个有效检查点。由于检查点稀疏,引擎常需重预填充数千个令牌。然而,消费级GPU无法隐藏此重复成本:RTX 5090仅提供约H100五分之一、B200十分之一的密集BF16吞吐量,因此每次冗余重预填充都会显著增加延迟。

相似文章

FreeToken:高效边缘原生MoE服务与带宽自适应执行

Hugging Face Daily Papers

FreeToken是一个边缘原生服务系统,它将计算和模型状态动态映射到异构本地硬件上,以在个人机器上运行大型开放权重模型,使得在单个GPU上高效执行高达753B参数的模型成为可能。

MobileMoE:扩展端侧混合专家模型

Hugging Face Daily Papers

MobileMoE 引入了高效的端侧混合专家语言模型,参数规模低于十亿,在性能和效率上均优于密集基线模型和现有的 MoE 模型。这些模型在开源数据集上训练,并在商用智能手机上展现出显著的加速效果。

SpecPrefetch:面向稀疏MoE基础模型的参数高效专家预取

arXiv cs.AI

SpecPrefetch提出了一种面向稀疏MoE模型的参数高效专家预取框架,使用轻量级适配器预测下一层专家以进行异步传输,同时保留原生路由语义。在Snapdragon 8 Elite设备上,它实现了高达20%的解码吞吐量提升,展示了在内存受限部署中的实用优势。