FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution利用带宽自适应执行实现高效边缘原生MoE服务

一、研究背景与核心问题

背景：

• 前沿开源 MoE 模型（如 DeepSeek-V4-Flash、GLM-5.2）能力接近闭源系统，但运行成本极高。

• 全球有超过1亿台消费级设备（游戏 PC、工作站、笔记本）配备独立 GPU，算力潜力巨大但未被有效利用。

• 核心矛盾：模型参数已开放，但运行门槛（硬件/成本）仍未降低。

核心问题：

如何让普通个人机器（而非数据中心集群）高效运行百亿/千亿参数级别的 MoE 模型？

二、现有系统存在的三大不足

三、FreeToken 的核心设计思路

核心理念： 将个人机器视为统一、弹性的推理平台，而非"小 GPU"。根据实际可用资源和工作负载变化，动态映射计算与模型状态。

三大核心技术创新：

1. 带宽自适应执行（Bandwidth-Adaptive Execution）

• 预填充阶段：采用全层双缓冲，GPU 计算当前层时，下一层专家权重同时通过 PCIe 流式加载，隐藏传输延迟。

2. 语义感知缓存（Semantic-Aware Caching）

• 专家缓存：使用跨所有 MoE 层的全局 LRU 缓存，动态跟踪路由变化，使 GPU 内存始终保留当前最常用的专家集合。

• 状态缓存：在代理工作负载的语义边界（如思考段、工具调用、对话轮次）处锚定循环状态检查点。当上下文被编辑时，可从最近的有效检查点恢复，仅重计算新后缀，避免全量重计算。

3. 弹性资源管理（Elastic Memory Management）

• GPU 专家缓存可在运行时动态调整大小（与 KV 缓存重新划分），无需重启引擎。

• 快速启动：专家权重直接从磁盘加载到最终主机布局，省去预热步骤；冷启动的首请求通过普通解码路径自然预热缓存。

四、系统实现亮点

• GPU 端缓存控制：路由去重、命中/未命中分类、LRU 受害者选择、带宽分割全部在 GPU 内完成，无主机同步开销，所有操作被捕获为 CUDA Graph。

• 统一专家存储格式（FTW）：提前将模型权重重排为统一布局，启动时跳过张量发现和重打包，直接用并行 DIO 读取。

• 平台自适应：若无法建立快速 DMA 路径，可回退为纯 CPU MoE 后端，保证可部署性。

五、实验评估概况

测试范围：

• 模型：Qwen3.6-35B-A3B、DeepSeek-V4-Flash（284B）、GLM-5.2（753B）

• 硬件：从 8GB RTX 4060 笔记本到 RTX PRO 6000 工作站，共 6 种配置

• 工作负载：数学推理、SWE 编码代理（两种协议）、邮件/日历代理

• 对比基线：llama.cpp、Ollama、KTransformers、MoE-Infinity

关键结果：

六、研究贡献与意义

FreeToken 通过“带宽自适应执行 + 语义感知缓存 + 弹性资源管理”三位一体的设计，使普通个人机器（从笔记本到台式机）能够高效运行百亿至千亿参数的 MoE 模型，在吞吐量和延迟上显著超越现有边缘推理系统，真正实现了“开放权重即开放访问”。

这里是自己的论文阅读记录，感兴趣的话可以参考一下，如果需要阅读原文的话可以看这里，如下所示：

项目地址在这里，如下所示：

下载地址在这里，如下所示：

前沿的开放权重模型正变得越来越普及，但为其提供服务在很大程度上仍然假定依赖数据中心基础设施。我们提出了 FreeToken，一个边缘原生的 MoE 服务系统，它将个人机器不仅视为一个小型 GPU，而是一个统一的、弹性的推理平台。FreeToken 协同设计了完整的服务栈，包括模型布局与加载、专家驻留、CPU-GPU 执行、代理状态复用以及运行时内存管理，这些设计围绕本地人工智能的两个现实情况展开：代理工作负载会持续改变其执行模式，并且边缘硬件暴露出异构资源，其平衡性因机器而异。FreeToken 不会固守一种固定的卸载策略，而是持续地将计算和模型状态映射到实际可用的资源上。FreeToken 支持超过 20 个 MoE 模型，以及从 8GB 笔记本电脑 GPU 到单工作站 GPU 的各种硬件上的真实编码和工具使用代理。更重要的是，它改变了这些机器实际能够提供的服务，从笔记本电脑上的 35B 模型，到游戏台式机上的 284B 模型，再到单工作站 GPU 上的 753B GLM-5.2 模型。FreeToken 将开放权重转化为可部署的本地软件，使用户已拥有的机器成为前沿规模智能的实用平台。

1 引言

近来，如 Kimi-K3 (Kimi Team, 2026)、GLM-5.2 (Zai, 2026) 和 DeepSeek-V4-Flash-0731 (DeepSeek-AI, 2026) 等开放权重模型，正在迅速缩小与最强大的专有系统之间的能力差距。然而，发布模型参数仅仅决定了谁能获得模型，而非谁能负担得起运行它。前沿的开放模型仍然依赖于稀缺的、价值数百万美元的数据中心级 GPU 集群，并且尽管托管 API 可能比可比的专有产品更便宜，但持续使用的成本仍然很高。随着代理应用程序急剧增加推理需求 (Presenc AI Research, 2026; Anthropic, 2026)，这种成本对个人用户和小型团队来说尤其沉重。因此，开放模型与专有模型之间的能力差距，其缩小速度远快于那些能获得前沿模型与那些能大规模使用它们的人群之间的可及性差距。

乍一看，这种可及性差距似乎是一个硬件问题。然而，超过一亿台消费级机器已经配备了独立 GPU，涵盖了游戏台式机、工作站和高性能笔记本电脑。总的来说，这些机器代表了大量有能力但未被充分利用的计算资源。因此，缺失的部分并非硬件本身，而是一个服务系统，该系统能够将每台异构的消费级机器视为一个统一的推理平台，并自动将其 GPU、CPU、内存和互连资源映射到它能高效运行的最强模型配置上。

