FreeToken：让消费级GPU本地运行290B+ MoE模型
FreeToken让开发者在消费级GPU上本地跑290B+ MoE，区别是把CPU、GPU和内存做成弹性推理平台。
GitHub FlashML-org/FreeToken 更新 2026-09-22 分支 main 星标 13.6K 分叉 1.3K
Python/CUDA/C++ 边缘推理 DeepSeek-V4-Flash NVIDIA RTX 30/40/50

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你有NVIDIA RTX 30、40或50系列，想在本地运行DeepSeek-V4-Flash等MoE模型。
    README 的“Diverse Consumer Hardware”和“Broad MoE & Ecosystem Support”列出RTX 30/40/50及DeepSeek-V4-Flash。
  • 你的代理使用Codex、Claude Code或OpenCode，并需要Anthropic/OpenAI兼容API。
    README 的“Broad MoE & Ecosystem Support”明确列出这些代理和Anthropic/OpenAI-compatible APIs。
  • 你需要在tool calls或thinking blocks发生后减少上下文重算。
    README 的“Semantic-Aware Caching”说明semantic anchor checkpoints可避免agentic context edits后的冗余重算。
  • 你希望在不重启引擎或重新加载权重的情况下调整VRAM用途。
    README 的“Elastic Memory Management”明确支持expert caches与KV memory之间的运行时VRAM重分配。

不适合，如果你

  • 你的GPU不属于README列出的NVIDIA RTX 30、40或50系列。
    README 的“Diverse Consumer Hardware”只明确写出NVIDIA RTX 30、RTX 40和RTX 50原生支持。
  • 你需要稳定版而不是Nightly rolling版本。
    项目元数据将最新版本标为“Nightly (rolling)”，版本发布数为3个。
  • 你需要已有的显存占用、吞吐、延迟或输出质量基准。
    README正文只写“290B+”和“blistering interactive speeds”，没有给出对应数值基准。
  • 你需要README已明确支持的非MoE模型或非列出的量化格式。
    README重点描述frontier open-weight MoE模型，并举例MXFP4、NVFP4、FP8和BF16；未说明其他范围。

前置条件

  • 硬件：README写明原生支持“NVIDIA RTX 30, RTX 40, and RTX 50 series GPUs”。 / Hardware: The README states native support for “NVIDIA RTX 30, RTX 40, and RTX 50 series GPUs.”
  • 桌面端：README提供“Windows or Linux”下载。 / Desktop: The README offers downloads for “Windows or Linux.”
  • CLI安装：README推荐使用uv或pip，并给出“uv pip install "freetoken[accel]"”。 / CLI installation: The README recommends uv or pip and provides “uv pip install "freetoken[accel]".”
  • 模型与格式：README列出DeepSeek-V4-Flash、Qwen3.6-35B-A3B、GLM-5.2，以及MXFP4、NVFP4、FP8、BF16。 / Models and formats: The README lists DeepSeek-V4-Flash, Qwen3.6-35B-A3B, GLM-5.2, and MXFP4, NVFP4, FP8, BF16.

第一步命令（README 原文）

uv pip install "freetoken[accel]"

要注意

  • 旧FTW checkpoint可能需要额外修复流程。
    Getting Started列出了“Repairing old FTW checkpoints”文档。
  • CLI安装包含accel额外组件，不能只按基础包名判断依赖范围。
    README的CLI命令是“uv pip install "freetoken[accel]"”。
  • 模型、量化格式和CLI细节分散在独立文档中，README要求继续查看install、quickstart、models和cli文档。
    Getting Started的“For More details”列表列出了这四份文档。

替代方案

  • SGLang：如果你的现有系统已经围绕SGLang构建，README没有提供迁移或性能比较依据，无法进一步判断。
    README 的“Acknowledgment”
  • vLLM：如果团队已有vLLM集成，README只说明FreeToken学习并复用了vLLM代码，未说明何时更好。
    README 的“Acknowledgment”
  • llama.cpp：如果目标是采用README列出的llama.cpp生态，材料没有提供FreeToken与其的功能或性能对比。
    README 的“Acknowledgment”

