跳到主要内容Skip to main content

MetaMeta · 发布于released 2026-08-09

Muse GlimmerMuse Glimmer

Meta 的开放权重系列,apache-2.0,量化覆盖横跨多家主力量化者。Meta's open-weight series, apache-2.0, with quantisation coverage across several major quantisers.

  • 通用对话General chat
  • apache-2.0Apache-2.0

先说清楚:这个站的数据怎么来的First, where this site's data comes from

✅ 实测字段Measured fields

直接从 Hugging Face 公开 API 读取的客观数据:文件体积(字节)、上下文长度、架构、许可、下载量、更新时间。Objective data read straight from the Hugging Face public API: file sizes in bytes, context length, architecture, licence, downloads, last updated.

✅ 推导Derived

由实测字段按公开规则算出:每权重比特数(依 llama.cpp 命名标准)、档位归属、显存需求区间。推导规则在Computed from the measured fields by published rules: bits per weight (per the llama.cpp naming convention), tier assignment, VRAM requirement range. The rules are fully published in METHODOLOGY.md 完整公开,任何人可复算。 — anyone can recompute them.

❌ 我们不说的What we do not claim

哪个量化质量更高、哪个更快、哪个模型更强——这些需要实测,本站不跑 benchmark,所以不装作知道。凡我们给出的主观判断,一律显式标注「我们的口径」。Which quantisation is higher quality, which is faster, which model is stronger — these need measurement. This site does not run benchmarks, so it does not pretend to know. Every subjective judgement we do offer is explicitly marked as our own reading.

本站This site does 不下载、不托管任何模型权重文件not download or host any model weight files。所有数字都来自公开元数据,点击即可回到发布页核对。. Every figure comes from public metadata, and clicking it takes you back to the release page to verify. 采集时间Collected: 2026-10-30(数据快照,非实时) (a snapshot, not live)

中文生态China availability 国产 / 国内可直接用 / 备案状态 · 快照domestic / direct access / CAC filing · snapshot 2026-10-20

  • 出品属地Origin 国外出品foreign-made 出品方为 Meta。Made by Meta.
  • 国内下载Direct access 国内可直连direct OK ModelScope 有 meta-models 官方组织镜像(2026-10-20 实测 200);Hugging Face 直连不可达。ModelScope carries the official meta-models org mirror (measured 200); Hugging Face direct unreachable. · 国内镜像入口domestic mirror
  • 备案状态CAC filing 未见于备案名单not in filing list:公示名单未检索到 Meta / Muse 相关条目(2026-10-20;同名命中均为无关国内主体)。No Meta / Muse entry found in the public registry (searched 2026-10-20; same-name hits are all unrelated domestic entities).

备案信息以网信办《生成式人工智能服务已备案信息》公示名单为准(按批次滚动更新,本站只抄编号不解读);「国内可直连」是本站从大陆网络直连实测的结果,不是厂商承诺。Filing status is quoted from the CAC public registry (updated batch by batch; this site copies the number and does not interpret it). "Direct access" is this site's own reachability measurement from a mainland network, not a vendor promise.

成员Member 1Muse Glimmer 30BMuse Glimmer 30B

29.78B 总参29.78B total params · 通用主力General · 10 个量化来源10 quant sources

A基础模型卡Base model card 规格 · 许可 · 访问门槛 · 参数量三来源交叉核对specs · licence · access · parameter count cross-checked across three sources

官方发布页Official release pagemeta-models/Muse-Glimmer-30B ↗
许可Licenceapache-2.0
访问门槛Access✅ 公开下载 无需申请✅ Public download no application needed
规模Scale
官网标注Vendor states29.78B 总参29.78B total params
官方 API 申报Official API—
本站实测反推This site, measured—
权重精度构成Precision breakdown—
架构Architecturemuse-glimmer
上下文长度Context length131,072 tokens
基座Base model本仓即基座(不是微调版)this repo is the base model, not a fine-tune
任务类型Task type—
输入模态Input modality✓ 支持✓ Supported 出处 ↗source ↗ 模型卡model card · 2026-10-28
模型卡「Supported modalities」:输入文本+图像、输出文本;带 ViT-G/14 感知编码器;音频不支持;视频按帧处理(未针对视频优化)。经 hf-mirror 镜像核实(原站在当前区域被屏蔽)。Card "Supported modalities": input text + image, output text; ViT-G/14 perception encoder; audio not supported; video processed frame-by-frame (not optimized for video). Verified via the hf-mirror.com mirror (the origin page is region-blocked).
工具调用Tool calling✓ 支持✓ Supported 出处 ↗source ↗ 模型卡model card · 2026-10-28
模型卡:Reliable Tool Use——跨多轮长流程按 schema 可靠调用函数;工具失败会诊断并重试。经 hf-mirror 镜像核实。Card: "Reliable Tool Use" — schema-based function calls across extended multi-turn workflows; failed tool calls are diagnosed and retried. Verified via the hf-mirror.com mirror.
定位Role通用主力General
标签Tags—
官方下载量Downloads202k 点赞likes 2k
发布日Released—
最近更新Last updated2026-10-22
发布页体积Release-page size—

apache-2.0,61 个 GGUF 仓(第三方 60),unsloth / LM Studio / bartowski 三家主力量化者都覆盖。apache-2.0, 61 GGUF repos (60 third-party), covered by all three of unsloth, LM Studio and bartowski.

B该选哪个Which one to pick 按你的显存倒推work backwards from your VRAM

按「你实际能腾出多少显存或内存」选档位,而不是按参数猜。下面每档的体积都是实测值(来自发布页文件列表),加权 15% 余量给运行时与 KV cache。Pick a tier by how much VRAM or memory you can actually free up, not by guessing from spec sheets. Every size below is measured (from the release page file listing) with 15% headroom added for runtime and the KV cache.

单卡全量装得下Fits entirely on one card