MoE 架构为在边缘设备上服务前沿规模的开放权重模型开辟了新路径。一个 MoE 层包含数百个专家，同时仅将每个 token 路由到其中的一小部分。例如，DeepSeek-V4-Flash 在其 43 层中的每一层，都会激活 256 个路由专家中的 6 个，因此其 284B 参数中仅有 13B 参与任一 token 的计算。在部署的精度下，这个激活参数规模适合 RTX 5090 的 32GB 内存容量。然而，稀疏性减少了每个 token 的计算量，却并未同比例减少完整专家池所需的内存。完整模型仍可能远超 GPU 内存，迫使非活跃专家驻留在主机内存或二级存储中，并按需进入执行路径。因此，MoE 为个人硬件上的前沿推理同时创造了机遇和核心系统挑战：稀疏激活使计算变得可行，而完整的专家池则使得高效服务变得困难。

一个日益壮大的服务系统生态系统已经开始将强大的开放权重模型带到个人硬件上，包括 llama.cpp (Gerganov et al., 2023)、KTransformers (KVCache-AI Team, 2025) 和 Ollama (Ollama Team, 2023)。然而，这些现有系统仅解决了边缘 MoE 服务问题的零散部分，并在三个维度上存在不足，阻碍了边缘服务达到其理论能力：

首先，预填充在很大程度上破坏了 MoE 中的工作集稀疏性。尽管每个 token 仅激活少数专家，但长提示词中所有 token 的路由并集通常覆盖了每层中的大多数专家，使得专家工作集实际上变得密集。这带来了计算和内存移动两方面的挑战，因为超过 VRAM 的专家必须从主机内存反复流式传输。这个问题在代理工具调用工作负载中尤其严重，这些工作负载中长且持续增长的上下文会触发频繁的预填充；然而，现有的边缘服务系统几乎不提供对隐藏专家移动或跨轮次复用循环状态的支持。其次，解码则呈现出相反的机制：每个 token 仅激活稀疏的专家子集，但缓存未命中需要专家被反复加载、驱逐或从主机内存执行。现有系统缺乏一种有原则的策略来处理这些未命中。静态放置无法跟随 token 级别的路由变化，而预测和预取可能降低未命中率，但无法决定不可避免的未命中应如何在 PCIe 传输、GPU 执行和直接 CPU 执行之间分配。第三，这两个问题因边缘资源的多样性和可变性而被放大。与数据中心部署不同，消费级硬件在 GPU 容量、PCIe 带宽、主机内存带宽、CPU 能力和可用 VRAM 方面差异巨大。这些资源也很少专用于模型服务：用户可能同时运行浏览器、游戏和其他应用程序。

(1) 带宽自适应执行将有限的边缘带宽从固定的瓶颈转变为运行时的调度信号。在预填充期间，FreeToken 将专家移动与计算进行双缓冲：当 GPU 计算当前层时，下一层的专家通过 PCIe 进行流式传输。解码需要更细粒度的分配，因为 PCIe 传输和直接 CPU 专家执行都消耗相同的主机内存带宽。因此，FreeToken 应用一个 q∗ 策略，将每步的缓存未命中在 GPU 缓存填充和直接 CPU 执行之间进行划分 (§ 3.2)，以匹配所部署机器能维持的带宽。(2) 语义感知缓存决定了在稀缺内存中保留什么。在代理轮次之间，代理框架会在语义边界（如思考片段和工具调用）处编辑上下文。在预填充期间，FreeToken 将这些边界处的循环状态检查点锚定，以便在编辑后，仅需重新计算新的后缀。在解码期间，相邻的 token 经常路由到重叠的专家。FreeToken 通过共享的 LRU 专家缓存捕获这种 token 间的路由局部性，使得大多数路由访问都能在 VRAM 中命中，仅将剩余的未命中留给 q∗ 策略处理。(3) 弹性边缘资源管理使 FreeToken 能够适应个人硬件不断变化的内存状况。在调度器安全点，FreeToken 能在修订后的内存预算下动态调整和重建 GPU 专家缓存，而无需重启引擎或重新加载主机驻留的专家池。FreeToken 通过直接将专家加载到其最终的主机布局中，然后再固定已填充的内存，进一步减少了启动延迟。

FreeToken 在广泛的消费级和工作站级硬件上支持超过 20 个 MoE 模型。在实验部分，我们主要在三个代表性的前沿模型上评估 FreeToken，包括 Qwen3.6-35B-A3B、DeepSeek-V4-Flash 和 GLM-5.2；在从 8 GB RTX 4060 笔记本电脑到单 RTX PRO 6000 工作站的六台机器上；使用四个真实的代理工作负载；并与 llama.cpp、Ollama、KTransformers 和 MoE-Infinity 进行比较。具体而言，在 RTX 5090 上，FreeToken 在 Qwen3.6-35B-A3B 上维持 77-83 tok/s，在 DeepSeek-V4-Flash 上维持 22-25 tok/s，在所有工作负载上比最先进的边缘服务实现了 1.5-2.3 倍的解码吞吐量提升。其性能在工作负载变得更具代理性时也保持显著稳定：解码速率保持在单轮设置值的 12% 以内，而竞争系统则大幅下降。这种优势在尾部延迟方面更为明显。FreeToken 在所有工作负载中将最坏情况下的 TFTT 保持在 44 秒以下，而每个基线在至少一种设置中超过 150 秒，这足以在实际代理客户端中触发超时。在五个消费级系统上，FreeToken 将解码吞吐量提高了 1.3-2.1 倍。在 8 GB RTX 4060 笔记本电脑上，它以 39.3 tok/s 的速度服务 35B 模型，超过了 Codex 33 tok/s 的中位数解码速度。在 32 GB 游戏台式机上，它交互式地服务 284B 模型。在单张 RTX PRO 6000 工作站 GPU 上，它服务 753B GLM-5.2 的吞吐量是 llama.cpp 的两倍。

