Hugging Face 宣布在 transformers 中支持高效运行 GGUF 模型，让原本为 llama.cpp 生态准备的量化检查点可以直接通过熟悉的 transformers API 在本地设备上加载和生成。GGUF 是 llama.cpp 团队开发的本地推理格式，把模型权重、tokenizer 信息和可选的聊天模板打包进单个文件，并通过不同量化等级在精度和内存占用之间做取舍。Hugging Face Hub 上已有大量现成 GGUF 检查点，例如 Unsloth、LM Studio Community、bartowski 等发布方提供了多种量化版本，下载量已达数百万次。

这次集成的核心是复用 ggml 的底层 kernel 来逼近 llama.cpp 的性能。transformers 通过 kernels 库分发兼容构建的 ggml Metal kernel，并在 generate 中减少同步开销。初始重点支持 Apple Silicon 上的本地推理，覆盖 Qwen3.5 架构。加载方式很简单：从 Hub 取模型 ID 和文件名，通过 from_pretrained 传入 gguf_file 参数即可，后续全部走标准 transformers API。权重保持打包状态驻留在 Metal 上时，系统会自动加载兼容的 ggml/Metal 层 kernel，并使用 ggml-org/ggml-attn 作为注意力实现；如果 kernel 获取失败则回退到 sdpa 并给出警告。

量化等级的选择直接影响文件大小和精度。以 Unsloth 的 Qwen3.5-4B 为例：BF16 原始版 8.42 GB，Q6_K 为 3.53 GB，Q5_K_M 为 3.14 GB，Q4_K_M 为 2.74 GB。官方建议从 Q4_K_M 起步，内存充裕再尝试 Q5_K_M 或 Q6_K。更激进的量化能让更大模型塞进有限内存，但质量损失取决于具体模型和任务，需要在实际工作上评估。

性能方面，官方在 MacBook Pro M2 Max（32 GB 统一内存，macOS 26.6，PyTorch 2.12.1，kernels 0.17.0）上对比了 transformers 与 llama.cpp 的 token 生成速率，覆盖小稠密模型、大稠密模型和 MoE 模型三个检查点。llama.cpp 侧用 llama-bench 测 decode-only 吞吐，transformers 侧测包含 prefill 的 128 token 生成。结果显示 transformers 在三个检查点上均接近 llama.cpp。需要说明的是两者并非完全相同的基准条件：transformers 的测量包含 prefill，而 llama-bench 报告的是纯解码吞吐。

除了直接加载，transformers serve 也支持同一检查点，暴露 OpenAI 兼容 API，可连接 Jan、Pi 等客户端。模型参数格式为 :.gguf，冒号前是 Hub 仓库，冒号后是具体量化文件。支持思考模板的模型可通过 –reasoning on/off/auto 控制推理过程。

这次集成还带来几个实际用途：在 Python/PyTorch 中实验 GGUF 模型、用 hooks 检查中间激活、修改 forward 或原型化自定义层；用现有 transformers 评估流程衡量量化检查点质量；验证 GGUF 转换是否正确；用自定义 logits processor 和 stopping criteria 尝试新的解码思路；以及通过 GgufConfig(dequantize=True) 反量化权重后继续微调。

更大的机会在于把 ggml kernel 的性能带给 llama.cpp 尚未支持的模型。kernel 只作用于张量，不要求整个模型来自 GGUF 文件，因此同一批构建模块可以集成进其他 transformers 模型和加载流程，未来也可能扩展到视觉、音频和多模态模型。不过每个架构仍需要单独集成和验证，目前的 GGUF 示例只覆盖文本生成。

性能提升的另一部分来自 generate 本身的改动，且对所有 transformers 模型有效，不限于 GGUF。一是当支持的 decoder-only 输入无 padding 时，提前移除全 1 的 attention mask，避免下游注意力代码反复检查；二是延迟 stopping check，把停止决策异步复制并在下一步消费，让 CPU 在 GPU 运行期间继续调度工作。kernel 降低单次操作成本，减少同步点则让 CPU 调度和 GPU 执行重叠。

当前限制也很明确：打包推理路径仅支持 MPS；padding 和 batching 仍需完善，带 padding 的批次无法走 mask 优化捷径，性能可能更低；架构覆盖目前限于 Qwen3.5 稠密和 MoE 架构（含兼容的 Qwen3.8 检查点）。官方表示会逐步扩展覆盖，并欢迎用户提交想用的 GGUF 模型和用例来帮助排定优先级。