MODEL-ZOO

Muse Glimmer：Meta开源VLM

一个压缩到12.5 GB的300亿参数视觉语言模型，完全在16 GB Mac mini的内存中运行。

admin

Aug 14, 2026 • 16 min read

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

Meta以59.6 GB的下载包发布Muse Glimmer，其官方量化权重面向24和32 GB的机器。压缩到12.5 GB——包括视觉塔——它完全运行在Apple销售的最便宜Mac的内存之内。以下是命令、来自真实Mac mini的测量结果，以及它不再舒适的那个临界点。

1、一个能看的300亿模型带来的问题

Meta在2026年8月10日发布了Muse Glimmer。它是一个dense（稠密）模型——它的296亿参数每一个都在每个token上做功，这与混合专家（MoE）设计不同——后者由一个路由器唤醒一小部分参数。稠密模型恰好因此更难压缩：没有多余容量可以丢弃。

它还携带一个ViT-G/14视觉编码器——约18亿参数、自带50层——把图像转换成语言模型能读取的东西。

Meta自己的文档把这些量化权重描述为面向24 GB和32 GB消费级硬件优化，其公开发布的最小的量化系列以尺寸命名：K-Quant-17GB。17 GB比基础版Mac mini的整个内存还大。因此运行这个模型的最小官方方式，比我想要运行它的整台机器还大。

这个差距就是本文存在的原因。

2、Muse Glimmer到底是什么

架构讲到这里就够了——足够让后面的数字讲得通，不再多讲。

有两个细节稍后很关键。202,048个token的词汇表让输出投影变得巨大——202,048 × 6,656 是单个矩阵中的13.5亿参数，比模型中任何其他矩阵大十倍。而3:1滑动窗口模式让注意力缓存保持很小，这就是长提示词在这里消耗的是速度而非内存的原因。

3、压缩阶梯

下面所有内容都在我自己的硬件上测量：一段固定的800 token段落上的困惑度（perplexity），贪心解码，每个构建用同一段落。

把中间两行一起读，因为那个对比是我最想捍卫的：在同样的每个权重4比特下，这个构建既更小又略微更准——磁盘空间省25%，困惑度低1.1%。困惑度越低越好，差距很小，但它带着一个不利条件还朝着正确的方向走。社区构建把token嵌入和整个视觉塔都留在全精度。这个构建两者都压缩了，仍然胜出。

3比特那行是能装进16 GB机器的那个，它的困惑度明显更差——那是丢掉第三个比特的代价，而不是方法本身的缺陷。4比特对照组则证明了这个差异来自位宽而不是技术。

只有3比特构建能跨过那条线。Meta最小的官方量化系列高于整台机器的内存。

3、你需要什么

这些是你需要的：

一台Apple Silicon Mac。对3比特构建：16 GB可用，但有下面提到的注意事项。我在一台运行macOS 26.5.2的基础款**M4 Mac mini (16 GB)**上测量，另外在一台64 GB的M4 Max上单独测量。
约13 GB的空闲磁盘空间。
Python 3.10或更新版本。
一条sudo命令。这在16 GB上运行很重要：macOS限制了GPU可以固定的统一内存上限，默认上限低于这个模型所需。你必须调高它。

三条命令

打开终端（⌘-空格，输入"Terminal"）然后粘贴：

python3 -m pip install "turboquant-mlx-full[vlm]>=0.21.1"

这就是开源引擎 TurboQuant-MLX ，用于Apple Silicon上LLM的极限权重+KV缓存压缩（Google TurboQuant的MLX实现）。

它构建在Apple的MLX之上——你的Mac的GPU，无需CUDA、无需Docker、无需云端，什么都不离开机器。

然后调高GPU内存上限：

sudo sysctl -w iogpu.wired_limit_mb=14336

这要求macOS允许GPU固定mini的16 GB中多达14 GiB。重启后会重置，这其实是我更喜欢的——不留任何永久改动。然后：