总之，这些进步将开放权重转化为开放访问，将前沿智能从数据中心基础设施带到用户已拥有的机器上。FreeToken 推动了本地推理的速度和能力边界，使个人硬件能够交互式地服务以前仅在实际中可行的模型。我们在 flashml.ai 发布了该系统。

2 边缘 MoE 服务面临的挑战

MoE 是边缘服务的自然架构。一个典型的 MoE 层存储 E 个专家，但仅将每个 token 路由到其中 k≪E 个，因此单个解码步骤所触及的权重仅占该层总参数的一小部分。然而，在实践中，现有的边缘服务引擎 (Gerganov et al., 2023; KVCache-AI Team, 2025; Xue et al., 2024) 提供的性能远低于硬件理论上能支持的，并且这种不足在代理工作负载上更为严重：首次生成 token 的时间 (TTFT) 随每次工具调用而增长，解码运行速度远低于机器的内存带宽。本节探讨了这种不足背后的三个挑战：预填充成本 (§ 2.1)、解码成本 (§ 2.2) 以及两者之下的资源可变性 (§ 2.3)；§ 3 的三个小节按顺序回答了这些问题。

2.1 预填充阶段的挑战：传输与重计算成本

预填充决定了每个代理轮次的 TTFT。在边缘硬件上，预填充时间主要由两部分组成：专家传输，其规模取决于完整模型而非激活路径；以及上下文重计算，代理会话触发此操作的频率远超当前系统所能承受。

专家传输为每次预填充增加了数秒时间。 尽管解码将每个 token 仅路由到 k 个专家，但预填充过程每层涉及数千个 token。结果，这些被路由的 token 激活了几乎整个专家集。因此，一次预填充过程几乎将完整的专家池通过 CPU-GPU 互连进行流式传输。这引入了严重的 I/O 开销，而 VRAM 驻留部署则完全不会执行此操作。以 DeepSeek-V4-Flash 的 FP4 部署为例，它需要传输大约 140 GB 的专家权重，在 RTX 5090 系统（PCIe 5.0 x16，∼60GB/s）上增加约两秒，在 RTX 4090 和 3090 级台式机（PCIe 4.0 x16，∼25GB/s）上增加五秒，在笔记本电脑常见的 x8 链路上增加十秒或更长时间。按需获取专家的引擎会将整个这段时间暴露为 GPU 空闲时间。这种数秒的延迟在代理服务中通常是不可接受的。

代理工具调用触发频繁的重新预填充。 第二个挑战是重复模型已经完成的计算。许多前沿模型采用混合注意力架构，将全注意力与滑动窗口注意力（例如，DeepSeek-V4-Flash (DeepSeek-AI, 2026) 和 GPT-OSS (OpenAI, 2025)）或循环层（例如，Qwen3.6-35B-A3B 中的门控 DeltaNet (Yang et al., 2024b) 和 Kimi-K3 中的 Kimi Delta Attention (Kimi Team, 2025)）交织在一起。与标准注意力不同，这些层将过去的上下文压缩为单一状态或一个最近的 KV 条目窗口。由于每个保存的状态消耗的内存与数百个 token 的 KV 缓存一样多，服务引擎只保留少量检查点。代理工作负载几乎在每一轮都会修改上下文。例如，工具调用常常移除旧的输出并删除思考片段。由于这些修改，在修改位置之后获取的任何检查点都变得无效。引擎必须回退到修改之前的最后一个有效检查点。由于检查点稀疏，引擎通常需要重新预填充数千个 token。然而，消费级 GPU 无法隐藏这种重复成本：RTX 5090 的密集 BF16 吞吐量大约相当于 H100 的五分之一和 B200 的十分之一，因此长上下文的每次冗余重新预填充都会占用 GPU 数十秒。

2.2 解码阶段的挑战：缓存未命中和有限的 CPU 带宽

解码延迟取决于如何处理每一步专家的未命中，我们的分析将现有引擎的减速归因于两个硬件特征和一个策略后果：静态专家放置错过了大部分路由流量，消费级 CPU 带宽太小无法单独吸收剩余部分，以及在这两条路径之间正确分配未命中工作是硬件特定的。

静态专家放置错过了路由流量。 现有的混合引擎在加载或预填充时固定其专家放置位置：llama.cpp 在模型加载时将 MoE 张量分配给设备 (Gerganov et al., 2023)，而 KTransformers 将“热”专家子集固定在 GPU 内存中，并在 CPU 上执行其余部分 (KVCache-AI Team, 2025)。然而，路由随每个 token 和每个工作负载而变化。在预填充时冻结的放置仅捕获了路由流量的一小部分。因此，大多数专家评估落在 CPU 上，使 GPU 和 PCIe 链路闲置 (§ 5.3)。

消费级 CPU 无法单独承担解码任务。 在小的解码批次下，专家执行受内存限制：每个 token 流式传输路由专家权重一次。消费级平台将 CPU 连接到两个 DRAM 通道。这提供大约 50 GB/s 的双通道 DDR4 峰值带宽和 80-90 GB/s 的 DDR5 带宽，而单个 RTX 4090 或 5090 从其片上内存获取 1-1.8 TB/s 的带宽。由于这种带宽差距，仅依赖 CPU 的专家路径将解码速度限制为相同权重在 VRAM 中能维持的速度的一小部分，无论有多少核心可用。

正确的工作划分是硬件特定的。 一个未命中的专家可以通过 PCIe 传输并在 GPU 上执行，或者在其权重所在的 CPU 上执行。两种方法并非普遍更优。仅依赖传输会使主机带宽和 CPU 核心在主机内存能提供的字节数超过链路可移动的字节数时闲置。相反，仅依赖 CPU 执行会使 PCIe 链路闲置，并放弃缓存填充将带来的未来命中。正确的混合方式取决于硬件。例如，配备 LPDDR5 的 RTX 4060 笔记本电脑和配备 DDR5 的 RTX 5090 台式机处于两端。

