你在笔记本上开着浏览器和视频会议，又想让本地 AI 帮你改代码。问题不只是显卡够不够快。模型所需的数据可能放不进显存，只能在系统内存和显存之间来回搬；一旦通道拥堵，GPU 就会停下来等数据。FreeToken 想解决的正是这件事：不把个人电脑当成一块缩水的服务器显卡，而是把 GPU、CPU、系统内存和它们之间的带宽放在一起调度，让模型的执行方式随机器和负载变化。
论文将 FreeToken 定义为面向边缘设备的 MoE 推理系统。边缘推理，就是直接在个人电脑等用户身边的设备上运行模型，而不是把请求发往数据中心。作者报告称，系统支持超过 20 个 MoE 模型，并在真实的编程、工具调用智能体任务上进行了测试。下文的性能数字均来自这一篇论文，尚没有第二个独立信源验证。
大模型装得下，不等于跑得动
MoE——Mixture of Experts，中文常译为“专家混合”——会把模型拆成许多专家子网络。每处理一个 token，也就是模型读写文字时使用的基本单位，系统只调用少数专家。好处是一次计算不必动用全部参数；麻烦是完整的专家库仍然很大。如果本轮需要的专家不在显存，就得从系统内存临时搬进去，或者直接交给 CPU 计算。
这像一家仓库很大的餐厅：每张订单只需要少数几种食材，但你不知道下一单会点什么。小冰箱装不下整个仓库。频繁取货会让厨师等车，全部留在仓库加工又太慢。
这个问题在智能体任务里更突出。智能体不只回答一次问题，还会调用工具、读取结果、修改上下文，再继续生成。推理通常分成两个阶段。Prefill 是先读完已有提示词，决定多久能吐出第一个 token；decode 则是随后逐个生成 token。论文指出，长提示词的 prefill 往往会触及几乎全部专家，稀疏模型在这一阶段近似变“密”。到了 decode，每一步只用少量专家，但专家选择不断改变，缓存又容易落空。
先把搬运藏到计算后面
FreeToken 没有给所有设备规定一套固定卸载方案。它把完整专家库保存在 CPU 一侧的系统内存中，把剩余显存做成可调整的专家缓存，再持续按实际资源安排计算和模型状态。
在 prefill 阶段，它采用双缓冲：GPU 计算当前层时，系统同时通过 PCIe——连接 CPU 与 GPU 的高速通道——搬运下一层专家。两个缓冲区轮流使用，尽量把运输时间藏在计算时间后面。若显存连两个完整层的缓冲都容不下，系统会退回按需加载，不强行超额占用。
论文给出的拆解实验显示，在 RTX 5090 上，开启双缓冲后，每个 8,192-token 的 prefill 分块耗时 1.19 至 1.22 秒，接近通过实测 52.7 GB/s 链路搬完 64.4 GB 专家池的时间。关闭第二个缓冲区后，4k、8k 和 16k 提示词的吞吐量分别下降 19%、25% 和 26%。这说明重叠搬运确实是其 prefill 收益的重要来源。
FreeToken 还会在思考片段、工具调用、工具输出和对话轮次等语义边界保存状态检查点。智能体删改历史记录时，只要较早的前缀仍然有效，系统就能从最近的有效检查点继续，只重算新后缀。它解决的是一个很实际的问题：工具调用改了后半段上下文，不该逼模型把前面没变的内容再读一遍。
缺失的专家，搬过去还是就地算
Decode 阶段的关键选择是：缓存未命中时，究竟把专家传入 GPU，还是留在系统内存、直接由 CPU 执行？两条路会争用同一份主机内存带宽。全部搬运可能闲置 CPU；全部交给 CPU，又会浪费 PCIe 和 GPU，并失去把专家留在缓存、供后续复用的机会。
FreeToken 会在部署机器上实测专家传输带宽和主机处理带宽，据此把每一步缺失的专家分成两组。一组进入 GPU 缓存并由 GPU 执行，另一组留给 CPU；两边并行，目标是让完成时间尽量接近。系统至少保留一次缓存填充，因此即使 CPU 承担多数缺失任务，GPU 缓存仍会逐步预热。论文称，两条路径最终合并精确的 MoE 输出，没有引入算法近似。
缓存本身采用 LRU——Least Recently Used，即优先淘汰最久没有使用的专家。原因是相邻 token 往往会重复调用一部分专家。论文对四类任务的路由轨迹进行回放：在相同缓存容量下，FreeToken 的未命中率在两个测试模型上分别为 16% 和 39%；KTransformers 为 41% 和 59%，llama.cpp 的静态划分为 62% 和 89%。相比一次加载后便基本不变的布局，这种缓存会跟着当前生成过程移动。
它把“本地可运行”推到了哪里
论文在六台机器、四类智能体任务上测试 FreeToken，并与 llama.cpp、Ollama、KTransformers 和 MoE-Infinity 比较。在 RTX 5090 上，Qwen3.6-35B-A3B 的 decode 达到 77—83 tok/s，DeepSeek-V4-Flash 达到 22—25 tok/s；相对各任务中最强基线，分别提高 1.8—2.3 倍和 1.5—1.9 倍。三个智能体任务中的速度与单轮任务相比，波动保持在 12% 以内。
首个 token 的等待也更稳定。论文称，FreeToken 在所有测试单元中的最差单轮 TTFT——Time to First Token，即从提交请求到看到第一个 token 的时间——均低于 44 秒；每个基线系统都至少在一种设置中超过 150 秒。对会设置超时的智能体客户端来说，尾部延迟不只是体验指标，也可能决定一次工具调用能否完成。
硬件跨度同样值得注意。作者报告，FreeToken 可在配备 8GB RTX 4060 的笔记本上以 39.3 tok/s 运行 35B 模型；在 32GB RTX 5090 游戏桌面电脑上运行 284B 的 DeepSeek-V4-Flash；并在单张 96GB RTX PRO 6000 上服务 753B 的 GLM-5.2，吞吐量为 llama.cpp 的两倍。这里的参数量指论文采用的模型口径，不等于每生成一个 token 都会激活全部参数。
真正有意思的不是又一个“超大模型成功启动”的展示，而是 FreeToken 把本地推理重新定义成资源编排问题。个人设备的显存会被浏览器、桌面和游戏占用，上下文增长也会挤压 KV Cache——模型保存中间结果、避免反复重算的“草稿纸”。FreeToken 可以在调度安全点调整专家缓存与其他内存的分配，不重启引擎，也不重新载入主机侧专家池。它因此试图回答一个比“模型能否塞进显卡”更实际的问题：当机器资源一直变化时，系统怎样继续服务。
局限与未知
- 所有结果都来自作者论文。材料没有提供独立复现，FreeToken 的代码、版本、许可证和发布状态也未在此得到外部核验；作者称系统已发布于 flashml.ai。
- 35B、284B 和 753B 的展示不能简单理解为“只靠对应显存即可流畅运行”。运行还依赖 CPU、系统内存、存储、互连和量化格式；不同展示的上下文长度及完整资源需求并未统一说明。
- “带宽自适应”在论文中有实测带宽、任务分流和拆解实验支撑，但现有材料没有展示长期运行时带宽波动下的在线监测频率、调整开销，以及与其他前台应用争抢资源时的完整效果。