Meta 的 Muse Glimmer 把 300 亿参数 Agent 模型压进了 24 GB 硬件包络。K-Quant-17GB 权重之外，还能容纳 KV cache、18 亿参数视觉编码器和 DFlash 推测解码 drafter。这项系统进展很实在：多模态、可调用工具的 Agent 开始从云端依赖变成个人和小团队可以实际拥有的本地能力。
能装下只是准入测试。常驻本地 Agent 还需要可接受的响应速度、边界明确的上下文内存、持久状态、可恢复工具调用、最小权限和可审计更新。因此，真正有用的评估单位是完整运行时合同，而不是单个模型文件。
Muse Glimmer 适合用来讨论这份合同。Meta 同时发布了开放权重、量化版本、模型卡、评测方法和具体设备数据。相同资料也清楚划出了厂商主张的边界，以及部署者仍需自行验收的部分。
Meta 发布了什么
Muse Glimmer 模型卡显示，这是一款约 296 亿参数的稠密因果 Transformer，其中包括约 18 亿参数的 ViT-G/14 感知编码器。模型接受文本和图片输入，输出文本，上下文长度为 131072 token 以上。它使用 32 个 query head 和 2 个 KV head 的 GQA，注意力层按三个局部层加一个全局层循环。
Meta 以 Apache 2.0 发布了四类工件：
- BF16 全精度权重。
- 两个约 4-bit 的量化版本。
- 用于推测解码的 DFlash drafter head。
- 感知编码器。
目标场景包括本地 Agent、编码、结构化工具调用、多模态推理、合成数据和 LLM-as-a-judge。Meta 还称模型针对多步推理、失败恢复、脚手架兼容和 100 多种语言训练。
这些属于模型能力，还不是一套完整 Agent 产品。发布页在 8 月 10 日称，针对 llama.cpp、MLX 和 ExecuTorch 的优化集成会在接下来几天陆续到位。因此，发布初期的运行时支持仍是持续变化的集成状态，不能统一理解为全部后端已经开箱即用。
逐项拆解 24 GB 包络
30B 模型使用 BF16 时，仅权重就需要 55 GB 以上。Meta 的量化方案改变了这份预算：
| 版本 | 厂商报告的质量变化 | 目标硬件 | 部署含义 |
|---|---|---|---|
| 全精度 | 基线 | 64 GB VRAM | 微调与最高保真参考 |
| K-Quant-Dynamic | 下降 0.2% | 32 GB VRAM | 用更大设备预算换取质量余量 |
| K-Quant-17GB | 下降 1.0% | 24 GB VRAM | 为 KV cache、视觉编码器和 drafter 留出空间 |
质量变化是 15 个 benchmark 准确率指标的平均值，属于厂商汇总口径。平均下降 1% 无法保证每种任务都只下降 1%。特定工具 schema、语言、图片类型、长上下文或工作流中可能出现更集中的退化。
17 GB 描述的是模型权重，也不等于进程峰值内存。实际峰值还取决于：
- 上下文长度与 KV cache 精度。
- 图片数量和分辨率。
- DFlash drafter 的占用。
- 运行时 buffer 与后端实现。
- Batch size、并发请求和 Agent 脚手架开销。
- Mac 上其他应用对统一内存的占用。
官方 GGUF 仓库可以把固定占用拆得更清楚：K-Quant-17GB 主模型文件约为 16.76 个十进制 GB，量化视觉 projector 约 1.40 GB，DFlash drafter 约 1.63 GB，合计约 19.79 GB。此时还没有计入 KV cache、运行时 buffer 和 Agent 宿主。Dynamic 版本的固定组合约为 22.69 GB。因此，24 GB 适合解释为经过验证的目标配置，不能理解为拥有 24 GB 空闲 context 容量。
正确验收方式是在目标上下文和真实工作负载下测量峰值常驻内存。模型能在 4K context 下成功加载，无法证明 100K token session、视觉输入和推测解码可以同时稳定运行。
延迟属于 Agent 合同
Agent 会在模型推理和工具之间反复切换。解码变慢后，每次规划、调用和恢复都会累积等待时间。Muse Glimmer 配套的 DFlash 是一个五层 block diffusion drafter，一次提出 16 个 token，再由主模型并行验证。
模型卡给出的 batch 1、greedy decoding 数据如下：
| 设备 | 基线 | 使用 DFlash | 报告加速 |
|---|---|---|---|
| Nvidia RTX 5090 | 74.9 tok/s | 233.4 tok/s | 3.1 倍 |
| Apple M4 Max | 23.7 tok/s | 37.8 tok/s | 1.5 倍 |
| Apple M5 Max | 26.6 tok/s | 50.2 tok/s | 1.8 倍 |
这些数据证明该架构在 Meta 测试配置中可以达到较好响应速度。它们没有覆盖 prompt 处理延迟、首 token 时间、长上下文减速、散热表现或全部运行时版本。发布后的早期社区实测显示，24 GB RTX 3090 级设备装下完整组合具有可行性；DFlash 加速幅度则会受到 llama.cpp 实现细节和近期变更影响。这些信息适合作为部署线索，证据身份仍是独立用户实测。
截至 8 月 11 日，软件路径仍在快速变化。Muse Glimmer 支持在 8 月 10 日合入 llama.cpp；一项 DFlash GPU 优化仍是 draft；工具调用解析修复仍处于 open 状态。可复现 benchmark 应记录精确 runtime commit 与 parser 配置。模型发布日期和集成达到生产可用的日期可能不同。
常驻 Agent 更适合使用端到端任务 P95 延迟作为指标。它应包含 prompt ingest、工具执行、模型重试和恢复。Tokens per second 只测量闭环中的一个阶段。
Benchmark 分数必须附带 harness 标签
Meta 报告 Muse Glimmer 在同尺寸模型中表现较强，例如 MCP Atlas 75.5、DeepSearch QA 74.6、SWE-Bench Pro 51.2、SWE-Bench Verified 76.0。它也没有赢下每一项。Meta 表格中的 Qwen3.6-27B 在 SkillsBench、OSWorld-Verified、SWE-Bench Verified 和 Terminal-Bench 2.1 上更高。
配套的评测方法报告给出了理解这些数字所需的上下文：
- 不同 benchmark 分别使用内部复现、自报分数或 Artificial Analysis 数据。
- Agent 评测依赖特定工具、prompt、容器、judge、turn budget 和 scaffold。
- 第三方模型配置可能没有针对其原生优势调优。
- 部分评测使用 LLM judge，另一部分使用确定性评分。
- 多数分数取多轮平均，但各 benchmark 的轮数并不完全一致。
离开 harness 的模型分数是不完整主张。本地部署又增加了一套 harness：量化版本、推理后端、上下文设置、工具定义和主机系统。生产判断应回答：这套完整本地栈能否在你的内存、延迟、安全和恢复预算内完成指定任务。
AI Agent 评测缺口框架进一步讨论了这个问题。评测需要冻结任务合同，并把结果归因到模型与 harness 的组合。
常驻需要上下文窗口之外的持久状态
131K context 是很大的工作集，但它不是持久记忆。
进程重启后，模型需要一份目标、审批、工具结果、文件版本和未完成副作用的事实源。Context compaction 可以保留摘要，也可能丢失审计或恢复所需细节。本地 Agent 至少需要四层状态：
- 临时上下文：当前 prompt、近期观测和活动计划。
- 持久 session 状态：事件、checkpoint、工具意图、结果和审批记录。
- 长期记忆：经过用户许可的事实与偏好，包含来源、保留和删除规则。
- 外部系统状态：文件、日历、消息、仓库和设备，它们可能独立变化。
这种分层直接影响运行安全。即使模型完整恢复了对话，重试工具仍可能制造重复日程或消息。恢复层需要幂等键、对账机制，或者把状态不明的动作暂停并交给人工处理。
AI Agent Sandbox 状态模型讨论了同一组生命周期边界。本地执行改变了状态存放位置，没有消除对持久性合同的需求。
本地推理改变了信任边界
本地运行可以减少发送给模型服务商的原始个人数据。与此同时，一个高能力进程被放到了用户文件、浏览器 session、消息、日历和凭据旁边。
隐私与权限需要分别验收：
- 数据本地性：哪些输入留在设备上，哪些工具仍会向外发送？
- 凭据可达性：Agent 能否读取 token、cookie、SSH key 或密码库？
- 动作权限：哪些操作只读、可撤销或不可逆？
- Prompt injection 暴露面：不可信文档或网页能否改变工具行为？
- 审计能力：用户能否看到读取了什么数据、发生了哪些外部副作用？
- 更新完整性：模型、量化、运行时和 skill 是否固定版本并校验哈希？
Meta 模型卡也建议使用系统级 guardrail，并要求不可逆操作经过人工确认。其安全表格还显示明显剩余风险：厂商报告 Muse Glimmer 在 Siren AgentDojo 上的攻击成功率为 28.4%，同表 Gemma4-31B 为 25.6%，Qwen3.6-27B 为 40.3%。无论 benchmark 向生产环境迁移的精确程度如何，方向很清楚：本地性无法单独承担安全控制。
脚手架兼容性也应作为接口合同。OpenClaw 中可用的工具 schema，换到另一套 harness 后，system prompt、错误表达、审批流程和 observation 格式都可能不同。Agent Skills 跨工具兼容将可移植指令与运行时适配器做了分层。
部署验收矩阵
在授予 Muse Glimmer 真实工具的持久访问权之前，应测试整套系统：
| 合同领域 | 最低证据 | 失败门槛示例 |
|---|---|---|
| 内存 | 目标 context、视觉输入、drafter 与并发应用下的峰值占用 | OOM、频繁 swap，或 context 被迫缩到任务要求以下 |
| 延迟 | 包含工具的端到端 P50 与 P95 | 尾延迟破坏交互体验或自动化截止时间 |
| 任务质量 | 在冻结真实任务上重复运行 | 成功率低于基线，或量化损失集中在关键任务 |
| 工具可靠性 | Schema 合规、超时恢复、幂等重试 | 外部副作用重复或丢失 |
| 权限 | 最小权限 scope，不可逆动作确认 | 能访问无关密钥或执行未批准写操作 |
| Prompt injection | 不可信网页、邮件和文档挑战集 | 内容可以覆盖策略或外传数据 |
| 状态恢复 | 在每个工具边界做重启与崩溃测试 | 恢复后缺失状态或重复动作 |
| 更新 | 固定哈希、回归集和回滚工件 | 模型或运行时升级静默改变行为 |
这张矩阵改变了购买问题。判断标准不再是 30B 模型能否装进 24 GB 显卡，而是完整本地 Agent 能否在你实际拥有的硬件上通过一份可验证的服务合同。
常见问题
Muse Glimmer 真的能跑进 24 GB 吗？
Meta 将 K-Quant-17GB 的目标标为 24 GB VRAM，并为 KV cache、感知编码器和 DFlash drafter 预留剩余空间。实际结果取决于 context、cache 精度、图片、运行时 buffer 和其他负载，因此仍需测量峰值内存。
24 GB 指系统内存还是显存？
模型卡写的是 24 GB VRAM。Apple 使用统一内存，容量由模型、操作系统和其他应用共同占用。LM Studio 的模型页另行标注最低 26 GB system memory，这属于另一种资源口径。比较配置时应分别核对 VRAM、RAM、统一内存和模型文件大小。
Muse Glimmer 可以完全离线吗？
模型本身可以不依赖云端推理和网络。只有工具、记忆、模型文件、遥测和更新链也全部留在本地时，完整 Agent 才能称为完全离线。
本地推理是否等于隐私和安全？
本地推理改善数据本地性。安全仍取决于工具权限、凭据隔离、prompt injection 防护、日志、确认门和网络工具行为。
应该用哪项 benchmark 决定是否部署？
公开 benchmark 适合筛选候选。最终决策应基于你的量化版本、后端、prompt、工具、硬件与安全策略，在冻结真实任务上重复评测。