753B 参数的 GLM-5.2 跑在单张工作站 GPU 上,284B 模型塞进游戏主机,35B 模型装进 8GB 显存的笔记本——这不是营销幻灯片,而是 UC Berkeley 团队 8 月 17 日放出的论文 FreeToken(arXiv:2608.16157)给出的配置清单。论文上线三天,已登上 Hugging Face Daily Papers 热榜,作者名单里包括 Song Han、Matei Zaharia 和 Ion Stoica。
本地跑大 MoE,到底难在哪
开源权重的模型越做越大——GLM-5.2 有 753B 参数,DeepSeek、Qwen 的旗舰也是数百 B 级别的 MoE。但论文开篇就点破现状:为这些模型做 serving 的系统,基本都默认你有一台数据中心服务器。
个人机器的现实完全不同。论文的判断是:边缘硬件暴露的是异构资源,而且每台机器的配比都不一样;更麻烦的是,agent 工作流的执行模式还在持续变化——上一秒在写代码,下一秒在调工具,专家激活的分布完全不同。传统的 offload 方案之所以慢,是因为它们把个人机器当成"一块小 GPU"来打补丁。
FreeToken 的出发点是把整台机器——GPU、CPU、host 内存、互连——当成一个统一的弹性推理平台来调度。它不固定任何 offloading 策略,而是持续地把计算和模型状态映射到实际可用的资源上。
三个工程核心
带宽自适应的 CPU-GPU 协同执行。 项目 README 称之为 q* 策略:根据带宽动态决定专家计算放在哪一侧执行,配合全层 double-buffered prefill 流式加载和全局 LRU 专家缓存,尽量让权重搬运和计算重叠。
语义感知缓存。 这是专门为 agent 场景设计的:工具调用、思考块这类上下文编辑,通过 semantic anchor 检查点复用已有的 KV cache,避免整段上下文重算。跑过长会话 coding agent 的人都知道,上下文重算的等待有多折磨人。
弹性内存管理。 显存里的专家缓存和 KV 内存可以在运行时动态再分配,不用重启引擎、不用重载权重——agent 负载变了,内存布局跟着变。
实测口径与生态位
按论文报告的数字:8GB 显存的笔记本可以跑 35B 模型,一台游戏桌面可以跑 284B 模型,单张工作站 GPU 可以跑 753B 的 GLM-5.2。系统支持 20 多个开源 MoE 模型,官方点名 DeepSeek-V4-Flash、Qwen3.6-35B-A3B 和 GLM-5.2,量化格式覆盖 MXFP4、NVFP4、FP8、BF16,硬件支持 NVIDIA RTX 30/40/50 系列消费卡。
更值得注意的是接口层:它提供 Anthropic/OpenAI 兼容 API,README 直接列出了适配的 coding agent——Codex、Claude Code、OpenCode、OpenClaw、DeepSeek Harness。也就是说,你本地的 Claude Code 完全可以把后端指向这台跑着 284B 模型的游戏 PC。
项目以 Apache 2.0 许可证开源,代码托管在 GitHub 的 FlashML-org/FreeToken,桌面端提供 Windows 和 Linux 安装包。作者也坦言系统深受 mini-sglang 启发,复用了 SGLang、vLLM、FlashInfer 等项目的代码。
所以呢
FreeToken 真正做的事,是论文原话说的 "turns open weights into deployable local software"——把开源权重变成可部署的本地软件。过去两年开源模型在能力上追平闭源,但能流畅跑起来的机器始终在数据中心;这篇论文把边界推到了用户手头已有的设备上。
当然,上面这些数字都来自作者自己的报告,消费级硬件上的实际 token 速度还需要社区验证——项目刚开源,GitHub star 数还不多,桌面端也还处于 v0.2.0-beta 阶段。但方向已经很清楚:当 753B 模型可以常驻一张工作站 GPU,本地 agent 的隐私、成本和延迟三件事,会被同时改写。