whichllm：用真实 Benchmark 而非参数量，帮你找到硬件上跑得起来的最佳本地 LLM

现在我有足够的信息来撰写完整的中文学习笔记了。

whichllm：用真实 Benchmark 而非参数量，帮你找到硬件上跑得起来的最佳本地 LLM

一句话定性：这是一个 CLI 工具，解决的不是"我的显卡能跑哪些模型"，而是"跑得起来的模型里，哪个真正最好"——这两个问题的差距，正是它存在的全部理由。

核心观点

本地部署 LLM 的社区长期存在一个思维定势：显存装得下的最大模型 = 最好的选择。whichllm 要打破的，恰恰是这个直觉。

原文用一个具体例子说明了这个差距有多真实：

RTX 4090（24GB 显存）完全装得下 Qwen3-32B，但 whichllm 把它排在 #2，把更小的 Qwen3.6-27B 排在 #1——因为后者在真实 Benchmark 上得分更高（92.8 vs 83.0），且属于更新一代。

这个例子直接说明了问题所在：一个只回答"装得下什么"的工具，会把次优模型交给你。

关键机制：评分系统的真正巧妙之处

whichllm 的机制不是简单地爬 HuggingFace 然后按参数量排序。它最核心的设计是三重折扣系统：

1. 多源 Benchmark 融合，加权置信度

评分来源包括：LiveBench、Artificial Analysis、Aider（代码评测）、Multimodal/Vision、Chatbot Arena ELO、Open LLM Leaderboard。每个来源都有置信权重，不同来源得分的影响力不同。

2. 证据等级折扣（这是最容易被忽视的设计）

每个模型的 Benchmark 数据被打上标签：

这意味着一个小 LoRA fork 不能直接继承 70B 基座模型的高分——这是防刷榜的关键设计，也是绝大多数静态榜单不具备的能力。

3. 时效性衰减

旧 Benchmark 快照沿模型世代谱系被降权，2024 年的旧测试结果不能压过 2025/2026 年的新一代模型。每次输出都打印快照日期，让"推荐是否过期"变得自证，而不是隐性失效。

评分公式结构

总分 = (Benchmark质量 + log2(模型大小) × 最高35分)
      × 量化折扣
      × 证据置信系数 (×0.55~1.0)
      × 运行适配系数 (×0.50~1.0)
      + 速度/来源可信度/流行度微调

关键信息：硬件配置参考（2026年5月快照）

速度颜色编码：< 4 tok/s 红色 / 410 黄色 / 1030 绿色 / 30+ 亮绿。

代码/命令示例

最常用场景

# 自动检测硬件，推荐最佳模型
uvx whichllm@latest

# 购机前模拟某块 GPU
uvx whichllm@latest --gpu "RTX 4090"

# 保守模式（类 LM Studio 风格，只要完全装入显存的模型）
uvx whichllm@latest --gpu-only --speed usable --vram-headroom 1GB

# 对比多块候选 GPU
whichllm upgrade "RTX 4090" "RTX 5090" "H100"

# 反向查询：跑 llama 3 70B 需要什么显卡
whichllm plan "llama 3 70b"

# 一键启动聊天（自动下载+运行）
whichllm run "qwen 2.5 1.5b gguf"

# 输出 JSON 供脚本使用
whichllm --top 1 --json | jq -r '.models[0].model_id'

生成 Python 代码片段

whichllm snippet "qwen 7b"

输出即可运行的代码：

from llama_cpp import Llama
llm = Llama.from_pretrained(
    repo_id="Qwen/Qwen2.5-7B-Instruct-GGUF",
    filename="qwen2.5-7b-instruct-q4_k_m.gguf",
    n_ctx=4096,
    n_gpu_layers=-1,
    verbose=False,
)
output = llm.create_chat_completion(
    messages=[{"role": "user", "content": "Hello!"}],
)
print(output["choices"][0]["message"]["content"])

交叉验证

我搜索并对比了两个独立信息源：

信息源 1：whichllm.app（独立 Web 工具，作者 aritra1999）

这是一个与 GitHub CLI 工具同名但独立开发的 Web 版工具。它同样从 HuggingFace 扫描 3000+ 模型，聚合 Arena Open、LLM EvalPlus、BigCodeBench、LiveBench 等 5 个 Leaderboard 的分数，根据用户填写的 RAM/VRAM 规格推荐模型。

• 认同点：多源 Benchmark 融合 + 硬件匹配的核心思路完全一致，说明这一方向的需求是真实的，已有多个独立开发者在解决同一问题。
• 差异点：Web 版是图形界面，需要手动填写硬件参数，无法做架构感知的 VRAM 精确估算（KV cache、GQA 等），也没有 MoE 活跃参数速度修正。CLI 版的评分系统明显更精细。

信息源 2：《本地LLM硬件选择完全指南2026》（braindetox.kr，独立中文技术博客）

该文章是从用户实战视角出发的硬件选购指南，不涉及 whichllm 工具本身，但其核心判断与原文高度呼应：

