FreeToken：加州大学伯克利分校与麻省理工学院开源的推理引擎可在单个消费级GPU上运行7530亿参数的MoE模型

FreeToken颠覆了传统假设——即模型必须完全装入GPU内存。它将所有权重保留在系统RAM中，而将GPU视为全局LRU缓存，仅保存当前token所路由经过的“热点”专家模块^[2]。由于MoE模型每个token只激活一小部分专家模块，因此在一次前向传播过程中，7530亿参数模型的大部分根本无需加载到GPU上，这正是实现数百亿乃至千亿级参数模型在8–96GB显存卡上推理的核心技巧。

更难的工程问题是隐藏专家模块进出缓存所带来的延迟。FreeToken在首次运行时对PCIe和CPU内存带宽进行一次基准测试，然后根据特定机器的实际性能动态分配缓存未命中任务——在PCIe传输路径和CPU侧执行之间按实际更快的一方比例拆分^[3]。预填充（prefill）和解码（decode）被视为两个独立的带宽问题：预填充使用全层双缓冲流式处理来重叠权重加载与计算过程，而解码则依赖自适应LRU缓存；此外，VRAM可在专家缓存和KV缓存之间于运行时重新分配，无需重启引擎。正如一段对该代码库的技术解析所指出的那样，真正的瓶颈从来不是原始算力，而是专家权重何时、何地移动。

围绕FreeToken发布的每一篇媒体报道和社交媒体内容都在讲述同一个简洁的故事：比Ollama快2–4倍，在单张显卡上运行7530亿参数模型的速度几乎是llama.cpp的两倍。这一叙事几乎完全来自论文自身的基准表格及研究人员自己的社交发文。最详尽的独立审查出现在Reddit的r/LocalLLaMA论坛中，最初是一篇热情的实测报告，后来演变为一场尖锐的方法论争论。

核心质疑点包括：未披露llama.cpp基线版本提交记录或运行标志、未说明显著影响llama.cpp卸载性能的调优选项、仅提供单次运行数据且无波动范围报告、以及未能明确承认此前llama.cpp在卸载方面的先驱工作。最尖锐的指控——FreeToken项目自身的GitHub拉取请求显示，其基于带宽的混合执行启发式策略在某些配置下表现不如纯CPU执行——恰恰源自该项目内部仓库，而非外部评测。一项独立复现确实发现了在相同硬件条件下比llama.cpp快2.2–3.1倍的解码速度提升，但冷启动首token延迟显著更长（21.7秒对比4.7秒），这种权衡在headline数字中并未提及。

论文自身的论述很直接：开源权重的前沿模型不断发布，但服务于它们的基础设施仍默认处于数据中心环境^[1]。随着MoE模型的总参数量突破任何单个消费级GPU所能容纳的极限，而每个token所需激活的专家数量却保持较小，这一鸿沟正在扩大。

传统的CPU-GPU卸载技术早已存在，但它始终受限于PCIe带宽，因为它假设互联通道是唯一关键变量^[1]。FreeToken的贡献在于测量给定机器的实际可用带宽——无论是PCIe还是主机内存，并据此调整执行路径的分配比例——这个看似微小的想法，当决定因素是从可响应聊天机器人到卡顿界面之间的几秒延迟时，变得至关重要。

8GB显存的headline掩盖了一个真实成本：运行最大支持配置仍需约512GB系统内存，因为现在这些内存承担了原本由GPU完成的工作^[4]。FreeToken所描绘的分级硬件图景——8GB笔记本GPU支持350亿参数、32GB桌面显卡支持2840亿参数、96GB工作站显卡支持7530亿参数——只有在对应主机具备足够系统内存的情况下才成立^[5]。

社区测试揭示了公告未强调的多个粗糙之处：目前引擎仅支持CUDA，尚无Vulkan路径，对AMD显卡或Apple Silicon的支持不确定，最佳性能绑定于官方NVFP4量化检查点，而非大多数本地大模型用户磁盘上已有的GGUF或EXL3格式。测试者还总结出一条与GPU无关的实用建议：DDR5内存速度（不仅仅是容量）对实际吞吐量有不成比例的影响，因为每次缓存未命中都需往返系统内存，而非停留在显卡上。