显存 → 档位速查(权重全部放显存,不卸载到系统内存)VRAM → tier cheat sheet (all weights on the GPU, no offload to system memory)
8 GB 显存8 GB VRAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
共享显卡 / 老卡,够跑小MoE 与 2B 级shared or older cards; enough for small MoE and 2B-class models
12 GB 显存12 GB VRAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
RTX 3060 12G / 4050 12GRTX 3060 12G / 4050 12G
16 GB 显存16 GB VRAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
RTX 4060 Ti 16G / 5060 Ti 16GRTX 4060 Ti 16G / 5060 Ti 16G
24 GB 显存24 GB VRAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
RTX 3090 / 4090 / 5090RTX 3090 / 4090 / 5090
48 GB 显存48 GB VRAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
RTX A6000 / L40S / A100 40G×2RTX A6000 / L40S / A100 40G×2
80 GB 显存80 GB VRAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
A100 80G / H100 80G / Mac Studio 大统一内存A100 80G / H100 80G / Mac Studio large unified memory

显存不够时的替代路径When VRAM is not enough

llama.cpp 的llama.cpp’s -ngl 可以只把部分层放显存、其余落系统内存;多卡则自动切分。can keep only some layers on the GPU and spill the rest to system memory; with multiple cards it splits automatically. 代价是速度:纯 CPU 推理通常比同规模 GPU 慢数倍,但同样能出结果。The trade-off is speed: CPU-only inference is usually several times slower than a comparable GPU, but still produces results.

系统内存 / 多卡 → 档位速查System memory / multi-GPU → tier cheat sheet
64 GB 系统内存64 GB system RAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
纯 CPU 推理,速度慢但可跑;建议开swap 兜底CPU-only inference — slow but it runs; enable swap as a safety net
纯 CPU 会明显慢于 GPU;若显存够,优先用上面的单卡档

CPU-only is markedly slower than GPU — if you have the VRAM, prefer the single-card tiers above
128 GB 系统内存128 GB system RAM Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
工作站标准配置,纯 CPU 可跑中等规模 MoEthe standard workstation config; CPU-only handles mid-size MoE
纯 CPU 会明显慢于 GPU;若显存够,优先用上面的单卡档

CPU-only is markedly slower than GPU — if you have the VRAM, prefer the single-card tiers above
256 GB 统一内存 / 多卡256 GB unified memory / multi-GPU Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
Mac Studio / 服务器内存,或 2~4 张 80G 卡张量并行Mac Studio / server memory, or 2–4 × 80G cards under tensor parallel
纯 CPU 会明显慢于 GPU;若显存够,优先用上面的单卡档

CPU-only is markedly slower than GPU — if you have the VRAM, prefer the single-card tiers above
640 GB+ 内存 / 8×80G640 GB+ memory / 8×80G Q8_0Q8_0(2.7 GB · 近似无损Near lossless)
更省:Smaller: 作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB / 作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB
超大 MoE 的门槛,需要多卡切分或大内存服务器the threshold for very large MoE — needs multi-GPU splitting or a big-memory server
纯 CPU 会明显慢于 GPU;若显存够,优先用上面的单卡档

CPU-only is markedly slower than GPU — if you have the VRAM, prefer the single-card tiers above

本系列档位体积跨度 6.5 GB → 5.1 GB。

Tier sizes in this series span 6.5 GB → 5.1 GB. 跨度过大说明同一系列的量化选择空间很宽,这正是量化选型的主要收益所在。

