FreeToken 重写本地 MoE 推理：在合适的硬件上比 Ollama 快一倍

加州大学伯克利分校与得克萨斯大学奥斯汀分校研究者推出的一个新开源推理引擎，清除了一道让「在消费级硬件上跑前沿规模的专家混合（MoE）模型」变得不切实际的瓶颈 —— 但只在合适的条件下成立，而那些条件比网上流传的病毒式基准所暗示的要苛刻得多。

FreeToken 于 2026 年 8 月 17 日随论文《FreeToken：以带宽自适应执行实现高效的边缘原生 MoE 服务》发表，并同时以 Apache 2.0 开源软件形式发布。它把 Ollama 和 llama.cpp 所用的静态 GPU/CPU 模型切分方案替换掉，改为把整台个人电脑 —— GPU、CPU、显存、系统内存和 PCIe 互连 —— 当作一个单一的弹性推理平台。论文作者名单里有几位来自伯克利和 UT 奥斯汀的知名人物：Song Han、Matei Zaharia、Ion Stoica、Kurt Keutzer 和 Chenfeng Xu 都在贡献者之列。该项目在发布首周就积累了超过 2200 颗 GitHub 星。

那句头条式的主张 —— 在单块工作站 GPU 上跑 Z.ai 的 7530 亿参数 GLM-5.2 —— 是真的。但这在实践中需要什么、以及 FreeToken 的做法究竟在什么时候真的胜过现有方案，与社交媒体上正在进行的那场讨论是两回事。

MoE 模型为什么会造出一个 PCIe 带宽问题

要理解 FreeToken 的架构，先得理解 MoE 模型为什么在消费级硬件上既诱人又难伺候。

稠密大语言模型每生成一个 token 都会激活它全部的参数。而 MoE 模型维护着一大批专门化的「专家」子网络，每个 token 只被路由给其中一小部分。比如 DeepSeek-V4-Flash 有 2840 亿总参数，但每个 token 只激活约 130 亿。正是这种稀疏性，让人们能在可控的每 token 计算成本下造出总容量巨大的模型。MoE 是当前许多最大的开放权重模型背后的架构：DeepSeek-V4-Flash、Qwen3.6-35B、GLM-5.2 等等。

问题在于存放。某个 token 上那 130 亿个激活参数，能装进一块 16 到 24GB 显存的消费级 GPU。但剩下那 2710 亿个未激活参数得有地方待，而它们装不进显存。它们占着系统内存，GPU 则在每个 token 上通过 PCIe 总线去取所需的专家。消费级 PCIe 带宽 —— 视插槽和世代通常在 16 到 64 GB/s —— 远低于数据中心用来掩盖这项开销的 NVLink 互连。

MoE 的路由是动态的：门控网络根据进来的 token 选择专家，这意味着运行时无法预先知道接下来会需要哪些专家权重。正是这种不可预测性，让静态放置策略 —— 也就是 FreeToken 之前每一个推理引擎所用的做法 —— 在根本上是浪费的。

Ollama 和 llama.cpp 怎么处理这个问题 —— 以及为什么不够

本地大模型推理中占主导的两个工具 —— C++ 推理引擎 llama.cpp，以及用 Go 守护进程包装 llama.cpp、加上模型管理和 REST API 的 Ollama —— 处理 MoE 权重分布的方式，是在模型加载时做一次性决定。一部分层被永久分配给 GPU，其余永久分配给 CPU 可访问的系统内存。Ollama 基于硬件探测自动完成这个切分；llama.cpp 则要求用户通过命令行参数手工配置。

这种静态做法可预测、开销低。但它对相当一部分 token 来说也是根本错的：因为被激活的专家每个 token 都在变，一条固定的 GPU/CPU 边界必然会迫使许多 token 绕到错的那一边。每发生一次缓存未命中，GPU 就要停下来等专家权重经 PCIe 链路传过来。在笔记本上，每一次缓存未命中都是一次 GPU 停顿。

对于小到能把大部分层放进显存的模型，这种局面还可控。而当模型有相当大一部分装不进显存时 —— 也就是前沿规模 MoE 模型在消费级硬件上的定义性条件 —— 它就变成一道严重的性能天花板。

