端侧MoE推理新神器FreeToken发布，论文2026年8月公开

Q: FreeToken 支持哪些模型？

目前它已经支持了 20 多种 MoE 模型，我粗略列一下哈： - DeepSeek-V4-Flash- GLM-5.2、GLM-4.7- Qwen3.6-35B-A3B、Qwen3.5-35B-A3B、Qwen3-30B-A3B- GPT-OSS-120B/20B- Gemma-4- MiniMax-M2.5- Muse-Glimmer……还有好几个我没记全的。

ivye
工具收集
3小时前
7热度
0评论

本地跑大模型，显存不够一直是老大难问题。不过 FreeToken 想解决的可不只是这个问题。

它的核心思路是：把 GPU、CPU、内存和 PCIe 总线当成一个整体来调度。

一、FreeToken 到底是什么？

我觉得 FreeToken 这玩意儿挺有意思的。它是一套专门给端侧硬件用的 MoE（Mixture-of-Experts）推理系统，背后有 Shuo Yang、Song Han、Matei Zaharia、Ion Stoica 这些大佬参与开发，论文是 2026 年 8 月才公开的。

说实话，它可不是简单的把计算往 CPU 上搬那么简单。人家从底层就把整套推理运行时给重构了——Expert 怎么加载、怎么缓存、CPU 和 GPU 怎么配合、Agent 上下文复用、显存动态管理……每个环节都重新设计过。你猜怎么着？这真的有用吗？效果确实不错。

官方的说法是，FreeToken 已经能跑 20 多种 MoE 模型了，从 8GB 显存的笔记本 GPU 一直到工作站级别的显卡都能适配。老实讲，这个兼容性确实挺吓人的。实验那边重点测了几个：Qwen3.6-35B-A3B、DeepSeek-V4-Flash 和 GLM-5.2。话说回来，这几个都是挺主流的模型，能跑通就说明 FreeToken 不是纸上谈兵，对吧。

二、MoE 模型的端侧痛点

我觉得MoE这东西吧，最大的卖点就是总参数能堆得特别大。不过呢，每个Token实际上只唤醒少数几个Expert。

你拿 DeepSeek-V4-Flash 打个比方哈，它虽然总共塞进去了 284B 参数，但每个 Token 每层其实就挑出 6 个 Expert 来干活，真正参与计算的也就 13B 左右。
这怎么破？剩下那些不参与当下计算的 Expert 权重，总不能悬空吧？你猜怎么着，这地方还真不好安置。

显存？根本装不下那么多 Expert，对吧……
塞到系统内存里倒是行，但你得通过 PCIe 一条一条搬过来，这过程挺磨人的。
结果 PCIe 那点带宽，跟 GPU 显存比起来，简直是杯水车薪。
CPU 其实也能顶上算 Expert，不过嘛，算力跟内存带宽双双受限，跑起来挺吃力的，效率大打折扣。
还有啊，Agent 但凡改一下上下文，之前算好的 Prefill 可能就得推倒重来，那开销想想都头大。

说实话，FreeToken 这套玩法的核心，说白了就一句话：别死磕 GPU Offload 或者 CPU Offload 某一招，直接看眼下这台机器的带宽和算力到底够不够，再来动态调度。这思路是不是顺多了？

三、核心技术：Prefill 全层双缓冲

说实话，长 Prompt 的 Prefill 绝对是端侧 MoE 最容易卡住的地方。

Decode 阶段其实还好，一个 Token 就调用几个 Expert 就够了。但你想想 Prefill 的时候——长 Prompt 一进来，大量 Token 的路由范围直接覆盖几乎整个 Expert 池，数据量巨大。论文里提到一个数字，DeepSeek-V4-Flash 的 FP4 部署在 RTX 5090 上，单次 Prefill 可能要搬 140GB 的 Expert 权重……这数字吓人不？

FreeToken 的做法挺巧妙的：全层双缓冲流水线。

GPU 正在算第 L 层；
后台传输线程同时通过 PCIe 把第 L+1 层的 Expert 数据搬过来；
当前层一跑完，两个 Buffer 直接交换；
下一层的 Expert 早就待命了。

说白了就是——把计算和传输时间叠在一起，PCIe 延迟能藏多少藏多少。

