来源：GitHub (★86)
URL: https://github.com/FedericoTs/quantprobe
精读日期：2026-08-19
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • QuantProbe 的核心主张：在下载任何模型之前，用 1 秒预测模型在你确切硬件上的速度（tok/s）和内存适配性，并自动生成精确的 llama.cpp 运行命令。
  • 定位是"放置（placement）胜过预算（budget）"：不推荐别人构建的量化方案，而是测量你的模型，构建一个只为你硬件存在的文件——探测每层在何处崩溃，保护该层并压缩其余部分，将结果跨 VRAM/RAM/磁盘放置。
  • 所有预测先注册后测量（pre-registered），失败案例与成功案例以同等篇幅公开；在 13/13 个基准上实测速度 ≥0.90× 预测值，通常为 1.1–1.8× 更高。
  • 能回溯预测从未训练过的第三方结果：airllm 的 30× 速度差异、DGX Spark 报告、1.56 TB Kimi 配置。
  • 自校准：无需硬件规格标志，自动检测机器（示例：vram 6GB@192 | ram 16GB@48 | disk 0.5 GB/s），并通过校准锚点运行（CPU x1.18, GPU x0.75）修正预测。
  • 示例输出：Qwen3-30B-A3B @ 2.5-bit 在 16GB RAM 机器上，专家拆分方案 22.2 tok/s，混合方案 19.0 tok/s，纯 CPU 13.2 tok/s；绑定约束为带宽受限（系统 RAM 带宽占每个解码 token 的 51%）。
  • 质量验证：推荐的 2.5-bit 30B 模型在机器可检查任务上达到 ≥85% 通过率（诚实下限，含 5 个失败计数），高于预设的 80% 门槛；5 个任务在 4k 上下文窗口内推理中途耗尽，16k 时全部通过（一个需要 7,417 token 的思考）。

二、方法/架构拆解

  • 核心机制：通过模型每一层的"探测"（probe）确定压缩崩溃点，保护关键层（敏感带），压缩其余层，然后跨 VRAM/RAM/磁盘分层放置。
  • 自校准流程：一次校准 + 两次在自有 GGUF 上的基准运行，即可缩放所有预测；校准使用实测常量（如 RAM 24.3 GB/s、磁盘 3.13 GB/s），而非规格表。
  • 预注册验证协议：预注册 #64 通过门槛——留一法（leave-one-out）中位误差 <5%（跨 5 个臂），全阶梯约 12% 中位误差，失败偏向低估。
  • 速度预测模型：基于"定律"（law）推导，非方差归因确认；预注册 #95 标记为"derived from the law, not confirmed by variance attribution"——放置杠杆在 1000/1000 次中决定方差。
  • 质量评估：使用 llama.cpp 自身的 full-distribution KL 散度；因测量到困惑度移动 23% 而模型在 27% 位置改变所选 token，故采用全分布而非单点指标。
  • 命令行输出：生成精确的 llama-server 命令，如 llama-server -m model.gguf -ngl 99 -ot "blk\.(16|17|…|47)\.ffn_.*_exps\.=CPU" --no-mmap -b 1024 -ub 1024 --threads 4。
  • quantprobe auto 模式：自动检测机器、询问模型、选择最佳量化、下载并启动，无需学习任何标志。
  • 任务基准：JSON 提取（精确值）、算术（到分）、单标签分类、可执行代码（通过断言）、摘要（源中不存在的数字触发确定性幻觉检查）。
  • 架构族不可预测性发现：Qwen2.5-7B、Qwen3-30B 和 Qwen3.5-35B 在中位带崩溃，而某些模型在特定层崩溃；架构族无法预测崩溃点，权重统计指向错误方向。

三、值得注意的局限/争议

作者承认的局限：

  • 速度预测标记为"derived from the law, not confirmed by variance attribution"——时间分解本身是未触及的算术，标签精确标价了未测量的部分。
  • 一个失败预测被公开：预测解码速度不变（±3%），实际 +6.6% 更快——"好的结果，失败的预测"，以与成功同等篇幅发布。
  • 诚实下限：若将 5 个在 4k 上下文失败的任务计为失败，通过率为 85%（仍高于 80% 门槛）。
  • 某些分类标签明确标注"derived from the law"，直到重新推导获得确认。

AI 判断的局限/争议：

  • 校准依赖用户机器上的两次基准运行，若用户跳过校准，预测精度可能显著下降（未说明降级幅度）。
  • 速度预测的"定律"本质是经验拟合，对未见过的新架构（如未来 GPU 内存层级变化）可能失效。
  • 质量门槛（80%/60%）是作者自定义标准，非行业共识；"business-useful"的定义模糊。
  • 对磁盘流式（disk-stream）放置的预测误差可能更大（全阶梯 12% 中位误差，未细分各放置类型）。
  • 项目处于早期阶段（★86），验证范围有限——13/13 基准的硬件多样性未明确。

四、与 RRLab 研究的关联

  • Harness 工程：QuantProbe 的"探测-保护-压缩-放置"流水线是典型的 harness 思维——不是选模型，而是为硬件定制模型文件。RRLab 可借鉴其"先注册后测量"的验证纪律，以及失败与成功同等公开的透明度原则。
  • 多模型协同：其"架构族不预测崩溃点"的发现提示：多模型协同调度时，不能按架构族做统一压缩策略，需逐层探测。RRLab 的多模型编排可引入"每层敏感度"作为调度元数据。
  • 模型评测：KL 散度全分布测量（而非单点困惑度）的实践值得借鉴——RRLab 评测体系可增加"token 级变化率"指标；其"机器可检查任务"基准（JSON 提取、算术、可执行代码、确定性幻觉检查）是高质量的功能评测模板。
  • Agent 落地：QuantProbe 的"带宽受限"诊断（51% decode token 花在 RAM 带宽）对 Agent 实时性至关重要——RRLab 的 Agent 部署可先做带宽预算分析，避免在带宽瓶颈机器上部署高延迟模型。
  • AI 原生产品：quantprobe auto 的"零标志"体验是 AI 原生工具的优秀范式——自动检测、自动决策、自动执行。RRLab 的工具链可借鉴这种"说你想做什么，而不是怎么做"的交互模式。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/FedericoTs/quantprobe