跳到主要内容

GoogleGoogle · 发布于 2026-06

Gemma 4Gemma 4

Google 开放权重最新一代,三种规格各自都有量化覆盖。

  • 通用对话
  • MoE 稀疏
  • 小尺寸可跑

先说清楚:这个站的数据怎么来的

✅ 实测字段

直接从 Hugging Face 公开 API 读取的客观数据:文件体积(字节)、上下文长度、架构、许可、下载量、更新时间。

✅ 推导

由实测字段按公开规则算出:每权重比特数(依 llama.cpp 命名标准)、档位归属、显存需求区间。推导规则在 METHODOLOGY.md 完整公开,任何人可复算。

❌ 我们不说的

哪个量化质量更高、哪个更快、哪个模型更强——这些需要实测,本站不跑 benchmark,所以不装作知道。凡我们给出的主观判断,一律显式标注「我们的口径」。

本站不下载、不托管任何模型权重文件。所有数字都来自公开元数据,点击即可回到发布页核对。 采集时间:2026-09-30(数据快照,非实时)

成员 1Gemma 4 26B-A4B(MoE)

26B 总参 / 4B 激活 · 低延迟 MoE · 8 个量化来源

A基础模型卡 这一档位是什么

官方发布页google/gemma-4-26B-A4B-it ↗
许可apache-2.0 许可原文 ↗
规模26B 总参 / 4B 激活
架构gemma4
上下文长度262,144 tokens
定位低延迟 MoE
官方下载量12.5M 点赞 2k
最近更新2026-07-20

MoE:总参 26B 但每 token 只激活约 4B,速度接近 4B 稠密。

B该选哪个 按你的显存倒推

按「你实际有多少显存能装」选档位,而不是按参数猜。下面每档的体积都是实测值(来自发布页文件列表),加权 15% 余量给运行时与 KV cache。

显存 → 档位速查(体积最小的可行档,质量最高的那一档)
8 GB 显存 Q8_0(0.5 GB · 近似无损)
更省:BF16 0.9 GB
消费级入门卡、共享显卡
12 GB 显存 Q8_0(0.5 GB · 近似无损)
更省:IQ2_S 10 GB / BF16 0.9 GB
RTX 3060 12G / 4060Ti 16G 降配使用
16 GB 显存 Q8_0(0.5 GB · 近似无损)
更省:UD-Q3_K_XL 13 GB / BF16 0.9 GB
RTX 4060Ti 16G / 4070S 超配
24 GB 显存 Q8_0(0.5 GB · 近似无损)
更省:Q5_K 18 GB / BF16 0.9 GB
RTX 3090 / 4090
48 GB+ 显存 Q8_0(0.5 GB · 近似无损)
更省:UD-Q8_K_XL 28 GB / BF16 0.9 GB
A6000 / L40S / Mac 统一内存
展开:本系列所有档位的实测体积(32 档)
量化档体积每权重比特档位最小体积来源
UD-IQ2_XXS 9.9 GB 2.13 bpw 极限压缩 unsloth
IQ2_XXS 9.7 GB 2.13 bpw 极限压缩 bartowski
IQ2_XS 10 GB 2.31 bpw 极限压缩 bartowski
UD-IQ2_M 10 GB 2.39 bpw 极限压缩 unsloth
IQ2_M 11 GB 2.39 bpw 极限压缩 bartowski
IQ2_S 10 GB 2.46 bpw 极限压缩 bartowski
Q2_K 11 GB 2.80 bpw 极限压缩 AtomicChat
UD-IQ3_XXS 11 GB 3.06 bpw 长上下文优先 unsloth
IQ3_XXS 12 GB 3.06 bpw 长上下文优先 bartowski
UD-IQ3_S 11 GB 3.35 bpw 长上下文优先 unsloth
UD-Q2_K_XL 11 GB 3.35 bpw 长上下文优先 unsloth
IQ3_XS 12 GB 3.36 bpw 长上下文优先 bartowski
Q3_K 12 GB 3.55 bpw 长上下文优先 giladgd
IQ3_M 12 GB 3.66 bpw 长上下文优先 AtomicChat
UD-IQ4_NL 14 GB 4.05 bpw 平衡档 unsloth
IQ4_NL 15 GB 4.05 bpw 平衡档 bartowski
UD-Q3_K_M 13 GB 4.15 bpw 平衡档 unsloth
MXFP4 17 GB 4.25 bpw 平衡档 unsloth
UD-IQ4_XS 14 GB 4.25 bpw 平衡档 unsloth
IQ4_XS 14 GB 4.25 bpw 平衡档 AtomicChat
UD-Q3_K_XL 13 GB 4.42 bpw 平衡档 unsloth
Q4_0 14 GB 4.55 bpw 平衡档 giladgd
Q4_1 16 GB 4.83 bpw 平衡档 bartowski
Q4_K 15 GB 4.85 bpw 平衡档 AtomicChat
Q5_0 18 GB 5.54 bpw 保守档 giladgd
UD-Q4_K_XL 17 GB 5.62 bpw 保守档 AtomicChat
Q5_K 18 GB 5.69 bpw 保守档 AtomicChat
UD-Q6_K 23 GB 6.54 bpw 保守档 unsloth
Q6_K 23 GB 6.59 bpw 保守档 lmstudio-community
Q8_0 0.5 GB 8.50 bpw 近似无损 ggml-org
UD-Q8_K_XL 28 GB 8.72 bpw 近似无损 unsloth
BF16 0.9 GB 16.00 bpw 近似无损 ggml-org

