单卡5090跑满血DeepSeek-V4-Flash！爆火的FreeToken一周狂揽8.4k

智猩猩AI整理
编辑：BugMaker

大模型开源之后，真正的问题正在从“模型能不能获得”变成“普通用户能不能跑起来”。

目前越来越多百亿、千亿参数级开源模型开放权重，但这些模型真正运行时，仍然依赖昂贵的数据中心GPU。

但真正的瓶颈并不只是硬件。

大量消费级设备已经拥有独立GPU，包括游戏主机、工作站和高性能笔记本，但这些计算资源长期没有被充分利用。

近日，MIT韩松参与提出的FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution正式开源。

项目开源后迅速在GitHub走红。智猩猩AI在8月20日首次关注时，FreeToken还只有76 Stars，随后几天迅速冲上GitHub热门榜单。

8月22日，FreeToken登上GitTrend全站Trending第3，当天新增约1.8k Stars。8月25日又以约2.1k的单日新增位列全站第5。

截至8月26日，FreeToken已经达到8.4k+ Stars。短短几天从不足百星冲到数千星，也让这个边缘推理项目迅速成为近期AI Infra领域热度最高的开源项目之一。

它做的事情非常直接：

让消费级和边缘GPU也能够运行原本依赖数据中心的超大规模MoE模型。

FreeToken支持超过20个MoE模型，可以在从8GB笔记本GPU到工作站GPU的不同设备上运行。

其中最受关注的是，它让不同级别的消费硬件具备运行超大MoE模型的能力：

• 在RTX 4060笔记本上运行35B模型。

• 在32GB游戏桌面GPU上运行284B模型。

• 甚至在单张RTX PRO 6000上运行753B参数的GLM-5.2模型。

更重要的是，它并不是简单压缩模型，而是重新设计了一套面向边缘设备的MoE推理系统。

FreeToken希望解决的问题是：

让原本依赖数据中心的大模型推理能力，逐步进入用户自己的设备。

01

超大MoE模型进入本地设备，

关键是重新设计推理系统

MoE模型给本地运行带来了新的可能。

与传统密集模型不同，MoE模型虽然拥有大量参数，但每生成一个Token时，并不会激活全部专家。

可以简单理解为，一个MoE模型内部包含大量“子模型”，每次生成内容时只调用其中一部分专家。

但新的问题也出现了。

模型完整权重依然非常大，很多专家无法全部放入GPU显存。

因此，推理系统需要不断在GPU显存、CPU内存甚至磁盘之间移动专家权重。

过去的方法通常采用固定策略：哪些专家放GPU，哪些专家放CPU，什么时候加载。

这些规则在真实环境中并不稳定。

因为消费级设备和数据中心完全不同。

用户电脑上的GPU显存可能被浏览器、游戏等程序占用。

CPU、内存带宽和PCIe速度也存在巨大差异。

FreeToken提出的核心思想是：不要把边缘设备看成一块“小GPU”，而是把整台机器看成一个统一推理平台。

FreeToken没有继续采用固定的模型放置策略，而是围绕边缘设备三个核心限制重新设计推理流程。

第一是带宽自适应执行（Bandwidth-Adaptive Execution）。

FreeToken会根据当前机器真实测量得到的PCIe传输带宽和CPU内存带宽，动态决定哪些专家加载到GPU，哪些专家直接由CPU执行。

简单来说：

如果PCIe更适合搬运数据，就优先把专家放入GPU缓存。

如果CPU还有剩余带宽，就让CPU直接计算部分专家。

这样避免了过去固定策略造成的资源浪费。

第二是语义感知缓存（Semantic-Aware Caching）。

MoE推理过程中，不同Token选择的专家并不是完全随机。

相邻Token往往会访问相似专家。

FreeToken利用这一规律，在GPU中建立共享专家缓存，让经常使用的专家保持驻留。

论文中的实验显示，在相同缓存容量下，FreeToken的LRU专家缓存策略相比传统静态放置策略能够明显降低专家缺失率。

第三是弹性内存管理。

传统推理系统启动时就决定显存如何分配。