你们猜怎么着？论文实验的数据还挺好看的：RTX 5090 上跑 8192 Token 的 Prefill，Expert 流式传输速度能达到大约 52.7GB/s。如果取消双缓冲……4K、8K、16K 的吞吐分别掉了 19%、25% 和 26%。

差距还挺明显的对吧。

四、核心技术：q* 带宽自适应 CPU/GPU 调度

说实话，Decode阶段的问题还真不太一样。

我觉得吧，一个Token其实只激活少数几个Expert。要是这些Expert刚好已经在GPU Cache里，那太好了，直接算就行……可一旦没命中，就会产生Cache Miss。

老实讲，老办法基本就两条路：要么从内存把Expert搬到GPU，要么干脆让CPU算。

而FreeToken的思路有点不一样——它会根据机器当前的实际PCIe带宽和CPU计算能力，对Cache Miss做个动态拆分。

你看个例子，假设现在碰上10个Expert Miss：

一部分走PCIe搬去GPU；
另一部分直接在CPU上算，不搬了；
两边的活儿还能并行干；
最后把结果汇到一块儿。

这招叫 q Bandwidth-Adaptive Execution。

FreeToken会用ft bench bw实测一下当前机器的CPU/内存和PCIe性能，再按比例分流，而不是套用一个死板的固定参数。

说白了，它把PCIe带宽当成了一个可以灵活调度的运行时变量，而不是一道不可逾越的硬件门槛。

五、核心技术：全局 LRU Expert Cache

说实话，FreeToken 压根不会让每个 Expert 都跑去系统内存重新加载一遍。

它在 GPU 显存里专门搞了个共享的 Expert Cache，靠 LRU（Least Recently Used）策略来管。最近老被调用的 Expert 就尽量留在显存里；等显存不够用了，优先踢掉那些闲了好一阵子的。

话说回来，你猜怎么着？这 Cache 可不是按某一层单独管的，而是当成跨层共享的 Expert 缓存池在用。这么一来，有限的 VRAM 总算能被利用得更充分一些。

六、核心技术：面向 Agent 的语义状态复用

说实话，FreeToken 没停在普通聊天优化上。

它盯的是 Coding Agent 和工具调用这些场景——这才是真正费算力的地方。

你想想 Agent 的工作流程：

用户问 → 思考 → 调工具 → 拿结果 → 改上下文 → 再来一轮推理……是不是有点绕？

每调一次工具，Prompt 都可能变。

按老办法，历史上下文一大堆，重新 Prefill 根本扛不住。

所以 FreeToken 的做法是，在特殊 Token 边界埋下语义锚点检查点——比如对话轮次、Thinking 区块、Tool Call 和 Tool Output。

上下文一改，系统直接找修改位置前最近的那个有效 Checkpoint，从那儿接着算。

不用回头重跑全部历史。

这设计特别适合 Coding Agent，对吧？

因为 Agent 改上下文的地方，往往都有明确的语义边界——正好卡在锚点上。

七、核心技术：显存动态热调整

说实话，消费级显卡本来就不是为 AI 推理专门设计的。

你想想看，一个普通用户可能同时开着浏览器、打打游戏、跑跑 Blender、剪个视频、渲染个 3D……各种 CUDA 程序都能往上怼。这时候显存使用情况肯定是一会儿高一会儿低的，对吧？

FreeToken 的做法是把 GPU Expert Cache 做成一个可以随时伸缩的资源池。我觉得这个设计挺关键的——跑着跑着 VRAM 变小了，它能在安全调度点自动缩小 Cache，把更多的 Expert 挪到 CPU 内存里；反过来显存释放出来了，Cache 就能重新扩大。

官方 CLI 已经给了 ft ctl cache --moe ... --kv ... 这类接口，Cache 可以直接在线重建和调整，推理引擎不用重启，主机端的 Expert 权重也省去了重新加载的麻烦。

八、实测性能

说实话，FreeToken 这篇论文里的测试结果，真的挺让人意外的。

我看了下他们在 RTX 5090 上的表现——

Qwen3.6-35B-A3B：大概 77–83 tok/s，这速度相当猛了
DeepSeek-V4-Flash：约 22–25 tok/s
跟其他端侧推理系统比，Decode 吞吐直接拉高了 1.5–2.3 倍，差距还挺明显的
五台消费级机器一起测，提升幅度在 1.3–2.1 倍左右
最让我印象深刻的——8GB 显存的 RTX 4060 笔记本，跑 35B 模型居然能到 39.3 tok/s……
32GB 显存的游戏 PC，直接就能交互式跑 284B 的模型
单张 RTX PRO 6000 更是能扛住 753B 的 GLM-5.2，论文里说吞吐量大概是 llama.cpp 的两倍

