FreeToken：单卡运行753B参数MoE模型的本地方案

前沿开放权重模型的发布速度已经超过了支撑它们的硬件假设条件。Kimi-K3、GLM-5.2 和 DeepSeek-V4-Flash 正在缩小与闭源系统的能力差距，但开放参数只决定了谁能获取模型，而非谁能负担得起运行它的成本。推理服务仍然需要数据中心级 GPU 集群，而随着 Agent 工作负载推动推理需求上升，这一成本对于个人开发者和小团队而言压力最大。与此同时，超过一亿台消费级机器已经配备了独立 GPU。来自加州大学伯克利分校和德克萨斯大学奥斯汀分校的研究团队提出了 FreeToken。该研究团队认为，缺失的环节不是硬件，而是一个服务系统：它将个人机器视为一个统一的、弹性的推理平台，而非一块小型 GPU，持续将计算和模型状态映射到机器实际拥有的 GPU、CPU、内存和互联带宽上。最终实现了在 8GB 笔记本 GPU 上以交互速度运行 35B 模型、游戏台式机上 284B、以及单块工作站显卡上运行 753B GLM-5.2。

是的，FreeToken 采用 Apache-2.0 许可发布在 GitHub 上，发布在 PyPI 为 freetoken v0.1.2（uv pip install "freetoken[accel]"），并作为 Windows 和 Linux 的一键桌面应用发布于 flashml.ai。CLI 面向 Linux x86_64 + NVIDIA GPU（驱动 r580+，CUDA 13）。ft serve 在 1919 端口暴露 OpenAI 和 Anthropic 兼容的端点，ft launch claude 则可将 Claude Code、Codex、OpenCode 或 OpenClaw 对接到你自己的机器上。

适用人群：Agent token 费用已超过自购 GPU 成本的个人开发者、创业公司和中小型工程团队；企业应将其视为气隙隔离或受监管工作负载的路径，而非数据中心替代方案。行业契合度最高：医疗和法律（数据永不离开机器）、国防、金融和知识产权密集型研发。典型应用场景：本地编码 Agent、私有代码审查、离线合同分析、合成数据生成、批量评测。

混合专家机制使本地前沿推理在算术上变得可行。DeepSeek-V4-Flash 在每层 43 层中激活 256 个路由专家中的 6 个，因此其 284B 参数中只有 13B 参与任何单个 token。但稀疏性并不会缩小专家池——在 FP4 下完整集合约为 140 GB，因此非活跃专家驻留在主机内存中，按需进入执行路径。

研究团队分离出现有引擎中的三个失败模式（llama.cpp、KTransformers、Ollama、MoE-Infinity）：

Prefill 破坏稀疏性：每层数千个 token 路由到几乎整个专家集合，因此 prefill 过程经由 PCIe 流式传输整个池——在 RTX 5090 上约需 2 秒，PCIe 4.0 台式机 5 秒，笔记本常见的 x8 链路则需要 10 秒或更长。

静态放置错失解码流量：llama.cpp 在加载时分配 MoE 张量；KTransformers 固定一个"热点"子集。路由在每个 token 上都会转移，因此大多数专家求值落在 CPU 上，而 GPU 和 PCIe 链路则闲置。

消费级 CPU 无法承载剩余部分：双通道 DDR5 提供 80–90 GB/s，而 RTX 4090 或 5090 从片上封装内存汲取的是 1–1.8 TB/s。

带宽自适应执行（q* 策略）：由于 DMA 传输和 CPU 专家执行从同一主机内存子系统读取，饱和的 PCIe 链路会留下残余带宽 B_H − B_P。FreeToken 将每步的 m 缓存未命中相应分割：q* ≈ m × B_P / B_H 专家填充到 GPU 缓存，其余在 CPU 上就地计算，两个部分和精确合并——无近似、无路由器修改。两条带宽都在部署机器上实测（ft bench bw），这很关键：RTX 5090 服务器上测得的 B_P:B_H 为 52.7:77.3，但 4060 笔记本上为 11.8:47.5。