材料未说明

  • README没有说明最低显存、系统内存、CPU型号或磁盘空间要求。 / The README does not specify minimum VRAM, system RAM, CPU models, or disk space.
  • README没有给出RTX 30/40/50各型号对应的吞吐、首Token延迟或并发数据。 / The README provides no throughput, time-to-first-token, or concurrency data for individual RTX 30/40/50 models.
  • README没有说明Windows与Linux在CUDA、驱动或功能上的差异。 / The README does not explain CUDA, driver, or feature differences between Windows and Linux.
  • README没有列出完整的支持模型清单、模型获取方式或每种量化格式的限制。 / The README does not provide a complete model list, model acquisition procedure, or limitations for each quantization format.
  • README没有说明Nightly rolling版本的兼容性策略、回滚方式或稳定版计划。 / The README does not describe compatibility policy, rollback procedures, or a stable-release plan for the Nightly rolling version.
  • README没有提供与SGLang、vLLM、FlashInfer、LightLLM或llama.cpp的性能对比。 / The README provides no performance comparison with SGLang, vLLM, FlashInfer, LightLLM, or llama.cpp.

💡 深度解析

6
适合 我的代码代理会反复插入工具调用结果和 thinking blocks，使用 DeepSeek 或 Qwen MoE 模型时 KV Cache 会增长并挤压专家缓存；FreeToken 能否在不中断引擎的情况下处理这种变化？
适合读者： 维护长上下文代码代理和工具调用工作流、使用 DeepSeek 或 Qwen MoE 模型并受限于单机 VRAM 的应用工程师

适合，FreeToken 明确针对代理式上下文编辑和动态显存竞争设计，但它不能消除长上下文带来的 KV 内存增长。

  • 语义锚点检查点可保存并复用循环状态和 KV Cache，README 明确举例包括 tool calls 和 thinking blocks。
  • 引擎支持运行时在专家缓存与 KV memory 之间重新分配 VRAM，且无需重启引擎或重新加载权重。
  • 全局 LRU 专家缓存可减少专家权重反复加载，适合 MoE 请求中上下文持续变化的情况。

README 没有说明缓存命中率、重新分配触发策略、最大上下文长度或在 KV Cache 持续增长时的失败行为，因此无法保证具体代理工作流始终保持目标延迟。

  • About：semantic anchor checkpoints for recurrent state and KV caches
  • About：agentic context edits (e.g., tool calls, thinking blocks)
  • About：dynamic, runtime VRAM re-allocation between expert caches and KV memory without engine restarts or weight reloading
  • About：global LRU expert caching
uv pip install "freetoken[accel]"
材料未说明：语义锚点的创建、失效和命中判定规则；专家缓存与 KV memory 动态分配的触发阈值；最大支持上下文长度及 KV 内存不足时的错误处理
适合 我正在使用 Claude Code 和 OpenCode，并希望把本地 DeepSeek 或 GLM MoE 模型接到代码代理中；我需要 Anthropic/OpenAI 兼容接口和工具调用场景，FreeToken 是否适合？
适合读者： 正在把本地模型接入 Codex、Claude Code 或 OpenCode 的代码代理工程师，需要工具调用和上下文编辑

适合，README 直接把代码代理和工具调用列为兼容 API 的目标场景，但兼容性仍限于文档明确覆盖的接口行为。

  • 项目提供 Anthropic 和 OpenAI 兼容 API，并明确列出 Codex、Claude Code、OpenCode、OpenClaw 与 DeepSeek Harness。
  • 语义锚点检查点可复用循环状态和 KV Cache，针对工具调用、思考块和上下文编辑减少重复计算。
  • 支持全局 LRU 专家缓存与动态 VRAM 在专家缓存和 KV 内存之间重新分配，适合代理请求中上下文不断变化的工作负载。

README 没有说明所有工具调用协议、流式事件、停止条件、错误格式是否与云端服务完全一致，也未提供代理端到端延迟数据。

  • About：Anthropic/OpenAI-compatible APIs ... Codex, Claude Code, OpenCode, OpenClaw, DeepSeek Harness
  • About：semantic anchor checkpoints for recurrent state and KV caches
  • About：agentic context edits (e.g., tool calls, thinking blocks)
