Meta Muse Glimmer 30B 小白入门开放权重与 24GB 显存本地部署假设你把一张智能家居面板截图交给 AI让它读懂界面、修改代码、调用工具检查结果碰到失败后再换一种办法。过去这类任务通常依赖云端大模型。Meta 新发布的 Muse Glimmer 30B 把目标放在个人电脑上希望模型在本地完成长时间推理、看图和工具调用。这次发布有一个清楚的工程进展。约 300 亿参数的稠密多模态模型经过量化进入了 24 GB 消费级显存的范围。这个门槛仍然不低却已经让高性能本地智能体从专业服务器走向部分个人工作站。 专栏介绍 《GitHub小白开源成长课》这个专栏写给计算机初学者、大学生和刚接触 AI 开源项目的读者。每篇文章挑一个值得动手的 GitHub 项目读源码查依赖也把费用、许可证和使用边界讲清楚。读完以后你至少能判断这个项目解决什么问题自己能不能跑以及下一步该从哪个文件学起。如果你正在从“会收藏项目”走向“能读懂项目”可以关注这个专栏。后面还会继续拆解 AI 编程、科研工具、多智能体和 AI 内容创作方向的开源项目。先交代这篇文章的核验范围本文核对日期为 2026 年 8 月 11 日。资料来自 Meta 官方发布页、官方 Hugging Face 模型卡与配置、Meta 的评测方法报告以及 Transformers、llama.cpp、ExecuTorch 的公开源码和问题记录。首先要先澄清一个容易混淆的点。Muse Glimmer 没有同名的 Meta 官方 GitHub 独立仓库。模型权重和配置放在 Hugging FaceGitHub 上可以阅读 Transformers、llama.cpp 与 ExecuTorch 的适配代码。日常交流里可以称它为开源模型严谨一些则应称为 Apache 2.0 开放权重模型因为 Meta 没有公开完整训练代码、精确训练数据清单和全套训练管线。一分钟看懂 Muse Glimmer 30B项目2026 年 8 月 11 日核验结果发布机构Meta Superintelligence Labs发布时间2026 年 8 月 10 日参数规模约 29.6BHugging Face 元数据为 29,776,626,688输入与输出文本和图像输入文本输出上下文长度131,072 及以上公开配置写明 131,072知识截止日期2026 年 1 月 4 日主要用途本地智能体、编程、函数调用、图像理解、模型评测量化硬件目标17 GB 版面向 24 GB 显存或统一内存Dynamic 版面向 32 GB完整精度目标64 GB VRAM模型许可证Apache License 2.0另有 Muse Glimmer Usage Policy官方入口Hugging Face 模型集合与 Meta 官方发布页它和 Google Research 的文本生成图像模型 Muse、Microsoft 的游戏世界模型 Muse、Meta 早年的 MUSE 词向量项目都没有关系。Muse Spark 是它的教师模型之一也不能和可下载的 Muse Glimmer 混为一谈。它想解决云端智能体的哪块麻烦智能体比普通聊天机器人多了一层行动能力。它会拆任务、选择工具、读回执行结果再决定下一步。这样的系统若长期依赖云端会遇到网络可用性、调用费用、数据传输和响应延迟等问题。Muse Glimmer 面向本地常驻工作流。官方列出的能力包括多步规划、结构化函数调用、失败恢复、长上下文处理和图片理解。适合它的任务可以是阅读截图后定位界面问题也可以是让编程智能体在测试目录里修改代码、运行测试并解释结果。模型本身只会生成文本和工具调用参数。文件是否真的被改动邮件是否真的发出取决于外部智能体框架给了它哪些工具和权限。这条边界非常重要也是部署时最容易被忽略的地方。小白也能读懂的模型工作方式图片先被翻译成模型能读的 tokenMuse Glimmer 带有一个约 1.8B 参数的 ViT-G/14 感知编码器。图片会被切成小块转成视觉特征再投影到语言模型能够接收的表示空间。公开配置把单张图片的上限写为 4096 个视觉 token。这意味着模型可以把截图、图表和文档图片同文字放在一个上下文里推理。它最后只输出文字不会直接生成图片也不支持音频输入输出。模型卡还提醒视频没有经过专门优化部分运行时会直接关闭视频入口。52 层 Transformer 怎样省下长上下文成本主模型是一套 52 层稠密因果 Transformer。源码里的注意力安排很有特点三个 2048 窗口的局部注意力层后面跟一个全局注意力层然后继续循环。局部层主要观察附近内容计算量更容易控制。全局层定期把更远的信息串起来。模型还使用 32 个查询头和 2 个 KV 头减少长上下文 KV cache 的体积。这样的结构让 131,072 token 上下文更适合本地设备但长上下文仍会消耗额外内存配置里的上限不代表每台机器都能轻松用满。工具调用需要模板和解析器共同工作模型会按照 ATEM 格式生成函数名和参数。chat_template.jinja负责把系统消息、用户消息与工具定义整理成模型认识的输入ExecuTorch 的serving/tool_parsers/atem.py再把模型输出转换为 OpenAI 兼容的tool_calls。源码对未定义工具、格式损坏和参数类型都做了处理。工具调用要靠权重、聊天模板、解析器和运行时共同完成。缺少其中一块智能体都可能只吐出一段难以解析的控制文本。DFlash 用一个小模型帮主模型打草稿普通自回归模型每次向后生成一个 token。Muse Glimmer 另外提供 DFlash drafter它能一次提出一块候选 token默认块大小为 16。主模型并行检查这些候选接受正确部分再修正错误部分。官方报告显示17 GB 量化主模型加 DFlash 后RTX 5090 的解码速度从 74.9 tok/s 提升到 233.4 tok/sM4 Max 从 23.7 提升到 37.8 tok/sM5 Max 从 26.6 提升到 50.2 tok/s。测试使用 batch size 1 和 greedy decoding。硬件、上下文、任务与后端换掉后速度也会变化。官方案例里模型怎样完成一项任务Meta 发布页展示了一个 OpenCode 中的 Home Assistant 仪表板任务。演示里的模型需要理解目标编写或修改代码调用工具查看结果并在遇到问题后继续调整。这个案例适合用来理解本地智能体的完整链条。用户给出目标框架整理上下文模型规划下一步工具执行实际操作结果再回到模型。如果任务没有完成模型会重新规划。官方没有随模型仓库提供该演示的完整工程快照、提示词、权限配置和机器环境。我们只能把它当作官方演示不能据此推断普通电脑一定能复现相同速度与成功率。这次开放了哪些东西官方模型集合目前有四类工件。工件公开内容适合用途Muse-Glimmer-30BBF16 safetensors、tokenizer、配置、聊天模板完整精度推理、研究和微调Muse-Glimmer-30B-GGUF两个 K-Quant 主模型、视觉投影器、DFlash drafterllama.cpp 本地推理Muse-Glimmer-30B-ExecuTorch-PTENVIDIA CUDA 与 Apple Metal 预导出工件端侧优化和运行时研究Muse-Glimmer-30B-assistantDFlash drafter 权重推测解码加速运行实现也已经进入开源上游。llama.cpp 在 2026 年 8 月 10 日合并了 Muse Glimmer 的文本、视觉、GGUF 转换和聊天解析支持。Transformers 5.15.0 加入了模型结构、处理器和 DFlash assistant 实现。ExecuTorch 则公开了模型导出、视觉预处理、服务端和运行器代码。没有确认开放的内容包括完整预训练代码、精确训练集清单、数据比例、训练 token 数、奖励模型、后训练数据和全套评测脚手架。Meta 公开了训练分为预训练、中期训练和后训练也说明使用 Muse Spark 输出进行蒸馏。这些资料足以理解方法仍不足以从头复现训练。24 GB 显存到底意味着什么官方 GGUF 仓库给出了四个关键文件。文件文件大小作用muse-glimmer-30B-kquant-17gb.gguf16.8 GB推荐的文本主模型muse-glimmer-30B-kquant-dynamic.gguf19.7 GB更高质量的量化主模型mmproj-kquant.gguf1.4 GB图片输入需要的视觉投影器dflash-kquant.gguf1.6 GB可选的推测解码草稿模型17 GB 版做纯文本时官方估算模型内存约 17 GB。加上视觉投影器和 drafter 后约为 20 GB。剩余空间还要容纳上下文、驱动和系统开销所以官方把目标硬件写成 24 GB。Dynamic 版的对应数字约为 20 GB 与 23 GB更适合 32 GB 显存或统一内存。BF16 权重本身超过 55 GB官方给出的目标是 64 GB VRAM。官方把 24 GB 列为量化路线的目标容量。具体能否稳定运行还会受到上下文长度、并发数和推理后端影响。8 GB 与 12 GB 显卡不在官方全量 GPU 推理的舒适区间。纯 CPU 可以构建 llama.cppMeta 没有承诺普通消费级 CPU 能达到流畅交互速度。第一次安装建议走 GGUF 路线初学者可以先用 llama.cpp 加 17 GB 量化模型。这样不需要一开始处理 BF16 分片、Transformers 开发版本和复杂的 ExecuTorch 导出流程。先准备这些条件至少 24 GB 可用显存或 Apple 统一内存至少 25 GB 空闲磁盘若保留多个量化版本需要更多空间llama.cppb10353或更新版本用于下载模型的 Python 与 Hugging Face CLIWindows 使用支持所选后端的显卡驱动macOS 推荐 Apple SiliconLinux 根据显卡选择 CUDA 或其他后端如果改走 Transformers 路线当前正式支持版本为 5.15.0。该版本要求 Python 3.10 或更新版本、PyTorch 2.5 或更新版本。官方没有为 Muse Glimmer 单独钉死 CUDA 版本实际组合要跟随显卡驱动与 PyTorch 或 llama.cpp 的发行包。选择预编译包或从源码构建第一次尝试可以直接使用 llama.cppb10353或更新的 Release。Windows 要按显卡和驱动选择 CUDA、Vulkan、HIP 或 CPU 包。macOS Apple Silicon 选择 arm64 包。Linux 也可以使用对应的预编译产物。需要自行构建时Linux 的 NVIDIA CUDA 路线可使用官方模型卡中的命令。gitclone https://github.com/ggml-org/llama.cppcdllama.cpp cmake-Bbuild-DBUILD_SHARED_LIBSOFF-DGGML_CUDAON cmake--buildbuild--configRelease-j\--targetllama-cli llama-mtmd-cli llama-servermacOS Apple Silicon 省略-DGGML_CUDAONMetal 默认启用。cmake-Bbuild-DBUILD_SHARED_LIBSOFF cmake--buildbuild--configRelease-j\--targetllama-cli llama-mtmd-cli llama-serverWindows PowerShell 使用同一套 CMake 参数Visual Studio 生成器通常会把程序放到build\bin\Release\。git clone https://github.com/ggml-org/llama.cppSet-Locationllama.cppcmake-B build-DBUILD_SHARED_LIBSOFF-DGGML_CUDAON cmake--build build--config Release-j --target llama-clillama-mtmd-clillama-server下载前先看清文件大小下面的 Bash 命令适用于 Linux 和 macOS。第一条hf download只预览文件不开始下载。python3-mpipinstallhuggingface_hub hf download meta-models/Muse-Glimmer-30B-GGUF\--local-dir Muse-Glimmer-30B-GGUF\--includemuse-glimmer-30B-kquant-17gb.gguf\--dry-run hf download meta-models/Muse-Glimmer-30B-GGUF\--local-dir Muse-Glimmer-30B-GGUF\--includemuse-glimmer-30B-kquant-17gb.ggufWindows PowerShell 使用反引号续行。py-m pip install huggingface_hub hf download meta-models/Muse-Glimmer-30B-GGUF --local-dirMuse-Glimmer-30B-GGUF --includemuse-glimmer-30B-kquant-17gb.gguf--dry-run hf download meta-models/Muse-Glimmer-30B-GGUF --local-dirMuse-Glimmer-30B-GGUF --includemuse-glimmer-30B-kquant-17gb.gguf第一次只做文本测试可以暂时不下载mmproj-kquant.gguf与dflash-kquant.gguf。公开模型本身不要求 API Key。若你的 Hugging Face 工作流确实需要账号 token请把它放在本机凭据或环境变量中示例值写成YOUR_HF_TOKEN不要硬编码进脚本和截图。检查 llama.cpp 版本./llama-cli--versionWindows 预编译包通常使用下面的形式。.\llama-cli.exe--version输出里的 build number 需要大于或等于 10353。自行编译时Linux 和 macOS 可执行文件常见于build/bin/Windows Release 构建常见于build\bin\Release\。命令中的路径要按你实际下载或编译的位置调整。完成最小文本测试Linux 和 macOS 可以运行下面的官方参数组合。./llama-cli\-mMuse-Glimmer-30B-GGUF/muse-glimmer-30B-kquant-17gb.gguf\-ngl99-c32768\--jinja\--temp1.0--top-p0.95--top-k64Windows PowerShell 的写法如下。.\llama-cli.exe -m.\Muse-Glimmer-30B-GGUF\muse-glimmer-30B-kquant-17gb.gguf -ngl 99-c 32768 --jinja --temp 1.0--top-p 0.95--top-k 64-ngl 99会尝试把模型层放到 GPU。若你使用 CPU 路线需要按 llama.cpp 的后端说明调整。--jinja不能省略模型依赖 GGUF 内嵌的聊天模板。只想跑一次问答时可以加入-st或--single-turn。稳定后再加入图片图片输入需要额外下载mmproj-kquant.gguf并改用llama-mtmd-cli。先用前面的hf download命令把--include文件名换成mmproj-kquant.gguf再运行下面的命令。./llama-mtmd-cli\-mMuse-Glimmer-30B-GGUF/muse-glimmer-30B-kquant-17gb.gguf\--mmprojMuse-Glimmer-30B-GGUF/mmproj-kquant.gguf\-ngl99-c32768\--jinja\--temp1.0--top-p0.95--top-k64\--imagepublic-sample.png-pDescribe this image.第一次测试请使用不含个人信息的公开图片。模型输出需要人工核对尤其是表格数字、界面按钮与小字号文字。首发阶段最容易踩的坑Muse Glimmer 发布仅一天上游仍在快速修补。下面这些问题都能在官方说明或公开 Issue 中找到依据。旧版 llama.cpp 不认识新架构Muse Glimmer 支持刚在 2026 年 8 月 10 日合并。b10344及更早版本会拒绝加载常见信息包含unknown model architecture。先查 build number往往比反复修改模型路径更有效。忘记--jinja会破坏聊天模板模型的工具、推理和多轮消息都依赖自定义模板。官方 GGUF 说明明确要求开启 Jinja。模板开关缺失时多模态命令会直接提示自定义模板不受支持。交互程序等待输入看起来像卡住llama-cli默认会继续等待下一轮消息。单轮脚本可以加-st。这个现象和模型加载失败不同先看终端是否已经给出上一轮回答。图片命令用错了程序普通llama-cli只走文本路径。图片需要llama-mtmd-cli和mmproj-kquant.gguf。视觉投影器还会增加持续显存占用。llama.cpp Issue #26873 在一套双卡环境中报告了额外约 1.1 GB 占用和 prefill 下降。这是单一环境记录实际影响要在自己的机器上核对因此视觉测试适合放在文本之后。131K 上下文会被并发 slot 拆分llama-server会把-c指定的总上下文分给-np个 slot。若设置-c 131072 -np 4单个请求实际只有 32768。提高总上下文还会增加 KV cache 内存不能只盯着权重文件大小。DFlash 适合最后再加截至核对日期llama.cpp Issue #26894 仍在报告官方 dynamic GGUF 配合 drafter 时的崩溃问题。工具调用漏检的修复 PR #26879 当时也尚未合并。先验证主模型文本再加视觉最后才尝试 DFlash 与工具调用排查范围会小很多。性能表应该怎样读Meta 把 Muse Glimmer-30B 与 Gemma4-31B、Qwen3.6-27B 的思考模式做了比较。Muse Glimmer 在 MCP Atlas Public 得到 75.5在 DeepSearch QA 得到 74.6在 SWE-Bench Pro 得到 51.2在 CharXiv Reasoning 得到 78.8这些项目里它处于领先位置。同一张表里也有落后的项目。Qwen3.6-27B 在 OSWorld-Verified、SWE-Bench Verified、TerminalBench 2.1、ScreenSpot Pro、OmniDocBench 和 MMMU Pro 上更高。Gemma4-31B 在 GPQA Diamond 与 HLE Text 上更高。安全指标也不应跳过。CI Memories 的 violation 越低越好Muse Glimmer 为 26.4Gemma4-31B 为 12.1。Siren AgentDojo 的攻击成功率同样越低越好Muse Glimmer 为 28.4Gemma4-31B 为 25.6。这些结果说明 Muse Glimmer 在本地智能体和部分编程任务上有竞争力也说明它没有全面领先更没有解决提示词注入和隐私信息流问题。Meta 的比较使用指定脚手架、系统提示和采样配置。换一套智能体框架后排名可能改变。成本、隐私与许可证要一起算本地权重没有按次调用费机器仍然有成本Meta 没有对本地权重收取按 token 费用。你仍要承担至少约 17 GB 的下载、更多磁盘缓存、24 GB 级硬件、电力和散热成本。使用 Together AI、Fireworks AI、OpenRouter 等第三方托管服务时还要单独查看服务地区、API 价格和数据政策。模型许可证不会替你支付第三方服务费。本地推理只能保护留在本机的那部分数据权重、提示词、图片和工具都在本机时推理可以不经过模型云服务。一旦智能体接入网页搜索、邮件、日历、云盘或外部 API相关内容仍可能离开设备。日志、缓存和遥测也要纳入检查。第一次实践只给一个测试目录优先提供只读或可撤销的工具。删除文件、发送消息、付款、提交代码和部署服务都应保留人工确认。来源不可信的网页和文档里可能藏有提示词注入也不能直接让模型照做。Apache 2.0 之外还有使用政策官方权重、量化版本、drafter 和感知编码器标记为 Apache License 2.0。商业使用、修改与再分发需要遵守许可证要求包括提供许可证副本、标记修改和保留相关声明。模型仓库还提供 Muse Glimmer Usage Policy。它覆盖违法活动、恶意代码、未经授权处理敏感个人信息、欺诈、冒充和高风险用途等限制并写明模型不面向 18 岁以下个人下载或使用。Apache 2.0 解决模型工件的许可问题。输入文件权利、训练数据争议、输出版权、第三方工具条款和行业监管仍要分别处理。这里是一般性提醒不能替代法律意见。优点很具体限制也很现实观察角度我的判断本地部署17 GB 量化权重把 30B 稠密模型放进 24 GB 消费级硬件范围多模态文本、图片、长上下文和工具调用进入同一条智能体流程开放程度权重、配置、GGUF、PTE 与运行时代码齐全完整训练流程没有公开上手成本官方命令清楚17 GB 下载和 24 GB 硬件仍是明显门槛运行成熟度llama.cpp 与 Transformers 已支持首发兼容问题仍在修复隐私纯本地推理可减少云端传输外部工具会重新引入数据外流可靠性部分智能体基准表现突出多步推理、事实和工具权限仍需人工检查我更看重它的工程组合。量化主模型、视觉投影器、聊天模板、工具解析和 DFlash 都有公开入口学生可以沿着一次真实推理怎样落地到运行时来读源码。它的硬件目标覆盖一部分高配个人电脑。普通轻薄本和 8 GB 显卡用户很难按官方目标完整运行。想研究从数据到训练的完整复现流程这个发布也提供不了足够材料。哪些初学者适合从它开始比较适合已经有 24 GB 显存显卡或 24 GB 以上 Apple 统一内存学过基础 Python 或终端命令想了解本地多模态智能体的读者。对函数调用、长上下文、视觉编码器、GGUF 或推测解码感兴趣的学生也能从这次发布里找到清晰的源码入口。只有 8 GB 或 12 GB 显存、希望点开网页立即使用、需要音频或原生视频能力的人可以先关注更小的模型。需要 AI 自动操作真实邮件、财务账户、生产服务器和唯一文件的场景也不适合作为第一次实验。推荐按这条线读源码Muse Glimmer 的学习入口分布在 Hugging Face 与几个上游仓库里。建议按由浅入深的顺序阅读。官方模型卡 README 先看用途、结构、性能和风险。官方 GGUF README 对照文件组合、下载命令、Jinja、上下文 slot 与 reasoning 参数。config.json找到 52 层、局部与全局注意力、2 个 KV 头和 131,072 上下文。chat_template.jinja观察用户消息、工具定义和 ATEM 调用怎样编码。examples/models/muse-glimmer/model/model.py阅读文本模型、注意力和 KV cache。examples/models/muse-glimmer/model/dflash_model.py理解 drafter 怎样使用主模型隐藏状态。examples/models/muse-glimmer/serving/serve.py看 OpenAI 兼容服务、图片限制和推理内容分流。serving/tool_parsers/atem.py看工具参数怎样从模型文本变成结构化调用。src/models/muse-glimmer.cpp继续追踪 llama.cpp 的文本推理图。tools/mtmd/models/muse-glimmer.cpp理解视觉投影器接入路径。ExecuTorch 代码使用 BSD 风格许可证Transformers 使用 Apache 2.0llama.cpp 使用 MIT。复制代码时要查看各自仓库的许可证不能用模型权重的 Apache 2.0 统一概括。第一次实践只做一件小事建议把目标设成“让模型在本地完成一次可人工核对的文本问答”。具体做法很简单。确认机器有 24 GB 可用显存或统一内存并预留至少 25 GB 磁盘。安装b10353或更新的 llama.cpp只下载 17 GB 主模型。用 32K 上下文解释一段不含隐私的短代码暂时不加载图片、DFlash 和任何工具。记录 build number、模型文件名、上下文长度、加载时间、显存占用和输出中的明显错误。基础文本稳定后再加入一张公开图片。视觉稳定后再研究本地只读工具。每次只增加一个变量首发阶段遇到问题时会容易判断来源。如果你想继续从“模型能回答”走到“模型能安全地做事”可以关注《GitHub小白开源成长课》。后续还会继续拆解智能体框架、工具权限、多模态运行时和本地模型部署项目。关键官方参考资料Meta 官方发布页Muse Glimmer 官方模型集合BF16 权重与模型卡官方 GGUF 权重与运行说明官方 ExecuTorch PTE 工件Muse Glimmer 评测方法报告Muse Glimmer Usage Policyllama.cpp Muse Glimmer 支持 PRllama.cpp b10353 Releasellama.cpp DFlash 问题记录llama.cpp 视觉投影器问题记录llama.cpp 工具调用修复 PRTransformers Muse Glimmer 支持 PRTransformers 5.15.0 ReleaseExecuTorch Muse Glimmer 源码入口Perception Encoder 论文DFlash 论文人工智能开源GitHub大模型本地部署智能体多模态llama.cppMetaMuse Glimmer Meta Muse Glimmer 30B 小白入门｜开放权重与 24GB 显存本地部署
Meta Muse Glimmer 30B 小白入门开放权重与 24GB 显存本地部署假设你把一张智能家居面板截图交给 AI让它读懂界面、修改代码、调用工具检查结果碰到失败后再换一种办法。过去这类任务通常依赖云端大模型。Meta 新发布的 Muse Glimmer 30B 把目标放在个人电脑上希望模型在本地完成长时间推理、看图和工具调用。这次发布有一个清楚的工程进展。约 300 亿参数的稠密多模态模型经过量化进入了 24 GB 消费级显存的范围。这个门槛仍然不低却已经让高性能本地智能体从专业服务器走向部分个人工作站。 专栏介绍 《GitHub小白开源成长课》这个专栏写给计算机初学者、大学生和刚接触 AI 开源项目的读者。每篇文章挑一个值得动手的 GitHub 项目读源码查依赖也把费用、许可证和使用边界讲清楚。读完以后你至少能判断这个项目解决什么问题自己能不能跑以及下一步该从哪个文件学起。如果你正在从“会收藏项目”走向“能读懂项目”可以关注这个专栏。后面还会继续拆解 AI 编程、科研工具、多智能体和 AI 内容创作方向的开源项目。先交代这篇文章的核验范围本文核对日期为 2026 年 8 月 11 日。资料来自 Meta 官方发布页、官方 Hugging Face 模型卡与配置、Meta 的评测方法报告以及 Transformers、llama.cpp、ExecuTorch 的公开源码和问题记录。首先要先澄清一个容易混淆的点。Muse Glimmer 没有同名的 Meta 官方 GitHub 独立仓库。模型权重和配置放在 Hugging FaceGitHub 上可以阅读 Transformers、llama.cpp 与 ExecuTorch 的适配代码。日常交流里可以称它为开源模型严谨一些则应称为 Apache 2.0 开放权重模型因为 Meta 没有公开完整训练代码、精确训练数据清单和全套训练管线。一分钟看懂 Muse Glimmer 30B项目2026 年 8 月 11 日核验结果发布机构Meta Superintelligence Labs发布时间2026 年 8 月 10 日参数规模约 29.6BHugging Face 元数据为 29,776,626,688输入与输出文本和图像输入文本输出上下文长度131,072 及以上公开配置写明 131,072知识截止日期2026 年 1 月 4 日主要用途本地智能体、编程、函数调用、图像理解、模型评测量化硬件目标17 GB 版面向 24 GB 显存或统一内存Dynamic 版面向 32 GB完整精度目标64 GB VRAM模型许可证Apache License 2.0另有 Muse Glimmer Usage Policy官方入口Hugging Face 模型集合与 Meta 官方发布页它和 Google Research 的文本生成图像模型 Muse、Microsoft 的游戏世界模型 Muse、Meta 早年的 MUSE 词向量项目都没有关系。Muse Spark 是它的教师模型之一也不能和可下载的 Muse Glimmer 混为一谈。它想解决云端智能体的哪块麻烦智能体比普通聊天机器人多了一层行动能力。它会拆任务、选择工具、读回执行结果再决定下一步。这样的系统若长期依赖云端会遇到网络可用性、调用费用、数据传输和响应延迟等问题。Muse Glimmer 面向本地常驻工作流。官方列出的能力包括多步规划、结构化函数调用、失败恢复、长上下文处理和图片理解。适合它的任务可以是阅读截图后定位界面问题也可以是让编程智能体在测试目录里修改代码、运行测试并解释结果。模型本身只会生成文本和工具调用参数。文件是否真的被改动邮件是否真的发出取决于外部智能体框架给了它哪些工具和权限。这条边界非常重要也是部署时最容易被忽略的地方。小白也能读懂的模型工作方式图片先被翻译成模型能读的 tokenMuse Glimmer 带有一个约 1.8B 参数的 ViT-G/14 感知编码器。图片会被切成小块转成视觉特征再投影到语言模型能够接收的表示空间。公开配置把单张图片的上限写为 4096 个视觉 token。这意味着模型可以把截图、图表和文档图片同文字放在一个上下文里推理。它最后只输出文字不会直接生成图片也不支持音频输入输出。模型卡还提醒视频没有经过专门优化部分运行时会直接关闭视频入口。52 层 Transformer 怎样省下长上下文成本主模型是一套 52 层稠密因果 Transformer。源码里的注意力安排很有特点三个 2048 窗口的局部注意力层后面跟一个全局注意力层然后继续循环。局部层主要观察附近内容计算量更容易控制。全局层定期把更远的信息串起来。模型还使用 32 个查询头和 2 个 KV 头减少长上下文 KV cache 的体积。这样的结构让 131,072 token 上下文更适合本地设备但长上下文仍会消耗额外内存配置里的上限不代表每台机器都能轻松用满。工具调用需要模板和解析器共同工作模型会按照 ATEM 格式生成函数名和参数。chat_template.jinja负责把系统消息、用户消息与工具定义整理成模型认识的输入ExecuTorch 的serving/tool_parsers/atem.py再把模型输出转换为 OpenAI 兼容的tool_calls。源码对未定义工具、格式损坏和参数类型都做了处理。工具调用要靠权重、聊天模板、解析器和运行时共同完成。缺少其中一块智能体都可能只吐出一段难以解析的控制文本。DFlash 用一个小模型帮主模型打草稿普通自回归模型每次向后生成一个 token。Muse Glimmer 另外提供 DFlash drafter它能一次提出一块候选 token默认块大小为 16。主模型并行检查这些候选接受正确部分再修正错误部分。官方报告显示17 GB 量化主模型加 DFlash 后RTX 5090 的解码速度从 74.9 tok/s 提升到 233.4 tok/sM4 Max 从 23.7 提升到 37.8 tok/sM5 Max 从 26.6 提升到 50.2 tok/s。测试使用 batch size 1 和 greedy decoding。硬件、上下文、任务与后端换掉后速度也会变化。官方案例里模型怎样完成一项任务Meta 发布页展示了一个 OpenCode 中的 Home Assistant 仪表板任务。演示里的模型需要理解目标编写或修改代码调用工具查看结果并在遇到问题后继续调整。这个案例适合用来理解本地智能体的完整链条。用户给出目标框架整理上下文模型规划下一步工具执行实际操作结果再回到模型。如果任务没有完成模型会重新规划。官方没有随模型仓库提供该演示的完整工程快照、提示词、权限配置和机器环境。我们只能把它当作官方演示不能据此推断普通电脑一定能复现相同速度与成功率。这次开放了哪些东西官方模型集合目前有四类工件。工件公开内容适合用途Muse-Glimmer-30BBF16 safetensors、tokenizer、配置、聊天模板完整精度推理、研究和微调Muse-Glimmer-30B-GGUF两个 K-Quant 主模型、视觉投影器、DFlash drafterllama.cpp 本地推理Muse-Glimmer-30B-ExecuTorch-PTENVIDIA CUDA 与 Apple Metal 预导出工件端侧优化和运行时研究Muse-Glimmer-30B-assistantDFlash drafter 权重推测解码加速运行实现也已经进入开源上游。llama.cpp 在 2026 年 8 月 10 日合并了 Muse Glimmer 的文本、视觉、GGUF 转换和聊天解析支持。Transformers 5.15.0 加入了模型结构、处理器和 DFlash assistant 实现。ExecuTorch 则公开了模型导出、视觉预处理、服务端和运行器代码。没有确认开放的内容包括完整预训练代码、精确训练集清单、数据比例、训练 token 数、奖励模型、后训练数据和全套评测脚手架。Meta 公开了训练分为预训练、中期训练和后训练也说明使用 Muse Spark 输出进行蒸馏。这些资料足以理解方法仍不足以从头复现训练。24 GB 显存到底意味着什么官方 GGUF 仓库给出了四个关键文件。文件文件大小作用muse-glimmer-30B-kquant-17gb.gguf16.8 GB推荐的文本主模型muse-glimmer-30B-kquant-dynamic.gguf19.7 GB更高质量的量化主模型mmproj-kquant.gguf1.4 GB图片输入需要的视觉投影器dflash-kquant.gguf1.6 GB可选的推测解码草稿模型17 GB 版做纯文本时官方估算模型内存约 17 GB。加上视觉投影器和 drafter 后约为 20 GB。剩余空间还要容纳上下文、驱动和系统开销所以官方把目标硬件写成 24 GB。Dynamic 版的对应数字约为 20 GB 与 23 GB更适合 32 GB 显存或统一内存。BF16 权重本身超过 55 GB官方给出的目标是 64 GB VRAM。官方把 24 GB 列为量化路线的目标容量。具体能否稳定运行还会受到上下文长度、并发数和推理后端影响。8 GB 与 12 GB 显卡不在官方全量 GPU 推理的舒适区间。纯 CPU 可以构建 llama.cppMeta 没有承诺普通消费级 CPU 能达到流畅交互速度。第一次安装建议走 GGUF 路线初学者可以先用 llama.cpp 加 17 GB 量化模型。这样不需要一开始处理 BF16 分片、Transformers 开发版本和复杂的 ExecuTorch 导出流程。先准备这些条件至少 24 GB 可用显存或 Apple 统一内存至少 25 GB 空闲磁盘若保留多个量化版本需要更多空间llama.cppb10353或更新版本用于下载模型的 Python 与 Hugging Face CLIWindows 使用支持所选后端的显卡驱动macOS 推荐 Apple SiliconLinux 根据显卡选择 CUDA 或其他后端如果改走 Transformers 路线当前正式支持版本为 5.15.0。该版本要求 Python 3.10 或更新版本、PyTorch 2.5 或更新版本。官方没有为 Muse Glimmer 单独钉死 CUDA 版本实际组合要跟随显卡驱动与 PyTorch 或 llama.cpp 的发行包。选择预编译包或从源码构建第一次尝试可以直接使用 llama.cppb10353或更新的 Release。Windows 要按显卡和驱动选择 CUDA、Vulkan、HIP 或 CPU 包。macOS Apple Silicon 选择 arm64 包。Linux 也可以使用对应的预编译产物。需要自行构建时Linux 的 NVIDIA CUDA 路线可使用官方模型卡中的命令。gitclone https://github.com/ggml-org/llama.cppcdllama.cpp cmake-Bbuild-DBUILD_SHARED_LIBSOFF-DGGML_CUDAON cmake--buildbuild--configRelease-j\--targetllama-cli llama-mtmd-cli llama-servermacOS Apple Silicon 省略-DGGML_CUDAONMetal 默认启用。cmake-Bbuild-DBUILD_SHARED_LIBSOFF cmake--buildbuild--configRelease-j\--targetllama-cli llama-mtmd-cli llama-serverWindows PowerShell 使用同一套 CMake 参数Visual Studio 生成器通常会把程序放到build\bin\Release\。git clone https://github.com/ggml-org/llama.cppSet-Locationllama.cppcmake-B build-DBUILD_SHARED_LIBSOFF-DGGML_CUDAON cmake--build build--config Release-j --target llama-clillama-mtmd-clillama-server下载前先看清文件大小下面的 Bash 命令适用于 Linux 和 macOS。第一条hf download只预览文件不开始下载。python3-mpipinstallhuggingface_hub hf download meta-models/Muse-Glimmer-30B-GGUF\--local-dir Muse-Glimmer-30B-GGUF\--includemuse-glimmer-30B-kquant-17gb.gguf\--dry-run hf download meta-models/Muse-Glimmer-30B-GGUF\--local-dir Muse-Glimmer-30B-GGUF\--includemuse-glimmer-30B-kquant-17gb.ggufWindows PowerShell 使用反引号续行。py-m pip install huggingface_hub hf download meta-models/Muse-Glimmer-30B-GGUF --local-dirMuse-Glimmer-30B-GGUF --includemuse-glimmer-30B-kquant-17gb.gguf--dry-run hf download meta-models/Muse-Glimmer-30B-GGUF --local-dirMuse-Glimmer-30B-GGUF --includemuse-glimmer-30B-kquant-17gb.gguf第一次只做文本测试可以暂时不下载mmproj-kquant.gguf与dflash-kquant.gguf。公开模型本身不要求 API Key。若你的 Hugging Face 工作流确实需要账号 token请把它放在本机凭据或环境变量中示例值写成YOUR_HF_TOKEN不要硬编码进脚本和截图。检查 llama.cpp 版本./llama-cli--versionWindows 预编译包通常使用下面的形式。.\llama-cli.exe--version输出里的 build number 需要大于或等于 10353。自行编译时Linux 和 macOS 可执行文件常见于build/bin/Windows Release 构建常见于build\bin\Release\。命令中的路径要按你实际下载或编译的位置调整。完成最小文本测试Linux 和 macOS 可以运行下面的官方参数组合。./llama-cli\-mMuse-Glimmer-30B-GGUF/muse-glimmer-30B-kquant-17gb.gguf\-ngl99-c32768\--jinja\--temp1.0--top-p0.95--top-k64Windows PowerShell 的写法如下。.\llama-cli.exe -m.\Muse-Glimmer-30B-GGUF\muse-glimmer-30B-kquant-17gb.gguf -ngl 99-c 32768 --jinja --temp 1.0--top-p 0.95--top-k 64-ngl 99会尝试把模型层放到 GPU。若你使用 CPU 路线需要按 llama.cpp 的后端说明调整。--jinja不能省略模型依赖 GGUF 内嵌的聊天模板。只想跑一次问答时可以加入-st或--single-turn。稳定后再加入图片图片输入需要额外下载mmproj-kquant.gguf并改用llama-mtmd-cli。先用前面的hf download命令把--include文件名换成mmproj-kquant.gguf再运行下面的命令。./llama-mtmd-cli\-mMuse-Glimmer-30B-GGUF/muse-glimmer-30B-kquant-17gb.gguf\--mmprojMuse-Glimmer-30B-GGUF/mmproj-kquant.gguf\-ngl99-c32768\--jinja\--temp1.0--top-p0.95--top-k64\--imagepublic-sample.png-pDescribe this image.第一次测试请使用不含个人信息的公开图片。模型输出需要人工核对尤其是表格数字、界面按钮与小字号文字。首发阶段最容易踩的坑Muse Glimmer 发布仅一天上游仍在快速修补。下面这些问题都能在官方说明或公开 Issue 中找到依据。旧版 llama.cpp 不认识新架构Muse Glimmer 支持刚在 2026 年 8 月 10 日合并。b10344及更早版本会拒绝加载常见信息包含unknown model architecture。先查 build number往往比反复修改模型路径更有效。忘记--jinja会破坏聊天模板模型的工具、推理和多轮消息都依赖自定义模板。官方 GGUF 说明明确要求开启 Jinja。模板开关缺失时多模态命令会直接提示自定义模板不受支持。交互程序等待输入看起来像卡住llama-cli默认会继续等待下一轮消息。单轮脚本可以加-st。这个现象和模型加载失败不同先看终端是否已经给出上一轮回答。图片命令用错了程序普通llama-cli只走文本路径。图片需要llama-mtmd-cli和mmproj-kquant.gguf。视觉投影器还会增加持续显存占用。llama.cpp Issue #26873 在一套双卡环境中报告了额外约 1.1 GB 占用和 prefill 下降。这是单一环境记录实际影响要在自己的机器上核对因此视觉测试适合放在文本之后。131K 上下文会被并发 slot 拆分llama-server会把-c指定的总上下文分给-np个 slot。若设置-c 131072 -np 4单个请求实际只有 32768。提高总上下文还会增加 KV cache 内存不能只盯着权重文件大小。DFlash 适合最后再加截至核对日期llama.cpp Issue #26894 仍在报告官方 dynamic GGUF 配合 drafter 时的崩溃问题。工具调用漏检的修复 PR #26879 当时也尚未合并。先验证主模型文本再加视觉最后才尝试 DFlash 与工具调用排查范围会小很多。性能表应该怎样读Meta 把 Muse Glimmer-30B 与 Gemma4-31B、Qwen3.6-27B 的思考模式做了比较。Muse Glimmer 在 MCP Atlas Public 得到 75.5在 DeepSearch QA 得到 74.6在 SWE-Bench Pro 得到 51.2在 CharXiv Reasoning 得到 78.8这些项目里它处于领先位置。同一张表里也有落后的项目。Qwen3.6-27B 在 OSWorld-Verified、SWE-Bench Verified、TerminalBench 2.1、ScreenSpot Pro、OmniDocBench 和 MMMU Pro 上更高。Gemma4-31B 在 GPQA Diamond 与 HLE Text 上更高。安全指标也不应跳过。CI Memories 的 violation 越低越好Muse Glimmer 为 26.4Gemma4-31B 为 12.1。Siren AgentDojo 的攻击成功率同样越低越好Muse Glimmer 为 28.4Gemma4-31B 为 25.6。这些结果说明 Muse Glimmer 在本地智能体和部分编程任务上有竞争力也说明它没有全面领先更没有解决提示词注入和隐私信息流问题。Meta 的比较使用指定脚手架、系统提示和采样配置。换一套智能体框架后排名可能改变。成本、隐私与许可证要一起算本地权重没有按次调用费机器仍然有成本Meta 没有对本地权重收取按 token 费用。你仍要承担至少约 17 GB 的下载、更多磁盘缓存、24 GB 级硬件、电力和散热成本。使用 Together AI、Fireworks AI、OpenRouter 等第三方托管服务时还要单独查看服务地区、API 价格和数据政策。模型许可证不会替你支付第三方服务费。本地推理只能保护留在本机的那部分数据权重、提示词、图片和工具都在本机时推理可以不经过模型云服务。一旦智能体接入网页搜索、邮件、日历、云盘或外部 API相关内容仍可能离开设备。日志、缓存和遥测也要纳入检查。第一次实践只给一个测试目录优先提供只读或可撤销的工具。删除文件、发送消息、付款、提交代码和部署服务都应保留人工确认。来源不可信的网页和文档里可能藏有提示词注入也不能直接让模型照做。Apache 2.0 之外还有使用政策官方权重、量化版本、drafter 和感知编码器标记为 Apache License 2.0。商业使用、修改与再分发需要遵守许可证要求包括提供许可证副本、标记修改和保留相关声明。模型仓库还提供 Muse Glimmer Usage Policy。它覆盖违法活动、恶意代码、未经授权处理敏感个人信息、欺诈、冒充和高风险用途等限制并写明模型不面向 18 岁以下个人下载或使用。Apache 2.0 解决模型工件的许可问题。输入文件权利、训练数据争议、输出版权、第三方工具条款和行业监管仍要分别处理。这里是一般性提醒不能替代法律意见。优点很具体限制也很现实观察角度我的判断本地部署17 GB 量化权重把 30B 稠密模型放进 24 GB 消费级硬件范围多模态文本、图片、长上下文和工具调用进入同一条智能体流程开放程度权重、配置、GGUF、PTE 与运行时代码齐全完整训练流程没有公开上手成本官方命令清楚17 GB 下载和 24 GB 硬件仍是明显门槛运行成熟度llama.cpp 与 Transformers 已支持首发兼容问题仍在修复隐私纯本地推理可减少云端传输外部工具会重新引入数据外流可靠性部分智能体基准表现突出多步推理、事实和工具权限仍需人工检查我更看重它的工程组合。量化主模型、视觉投影器、聊天模板、工具解析和 DFlash 都有公开入口学生可以沿着一次真实推理怎样落地到运行时来读源码。它的硬件目标覆盖一部分高配个人电脑。普通轻薄本和 8 GB 显卡用户很难按官方目标完整运行。想研究从数据到训练的完整复现流程这个发布也提供不了足够材料。哪些初学者适合从它开始比较适合已经有 24 GB 显存显卡或 24 GB 以上 Apple 统一内存学过基础 Python 或终端命令想了解本地多模态智能体的读者。对函数调用、长上下文、视觉编码器、GGUF 或推测解码感兴趣的学生也能从这次发布里找到清晰的源码入口。只有 8 GB 或 12 GB 显存、希望点开网页立即使用、需要音频或原生视频能力的人可以先关注更小的模型。需要 AI 自动操作真实邮件、财务账户、生产服务器和唯一文件的场景也不适合作为第一次实验。推荐按这条线读源码Muse Glimmer 的学习入口分布在 Hugging Face 与几个上游仓库里。建议按由浅入深的顺序阅读。官方模型卡 README 先看用途、结构、性能和风险。官方 GGUF README 对照文件组合、下载命令、Jinja、上下文 slot 与 reasoning 参数。config.json找到 52 层、局部与全局注意力、2 个 KV 头和 131,072 上下文。chat_template.jinja观察用户消息、工具定义和 ATEM 调用怎样编码。examples/models/muse-glimmer/model/model.py阅读文本模型、注意力和 KV cache。examples/models/muse-glimmer/model/dflash_model.py理解 drafter 怎样使用主模型隐藏状态。examples/models/muse-glimmer/serving/serve.py看 OpenAI 兼容服务、图片限制和推理内容分流。serving/tool_parsers/atem.py看工具参数怎样从模型文本变成结构化调用。src/models/muse-glimmer.cpp继续追踪 llama.cpp 的文本推理图。tools/mtmd/models/muse-glimmer.cpp理解视觉投影器接入路径。ExecuTorch 代码使用 BSD 风格许可证Transformers 使用 Apache 2.0llama.cpp 使用 MIT。复制代码时要查看各自仓库的许可证不能用模型权重的 Apache 2.0 统一概括。第一次实践只做一件小事建议把目标设成“让模型在本地完成一次可人工核对的文本问答”。具体做法很简单。确认机器有 24 GB 可用显存或统一内存并预留至少 25 GB 磁盘。安装b10353或更新的 llama.cpp只下载 17 GB 主模型。用 32K 上下文解释一段不含隐私的短代码暂时不加载图片、DFlash 和任何工具。记录 build number、模型文件名、上下文长度、加载时间、显存占用和输出中的明显错误。基础文本稳定后再加入一张公开图片。视觉稳定后再研究本地只读工具。每次只增加一个变量首发阶段遇到问题时会容易判断来源。如果你想继续从“模型能回答”走到“模型能安全地做事”可以关注《GitHub小白开源成长课》。后续还会继续拆解智能体框架、工具权限、多模态运行时和本地模型部署项目。关键官方参考资料Meta 官方发布页Muse Glimmer 官方模型集合BF16 权重与模型卡官方 GGUF 权重与运行说明官方 ExecuTorch PTE 工件Muse Glimmer 评测方法报告Muse Glimmer Usage Policyllama.cpp Muse Glimmer 支持 PRllama.cpp b10353 Releasellama.cpp DFlash 问题记录llama.cpp 视觉投影器问题记录llama.cpp 工具调用修复 PRTransformers Muse Glimmer 支持 PRTransformers 5.15.0 ReleaseExecuTorch Muse Glimmer 源码入口Perception Encoder 论文DFlash 论文人工智能开源GitHub大模型本地部署智能体多模态llama.cppMetaMuse Glimmer