FreeToken 的 Q* 策略用实时调度取代静态切分

FreeToken 采取的是结构上不同的做法。整个专家池作为唯一权威副本存放在系统内存里。GPU 的显存则充当一个动态的 LRU（最近最少使用）缓存，保存最近被激活过的那些专家权重 —— 这是FreeToken 论文中的描述。

选用 LRU 缓存不是随意的。MoE 模型表现出很强的引用局部性：对一串相关的 token，门控网络倾向于反复激活同一小批专家。一个用户在写 Python 函数，多数 token 会走代码相关的专家；一个用户在问历史问题，则会走另一批。在任何连贯序列的头几个 token 之后，LRU 缓存就被那些不断被激活的「热」专家填满。FreeToken 论文报告，在典型负载下缓存命中率高达 85%。

而当缓存未命中真的发生时 —— 需要某个当前不在显存里的专家 —— FreeToken 的 Q* 策略就介入了。它不是干等权重传到 GPU，而是同时评估两个选项：把权重经 PCIe 流式传给 GPU 在那边执行，或者直接在 CPU 上算 —— CPU 的内存里本来就有那些权重。两个选项都不是普遍更快；答案取决于跑这个任务的机器上 PCIe 带宽与 CPU 内存带宽之间的具体平衡。

启动时，FreeToken 在实际硬件上对两条路径各跑一次基准。当一批缓存未命中发生时，它计算出一个闭式比例，决定把多少工作分给哪一边。在一台配 PCIe 5.0 的高端工作站上，FreeToken 可能把约 41% 的未命中专家送给 GPU、59% 给 CPU。而在一台 PCIe 4.0 链路更窄、但 CPU 更强的笔记本上，这个比例可能反过来，约为 13% 和 87%。系统的目标是让两条执行路径同时完成，从而消除困扰静态卸载的那种顺序停顿。

第三项机制处理预填充阶段 —— 也就是对一段长输入提示词的初始处理 —— 在那里，多样的 token 序列可能激活一大片专家，把一个已经预热好的缓存也耗尽。FreeToken 在预填充期间使用双缓冲：当 GPU 处理第 N 层的专家时，引擎预测第 N+1 层将需要哪些专家，并并行地把它们从内存流入一个次级显存缓冲区。等 GPU 做完第 N 层，第 N+1 层的权重已经加载好了，PCIe 传输延迟被藏在了 GPU 计算的背后。

最后，FreeToken 用自己的 FTW（FreeToken Weight）格式把模型权重存在磁盘上，该格式与引擎的内部内存布局完全一致。标准推理引擎在启动时要加载权重、解码，再重新打包成合适的内部格式 —— 对动辄数百 GB 的模型来说这是个慢操作。FTW 则是一次直接的内存映射读取，没有中间转换，缩短了大模型的启动时间。

独立测试印证了这些增益 —— 在工作站硬件上

FreeToken 论文报告了作者自行完成的基准：该引擎在一块 8GB 的 RTX 4060 笔记本上以约每秒 39.3 个 token 跑 Qwen3.6-35B；在一台 RTX 5090 台式机上以每秒 22 到 25 个 token 提供 DeepSeek-V4-Flash（2840 亿参数）服务；并在单块工作站 GPU 上以约每秒 14.9 个 token 处理 GLM-5.2（7530 亿参数），而 llama.cpp 在同等硬件上是 7.3。这些基准由作者本人完成，尚未被外部实验室大规模独立复现。

目前可得的最可信独立测试来自BetterStack，它跑的是一个真实的智能体式编程任务 —— 用 OpenCode 写一整套 Pytest 测试 —— 硬件是一台配 RTX 5090（32GB 显存）、Core Ultra 9 285K CPU 和 64GB DDR5 内存的工作站。测试模型是 8 比特量化的 Qwen3.6-35B（约 38GB），比 GPU 显存大约多 6GB。Ollama 用 14 分 20 秒完成任务，中位速度每秒 58.8 个 token。FreeToken 用 4 分 40 秒完成同一任务，每秒 132.5 个 token。这 2.25 倍的加速，正是在 FreeToken 设计所针对的那种负载上观察到的：一个超出显存的 MoE 模型，被用于一个上下文不断变化的智能体任务。

