FreeToken AI 评测：消费级 GPU 能跑前沿 MoE 大模型吗？

FreeToken 是一款新的开源推理引擎，用一台个人电脑中的多种硬件共同运行大型 Mixture-of-Experts 模型。它把 GPU 显存当作高速专家缓存，将完整专家池保留在系统内存，再在 PCIe 传输与 CPU 计算之间分配剩余工作。在部分 NVIDIA 系统上，这能让无法整体装入显存的模型达到可交互速度。

本文评测的是 FlashML-org/FreeToken 项目，不是同名 token 服务或 SDK。内容于 2026 年 8 月 25 日完成复核。本文只承担一个明确搜索意图：FreeToken AI 的硬件要求、安装、作者 benchmark、局限和商业适用性。如果你要先判断哪个本地模型适配现有电脑，请阅读本地 LLM 硬件适配指南。

FreeToken AI 是什么？

FreeToken 是 FlashML 的 edge-native serving runtime。FreeToken 官方 GitHub 仓库列出了消费级笔记本、游戏台式机和工作站 GPU 支持，并为 coding agent 与工具调用 agent 提供 OpenAI 和 Anthropic 兼容 endpoint。代码采用 Apache 2.0 许可。

它主要面向稀疏 MoE 模型。MoE checkpoint 拥有很多专家网络，但 router 每个 token 只激活少量专家。因此，生成一个 token 的实际计算量可以远小于总参数量。难点在于内存：即使大部分专家不活跃，全部权重仍需要存放位置。

FreeToken 把整台电脑视为一个推理系统。非专家权重和高频专家留在 GPU，完整专家池留在 host RAM。缓存未命中时，要么通过 PCIe 传输后由 GPU 计算，要么直接在 CPU 上执行。

FreeToken 如何运行超过 GPU 显存的模型？

FreeToken 研究论文描述了五个配合机制：

1. 共享 GPU 专家缓存：用 LRU 跟踪最近使用的层与专家组合，而不是在启动时固定全部放置。
2. 带宽自适应执行：根据真实机器的测量结果，在 PCIe 传输加 GPU 计算与 CPU 直接计算之间分配 miss。
3. Pipeline prefill：两个层 buffer 将专家传输与 GPU 计算重叠，减少长 prompt 的显性等待。
4. 语义 state anchor：在工具调用、thinking block 和会话边界保存 checkpoint，让 agent 编辑历史后仍能复用更多上下文。
5. 弹性内存池：当上下文变长时，runtime 可在专家缓存与 KV cache 之间重新分配显存，无需重载 host 专家池。

这不是说 284B 或 753B checkpoint 真的装入了一块小 GPU。完整模型仍需要 host RAM 或存储。FreeToken 的目标是在每个阶段把工作放到合适的 GPU、CPU 和互连路径，使活跃路径保持高速。

FreeToken 的硬件要求是什么？

当前FreeToken 安装要求包括 Linux x86_64、NVIDIA GPU、r580 或更新驱动、CUDA 13 与 Python 3.10 或更新版本。CUDA kernel 在首次使用时 JIT 编译，因此需要 CUDA 13 toolkit 与 nvcc。

这些只是软件门槛，不代表任意模型都能适配。容量规划还要考虑：

• 系统内存：完整专家池、runtime 分配和操作系统都需要空间。
• 显存：需容纳非专家权重、KV cache、执行 buffer 和有效专家缓存。
• 高速存储：需容纳 checkpoint、可选 FTW 转换权重、cache 和 rollback 空间。
• Host 带宽：CPU 内存带宽与 PCIe 带宽会直接改变 miss 分配。
• 供电与散热：持续的本地 agent 会长时间使 CPU、GPU 和内存处于负载中。

这张表是已测试配置的证据，不是采购清单。笔记本使用官方 NVFP4 模型，较大系统的部分对比使用了不同格式。架构、量化、上下文、agent 轨迹、RAM、CPU 带宽和 PCIe 代际都会影响结果。

FreeToken 支持哪些模型和 backend？

官方支持模型列表目前包括部分 DeepSeek-V4-Flash、GLM-5.2、GLM-4.7、Qwen3.6、Qwen3.5、Qwen3-MoE、gpt-oss、Gemma-4、MiniMax-M2.5 和 Muse-Glimmer checkpoint。兼容性取决于架构与格式。多模态 checkpoint 目前只提供文本输出。

MoE backend 可设为 fused、offload、cpu、hybrid 或 auto。Fused 需要专家装入显存。Offload 从 host RAM 传输 miss。CPU 在原位计算 miss。Hybrid 将两条路径重叠。Auto 默认 offload，带宽 benchmark 建议后可选 hybrid。

这份列表会快速变化。每次 eval 都应固定 FreeToken 版本、模型仓库、精确 revision、量化和许可。引擎的 Apache 许可不能取代模型许可和使用条款。

FreeToken benchmark 值得信任吗？