2.3 资源管理的挑战：边缘环境中没有什么是专用的

在数据中心环境中，GPU 和 CPU 资源通常完全专用于服务工作负载。然而，在笔记本电脑和个人电脑等边缘设备上，LLM 服务只是众多并发应用程序之一。因此，服务引擎可用的资源是高度动态的。

VRAM 预算及其分配在服务期间频繁变化。 在边缘设备上，GPU 与桌面合成器、浏览器和游戏共享，这些应用程序随时可能占用 GB 级的 VRAM。因此，服务引擎可用的预算在不同启动时不同，并且在服务期间的任何时刻都可能缩小或增长。该预算的最佳分配方式也会变化：代理会话在轮次间累积上下文，因此 KV 缓存需求增长，而专家工作集大致固定，在第一轮选择的分配在几轮之后就不适用了。因此，GPU 内存必须在运行时保持可调整，包括总大小以及在 KV 缓存和专家之间的分配，而无需重启引擎。

引擎启动缓慢，且频繁发生。 启动服务引擎是资源密集型的：必须在第一个请求之前从磁盘加载完整的专家池并预热 GPU。对于 DeepSeek-V4-Flash 的 FP4 部署，仅从 7 GB/s 的 NVMe 驱动器读取大约 140 GB 的池就需要大约 20 秒，之后才开始任何预热。在边缘机器上，这种成本会重复发生：用户需要时打开引擎，用完时关闭以释放机器，并且切换到不同模型也会重启引擎。因此，边缘引擎必须快速启动。

3 FreeToken 设计

FreeToken 围绕两级专家-内存层次结构组织边缘 MoE 服务（图 2）。CPU 驻留的专家池持有完整的路由专家权重，并作为真实来源，而非专家权重则常驻在 GPU 上。FreeToken 将剩余的 GPU 内存转换为一个由所有 MoE 层共享的单一弹性专家缓存：每个槽位持有评估一个层-专家对所需的所有张量，因此驻留、查找和执行都基于逻辑上的（层，专家）标识符，而非张量分片。

该设计遵循 § 2 中识别的两个服务阶段的瓶颈。在预填充期间 (§ 3.1)，FreeToken 将大量的专家移动隐藏在计算之后，并维护能够在代理上下文编辑后存活的（包括循环状态的）前缀。在解码期间 (§ 3.2)，带宽自适应执行根据机器两个实测带宽，在 PCIe 传输和 CPU 执行之间划分缓存未命中。在这两个阶段之下，一个弹性专家内存生命周期 (§ 3.3) 将 GPU 缓存容量转变为运行时可调整的资源，而非加载时的常量。

3.1 预填充协同设计：流水线加载与语义感知状态缓存

§ 2.1 将预填充成本归因于两个部分：大量的专家传输和冗余的重计算。FreeToken 为每个部分提供了专门的机制：全层双缓冲将前者隐藏在计算之后，而语义感知状态缓存让前缀（包括循环状态）能够在上下文编辑后存活，否则这些编辑会触发重计算。

全层双缓冲将传输隐藏在计算之后。 由于预填充激活了几乎每层的整个专家集 (§ 2.1)，FreeToken 不会按需获取预填充专家。它从全局槽位池中分配两个全层缓冲区。当 GPU 从一个缓冲区计算第 ll 层的路由专家时，一个专用的传输流同时将第 l+1 层的完整专家集加载到另一个缓冲区中。通过加载整层，传输可以在该层路由已知之前就开始。这确保了权重移动在后台连续进行，而不是在各层之间串行。然后缓冲区交换角色。由于它们共享解码缓存的槽位池，因此没有单独的预填充缓存，也没有阶段交接，并且在预填充中存活的条目为延迟敏感的解码阶段提供了初始状态。当槽位池无法腾出两个完整层时，FreeToken 会回退到按需预填充加载，以避免 GPU 内存超订。

语义锚点跨上下文编辑保留循环状态。 混合注意力模型在 KV 缓存之外增加了第二种前缀资源。FreeToken 使用基数前缀树管理全注意力 KV，遵循现有的服务系统 (Zheng et al., 2024)；然而，循环层将其整个前缀压缩为一个不断演变的状态，该状态不能部分重用，因此这些层的前缀重用取决于在预填充和解码期间获取的状态检查点。为了解决这个问题，FreeToken 维护了一个语义感知状态缓存。这是一个小的循环状态检查点池，附加到前缀树的节点上。当新请求到达时，它会从在提示词编辑后其位置仍然存活的最近检查点恢复。由于每个检查点捕获了所有此类层的完整循环状态，只能持有少数几个，并且它们的位置决定了其价值。

FreeToken 将此预算花费在语义锚点上：标记思考片段、工具调用和输出以及对话轮次的特殊 token 边界。这些正是代理框架修改和截断上下文的位置：OpenClaw 从除最新轮次外的每个助手轮次中剥离思考块 (OpenClaw Contributors, 2026)；OpenCode 将超出近期窗口的工具输出替换为固定占位符 (OpenCode, 2026)；SWE-agent 忽略除最后 nn 个观察之外的所有内容 (Yang et al., 2024a)。在每种情况下，编辑都会替换或移除由特殊 token（如思考片段、工具调用、工具输出和对话轮次）标记的整个块。因为框架会保留直到被编辑块之前的精确前缀，在这些语义边界处获取的检查点比那些放置在任意位置的检查点更有可能在这次截断中存活。当代理框架在工具调用后编辑历史时，保留的前缀结束于这样一个边界。锚定在那里的检查点允许全注意力层重用其直到编辑点的 KV 缓存，同时循环层从锚点恢复，因此只有真正新的后缀被重新预填充。检查点槽位独立于 KV 池，使用 LRU 淘汰策略进行回收。

3.2 解码协同设计：语义感知专家缓存与 q∗ 策略