展开:本系列所有档位的实测体积Expand: measured sizes for every tier(52 档tiers)
量化档Quant最小体积Min size每权重比特bpw档位Tier这档意味着什么What this tier means该档文件数 / 体积跨度Files in tier / size range最小体积来源
IQ1_SIQ1_S 6.5 GB 1.62 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 NANI-Nithin
Q1_0Q1_0 4.8 GB 1.65 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 NANI-Nithin
IQ1_MIQ1_M 7.1 GB 1.90 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 NANI-Nithin
UD-IQ2_XXSUD-IQ2_XXS 11 GB 2.13 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 unsloth
IQ2_XXSIQ2_XXS 8.0 GB 2.13 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 3 个 · 8.0 GB~9.3 GB NANI-Nithin
UD-IQ2_XSUD-IQ2_XS 12 GB 2.31 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 unsloth
IQ2_XSIQ2_XS 8.7 GB 2.31 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 2 个 · 8.7 GB~9.6 GB NANI-Nithin
UD-IQ2_MUD-IQ2_M 12 GB 2.39 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 unsloth
IQ2_MIQ2_M 9.8 GB 2.39 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 4 个 · 9.8 GB~11 GB AtomicChat
IQ2_SIQ2_S 9.1 GB 2.46 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 2 个 · 9.1 GB~10 GB NANI-Nithin
Q2_0Q2_0 9.0 GB 2.62 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 NANI-Nithin
Q2_K_SQ2_K_S 10 GB 2.71 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 NANI-Nithin
Q2_KQ2_K 11 GB 2.80 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 3 个 NANI-Nithin
Q2_K_LQ2_K_L 12 GB 2.89 bpw 极限压缩Extreme compression 能装下就装,质量明显下降Fit it in at the cost of visibly lower quality 1 个 bartowski
UD-IQ3_XXSUD-IQ3_XXS 13 GB 3.06 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 1 个 unsloth
IQ3_XXSIQ3_XXS 11 GB 3.06 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 5 个 · 11 GB~12 GB AtomicChat
UD-Q2_K_XLUD-Q2_K_XL 12 GB 3.35 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 1 个 unsloth
IQ3_SIQ3_S 13 GB 3.35 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 1 个 NANI-Nithin
IQ3_XSIQ3_XS 12 GB 3.36 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 3 个 NANI-Nithin
Q3_K_SQ3_K_S 13 GB 3.50 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 3 个 NANI-Nithin
Q3_K_MQ3_K_M 14 GB 3.55 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 4 个 NANI-Nithin
Q3_K_LQ3_K_L 15 GB 3.60 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 3 个 NANI-Nithin
UD-IQ3_MUD-IQ3_M 14 GB 3.66 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 1 个 unsloth
IQ3_MIQ3_M 13 GB 3.66 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 4 个 · 13 GB~15 GB NANI-Nithin
Q3_K_XLQ3_K_XL 16 GB 3.66 bpw 长上下文优先Long context first KV 缓存也吃紧时的选择The pick when the KV cache is also tight 1 个 bartowski
IQ4_NLIQ4_NL 16 GB 4.05 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 3 个 NANI-Nithin
IQ4_XSIQ4_XS 15 GB 4.25 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 7 个 · 15 GB~16 GB AtomicChat
作者标注 4.30bpwauthor-stated 4.30bpw 1.4 GB 4.30 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 1 个 ddh0
UD-Q3_K_XLUD-Q3_K_XL 13 GB 4.42 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 1 个 unsloth
Q4_0Q4_0 16 GB 4.55 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 2 个 NANI-Nithin
作者标注 4.66bpwauthor-stated 4.66bpw 16 GB 4.66 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 1 个 ddh0
Q4_K_SQ4_K_S 16 GB 4.75 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 3 个 NANI-Nithin
Q4_1Q4_1 18 GB 4.83 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 2 个 NANI-Nithin
Q4_K_MQ4_K_M 17 GB 4.85 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 9 个 · 17 GB~19 GB meta-models
Q4_KQ4_K 20 GB 4.85 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 1 个 meta-models
作者标注 4.85bpwauthor-stated 4.85bpw 1.6 GB 4.85 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 1 个 ddh0
Q4_K_LQ4_K_L 18 GB 4.95 bpw 平衡档Balanced 默认推荐,质量和体积的折中点The default recommendation — the compromise between quality and size 1 个 bartowski
作者标注 5.03bpwauthor-stated 5.03bpw 18 GB 5.03 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 ddh0
作者标注 5.51bpwauthor-stated 5.51bpw 1.8 GB 5.51 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 ddh0
Q5_K_SQ5_K_S 19 GB 5.54 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 3 个 NANI-Nithin
Q5_0Q5_0 19 GB 5.54 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 NANI-Nithin
UD-Q4_K_XLUD-Q4_K_XL 16 GB 5.62 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 unsloth
Q5_K_MQ5_K_M 19 GB 5.69 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 6 个 · 19 GB~23 GB unsloth
Q5_1Q5_1 21 GB 5.69 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 NANI-Nithin
Q5_K_LQ5_K_L 20 GB 5.84 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 2 个 · 20 GB~21 GB unsloth
UD-Q5_K_XLUD-Q5_K_XL 22 GB 5.84 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 unsloth
UD-Q6_KUD-Q6_K 26 GB 6.54 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 unsloth
Q6_KQ6_K 23 GB 6.59 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 6 个 · 23 GB~28 GB NANI-Nithin
作者标注 6.68bpwauthor-stated 6.68bpw 23 GB 6.68 bpw 保守档Conservative 几乎无质量损失Almost no quality loss 1 个 ddh0
Q8_0Q8_0 2.7 GB 8.50 bpw 近似无损Near lossless 体积接近原始精度Size close to the original precision 12 个 · 2.7 GB~32 GB ddh0
UD-Q8_K_XLUD-Q8_K_XL 32 GB 8.72 bpw 近似无损Near lossless 体积接近原始精度Size close to the original precision 1 个 unsloth
BF16BF16 5.1 GB 16.00 bpw 近似无损Near lossless 体积接近原始精度Size close to the original precision 8 个 · 5.1 GB~56 GB ddh0

「每权重比特」是按 llama.cpp 公开命名标准从文件名推导的,同一档位在不同模型上的真实值会略有差异。这是Bits per weight is derived from the filename by llama.cpp’s published naming convention; the real value varies slightly between models at the same tier. This is B 级推导grade-B derived,不是实测值。 — not a measured value.

关于「最小体积」与「变体」:On "smallest size" and "variants":同名档位下可能有多个不同文件 (不同量化者的实现差异,或带 -AD- 混合精度、-PLEQ4_0 上下文扩展、 -DENSE 等后缀的特殊变体)。上表取的是该档最省的可行体积, 「体积跨度」列给出该档实际的体积范围——跨度大说明该档内部差异明显, 选具体文件时请以跨度上界为准。

C量化版本总表Quantisation versions 横向对比side by side

量化者Quantiser许可Licence档数Tiers总体积Total size 上下文Context建议档Recommended下载量Downloads更新Updated
官方 official meta-models
muse-glimmer
apache-2.0 2 36 GB 131,072 Q4_KQ4_K
20 GB
210k 2026-10-20
unsloth
muse-glimmer
apache-2.0 15 308 GB 131,072 UD-Q3_K_XLUD-Q3_K_XL
13 GB
789k 2026-08-10
lmstudio-community
muse-glimmer
apache-2.0
继承自基座Inherited from base meta-models/Muse-Glimmer-30B · 量化仓未单独声明许可 · the quant repo declares no licence of its own
1 16 GB 131,072 Q4_K_MQ4_K_M
17 GB
113k 2026-08-12
bartowski imatriximatrix
muse-glimmer
apache-2.0 26 468 GB 131,072 Q4_K_LQ4_K_L
18 GB
26k 2026-08-13
AtomicChat imatriximatrix
muse-glimmer
apache-2.0 10 382 GB 131,072 Q4_K_MQ4_K_M
19 GB
15k 2026-10-28
NANI-Nithin
muse-glimmer
apache-2.0 30 479 GB 131,072 Q4_1Q4_1
18 GB
11k 2026-09-07
ggml-org
muse-glimmer
apache-2.0 3 105 GB 131,072 Q4_K_MQ4_K_M
19 GB
6k 2026-10-25
Abiray imatriximatrix
muse-glimmer
apache-2.0 10 160 GB 131,072 Q4_K_MQ4_K_M
17 GB
716 2026-08-10
mradermacher
muse-glimmer
apache-2.0 11 179 GB 131,072 Q4_K_MQ4_K_M
17 GB
655 2026-08-12
ddh0 imatriximatrix
muse-glimmer
apache-2.0
继承自基座Inherited from base meta-models/Muse-Glimmer-30B · 量化仓未单独声明许可 · the quant repo declares no licence of its own
8 144 GB 131,072 作者标注 4.66bpwauthor-stated 4.66bpw
16 GB
349 2026-08-10