uv pip install "freetoken[accel]"
材料未说明：与 Codex、Claude Code 和 OpenCode 的逐项协议兼容性；流式输出、并发工具调用和函数参数错误时的实际行为
适合 我正在 RTX 30、40、50 系列设备上研究 CPU–GPU 协同执行，需要比较 MXFP4、NVFP4、FP8 和 BF16 的 MoE 推理路径；FreeToken 是否适合作为实验对象？
适合读者： 研究 NVIDIA RTX 30、40、50 系列设备上 CPU–GPU 协同 MoE 推理的研究人员，需要比较 MXFP4、NVFP4、FP8 和 BF16

适合，FreeToken 的架构和公开支持范围与这类实验高度匹配，尤其适合研究带宽、专家缓存和异构资源调度之间的关系。

  • README 将 GPU、CPU、主机内存和互联作为统一、弹性的推理平台。
  • 运行时使用带宽自适应的 CPU–GPU 协同执行 q* policy，并提供全层双缓冲预填充、全局 LRU 专家缓存和图兼容执行。
  • README 明确列出 MXFP4、NVFP4、FP8、BF16，以及 RTX 30/40/50 系列硬件。
  • Apache License 2.0 允许研究用户集成、修改和再发布。

不过，README 没有给出 q* 策略细节、各格式的算子覆盖、基准数据或可重复实验脚本，因此不能仅凭项目介绍完成严谨的定量比较。

  • About：heterogeneous edge resources—GPUs, CPUs, host memory, and interconnects—as a unified, elastic inference platform
  • About：bandwidth-adaptive CPU–GPU co-execution (q* policy)
  • About：MXFP4, NVFP4, FP8, BF16；NVIDIA RTX 30, RTX 40, RTX 50
  • License：Apache License 2.0
git clone https://github.com/FlashML-org/FreeToken.git && cd FreeToken
uv venv && source .venv/bin/activate
uv pip install -e ".[accel]"
材料未说明：q* policy的输入、决策逻辑和可调参数；每种精度格式的算子支持、模型转换流程和基准测试方法；不同 PCIe 或互联带宽下的可复现实验数据
视情况 我只有一台配备 NVIDIA RTX 40 系列显卡的个人游戏电脑，但想本地运行 290B 以上的 DeepSeek、Qwen 或 GLM MoE 模型，FreeToken 适合吗？
适合读者： 拥有 NVIDIA RTX 40 系列显卡、希望在个人游戏电脑上运行 290B+ 开放权重 MoE 模型的本地 AI 开发者

视情况，FreeToken 的目标正是把 290B+ MoE 模型带到消费级硬件上，但能否实际运行取决于整机资源，而不只是显卡型号。

  • README 明确支持 NVIDIA RTX 30、40、50 系列，并将 GPU、CPU、主机内存和互联视为统一资源。
  • 项目列出 DeepSeek-V4-Flash、Qwen3.6-35B-A3B、GLM-5.2，以及 MXFP4、NVFP4、FP8、BF16 格式。
  • CPU–GPU 协同、全局 LRU 专家缓存和动态 VRAM 重分配，针对的正是显存不足与专家搬运问题。

README 没有给出具体显存、主机内存、磁盘空间或 PCIe 带宽门槛，也没有保证每种 RTX 40 配置都达到交互速度。

  • About：Run 290B+ frontier MoE models locally on your gaming PC
  • About：native support for NVIDIA RTX 30, RTX 40, and RTX 50 series GPUs
  • About：DeepSeek-V4-Flash, Qwen3.6-35B-A3B, GLM-5.2；MXFP4, NVFP4, FP8, BF16
uv pip install "freetoken[accel]"
材料未说明：目标模型在具体 RTX 40 型号、主机内存和存储配置上的最低要求；不同量化格式下的实际首 Token 延迟和生成速度
视情况 我需要在 Windows 或 Linux 工作站上运行 FreeToken，团队希望先用桌面 GUI 管理模型，再用 CLI 自动化；项目当前只有 3 个 release 且最新标记为 nightly，这种部署方式是否稳妥？
适合读者： 需要在 Windows 或 Linux 工作站上部署本地模型服务、但团队主要使用 GUI 和 CLI 而非自行编译推理引擎的开发者

