深度解析 LLM Checker 四维评分系统：Q/S/F/C 如何为你精准推荐本地大模型

深度解析 LLM Checker 四维评分系统：Q/S/F/C 如何为你精准推荐本地大模型

【免费下载链接】llm-checkerAdvanced CLI tool that scans your hardware and tells you exactly which LLM or sLLM models you can run locally, with full Ollama integration.项目地址: https://gitcode.com/gh_mirrors/ll/llm-checker

LLM Checker 是一款先进的命令行（CLI）工具，它会扫描你的电脑硬件（CPU、GPU、内存），通过质量（Q）、速度（S）、适配（F）、上下文（C）四维评分系统，精准告诉你哪些本地大模型（LLM/sLLM）能在你的机器上流畅运行，并与 Ollama 深度集成。本文将带你深入拆解这套评分系统的运作机制，帮你彻底搞懂"为什么它给我推荐了这个模型"。

一、为什么推荐本地大模型需要"四维评分"

想在一台笔记本或家用 PC 上跑大模型，最怕两件事：模型装不下（显存/内存不够）和跑得飞快慢（每秒几个 token，等待焦虑）。而"大参数一定更好"的直觉也常常失灵——你的 8GB 显卡跑 70B 模型会爆显存，跑 0.5B 小模型又体验太差。

LLM Checker 的解法是把"这台机器适合跑哪个模型"拆成 4 个可量化维度，每个模型都会得到 4 个 0-100 的子分数：

最后，四个分数按"使用场景"加权求和，再加上一个"高容量修正分"（H），得到 0-100 的总分，排名靠前的就是最推荐给你的模型。核心打分逻辑位于 deterministic-selector.js，权重配置统一收敛在 scoring-config.js。

二、逐个拆解：Q/S/F/C 各自怎么打分

2.1 Q（质量）：先查"实测成绩"，查不到再按体量估算

质量分是最"聪明"的一维，它有两条路径（deterministic-selector.js）：

• 📊有实测基准成绩：系统会从本地评分库（如 BigCodeBench、HumanEval、LiveBench、MMLU-Pro、MMMU 等）中查该模型的测试分数，并按同类模型中的百分位换算到统一区间。这意味着不同榜单（难度差异巨大）的成绩可以公平比较。
• 🔮没有实测数据：退化为"参数量级基础分"（0.5B-1B 约 45 分，7B 约 75 分，13B 约 82 分，30B 约 89 分，70B 约 95 分），再叠加几笔修正：
  • 家族加成：deepseek-r1 +5、qwen3 +4、deepseek +3 等；
  • 量化惩罚：Q8_0 不扣分，Q4_K_M 扣 5 分，Q2_K 扣 12 分（压缩越狠质量损失越大）；
  • 新鲜度与热度：已弃用模型扣 12 分，Ollama 拉取量破亿加 4 分；
  • 任务匹配：写代码场景选 coder 模型加 6 分，但选非 instruct 模型写代码会扣 15 分。

2.2 S（速度）：一套"算力常数 ÷ 参数量"的估算模型

速度分基于你机器的实际硬件推算预估 token 吞吐（deterministic-selector.js）：

• 不同后端有各自的算力常数 K：NVIDIA CUDA = 220，Apple Metal = 160，CPU ARM = 90，CPU x86 = 70；
• 基础速度 ≈ K ÷ 有效参数量，量化越低速度越快（Q8_0 慢至 0.8 倍，Q2_K 快至 1.35 倍），8 核以上 CPU 和独显还能再乘加成；
• 最后与"场景目标速度"对比换算成分数：通用/编程场景目标 40 token/s，推理场景放宽到 25，Embeddings 高达 200。

💡 所以同一个 8B 模型，在独显工作站上 S 分可能接近满分，在纯 CPU 笔记本上则明显偏低——速度分永远是"你的硬件"专属的。

2.3 F（适配）：内存装得下，才有资格谈其他

适配分判断模型内存需求占可用内存预算的比例（deterministic-selector.js）：

• 需求 ≤ 预算的 90%：满分 100，留有余量，运行稳定；
• 需求在 90%~100% 之间：70 分，能跑但偏紧；
• 超出预算：直接淘汰，不进入评分。

2.4 C（上下文）：长文档党最该关注的一维

上下文分对比模型最大上下文（ctxMax）与场景目标（通用 4096，编程/推理 8192 等）：满足目标满分 100，只有目标一半给 70 分，更低则为 0。注意它不会直接淘汰模型，而是通过权重"压低"排名——即使上下文不足，模型仍可能因其他维度优秀上榜。

三、权重怎么配：不同场景，不同侧重

四个子分并不是平均相加，权重随你的使用场景变化（完整配置见 scoring-config.js）：

此外还有面向特殊需求的一键预设（scoring-config.js）：fast模式把速度权重拉到 55%，quality模式把质量拉到 65%。

隐藏第五分：H（高容量修正）

对于显存 ≥ 32GB 的大内存机器，系统还会追加"高容量修正"：如果你 128GB 显存却只配一个 7B 小模型，属于"大材小用"，会被最高扣 24 分，引导你选择 30B 起步、70B 甜点区间的模型（deterministic-selector.js）。

统一评分核心：三条命令，同一把尺子

历史上check、recommend、smart-recommend三条命令各用一套引擎，可能对同一个模型给出不同结论。现在统一评分核心 scoring-core.js 让所有命令共用同一个rankModels()入口——相同输入，必然相同分数，消除了"两条命令推荐打架"的问题。

四、一次推荐的完整旅程

以check命令为例，评分流水线是：

1. 硬件扫描→ 得出内存预算与后端（CUDA/Metal/CPU）；
2. 对模型池中每个模型挑选最合适的量化版本（装不下更高质量的自动降档）；
3. 计算内存需求，装不下的直接出局；
4. 分别算出 Q、S、F、C 四个子分；
5. 按场景权重加权，叠加 H 修正，得到 0-100 总分并排序；
6. 输出时还会附上"推荐理由"（rationale），解释为什么是这个模型、这个量化版本。

五、快速上手：3 步验证你自己的硬件

🚀 克隆仓库即可开始体验：

git clone https://gitcode.com/gh_mirrors/ll/llm-checker cd llm-checker npm install

随后运行检查命令即可看到带四维分数的推荐列表。各命令的详细参数与输出解读，可参考官方文档 usage-guide.md 和 advanced-usage.md；进阶场景（多卡、MoE 模型、策略路由）见 docs/reference/technical-docs.md。

六、总结：四维评分带来的确定性

• Q让"聪明程度"有据可查（实测基准优先，参数量兜底）；
• S让速度预估绑定你的真实硬件，而非纸面参数；
• F从源头杜绝"推荐了也跑不动"的尴尬；
• C保证长文档、长对话场景不被小上下文模型拖累；
• H修正让大显存机器不再"浪费"。

理解了 Q/S/F/C，你再看到 LLM Checker 的推荐列表时，就能清楚地知道每个分数背后意味着什么——这正是它能把"跑哪个模型"从玄学变成工程判断的原因。

【免费下载链接】llm-checkerAdvanced CLI tool that scans your hardware and tells you exactly which LLM or sLLM models you can run locally, with full Ollama integration.项目地址: https://gitcode.com/gh_mirrors/ll/llm-checker