• 认同：明确反对"参数量越大越好"，支持"用最大量化把最大模型塞进显存的 Q4_K_M"策略；RTX 4090/M3 Max 的推荐模型（Qwen 系列）与 whichllm 输出完全吻合。
• 补充（重要）：该文章指出，英文 Benchmark 分数不能直接对应中文任务质量——Qwen 2.5 在中文任务上的实际优势远超其英文榜单分数所呈现的。这是 whichllm 当前版本的一个潜在盲区：它的 Benchmark 来源（LiveBench、Arena ELO 等）仍以英文评测为主，对中文用户来说存在系统性偏差。
• 反驳点：该指南建议用户"用工具表格做第一筛，然后手动测 2~3 个候选"，隐含着对全自动化推荐的一定保留态度。

综合判断：两个独立信源都验证了原文核心逻辑（多 Benchmark 融合优于参数量启发式）的正确性，但中文评测覆盖不足是客观存在的局限。

边界与局限：不能无条件唱赞歌

1. Benchmark 来源英文偏重：如上所述，对需要中文、日文、多语言任务的用户，分数可信度打折。
2. 速度是估算，不是实测：所有 tok/s 数据是带宽约束模型估算出来的"规划范围"，~ 和 ? 标记提示了置信度，真实速度受驱动版本、系统负载、散热等影响，RTX 3090 和 RTX 4090 的实测差异有时大于估算。
3. MoE 模型的双重计数问题：工具用"总参数量"评质量、用"激活参数量"估速度，这个处理方式在 Qwen3-30B-A3B（MoE 102 t/s）的例子上看起来合理，但对一些激活参数比例极端的 MoE 架构，质量估算可能存在高估。
4. "雄心勃勃"模式可能推荐边缘 fit：默认包含"partial RAM offload"，这在某些场景下会导致速度比预期慢得多，原文也提示了用 --gpu-only --speed usable --vram-headroom 1GB 做保守配置，但新手容易忽略这个。
5. 非 GGUF 格式体验较弱：AWQ/GPTQ/FP16 格式虽支持，但 run 命令的核心优化围绕 GGUF + llama-cpp-python，其他格式的一键体验质量较低。

个人启发

对个人开发者：最实用的工作流不是跑一次 whichllm 就决定模型，而是：

1. 跑 whichllm --top 5 --json 得到候选列表；
2. 对 top-3 用 whichllm run 各测一段对话；
3. 再用 whichllm snippet 生成代码嵌入到项目中。

这比去 HuggingFace 手动搜索、看榜单、估 VRAM、找 GGUF 文件名，节省的时间相当可观。

对购机决策者：whichllm --gpu "RTX 5090" vs whichllm --gpu "RTX 4090" 的对比输出，比任何评测文章都直接——你能看到两张卡对应的 Top-1 模型质量分差（94.7 vs 92.8）和速度差（~40 t/s vs ~27 t/s），从而判断溢价是否值得。目前数据显示，RTX 5090 对本地 LLM 的核心优势是速度（~50%提升），质量分提升有限，因为瓶颈已经不在 VRAM 容量而在带宽。

对中文用户的特别提示：用 --profile 过滤任务时，目前没有 --profile chinese 选项。在 whichllm 的推荐基础上，应额外验证目标模型是否有针对中文的专项测试记录，Qwen 系列通常是最优先选项，这与工具的自动推荐结果吻合，但机制不同。

延伸思考

1. "装得进"和"跑得好"的分离会继续加剧吗？ 随着 MoE 架构（如 Qwen3-30B-A3B、DeepSeek-V3）越来越普及，"总参数量大"但"激活参数少、速度快"的模型会越来越多。纯 VRAM 匹配工具的局限会进一步暴露，whichllm 这类工具的细分价值会更大——但它的评分系统是否能跟上 MoE 质量评估的复杂性，值得持续观察。

2. 自动化推荐 vs 个人偏好的边界在哪里？ whichllm 的 Benchmark 融合是对"通用质量"的综合判断，但实际使用中，一个代码开发者和一个创意写作者对"最佳模型"的定义完全不同。--profile coding 等过滤器是朝这个方向迈出的一步，但任务粒度还很粗——真正的个性化推荐需要用户的历史对话数据，这与本地隐私部署的初衷形成张力。

3. 这类工具本身会不会造成模型同质化？ 如果全球大量本地部署用户都用 whichllm，且工具的评分逻辑持续推荐 Qwen 系列（因为它们在 Benchmark 上确实领先），会不会形成一个"推荐→下载量增加→HuggingFace 热度增加→反馈进评分系统"的自我强化循环，反而让评分失去多样性参考价值？这是所有基于聚合数据的推荐系统都面临的共同问题。

📚 参考来源

1. GitHub - Andyyyy64/whichllm: Find the local LLM that actually runs and performs best on your hardware. Ranked by real, recency-aware benchmarks, not parameter count. One command, run it instantly. · GitHub