在 Transformers 里运行 GGUF：比较本地模型前，先检查运行路径

一项近期集成，也有明确边界

Marc Sun、Arthur Zucker 和 Lysandre 在 Hugging Face 的 2026-09-22 文章 ↗中，介绍在 Transformers 里以打包格式推理 GGUF 模型。最初的快速路径面向 Apple Silicon/MPS，以及受支持的 Qwen3.5、Qwen3.8 架构。这个范围比“文件能够加载”更重要。

我们提出的学习练习，是制作一份可复现的实验计划；并非建议替换已经好用的运行工具。下文的比较尚未执行。

下载前先分清三个问题

第一，选择哪个模型、哪个具体修订？一个仓库名称可能对应多个检查点。请记下发布者、修订版本和准确文件名。第二，文件里装了什么？Hub 的 GGUF 文档 ↗介绍格式与元数据查看器。用查看器检查文件，不要把扩展名当成质量评分。这里引用的是 2026-10-11 核查的动态文档，不是带固定发布日期的发布文章。

第三，你的设备实际会采用哪条运行路径？这与加载器是否理解文件格式是两件事。成功加载，本身不能证明使用了预期的打包内核。先检查运行消息，记录设备和依赖，再把某个内存或速度结果归因于量化。

这样拆分，也能让排错更具体。模型启动不了时，可以逐一判断是检查点、加载器还是设备路径不兼容，而不是同时更换多个组件。

做一个小而贴近自己的任务集

选六个自己能评分的短任务：两篇自写文本的摘要、两份虚构记录的结构化提取，以及两道你已经理解的小算法解释题。给提取字段准备标准答案，为解释题写一份简短评分标准。第一次练习不要使用敏感文件。

对每个任务保持提示词、聊天模板、输出上限和采样设置一致。既改变检查点精度又修改提示词，就很难判断答案为什么变好。以后比较两种量化时，尽量只更换文件，并在工具允许的范围内对齐其他条件。

记录完整的使用体验

分别记录启动耗时、首个输出耗时、生成耗时、峰值内存、输出格式是否有效，以及质量判断。保留第一次冷启动与重复热启动结果，不要悄悄挑出最快的一次。还应记录是否运行了其他高负载应用，以及设备是否插电。

结构化提取中，文字再流畅，只要破坏必需字段，就算输出失败；摘要中，回答再快，只要添加原文没有的事实，也算失败。这样的检查让时间数字有了实际意义。

不要把口径不同的测量放进一张速度榜。计入提示词处理的结果，与只测生成令牌的结果，回答的是不同问题。每个数字旁边都应写明计时边界。

用可检查的决定结束练习

建议产出六行任务记录、环境说明和原始输出，再写明哪个任务需要进一步调查，才能放心日常使用。小型检查点如果达到自己的评分标准，可以很有价值；仅仅能装进内存，证明的是另一件事。始终把实验计划与以后取得的实测结果分开记录。