在解码期间的每个 MoE 层，路由器和缓存查找在 GPU 上运行，并识别已驻留在缓存中的活跃专家 HH，这些专家直接在 GPU 上执行。剩下的挑战是如何服务 m 个唯一的缺失专家 M。

语义感知专家缓存跟随模型不断演变的计算过程。 在解码期间，路由表现出很强的时间专家局部性：在连续步骤中，同一 MoE 层反复路由到重叠或最近使用过的专家，这是一种跨模型家族测量的路由一致性 (Liang et al., 2025)。FreeToken 通过语义感知专家缓存将此属性转化为 GPU 驻留。它不是根据加载时选择的与工作负载无关的放置来固定专家，而是维护一个共享的 LRU 驻留空间，其内容持续跟随路由器选择的专家。缓存命中刷新专家的最近性，缓存填充接纳新选择的专家，淘汰则移除模型最近最少需求的专家。通过这种方式，稀缺的 GPU 内存跟踪生成过程的当前工作集。§ 5.3 在我们的代理跟踪上确认了这种局部性，并在相同缓存容量下量化了其相对于静态放置的优势。

缓存无法消除未命中：冷启动、突然的工作集转移和有限的容量仍会使一些选定的专家不在 GPU 上。带宽自适应执行服务这些残留未命中，决定哪些专家应被带入缓存，哪些应在 CPU 上就地执行。

在执行期间，CPU 和 GPU 计算各自的部分和并将其合并，精确保留 MoE 输出，无算法近似。在执行顺序上，FreeToken 首先启动 CPU 分支。然后运行 GPU 未命中路径，该路径包括缓存更新、F 的批量复制，以及组合 GPU 执行集 G=H∪F 的分组评估。同时，CPU 工作线程处理 C。因此，暴露的层延迟是并发两个分支中较慢者的延迟，这正是方程 4 所平衡的量。这种每层控制流包括未命中检测、集合大小确定、受害者选择和 CPU 分支本身。将所有这些保持在一个静态捕获的 CUDA Graph 内本身就是一个实现问题；§ 4.1 介绍了与图兼容的缓存和执行机制。

3.3 面向边缘原生运行时的弹性内存管理

与数据中心部署不同，边缘 GPU 资源很少完全专用于 LLM 服务。服务引擎可用的 VRAM 可能因启动而异，甚至在会话中间因 GPU 与其他应用程序共享而发生变化。此外，随着上下文的增长，内存需求本身也在专家缓存和 KV 缓存之间转移，并且引擎通常是按需启动的。因此，从磁盘构建 CPU 驻留专家池是一个用户可见的成本。FreeToken 通过两种机制吸收这种可变性，两者都基于一个属性：因为 CPU 驻留专家池仍然是真实来源，GPU 内存仅影响性能，从不影响正确性。

运行时缓存重配置。 在分配了非专家权重和运行时状态后，FreeToken 将剩余的 GPU 内存预算在 KV 缓存页面和完整专家槽位之间进行划分。这种划分并非在启动时固定。在任何调度器安全点，FreeToken 都可以为修订后的运行时 VRAM 预算重建 GPU 专家缓存。这无需重启引擎或重新加载 CPU 驻留专家池即可完成，动态地为新的缓存配置重新建立捕获的执行路径。

快速引擎引导。 启动时间有两个组成部分：将专家池从磁盘加载到主机内存，以及传统的 GPU 预热。FreeToken 缩短了第一部分并消除了第二部分。加载直接将专家权重从磁盘读入其最终的主机布局，并且仅在之后固定内存；首先固定空缓冲区会错误地调入并清零 GB 级页面，仅仅是为了随后覆盖它们。预热在本设计中是不必要的：第一个请求在缓存未命中时提供服务，其未命中由 § 3.2 的普通解码路径处理，并且缓存通过正常服务预热。

4 实现

FreeToken 遵循 SGLang 和 vLLM (Zheng et al., 2024; Kwon et al., 2023) 等建立的以 GPU 为中心的服务架构，将分页 KV 缓存管理和基于基数树的前缀复用与社区内核库（如 FlashInfer (Ye et al., 2025) 和 Flash Linear Attention (Yang and Zhang, 2024)）相结合。在此基础之上，两个实现层实现了 § 3 的设计：与图兼容的专家缓存 (§ 4.1) 及其下的存储和平台机制 (§ 4.2)。

4.1 与 CUDA 图兼容的 LRU 缓存

专家缓存本质上是动态的：错过的具体专家、获取的专家数量以及被淘汰的槽位在每一步都可能发生变化。因此，由主机控制的缓存会在每个 MoE 层重新引入代价高昂的设备同步。为避免这种情况，FreeToken 将所有依赖路由的控制严格保留在 GPU 上。这种动态控制作为静态捕获图内部的数据来表示。具体来说，这些数据包括固定形状的工作缓冲区和设备端的有效计数。

设备端缓存控制。 对于每个 MoE 层，一个 GPU 内核会对路由的专家进行去重，对照驻留表对其进行分类，导出基于带宽的获取数量 q，选择淘汰的受害者，并将逻辑路由 ID 重写为物理槽位 ID 或一个特殊的 CPU 分配标志。受害者选择避免了经典 LRU 陷阱，即每次淘汰需要扫描整个缓存。相反，一个单次遍历的内核可以一次性识别出 K 个最近最少使用的候选槽位用于淘汰。然后，未命中路径只需消耗这些槽位中的前 q≤K 个。因此，无论实际未命中数量如何，受害者发现成本始终恰好是一次遍历。由此产生的拷贝工作列表驱动一个单一的融合传输。由于每个专家存储体共享相同的逻辑专家到槽位映射 (§ 4.2)，一个单一的设备驻留源/目标索引列表可以应用于所有存储体，只需一次固定形状的启动。使用有效计数来屏蔽任何未使用的工作。这种设计产生了很少的内核启动，实现了高 PCIe 利用率，并将依赖路由的决策开销从主机移除。

