FreeToken：消费级机器不是缩水的服务器，是异构资源

它换掉的是一个看法

稀疏 MoE 每处理一个 token 只计算一小部分参数，但解码仍然要在数千亿个未激活权重之间做路由。数据中心里 NVLink 这类高带宽互连可以把专家权重的传输开销掩盖过去；消费级机器上掩盖不住——PCIe 吞吐通常只有 16 到 64 GB/s，加上主机内存延迟，这就成了解码瓶颈。现有的边缘运行时依赖静态专家卸载：未激活权重放在系统内存里，一旦被激活就同步传到 GPU，而缓存未命中时整个执行过程完全停顿。

FreeToken 的前提是换一个看法：个人电脑不是资源受限的数据中心节点，而是一组可弹性调度的异构资源。具体做法有三层：

• 动态协同调度（论文称 q* 策略）：缓存未命中时不让 GPU 停下来等，而是按实时互连吞吐，在 CPU 核心与 GPU 张量核心之间分配 token 计算任务。
• 快速权重格式加整层双缓冲：让权重经 PCIe 传输的过程与活跃计算层的执行完全重叠。
• 弹性内存管理器：运行期间动态调整显存在 KV 缓存条目与常驻专家槽位之间的配比，不需要重新加载模型。

对照它自己给出的定位：Ollama 和 llama.cpp 针对量化与逐层卸载优化，但无法在主机与设备之间动态分配稀疏专家负载；vLLM 与 SGLang 针对数据中心吞吐优化，其设计假设是高带宽互连而不是异构内存层次；KTransformers 采用静态卸载规则，而 FreeToken 实时计算每一层的闭式最优分配。

为智能体准备的那一半

这一半比吞吐数字更值得记。编程助手和自主智能体的执行模式很特别：频繁修改提示词、把工具调用结果塞回上下文、生成思考块——上下文窗口一直在变。而前缀一变，标准引擎就会丢弃线性 KV 缓存，触发代价高昂的完整序列重计算。

FreeToken 加了语义锚点检查点：在逻辑任务边界上缓存中间注意力状态与循环激活值。于是当智能体修改某个中间工具参数或插入一段外部执行结果时，它可以复用已有的子序列状态，而不必让整个提示词缓存失效。

这与本站《长时程智能体的记忆与上下文管理》讲的是同一件事，只是落在了推理引擎这一层。

数字，以及围绕数字的争论

论文报告的结果：在配 8GB 显存 RTX 4060 的笔记本上跑 Qwen3.6-35B，约每秒 39 个 token；在 RTX 5090 台式机上跑了 DeepSeek-V4-Flash（284B）；在单块工作站 GPU 上跑了 GLM-5.2（753B）。相同 MoE 模型上，解码比 Ollama、llama.cpp 一类运行时快 3 到 4 倍，预填充快 6 到 30 倍。目前支持 Linux 与 Windows 上的 NVIDIA RTX 30、40、50 系列。

共同作者包括 Databricks 联合创始人 Matei Zaharia 与 Ion Stoica，以及 Song Han、Kurt Keutzer。

而社区正在争论的，恰好是这些数字的成立条件：

1. 对照组是否公平——与经过手工调优的 llama.cpp 配置比较是否合理，这一点尚无共识。
2. 闭式解与真实环境的距离——理论上的 q* 闭式计算能否准确反映真实的 CPU 调度延迟、内存争用，以及多个智能体并发时不断变化的专家常驻情况。

这两条不推翻结果，但它们决定这个 3 到 4 倍在你的机器上还剩多少。速度永远是「在某组条件下的速度」，而这一次，那组条件正被公开地检查。