FreeToken：面向边缘设备的MoE推理引擎，单卡工作站运行753B GLM-5.2

边缘推理的瓶颈不在硬件，而在服务系统

前沿开源大模型（如Kimi-K3、GLM-5.2、DeepSeek-V4-Flash）正快速缩小与闭源系统的性能差距，但模型参数开放不等于推理可负担。当前主流MoE推理仍默认需数据中心级GPU集群，高昂成本对独立开发者与中小团队构成显著门槛。而现实中，超一亿台消费级设备已配备独立GPU。研究团队指出，缺失的关键并非硬件，而是能将个人设备视为统一、弹性推理平台的服务系统——它动态适配设备实际拥有的GPU、CPU、内存及互连带宽，而非将其简化为‘一块小显卡’。

三类典型部署场景与适用领域

FreeToken已在GitHub开源（Apache-2.0协议），PyPI发布v0.1.2版本（`uv pip install "freetoken[accel]"`），并提供Windows/Linux一键桌面应用（flashml.ai）。CLI工具支持Linux x86_64 + NVIDIA驱动r580+（CUDA 13），`ft serve`暴露OpenAI/Anthropic兼容API（端口1919），`ft launch claude`可本地运行Claude Code等代码智能体。目标用户明确：个体开发者、初创公司及SMB工程团队（其智能体token账单已超自有GPU成本）；企业用户则适用于气隙环境或强监管工作负载，而非替代数据中心。最强行业契合度集中于医疗、法律（数据永不离机）、国防、金融及知识产权密集型研发场景，典型应用包括本地编程助手、私有代码审查、离线合同分析、合成数据生成与批量模型评测。

现有引擎的三大失效模式

MoE结构虽使本地前沿推理在算术层面可行（如DeepSeek-V4-Flash每层仅激活6/256专家，单次推理仅调用约13B参数），但现有推理引擎存在根本性缺陷：

• Prefill阶段摧毁稀疏性：数千token预填充时几乎路由至全部专家池，导致整套FP4权重（约140GB）经PCIe反复加载——RTX 5090需约2秒，PCIe 4.0桌面达5秒，笔记本常见x8链路则超10秒；
• 静态张量放置错失解码流量：llama.cpp等在加载时即固化专家张量位置，KTransformers仅缓存“热点”子集；但路由随token动态变化，多数专家计算被迫落至CPU，GPU与PCIe空转；
• 消费级CPU无法承载剩余计算：双通道DDR5带宽仅80–90 GB/s，远低于RTX 4090/5090从片上存储获取的1–1.8 TB/s，形成严重瓶颈。

三大核心技术机制

FreeToken提出三项协同设计：

• 带宽自适应执行（q*策略）：DMA传输与CPU专家计算共享主机内存子系统，当PCIe饱和时，剩余带宽为B_H − B_P。引擎据此按比例分配每步m次缓存未命中：约q* ≈ m × B_P / B_H个专家载入GPU缓存，其余就地CPU计算，两部分结果精确合并（无近似、不修改路由逻辑）。带宽实测值因设备而异（如RTX 5090服务器B_P:B_H=52.7:77.3，RTX 4060笔记本为11.8:47.5）；
• 语义感知缓存：Prefill采用全层双缓冲（计算第l层时预取第l+1层）；循环状态检查点锚定于特殊token边界（如思考块、工具调用/输出），恰好匹配智能体上下文截断点，编辑后仅重prefill新后缀；Decode阶段采用跨所有MoE层的共享LRU专家缓存，路由实时驱动缓存更新，而非加载时冻结；
• 弹性内存管理：调度安全点处，GPU专家缓存可依据修订后的显存预算重建，无需重启引擎或重载主机专家池。专家直接从磁盘读入最终主机布局并锁定，首请求即以冷缓存服务，免GPU预热。

实测性能表现

在RTX 5090上，FreeToken对Qwen3.6-35B-A3B（BF16）维持77–83 token/s，对DeepSeek-V4-Flash（MXFP4）达22–25 token/s，较最强基线提升1.5–2.3倍，且解码延迟波动控制在基线12%以内。