卡片左侧色条 = 推荐档位Colour bar on the left = recommended tier 近似无损Near lossless 保守Conservative 平衡Balanced 长上下文Long context 极限压缩Extreme compression

「建议档」是本站按体积最小且落在平衡档的规则自动选出的,不是质量排名。官方量化排在最前;带 imatrix 标记的仓库带重要性矩阵数据。The recommended tier is picked by rule — smallest size that still lands in the balanced tier — not by a quality ranking. Official quantisations are listed first; repos marked imatrix ship an importance matrix.

D每个变体详解Every variant in detail 七字段seven fields

每个变体按七个字段展开:它是什么 → 量化者做了什么 → 与同系列其他变体的区别 → 存在的意义 → 优势 → 为什么选它 → 已知取舍。最后一项是本站唯一会写主观判断的地方,且都标注了「我们的口径」。Each variant expands along seven fields: what it is → what the quantiser did → how it differs from other variants in this series → why it exists → strengths → why you would pick it → known trade-offs.The last field is the only place this site offers a subjective judgement, and every item is marked as our own reading.

官方 official meta-models

apache-2.0 2 档2 tiers · 36 GB · 210k 下载210k downloads
它是什么What it ismeta-models/Muse-Glimmer-30B-GGUF ↗,提供 2 个 GGUF 量化档,合计 36 GB。这是模型方自己发布的,不是第三方。meta-models/Muse-Glimmer-30B-GGUF ↗, providing 2 GGUF tiers totalling 36 GB. Published by the model authors themselves, not a third party.
量化者做了什么What the quantiser did模型作者自行量化,只有覆盖不到的档位才需要考虑第三方Quantised by the model author; third parties are only worth considering for tiers this does not cover;未提供重要性矩阵(imatrix),走的是纯权重量化路线No importance matrix (imatrix); this is pure weight quantisation;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 36.4 GB(发布页 gguf.total 字段)Total weight bytes 36.4 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers、AtomicChat 10 档tiers 等)。The series has 9 other quantisation sources (unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, AtomicChat 10 tiers, among others). 本仓 2 档,覆盖中等。 This repo has 2 tiers — middling coverage in this series.
存在的意义Why it exists模型作者最清楚哪几层权重对质量敏感,官方量化通常是最保守、最不会出错的选择——官方出了就优先用它。The model author knows best which layers are quality-sensitive, and official quantisation is usually the most conservative, least likely to break — reach for the official build first.
优势Strengths· 官方出品,出错时责任明确Made by the model author, so there is someone accountable when it goes wrong
· 平衡档落在 Q4_K(20 GB),是大多数人的起点The balanced tier lands on Q4_K (20 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K(20 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K directly (20 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 档位极少,没有升降空间,被显存卡住时无路可退Very few tiers, so there is no room to move up or down when VRAM runs out

unsloth

apache-2.0 15 档15 tiers · 308 GB · 789k 下载789k downloads
它是什么What it isunsloth/Muse-Glimmer-30B-GGUF ↗,提供 15 个 GGUF 量化档,合计 308 GB。由 unsloth 发布。unsloth/Muse-Glimmer-30B-GGUF ↗, providing 15 GGUF tiers totalling 308 GB. Published by unsloth.
量化者做了什么What the quantiser did未提供重要性矩阵(imatrix),走的是纯权重量化路线No importance matrix (imatrix); this is pure weight quantisation;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 308.1 GB(发布页 gguf.total 字段)Total weight bytes 308.1 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers、AtomicChat 10 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, AtomicChat 10 tiers, among others). 本仓 15 档,覆盖中等。 This repo has 15 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(UD-Q3_K_XL 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as UD-Q3_K_XL), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 平衡档落在 UD-Q3_K_XL(13 GB),是大多数人的起点The balanced tier lands on UD-Q3_K_XL (13 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 UD-Q3_K_XL(13 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take UD-Q3_K_XL directly (13 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)No imatrix, so quality loss at the same tier may be more visible than in an imatrix build (our reading, to be verified by measurement)
· 全仓 308 GB,硬盘紧张的话建议只下需要的 1~2 个档位308 GB for the whole repo — if disk is tight, download only the one or two tiers you need

lmstudio-community

apache-2.0
继承自基座 meta-models/Muse-Glimmer-30B,量化仓未单独声明

Inherited from base meta-models/Muse-Glimmer-30B — the quant repo declares none of its own
1 档1 tiers · 16 GB · 113k 下载113k downloads
它是什么What it islmstudio-community/Muse-Glimmer-30B-GGUF ↗,提供 1 个 GGUF 量化档,合计 16 GB。由 lmstudio-community 发布。lmstudio-community/Muse-Glimmer-30B-GGUF ↗, providing 1 GGUF tiers totalling 16 GB. Published by lmstudio-community.
量化者做了什么What the quantiser did未提供重要性矩阵(imatrix),走的是纯权重量化路线No importance matrix (imatrix); this is pure weight quantisation;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;权重总字节 16.8 GB(发布页 gguf.total 字段)Total weight bytes 16.8 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、bartowski 26 档tiers、AtomicChat 10 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, bartowski 26 tiers, AtomicChat 10 tiers, among others). 本仓 1 档,覆盖最少。 This repo has 1 tiers — the narrowest coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_K_M 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_K_M), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 平衡档落在 Q4_K_M(17 GB),是大多数人的起点The balanced tier lands on Q4_K_M (17 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K_M(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K_M directly (17 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 档位极少,没有升降空间,被显存卡住时无路可退Very few tiers, so there is no room to move up or down when VRAM runs out
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)No imatrix, so quality loss at the same tier may be more visible than in an imatrix build (our reading, to be verified by measurement)
· 量化仓自己没写许可字段,这里的 apache-2.0 是继承基座 meta-models/Muse-Glimmer-30B 的推断值——著作权上量化不可能脱离基座许可,但量化者的 redistribution 条款是否另有约定,需自己去读基座许可原文确认The quant repo declares no licence of its own; the apache-2.0 shown here is inferred from the base model's meta-models/Muse-Glimmer-30B — under copyright, a quantisation cannot escape the base licence. Whether the quantiser adds its own redistribution terms is for you to determine by reading the base licence.

bartowski

apache-2.0 26 档26 tiers · 468 GB · 26k 下载26k downloads
它是什么What it isbartowski/Muse-Glimmer-30B-GGUF ↗,提供 26 个 GGUF 量化档,合计 468 GB。由 bartowski 发布。bartowski/Muse-Glimmer-30B-GGUF ↗, providing 26 GGUF tiers totalling 468 GB. Published by bartowski.
量化者做了什么What the quantiser did带重要性矩阵(imatrix:/models_out/Muse-Glimmer-30B-GGUF/Muse-Glimmer-30B-imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳Ships an importance matrix (imatrix: /models_out/Muse-Glimmer-30B-GGUF/Muse-Glimmer-30B-imatrix.gguf) — quantises after scoring each layer by activation statistics, usually steadier than plain RTN;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 468.0 GB(发布页 gguf.total 字段)Total weight bytes 468.0 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、AtomicChat 10 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, AtomicChat 10 tiers, among others). 本仓 26 档,覆盖中等。 This repo has 26 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_K_L 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_K_L), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 档位覆盖最广的一档(26 档),从极限压缩到近似无损都能选The widest tier coverage here (26 tiers), from extreme compression up to near lossless
· 带 imatrix,同档位下质量通常更稳Ships imatrix, so quality at the same tier is usually steadier
· 平衡档落在 Q4_K_L(18 GB),是大多数人的起点The balanced tier lands on Q4_K_L (18 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K_L(18 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K_L directly (18 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 全仓 468 GB,硬盘紧张的话建议只下需要的 1~2 个档位468 GB for the whole repo — if disk is tight, download only the one or two tiers you need

AtomicChat

apache-2.0 10 档10 tiers · 382 GB · 15k 下载15k downloads
它是什么What it isAtomicChat/Muse-Glimmer-30B-GGUF ↗,提供 10 个 GGUF 量化档,合计 382 GB。由 AtomicChat 发布。AtomicChat/Muse-Glimmer-30B-GGUF ↗, providing 10 GGUF tiers totalling 382 GB. Published by AtomicChat.
量化者做了什么What the quantiser did带重要性矩阵(imatrix:/workspace/imatrix/muse-glimmer.imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳Ships an importance matrix (imatrix: /workspace/imatrix/muse-glimmer.imatrix.gguf) — quantises after scoring each layer by activation statistics, usually steadier than plain RTN;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 382.0 GB(发布页 gguf.total 字段)Total weight bytes 382.0 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, among others). 本仓 10 档,覆盖中等。 This repo has 10 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_K_M 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_K_M), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 带 imatrix,同档位下质量通常更稳Ships imatrix, so quality at the same tier is usually steadier
· 平衡档落在 Q4_K_M(19 GB),是大多数人的起点The balanced tier lands on Q4_K_M (19 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K_M(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K_M directly (19 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 全仓 382 GB,硬盘紧张的话建议只下需要的 1~2 个档位382 GB for the whole repo — if disk is tight, download only the one or two tiers you need

NANI-Nithin

apache-2.0 30 档30 tiers · 479 GB · 11k 下载11k downloads
它是什么What it isNANI-Nithin/Muse-Glimmer-30B-GGUF ↗,提供 30 个 GGUF 量化档,合计 479 GB。由 NANI-Nithin 发布。NANI-Nithin/Muse-Glimmer-30B-GGUF ↗, providing 30 GGUF tiers totalling 479 GB. Published by NANI-Nithin.
量化者做了什么What the quantiser did未提供重要性矩阵(imatrix),走的是纯权重量化路线No importance matrix (imatrix); this is pure weight quantisation;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 514.8 GB(发布页 gguf.total 字段)Total weight bytes 514.8 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, among others). 本仓 30 档,覆盖最全。 This repo has 30 tiers — the broadest coverage coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_1 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_1), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 档位覆盖最广的一档(30 档),从极限压缩到近似无损都能选The widest tier coverage here (30 tiers), from extreme compression up to near lossless
· 平衡档落在 Q4_1(18 GB),是大多数人的起点The balanced tier lands on Q4_1 (18 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_1(18 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_1 directly (18 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)No imatrix, so quality loss at the same tier may be more visible than in an imatrix build (our reading, to be verified by measurement)
· 全仓 479 GB,硬盘紧张的话建议只下需要的 1~2 个档位479 GB for the whole repo — if disk is tight, download only the one or two tiers you need

ggml-org

apache-2.0 3 档3 tiers · 105 GB · 6k 下载6k downloads
它是什么What it isggml-org/Muse-Glimmer-30B-GGUF ↗,提供 3 个 GGUF 量化档,合计 105 GB。由 ggml-org 发布。ggml-org/Muse-Glimmer-30B-GGUF ↗, providing 3 GGUF tiers totalling 105 GB. Published by ggml-org.
量化者做了什么What the quantiser did未提供重要性矩阵(imatrix),走的是纯权重量化路线No importance matrix (imatrix); this is pure weight quantisation;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 104.6 GB(发布页 gguf.total 字段)Total weight bytes 104.6 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, among others). 本仓 3 档,覆盖中等。 This repo has 3 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_K_M 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_K_M), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 平衡档落在 Q4_K_M(19 GB),是大多数人的起点The balanced tier lands on Q4_K_M (19 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K_M(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K_M directly (19 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 档位极少,没有升降空间,被显存卡住时无路可退Very few tiers, so there is no room to move up or down when VRAM runs out
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)No imatrix, so quality loss at the same tier may be more visible than in an imatrix build (our reading, to be verified by measurement)

Abiray

apache-2.0 10 档10 tiers · 160 GB · 716 下载716 downloads
它是什么What it isAbiray/Muse-Glimmer-30B-GGUF ↗,提供 10 个 GGUF 量化档,合计 160 GB。由 Abiray 发布。Abiray/Muse-Glimmer-30B-GGUF ↗, providing 10 GGUF tiers totalling 160 GB. Published by Abiray.
量化者做了什么What the quantiser did带重要性矩阵(imatrix:/models_out/Muse-Glimmer-30B-GGUF/Muse-Glimmer-30B-imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳Ships an importance matrix (imatrix: /models_out/Muse-Glimmer-30B-GGUF/Muse-Glimmer-30B-imatrix.gguf) — quantises after scoring each layer by activation statistics, usually steadier than plain RTN;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 171.6 GB(发布页 gguf.total 字段)Total weight bytes 171.6 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, among others). 本仓 10 档,覆盖中等。 This repo has 10 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_K_M 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_K_M), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 带 imatrix,同档位下质量通常更稳Ships imatrix, so quality at the same tier is usually steadier
· 平衡档落在 Q4_K_M(17 GB),是大多数人的起点The balanced tier lands on Q4_K_M (17 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K_M(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K_M directly (17 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 暂未发现明显取舍(不代表没有,建议先下一档实测)No obvious trade-off found (which is not the same as none — download one tier and measure before committing)

mradermacher

apache-2.0 11 档11 tiers · 179 GB · 655 下载655 downloads
它是什么What it ismradermacher/Muse-Glimmer-30B-GGUF ↗,提供 11 个 GGUF 量化档,合计 179 GB。由 mradermacher 发布。mradermacher/Muse-Glimmer-30B-GGUF ↗, providing 11 GGUF tiers totalling 179 GB. Published by mradermacher.
量化者做了什么What the quantiser did未提供重要性矩阵(imatrix),走的是纯权重量化路线No importance matrix (imatrix); this is pure weight quantisation;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;发布页声明溯源到 meta-models/Muse-Glimmer-30BThe release page traces this back to meta-models/Muse-Glimmer-30B;权重总字节 191.6 GB(发布页 gguf.total 字段)Total weight bytes 191.6 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, among others). 本仓 11 档,覆盖中等。 This repo has 11 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(Q4_K_M 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as Q4_K_M), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 平衡档落在 Q4_K_M(17 GB),是大多数人的起点The balanced tier lands on Q4_K_M (17 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 Q4_K_M(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take Q4_K_M directly (17 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)No imatrix, so quality loss at the same tier may be more visible than in an imatrix build (our reading, to be verified by measurement)

ddh0

apache-2.0
继承自基座 meta-models/Muse-Glimmer-30B,量化仓未单独声明

Inherited from base meta-models/Muse-Glimmer-30B — the quant repo declares none of its own
8 档8 tiers · 144 GB · 349 下载349 downloads
它是什么What it isddh0/Muse-Glimmer-30B-GGUF ↗,提供 8 个 GGUF 量化档,合计 144 GB。由 ddh0 发布。ddh0/Muse-Glimmer-30B-GGUF ↗, providing 8 GGUF tiers totalling 144 GB. Published by ddh0.
量化者做了什么What the quantiser did带重要性矩阵(imatrix:/home/dylan/imatrices/Muse-Glimmer-30B-ddh0_v2-imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳Ships an importance matrix (imatrix: /home/dylan/imatrices/Muse-Glimmer-30B-ddh0_v2-imatrix.gguf) — quantises after scoring each layer by activation statistics, usually steadier than plain RTN;针对 muse-glimmer 架构优化Optimised for the muse-glimmer architecture;声明上下文 131,072 tokensDeclared context 131,072 tokens;权重总字节 155.0 GB(发布页 gguf.total 字段)Total weight bytes 155.0 GB (the release page's gguf.total field)。
与同系列其他变体的区别How it differs from other variants in this series同系列另有 9 个量化来源(meta-models 2 档tiers、unsloth 15 档tiers、lmstudio-community 1 档tiers、bartowski 26 档tiers 等)。The series has 9 other quantisation sources (meta-models 2 tiers, unsloth 15 tiers, lmstudio-community 1 tiers, bartowski 26 tiers, among others). 本仓 8 档,覆盖中等。 This repo has 8 tiers — middling coverage in this series.
存在的意义Why it exists补上官方没覆盖的档位(作者标注 4.66bpw 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。Fills tiers the official build does not cover (such as author-stated 4.66bpw), so you can get it running on limited VRAM — or trade the other way, for more precision and quality.
优势Strengths· 带 imatrix,同档位下质量通常更稳Ships imatrix, so quality at the same tier is usually steadier
· 平衡档落在 作者标注 4.66bpw(16 GB),是大多数人的起点The balanced tier lands on author-stated 4.66bpw (16 GB), the starting point for most people
为什么选它 / 目的Why you would pick it / its purpose如果你的瓶颈是显存:直接下 作者标注 4.66bpw(16 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
If VRAM is your constraint: take author-stated 4.66bpw directly (16 GB, Balanced).
If speed is your constraint: this repo has nothing faster — GGUF speed is decided by architecture and backend, not by quantisation tier — so switching quantiser will not help.
If quality is your constraint: step up one tier to conservative (Q5_K_M / Q6_K).
已知取舍Known trade-offs· 量化仓自己没写许可字段,这里的 apache-2.0 是继承基座 meta-models/Muse-Glimmer-30B 的推断值——著作权上量化不可能脱离基座许可,但量化者的 redistribution 条款是否另有约定,需自己去读基座许可原文确认The quant repo declares no licence of its own; the apache-2.0 shown here is inferred from the base model's meta-models/Muse-Glimmer-30B — under copyright, a quantisation cannot escape the base licence. Whether the quantiser adds its own redistribution terms is for you to determine by reading the base licence.

E量化者档案Quantiser profiles 选量化者意味着什么what choosing a quantiser means

量化者决定了这个包的档位覆盖、命名规范、是否带 imatrix、什么时候跟进新模型。这一区块说明「选这个量化者的量化意味着什么」。The quantiser decides this build's tier coverage, naming convention, whether it ships imatrix, and how fast it follows new models. This section spells out what choosing that quantiser means.

meta-models

在本系列:1 个仓 · 210k 下载In this series: 1 repos · 210k downloads · 含官方仓 · includes the official repo

<p class="muted">该发布者未提供说明。以下为该仓库的客观元数据(规格、许可、文件体积、更新时间),不含本站的主观解读。</p>

<p class="muted">This publisher ships no description. What follows is the repo’s own metadata (size, licence, file size, last updated) — no editorialising from us.</p>

发布页 ↗release page ↗

unsloth 量化覆盖面最广、下载量最高的第三方量化者Broadest coverage, highest downloads

在本系列:1 个仓 · 789k 下载In this series: 1 repos · 789k downloads

定位:量化覆盖面最广、下载量最高的第三方量化者。

擅长什么:几乎每个主流基础模型都第一时间跟 GGUF,且档位最全——从极限压缩到近似无损一应俱全。提供静态(static)与动态(dynamic,用 UD- 前缀)两套量化。

  • 为什么要认 unsloth 版:
  • 覆盖率高 → 你想要的档位通常都有
  • 命名规范 → Q4_K_M 就是 Q4_K_M,不会同档不同名
  • 带 importance matrix(imatrix)→ 量化质量比纯 RTN 更稳
  • 官方教程与 LM Studio / llama.cpp 集成路径最顺

注意:unsloth 的动态量化(UD-Q4_K_XL 等)在同档位下体积略大、速度略慢,换来的是质量通常更好。是否值得取决于你的瓶颈是显存还是速度——这是我们的口径,不是实测结论。

官方发布页:https://huggingface.co/unsloth

Position: The broadest quantisation coverage and the highest downloads among third-party quantisers.

What it is good at: publishes GGUF for almost every mainstream base model first, with the most complete tier range — from extreme compression to near lossless. Offers both static and dynamic (the UD- prefix) quantisation.

  • Why choose the unsloth build:
  • Broad coverage → the tier you want is usually there
  • Naming discipline → Q4_K_M means Q4_K_M, with no different name for the same tier
  • Ships an importance matrix (imatrix) → quality is steadier than plain RTN
  • The smoothest path to official tutorials and LM Studio / llama.cpp integration

Note: unsloth's dynamic quantisation (UD-Q4_K_XL and similar) is slightly larger and slightly slower at the same tier, in exchange for usually better quality. Whether that trade is worth it depends on whether your bottleneck is VRAM or speed — this is our reading, not a measurement.

Release page: https://huggingface.co/unsloth

发布页 ↗release page ↗

lmstudio-community LM Studio 官方社区组织,为其 GUI 客户端供包Powers the LM Studio GUI

在本系列:1 个仓 · 113k 下载In this series: 1 repos · 113k downloads

定位:LM Studio 桌面客户端的官方社区组织,为其 GUI 供包。

  • 特点:
  • 档位偏保守务实,以「在 LM Studio 里能顺畅跑起来」为目标筛选
  • 文件命名与 LM Studio 的模型库索引对得上,下载后能被客户端直接识别
  • 也会带 MTP / 投机采样相关的特殊版本

适合谁:如果你用 LM Studio 而不是自己敲 llama-server 命令行,这个组织的包省心程度最高。

不适合谁:如果你要精细控制加载参数(tensor split、n_gpu_layers、上下文分配),社区包往往不针对你的硬件调优,仍要自己调。

发布页:https://huggingface.co/lmstudio-community

Position: The official community organisation behind the LM Studio desktop client, supplying packages for its GUI.

  • Characteristics:
  • Tiers lean conservative and pragmatic, selected for "runs smoothly inside LM Studio"
  • File naming lines up with LM Studio's model library index, so downloads are recognised by the client directly
  • Also ships special builds related to MTP / speculative sampling

Who it suits: if you use LM Studio rather than driving llama-server yourself, packages from this organisation save the most fuss.

Who it does not suit: if you need fine control over load parameters (tensor split, n_gpu_layers, context allocation) — community packages are usually not tuned to your hardware, so you still tune them yourself.

Release page: https://huggingface.co/lmstudio-community

发布页 ↗release page ↗

bartowski 老牌量化者,档位命名规范、说明文档最完整Veteran quantizer, best-documented naming

在本系列:1 个仓 · 26k 下载In this series: 1 repos · 26k downloads

定位:老牌量化者,档位命名规范、说明文档最完整。

  • 特点:
  • 每档位都写清「这个档适合什么场景」,不是只丢一堆文件
  • 命名遵循 llama.cpp 约定,Q4_K_M 就是社区通义的那个 Q4_K_M
  • 同一个模型常常同时提供静态量化与 imatrix 量化两个目录

怎么选他的包:看仓库里的 README 分档说明,那是少数把「为什么这档质量损失小、那档损失大」写清楚的地方。

注意:他的仓库名常带 Qwen_ Meta-Llama_ 这类前缀(因为 HF 仓库名不允许重复,量化者要加模型组织名消歧),搜仓时别漏掉前缀。

发布页:https://huggingface.co/bartowski

Position: A long-standing quantiser with the most complete tier naming and documentation.

  • Characteristics:
  • Every tier states what scenario it suits, rather than just dumping files
  • Naming follows the llama.cpp convention — Q4_K_M is the community's Q4_K_M
  • The same model often ships both static and imatrix directories

How to choose their builds: read the tier-by-tier README in the repo — it is one of the few places that actually explains *why* one tier loses little quality and another loses more.

Note: repo names often carry a Qwen_ or Meta-Llama_ prefix (Hugging Face repo names must be unique, so quantisers prefix the organisation name to disambiguate) — do not miss the prefix when searching.

Release page: https://huggingface.co/bartowski

发布页 ↗release page ↗

AtomicChat

在本系列:1 个仓 · 15k 下载In this series: 1 repos · 15k downloads

<p class="muted">该发布者未提供说明。以下为该仓库的客观元数据(规格、许可、文件体积、更新时间),不含本站的主观解读。</p>

<p class="muted">This publisher ships no description. What follows is the repo’s own metadata (size, licence, file size, last updated) — no editorialising from us.</p>

发布页 ↗release page ↗

NANI-Nithin

在本系列:1 个仓 · 11k 下载In this series: 1 repos · 11k downloads

<p class="muted">该发布者未提供说明。以下为该仓库的客观元数据(规格、许可、文件体积、更新时间),不含本站的主观解读。</p>

<p class="muted">This publisher ships no description. What follows is the repo’s own metadata (size, licence, file size, last updated) — no editorialising from us.</p>

发布页 ↗release page ↗

ggml-org llama.cpp 所属组织的官方量化发布Official quant builds from the llama.cpp org

在本系列:1 个仓 · 6k 下载In this series: 1 repos · 6k downloads

定位:llama.cpp 自己的官方量化发布渠道。

为什么重要:ggml 是 llama.cpp 的底层张量库,ggml-org 发的 GGUF 由项目核心作者把关。遇到新架构(比如新出的 MoE 稀疏模型),ggml-org 通常是第一个支持并发布可用 GGUF 的。

  • 特点:
  • 档位偏保守,优先保证能正确加载与推理不出错
  • 覆盖不一定全(作者精力有限,只跟进自己关心的模型)
  • 适合作为「该架构能不能在 llama.cpp 上跑」的权威参考

适合谁:想第一时间在新架构上尝鲜、或者需要确认某个模型是否已被 llama.cpp 支持。

发布页:https://huggingface.co/ggml-org

Position: The official quantisation release channel of llama.cpp itself.

Why it matters: ggml is llama.cpp's underlying tensor library, and ggml-org's GGUFs are vetted by the project's core authors. When a new architecture appears (a new sparse MoE, say), ggml-org is usually the first to support it and publish a usable GGUF.

  • Characteristics:
  • Tiers lean conservative, prioritising correct loading and inference that does not break
  • Coverage is not necessarily complete (limited authorial bandwidth — they track only models they care about)
  • Serves as the authoritative reference for "can this architecture run on llama.cpp at all"

Who it suits: people who want to try a new architecture first-hand, or need to confirm whether llama.cpp supports a given model.

Release page: https://huggingface.co/ggml-org

发布页 ↗release page ↗

Abiray

在本系列:1 个仓 · 716 下载In this series: 1 repos · 716 downloads

<p class="muted">该发布者未提供说明。以下为该仓库的客观元数据(规格、许可、文件体积、更新时间),不含本站的主观解读。</p>

<p class="muted">This publisher ships no description. What follows is the repo’s own metadata (size, licence, file size, last updated) — no editorialising from us.</p>

发布页 ↗release page ↗

mradermacher Mirostat 作者,长期做低比特实验性量化Known for experimental low-bit quants

在本系列:1 个仓 · 655 下载In this series: 1 repos · 655 downloads

定位:Mirostat 采样算法作者,长期做低比特实验性量化。

  • 特点:
  • 愿意发别人不敢发的极低比特档位(IQ2_XXS、Q2_K 这类)
  • 关注点在「量化方法本身」——会试不同的 imatrix、不同的重要性矩阵来源
  • 文件命名带 i1 h2 之类的后缀,标明用的是哪一版重要性矩阵

适合谁:在做「极小显存里塞下最大模型」这类实验,或者想对比不同重要性矩阵对质量的影响。

不适合谁:日常使用。极低比特档位的质量损失通常已经很明显了,除非你确实没有别的选择,否则不建议作为主力。

发布页:https://huggingface.co/mradermacher

Position: Author of the Mirostat sampling algorithm, long-running low-bit experimental quantisations.

  • Characteristics:
  • Willing to publish very low-bit tiers others dare not (IQ2_XXS, Q2_K and the like)
  • Focused on the quantisation method itself — tries different imatrix files and different sources for the importance matrix
  • File names carry suffixes like i1 or h2, marking which version of the importance matrix was used

Who it suits: experiments along the lines of "fit the largest possible model into the smallest possible VRAM", or comparisons of how different importance matrices affect quality.

Who it does not suit: everyday use. Quality loss at those very low bits is usually already noticeable — unless you genuinely have no alternative, do not make it your primary build.

Release page: https://huggingface.co/mradermacher

发布页 ↗release page ↗

ddh0

在本系列:1 个仓 · 349 下载In this series: 1 repos · 349 downloads

<p class="muted">该发布者未提供说明。以下为该仓库的客观元数据(规格、许可、文件体积、更新时间),不含本站的主观解读。</p>

<p class="muted">This publisher ships no description. What follows is the repo’s own metadata (size, licence, file size, last updated) — no editorialising from us.</p>

发布页 ↗release page ↗

F更新记录Update history 谁在跟进who is keeping up

按更新时间倒序。更新频繁说明该量化者在跟进新版本;长期不更新则基础模型升版后可能不同步。Sorted by most recent update. Frequent updates mean the quantiser is tracking new releases; a long silence means it may have fallen behind the base model.

  • 2026-10-28 AtomicChat 更新了 10 个档位updated 10 tiers · 含 imatrix · with imatrix
  • 2026-10-25 ggml-org 更新了 3 个档位updated 3 tiers
  • 2026-10-20 meta-models 更新了 2 个档位updated 2 tiers
  • 2026-09-07 NANI-Nithin 更新了 30 个档位updated 30 tiers
  • 2026-08-13 bartowski 更新了 26 个档位updated 26 tiers · 含 imatrix · with imatrix
  • 2026-08-12 lmstudio-community 更新了 1 个档位updated 1 tiers
  • 2026-08-12 mradermacher 更新了 11 个档位updated 11 tiers
  • 2026-08-10 ddh0 更新了 8 个档位updated 8 tiers · 含 imatrix · with imatrix
  • 2026-08-10 Abiray 更新了 10 个档位updated 10 tiers · 含 imatrix · with imatrix
  • 2026-08-10 unsloth 更新了 15 个档位updated 15 tiers

基础模型Base model meta-models/Muse-Glimmer-30B 最近更新:last updated: 2026-10-22 · 本站采集时间:collected: 2026-10-30

下好之后用什么跑What runs it

本站只负责「该下哪一档」。跑起来是另一件事 —— 下面这几个工具自己的文档里写明了支持本地模型(Ollama / vLLM / llama.cpp / LM Studio),点进去看具体怎么接。This site only answers which tier to download. Running it is a different problem — the tools below document local-model support in their own docs (Ollama / vLLM / llama.cpp / LM Studio). Follow the link to see how.

这些条目的本地模型支持情况由它们自己的官方文档佐证;本站不实测。Local-model support for each entry is evidenced by that project official documentation. This site runs no measurements.