话说回来，他们测 TTFT 的时候，把所有最坏情况都压在了 44 秒以内。而对比的基线系统呢？有些场景直接飙到 150 秒以上。你猜怎么着？这差距可不是一点半点。

不过我觉得吧，这些数字得理性看待——它们只是论文作者在自己特定的硬件、模型、量化格式和工作负载下跑出来的结果。所以，不是每个 RTX 4060 或者 5090 用户都能直接拿到一模一样的速度，对吧？这一点得心里有数。

九、目前支持什么模型和硬件？

说实话，FreeToken 目前主要面向 Linux x86_64 + NVIDIA GPU + CUDA 13 这个组合。NVIDIA 驱动得 r580 以上，Python 也要 ≥3.10。对了，官方倒是也出了 Windows 和 Linux 的桌面 App，算是比较贴心了。

现在官方已经验证过的模型：

DeepSeek-V4-Flash
GLM-5.2 —— 最近挺火的
GLM-4.7
Qwen3.6-35B-A3B，Qwen3.5-35B-A3B，还有 Qwen3-30B-A3B 这一大家子
GPT-OSS-120B 和 20B
Gemma-4
MiniMax-M2.5
Muse-Glimmer

MoE 后端方面，fused、offload、cpu、hybrid、auto 都有。

其中 hybrid 是 CPU 与 PCIe 动态混合执行的模式，auto 则是根据模型类型加上本机带宽测试的结果自动选策略——感觉这个设计挺合理的，对吧？

话说回来，官方还特别注明了一点：多模态模型现在还是按纯文本方式提供服务。另外 DeepSeek-V4 的话，得保留 checkpoint 里的 inference/config.json，漏了这个可能就跑不起来……

十、如何快速使用？

官方给了个 CLI 安装方式，挺方便的：

uv venv
source .venv/bin/activate
uv pip install "freetoken[accel]"

装完之后直接启动模型就行：

ft serve --model ~/models/Qwen3.6-35B-A3B

参数这里也能直接填 Hugging Face 的 Repo ID，省事。

启动以后，FreeToken 接口是跟 OpenAI 兼容的：

/v1/chat/completions
/v1/responses
/v1/models

另外也支持 Anthropic 的 API：

/v1/messages
/v1/messages/count_tokens

说白了就是，你现有那些支持 OpenAI 或者 Anthropic 接口的客户端，改一下 Base URL 就能直接用。这设计我倒是觉得挺聪明的。

Coding Agent 这边官方 CLI 还做得更细：

ft launch claude
ft launch codex
ft launch openclaw
ft launch opencode

一条命令，自动配好对应 Agent 去用 FreeToken 服务。你猜怎么着？连配置都不用手动折腾了……

十一、项目地址

官网：https://www.flashml.ai/

GitHub：https://github.com/FlashML-org/FreeToken

论文：https://arxiv.org/abs/2608.16157

FAQ

FreeToken 是什么？

说实话，这个东西挺有意思的。FreeToken 是一套专门给端侧硬件设计的 MoE（Mixture-of-Experts）推理系统，背后的研究团队阵容挺强——Shuo Yang、Song Han、Matei Zaharia、Ion Stoica 这些人，论文是 2026 年 8 月刚公开的，所以还挺新的。

FreeToken 支持哪些模型？

目前它已经支持了 20 多种 MoE 模型，我粗略列一下哈：

- DeepSeek-V4-Flash
- GLM-5.2、GLM-4.7
- Qwen3.6-35B-A3B、Qwen3.5-35B-A3B、Qwen3-30B-A3B
- GPT-OSS-120B/20B
- Gemma-4
- MiniMax-M2.5
- Muse-Glimmer
……还有好几个我没记全的。

FreeToken 的性能表现如何？

我倒是认为这数据还挺能打的。在 RTX 5090 上跑 Qwen3.6-35B-A3B 能达到 77-83 tok/s，DeepSeek-V4-Flash 大概 22-25 tok/s……你猜怎么着，相比其他端侧推理系统，Decode 吞吐整体提升了大约 1.5 到 2.3 倍。这个提升幅度，我觉得还是挺值得关注的一个点……