「每权重比特」是按 llama.cpp 公开命名标准从文件名推导的,同一档位在不同模型上的真实值会略有差异。这是 B 级推导,不是实测值。

C量化版本总表 横向对比

量化者许可档数总体积 上下文建议档下载量更新
unsloth imatrix
gemma4
apache-2.0 17 359 GB 262,144 Q4_K
17 GB
544k 2026-07-17
ggml-org
gemma4
apache-2.0 3 87 GB 262,144 Q4_0
15 GB
397k 2026-07-26
bartowski imatrix
gemma4
apache-2.0 18 413 GB 262,144 Q4_K
17 GB
57k 2026-07-27
lmstudio-community
gemma4
apache-2.0 3 62 GB 262,144 Q4_K
17 GB
41k 2026-07-20
AtomicChat imatrix
gemma4
apache-2.0 9 186 GB 262,144 Q4_K
17 GB
5k 2026-07-24
giladgd
gemma4
apache-2.0 9 234 GB 262,144 Q4_K
17 GB
2k 2026-06-28
mradermacher
gemma4
apache-2.0 7 170 GB 262,144 Q4_K
17 GB
2k 2026-04-06
indiansatoshi imatrix
gemma4
apache-2.0 18 413 GB 262,144 Q4_K
17 GB
1k 2026-05-14

「建议档」是本站按体积最小且落在平衡档的规则自动选出的,不是质量排名。官方量化排在最前;带 imatrix 标记的仓库带重要性矩阵数据。

D每个变体详解 七字段

每个变体按七个字段展开:它是什么 → 量化者做了什么 → 与同系列其他变体的区别 → 存在的意义 → 优势 → 为什么选它 → 已知取舍。最后一项是本站唯一会写主观判断的地方,且都标注了「我们的口径」。

unsloth

