8GB显存跑35B模型，每秒39Token，伯克利MIT联手开源

8GB显存的笔记本，跑35B参数的MoE大模型，每秒还能出39个Token。这不是云厂商的演示，是加州大学伯克利分校和麻省理工学院刚开源的一个推理引擎干出来的事。

这个项目叫FreeToken，定位是"边缘原生"的MoE推理运行时。共同作者名单里有两个名字值得注意：Databricks联合创始人Matei Zaharia和Ion Stoica，以及MIT的Song Han、Kurt Keutzer。学术背景够硬，但真正让社区兴奋的是它解决了一个长期被忽视的问题——消费级硬件跑大模型，瓶颈根本不在算力，而在PCIe带宽。

静态卸载为什么卡？

稀疏MoE架构有个特点：处理每个Token时只激活全部参数的一小部分，但解码过程仍然要在数千亿个未激活权重里做路由。数据中心里有NVLink这种高带宽互连，专家权重的传输开销可以被掩盖。消费级硬件没这个条件，PCIe吞吐量通常只有16到64GB/s，主机内存延迟直接变成解码瓶颈。

现有边缘运行时普遍用静态专家卸载：未激活的权重放在系统内存里，一旦被激活就同步传到GPU。问题在于，一旦发生缓存未命中，整个执行过程会完全停顿。GPU在等数据，CPU在等GPU，整条流水线卡死。

FreeToken的解法：让CPU和GPU一起干活

FreeToken用了一种叫q*策略的动态协同调度方案，取代僵化的卸载机制。核心思路是：缓存未命中时，GPU不停下来等，而是根据实时互连吞吐量，把Token计算任务在CPU核心和GPU张量核心之间动态分配。

这套系统还做了两件事来配合调度：

• 快速权重格式（FTW）加整层双缓冲：让PCIe传输权重和活跃计算层的执行完全重叠，传输时间被"藏"在计算背后。
• 弹性内存管理器：运行期间动态调整KV缓存条目和常驻专家槽位之间的显存分配，不用重新加载模型。

换句话说，FreeToken把"卸载"从一种被动补救变成了主动调度。每一层计算前，系统实时算一个闭式最优分配方案，决定哪些Token在CPU算、哪些在GPU算，而不是等缓存未命中发生后再想办法。

智能体场景下的额外优化

现代编程助手和自主智能体有个独特的执行模式：频繁修改提示词、返回工具调用结果、生成思考块，这些操作会不断改变上下文窗口。标准引擎遇到前缀变化时，会丢弃线性KV缓存，然后触发一次代价高昂的完整序列重计算。

FreeToken集成了语义锚点检查点机制，在逻辑任务边界缓存中间注意力状态和循环激活值。当智能体修改中间工具参数或插入外部执行结果时，系统可以复用已有的子序列状态，而不是让整个提示词缓存失效。这个设计明显是冲着Agent工作流去的。

和现有生态的差距有多大？

论文里直接给了对比数据。在相同的MoE模型上，FreeToken的解码速度比Ollama和llama.cpp快3到4倍，预填充速度快6到30倍。后两者针对GGUF量化和逐层卸载做了优化，但无法在主机和设备之间动态分配稀疏专家的负载。

另一个对比对象是KTransformers，它采用静态CPU/GPU卸载规则。FreeToken的做法是实时计算每一层的闭式最优分配方案，而不是用一套固定规则应对所有情况。

实测数据：从RTX 4060到753B模型

论文基准测试部分给出了几个具体场景：

• 配备8GB显存RTX 4060的笔记本，运行Qwen3.6-35B，速度约每秒39个Token。
• 配备RTX 5090的台式机，运行DeepSeek-V4-Flash（284B）。
• 配备单块工作站GPU的设备，运行GLM-5.2（753B）。

工具本身已经开放，命令行和桌面客户端可以通过FlashML.ai和GitHub获取，目前支持Linux和Windows系统上的NVIDIA RTX 30、40、50系列GPU。

社区在争论什么？

Hacker News和Reddit的LocalLLaMA论坛上，讨论热度不低。一个明显的共识是：本地硬件自主权正在成为开发者关注的核心议题。有工程师指出，把带宽自适应MoE服务和二手RTX 3090/4080搭配标准DDR4/DDR5内存，可以显著降低自托管前沿推理智能体的门槛，同时避免持续支付云API费用。

技术层面的质疑也存在。LocalLLaMA的讨论帖在追问：理论上的q*闭式计算能否准确反映真实环境中的CPU调度延迟、内存争用，以及智能体并发运行时不断变化的专家常驻情况？还有人质疑，和经过手工调优的llama.cpp配置做基线比较是否公平。

这些争论短期内不会有定论。但一个更广泛的范式转变已经清晰：开发者越来越认为，要摆脱专有API锁定、把智能体迭代成本降到零、在自动化编程工作流里保护知识产权隐私，对边缘异构资源做协同调度是绕不开的一步。FreeToken不是第一个尝试，但它把这件事的门槛往下拉了一大截。