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

一、核心论点/事实

  • 核心目标：在下载任何模型前，1 秒内回答"这个模型能否在我的机器上跑、速度多快"，并生成专属于该硬件的优化配置文件。
  • 实测校准：所有预测基于实测硬件常数（如 RAM 24.3 GB/s、disk 3.13 GB/s），而非规格表；支持 2016 年 16GB RAM 的 PC 运行 110B 模型。
  • 速度预测精度：13/13 基准测试中真实速度 ≥0.90× 预测值，通常为 1.1–1.8× 更高；留一法交叉验证中位数误差 <5%（5 臂），全阶梯约 12% 中位数误差，且误差偏向保守（低估）。
  • 质量保障：推荐配置通过 ≥80% 机器检查任务的预设门槛；2.5-bit 30B 模型在 16k 上下文下 5/5 任务通过（85% 诚实下限，含 5 个失败计数）。
  • 失败公开原则：所有预测在测量前预注册（prereg #64），失败与成功以同等篇幅公开（如速度预测 +6.6% 而非 ±3% 的失败预测）。
  • 架构无关性：模型损坏带（break band）位置无法由架构族或权重统计预测——Qwen2.5-7B、Qwen3-30B、Qwen3-35B 均在不同位置断裂，必须逐层探测。

二、方法/架构拆解

  • 探测机制（The Probe）：以"一列穿过内存层级（VRAM→RAM→disk）"的方式逐层探测模型，定位压缩下实际断裂的层，保护该层并压缩其余部分。
  • 三层内存放置（Placement）：自动检测硬件（如 VRAM 6GB@192、RAM 16GB@48、disk 0.5 GB/s），生成三种放置方案并定价：
  • 专家拆分（experts 34%→VRAM，其余→RAM）：22.2 tok/s，钉住 7GB RAM
  • 混合（attention→VRAM，experts→RAM）：19.0 tok/s，钉住 10GB RAM
  • 纯 CPU（GPU 空闲）：13.2 tok/s，预期双峰速度
  • 瓶颈识别：自动判定"带宽受限"（系统 RAM 带宽），并量化每 token 中 51% 解码时间消耗在 RAM 带宽上。
  • 命令生成：输出精确的 llama.cpp 命令（如 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 全自动执行。
  • 自校准流程：一次校准 + 两次基准运行（基于用户自己的 GGUF）缩放所有预测；锚定运行（anchor runs）确定 CPU/GPU 层级比率（如 CPU ×1.18、GPU ×0.75）。
  • 质量评估：使用 llama.cpp 自身的 full-distribution KL 散度（因测量到 perplexity 移动 23% 时模型在 27% 位置改变 token 选择）；深度感知配方（depth-aware recipe）估计质量成本（如 ×1.07）。
  • 任务套件（Task Suite）：JSON 提取（精确值）、算术（到分）、单标签分类、可执行代码（通过断言）、摘要（确定性幻觉检查——源中不存在的数字即失败）；0.6B 模型触发套件自身 kill rule（57.9% < 60%），仪器正确拒绝判定为业务可用。
  • Ollama 集成：读取 Ollama 实际选择的放置方案，与规划器定价对比，VRAM 争用时拒绝比较（测量纪律）。

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

作者承认的局限：

  • 速度预测存在失败案例：预测解码速度不变（±3%），实际 +6.6% 更快——"好结果但失败的预测"，已按同等篇幅公开。
  • 5 个任务在 4k 上下文窗口内因推理中途耗尽而失败；16k 下全部通过（其中一个需要 7,417 token 的思考）。
  • 全阶梯预测中位数误差约 12%，且误差偏向低估（保守方向）。
  • 推理模型（reasoning models）在回答前消耗大量思考预算，可能影响短上下文场景的实用性。

AI 判断的局限：

  • 依赖用户机器上的校准运行（anchor runs），首次使用需额外时间成本；无锚定模式（--no-anchors）可能降低精度。
  • 2.5-bit 量化即使"保护关键层"，长期可靠性（如数值稳定性、多轮对话累积误差）未充分验证。
  • 任务套件覆盖范围有限（5 类任务），"业务可用"判定可能不适用于所有下游场景。
  • 对 CUDA host memory 的钉住（pinning）可能影响同一机器上其他应用的性能，未讨论多租户场景。

四、与 RRLab 研究的关联

  • Harness 工程：quantprobe 的"预注册预测 + 失败公开"方法论可直接借鉴——RRLab 的评测 harness 可引入预注册基准（pre-registered benchmarks），确保每个数字在测量前有明确假设，失败与成功同等报告。
  • 模型评测：其"深度感知配方"（逐层探测断裂带）提示 RRLab 评测不应仅看整体指标，需关注模型内部层级的脆弱性分布；KL 散度 vs perplexity 的对比（perplexity 移动 23% 但 token 选择改变 27%）说明评测指标需多维交叉验证。
  • 多模型协同：quantprobe 的"任务套件 + kill rule"（0.6B 模型 57.9% < 60% 被拒绝）为 RRLab 的多模型路由/选择提供参考——小模型应有明确的"不可用阈值"，而非无条件降级。
  • Agent 落地：其"确定性幻觉检查"（源中不存在的数字即失败）可直接用于 RRLab 的 Agent 工具调用验证；"推理模型思考预算"的发现（7,417 token 思考）提示 Agent 设计需考虑上下文窗口分配策略。
  • AI 原生产品：quantprobe 的"1 秒回答 + 自动执行"交互模式（quantprobe auto）是 AI 原生工具的优秀范式——用户只需表达意图，工具自动完成检测、规划、下载、启动全流程，RRLab 产品可借鉴此"零配置"体验。

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