语义感知缓存：在 prefill 期间，完整层双缓冲在 GPU 计算第 l 层时流式传输第 l+1 层。循环状态检查点锚定在特殊 token 边界——思考块、工具调用、工具输出——正是 Agent harness 截断上下文的位置，因此编辑只需重新 prefill 新的后缀。在解码期间，跨所有 MoE 层的共享 LRU 专家缓存跟随路由器，而非在加载时冻结的放置策略。

弹性内存管理：在调度器安全点，GPU 专家缓存在修订后的 VRAM 预算下重建，无需重启引擎或重新加载主机池。专家从磁盘直接读取到最终主机布局，然后固定；不需要 GPU 预热，因为第一次请求是在冷缓存下服务的。

在 RTX 5090 上，FreeToken 在 Qwen3.6-35B-A3B（BF16）上持续保持 77–83 tok/s，在 DeepSeek-V4-Flash（MXFP4）上保持 22–25 tok/s——最强基线的 1.5–2.3 倍，解码在三个 Agent 工作负载中保持在单轮速率的 12% 以内。最坏情况 TTFT 在每个测试格中都低于 44 秒；llama.cpp 达到 232 秒，Ollama 179 秒，KTransformers 在某个测试格中达到 946 秒，已超过 Agent 客户端超时阈值。

在相同缓存容量下（Qwen3.6 池的 37%），全局 LRU 的解码时专家读取未命中率为 16%，而 KTransformers 为 41%，llama.cpp 为 62%。在 8GB RTX 4060 笔记本上，NVFP4 版本以 39.3 tok/s 提供 35B 服务——超过了生产追踪中测得的 Codex 中位解码速度 33 tok/s。在单块 RTX PRO 6000 上，GLM-5.2（753B，40B 活跃）运行速度为 14.9 tok/s，而 llama.cpp 为 7.3 tok/s。

这篇论文在算术上是干净的——每个发布的比率都从自身数据重新计算得出。

目前没有任何独立复现；16 项声明中有 9 项因必要性而自我报告，非刻意回避。

最值得注意的旗帜：39.3 tok/s 击败了 Codex 标准化后的 33.9，而非其纯解码中位数 57.1。

"单 GPU"标题悄然需要 192–512 GB 主机 DRAM。

基线 KTransformers 以 6 个 CPU 线程运行，低于其所针对的众核 AMX 配置。

FreeToken 使用实测带宽（而非固定卸载规则）在 PCIe 填充和 CPU 执行之间分割 MoE 缓存未命中。

专家输出保持位精确——无路由器更改、无专家替换、无精度放松。

比 llama.cpp、Ollama 和 KTransformers 的解码吞吐量高 1.5–2.3 倍，尾部 TTFT 在 44 秒以下。

8GB 笔记本 GPU 上 35B 达到 39.3 tok/s；单块工作站 GPU 上运行 753B GLM-5.2。

Apache-2.0，发布于 PyPI 和 Windows/Linux 桌面应用——今天下午即可部署。

查看论文、GitHub 仓库和项目。也请关注我们的 Twitter，别忘了加入我们 15 万+的 ML SubReddit 并订阅我们的通讯。等一下！你用 telegram 吗？现在你也可以加入我们了。

需要与我们合作推广你的 GitHub 仓库或 Hugging Face 页面或产品发布或网络研讨会等？请联系我们

Asif Razzaq 是 Marktechpost Media Inc. 的首席执行官。作为一位有远见的企业家和工程师，Asif 致力于利用人工智能的潜力造福社会。他最新的事业是推出了一个人工智能媒体平台 Marktechpost，该平台以深度报道机器学习和深度学习新闻而著称，既具有技术深度又易于被广大受众所理解。该平台每月浏览量超过 200 万次，展示了其在受众中的受欢迎程度。