TURBOQUANT_QMM_MAX_TOKENS=1000000 python3 -m turboquant_mlx.generate_vlm \
    --model manjunathshiva/Muse-Glimmer-30B-tq3-g64 \
    --prompt "Explain what a Mixture-of-Experts model is, in two paragraphs." \
    --reasoning low --max-tokens 512

第一次运行会下载一次12.5 GB。之后完全离线。

注意是generate_vlm，不是generate。纯文本入口只认识纯文本架构，会以Model type muse_glimmer not supported停下。即使你的提示词没有图片也要用多模态版本——— image标志是可选的。

要描述一张图片，加一个标志：

TURBOQUANT_QMM_MAX_TOKENS=1000000 python3 -m turboquant_mlx.generate_vlm \
    --model manjunathshiva/Muse-Glimmer-30B-tq3-g64 \
    --image ~/Desktop/photo.jpg \
    --prompt "What is in this picture?" \
    --reasoning low --max-tokens 220

有一件事第一次看起来会很奇怪。这个模型在作答前会在一个独立通道里思考，而命令行会打印原始流——所以你会看到它在真正的答案之前自言自语（"Ok. Possibly use simple language. Let's output."）。那是模型在工作，不是故障。 — reasoning low 让它简短。如果你想把这个思考过程干净地分离出来，就改跑OpenAI兼容服务器（turboquant-serve-vlm），它会把它拆到自己单独的字段里。

那个环境变量不是装饰。它强制每个提示词长度都走融合计算路径；没有它，较长的提示词会回退到一条短暂需要数GB临时空间的路径。我在一个图像问题上测量了差异——同样的模型、同样的提示词、同样的答案：

在64 GB机器上，这个差距不可见。在16 GB机器上，它是有用和没用的区别。

4、它在16 GB mini上实际表现如何

这里的每一行都是在Mac mini上的真实运行，不是估算。

那张表里有三件事值得读出来。

生成速度几乎不动。无论提示词多长，它都维持在每秒3.4到3.7个token。那大致是阅读速度——文字就像有人在快速打字一样到来。它不是聊天体验；它是"问个问题，去冲杯咖啡"的体验，而对这台尺寸的机器上一个带视觉的300亿模型，我愿意接受。

提示词处理在约2,000个token之后断崖式下跌。到2,068是每秒20个token，到5,068就只剩6个。最后一行就是墙钟时间跳到接近十五分钟的原因。这个崩塌是提示词处理期间的内存压力，不是模型变慢——是机器没有工作空间了。把约2,000个token当作16 GB上实用的交互上限。

最上面一行的余量是0.20 GB。在5,068个token时，运行峰值达到可用的15.46 GB中的15.26 GB。这不是舒适的余量；这是一个四舍五入误差。先关掉你的浏览器——我是认真的。

绿线是答案正在被写出，它几乎不在乎你的提示词有多长。蓝线是机器在读取你的提示词，而那里正是16 GB Mac耗尽空间的地方。

5、视觉那一半是好的

压缩覆盖了视觉编码器，而这恰恰是它可能悄悄坏掉的地方——一个自信且错误地描述图像的模型，比一个响亮失败的更糟。

所以我用一个对照组测试它：同样的四张图走mlx-community的4比特构建，后者把视觉塔留在全精度。如果两者都漏了某个案例，那是模型的问题。如果只有我的漏了，那是我的压缩的问题。

四个全中，三个构建都是。在这里压缩视觉塔没有任何可测量的代价。

6、而且在mini上也能用

那张表是在64 GB机器上测的，所以我在Mac mini上跑了完全相同的测试。四个全中，在16 GB上：

⁽¹⁾ 冷模型加载，不是推理——后面三个约60秒才是真实数字。

每张图约一分钟，而64 GB机器上是11–13秒。慢五倍，但仍然是Apple销售的最便宜Mac上描述图片的300亿模型。

有一个结果让我意外：mini的峰值比大机器更低——同一组四张图，13.79 GiB对14.03 GiB。峰值内存不是模型的固定属性。MLX的分配器在有富余空间时会抓住更多临时空间，没有时就释放。这很好地说明要在你实际打算使用的机器上测量，而不是把大机器的数字按比例缩小。

