8GB显存如何跑35B：深入理解FreeToken的专家缓存与CPU-GPU协同
内容提要
FreeToken通过专家缓存与CPU-GPU协同，在8GB显存上运行35B MoE模型。它将完整专家池存于内存，显存作为LRU缓存，按q*策略动态分配未命中专家至GPU或CPU，Prefill用双缓冲隐藏传输，并优化Agent状态缓存。相比llama.cpp静态卸载，FreeToken更高效，但仅适用于MoE模型。
延伸解读
MoE 稀疏性：8GB 跑 35B 的前提
FreeToken 能在 8GB 显存运行 35B 模型，关键在于 Qwen3.6-35B-A3B 是 MoE 架构，每个 token 只激活约 3B 参数。但完整 35B 权重仍需存储，FreeToken 将其放在 32GB 内存中，显存仅作为缓存。若换成 Dense 模型如 Qwen3.8-27B，每个 token 需计算全部参数，无法利用此机制，只能依赖量化与静态层卸载。
q* 策略：动态平衡 CPU 与 GPU
FreeToken 根据实测带宽（PCIe 搬运带宽 B_P 和 CPU 内存带宽 B_H）计算 q*，决定未命中专家中多少搬入 GPU、多少由 CPU 计算。公式 q* ≈ m × B_P / B_H 使两条并行路径耗时接近，最大化硬件利用。例如 4060 Laptop 上 B_P=11.8 GB/s、B_H=47.5 GB/s，4 个 miss 时约 1 个搬 GPU、3 个留 CPU。该策略避免静态分配，适应不同机器配置。
与 llama.cpp 的本质区别
llama.cpp 的 -ngl 是静态层卸载，--cpu-moe 将专家固定于 CPU，均无跨 token 的专家缓存。FreeToken 则维护全局 LRU 专家缓存，动态决定每个 (layer, expert) 在 GPU 或 CPU 执行，并支持 CPU/GPU 并行计算。llama.cpp 适合 Dense 模型或简单卸载，FreeToken 专为 MoE 设计，但当前仅支持 Linux + NVIDIA，Mac 用户仍需依赖 llama.cpp。
性能限制与适用场景
39.3 tok/s 是特定配置（4060 Laptop、NVFP4、coding-agent workload）下的 Decode 速度，不代表所有场景。系统内存需足够容纳完整专家池（论文用 32GB），否则会 swap 导致性能骤降。缓存冷启动或话题突变时 miss 率上升，速度下降。Prefill 阶段因工作集稠密，需双缓冲隐藏传输，长 Prompt 下性能影响更明显。
Q&A
FreeToken 如何在 8GB 显存上运行 35B 的 MoE 模型？
FreeToken 并没有把 35B 参数全部塞进显存，而是将完整的 MoE 专家权重放在系统内存中，显存作为专家缓存，按需换入换出。它利用 MoE 模型每个 token 只激活一小部分专家的特性，通过 CPU 和 GPU 协同计算未命中的专家，从而在 8GB 显存上运行 35B 模型。
FreeToken 的 q* 策略是什么？如何决定哪些专家在 GPU 计算，哪些在 CPU 计算？
q* 策略根据实测的 PCIe 带宽（B_P）和 CPU 内存带宽（B_H）计算最优的 GPU 搬运专家数量。公式为 q* ≈ m × B_P / B_H，其中 m 是未命中的专家数。它旨在让 PCIe 搬运和 CPU 计算同时完成，最大化硬件利用率。例如，在 4060 Laptop 上，B_P=11.8 GB/s，B_H=47.5 GB/s，m=4 时，q*≈1，即 1 个专家搬入 GPU，3 个由 CPU 计算。
FreeToken 的专家缓存为什么有效？它利用了 MoE 路由的什么特性？
FreeToken 的专家缓存有效是因为 MoE 路由存在短期局部性：相邻 token 往往路由到相似的专家集合。通过全局 LRU 缓存，最近使用的专家留在 GPU，未命中的专家按需换入，从而减少 PCIe 传输。论文中，在相同缓存容量下，FreeToken 的 Decode miss rate 为 16%，远低于 KTransformers 的 41% 和 llama.cpp 的 62%。
FreeToken 如何处理 Prefill 阶段？为什么不能像 Decode 一样按需加载专家？
Prefill 阶段一次处理大量 token，路由结果并集几乎覆盖所有专家，因此按需加载会导致大量细碎传输。FreeToken 采用完整层双缓冲：用两块缓冲区交替计算和传输，计算第 l 层时同时传输第 l+1 层，隐藏 PCIe 延迟。这需要至少两层专家大小的缓存空间。
FreeToken 与 llama.cpp 的静态卸载有何区别？
llama.cpp 的 -ngl 是静态层卸载，加载时决定哪些层在 GPU，哪些在 CPU，运行时固定。--cpu-moe 可将 MoE 专家留在 CPU，但缺乏跨 token 的持久专家缓存。FreeToken 则动态管理每个 (layer, expert) 的位置，使用全局 LRU 缓存和 q* 策略，在 Decode 时动态决定专家在 GPU 还是 CPU，并支持 Prefill 双缓冲和 Agent 状态缓存。
FreeToken 有哪些限制？在什么情况下不适合使用？
FreeToken 主要适用于 MoE 模型，Dense 模型无法利用专家缓存。它需要足够大的系统内存容纳完整专家池（如 32GB），且性能受整机带宽（内存、PCIe）影响。此外，它目前仅支持 Linux x86_64 + NVIDIA GPU，不支持 Mac。
FreeToken 如何优化 Agent 场景中的重复 Prefill？
FreeToken 在 Agent 场景中利用语义锚点（如对话结束、工具调用开始/结束）保存 recurrent-state checkpoint。当上下文被修改时，从最近的锚点恢复 KV 和状态，只重新计算变化后的后缀，避免从头 Prefill。
FreeToken 的 FTW 格式有什么作用？
FTW 是 FreeToken 的快速权重格式，它预先将模型权重转换为运行时最终布局，避免加载时的重新排列和内存清零，从而缩短启动时间。它不是新的量化算法。
