FreeToken 完全拆解：带宽自适应执行，让 8GB 笔记本跑 35B、单卡工作站跑 753B 的边缘 MoE 服务系统

挑战一：Prefill 摧毁稀疏性——专家传输与重复计算#

第一重成本来自专家传输。解码时每个 token 只路由到 $k$ 个专家，但 prefill 一次要处理成千上万个 token，这些 token 的路由并集几乎覆盖每一层的全部专家。一次 prefill 相当于把整个专家池流过 CPU-GPU 互连，这是显存驻留部署完全不会有的 I/O 开销。

以 FP4 部署的 DeepSeek-V4-Flash 为例：约 140GB 专家权重需要传输。在 RTX 5090 机器上（PCIe 5.0 ×16，实测约 60GB/s）需要约 2 秒；在 RTX 4090/3090 这类 PCIe 4.0 ×16 桌面机上（约 25GB/s）需要约 5 秒；笔记本常见的 ×8 链路则要 10 秒以上。如果引擎按需（on-demand）抓取专家，整个传输窗口 GPU 都是空闲的——这段时间全部暴露为延迟。

第二重成本来自重复计算。智能体的工具调用几乎每一轮都会修改上下文：删掉旧的工具输出、截断思考段（thinking segment）。这直接打击混合注意力（hybrid attention）架构——许多前沿模型在全注意力之外交织了滑动窗口注意力（sliding-window attention，如 DeepSeek-V4-Flash、GPT-OSS）或循环层（recurrent layer，如 Qwen3.6-35B-A3B 中的 gated DeltaNet、Kimi-K3 中的 Kimi Delta Attention）。循环层把整个过去上下文压缩进一个持续演化的状态（recurrent state），这个状态无法像 KV 缓存那样部分复用，只能整体保存或整体重算；因为单个状态占用的内存相当于数百个 token 的 KV 缓存，引擎只能保存少量检查点（checkpoint）。上下文一被编辑，编辑位置之后的所有检查点全部失效，只能回退到最后一个有效检查点，经常要重新 prefill 数千个 token。而消费级 GPU 的稠密算力有限——RTX 5090 的 BF16 稠密吞吐大约只有 H100 的五分之一、B200 的十分之一——每次冗余 re-prefill 都会占用 GPU 几十秒。

挑战二：Decode 的缓存缺失——静态放置、CPU 带宽与”最优分工因机而异”#

解码阶段每个 token 只激活稀疏的专家子集，但缓存缺失（cache miss）导致专家被反复加载、驱逐或在主机内存里执行。现有引擎缺乏处理这些缺失的原则性策略：

• 静态专家放置错过大部分路由流量。 llama.cpp 在模型加载时就把 MoE 张量分配到各设备；KTransformers 把”热门”专家子集固定（pin）在 GPU 显存，其余在 CPU 上执行。但路由随每个 token、每个负载实时变化，prefill 时冻结的放置只能覆盖路由流量的一小部分，导致绝大多数专家计算落到 CPU 上，GPU 与 PCIe 链路反而闲着。
• 消费级 CPU 的带宽扛不住全部解码。 小批次解码时专家执行是内存受限（memory-bound）的：每个 token 要把路由到的专家权重完整流过一遍。消费级平台的内存只有双通道：双通道 DDR4 峰值约 50GB/s，DDR5 约 80-90GB/s，而单张 RTX 4090/5090 从板载显存取数可达 1-1.8TB/s。这个带宽差决定了纯 CPU 专家路径的解码速度只有显存路径的零头，与核心数无关。
• 正确的分工比例是硬件相关的。 缺失的专家可以经 PCIe 传上来在 GPU 算，也可以就地（in-place）在 CPU 上算。两者没有普适的优劣：只靠传输，主机内存能比链路搬得快的部分就浪费了；只靠 CPU，PCIe 链路闲着，还放弃了”填充缓存换来未来命中”的收益。RTX 4060 笔记本（LPDDR5）与 RTX 5090 桌面机（DDR5）处在主机-互连带宽平衡的两个极端，最优混合比例从规格表上读不出来，必须在实际运行的机器上定量测量。