视情况，启动路径对 Windows/Linux 用户友好，但 nightly 状态和较少的正式 release 使长期稳定性仍需谨慎判断。

  • README 提供 Windows 和 Linux 桌面应用，GUI 可负责引擎设置、运行模型、聊天和调优。
  • CLI 支持 uv 或 pip 安装，并提供安装、Quick Start、模型和 CLI reference 文档。
  • 项目数据只有 3 个 release，最新 release 标记为 nightly；这说明底层接口、权重格式或运行行为可能仍在变化。
  • README 还提供旧 FTW checkpoint 修复文档，表明权重格式管理需要关注版本兼容。

README 没有给出稳定性承诺、版本固定流程、升级回滚方案或 Windows/Linux 的功能差异，因此不宜仅凭 GUI 易用性判断生产部署风险。

  • Getting Started—Desktop app：Download FreeToken for Windows or Linux
  • Getting Started—CLI：Install FreeToken with uv (recommended) or pip
  • 项目数据：release_count 为 3，latest_release 为 nightly
  • Getting Started：Repairing old FTW checkpoints
uv pip install "freetoken[accel]"
材料未说明：nightly 版本的发布频率、破坏性变更策略和回滚方式；桌面应用与 CLI 在模型、缓存和调优功能上的差异；Windows 与 Linux 的 CUDA、驱动和硬件兼容矩阵
适合 我计划把 FreeToken 集成到一个商业化的本地 AI 产品中，并可能修改 Python、CUDA、C++ 和 C 代码后再发布；Apache License 2.0 是否满足这个许可约束？
适合读者： 希望把本地 MoE 服务嵌入商业软件、需要允许修改和再发布推理组件的企业研发工程师

适合，项目采用 Apache License 2.0，通常允许企业集成、修改和再发布；但第三方依赖和商标义务仍需单独核查。

  • 项目数据明确标注许可证为 Apache License 2.0。
  • README 的 License 章节直接链接到 Apache License 2.0 文本，许可信息不是仅存在于项目描述中。
  • 项目由 Python、CUDA、C++、C 和 Shell 组成，因此企业集成时会涉及运行时、原生扩展和构建脚本，而不只是 Python 包。
  • README 的 Acknowledgment 列出 SGLang、vLLM、FlashInfer、LightLLM、llama.cpp 等受启发或复用代码的项目。

README 没有逐项列出第三方代码的许可证、NOTICE 文件要求、专利条款适用范围或模型权重许可，因此不能仅凭 Apache License 2.0 判断整个产品的合规性。

  • 项目数据：license 为 Apache License 2.0
  • License：Apache License 2.0
  • 项目数据：Python、CUDA、C++、C、Shell
  • Acknowledgment：SGLang、vLLM、FlashInfer、LightLLM、llama.cpp
材料未说明：所有第三方依赖和复用代码的完整许可证清单；模型权重、量化文件和 FTW 文件的单独许可条件；项目是否随发行包提供 NOTICE 或其他归属文件

✨ 核心亮点

  • 支持消费级硬件运行290B+ frontier MoE模型
  • q★策略实现CPU–GPU带宽自适应协同推理
  • 语义锚点缓存减少tool calls后的上下文重算
  • 运行时在expert cache与KV memory间重分配VRAM
  • Nightly滚动版本且仅有3个版本发布记录

🔧 工程化

  • 提供MoE serving运行时，支持DeepSeek-V4-Flash与GLM-5.2
  • 兼容Anthropic/OpenAI API，可接入Codex和Claude Code
  • 桌面应用覆盖Windows、Linux，CLI支持uv安装
  • FTW格式、全局LRU expert cache支持高效MoE执行

⚠️ 风险

  • 最新版本为Nightly rolling，发布记录仅3个
  • 材料只列NVIDIA RTX 30、40、50原生支持
  • README未给出290B+模型的显存、速度与质量数据
  • 项目仅7名贡献者，维护与响应能力无法由材料确认

👥 适合谁？

  • 需要在RTX 30/40/50上运行DeepSeek-V4-Flash的开发者
  • 构建Codex、Claude Code等工具调用代理的团队
  • 希望用Windows或Linux桌面运行290B+ MoE模型的用户
  • 需要MXFP4、NVFP4、FP8或BF16量化格式的实验者