本地大模型跑不动时，先别急着换显卡：用 QuantProbe 把模型、量化与内存分层算清楚
本地运行大模型时，最常见的失败路径是先下载十几 GB 的 GGUF，再反复改 -ngl、上下文长度和量化等级。最后即使能启动，也未必知道瓶颈在显存、系统内存带宽、磁盘，还是模型的 MoE 专家层。更麻烦的是，同一个模型在不同机器上并不存在一个通用的“推荐量化”。
QuantProbe 是 Federico Sciuca 发布的 MIT 许可 Python 工具，目标不是替代 llama.cpp，而是在下载或启动之前，基于当前机器测得的硬件条件，为 GGUF 模型估算可行放置方式和生成用的 llama-server 命令。它当前在 PyPI 的版本为 1.21.0；HN 的发布帖将它描述为面向消费级硬件的本地推理规划工具。
这类工具最有价值的地方不在于报出一个看似精确的 tokens/s 数字，而在于把“这台机器能不能跑”“应该把哪些权重放哪里”“为了速度牺牲多少质量”拆成可以检查的决策。
先理解：模型装得下，不等于解码跑得快
推理时至少有三类资源会共同限制速度：
- 显存容量和带宽：放得进 GPU 的层通常更快，但不是所有权重都必须进显存。
- 系统内存与 CPU 带宽：混合放置或 CPU 路径会频繁读取内存；容量足够却带宽较低，解码仍会慢。
- 磁盘与权重布局：如果方案依赖流式读取，磁盘速度就会进入关键路径；这与首次下载模型的耗时是两回事。
对于 MoE 模型，参数总量也容易误导人。每个 token 只会激活部分专家，但注意力层、KV cache 和被放到不同设备的专家仍会影响实际吞吐。因此，“30B 模型”不能直接推出需要多少显存，更不能直接推出每秒 token 数。
QuantProbe 的 plan 会把候选分成全显存、混合放置、专家拆分、纯 CPU 或磁盘流式等路径。应把它看成比较候选方案的工具：它输出的预测来自工具自身模型和本机测量，不应当替代你对目标上下文长度、并发数和真实任务的压测。
从只读规划开始，而不是立即下载
工具可直接通过 PyPI 安装。若只是比较模型，不需要先让它下载权重：
pip install quantprobe quantprobe plan --model qwen3-30b quantprobe plan --gguf ./models/model.gguf
README 的示例输出会列出模型文件大小、候选放置方案、预测吞吐以及一条可直接交给 llama-server 的启动命令。这里要特别注意：输出中出现的 -ot 正则和 -ngl 等参数是为该候选方案生成的，不应盲目复制到另一模型或另一台机器。
先检查硬件视图也很有意义：
quantprobe hw quantprobe calibrate quantprobe plan --gguf ./models/model.gguf
calibrate 的作用是减少“硬件规格表等于实际性能”的假设。尤其是笔记本、共享内存设备和长时间负载会降频的 GPU，实际带宽与标称值可能差很多。校准并不会让模型变快；它只是让后续估算更接近这台机器。若不想使用已有锚点，README 还提供了 --no-anchors 回退到基础估算的选项。
让规划结果进入可复现的验证闭环
一个稳妥流程不是看到最高预测值就开始下载，而是按下面的顺序收敛：
- 用
plan比较两三个目标模型或量化，不下载全部候选。 - 选择能满足目标延迟和内存上限的一个候选，再下载对应 GGUF。
- 用实际文件执行
plan --gguf，核对模型元数据与最初按名称估算的假设是否一致。 - 用
run启动，或将生成的 llama.cpp 命令放入自己的服务脚本。 - 对真实提示词和目标上下文长度测量首 token 延迟、持续解码速度与内存峰值；不要只测短提示词。
已有文件时，run 可以在规划后启动聊天；需要明确吞吐目标时，optimize --tps 20 用于寻找达到目标速度的较低成本路径，target --tps 5 --ladder 则从目标速度反推合适模型。下面的命令不会修改模型权重，适合先做方案讨论：
quantprobe optimize --tps 20 quantprobe target --tps 5 --ladder quantprobe run --gguf ./models/model.gguf --dry
真正触及权重的功能有不同成本。fetch 会下载模型；quantize 会基于输入 GGUF 构建量化结果；probe 用评测数据测量模型在压缩下的脆弱区段。它们都应先评估磁盘空间与耗时。README 明确区分了快速路径和自定义量化路径：后者会测量并构建针对模型和硬件的量化版本，代价是更长运行时间和更多临时磁盘空间；不要把它当作一次普通的参数调优。
还有一个容易被忽略的工程点：规划命令与模型文件本身都应版本化。下载完成后，至少记录 GGUF 的来源、文件名、量化类型、quantprobe hw 的输出摘要、校准日期和实际启动命令。否则，几周后即使同名模型仍能启动，也难以判断性能变化是新驱动、不同量化文件、CPU 省电策略还是 llama.cpp 更新造成的。若团队需要比较多台机器，可以把相同提示词、相同上下文长度、首 token 延迟、稳定解码吞吐和峰值内存做成一张基准表；规划输出提供候选，统一测量条件才提供决策依据。
自定义量化尤其需要分开验证“能加载”和“可用”。前者只说明运行时没有报错；后者还要看代码补全是否保持语法、RAG 回答是否仍能引用上下文、工具调用 JSON 是否稳定。对业务关键模型，最好保留未量化或较高位宽版本作为对照，并在相同种子和相同测试集上比较。这样即使最终选择更小的文件，也能说清楚换来的究竟是磁盘节省、内存余量还是可接受的质量取舍。
还应把失败结果保留下来。某个量化在短对话中看起来足够快，却可能在长上下文、批量 embedding、JSON 严格输出或连续工具调用时突然失效；这不是“模型随机”，而是测试覆盖不足。将失败提示词、峰值内存、错误类型和复现命令一并记录，后续升级驱动或更换 GGUF 时就能快速区分回归与配置变化，也能避免团队成员重复踩同一条资源边界。
quantprobe probe --gguf ./models/f16.gguf --eval ./wiki.test.raw quantprobe quantize --gguf ./models/f16.gguf --out ./models/2bit.gguf
它能解决什么，不能替你决定什么
QuantProbe 很适合“本地 LLM 选型与落地前评估”：例如只有有限显存，但有足够系统内存；或者要在同一台开发机上比较不同 GGUF、不同量化与不同层放置方式。对运行 llama.cpp 的个人设备、边缘机器和内部开发环境尤其有帮助。
但有四个边界需要保留：
- 预测不是 SLA。 并发请求、上下文长度、采样参数、提示词结构、温度和后台负载都会让真实结果偏离规划值。
- 它不替代 llama.cpp。 QuantProbe 生成的是启动建议，实际运行时、模型兼容性、GPU 驱动和服务层仍需自行维护。
- 不要把生成阶段与预填充混为一谈。 长上下文的预填充和持续生成受资源限制的方式不同；只看 tokens/s 会漏掉首 token 延迟。
- 自定义量化需要验收质量。 即使工具试图保护模型的脆弱部分，仍应使用与你的代码、检索或问答场景相符的评测集比较输出，而不是只看压缩比例。
如果你的目标只是快速体验一个模型，quantprobe auto 可以执行检测、选择、下载和启动的交互式流程；但在生产或团队环境中，建议优先使用可记录的 plan、hw、calibrate 和实际压测数据，把最终 llama-server 命令、GGUF 校验值和测试条件写入部署记录。这样下次更换模型或硬件时，才有可比较的基线。
小结
本地推理调优不应从“换更大的卡”开始，而应从可测量的约束开始：模型权重在哪里、解码时从哪里读取、上下文和并发如何占用资源、质量下降是否可接受。QuantProbe 将这些因素收拢为可比较的规划与命令建议；真正可靠的部署仍要回到你的硬件、目标负载和端到端基准。
相关链接