挑战三：边缘资源没有什么是专用的#

数据中心里 GPU 和 CPU 整机专供推理负载；在笔记本和个人电脑上，LLM 服务只是众多并发应用之一。桌面合成器、浏览器、游戏随时可能划走数 GB 显存，因此服务引擎可用的显存预算在不同次启动之间不同，服务中途还可能收缩或增长。最优的预算划分也在移动：智能体会话跨轮次累积上下文，KV 缓存需求不断增长，而专家工作集基本固定——首轮选择的划分在几十轮之后就错了。显存总量及其在 KV 缓存与专家缓存之间的分配必须能在运行期调整，且不能重启引擎。

引擎启动本身也很慢且频繁发生。完整专家池要从磁盘读入并预热 GPU 才能服务第一个请求：DeepSeek-V4-Flash 的 140GB 池从 7GB/s 的 NVMe 读出就要约 20 秒。边缘用户”用到才开、不用就关”，换模型还要重启引擎，启动速度直接决定可用性。

全层双缓冲：让专家搬运消失在计算背后#

既然 prefill 会激活每层几乎全部专家（论文 2.1 节），FreeToken 就不按需抓取 prefill 专家，而是从全局槽位池中分配两个全层缓冲区（full-layer buffer）。GPU 从其中一个缓冲区计算层 $l$ 的被路由专家时，一条专用传输流（transfer stream）同时把层 $l+1$ 的完整专家集加载进另一个缓冲区。关键设计点：

• 传输可以在路由已知之前开始。 因为加载的是”整层”，不需要等待该层路由结果，权重搬运全程在后台连续进行，而不是在层与层之间串行。
• 两个缓冲区与 decode 缓存共享同一个槽位池。 没有单独的 prefill 缓存，也没有阶段交接（phase handoff）；prefill 期间存活的条目直接为延迟敏感的 decode 阶段”播种”。当槽位池腾不出两个整层的空间时，FreeToken 回退到按需 prefill 加载，而不是超订（oversubscribe）显存。

实测效果（论文图 4a，RTX 5090 + Qwen3.6-35B，BF16）：开启重叠后，每个 8192-token 的 prefill 块在 1.19-1.22 秒内完成——这正是把 64.4GB 专家池以 52.7GB/s 流一遍的时间，即 PCIe 5.0 ×16 链路的实际上限。也就是说专家计算被完全隐藏在传输后面，prefill 变成纯传输受限，16k token 的 prefill 吞吐达到 6.7k tok/s。关闭第二个缓冲区后传输与计算串行，吞吐损失随提示词长度增长：4k token 损失 19%，8k 损失 25%，16k 损失 26%——提示词越长，被隐藏的计算占比越高，损失越大。

语义锚点：让循环状态跨越智能体的上下文编辑#

混合注意力模型在 KV 缓存之外增加了第二种前缀资源。全注意力层的 KV 由 radix 前缀树（prefix tree）管理（沿用 SGLang 等系统的成熟做法，可部分复用）；但循环层把整个前缀压缩进一个持续演化的状态，无法部分复用，其前缀复用只能依赖 prefill/decode 期间保存的状态检查点。检查点很贵（每个状态的体积相当于数百个 token 的 KV 缓存），只能保留少数几个，因此检查点放在哪，直接决定它们值不值钱。

FreeToken 把预算花在语义锚点（semantic anchor）上：标记思考段、工具调用、工具输出、对话轮次的特殊 token（special token）边界。这些位置恰好是智能体框架修改与截断上下文的地方：

• OpenClaw 会裁剪除最新一轮外所有 assistant 轮的思考块；
• OpenCode 的 compaction 机制把超过近期窗口的工具输出替换为固定占位符；
• SWE-agent 只保留最后 $n$ 条观察（observation）。

