本文基于 2026-08-22 情报快照,数据以原文为准。
摘要:FreeToken 是一个面向消费级硬件的 MoE 推理引擎,论文与代码双发,核心思路是把「带宽」而非「算力」当作第一约束:不再绑定固定卸载策略,而是把 GPU、CPU、主机内存与 PCIe 视为一块弹性平台,按需把专家权重与 KV 缓存在设备间动态摆放。论文实测,8GB 显存笔记本可跑 35B 模型,32GB 游戏台式机可交互式运行 284B 前沿 MoE,单张工作站 GPU 甚至能跑 753B 的 GLM-5.2。本文拆解其机制、实测数据与本地推理赛道的下一步。
一、FreeToken 是什么
8 月 21 日晚,HN 上一则标题为「Run 290B+ frontier MoE models locally on your gaming PC」的帖子拿到约 26 分(本文写作时点;当日 19:10 快照为 25 分),评论区近乎空白,但对应的 GitHub 仓库 FlashML-org/FreeToken 却在稳步涨星:截至本文实测(8-22 晚)937★/63 forks,而当日 19:10 快照还是 834★/53 forks。仓库创建于 2026-07-20,最近一次 push 是 08-20,Apache-2.0 协议,以 Python 为主。
同期配套论文 arXiv:2608.16157《FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution》(8-17 提交 v1,11 位作者,含 Song Han、Matei Zaharia、Ion Stoica 等系统与高效计算领域的熟面孔)。论文立场鲜明:前沿开放权重模型越来越多,但 serving 依然默认数据中心存在;FreeToken 则把个人电脑当作「统一的弹性推理平台」,而不是「一块小 GPU」。
所谓带宽自适应执行(Bandwidth-Adaptive Execution),论文描述为:不承诺任何固定卸载策略,而是围绕两个现实,持续把计算与模型状态映射到实际可用的资源上------其一,agent 工作负载的执行模式不断变化;其二,边缘硬件异构,GPU/CPU/内存/互连的配比每台机器都不一样。落实到代码,仓库把 serving 栈整体协同设计:模型布局与加载、专家驻留、CPU-GPU 协同执行、agent 状态复用、运行时内存管理。
论文与仓库配套给出了更完整的画像:支持超过 20 个 MoE 模型,并已在真实编码与工具调用 agent(如 Codex、Claude Code、OpenCode、OpenClaw、DeepSeek Harness)上验证;硬件跨度从 8GB 显存的笔记本 GPU 一直到单张工作站 GPU。对外,引擎暴露 OpenAI 兼容接口(/v1/chat/completions、/v1/responses、/v1/models)与 Anthropic 兼容接口(/v1/messages、/v1/messages/count_tokens),任何客户端库只要把 base URL 指过去即可接入。
二、为什么 MoE 特别适合「游戏 PC」
MoE 模型天然契合「稀疏激活」:参数总量 290B 级,但单个 token 只激活其中一小部分专家。问题在于,边缘设备的瓶颈不是算力,而是内存带宽与显存容量------专家权重装不进显存,每次 decode 都要从主机内存走 PCIe 搬运,带宽有多窄,吞吐就有多低。FreeToken 的做法,是把「带宽」当作第一约束来调度。
仓库文档给出 5 种 MoE 后端:auto / fused / offload / cpu / hybrid。fused 要求专家常驻显存;offload 让专家住在主机内存,GPU 上只留一个 LRU 专家槽缓存,缺失时经 PCIe 流式拉取;cpu 则是缺失专家直接在 CPU 上计算而不是搬运;hybrid 最激进------每一步同时「从 PCIe 拉一部分缺失专家」与「在 CPU 算一部分」,重叠执行,并用 ft bench bw 在每台机器上校准一次卸载比例。auto 会自动选择:稠密模型走 fused,MoE 默认 offload,若带宽画像建议则升级为 hybrid。
此外还有两个面向 agent 场景的设计:一是语义感知缓存(Semantic-Aware Caching),以「语义锚点检查点」保存循环状态与 KV 缓存,agent 的工具调用、思考块等上下文编辑不必整段重算;二是弹性内存管理,运行期可在专家缓存与 KV 内存之间动态重分配显存,不需要重启引擎或重载权重。这两点直指论文归纳的 edge serving 三大痛点:prefill 阶段专家传输随全模型规模增长、上下文重复计算;decode 阶段缓存缺失与 CPU 带宽受限;以及「边缘上没有任何资源是专用的」。
具体到运行时,论文把 prefill 与 decode 分开设计:prefill 侧是「全层双缓冲预填流式加载 + 语义感知状态缓存」------专家权重按层流水化载入,double-buffered 让加载与计算重叠;decode 侧是「语义感知专家缓存 + q* 策略」------q* 在每一步根据当前带宽画像决定哪些专家缺失从 PCIe 拉取、哪些留在 CPU 上计算,目标是最小化每一步的等待时间。仓库还引入 FTW 快速权重格式,ft checkpoint 可把检查点预转换为该格式以加速加载,同时保持 graph-compatible 执行,便于接入既有计算图框架。论文特别指出,agent 场景下「冗余重算」是隐性杀手:每次工具调用都会修改上下文,若不做语义级复用,长上下文的 prefill 会在消费级 GPU 上占用数十秒------这正是语义感知缓存的设计动机。
三、实测与复现
论文给出跨五台消费级设备的实测,并同 llama.cpp、Ollama、KTransformers、MoE-Infinity 等边缘引擎对比:
| 硬件 | 模型 | 结果 |
|---|---|---|
| 8GB RTX 4060 笔记本 | 35B | 39.3 tok/s,超过 Codex 生产轨迹 33 tok/s 中位数 |
| 32GB 游戏台式机 | 284B | 可交互式使用 |
| 单张 RTX PRO 6000 工作站 GPU | 753B GLM-5.2 | 吞吐约为 llama.cpp 的 2 倍 |
在 RTX 5090 上端到端跑四个真实 agent 工作负载(AIME、OpenCode+SWE、Claude Code+SWE、OpenClaw+Email/Cal):Qwen3.6-35B-A3B(BF16)达到 77--83 tok/s,DeepSeek-V4-Flash(原生 MXFP4)达到 22--25 tok/s,decode 吞吐比现有边缘引擎高 1.5--2.3 倍。更值得注意的是 agent 化之后的稳定性:FreeToken 的 decode 速率保持在单轮设置的 12% 以内,而对比系统显著退化;最坏情况 TTFT 全程低于 44 秒,对比基线至少在一个设置里超过 150 秒------足以触发真实 agent 客户端的超时。跨五台机器整体提升 1.3--2.1 倍。
对照同赛道的两个信号:8-21 收录的 syv-ai/qwen38-27b-rtx3090(本文实测 412★)用 vLLM 在单张 RTX 3090 上把 Qwen3.8-27B 跑到约 1,000 tok/s(64 并发)、约 114 tok/s(单用户),走的是「量化 + DeltaNet 状态压缩」配方;llama.cpp 则在 8-21 发布 v0.2.0 正式版(ggml 0.21.0)。FreeToken 与它们的关系不是竞争而是互补:README 明确致谢 mini-sglang,并声明复用了 SGLang、vLLM、FlashInfer、flash-linear-attention、LightLLM、llama.cpp 的代码------它更像一个「站在既有后端之上的边缘调度层」,直接加载 HF safetensors 与部分 GGUF,对外暴露 OpenAI/Anthropic 兼容 API,并内置 ft launch claude/codex/dsh/hermes/openclaw/opencode 一键对接真实编码 agent。
需要说明的是,对比并非完全同一起跑线:Ollama 与 MoE-Infinity 干脆不支持 DeepSeek-V4 系列,MoE-Infinity 也没有可用的多轮 agent 服务接口,因此论文图表中以「×」标记的配置直接无法参与对比。官方 README 的模型清单覆盖 DeepSeek-V4-Flash、GLM-5.2/4.7、Qwen3.6/Qwen3.5-35B-A3B、Qwen3-30B-A3B、gpt-oss-120b/20b、Gemma-4、MiniMax-M2.5、Muse-Glimmer 等,量化格式支持 MXFP4、NVFP4、FP8、BF16;文档还特别提醒,DeepSeek-V4 检查点必须保留 inference/config.json 子目录,权威模型参数从这里读取。
官方 quickstart 的真实可运行示例(需 Python 环境,uv 安装):
bash
# 安装(uv 推荐)
uv pip install "freetoken[accel]"
# 启动服务:本地目录或 HF repo id 均可
ft serve --model ~/models/Qwen3.6-35B-A3B
# 日志出现 "API server is ready to serve on 127.0.0.1:1919" 即就绪
# OpenAI 兼容调用
curl http://127.0.0.1:1919/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model": "Qwen3.6-35B-A3B",
"messages": [{"role": "user", "content": "What is a Mixture-of-Experts model?"}],
"max_tokens": 256, "stream": true}'四、本地推理赛道的下一步
HN 26 分、评论区空白,但仓库持续涨星------这个组合很像「工程可行但话题性不足」的典型:社区对「消费级硬件跑前沿模型」的耐心,正在从猎奇转向可复现。把 FreeToken 与 Qwen3.8 单卡 3090、MiniMax H3 开源 5 天即上 16GB Mac(VPIPE)放在一起看,本地推理已经分成两条清晰路线:一条继续压「小模型量化」(27B 级、千 tok/s),另一条开始啃「大 MoE 卸载」(290B 级、数十 tok/s)。FreeToken 是后一条路线的系统化样本。
但边界依然硬:论文自己承认,RTX 5090 的稠密 BF16 吞吐大约只有 H100 的五分之一、B200 的十分之一;带宽与显存容量仍是物理约束。对 API 定价与私有化部署而言,「个人机器能跑 284B/753B 级模型」意味着本地替代选项真实存在,尤其对延迟敏感、数据敏感的 agent 场景;但全量权重动辄数百 GB,加载与首次 prefill 仍是门槛。值得跟进的时间点:一是 ft bench bw 校准后的 hybrid 实测能否在不同显卡上稳定复现;二是它能否真正成为 llama.cpp/vLLM 之外的第三极边缘引擎------论文的对比对象 KTransformers、MoE-Infinity 也在快速迭代。对大多数开发者,现在最务实的动作是:拿一张 30/40/50 系显卡,跑一遍官方 quickstart,用 --moe-backend hybrid 观察自己的带宽画像------这台机器能跑什么,不再由显存大小单独决定。
另一个被低估的信号是生态位:FreeToken 内置 ft launch 子命令,会直接改写 claude/codex/dsh/hermes/openclaw/opencode 等 agent 的 provider 配置并指向本地服务------这意味着它瞄准的不是「给开发者一个 CLI 跑模型」,而是「给现有 agent 生态一个本地推理后端」。这与 DeepSeek Harness 桌面端等「入口层」产品形成对照:一个做模型侧供给,一个做 agent 侧编排。对 API 定价的传导不会一夜发生,但「本地跑 284B」一旦成为默认选项,按 token 计价的 API 服务必须用延迟、多模态与稳定性来证明自己的溢价。
总结
FreeToken 的价值不在「又一个本地推理引擎」,而在于把 MoE 卸载从「拍脑袋选策略」变成「按带宽实时决策」:稀疏激活、带宽自适应、语义感知缓存三者叠加,才让 284B 级模型在 32GB 游戏台式机上可交互。论文数据、开源代码、兼容 API 三件套齐全,是本地推理赛道「大 MoE 卸载」路线最值得复现的样本。至于「290B+ 到底是不是 284B 的四舍五入」,README 的宣传口径与论文的实测口径略有出入------这正是读论文、跑代码时值得自己验证的第一个细节。
参考链接
- FlashML-org/FreeToken(GitHub): https://github.com/FlashML-org/FreeToken
- 论文 arXiv:2608.16157: https://arxiv.org/abs/2608.16157
- HN 帖子(id=49394148): https://news.ycombinator.com/item?id=49394148
- 官网 flashml.ai: https://www.flashml.ai/
- syv-ai/qwen38-27b-rtx3090: https://github.com/syv-ai/qwen38-27b-rtx3090
- llama.cpp v0.2.0 Release: https://github.com/ggml-org/llama.cpp/releases/tag/v0.2.0
- VPIPE(16GB Mac 跑 MiniMax H3): https://github.com/tgo-app-dev/vpipe