但边缘设备的资源会变化。

FreeToken允许运行过程中重新调整GPU专家缓存和KV Cache之间的空间分配，而不需要重新启动模型。

这让本地运行大型MoE模型更加接近云端服务体验。

02

面向Agent工作流优化，

让多轮工具调用不再反复计算

FreeToken并不是只针对普通聊天场景。

它重点关注的是越来越普遍的Agent工作负载。

例如Coding Agent，它需要不断读取代码、修改文件、运行测试并继续推理。

这类任务和普通问答不同。

一次任务可能包含多轮：模型思考，调用工具，读取结果，继续生成，上下文不断增长。

传统推理系统的问题在于，每次上下文变化都可能导致大量重复计算。

FreeToken针对这一点设计了语义锚点机制。

它会在思考过程、工具调用、工具输出等特殊位置保存状态。

当Agent修改历史上下文时，不需要重新计算全部内容，而只需要从最近有效状态继续推理。

这对于长时间运行的Agent非常重要。

因为未来的智能体不会只是回答一次问题，而是持续工作数分钟甚至数小时。

在性能方面，FreeToken也展示了明显优势。

在RTX 5090上测试了Qwen3.6-35B-A3B和DeepSeek-V4-Flash等模型，并与llama.cpp、Ollama、KTransformers等系统比较。

结果显示：

在Qwen3.6-35B-A3B上，FreeToken达到77–83 token/s，相比现有边缘推理系统最高提升2.3倍。

在参数规模更大的DeepSeek-V4-Flash上，这种优势依然存在。

DeepSeek-V4-Flash拥有284B总参数、13B激活参数，采用MXFP4专家权重。虽然每个Token真正参与计算的参数远小于284B，但完整专家池依然非常庞大，无法全部放入RTX 5090的32GB显存。

在RTX 5090上，FreeToken给DeepSeek-V4-Flash分配的GPU专家缓存只能容纳完整专家池的大约11%。即使在这么有限的缓存容量下，它的Decode专家缺失率仍控制在39%，而KTransformers和llama.cpp分别达到59%和89%。

在数学推理、OpenCode、Claude Code和OpenClaw四类任务中，FreeToken的Decode速度分别达到24.9、22.5、22.0和22.4 token/s，整体保持在22–25 token/s。

相比每个任务中的最强基线，FreeToken在DeepSeek-V4-Flash上的Decode吞吐达到其1.5–1.9倍。

明显的是Agent任务下的稳定性。从单轮数学推理进入OpenCode这类Coding Agent场景后，FreeToken从24.9 token/s变为22.5 token/s，整体变化并不大。

相比之下，KTransformers从单轮任务的10.4 token/s降到OpenCode场景的7.1 token/s，下降约31%。

这说明FreeToken解决的不只是“超大模型能不能在本地机器上运行”，还要让它进入真实Agent工作流后，在多轮交互中尽量保持稳定的推理速度。

03

从开源权重到真正可用的本地AI

FreeToken最大的意义，不只是又一个推理优化框架。

它改变的是大模型运行方式。

过去：

开源模型意味着任何人都可以下载权重。

但真正运行这些模型，仍然需要昂贵的数据中心资源。

FreeToken尝试解决的是中间这一步。

让用户已经拥有的GPU、CPU、内存和存储资源，被统一组织起来。

论文实验中，FreeToken覆盖了从RTX 4060笔记本到RTX PRO 6000工作站的不同硬件环境。

在8GB RTX 4060笔记本上，它可以运行35B模型，并达到39.3 token/s。

在单张RTX PRO 6000上，它运行753B GLM-5.2模型，吞吐达到llama.cpp的约2倍。

如果过去几年竞争的是谁能训练更大的模型，那么下一阶段的问题可能是：如何让更多设备真正运行这些模型。

随着越来越多MoE模型开放，推理系统本身正在成为大模型落地的重要基础设施。

FreeToken给出的答案是：

不要等待更大的GPU，先让现有硬件被更充分地利用。

关注+星标，获取AI前沿进展与开源一线动态