三种情况下，编辑都是替换或删除由特殊 token 标记的整块内容，而编辑点之前的精确前缀被保留。因此锚定在语义边界的检查点比任意位置上的检查点存活率高得多：上下文被编辑后，从”编辑后仍存活的最深检查点”恢复——全注意力层复用截至编辑点的 KV 缓存，循环层从锚点状态继续——真正新增的后缀才需要重新 prefill。检查点槽位用 LRU 独立于 KV 池回收。

语义感知专家缓存：跟随路由器走，而不是固定放置#

解码时的路由表现出强时间局部性：连续步长上同一 MoE 层反复路由到重叠或近期使用过的专家，这种路由一致性（routing consistency）已在多个模型家族上被测量验证。FreeToken 把这一性质转化为显存驻留：维护一个所有 MoE 层共享的 LRU 驻留空间，内容持续跟随路由器选择的专家——命中刷新该专家的新旧度，填充准入新选中的专家，驱逐最久未被模型需要的专家。稀缺的显存因此持续追踪生成的当前工作集（working set），而不是加载时冻结的、与负载无关的放置。

论文图 4b 在相同缓存容量下重放四类负载的真实路由轨迹，对比三种放置策略的解码期专家缺失率：在 RTX 5090 的服务容量下（Qwen3.6 专家池的 37%、DSV4-Flash 的 11%），FreeToken 的全局 LRU 分别缺失 16% 与 39% 的解码期专家读取，而 KTransformers 的 prefill 更新式放置为 41% 与 59%，llama.cpp 的忽略路由的静态切分为 62% 与 89%。在未达到全池容量的任何容量点上，排序都成立。

q* 策略：用实测带宽把缓存缺失分给 PCIe 与 CPU#

缓存无法消除全部缺失：冷启动、工作集突变、容量不足都会让部分被选中的专家不在 GPU 上。带宽自适应执行负责服务这些残余缺失，决定哪些专家补进缓存、哪些在 CPU 上就地执行。

核心观察： DMA 传输与 CPU 专家执行读取的是同一个主机内存子系统。当 PCIe 传输饱和时，剩余给并发 CPU 执行的残差带宽（residual bandwidth）为：

其中 $B_P$ 是实测的固定（pinned）内存专家传输带宽（PCIe 侧），$B_H$ 是实测的主机侧专家处理带宽（CPU 侧）。$B_P$ 与 $B_H$ 都取部署机器上的实测值，而非规格表数值。当 $B_H < B_P$（主机内存比链路还慢，如部分 PCIe 5.0 桌面机），残差为 0，全部缺失都该走传输。

把 $m$ 个缺失专家划分为缓存填充集 $\mathcal{F}$ 与 CPU 执行集 $\mathcal{C}$，$q=|\mathcal{F}|$：

$\mathcal{F}$ 中的专家传入缓存槽位、在 GPU 上执行并驻留供未来复用；$\mathcal{C}$ 中的专家直接从 CPU 端专家池执行、不改变驻留状态。两个集合并发服务：缓存填充以完整 PCIe 速率进行，CPU 只消耗被饱和链路剩下来的主机带宽——把残差带宽转化为当前 token 的进度，而不打断缓存更新。

两条并发分支的执行时间近似为：

其中 $S$ 是单个完整专家的大小（字节）。第一式：$q$ 个专家各自以 $B_P$ 的速率过 PCIe；第二式：$m-q$ 个专家在残差带宽 $B_H - B_P$ 上执行——分母之所以是差值而非 $B_H$，正是因为 PCIe 传输饱和时 CPU 只能拿到剩下的那部分。让两条并发分支时间相等（层延迟取两者较慢者，恰好就是该平衡的量）：

推导过程：$qS/B_P = (m-q)S/(B_H-B_P)$，两边消去 $S$ 得 $q(B_H-B_P)=(m-q)B_P$，展开 $qB_H = mB_P$，即 $q^{\star}=m\,B_P/B_H$。直觉：缺失专家按两条路径的带宽比例分配。 PCIe 相对主机内存越快，越多的缺失走填充；反之越多留在 CPU 就地执行。这个闭式解同时覆盖了所有硬件平衡：当 $B_H$ 逼近 $B_P$ 时 $q^{\star}$ 逼近缺失总数 $m$，系统退化为纯按需缓存填充，不需要单独的执行分支或策略——一个公式覆盖全部硬件形态。

