2026 年 9 月 22 日，Hugging Face 在官方博客宣布，transformers 开始支持直接运行 GGUF 量化模型。用户可以从 Hub 上挑选一个 GGUF 检查点，通过 from_pretrained 传入 gguf_file 参数直接加载，在自己的机器上生成文本，全程沿用熟悉的 transformers API。
这件事的意义在于打通了两套生态。GGUF 是 llama.cpp 团队主导的量化格式，Unsloth、LM Studio Community、bartowski 等发布的现成 GGUF 检查点在 Hub 上累计被下载数百万次，是本地推理事实上的标准格式。过去要在 transformers 里用这些权重，得先反量化再加载，性能和便利性都打折扣。这次更新把 ggml 的底层内核直接复用进来，让 transformers 也能高效地跑 GGUF。
过去加载 GGUF 有多绕
在此之前，transformers 对 GGUF 的支持停留在“能导、不好用”的阶段：加载时先把量化权重反量化成全精度再跑，内存占用大、速度也上不去。想在 Mac 上高效跑量化模型，llama.cpp、Ollama、LM Studio 才是正解，transformers 更多是训练和评测的工具。这次更新的目标很直白：让同一套 GGUF 检查点在 transformers 里跑出接近 llama.cpp 的速度。
现在的用法
前提是 Apple Silicon Mac、较新的 PyTorch，以及从 git 主分支安装的最新 transformers 和配套的 kernels 库。加载只需要两行：
tokenizer = AutoTokenizer.from_pretrained(model_id, gguf_file=filename)
model = AutoModelForCausalLM.from_pretrained(model_id, gguf_file=filename)
除此之外的所有步骤——分词、generate、流式输出——都和原来一模一样。官方还提供了 transformers serve 命令，一行就能把 GGUF 模型包装成 OpenAI 兼容的本地 API，Jan、Pi 这类客户端可以直接连上来用。
实测：确实接近 llama.cpp，但要看清口径
Hugging Face 在 MacBook Pro M2 Max（32GB 统一内存）上做了对比：llama.cpp 一侧用 llama-bench 测 128 个 token 的解码吞吐，transformers 一侧用 generate 生成同样的 128 个 token。在小 dense 模型、大 dense 模型、MoE 模型三个检查点上，transformers 的吞吐都逼近了 llama.cpp。
但口径差异要说明白：llama.cpp 的数字是纯解码吞吐（不含 prompt 处理），transformers 的数字包含了 prefill。严格来说不是同一把尺子量的，官方自己也承认“不意味着测试条件完全相同”。结论可以信大方向——差距已经很小，但别把“接近”理解成“打平”或“反超”。
做到这一点的关键有两处。一是复用 ggml 的 Metal 内核（通过 kernels 库分发），量化权重不再展开，直接以压缩形态做矩阵运算；二是对 generate 循环做了优化，去掉不必要的注意力掩码检查、异步处理停止条件，让 CPU 调度和 GPU 执行更好地重叠。后者对所有 transformers 模型都有收益，不只限于 GGUF。
边界：这些场景还覆盖不到
官方把限制写得很清楚。第一，高性能的打包推理路径目前只支持 Apple Silicon 的 MPS，其他设备只能走反量化加载的老路，内存占用更大、速度更慢。第二，填充和批处理还没优化好，带 padding 的 batch 性能会打折扣。第三，架构覆盖有限，首批只支持 Qwen3.5 的 dense 和 MoE 架构，以及兼容的 Qwen3.8 检查点，其他架构要逐步扩展。
换句话说，这次更新瞄准的是“在一台 Mac 上做单人交互式对话”的场景。生产级的批量推理、多架构支持，还在路上。
对本地部署用户意味着什么
最大的变化是工作流统一了：同一套 GGUF 检查点，既可以在 transformers 里做实验、看中间激活、改前向传播、跑评测，也可以直接 serve 起来给客户端用。量化转换的验证也更方便——原始权重和 GGUF 转换版可以在同一个框架里对比，排查量化误差。官方还提到，ggml 内核这条路未来可以延伸到 llama.cpp 不支持的新架构，乃至视觉、音频模型。
但也别急着把 llama.cpp 换掉。Hugging Face 自己在博客里写明了：llama.cpp 依然是“优先保证高效本地推理”时的推荐引擎，它的专用运行时、内存管理和硬件覆盖广度，仍然是 transformers 短期内追不上的。要的是稳、快、省心，llama.cpp 阵营的工具依然是首选；要在 Python 里折腾模型本身，transformers 现在终于跟上了。
常见问题
Q：我现在的 llama.cpp / Ollama 工作流需要换吗？
A：不需要。这次更新解决的是“在 transformers 里也能高效跑 GGUF”的问题，不是替代 llama.cpp。日常对话、稳定 serving 继续用原来的工具；在 Python 里做实验、评测、微调时，新功能会更顺手。
Q：Windows 或 Linux 机器能用吗？
A：GGUF 文件格式的加载支持是跨平台的，但高性能的打包推理路径目前只支持 Apple Silicon 的 MPS。在其他设备上会回退到反量化加载，内存占用更大、速度更慢。
Q：支持哪些模型架构？
A：首批覆盖 Qwen3.5 的 dense 和 MoE 架构，以及兼容的 Qwen3.8 检查点。官方表示扩展到其他架构“相对直接”，会逐步增加；想用的模型不在列表里，可以去 GitHub 提 issue 帮助排优先级。