图中驻留的 CPU 执行。 带宽自适应执行的 CPU 分支被捕获到同一个图中。对于每个支持的解码批量大小，FreeToken 准备稳定的固定 I/O 缓冲区和持久任务描述符。设备到主机的拷贝、主机函数提交节点、并发的 GPU 路径、同步节点以及主机到设备的结果拷贝都被一起捕获。因此，重放会重新执行完整的异构步骤，而无需每 token 的 Python 调度。工作线程本身形成一个持久的 C++ 池，固定到物理核心。它们的内核使用特定架构的 SIMD 和内核算量化来消费专家权重，这使该路径保持带宽受限。最后，它们返回经过门控加权的、每个 token 的部分输出。

4.2 专家存储与平台适配

专家存储体和 FTW 格式。 FreeToken 将模型特定的检查点布局规范化为一小组专家存储体。每个存储体使用扁平化的层-专家标识符 lE+e 作为其主要维度。所有存储体中具有相同标识符的行共同形成一个完整的专家。因此，GPU 内核和 CPU 执行器共享一个逻辑专家身份，无论底层物理格式如何。为了加速加载，FreeToken 提供了 FreeToken Weight (FTW) 格式，该格式提前将专家权重合并到此运行时存储体布局中。在引擎启动期间，此格式允许系统完全跳过张量发现和重新打包。相反，它使用并行的直接 I/O 将对齐的块读入大小精确的主机存储体，这些存储体仅在填充后才被固定 (§ 3.3)。

平台适配。 在加载时，FreeToken 选择与专家表示、GPU 架构和 CUDA 环境兼容的 GPU 内核。同时，CPU 执行器分派到可用的 SIMD 实现和物理核心布局。当完整的专家池无法被固定或注册用于 DMA（这在某些操作系统和驱动程序配置中是一个限制）时，FreeToken 会回退到纯 CPU 的 MoE 后端。在此后端下，专家权重保留在可分页的主机存储中，所有路由专家都在 CPU 上执行。非专家层保留在 GPU 上，并且只有激活大小的输入、路由元数据和聚合输出跨 CPU-GPU 边界传输。此路径以牺牲峰值传输带宽为代价，换取了在无法建立快速路径的平台上的可部署性。

5 评估

我们在真实的代理工作负载上评估 FreeToken，服务其完整专家池超过 VRAM 的 MoE 模型，并在六台机器上与积极维护的边缘服务引擎进行比较。§ 5.1 详细介绍了设置，§ 5.2 报告了主要的端到端结果，§ 5.3 将增益归因于 FreeToken 的机制并测试其在硬件上的通用性。

5.1 实验设置

硬件。 六个配备独立 GPU 的系统（表 1）：五台消费级机器，覆盖当前边缘硬件的有效主机和 PCIe 带宽范围，以及一台工作站级机器（单张 RTX PRO 6000 Blackwell，96 GB）用于承载前沿规模演示。3090、4090 和 5090 系统是租用的双插槽服务器，其 CPU 远超任何边缘主机，因此这些机器上的每次服务运行和带宽测量都被限制为 6 个 CPU 线程，并固定到 GPU 的 NUMA 节点。通过这种方式限制，服务器提供了 56.7–77.3 GB/s 的主机带宽，这与两台真实边缘机器在其自然全线程下达到的规模相同（台式机 16 核为 53.8 GB/s，笔记本电脑 14 核为 47.5 GB/s）；台式机和笔记本电脑在无层级限制下运行，并在真实边缘硬件上验证了模拟结果。表 1 中的所有带宽都是在部署的张量形状上测量的，而非取自平台规格。

模型 两个 MoE 模型：DeepSeek-V4-Flash（284B 参数，13B 激活）(DeepSeek-AI, 2026)，从其路由专家原生采用 MXFP4 量化的官方检查点提供服务；以及 BF16 格式的 Qwen3.6-35B-A3B (Qwen Team, 2026)，以确保各引擎间的精度完全一致（8 GB 笔记本电脑则服务其官方 NVFP4 版本 (NVIDIA, 2026b)）。跨硬件研究增加了 GLM-5.2 (Z.ai, 2026)（753B 参数，40B 激活；NVFP4 路由专家 (NVIDIA, 2026a)，433 GB 检查点），由 RTX PRO 6000 作为前沿规模层级提供服务。

表 1：测试系统。BP​ 是实测的专家通过 PCIe 从主机到设备的传输带宽；BH​ 是实测的 CPU 端 MoE 专家内核有效带宽。在三台租用服务器上，CPU 线程和 DRAM 列给出了容器配额。

工作负载。 四个代理场景。W1，数学推理：使用长思维链解码且无工具使用的 AIME 竞赛问题回答——单轮且解码主导。W2，编码代理：通过 OpenCode 框架使用真实工具执行，在三个脚本化的用户轮次中解决一个 SWE-bench 仓库问题。W3，编码代理，原生协议：通过每个引擎的 Anthropic 兼容端点，由 Claude Code 驱动解决相同问题，这会生成并发请求的子代理，并将会话增长到 56-65k 个 token。W4，电子邮件/日历代理：通过 OpenClaw 在标准配置下（其 120 秒空闲看门狗被禁用，以便慢速引擎仍可测量）对邮箱工具包进行十三个固定的用户轮次，承载约 ∼24.5k 个 token 的系统上下文基线。所有引擎使用相同的框架和相同的请求提供服务；编码运行必须生成参考金补丁，W4 运行必须完成所有十三个轮次。

基线。 llama.cpp、Ollama、KTransformers 和 MoE-Infinity (Xue et al., 2024)（在其支持的配置上）。权重格式完全对齐：每个引擎以 BF16 格式服务 Qwen3.6，并且每个引擎以比特精确的方式消费 DSV4-Flash 的原生 MXFP4 专家块。

指标。 解码吞吐量（每请求平均 tok/s）和 TTFT（每请求平均）。代理轨迹因引擎而异，因此不比较跨引擎的端到端总耗时。