实践中 FreeToken 把 $q^{\star}$ 取整，具体的 $\mathcal{F}$ 选择交给缓存替换策略，并始终至少保留一个填充，这样即使 CPU 处理了大部分缺失，缓存也持续在热身（warming）。带宽参数在部署时用工具实测（ft bench bw）。计算上，CPU 与 GPU 各自算出部分和（partial sum）后精确合并——不修改路由器、不替换专家、不放松精度，MoE 输出逐位（bit-exact）保真。

执行顺序与工程细节#

单层执行顺序：先启动 CPU 分支；随后 GPU miss 路径执行三步——缓存更新、$\mathcal{F}$ 的批量拷贝、以及合并执行集 $\mathcal{G} = \mathcal{H} \cup \mathcal{F}$ 的分组评估；CPU worker 并发处理 $\mathcal{C}$。暴露的层延迟是两条并发分支中较慢的那个，正是上面公式平衡的量。

以论文图 2 的例子核算：$m=4$，取 4060 笔记本的实测带宽 $B_P:B_H = 11.8:47.5$，$q^{\star} = 4 \times 11.8/47.5 \approx 0.99$，取整为 1——1 个缺失走 PCIe 填充，3 个在 CPU 就地执行，与图注一致。若换到 RTX 5090 服务器（52.7:77.3），同样 $m=4$ 时 $q^{\star} \approx 2.7$，约 3 个填充、1 个 CPU 执行——主机内存与链路带宽越接近，越倾向让 GPU 全包。这也是”正确分工因机而异”的直接体现。

这里有一个必须强调的工程难点：这个逐层控制流包含缺失检测、集合定容、受害槽选择与 CPU 分支本身，全部要装进一次静态捕获的 CUDA Graph 里（否则每层一次主机同步会让延迟优势荡然无存）。这是论文 4.1 节的主题，下文”实现细节”部分展开。

Device-side 缓存控制：单个 kernel 完成去重、分类、选 victim#

专家缓存的本质是动态的：每步缺失的专家、抓取的数量、驱逐的槽位都在变。如果由主机控制缓存，每个 MoE 层都要引入一次昂贵的设备同步。FreeToken 把所有依赖路由的控制严格留在 GPU 上，把动态控制表示为静态捕获 graph 内部的数据：固定形状的工作缓冲区（work buffer）与设备端驻留的有效计数（valid count）。

每个 MoE 层用一个 GPU kernel 完成：对路由专家去重 → 对照驻留表分类（命中/缺失）→ 按带宽比例推导抓取数 $q$ → 选择驱逐受害槽 → 把逻辑路由 ID 重写为物理槽位 ID 或”CPU 执行”的特殊标志。

受害槽选择绕开经典 LRU 陷阱（每驱逐一个槽位就全缓存扫描一遍）：单遍 kernel 一次性找出 $K$ 个最久未用的候选槽位，miss 路径只需消费其中前 $q \le K$ 个——无论实际缺失多少，受害发现永远只花一遍扫描。由此得到的拷贝工作列表驱动一次融合传输（fused transfer）：因为每个专家 bank 共享同一套逻辑 专家→槽位 映射（见 4.2 节），一份设备端源/目的索引列表就能以一次固定形状 launch 应用到所有 bank，未使用的工件由有效计数屏蔽。这个设计换来的是少量 kernel launch、高 PCIe 利用率，以及主机端零路由相关决策。

Graph 内的 CPU 执行分支#