这样图像方面还剩约0.66 GB的余量——大约是长文本情形下余量的三倍。

**有一个注意事项站得住。**四中四对四中四意味着没有检测到回退，而不是视觉质量完全相同。这些是干净的合成图像，答案明确无歧义，选择它们是为了让真实答案无可争辩。更难的测试组——杂乱的实拍照片、小文字、细粒度计数——仍然可能把它们分开。这是一次健全性检查，不是视觉基准。

(.venv) yashas@ManjunathsMini2 gemma % TURBOQUANT_QMM_MAX_TOKENS=1000000 python3 -m turboquant_mlx.generate_vlm \
    --model manjunathshiva/Muse-Glimmer-30B-tq3-g64 \
    --image ~/Desktop/maths.png \
    --prompt "What is in this picture?" \
    --reasoning high --max-tokens 512 --temp 0
[transformers] PyTorch was not found. Models won't be available and only tokenizers, configuration and file/data utilities can be used.
Fetching 10 files: 100%|████████████████████| 10/10 [00:00<00:00, 14968.97it/s]
Download complete: : 0.00B [00:00, ?B/s]                | 0/10 [00:00<?, ?it/s]
[INFO] Replaced 419 layers with PolarQuantized versions
[INFO] Loaded in 9.2s
[INFO] chat template: {'reasoning_strength': 'high'}
[transformers] Kwargs passed to `processor.__call__` have to be in `processor_kwargs` dict, not in `**kwargs`
==========
Files: ['/Users/yashas/Desktop/maths.png']

Prompt: <|begin_of_text|><|start|>system<|message|>You are a helpful AI assistant.
Knowledge cutoff: 2026-01-04.
Current date: 2026-08-11.

Reasoning strength: high.

# Valid recipients: "self", "user".<|eot|><|start|>user<|message|><|patch|>What is in this picture?<|eot|><|start|>assistant
 to=self<|message|>What is in this picture?

The user asks: What is in this picture? Probably describe. The picture shows a worksheet titled FRACTIONS. Name: Date: Fractions Select the correct fraction for the shaded part. There is a table with shaded parts and options. Then Write the fraction for the shaded part with three shapes.

Probably describe content. Might be a question about fractions. Could be they want the answers? "What is in this picture?" Might just describe.

Maybe they want the fractions for the shaded parts? Could be they want to know what is in the picture. So describe: It's a worksheet about fractions with shaded parts.

Might be a request to identify fractions. Could list each row.

First row: pink squares 5 out of 10? Let's see: first row: pink squares 5 out of 10? The first row has 5 pink squares out of 10? Actually 5 pink out of 10? The options are 5/5, 5/10, 2/10, 3/5. The first row has 5 pink out of 10? Let's count: first row: 5 pink squares? The image shows 5 pink out of 10? Actually 5 pink out of 10? The first row has 5 pink squares out of 10? Wait the row shows 5 pink squares? Let's count: first row: 5 pink squares? The image shows 5 pink out of 10? The first row has 5 pink squares out of 10? Actually there are 10 squares, 5 pink. So 5/10 = 1/2. Options include 5/5, 5/10, 2/10, 3/5. So 5/10.

Second row: yellow 2 out of 6? Options 2/6, 6/6, 2/7, 6/7. So 2/6? Actually yellow squares 3? Wait row 2: yellow 3? Let's count: 6 squares, 3 yellow? Actually 3 yellow? The image shows 3 yellow out of 6? Wait 6 squares total, 3 yellow. So 3/6? But options are 2/6, 6/6, 2/7, 6/7. Hmm maybe 3/6? Not listed? Wait maybe 2/6? Let's assume 3 yellow out of 6
==========
Prompt: 632 tokens, 13.257 tokens-per-sec
Generation: 512 tokens, 3.399 tokens-per-sec
Peak memory: 15.126 GB
peak memory: 14.09 GB
(.venv) yashas@ManjunathsMini2 gemma %

