到达时损坏：公共模型注册表中的无声缺陷 LLM 工件以及如何捕获它们

开发人员越来越多地通过从公共注册表中提取量化的 GGUF 工件来在本地运行 大语言模型，但分发管道中没有任何内容在到达用户之前对这些转换进行功能测试。我们执行了 327 个可量化的代码模型工件：其中 305 个来自官方 Ollama 库，涵盖 8 GB 或以下每个符合条件的量化级别的 15 个模型系列，以及 22 个来自 HuggingFace 上下载最多的社区存储库。每个人都运行一个包含 15 个任务的烟雾套件，经过校准，以便健康的工件能够通过，而已知损坏的工件会失败；然后，嫌疑人面临完整的 164 任务评估、第二个推理后端、独立分发者对相同模型的转换和量化作为裁判，以及对于社区文件，在工件自己的模板下重新测试。官方库包含五个默默存在缺陷的工件，一批四个 Qwen2.5-Coder-3B 转换和一个 phi3.5-mini 转换，它们解决了 164 个任务中的零个任务和两个后端的烟雾套件的零个，同时相同模型的独立转换工作：官方工件的 1.6%，29 个模型和尺寸转换组中的 2 个。裁决链清除了小模型工件，当它们仅因极端量化而崩溃时，幼稚的阈值就会谴责为损坏，并且它暴露了两个较旧的社区转换，它们在 CUDA 上严重退化，但在 Metal 上传递：不是有缺陷的文件，而是依赖于后端的故障，这是目前没有注册表测试的第三种现象。两个已确认的缺陷产生的输出的表面统计数据位于健康范围内，对于任何执行不足的低噪声启发式都是不可见的。我们发布了审计数据集、quantcheck 验收测试工具以及每个已确认缺陷的披露报告 (https://github.com/aditi-p31/quantcheck)，并认为模型注册表需要包注册表已经运行的验收门。