带宽自适应执行的 CPU 分支同样被捕获进同一张 graph。对每个受支持的 decode batch 尺寸，FreeToken 准备稳定的 pinned I/O 缓冲区与持久任务描述符（persistent task descriptor）；设备到主机拷贝、host-function 提交节点、并发 GPU 路径、同步节点、主机到设备结果拷贝全部一起捕获。这样 graph 回放（replay）就能重放完整的异构执行步，无需逐 token 的 Python 调度。worker 本身是一个 pin 在物理核心上的常驻 C++ 线程池，kernel 使用架构相关的 SIMD 指令与 kernel 内反量化（in-kernel dequantization）消费专家权重，使该路径保持带宽受限；最后返回经门控加权（gate-weighted）的逐 token 部分输出。

FTW 权重格式与平台适配#

FreeToken 把各模型的 checkpoint 布局规范化为一小组专家 bank（expert bank）。每个 bank 以扁平化标识 $lE+e$（层号 × 每层专家数 + 专家号）作为首维；所有 bank 中同一标识的行共同构成一个完整专家。于是 GPU kernel 与 CPU 执行器共享同一个逻辑专家身份，与底层物理格式无关。

加载快的关键是 FTW（FreeToken Weight）格式：提前把专家权重按运行期 bank 布局合并存储。引擎启动时跳过张量发现（tensor discovery）与重打包（repacking），用并行直接 I/O（direct I/O）把对齐块直接读进精确尺寸的主机 bank，填充完成后再 pin。

平台适配方面：加载时按专家表示、GPU 架构与 CUDA 环境选择 GPU kernel；CPU 执行器按可用 SIMD 实现与物理核布局分派。若完整专家池无法 pin 或注册 DMA（某些操作系统与驱动配置下的限制），FreeToken 回退到纯 CPU MoE 后端：专家权重留在可分页主机存储，所有被路由专家在 CPU 执行；非专家层仍在 GPU，只有激活尺寸的输入、路由元数据与聚合输出跨过 CPU-GPU 边界。该路径以峰值传输带宽换取在无法建立快速路径的平台上的可部署性。

实验设置#

硬件（论文表 1，带宽均为在部署张量形状上的实测值）：

前三台是租来的双路服务器，CPU 远超任何边缘主机，因此每次服务运行与带宽测量都被限制在 6 个 CPU 线程并 pin 到 GPU 的 NUMA 节点上——限流后它们的主机带宽为 56.7-77.3GB/s，与真实边缘机器自然满线程的水平相当（桌面机 16 核 53.8GB/s、笔记本 14 核 47.5GB/s）；桌面机与笔记本不设限，用于验证这种模拟在真实边缘硬件上成立。

模型：DeepSeek-V4-Flash（284B 参数、13B 活跃，官方 checkpoint 原生 MXFP4 量化）；Qwen3.6-35B-A3B（BF16，与各引擎精度完全对齐；8GB 笔记本改用官方 NVFP4 版本）；跨硬件研究追加 GLM-5.2（753B 参数、40B 活跃，NVFP4 路由专家，433GB checkpoint，在 RTX PRO 6000 上作为前沿档演示）。

负载：四个真实智能体场景。W1 数学推理（AIME 竞赛题，长思维链解码，无工具调用，单轮、解码主导）；W2 编码智能体（OpenCode 框架 + SWE-bench 仓库 issue，三次脚本化用户轮次内执行真实工具）；W3 编码智能体原生协议（同一 issue 经 Claude Code 的 Anthropic 兼容端点驱动，会并发请求子代理，会话增长到 56-65k token）；W4 邮件/日历智能体（OpenClaw 默认配置下 13 个固定用户轮次，约 24.5k token 的系统上下文底）。所有引擎以相同请求服务相同 harness；编码运行必须产出参考黄金补丁，W4 必须完成全部 13 轮。

基线：llama.cpp、Ollama、KTransformers、MoE-Infinity（在其支持的配置上）。权重格式严格对齐：每个引擎都以 BF16 服务 Qwen3.6，每个引擎都逐位（bit-exactly）消费 DSV4-Flash 的原生 MXFP4 专家块。指标为每请求平均解码吞吐（tok/s）与平均 TTFT（time to first token，首 token 时延）；由于各引擎的智能体轨迹会发散，不比较跨引擎的墙钟总时长。