5.2 主要结果

图 3 报告了两个模型在所有四个工作负载上的解码吞吐量和平均 TTFT（RTX 5090；Qwen3.6 使用 6 个 CPU 线程，DSV4-Flash 使用 8 个）。

解码吞吐量。 FreeToken 在 Qwen3.6 上维持 77-83 tok/s，在 DSV4-Flash 上维持 22-25 tok/s，是每个工作负载中最强基线的 1.8−2.3× 和 1.5−1.9×。在代理服务下，该速率也保持稳定：在三个代理工作负载中，它保持在单轮 W1 值的 12% 以内，而对上下文最敏感的基线 KTransformers（在 DSV4-Flash 上）在 W2 时已经损失了其 W1 速率的 31%。因此，单流基准测试高估了基线的代理性能。MoE-Infinity 仅服务 W1（8.8 tok/s）：其每专家预填充阶段限制导致更长提示词的工作负载中止，并且其捆绑的服务器在请求间不保留 KV 缓存。

首次生成 token 的时间 (TTFT)。 FreeToken 在六个多轮单元中的五个中发布了最低的平均 TTFT（Qwen3.6 的 W3 单元有利于 KTransformers 的 GPU 预填充分支），而 W1 的短独立提示词则有利于 llama.cpp。引擎间的尾部延迟差异比均值更显著：FreeToken 在每个单元中的最差轮次保持在 44 秒以下，而每个基线在某个地方都超过 150 秒——llama.cpp 为 232 秒，Ollama 为 179 秒，KTransformers 为 946 秒。这些停滞超过了真实客户端放弃请求的阈值：OpenClaw 带有 120 秒空闲看门狗，Claude Code 的默认请求超时大约为十分钟。因此，尾部 TTFT 是一个可用性边界，而非单纯的延迟统计数据。

图 3：在 RTX 5090 上的端到端服务，涵盖四个工作负载（1. AIME, 2. OpenCode+SWE, 3. Claude Code+SWE, 4. OpenClaw+Email/Cal）和两个模型（Qwen3.6-35B-A3B BF16 和 DeepSeek-V4-Flash MXFP4）。上图：解码 TPS；下图：平均 TTF（对数刻度）。× 标记引擎无法服务的配置（Ollama 和 MoE-Infinity 缺乏 DSV4 支持；MoE-Infinity 对多轮代理不提供可用服务器）。

5.3 分解与跨硬件分析

三项分析将端到端的增益归因于 FreeToken 的机制并测试其通用性：流水线预填充（图 4a）、专家缓存局部性（图 4b）以及跨全硬件范围的服务（图 5）。

流水线预填充。 全层双缓冲使预填充受传输限制：启用重叠后，每个 8,192 token 的预填充块在 1.19-1.22 秒内完成，这是在 52.7 GB/s 下流式传输 64.4 GB 专家池一次所需的时间——这是 PCIe 5.0 × 16 链路的实际上限——因此专家计算完全隐藏在传输之后，吞吐量在 16k token 时达到 6.7k tok/s（图 4a）。禁用第二个缓冲区会将传输与计算串行化，并在 4k token 时损失 19% 的吞吐量，8k 时损失 25%，16k 时损失 26%，惩罚随提示词长度增加而增加，因为隐藏的计算比例上升。

专家局部性。 解码路由携带足够的短程局部性，以至于基于每次未命中的 LRU 策略优于在预填充时选择的放置策略，这是 § 3.2 所依据的观察。图 4b 在相同缓存容量下，对来自所有四个工作负载的相同路由轨迹，重放了三种引擎放置策略。在 RTX 5090 服务容量（Qwen3.6 专家池的 37%，DSV4-Flash 的 11%）下，FreeToken 的全局 LRU 在解码时专家读取的未命中率为 16% 和 39%，而 KTransformers 的预填充更新放置为 41% 和 59%，llama.cpp 的路由不可知静态分割为 62% 和 89%。在除完整池之外的每个容量下，这种排序在所有工作负载中都成立。

跨硬件服务。 这种优势在每台机器上都成立。图 5 在五个消费级系统上重复了 W2：FreeToken 在 RTX 3090 和 4090 上领先最强基线 1.3 倍，在 5090 服务器上领先 1.9 倍，在 5090 台式机上领先 2.1 倍，在 RTX 4060 笔记本电脑上领先 1.8 倍，其中 NVFP4 版本在 8 GB、PCIe × 8 的机器上维持 39.3 tok/s——是 RTX 4090 速率的 92%。两个 5090 列共享相同的 GPU 芯片，仅在主机上有所不同：从多通道服务器转移到双通道消费级台式机，FreeToken 的解码速率损失了 4%，而 llama.cpp 由于其 CPU 驻留专家在两个 DDR5 通道上受限，仅保留了其速率的 80%。在前沿层级，FreeToken 在单张 RTX PRO 6000 上服务 GLM-5.2 的速率为 14.9 tok/s，而 llama.cpp 为 7.3（2.0 倍），且专家权重比特相同，平均 TTF 相当（7.5 对 7.8 秒）。KTransformers 在此机器上没有可服务的路径：其 GLM-5.2 方法需要 753 GB-1.5 TB 的主机驻留专家，而主机内存为 512 GiB，并且其 CPU 内核无法读取 GLM-5.2 的 NVFP4 布局。

图 4：(a) 预填充 TPS 与提示词长度的关系（RTX 5090, Qwen3.6-35B BF16），有和没有 FreeToken 的流水线全层加载。(b) 在相同路由轨迹上重放的解码时专家未命中率与缓存大小（占专家池的百分比）的关系，对应于三种引擎的放置策略；线条是 W1-W4 的平均值，带状区域为最小-最大范围。

6 相关工作

