2026 年 9 月 22 日，Hugging Face 在官方博客宣布，transformers 正式支持直接加载 GGUF 量化模型。用户只需在 from_pretrained 里传入 gguf_file 参数，就能把 Hub 上的 GGUF checkpoint 装进熟悉的 transformers API，在本地机器上跑起来。官方称，得益于复用 ggml 的底层内核，推理性能已接近 llama.cpp。
一行参数，GGUF 进了 transformers
用法比想象中简单：
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained(
"unsloth/Qwen3.5-4B-GGUF",
gguf_file="Qwen3.5-4B-Q4_K_M.gguf",
)之后就是标准 transformers 流程：tokenizer、generate、自定义 logits 处理器，全都照常用。同一份 checkpoint 还能通过 transformers serve 暴露为 OpenAI 兼容 API，接上 Jan、Pi 这类客户端就能当聊天后端。
性能是这次更新最有说服力的部分。Hugging Face 在 MacBook Pro M2 Max（32GB 统一内存）上实测了三类 checkpoint——小稠密模型、大稠密模型和 MoE 模型，transformers 的生成吞吐与 llama.cpp 的 llama-bench 成绩基本打平。秘诀是复用了 ggml 的 Metal 内核：量化矩阵运算、融合归一化、flash attention 等关键算子都直接调用 ggml 实现，Python 只负责调度。
这对谁有用：研究者，而非单纯追求速度的人
官方博客把目标用户说得很清楚，这一集成主要服务四类需求：在 Python/PyTorch 里实验 GGUF、用现有评测流程评估量化 checkpoint、验证 GGUF 转换是否正确、以及从 GGUF 反量化后继续微调。它解决的是「开发便利性」，而不是「更快」——博客里明确写道，llama.cpp 依然是高效本地推理的首选引擎。
边界也要看清：初期支持仅限 Apple Silicon，从 Qwen3.5 架构起步；需要安装 transformers 的 main 分支和 kernels 包；没有兼容量化内核时会回退到反量化加载，内存占用会明显上升。此前我们介绍过 llama.cpp 作为本地推理底座的定位（llama.cpp 适合谁？本地跑模型的轻量底座不是聊天产品 (/zh/article/1856-llama-cpp-shi-he-shui-ben-di-pao-mo-xing-de-qing-liang-di-zuo-bu-shi-liao-tian-c)），这次更新可以理解为：推理继续用 llama.cpp，做研究和原型时可以直接在 transformers 里折腾同一份 GGUF 文件，两套工具链不再来回倒腾权重。
对国内开发者还有一个现实意义：Qwen3.5 这类热门模型的 GGUF 发行版（Unsloth、bartowski 等）在 Hub 上下载量巨大，之前想在 PyTorch 生态里用它们得自己写加载逻辑，现在官方铺好了路。
