你想在自己的游戏电脑上运行一个超大模型，难题不只是“显存装不下”。即使把模型塞进主机内存，数据在 GPU、CPU 和内存之间来回搬运，也可能让生成速度慢到无法使用。FreeToken 要解决的正是这组矛盾：既扩大桌面电脑能承载的模型容量，又尽量保住吞吐——也就是单位时间内生成内容的速度。
项目方 FlashML-org 将它称为“边缘原生”推理引擎。推理引擎是不负责训练、只负责加载模型并执行生成计算的软件；边缘原生则表示计算主要留在个人设备，而非远端数据中心。项目宣称，FreeToken 能在游戏 PC 上运行参数量超过 290B（2900 亿）的前沿 MoE 模型。不过，目前全部性能说法都来自项目自己的 GitHub 说明，没有论文正文、第三方基准或可复现实验数字支撑。
把整台电脑当成一台机器
MoE，即 Mixture-of-Experts（混合专家模型），可以粗略理解为模型内部有许多“专家”模块，每次计算只调用其中一部分。它减少了单次生成需要参与计算的参数，但全部权重依然要有地方存放。桌面显卡的显存有限，于是容量和速度很容易顾此失彼。
FreeToken 的核心思路，是把 GPU、CPU、主机内存以及连接它们的总线视为一套统一资源，而不是只盯着显存。项目称，其 策略会根据带宽调整 CPU–GPU 协同执行；同时使用双缓冲的全层预填充流式处理、全局 LRU 专家缓存、兼容计算图的执行方式，以及名为 FTW 的快速权重格式。
这些名词指向同一个目标：哪些权重应该留在速度最快但空间最小的显存里，哪些可以暂存在主机内存，什么时候搬运，如何让搬运与计算尽量重叠。遗憾的是，项目说明没有给出 的具体决策方法，也没有披露各项设计分别带来多少收益。
缓存也能随任务变化
模型处理长上下文时，会保存 KV cache——可以把它看成阅读过程中留下的中间笔记，之后生成时不必从头重算。MoE 模型还需要缓存可能反复调用的专家权重。两类缓存都要争夺有限的显存。
FreeToken 宣称可以在运行时动态调整专家缓存和 KV memory 的显存份额，不必重启引擎，也不用重新加载权重。它还提出 semantic anchor checkpoints（语义锚点检查点），缓存 recurrent state（循环状态）和 KV cache。项目方称，当代理插入工具调用结果或修改 thinking blocks（思考过程块）时，引擎可以从合适的锚点继续，而不是重复计算整段上下文。
这对编程代理尤其有吸引力。此类工具经常在对话中调用外部工具，再把结果插回上下文。FreeToken 提供项目方所称的 Anthropic/OpenAI-compatible APIs，并列出 Codex、Claude Code、OpenCode、OpenClaw 和 DeepSeek Harness 等接入对象。但这里的“兼容”仍是项目自述，材料没有说明功能覆盖程度。
为什么值得关注
FreeToken 把数据中心推理系统积累的调度与缓存思路带回个人电脑。项目作者包括长期参与 Spark、Ray、vLLM 等系统的 Ion Stoica、Matei Zaharia，以及研究模型压缩和专用硬件的 Song Han。项目也明确表示，其设计或代码借鉴了 SGLang、vLLM、FlashInfer、LightLLM 和 llama.cpp 等项目。
项目方列出的模型包括 DeepSeek-V4-Flash、Qwen3.6-35B-A3B 和 GLM-5.2，并声称支持 MXFP4、NVFP4、FP8、BF16 等数值格式，以及 NVIDIA RTX 30、40、50 系列 GPU。Windows 和 Linux 均有版本。若这些能力能在常见配置上达到实用速度，本地用户确实可能用更少的远端服务完成大型模型推理。
局限与未知
- “可运行 290B+”不等于“运行得实用”。材料没有给出显卡、内存、模型精度、上下文长度、并发量、每秒 token 数、延迟或对照基线。
- 项目引用论文《FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution》，编号为 arXiv:2608.16157、标注年份为 2026，但供稿未包含论文页面或正文，实验和发布状态无法独立确认。
- 因此，“桌面挑战数据中心推理”目前更适合作为待验证的方向，而不是已经成立的结论。FreeToken 最值得看的，是它如何重新分配桌面硬件；最需要补上的，则是一套透明、可复现的真实机器测试。