BetterStack 的测试还量化了 FreeToken 的缓存能被压到多狠而代价不大。把专家缓存从占全部专家的 57.8% 降到 40%，只造成 7.2% 的性能损失 —— 这与论文所称「在典型负载下，一小批热专家承担了大多数激活」是一致的。

同一组 BetterStack 测试也确认了反面：当模型能完全装进显存时，赢的是 Ollama。同一模型的 4 比特量化版本占 22GB，在 Ollama 下达到每秒 239.6 个 token，而 FreeToken 是 225.3。当没有内存压力来抵消它时，FreeToken 的调度开销会付出一笔虽小但可测的代价。

笔记本基准错在哪 —— 以及它们确实说明了什么

一个在网络社区里广为流传的基准，在一台 6GB 显存、24GB 系统内存的 RTX 3050 笔记本上，把 FreeToken 与 Ollama 和 llama.cpp 作了对比。在这套硬件上跑一个 MXFP4 量化的 200 亿参数 MoE 模型，Ollama 的首 token 时间约 0.38 秒，llama.cpp 约 0.5 秒，FreeToken 是 1.17 秒 —— 大约三倍的等待。FreeToken 在吞吐上也落后。

这些数字是关于那套特定硬件配置的准确观察。但它们不构成对 FreeToken 设计目标的有意义检验。这个引擎的开销 —— 持续的缓存状态监控、Q* 策略计算、带宽测量 —— 在一个基本能装进固定 GPU/CPU 切分的 200 亿参数模型上，根本没有问题可解。那套机制在空转，却没挣回自己的成本，于是产出了最坏情况的性能画像：全是开销，没有收益。

比吞吐数字更说明问题的是：在同一台笔记本上，FreeToken 的桌面应用把 35B 和 27B 模型标记为「内存不足」。24GB 系统内存根本装不下那些模型的专家池。这不是软件局限，而是前沿 MoE 模型代价的直接反映。FreeToken 那台 RTX 5090 加 64GB 内存的工作站测试，用的是一台能力根本不同的机器。那些病毒式笔记本基准所做的比较，是在「资源配置得当的工具」与「资源不足的部署」之间进行的。

FreeToken 与 KTransformers 及其他方案的比较

在本地 MoE 服务这个领域里，与 FreeToken 最接近的在先系统是KTransformers，这是清华大学 MADSys 实验室与Approaching.AI的项目，曾在 SOSP 2025 上发表，并在 2026 年持续更新。KTransformers 同样面向大型 MoE 模型的 CPU/GPU 混合推理，而且除英伟达外还积极支持 AMD ROCm、Intel Arc 和昇腾 NPU —— 相对 FreeToken 当前只支持英伟达的约束，这是一项显著的平台广度优势。

架构上的差别才是核心区分。KTransformers 用的是在推理开始前就确定的静态 CPU/GPU 卸载规则。FreeToken 则基于实测带宽，实时为每一层计算一个闭式的最优切分。FreeToken 论文报告，相对 KTransformers 以及 llama.cpp、Ollama 等其他本地引擎，吞吐提升 1.5 到 2.3 倍。这些对比由作者自行完成；截至 2026 年 9 月初，尚未有在这个规模上的独立正面对比发表。

vLLM 和 SGLang 这两个占主导地位的生产级服务推理框架，在这里不是相关的替代方案。两者都是为具备高带宽 GPU 互连的数据中心环境设计的；它们假设的内存层级，个人机器并不具备。

对正在评估这片版图的开发者：当目标模型能装进显存时，Ollama 仍是常见本地负载的正确选择。而当模型装不进显存、且机器有足够系统内存容纳完整专家池时，FreeToken 才是正确选择 —— 而对前沿规模的 MoE 来说，这些要求目前指向的是配 64GB 或更多系统内存和一块英伟达 GPU 的工作站硬件。

当前的约束：只支持英伟达，以及内存要求

FreeToken 的命令行工具需要 Linux x86_64、驱动 r580 或更新的英伟达 GPU、CUDA 13，以及 Python 3.10 或更新版本。一个面向 Windows 和 Linux 的桌面应用（见 flashml.ai）去掉了 Python 依赖并自动完成配置。截至 2026 年 8 月，不支持 AMD ROCm 和苹果芯片。

