FreeToken：高效的边缘原生 MoE 服务与带宽自适应执行

TL;DR FreeToken 将个人机器视为统一弹性推理平台，通过带宽自适应执行与专家缓存，让 8GB 笔记本 GPU 运行 35B 模型、单工作站 GPU 运行 753B 模型，把开源权重变成可部署的本地软件。

问题

问题背景

前沿开放权重模型（如 Kimi-K3、GLM-5.2、DeepSeek-V4-Flash-0731）能力快速逼近闭源系统，但推理服务仍默认数据中心级 GPU 集群。个人机器上的 GPU（8 GB 笔记本到单工作站 GPU）虽可获取模型权重，却难以实际运行大规模 MoE。

现有方法局限

传统边缘推理方案通常固定 offloading 策略，例如静态划分专家到 CPU/GPU 或依赖统一内存交换。但 agent 工作负载的执行模式不断变化，固定策略会导致两个阶段的双重瓶颈：

• Prefill 阶段：模型加载与激活传输带来高额 PCIe 传输和重计算成本。
• Decode 阶段：专家缓存未命中频繁，CPU 带宽受限，逐 token 生成延迟恶化。
• 内存管理：边缘设备无专用资源，运行时的显存/内存压力与操作系统、其他应用动态争抢，静态预留无法适应。

这些局限使得 35B 级别模型在笔记本上超过可用显存，284B 或 753B 模型在单卡工作站上不可能以可接受延迟服务。

为什么这个问题难且重要

MoE 推理在边缘的挑战在于执行模式持续变化 与异构资源平衡因机而异：agent 在工具调用、代码生成、多轮对话间切换，每次激活的专家集合不同；同时 CPU-GPU 带宽、内存容量、GPU 算力比例差异显著。业界对开放权重模型的本地可部署性高度关注，因为这是将前沿智能从数据中心释放到个人设备的必经之路。

FreeToken 的核心论断：不应将个人机器视为小型 GPU，而应视为可弹性调整的统一推理平台。

行业类比

类似在消费级显卡上运行具备工具调用能力的编码 agent（如 SWE-bench 风格任务），模型必须按需将代码理解与生成相关的专家驻留显存，否则一次工具调用就会因显存溢出或专家换入换出导致秒级延迟。

核心洞察

• 将边缘推理从固定卸载策略转变为运行时动态映射，把个人机器视为统一弹性推理平台。 传统边缘LLM服务通常采用静态的层卸载或纯CPU执行，要么受限于显存容量无法加载大模型，要么无法适应负载变化。FreeToken观察到agent工作负载的执行模式持续变化，且边缘硬件资源异构，因此不预设offloading方案，而是持续将计算和模型状态映射到实际可用资源上。这种“平台化”思路使同一系统跨越8GB笔记本到单工作站GPU，支持从35B到753B模型，而不是针对某一硬件做定制优化，显著扩展了边缘可服务模型的边界。
• 挖掘agentic工作负载中的语义复用，通过semantic-aware state caching和expert caching降低CPU-GPU带宽压力。 现有MoE serving大多面向数据中心，依赖预取或专家并行，假设带宽充足且请求模式独立。边缘场景下CPU-GPU带宽有限，且agent在连续工具调用和代码执行中会重复访问相似的上下文和专家。FreeToken利用这种时序局部性，将状态和专家缓存与CUDA graph兼容的LRU结合，避免重复传输和重计算。这种把上层语义信息引入系统调度的设计，比单纯基于硬件的缓存策略更精准，是边缘推理中少见的跨层协同。

方法

输入：本地机器异构资源（GPU/CPU/内存/磁盘）、MoE open-weight 模型权重、动态变化的 agent 工作负载（编码、工具调用）。系统将个人机器视为统一弹性平台。

关键模块：

• Prefill 阶段：pipelined loading 流式加载权重分片；semantic-aware state caching 复用 agent 状态，减少重计算与传输开销。
• Decode 阶段：semantic-aware expert caching 根据语义预测所需专家，提高缓存命中；q* policy 在专家激活与带宽限制间动态平衡，决定 GPU/CPU 执行位置。
• Elastic memory management：运行时动态调整 GPU 显存与 CPU 内存分配，支持专家暂存、agent 状态及 KV cache 的弹性换入换出。
• CPU–GPU 协同：将不同算子调度到最合适设备，避免固定 offloading 模式。