主结果：RTX 5090 上的端到端对比#

下图是论文图 3：RTX 5090 上四个负载 × 两个模型的端到端结果，上排解码吞吐、下排平均 TTFT（对数刻度），× 表示该引擎无法服务该配置。

解码吞吐：FreeToken 在 Qwen3.6 上维持 77-83 tok/s，在 DSV4-Flash 上维持 22-25 tok/s，分别是各负载最强基线的 1.8-2.3 倍与 1.5-1.9 倍。更关键的是智能体负载下的稳定性：三个智能体负载下解码速率仍保持在单轮 W1 值的 12% 以内，而上下文最敏感的基线——DSV4-Flash 上的 KTransformers——到 W2 时已经损失了单轮速率的 31%。单流基准因此系统性高估了基线的智能体表现。MoE-Infinity 只能服务 W1（8.8 tok/s）：其逐专家 prefill 暂存上限中止了长提示词负载，自带的服务器在请求间不保留 KV 缓存。

TTFT：六个多轮单元格中 FreeToken 在五个取得最低平均 TTFT（Qwen3.6 × W3 一格 favor KTransformers 的 GPU-prefill 分支；W1 的短孤立提示词则 favor llama.cpp）。尾部时延比均值拉开得更狠：FreeToken 在每个单元格的最差轮次都低于 44 秒，而每个基线都在某处超过 150 秒——llama.cpp 232 秒、Ollama 179 秒、KTransformers 946 秒。这些停滞已经越过真实智能体客户端的放弃阈值：OpenClaw 自带 120 秒空闲看门狗，Claude Code 的默认请求超时约十分钟。尾部 TTFT 因此是可服务性边界（availability boundary），不只是延迟统计量。

机制分解：双缓冲、专家局部性、跨硬件普适性#

下图是论文图 4：左图为 prefill 吞吐随提示词长度的变化（开/关流水线加载），右图为解码期专家缺失率随缓存容量的变化（三种放置策略、相同路由轨迹重放）。

流水线 prefill 使 prefill 变为传输受限：开启重叠后每个 8192-token 块 1.19-1.22 秒完成，等于 64.4GB 专家池以 52.7GB/s 流过一遍的时间——PCIe 5.0 ×16 的实际上限；16k token 时吞吐 6.7k tok/s。关闭第二缓冲区则传输与计算串行，吞吐损失 19%（4k）、25%（8k）、26%（16k），随提示词变长而增大。

专家局部性：等容量下全局 LRU 缺失 16%（Qwen3.6 的 37% 容量）与 39%（DSV4-Flash 的 11% 容量），对比 KTransformers 的 41%/59% 与 llama.cpp 的 62%/89%。

跨硬件普适性（论文图 5，SWE issue + OpenCode 负载，Qwen3.6-35B-A3B）：FreeToken 相对最强基线的提升为 RTX 3090 与 4090 上 1.3 倍、5090 服务器上 1.9 倍、5090 桌面机上 2.1 倍、4060 笔记本上 1.8 倍——后者以 NVFP4 在 8GB、PCIe ×8 的机器上维持 39.3 tok/s，达到 RTX 4090 速率的 92%。两个 5090 列共享同一 GPU 硅片、只差主机：从多通道服务器换到双通道消费桌面，FreeToken 只损失 4% 解码速率，而 llama.cpp 因 CPU 驻留专家在两个 DDR5 通道上挨饿而只保住 80%——主机内存带宽越弱，带宽自适应的价值越大。

前沿档演示：单张 RTX PRO 6000 上，FreeToken 以 14.9 tok/s 服务 753B 的 GLM-5.2，llama.cpp 为 7.3 tok/s（2.0 倍），专家权重逐位相同，平均 TTFT 相当（7.5 秒 vs 7.8 秒）。KTransformers 在这台机器上根本没有可服务的路径：其 GLM-5.2 方案需要 753GB-1.5TB 主机驻留专家，而机器只有 512GiB 主机内存；其 CPU kernel 也不读 GLM-5.2 的 NVFP4 布局。