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

📅 2026/7/24 13:52:14
whichllm:用真实 Benchmark 而非参数量,帮你找到硬件上跑得起来的最佳本地 LLM
现在我有足够的信息来撰写完整的中文学习笔记了。whichllm用真实 Benchmark 而非参数量帮你找到硬件上跑得起来的最佳本地 LLM一句话定性这是一个 CLI 工具解决的不是我的显卡能跑哪些模型而是跑得起来的模型里哪个真正最好——这两个问题的差距正是它存在的全部理由。核心观点本地部署 LLM 的社区长期存在一个思维定势显存装得下的最大模型 最好的选择。whichllm要打破的恰恰是这个直觉。原文用一个具体例子说明了这个差距有多真实RTX 409024GB 显存完全装得下 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 数据被打上标签等级含义折扣系数direct有该模型的直接测试结果×1.0variant来自同系列变体有折扣base继承自基础模型×0.78interpolated插值估算有折扣self-reported上传者自报×0.55这意味着一个小 LoRA fork 不能直接继承 70B 基座模型的高分——这是防刷榜的关键设计也是绝大多数静态榜单不具备的能力。3. 时效性衰减旧 Benchmark 快照沿模型世代谱系被降权2024 年的旧测试结果不能压过 2025/2026 年的新一代模型。每次输出都打印快照日期让推荐是否过期变得自证而不是隐性失效。评分公式结构总分 (Benchmark质量 log2(模型大小) × 最高35分) × 量化折扣 × 证据置信系数 (×0.55~1.0) × 运行适配系数 (×0.50~1.0) 速度/来源可信度/流行度微调关键信息硬件配置参考2026年5月快照硬件VRAM推荐模型估算速度RTX 509032 GBQwen3.6-27B · Q6_K · score 94.7~40 t/sRTX 4090 / 309024 GBQwen3.6-27B · Q5_K_M · score 92.8~27 t/sRTX 40608 GBQwen3-14B · Q3_K_M · score 71.0~22 t/sApple M3 Max36 GBQwen3.6-27B · Q5_K_M · score 89.4~9 t/s纯 CPU—gpt-oss-20b(MoE) · Q4_K_M · score 45.2~6 t/s速度颜色编码 4 tok/s 红色 / 410 黄色 / 1030 绿色 / 30 亮绿。代码/命令示例最常用场景# 自动检测硬件推荐最佳模型 uvx whichllmlatest # 购机前模拟某块 GPU uvx whichllmlatest --gpu RTX 4090 # 保守模式类 LM Studio 风格只要完全装入显存的模型 uvx whichllmlatest --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_idQwen/Qwen2.5-7B-Instruct-GGUF, filenameqwen2.5-7b-instruct-q4_k_m.gguf, n_ctx4096, n_gpu_layers-1, verboseFalse, ) output llm.create_chat_completion( messages[{role: user, content: Hello!}], ) print(output[choices][0][message][content])交叉验证我搜索并对比了两个独立信息源信息源 1whichllm.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 融合优于参数量启发式的正确性但中文评测覆盖不足是客观存在的局限。边界与局限不能无条件唱赞歌Benchmark 来源英文偏重如上所述对需要中文、日文、多语言任务的用户分数可信度打折。速度是估算不是实测所有 tok/s 数据是带宽约束模型估算出来的规划范围~和?标记提示了置信度真实速度受驱动版本、系统负载、散热等影响RTX 3090 和 RTX 4090 的实测差异有时大于估算。MoE 模型的双重计数问题工具用总参数量评质量、用激活参数量估速度这个处理方式在 Qwen3-30B-A3BMoE 102 t/s的例子上看起来合理但对一些激活参数比例极端的 MoE 架构质量估算可能存在高估。雄心勃勃模式可能推荐边缘 fit默认包含partial RAM offload这在某些场景下会导致速度比预期慢得多原文也提示了用--gpu-only --speed usable --vram-headroom 1GB做保守配置但新手容易忽略这个。非 GGUF 格式体验较弱AWQ/GPTQ/FP16 格式虽支持但run命令的核心优化围绕 GGUF llama-cpp-python其他格式的一键体验质量较低。个人启发对个人开发者最实用的工作流不是跑一次whichllm就决定模型而是跑whichllm --top 5 --json得到候选列表对 top-3 用whichllm run各测一段对话再用whichllm snippet生成代码嵌入到项目中。这比去 HuggingFace 手动搜索、看榜单、估 VRAM、找 GGUF 文件名节省的时间相当可观。对购机决策者whichllm --gpu RTX 5090vswhichllm --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 系列通常是最优先选项这与工具的自动推荐结果吻合但机制不同。延伸思考装得进和跑得好的分离会继续加剧吗随着 MoE 架构如 Qwen3-30B-A3B、DeepSeek-V3越来越普及总参数量大但激活参数少、速度快的模型会越来越多。纯 VRAM 匹配工具的局限会进一步暴露whichllm这类工具的细分价值会更大——但它的评分系统是否能跟上 MoE 质量评估的复杂性值得持续观察。自动化推荐 vs 个人偏好的边界在哪里whichllm的 Benchmark 融合是对通用质量的综合判断但实际使用中一个代码开发者和一个创意写作者对最佳模型的定义完全不同。--profile coding等过滤器是朝这个方向迈出的一步但任务粒度还很粗——真正的个性化推荐需要用户的历史对话数据这与本地隐私部署的初衷形成张力。这类工具本身会不会造成模型同质化如果全球大量本地部署用户都用whichllm且工具的评分逻辑持续推荐 Qwen 系列因为它们在 Benchmark 上确实领先会不会形成一个推荐→下载量增加→HuggingFace 热度增加→反馈进评分系统的自我强化循环反而让评分失去多样性参考价值这是所有基于聚合数据的推荐系统都面临的共同问题。 参考来源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