输出：单台设备上高效运行大模型，如 8GB 笔记本 GPU 跑 35B，工作站 GPU 跑 753B。

差异：与静态层卸载或固定专家放置等传统方案不同，FreeToken 通过带宽自适应执行动态映射计算与模型状态，适应异构硬件与变化负载。

实验

实验设计

FreeToken 在从 8GB 笔记本 GPU 到 单工作站 GPU 的多种边缘硬件上评估，覆盖超过 20 个 MoE 模型（包括 35B、284B、753B GLM-5.2 等）。测试负载包含真实 coding agent 与 tool-using agent，重点考察系统在 agent 工作负载持续变化下的性能表现。对比基线为固定 offloading 策略的传统 MoE serving 系统。

关键发现

• 系统通过带宽自适应执行，能够在 8GB 笔记本 GPU 上运行 35B 模型，在游戏台式机上运行 284B 模型，在单工作站 GPU 上运行 753B GLM-5.2。
• 相比固定 offloading 策略，动态资源映射显著减少传输与重计算开销，提升 CPU-GPU 协同效率。
• 语义感知的 expert caching 与 agentic state reuse 降低 decode 阶段 cache miss 和 CPU 带宽压力。
• 运行时内存管理实现弹性适配，无需专用硬件即可服务前沿规模模型。

与基线对比深度解读

传统的 MoE serving 系统通常假设数据中心环境并采用固定 offloading 策略，导致边缘异构硬件上资源利用不平衡。FreeToken 将个人机器视为统一弹性推理平台，持续映射计算与模型状态到实际可用资源。实验表明，这种 co-design 方式使原本无法在消费级硬件上运行的模型变为可部署，将开放权重模型转化为可本地运行的软件，显著扩大了前沿模型的可用边界。

行业影响

落地场景

FreeToken 将前沿 MoE 模型（如 GLM-5.2）部署到个人设备，适合数据本地化与低延迟场景：

• 本地编码代理：在开发者笔记本上运行代码生成与工具调用 agent，避免代码上传云端。
• 隐私敏感的企业服务：医疗、金融行业的客服或文档处理模型可在本地 GPU 运行，满足合规要求。
• 电商内容生成：商家利用本地工作站生成商品描述与营销文案，降低 API 调用成本。

商业价值

• 降本：消除云端推理 API 持续费用，尤其对高频或长尾调用。例如 8GB 笔记本可运行 35B 模型。
• 体验提升：完全本地化带来毫秒级响应（无网络往返），并避免数据泄露风险。
• 生态推动：系统开源（GitHub），吸引开发者构建边缘原生 AI 应用。

跟现有产品/工作流的接口

FreeToken 作为 推理后端 无缝集成：

• 通过 OpenAI 兼容 API 暴露本地模型，替换云端端点。
• 直接加载 HuggingFace 权重，兼容常见模型格式。
• 与 IDE 插件（如 Continue.dev）或 LangChain 等编排框架结合，提供本地执行环境。

具体用例：电商平台为商家提供本地 AI 助手，在商家硬件上运行商品文案生成，数据不出企业；教育科技公司可将个性化辅导模型部署到学生设备，离线可用且保护学习数据。

局限

• 系统仅针对 **MoE** 模型设计，对 Dense 模型或非专家混合架构不支持，这限制了其通用性。尽管当前前沿开放权重模型多为 MoE，但 Dense 模型在边缘场景仍占有重要地位；此外，动态映射与缓存策略依赖专家激活的稀疏性和可预测性，若专家选择高度随机或负载模式频繁波动，缓存命中率可能显著下降，导致性能退化。
• 系统假设边缘设备上运行单用户或轻负载 agent 工作负载，未考虑多租户并发或服务级别保障（QoS）。当多个 agent 或后台进程同时竞争 CPU、GPU 和内存带宽时，弹性资源管理策略可能引发资源争抢，造成延迟抖动或吞吐下降；论文未提供并发场景下的评估结果，实际部署中需要额外的资源隔离或调度机制。
• 评估范围存在一定局限：主要针对 coding 和 tool-using agents 任务，硬件覆盖从 8GB 笔记本 GPU 到单工作站 GPU，未涉及更广泛的边缘设备（如手机、嵌入式 NPU）；语义感知的专家缓存和状态缓存需要额外的语义提取开销，论文未定量分析该开销对首次推理延迟的影响；与已有 offloading 或 expert caching 方法的对比可能不够全面，缺乏在更多模型族和异构硬件上的公平基准测试。