系统内存需求直接随模型规模缩放。跑一个 35B 模型需要的内存远超 24GB。要以论文所报告的基准速度提供 DeepSeek-V4-Flash（2840 亿参数）服务，需要 192GB 系统内存 —— 这是牢牢落在工作站范畴的硬件。而那次 7530 亿参数的 GLM-5.2 运行，用的是论文中描述为具备 96GB 显存和 512GB 系统内存的一块专用工作站 GPU。

FTW 权重格式虽然消除了启动时的重打包时间，却带来了格式锁定：模型必须以 FreeToken 的格式存储才能受益。对那些认定要持续跑特定模型的用户，这是一个合理的取舍；但对经常在不同引擎之间切换的用户，它增加了摩擦。

Windows 的内存完整性（Memory Integrity）—— 一项拦截未签名内核驱动的安全功能 —— 可能与 FreeToken 的 DLL 栈冲突。至少有一个有记录的案例，必须关闭内存完整性才能解决一次启动失败，而该失败在标准终端里没有产出任何有用的错误信息；以管理员身份运行才显示出真正的报错。这些是早期软件的安装边缘情况，但也表明其安装体验尚未达到 Ollama 的打磨程度。

智能体式负载才是明确的目标

除了吞吐基准之外，FreeToken 有两项特性对智能体式 AI 工作流格外重要 —— 在那类工作流里，模型的使用模式与单问单答式推理有根本不同。

一次智能体会话会不断重新进入预填充阶段。每一次工具调用的结果、每一个思考块、每一次上下文更新，都会触发对累积对话历史的又一遍处理。若不做优化，这会导致每一轮都对同一段前缀上下文重复计算 —— 随着会话变长，这是二次方级的代价。FreeToken 的语义感知缓存使用锚点检查点来保存 KV 缓存和循环状态，当只有上下文尾部发生变化时，跳过冗余的重新计算。

FreeToken 还允许在运行时于专家缓存与 KV 缓存之间重新分配显存，而不必重启引擎。会话越长，KV 缓存需要的空间越多；而当专家访问模式趋于稳定后，专家缓存可以被安全地缩小。通过 ft ctl 实现的这种动态再平衡，让引擎能够适应会话特性，而不必在启动时就锁定一个固定的内存分区。

这些特性解释了为什么 BetterStack 那个智能体编程测试 —— 一个涉及多次工具调用、上下文累积和反复预填充的任务 —— 表现出的加速比单次查询吞吐基准所能预测的更大。这份增益不只来自更好的解码吞吐；它还在那些构成真实智能体使用特征的反复预填充操作上层层叠加。

这道基准落差揭示了推理生态的什么问题

FreeToken 的出现，指向本地推理工具生态里一道自「MoE 成为大型开放权重模型主导架构」以来就存在的结构性缺口。开发者最先伸手去拿的那些工具 —— 图省事用 Ollama、图性能用 llama.cpp —— 都是为稠密模型设计的，用的是静态放置策略，对 MoE 专家路由那种动态、对缓存敏感的行为，没有任何有原则的应对机制。

在数据中心场景里，这道缺口是靠高带宽互连解决的；在消费级硬件上它一直没被解决，因为没有人去搭那套调度设施。FreeToken 是第一个由主要研究团队从第一性原理出发去啃消费级 MoE 服务问题的系统，其架构是围绕消费级硬件的具体性质构建的，而不是从数据中心的假设上缩小而来。

接下来值得盯的工作是：AMD ROCm 和苹果芯片支持会不会被加上；独立的基准复现能否在更广的硬件范围上确认论文的吞吐主张；以及那 1.5 到 2.3 倍的增益在 7500 亿以上参数规模上是否仍然成立 —— 在那个规模上，数据中心方案（租 GPU 集群时间）今天对多数开发者仍是唯一可行的选项。FreeToken 的核心主张是：人们已经拥有的个人机器，可以成为运行前沿规模开放权重智能的实用平台；而对这个主张最严肃的检验，将是它的增益在「迄今被用来跑基准的那些英伟达工作站之外的硬件」上能否存活。