8、16 或 32 GB 内存跑 Humanizer 12B：该下载哪个 GGUF 文件

使用本地模型的人大多会遇到的选择

假设你有一台 16 GB 内存的笔记本，想试试本地改写模型。打开模型页面，你会发现下载项一共有六个，从 3.9 GB 到 23.8 GB，名字像 Q6_K 和 IQ2_XS-QAT。这只是个假设，却是几乎每个人初次接触量化模型时的处境。humanizer 的模型卡在这一点上比多数做得好，它给每个文件标出了体积、实测峰值内存、保真度得分和事实核查数量，并直说每个文件是给谁用的。本文逐列解读这张表。关于模型本身，以及它的醒目说法有多可信，请看 humanizer 的数字究竟说明了什么。

对照表

Top-1 一致率指文件预测的最可能的下一个词元与完整 bf16 模型一致的比例，取英文和中文的平均值。Flagged 指 420 篇英文改写中，被严格的 LLM 评审发现有事实问题的篇数。峰值内存是作者在 M5 Max 上用 llama-server 配合 Metal、采用应用的设置、在改写过程中测得的数值。所有数字均出自作者。

小文件为什么不只是压缩出来的副本

模型卡做了一个区分，解释了为什么表中靠中间和靠下的文件表现比你想的要好。它说大多数 GGUF 文件来自一次 llama-quantize 处理，把每个权重取整到目标类型。2 比特、Q3 和 Q4_K_M 这几个文件做得更多。对 2 比特和 Q3 文件，作者先测量了每个权重张量在被压缩时对模型的伤害有多大，给敏感的张量更多比特，给耐压的张量更少。然后三者都经过逐层训练来复现完整模型，也就是量化感知训练，并在英文和中文改写数据上，用完整的 bf16 模型做了蒸馏。Q6_K 和 Q8_0 是标准构建，因为模型卡说，在这两个体积上几乎没有什么损失可以找回。

据模型卡，效果是可以测量的。对于 2 比特文件，同样大小的标准构建有 70% 的时候与 bf16 选中同一个下一个词元；多做的几步依次把这个比例提高到 81%、85%，再到 87%。包括 KL 散度和各文件事实核查在内的细节，在模型卡链接的一份量化文档里，我们没有逐项核实。

最终得到的仍然是普通的 GGUF 文件，任何较新的 llama.cpp 都能运行。如果你不想依赖作者的应用，这一点很重要。模型卡还提到，这些文件有自己独立的仓库，所以原有的下载命令仍然可用。

按你的内存怎么选

模型卡自己的建议很具体，也与表中数据吻合。有 32 GB 或更多内存，选 Q8_0，卡里称它为推荐且质量最佳。16 GB 选 Q6_K，卡里说没有可测量的损失。大约 14 GB，或者磁盘紧张时，选 Q4_K_M，有轻微损失，并经过量化感知训练。12 GB 选 Q3-QAT，损失很小，英文里事实上的小失误稍多几处。8 GB 则选最小的文件 IQ2_XS-QAT。应用会替你做这个匹配：首次运行时，它按你的内存从五种体积里推荐一种，最低到 8 GB 的机器，下载一次之后就可离线工作。

清单旁边还有两点提醒。第一，内存那一列是在 Mac 上的测量值，且给系统留了余量；模型卡说应用会保持大约 4 GB 空闲。在带独立显卡的 Windows 或 Linux 机器上，关键是显存，唯一可靠的办法是自己测试。第二，有两行是估算而不是测量：Q6_K 和 bf16 的峰值内存。如果你选了 16 GB 的方案，你依赖的就是 Q6_K 那个约 11 GB 的估算值。

读质量列时别骗自己

被标记的数量并不是一条直线下降，模型卡也解释了原因。bf16 有 52 篇被标记，Q8_0 有 44 篇，模型卡称两者的差距在噪声范围内。Q8_0、Q6_K 和 Q4_K_M 与 bf16 都在噪声范围内；Q3 和 2 比特会多犯几处小错。老实的总结是：在事实方面，前三个文件很难分出高下，后两个则付出了从数量上看得见的代价，也就是 420 篇中的 64 到 70 篇。

检测器那一列有个转折，模型卡写得很谨慎。在另一项测量中，同样 60 篇英文草稿用 Originality.ai 最严格档检测，Q8_0 被判出 60 篇中的 7 篇，Q3-QAT 为 4 篇，2 比特文件为 0 篇，bf16 为 4 篇。最小的文件得分最好，模型卡把它标为检测器得分最低，同时事实上的小失误多几处。这提醒我们，检测器分数和事实保真度可能朝相反方向走，而模型卡自己也说，检测器会变，这只是某一天的一次测量。如果你的工作涉及数字和名字，应该看的是事实那一列。

文件体积也不是内存开销的全部。峰值内存那一列在每一行都高于文件体积，因为运行时除了权重，还需要给上下文和缓冲区留空间。模型卡建议上下文设为 8192 个词元，覆盖指令、草稿和改写三者，并说长文档要在段落处拆开。对任何本地模型，一个好习惯是把文件体积当作下限，而不是预算，并留出余量。

其他让它跑得更快的办法

除了应用，模型卡还记录了几条路径。推荐的是 llama.cpp，附有下载命令、服务器命令和一个简短的 Python 客户端。Apple 芯片上有 MLX 路径，会在本地把权重转换成 8 比特。对于 Ollama，模型卡警告说 Ollama 会忽略文件里保存的聊天模板，转而套用自己的模板，这会让这个模型无法正常工作，所以它提供了带有正确模板的 Modelfile。处理长文档的命令行流程，有一个配套工具会逐段改写文章，保留标题、代码、表格和链接，并对任何丢了数字的片段发出标记。

还有一个社区项目值得一提，同时附上模型卡自己的提醒：我们没有测过它的性能。一位贡献者为 humanizer 训练了一个推测解码的草稿模型，他报告在 M5 Pro 上用 MLX 速度约为 1.5 倍，每秒 34.5 个词元，对比 22.8；在他的测试里，输出与单独运行 humanizer 时逐个词元完全相同。它与主模型一起运行，需要它自己模型卡里描述的 MLX 环境。

我们的看法

在机器放得下、还有余量的前提下，选最大的那个文件。按作者自己的度量，从 Q8_0 降到 Q6_K，420 篇改写里多出 12 篇被标记；降到 Q4_K_M 多出 14 篇；降到 2 比特多出 26 篇。对涉及数字和名字的工作，该权衡的是这个差距，文件体积倒在其次。如果你的内存处于中间档，这张表里 16 GB 对应的 Q6_K 看起来是最合适的折中：保真度和事实核查都接近 bf16，体积还不到 bf16 的一半。

继续阅读

全部文章按时间倒序排列在 Front 博客首页。

• Humanizer 12B：它的说法有多可信: 关于 Humanizer 12B 本地模型的说法，哪些经得起来源的检验。
• Ling 3.1 Flash：运行它需要什么: 运行 Ling 3.1 Flash 所需的硬件。
• DeepSeek V4.1 Flash 1017 时间线: DeepSeek 的 V4.1 Flash 发布、10 月 17 日的更新、价格和参数量。
• Meta Muse Spark Open 时间线: Meta Muse Spark Open 发布的带日期时间线。
• Reflection Beam 501B 时间线: Reflection Beam 501B 权重发布的带日期时间线。

常见问题

来源

• jialinyyzz/humanizer model card
• jialinyyzz/humanizer-GGUF