天津
智猩猩AI整理
编辑：BugMaker
大模型开源之后，真正的问题正在从“模型能不能获得”变成“普通用户能不能跑起来”。
目前越来越多百亿、千亿参数级开源模型开放权重，但这些模型真正运行时，仍然依赖昂贵的数据中心GPU。
但真正的瓶颈并不只是硬件。
大量消费级设备已经拥有独立GPU，包括游戏主机、工作站和高性能笔记本，但这些计算资源长期没有被充分利用。
近日，MIT韩松参与提出的FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution正式开源。
项目开源后迅速在GitHub走红。智猩猩AI在8月20日首次关注时，FreeToken还只有76 Stars，随后几天迅速冲上GitHub热门榜单。
8月22日，FreeToken登上GitTrend全站Trending第3，当天新增约1.8k Stars。8月25日又以约2.1k的单日新增位列全站第5。
截至8月26日，FreeToken已经达到8.4k+ Stars。短短几天从不足百星冲到数千星，也让这个边缘推理项目迅速成为近期AI Infra领域热度最高的开源项目之一。
它做的事情非常直接：
让消费级和边缘GPU也能够运行原本依赖数据中心的超大规模MoE模型。
FreeToken支持超过20个MoE模型，可以在从8GB笔记本GPU到工作站GPU的不同设备上运行。
其中最受关注的是，它让不同级别的消费硬件具备运行超大MoE模型的能力：
在RTX 4060笔记本上运行35B模型。
在32GB游戏桌面GPU上运行284B模型。
甚至在单张RTX PRO 6000上运行753B参数的GLM-5.2模型。
更重要的是，它并不是简单压缩模型，而是重新设计了一套面向边缘设备的MoE推理系统。
FreeToken希望解决的问题是：
让原本依赖数据中心的大模型推理能力，逐步进入用户自己的设备。
01
超大MoE模型进入本地设备，
关键是重新设计推理系统
MoE模型给本地运行带来了新的可能。
与传统密集模型不同，MoE模型虽然拥有大量参数，但每生成一个Token时，并不会激活全部专家。
可以简单理解为，一个MoE模型内部包含大量“子模型”，每次生成内容时只调用其中一部分专家。
但新的问题也出现了。
模型完整权重依然非常大，很多专家无法全部放入GPU显存。
因此，推理系统需要不断在GPU显存、CPU内存甚至磁盘之间移动专家权重。
过去的方法通常采用固定策略：哪些专家放GPU，哪些专家放CPU，什么时候加载。
这些规则在真实环境中并不稳定。
因为消费级设备和数据中心完全不同。
用户电脑上的GPU显存可能被浏览器、游戏等程序占用。
CPU、内存带宽和PCIe速度也存在巨大差异。
FreeToken提出的核心思想是：不要把边缘设备看成一块“小GPU”，而是把整台机器看成一个统一推理平台。
FreeToken没有继续采用固定的模型放置策略，而是围绕边缘设备三个核心限制重新设计推理流程。
第一是带宽自适应执行（Bandwidth-Adaptive Execution）。
FreeToken会根据当前机器真实测量得到的PCIe传输带宽和CPU内存带宽，动态决定哪些专家加载到GPU，哪些专家直接由CPU执行。
简单来说：
如果PCIe更适合搬运数据，就优先把专家放入GPU缓存。
如果CPU还有剩余带宽，就让CPU直接计算部分专家。
这样避免了过去固定策略造成的资源浪费。
第二是语义感知缓存（Semantic-Aware Caching）。
MoE推理过程中，不同Token选择的专家并不是完全随机。
相邻Token往往会访问相似专家。
FreeToken利用这一规律，在GPU中建立共享专家缓存，让经常使用的专家保持驻留。
论文中的实验显示，在相同缓存容量下，FreeToken的LRU专家缓存策略相比传统静态放置策略能够明显降低专家缺失率。
第三是弹性内存管理。
传统推理系统启动时就决定显存如何分配。
但边缘设备的资源会变化。
FreeToken允许运行过程中重新调整GPU专家缓存和KV Cache之间的空间分配，而不需要重新启动模型。
这让本地运行大型MoE模型更加接近云端服务体验。
02
面向Agent工作流优化，
让多轮工具调用不再反复计算
FreeToken并不是只针对普通聊天场景。
它重点关注的是越来越普遍的Agent工作负载。
例如Coding Agent，它需要不断读取代码、修改文件、运行测试并继续推理。
这类任务和普通问答不同。
一次任务可能包含多轮：模型思考，调用工具，读取结果，继续生成，上下文不断增长。
传统推理系统的问题在于，每次上下文变化都可能导致大量重复计算。
FreeToken针对这一点设计了语义锚点机制。
它会在思考过程、工具调用、工具输出等特殊位置保存状态。
当Agent修改历史上下文时，不需要重新计算全部内容，而只需要从最近有效状态继续推理。
这对于长时间运行的Agent非常重要。
因为未来的智能体不会只是回答一次问题，而是持续工作数分钟甚至数小时。
在性能方面，FreeToken也展示了明显优势。
在RTX 5090上测试了Qwen3.6-35B-A3B和DeepSeek-V4-Flash等模型，并与llama.cpp、Ollama、KTransformers等系统比较。
结果显示：
在Qwen3.6-35B-A3B上，FreeToken达到77–83 token/s，相比现有边缘推理系统最高提升2.3倍。
在参数规模更大的DeepSeek-V4-Flash上，这种优势依然存在。
DeepSeek-V4-Flash拥有284B总参数、13B激活参数，采用MXFP4专家权重。虽然每个Token真正参与计算的参数远小于284B，但完整专家池依然非常庞大，无法全部放入RTX 5090的32GB显存。
在RTX 5090上，FreeToken给DeepSeek-V4-Flash分配的GPU专家缓存只能容纳完整专家池的大约11%。即使在这么有限的缓存容量下，它的Decode专家缺失率仍控制在39%，而KTransformers和llama.cpp分别达到59%和89%。
在数学推理、OpenCode、Claude Code和OpenClaw四类任务中，FreeToken的Decode速度分别达到24.9、22.5、22.0和22.4 token/s，整体保持在22–25 token/s。
相比每个任务中的最强基线，FreeToken在DeepSeek-V4-Flash上的Decode吞吐达到其1.5–1.9倍。
明显的是Agent任务下的稳定性。从单轮数学推理进入OpenCode这类Coding Agent场景后，FreeToken从24.9 token/s变为22.5 token/s，整体变化并不大。
相比之下，KTransformers从单轮任务的10.4 token/s降到OpenCode场景的7.1 token/s，下降约31%。
这说明FreeToken解决的不只是“超大模型能不能在本地机器上运行”，还要让它进入真实Agent工作流后，在多轮交互中尽量保持稳定的推理速度。
03
从开源权重到真正可用的本地AI
FreeToken最大的意义，不只是又一个推理优化框架。
它改变的是大模型运行方式。
过去：
开源模型意味着任何人都可以下载权重。
但真正运行这些模型，仍然需要昂贵的数据中心资源。
FreeToken尝试解决的是中间这一步。
让用户已经拥有的GPU、CPU、内存和存储资源，被统一组织起来。
论文实验中，FreeToken覆盖了从RTX 4060笔记本到RTX PRO 6000工作站的不同硬件环境。
在8GB RTX 4060笔记本上，它可以运行35B模型，并达到39.3 token/s。
在单张RTX PRO 6000上，它运行753B GLM-5.2模型，吞吐达到llama.cpp的约2倍。
如果过去几年竞争的是谁能训练更大的模型，那么下一阶段的问题可能是：如何让更多设备真正运行这些模型。
随着越来越多MoE模型开放，推理系统本身正在成为大模型落地的重要基础设施。
FreeToken给出的答案是：
不要等待更大的GPU，先让现有硬件被更充分地利用。
关注+星标，获取AI前沿进展与开源一线动态
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