论文评估了六套系统、两个主要 MoE、四类 agent 工作负载和四个 baseline 引擎。作者报告 RTX 5090 上 Qwen3.6-35B-A3B 为 77 至 83 token/s，DeepSeek-V4-Flash 为 22 至 25 token/s。在五套消费级系统上，FreeToken 据报比最强的可用 baseline 快 1.3 至 2.1 倍。测试单元中最差的 time to first token 低于 44 秒，而每个 baseline 都在某处超过 150 秒。

这比单次短 prompt 截图更有参考价值，因为它包含 coding agent、工具调用、长上下文和尾延迟，并尽量对齐了模型格式。但这仍是 v1 arXiv preprint，数据来自项目作者。Wavect 没有复现本文中的 GPU 结果。它们是开展 benchmark 的充分理由，不是 SLA 保证。

FreeToken 对比 Ollama、AirLLM 和较小常驻模型

当模型是 sparse，且 agent 上下文导致反复 prefill 时，FreeToken 最有价值。如果较小的量化 dense 模型已能完全常驻显存并达到质量与延迟目标，它就没有那么必要。模型选择仍需要单独决策。如需具体案例，请阅读DeepSeek V4 Flash 本地部署指南。

如何安装和测试 FreeToken？

FreeToken 官方 quick start提供 OpenAI 和 Anthropic 兼容 endpoint。最小评估路径如下：

uv venv
source .venv/bin/activate
uv pip install "freetoken[accel]"
ft bench bw
ft serve --model Qwen/Qwen3.6-35B-A3B

然后检查 /v1/models，发送一个短 completion，最后再连接 agent。CLI 可将 Codex、Claude Code、OpenCode、OpenClaw 等 harness 指向本地服务。先执行 ft launch ... --dry-run，在应用前检查配置变更。

不要从最大 checkpoint 开始。先选最小但能代表目标负载的支持模型。记录下载大小、cold start、time to first token、prompt throughput、decode 速度、峰值显存、峰值内存、上下文容量、功耗与故障行为。

本地推理真的免费吗？

本地请求不会产生托管 provider 的 token 费用，但不等于零成本。每个通过验收的任务应计入硬件折旧、RAM、NVMe、电力、散热、工程时间、监控、模型更新、安全控制、停机、闲置容量与 fallback。

对已有工作站的单个开发者，边际成本可能接近零。面向客户的产品通常由冗余和利用率主导。用相同 prompt、工具调用、成功标准和并发来比较 FreeToken 与拟替代 API。如果模型无法完成任务，或服务器无法达到延迟目标，所谓免费 token 没有商业价值。

什么时候开展 FreeToken 试点才有商业意义？

• 持续 agent 负载：反复 coding 或工具调用产生足够 token 量，能支撑自有基础设施。
• 本地控制：数据位置、离线运行或稳定访问比即时切换模型更重要。
• 现有硬件：公司已拥有合适 NVIDIA 设备、足够 host RAM 和高速存储。
• 受支持 MoE 的质量：某个支持模型在真实任务 eval 中胜过现有 API。
• 明确工程责任：有人负责 patch、模型 revision、可观测性、认证与恢复。

如果需求低或波动大，产品必须始终使用最新 frontier 能力，硬件固定为 Apple 或 AMD，必须多模态 serving，或团队无法运维本地推理服务，则应选托管 API 或较小常驻模型。混合架构往往是更安全的商业默认：可预测的私有任务用本地推理，难任务或过载请求使用受控 cloud fallback。

生产就绪检查清单

1. 固定所有产物：FreeToken commit 或 release、模型 ID、revision、量化、CUDA、驱动与依赖。
2. 执行任务 eval：比较通过验收的任务比例，而不是参数量或通用 leaderboard。
3. 测量 agent trace：包含长上下文、工具调用、并发、retry 和历史压缩。
4. 保护 endpoint：除非确实要建立受保护网络服务，否则保留默认 loopback binding。远程访问前添加认证、授权、rate limit 和 audit log。
5. 观测全部瓶颈：记录队列、prefill、首 token、decode、cache hit、RAM、VRAM、存储和功耗。
6. 测试内存压力：验证其他应用占用 VRAM 或 KV cache 增长时的行为。
7. 规划故障与 fallback：为模型加载失败、timeout、低质量、过载和 host 中断定义处理。
8. 重算总成本：在采购硬件前，用实测利用率和成功任务计算。

如需理解上下文性能问题，请阅读多轮 LLM 推理的共享 KV cache 延迟分析。FreeToken 增加了语义 anchor 和弹性 cache 分配，但产品仍需要围绕 agent harness 进行端到端测量。

资料边界

功能、许可与广泛硬件支持来自 FreeToken 官方仓库。架构与 benchmark 数据来自作者的 arXiv 论文。软件前置条件来自安装指南。模型与 backend 兼容性来自模型文档。命令与 API 兼容性来自 quick start。Wavect 没有复现论文的硬件 benchmark，也不声称完成了独立验证。项目支持、模型和要求可能在复核日期后改变。