在低质量下，它起初返回2个黄色，但接着它假定为3（图像中的第二行）。由于token上限设为512，它被截断了。它对高质量和中复杂度图像表现良好。

7、为什么3比特是下限，以及它之下发生了什么

显而易见的问题：如果3比特能装下还富余1.5 GB，为什么不用2比特然后舒舒服服的？

我试了。一个3比特注意力加2比特前馈层的混合版本达到9.63 GiB——在16 GB机器上很宽敞。但也没法用：

那是50%的更差，而且很明显。让它重复一个词，模型把*"reverses"返回成"reverss"*——这是那种模型不再可靠拼写的损坏。不是那种只有基准测试才能抓到的细微退化。

原因是结构性的。2比特权重在混合专家（MoE）模型中能存活，那里上百个冗余的专家网络能吸收损伤。这是一个稠密模型。每个参数都承重，而在2比特下没有足够的分辨率来承载它们。我以前在一个32专家的MoE上见过这种失败；这次在稠密模型上得到了确认。

所以12.5 GB是这个模型今天的下限，mini装上它还剩约1.2 GB富余——不是我喜欢的那种舒适余量，但真实存在。

8、真正解锁mini的东西

这部分能推广到这一个模型之外。

压缩权重在相乘之前必须先变回数字。朴素的做法是把整个矩阵展开成全精度、相乘、然后扔掉。这需要大约每参数14字节的开销——对这个模型来说，当你一次处理超过一个token时，就是固定的**+3.85 GB**。它不随提示词长度增长；你一开始它就出现。

加总一下：12.53 GB权重加3.85 GB临时空间是16.4 GB——**超过mini的整个内存。**模型装下了。运行它却不行。

解决方案是一个Metal内核，在相乘时在GPU寄存器内部解包权重，这样展开的副本从未存在过。在同一个提示词上测量：

内存少六倍、速度快三倍，输出到小数点后四位都未变。如果你从这篇文章带走一个想法：在内存受限的硬件上，峰值比磁盘上的大小更重要，而峰值通常取决于格式是如何被使用的，而不是它有多小。

9、注意事项

3.5 tokens/秒是阅读速度，不是聊天速度。这个格式每个token大约比Apple原生4比特量化慢2.4–2.8倍。代价是算术——每次通过都要做一次旋转加一次码本查找——而不是内存带宽。在mini上这无所谓，因为4比特构建根本装不下。
约2,000个token是16 GB上实用的提示词上限。超过它，提示词处理崩塌，单个答案可能要花十五分钟。在64 GB机器上这个上限不适用。
你每次开机需要一次sudo。没有办法绕过——默认的Metal工作集上限低于这个模型所需。
代理（agentic）相关的结果不是来自mini。我把这个模型当作编码代理运行——它在一份真实仓库中找出并修复了一个植入的bug，八次运行八次成功——但那是在64 GB M4 Max上。在3.5 tok/s、7,000 token代理提示词下，mini是另一个实验，而我还没跑过。那是另一篇文章。
视觉是在合成图像上测试的，不是基准测试。见表格上方的注意事项。它是在mini上测量的，但只用了四张简单图像。
5,000 token时0.20 GB的余量很薄。先退出其他一切程序。

Meta自己对这款模型的指引指向24和32 GB的机器。基础款Mac mini两者都不是，而它是Apple销售的最便宜的带字母M的电脑。

在12.5 GB下，一个能读图的300亿参数模型运行在那台机器上，离线、免费——慢一些，需要一条sudo命令和一个我尽量精确说明的提示词长度上限。两年前这需要一个机架。这周它是显示器下面那个小小的银色盒子。

压缩模型在Hugging Face上以Meta的Apache-2.0许可证发布；引擎在GitHub和PyPI上。

原文链接: Muse Glimmer on a 16 GB Mac mini: Meta's 30B vision model, fully in memory

汇智网翻译整理，转载请标明出处