专家卸载与缓存。 服务其专家池超过 GPU 内存的 MoE 模型已趋于采用 FreeToken 也采用的架构：完整专家池驻留在主机内存或磁盘上，专家子集缓存在 GPU 上。EdgeMoE (Yi et al., 2023) 为设备端推理确立了此设计；Mixtral-offloading (Eliseev and Mazur, 2023) 将 LRU 专家缓存与推测性预取相结合；MoE-Infinity (Xue et al., 2024) 跟踪请求级激活模式以指导预取和缓存；而 ProMoE (Song et al., 2024)、ExpertFlow (He et al., 2024) 和 FineMoE (Fan et al., 2025) 则强化了预测未来路由的预测器。跨 MoE 模型家族的路由一致性测量 (Liang et al., 2025; Lin et al., 2025) 支持了此类缓存可能有效的假设。这些系统的区别在于它们预测未命中的效果如何，但服务未命中的方式则相同：每次未命中最终都是一次 PCIe 传输，因此无论预测变得多么准确，解码延迟仍然受限于链路，而主机的计算能力则闲置。一个补充性的研究方向通过放宽保真度来降低传输量：HOBBIT (Tang et al., 2024) 获取未命中专家的低精度副本，SiDA (Du et al., 2024) 和 SMoE (Zhu et al., 2025) 替代或跳过低分专家（以准确性换取带宽），而 Pre-gated MoE (Hwang et al., 2024) 则重构并微调路由器本身。FreeToken 保持路由计算精确且模型未经修改；它改变了服务残留未命中的方式，而非预测它们的准确度。

混合 CPU-GPU 执行。 第二条路线将 CPU 作为计算资源而非仅作为权重存储。对于密集型模型，FlexGen (Sheng et al., 2023) 和 DeepSpeed-Inference (Aminabadi et al., 2022) 以层粒度流式传输权重，用于面向吞吐量的批量推理，而 PowerInfer (Song et al., 2023) 根据激活统计信息分割神经元，这需要 ReLU 族稀疏性和学习到的预测器；llama.cpp 和 Ollama (Gerganov et al., 2023; Ollama Team, 2023) 在加载时静态地将整层分配给设备。对于 MoE，Fiddler (Kamahori et al., 2024) 首次将未命中的专家视为可以在 CPU 上执行的工作，而不仅仅是需要移动的数据；KTransformers (KVCache-AI Team, 2025) 使用 AMX 优化的内核使原地 CPU 专家执行变得快速；HybriMoE (Zhong et al., 2025) 通过每步调度模拟重新平衡 CPU/GPU 队列；SMoE (Zhu et al., 2025) 使用贪婪的双指针启发式方法平衡加载与 CPU 时间；其他系统则在 CPU 上执行每次未命中 (Huang et al., 2025) 或为离线吞吐量流水线化 CPU、GPU 和 I/O (Cao et al., 2024; Fang et al., 2025)。在这一系列工作中，工作的划分要么在启动时固定（KTransformers 即使在 PCIe 空闲且缓存容量可用时也将路由专家保留在 CPU 上），要么由主机端启发式方法重新计算，其调度成本和每层同步无法被捕获到 CUDA Graph 中；llama.cpp 同样无法在其混合模式下维持图执行。此外，这些系统是围绕单次、短提示词推理设计和评估的，通常使用未量化的权重；它们都没有提供跨请求的前缀重用，而多轮代理会话在每次工具调用轮次都会重新进入预填充阶段。FreeToken 则从两个实测带宽中推导出工作划分，作为一个封闭形式的比率（足够轻量以作为设备驻留数据保留在捕获的图中），并将其嵌入到一个服务运行时中，而非单次请求框架。

服务基础设施与分层内存。 FreeToken 构建在 vLLM (Kwon et al., 2023) 和 SGLang (Zheng et al., 2024) 建立的以 GPU 为中心的服务基础之上，并依赖于 FlashInfer (Ye et al., 2025)，其注意力调度为在 CUDA Graph 捕获内的动态行为开创了先例。在内存管理方面，SGLang HiCache (SGLang Team, 2025) 将 KV 缓存分层存储在 GPU、主机和远程存储中，以在长时间的多轮会话中保持前缀重用；WiSP (WiSP authors, 2026) 根据边际延迟值在专家权重和 KV 缓存之间分割 VRAM；eLLM (eLLM authors, 2025) 在运行时重新平衡弹性内存池；FluxMoE (FluxMoE authors, 2026) 对专家进行分页以优先保证 KV 缓存容量。这些管理器移动的是被动字节：当页面或专家缺失时，它只能被获取，而 WiSP 自己的分析发现，无论预测准确性如何，单流解码都受限于 PCIe，这是分配单独无法突破的上限。专家权重提供了另一个自由度，因为缺失的专家也可以在其所在位置进行计算。FreeToken 结合了这两种手段：它将分层内存的理念应用于专家池。它使用了一个弹性的全专家缓存，具有统一的预填充/解码驻留，并在同一服务基础上增加了带宽自适应的 CPU 协同执行。我们的贡献在于集成的运行时和测量带宽模型，该模型在此框架内协调缓存、传输和 CPU 执行。

7 结论

我们提出了 FreeToken，一个面向个人硬件上前沿规模 MoE 模型的边缘原生服务系统。FreeToken 基于一个简单的观察：一旦稀疏激活使得模型计算变得可行，本地推理就与其说是模型是否适合 GPU 的问题，不如说是系统如何协调机器资源的问题。因此，FreeToken 将 GPU、CPU、主机内存和互连视为一个统一的推理平台，使模型状态和执行适应代理工作负载不断变化的结构及其运行的硬件。FreeToken 涵盖超过 20 个 MoE 模型和从 8 GB 笔记本电脑 GPU 到工作站 GPU 的硬件，支持从 35B 到 753B 参数的模型，同时持续优于现有的边缘服务系统。更广泛地说，我们的结果表明，本地人工智能的边界越来越不仅由硬件容量决定，也由组合已有资源的服务软件决定。FreeToken 朝着将开放权重转化为开放访问迈出了一步，使个人机器成为前沿规模智能的实用平台。