apache-2.0 17 档 · 359 GB · 544k 下载
它是什么unsloth/gemma-4-26B-A4B-it-GGUF ↗,提供 17 个 GGUF 量化档,合计 359 GB。由 unsloth 发布。
量化者做了什么带重要性矩阵(imatrix:gemma-4-26B-A4B-it-GGUF/imatrix_unsloth.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 385.7 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(ggml-org 3 档、bartowski 18 档、lmstudio-community 3 档、AtomicChat 9 档 等)。 本仓 17 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 全仓 359 GB,硬盘紧张的话建议只下需要的 1~2 个档位

ggml-org

apache-2.0 3 档 · 87 GB · 397k 下载
它是什么ggml-org/gemma-4-26B-A4B-it-GGUF ↗,提供 3 个 GGUF 量化档,合计 87 GB。由 ggml-org 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 93.3 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、bartowski 18 档、lmstudio-community 3 档、AtomicChat 9 档 等)。 本仓 3 档,覆盖最少。
存在的意义补上官方没覆盖的档位(Q4_0 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_0(15 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_0(15 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

bartowski

apache-2.0 18 档 · 413 GB · 57k 下载
它是什么bartowski/google_gemma-4-26B-A4B-it-GGUF ↗,提供 18 个 GGUF 量化档,合计 413 GB。由 bartowski 发布。
量化者做了什么带重要性矩阵(imatrix:/models_out/gemma-4-26B-A4B-it-GGUF/google_gemma-4-26B-A4B-it-imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 442.9 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、ggml-org 3 档、lmstudio-community 3 档、AtomicChat 9 档 等)。 本仓 18 档,覆盖最全。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 全仓 413 GB,硬盘紧张的话建议只下需要的 1~2 个档位

lmstudio-community

apache-2.0 3 档 · 62 GB · 41k 下载
它是什么lmstudio-community/gemma-4-26B-A4B-it-GGUF ↗,提供 3 个 GGUF 量化档,合计 62 GB。由 lmstudio-community 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 66.3 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、ggml-org 3 档、bartowski 18 档、AtomicChat 9 档 等)。 本仓 3 档,覆盖最少。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

AtomicChat

apache-2.0 9 档 · 186 GB · 5k 下载
它是什么AtomicChat/gemma-4-26B-A4B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 186 GB。由 AtomicChat 发布。
量化者做了什么带重要性矩阵(imatrix:/root/work/gemma-4-26B-A4B-it/imatrix-coding.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 199.9 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、ggml-org 3 档、bartowski 18 档、lmstudio-community 3 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 暂未发现明显取舍(不代表没有,建议先下一档实测)

giladgd

apache-2.0 9 档 · 234 GB · 2k 下载
它是什么giladgd/gemma-4-26B-A4B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 234 GB。由 giladgd 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 251.2 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、ggml-org 3 档、bartowski 18 档、lmstudio-community 3 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)
· 全仓 234 GB,硬盘紧张的话建议只下需要的 1~2 个档位

mradermacher

apache-2.0 7 档 · 170 GB · 2k 下载
它是什么mradermacher/gemma-4-26B-A4B-it-GGUF ↗,提供 7 个 GGUF 量化档,合计 170 GB。由 mradermacher 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 182.9 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、ggml-org 3 档、bartowski 18 档、lmstudio-community 3 档 等)。 本仓 7 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

indiansatoshi

apache-2.0 18 档 · 413 GB · 1k 下载
它是什么indiansatoshi/google_gemma-4-26B-A4B-it-GGUF ↗,提供 18 个 GGUF 量化档,合计 413 GB。由 indiansatoshi 发布。
量化者做了什么带重要性矩阵(imatrix:/models_out/gemma-4-26B-A4B-it-GGUF/google_gemma-4-26B-A4B-it-imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-26B-A4B-it;权重总字节 442.9 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 17 档、ggml-org 3 档、bartowski 18 档、lmstudio-community 3 档 等)。 本仓 18 档,覆盖最全。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(17 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(17 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 全仓 413 GB,硬盘紧张的话建议只下需要的 1~2 个档位

E量化者档案 选量化者意味着什么

量化者决定了这个包的档位覆盖、命名规范、是否带 imatrix、什么时候跟进新模型。这一区块说明「选这个量化者的量化意味着什么」。

unsloth 量化覆盖面最广、下载量最高的第三方量化者

在本系列:1 个仓 · 544k 下载

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

擅长什么:几乎每个主流基础模型都第一时间跟 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

发布页 ↗

ggml-org llama.cpp 所属组织的官方量化发布

在本系列:1 个仓 · 397k 下载

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

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

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

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

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

发布页 ↗

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

在本系列:1 个仓 · 57k 下载

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

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

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

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

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

发布页 ↗

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

在本系列:1 个仓 · 41k 下载

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

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

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

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

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

发布页 ↗

AtomicChat

在本系列:1 个仓 · 5k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

giladgd

在本系列:1 个仓 · 2k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

mradermacher Mirostat 作者,长期做低比特实验性量化

在本系列:1 个仓 · 2k 下载

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

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

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

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

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

发布页 ↗

indiansatoshi

在本系列:1 个仓 · 1k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

F更新记录 谁在跟进

按更新时间倒序。更新频繁说明该量化者在跟进新版本;长期不更新则基础模型升版后可能不同步。

  • 2026-07-27 bartowski 更新了 18 个档位 · 含 imatrix
  • 2026-07-26 ggml-org 更新了 3 个档位
  • 2026-07-24 AtomicChat 更新了 9 个档位 · 含 imatrix
  • 2026-07-20 lmstudio-community 更新了 3 个档位
  • 2026-07-17 unsloth 更新了 17 个档位 · 含 imatrix
  • 2026-06-28 giladgd 更新了 9 个档位
  • 2026-05-14 indiansatoshi 更新了 18 个档位 · 含 imatrix
  • 2026-04-06 mradermacher 更新了 7 个档位

基础模型 google/gemma-4-26B-A4B-it 最近更新:2026-07-20 · 本站采集时间:2026-09-30

成员 2Gemma 4 31B(密集)

31B 密集 · 质量优先 · 8 个量化来源

A基础模型卡 这一档位是什么

官方发布页google/gemma-4-31B-it ↗
许可apache-2.0 许可原文 ↗
规模31B 密集
架构gemma4
上下文长度262,144 tokens
定位质量优先
官方下载量9.7M 点赞 4k
最近更新2026-07-20

同系列里最重的规格。

B该选哪个 按你的显存倒推

按「你实际有多少显存能装」选档位,而不是按参数猜。下面每档的体积都是实测值(来自发布页文件列表),加权 15% 余量给运行时与 KV cache。

显存 → 档位速查(体积最小的可行档,质量最高的那一档)
8 GB 显存 Q8_0(1.6 GB · 近似无损)
更省:BF16 3.1 GB
消费级入门卡、共享显卡
12 GB 显存 Q8_0(1.6 GB · 近似无损)
更省:IQ2_XS 10 GB / BF16 3.1 GB
RTX 3060 12G / 4060Ti 16G 降配使用
16 GB 显存 Q8_0(1.6 GB · 近似无损)
更省:Q3_K 13 GB / BF16 3.1 GB
RTX 4060Ti 16G / 4070S 超配
24 GB 显存 Q8_0(1.6 GB · 近似无损)
更省:UD-Q4_K_XL 19 GB / BF16 3.1 GB
RTX 3090 / 4090
48 GB+ 显存 Q8_0(1.6 GB · 近似无损)
更省:UD-Q8_K_XL 35 GB / BF16 3.1 GB
A6000 / L40S / Mac 统一内存
展开:本系列所有档位的实测体积(29 档)
量化档体积每权重比特档位最小体积来源
IQ1_S 7.9 GB 1.62 bpw 极限压缩 Mungert
IQ1_M 9.1 GB 1.90 bpw 极限压缩 Mungert
UD-IQ2_XXS 8.5 GB 2.13 bpw 极限压缩 unsloth
IQ2_XXS 9.1 GB 2.13 bpw 极限压缩 Mungert
IQ2_XS 10 GB 2.31 bpw 极限压缩 Mungert
UD-IQ2_M 11 GB 2.39 bpw 极限压缩 unsloth
IQ2_M 11 GB 2.39 bpw 极限压缩 Mungert
IQ2_S 11 GB 2.46 bpw 极限压缩 Mungert
Q2_K 12 GB 2.80 bpw 极限压缩 Mungert
UD-IQ3_XXS 12 GB 3.06 bpw 长上下文优先 unsloth
IQ3_XXS 13 GB 3.06 bpw 长上下文优先 bartowski
UD-Q2_K_XL 12 GB 3.35 bpw 长上下文优先 unsloth
IQ3_XS 13 GB 3.36 bpw 长上下文优先 Mungert
Q3_K 13 GB 3.55 bpw 长上下文优先 unsloth
IQ3_M 14 GB 3.66 bpw 长上下文优先 AtomicChat
IQ4_NL 17 GB 4.05 bpw 平衡档 unsloth
IQ4_XS 16 GB 4.25 bpw 平衡档 unsloth
UD-Q3_K_XL 15 GB 4.42 bpw 平衡档 unsloth
Q4_0 17 GB 4.55 bpw 平衡档 unsloth
Q4_1 19 GB 4.83 bpw 平衡档 unsloth
Q4_K 17 GB 4.85 bpw 平衡档 unsloth
Q5_0 21 GB 5.54 bpw 保守档 giladgd
UD-Q4_K_XL 19 GB 5.62 bpw 保守档 unsloth
Q5_K 21 GB 5.69 bpw 保守档 unsloth
UD-Q6_K 28 GB 6.54 bpw 保守档 unsloth
Q6_K 25 GB 6.59 bpw 保守档 unsloth
Q8_0 1.6 GB 8.50 bpw 近似无损 ggml-org
UD-Q8_K_XL 35 GB 8.72 bpw 近似无损 unsloth
BF16 3.1 GB 16.00 bpw 近似无损 ggml-org

「每权重比特」是按 llama.cpp 公开命名标准从文件名推导的,同一档位在不同模型上的真实值会略有差异。这是 B 级推导,不是实测值。

C量化版本总表 横向对比

量化者许可档数总体积 上下文建议档下载量更新
unsloth imatrix
gemma4
apache-2.0 18 426 GB 262,144 Q4_1
19 GB
343k 2026-07-17
bartowski imatrix
gemma4
apache-2.0 19 498 GB 262,144 Q4_K
20 GB
39k 2026-07-27
lmstudio-community
gemma4
apache-2.0 3 71 GB 262,144 Q4_K
19 GB
37k 2026-07-20
ggml-org
gemma4
apache-2.0 3 109 GB 262,144 Q4_0
18 GB
29k 2026-07-26
AtomicChat imatrix
gemma4
apache-2.0 9 216 GB 262,144 Q4_K
19 GB
4k 2026-07-24
giladgd
gemma4
apache-2.0 9 275 GB 262,144 Q4_K
19 GB
3k 2026-06-28
Mungert
gemma4
apache-2.0 18 388 GB 262,144 Q4_K
19 GB
3k 2026-06-05
mradermacher
gemma4
apache-2.0 7 197 GB 262,144 Q4_K
19 GB
1k 2026-04-18

「建议档」是本站按体积最小且落在平衡档的规则自动选出的,不是质量排名。官方量化排在最前;带 imatrix 标记的仓库带重要性矩阵数据。

D每个变体详解 七字段

每个变体按七个字段展开:它是什么 → 量化者做了什么 → 与同系列其他变体的区别 → 存在的意义 → 优势 → 为什么选它 → 已知取舍。最后一项是本站唯一会写主观判断的地方,且都标注了「我们的口径」。

unsloth

apache-2.0 18 档 · 426 GB · 343k 下载
它是什么unsloth/gemma-4-31B-it-GGUF ↗,提供 18 个 GGUF 量化档,合计 426 GB。由 unsloth 发布。
量化者做了什么带重要性矩阵(imatrix:gemma-4-31B-it-GGUF/imatrix_unsloth.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 457.4 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(bartowski 19 档、lmstudio-community 3 档、ggml-org 3 档、AtomicChat 9 档 等)。 本仓 18 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_1 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_1(19 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_1(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 全仓 426 GB,硬盘紧张的话建议只下需要的 1~2 个档位

bartowski

apache-2.0 19 档 · 498 GB · 39k 下载
它是什么bartowski/google_gemma-4-31B-it-GGUF ↗,提供 19 个 GGUF 量化档,合计 498 GB。由 bartowski 发布。
量化者做了什么带重要性矩阵(imatrix:/models_out/gemma-4-31B-it-GGUF/google_gemma-4-31B-it-imatrix.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 534.6 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、lmstudio-community 3 档、ggml-org 3 档、AtomicChat 9 档 等)。 本仓 19 档,覆盖最全。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(20 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(20 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 全仓 498 GB,硬盘紧张的话建议只下需要的 1~2 个档位

lmstudio-community

apache-2.0 3 档 · 71 GB · 37k 下载
它是什么lmstudio-community/gemma-4-31B-it-GGUF ↗,提供 3 个 GGUF 量化档,合计 71 GB。由 lmstudio-community 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 76.5 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、bartowski 19 档、ggml-org 3 档、AtomicChat 9 档 等)。 本仓 3 档,覆盖最少。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(19 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

ggml-org

apache-2.0 3 档 · 109 GB · 29k 下载
它是什么ggml-org/gemma-4-31B-it-GGUF ↗,提供 3 个 GGUF 量化档,合计 109 GB。由 ggml-org 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 116.8 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、bartowski 19 档、lmstudio-community 3 档、AtomicChat 9 档 等)。 本仓 3 档,覆盖最少。
存在的意义补上官方没覆盖的档位(Q4_0 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_0(18 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_0(18 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

AtomicChat

apache-2.0 9 档 · 216 GB · 4k 下载
它是什么AtomicChat/gemma-4-31B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 216 GB。由 AtomicChat 发布。
量化者做了什么带重要性矩阵(imatrix:/root/work/gemma-4-31B-it/imatrix-coding.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 231.5 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、bartowski 19 档、lmstudio-community 3 档、ggml-org 3 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(19 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 全仓 216 GB,硬盘紧张的话建议只下需要的 1~2 个档位

giladgd

apache-2.0 9 档 · 275 GB · 3k 下载
它是什么giladgd/gemma-4-31B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 275 GB。由 giladgd 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 295.4 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、bartowski 19 档、lmstudio-community 3 档、ggml-org 3 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(19 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)
· 全仓 275 GB,硬盘紧张的话建议只下需要的 1~2 个档位

Mungert

apache-2.0 18 档 · 388 GB · 3k 下载
它是什么Mungert/gemma-4-31B-it-GGUF ↗,提供 18 个 GGUF 量化档,合计 388 GB。由 Mungert 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B;权重总字节 416.6 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、bartowski 19 档、lmstudio-community 3 档、ggml-org 3 档 等)。 本仓 18 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(19 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)
· 全仓 388 GB,硬盘紧张的话建议只下需要的 1~2 个档位

mradermacher

apache-2.0 7 档 · 197 GB · 1k 下载
它是什么mradermacher/gemma-4-31B-it-GGUF ↗,提供 7 个 GGUF 量化档,合计 197 GB。由 mradermacher 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 262,144 tokens;发布页声明溯源到 google/gemma-4-31B-it;权重总字节 211.9 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 7 个量化来源(unsloth 18 档、bartowski 19 档、lmstudio-community 3 档、ggml-org 3 档 等)。 本仓 7 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(19 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(19 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

E量化者档案 选量化者意味着什么

量化者决定了这个包的档位覆盖、命名规范、是否带 imatrix、什么时候跟进新模型。这一区块说明「选这个量化者的量化意味着什么」。

unsloth 量化覆盖面最广、下载量最高的第三方量化者

在本系列:1 个仓 · 343k 下载

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

擅长什么:几乎每个主流基础模型都第一时间跟 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

发布页 ↗

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

在本系列:1 个仓 · 39k 下载

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

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

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

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

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

发布页 ↗

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

在本系列:1 个仓 · 37k 下载

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

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

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

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

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

发布页 ↗

ggml-org llama.cpp 所属组织的官方量化发布

在本系列:1 个仓 · 29k 下载

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

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

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

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

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

发布页 ↗

AtomicChat

在本系列:1 个仓 · 4k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

giladgd

在本系列:1 个仓 · 3k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

Mungert

在本系列:1 个仓 · 3k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

mradermacher Mirostat 作者,长期做低比特实验性量化

在本系列:1 个仓 · 1k 下载

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

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

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

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

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

发布页 ↗

F更新记录 谁在跟进

按更新时间倒序。更新频繁说明该量化者在跟进新版本;长期不更新则基础模型升版后可能不同步。

  • 2026-07-27 bartowski 更新了 19 个档位 · 含 imatrix
  • 2026-07-26 ggml-org 更新了 3 个档位
  • 2026-07-24 AtomicChat 更新了 9 个档位 · 含 imatrix
  • 2026-07-20 lmstudio-community 更新了 3 个档位
  • 2026-07-17 unsloth 更新了 18 个档位 · 含 imatrix
  • 2026-06-28 giladgd 更新了 9 个档位
  • 2026-06-05 Mungert 更新了 18 个档位
  • 2026-04-18 mradermacher 更新了 7 个档位

基础模型 google/gemma-4-31B-it 最近更新:2026-07-20 · 本站采集时间:2026-09-30

成员 3Gemma 4 E4B(高效)

4B 级 · 小显存首选 · 10 个量化来源

A基础模型卡 这一档位是什么

官方发布页google/gemma-4-E4B-it ↗
许可apache-2.0 许可原文 ↗
规模4B 级
架构gemma4
上下文长度131,072 tokens
定位小显存首选
官方下载量4.4M 点赞 2k
最近更新2026-07-20

小规格,量化覆盖 34 家,是入门本地部署最省资源的一档。

B该选哪个 按你的显存倒推

按「你实际有多少显存能装」选档位,而不是按参数猜。下面每档的体积都是实测值(来自发布页文件列表),加权 15% 余量给运行时与 KV cache。

显存 → 档位速查(体积最小的可行档,质量最高的那一档)
8 GB 显存 Q5_0(5.7 GB · 保守档)
更省:Q5_1 6.8 GB / Q6_K 6.2 GB
消费级入门卡、共享显卡
12 GB 显存 Q8_0(8.0 GB · 近似无损)
更省:Q6_K 6.2 GB / UD-Q8_K_XL 8.7 GB
RTX 3060 12G / 4060Ti 16G 降配使用
16 GB 显存 Q8_0(8.0 GB · 近似无损)
更省:Q6_K 6.2 GB / UD-Q8_K_XL 8.7 GB
RTX 4060Ti 16G / 4070S 超配
24 GB 显存 Q8_0(8.0 GB · 近似无损)
更省:UD-Q8_K_XL 8.7 GB / BF16 15 GB
RTX 3090 / 4090
48 GB+ 显存 Q8_0(8.0 GB · 近似无损)
更省:UD-Q8_K_XL 8.7 GB / BF16 15 GB
A6000 / L40S / Mac 统一内存
展开:本系列所有档位的实测体积(24 档)
量化档体积每权重比特档位最小体积来源
UD-IQ2_M 3.5 GB 2.39 bpw 极限压缩 unsloth
IQ2_M 4.0 GB 2.39 bpw 极限压缩 bartowski
Q2_K 4.0 GB 2.80 bpw 极限压缩 Mungert
UD-IQ3_XXS 3.7 GB 3.06 bpw 长上下文优先 unsloth
IQ3_XXS 4.6 GB 3.06 bpw 长上下文优先 Mungert
UD-Q2_K_XL 3.8 GB 3.35 bpw 长上下文优先 unsloth
IQ3_XS 4.6 GB 3.36 bpw 长上下文优先 Mungert
Q3_K 3.9 GB 3.55 bpw 长上下文优先 unsloth
IQ3_M 4.7 GB 3.66 bpw 长上下文优先 AtomicChat
IQ4_NL 4.3 GB 4.05 bpw 平衡档 Mungert
IQ4_XS 4.7 GB 4.25 bpw 平衡档 unsloth
UD-Q3_K_XL 4.6 GB 4.42 bpw 平衡档 unsloth
Q4_0 4.6 GB 4.55 bpw 平衡档 ggml-org
Q4_1 5.0 GB 4.83 bpw 平衡档 Mungert
Q4_K 4.8 GB 4.85 bpw 平衡档 unsloth
Q5_0 5.7 GB 5.54 bpw 保守档 prithivMLmods
UD-Q4_K_XL 5.1 GB 5.62 bpw 保守档 unsloth
Q5_K 5.4 GB 5.69 bpw 保守档 unsloth
Q5_1 6.8 GB 5.69 bpw 保守档 Mungert
UD-Q6_K 7.5 GB 6.54 bpw 保守档 unsloth
Q6_K 6.2 GB 6.59 bpw 保守档 lmstudio-community
Q8_0 8.0 GB 8.50 bpw 近似无损 prithivMLmods
UD-Q8_K_XL 8.7 GB 8.72 bpw 近似无损 unsloth
BF16 15 GB 16.00 bpw 近似无损 ggml-org

「每权重比特」是按 llama.cpp 公开命名标准从文件名推导的,同一档位在不同模型上的真实值会略有差异。这是 B 级推导,不是实测值。

C量化版本总表 横向对比

量化者许可档数总体积 上下文建议档下载量更新
ggml-org
gemma4
apache-2.0 3 26 GB 131,072 Q4_0
4.6 GB
1.4M 2026-07-26
unsloth
gemma4
apache-2.0 17 114 GB 131,072 Q4_1
5.1 GB
618k 2026-07-17
lmstudio-community
gemma4
apache-2.0 3 18 GB 131,072 Q4_K
5.3 GB
470k 2026-07-20
bartowski
gemma4
apache-2.0 14 127 GB 131,072 Q4_K
6.3 GB
35k 2026-07-26
batiai
gemma4
other
须读原文
2 11 GB 131,072 Q4_K
5.3 GB
7k 2026-04-18
AtomicChat imatrix
gemma4
apache-2.0 9 62 GB 131,072 Q4_K
5.3 GB
4k 2026-07-24
Mungert
gemma4
apache-2.0 16 126 GB 131,072 Q4_K
6.2 GB
3k 2026-06-11
mradermacher
gemma4
apache-2.0 8 70 GB 131,072 Q4_K
5.3 GB
3k 2026-04-11
prithivMLmods
gemma4
apache-2.0 9 90 GB 131,072 Q4_K
5.3 GB
2k 2026-06-07
giladgd
gemma4
apache-2.0 9 76 GB 131,072 Q4_K
5.4 GB
2k 2026-06-28

「建议档」是本站按体积最小且落在平衡档的规则自动选出的,不是质量排名。官方量化排在最前;带 imatrix 标记的仓库带重要性矩阵数据。

D每个变体详解 七字段

每个变体按七个字段展开:它是什么 → 量化者做了什么 → 与同系列其他变体的区别 → 存在的意义 → 优势 → 为什么选它 → 已知取舍。最后一项是本站唯一会写主观判断的地方,且都标注了「我们的口径」。

ggml-org

apache-2.0 3 档 · 26 GB · 1.4M 下载
它是什么ggml-org/gemma-4-E4B-it-GGUF ↗,提供 3 个 GGUF 量化档,合计 26 GB。由 ggml-org 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 27.7 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(unsloth 17 档、lmstudio-community 3 档、bartowski 14 档、batiai 2 档 等)。 本仓 3 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_0 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 社区验证充分(1.4M 次下载),踩坑的人少
· 平衡档落在 Q4_0(4.6 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_0(4.6 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

unsloth

apache-2.0 17 档 · 114 GB · 618k 下载
它是什么unsloth/gemma-4-E4B-it-GGUF ↗,提供 17 个 GGUF 量化档,合计 114 GB。由 unsloth 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 122.0 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、lmstudio-community 3 档、bartowski 14 档、batiai 2 档 等)。 本仓 17 档,覆盖最全。
存在的意义补上官方没覆盖的档位(Q4_1 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_1(5.1 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_1(5.1 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

lmstudio-community

apache-2.0 3 档 · 18 GB · 470k 下载
它是什么lmstudio-community/gemma-4-E4B-it-GGUF ↗,提供 3 个 GGUF 量化档,合计 18 GB。由 lmstudio-community 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 19.6 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、bartowski 14 档、batiai 2 档 等)。 本仓 3 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(5.3 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(5.3 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

bartowski

apache-2.0 14 档 · 127 GB · 35k 下载
它是什么bartowski/google_gemma-4-E4B-it-GGUF ↗,提供 14 个 GGUF 量化档,合计 127 GB。由 bartowski 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 136.3 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、batiai 2 档 等)。 本仓 14 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(6.3 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(6.3 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

batiai

other 2 档 · 11 GB · 7k 下载
它是什么batiai/gemma-4-E4B-it-GGUF ↗,提供 2 个 GGUF 量化档,合计 11 GB。由 batiai 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 11.6 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、bartowski 14 档 等)。 本仓 2 档,覆盖最少。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(5.3 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(5.3 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 档位极少,没有升降空间,被显存卡住时无路可退
· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)
· 许可是 other,必须自己读发布页原文再决定能不能用

AtomicChat

apache-2.0 9 档 · 62 GB · 4k 下载
它是什么AtomicChat/gemma-4-E4B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 62 GB。由 AtomicChat 发布。
量化者做了什么带重要性矩阵(imatrix:/root/work/gemma-4-E4B-it/imatrix-coding.gguf),用激活数据统计各层重要性后再量化,通常比纯 RTN 稳;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 66.5 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、bartowski 14 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 带 imatrix,同档位下质量通常更稳
· 平衡档落在 Q4_K(5.3 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(5.3 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 暂未发现明显取舍(不代表没有,建议先下一档实测)

Mungert

apache-2.0 16 档 · 126 GB · 3k 下载
它是什么Mungert/gemma-4-E4B-it-GGUF ↗,提供 16 个 GGUF 量化档,合计 126 GB。由 Mungert 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B;权重总字节 135.3 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、bartowski 14 档 等)。 本仓 16 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(6.2 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(6.2 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

mradermacher

apache-2.0 8 档 · 70 GB · 3k 下载
它是什么mradermacher/gemma-4-E4B-it-GGUF ↗,提供 8 个 GGUF 量化档,合计 70 GB。由 mradermacher 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 75.3 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、bartowski 14 档 等)。 本仓 8 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(5.3 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(5.3 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

prithivMLmods

apache-2.0 9 档 · 90 GB · 2k 下载
它是什么prithivMLmods/gemma-4-E4B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 90 GB。由 prithivMLmods 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 96.1 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、bartowski 14 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(5.3 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(5.3 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

giladgd

apache-2.0 9 档 · 76 GB · 2k 下载
它是什么giladgd/gemma-4-E4B-it-GGUF ↗,提供 9 个 GGUF 量化档,合计 76 GB。由 giladgd 发布。
量化者做了什么未提供重要性矩阵(imatrix),走的是纯权重量化路线;针对 gemma4 架构优化;声明上下文 131,072 tokens;发布页声明溯源到 google/gemma-4-E4B-it;权重总字节 81.7 GB(发布页 gguf.total 字段)。
与同系列其他变体的区别同系列另有 9 个量化来源(ggml-org 3 档、unsloth 17 档、lmstudio-community 3 档、bartowski 14 档 等)。 本仓 9 档,覆盖中等。
存在的意义补上官方没覆盖的档位(Q4_K 这类),让你能在有限显存里凑合跑起来,或者反过来用更高精度换质量。
优势· 平衡档落在 Q4_K(5.4 GB),是大多数人的起点
为什么选它 / 目的如果你的瓶颈是显存:直接下 Q4_K(5.4 GB,平衡档)。
如果你的瓶颈是速度:这个仓里没有更快的档位(GGUF 的速度主要由架构与后端决定,不由量化档决定),换量化者意义不大。
如果你的瓶颈是质量:往上走一档到保守档(Q5_K_M / Q6_K)。
已知取舍· 无 imatrix,同档位下质量损失可能比带 imatrix 的版本更明显(我们的口径,需实测验证)

E量化者档案 选量化者意味着什么

量化者决定了这个包的档位覆盖、命名规范、是否带 imatrix、什么时候跟进新模型。这一区块说明「选这个量化者的量化意味着什么」。

ggml-org llama.cpp 所属组织的官方量化发布

在本系列:1 个仓 · 1.4M 下载

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

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

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

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

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

发布页 ↗

unsloth 量化覆盖面最广、下载量最高的第三方量化者

在本系列:1 个仓 · 618k 下载

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

擅长什么:几乎每个主流基础模型都第一时间跟 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

发布页 ↗

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

在本系列:1 个仓 · 470k 下载

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

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

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

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

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

发布页 ↗

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

在本系列:1 个仓 · 35k 下载

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

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

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

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

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

发布页 ↗

batiai

在本系列:1 个仓 · 7k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

AtomicChat

在本系列:1 个仓 · 4k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

Mungert

在本系列:1 个仓 · 3k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

mradermacher Mirostat 作者,长期做低比特实验性量化

在本系列:1 个仓 · 3k 下载

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

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

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

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

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

发布页 ↗

prithivMLmods

在本系列:1 个仓 · 2k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

giladgd

在本系列:1 个仓 · 2k 下载

代表:openbmb(面壁智能)、google、Qwen、unsloth 转发的 Qwen/Qwen3-30B-A3B-GGUF。

  • 为什么优先级最高:
  • 只有模型作者完全知道哪几层权重对质量最敏感
  • 官方量化档位数量通常很少(往往只有 Q4_K_M / Q8_0 两三档),因为官方只覆盖「安全」的选择
  • 出错时责任明确,不会因为第三方的错误 imatrix 导致质量异常

如果官方出了量化版,优先用它。 除非你需要官方没提供的极低比特档位。

  • 例外情况:
  • 官方可能只出 1~2 档,你实际需要 Q3 或 IQ4_XS 之类,还是得找第三方
  • 官方 GGUF 的更新频率依赖官方团队节奏,可能比第三方慢

核验方式:在本站系列页里,标有「官方」的条目会排在第三方之前。每条的许可都从 HF 发布页的 cardData.license 字段读取,以发布页原文为准。

发布页 ↗

F更新记录 谁在跟进

按更新时间倒序。更新频繁说明该量化者在跟进新版本;长期不更新则基础模型升版后可能不同步。

基础模型 google/gemma-4-E4B-it 最近更新:2026-07-20 · 本站采集时间:2026-09-30