如果你有一张 RTX 4090，直觉上可能会选参数更大的模型。whichllm 的工具输出示例偏不这么排：它把 Qwen3.6-27B Q5_K_M 放在 Qwen3-32B Q4_K_M 前面。
理由不是 27B 有什么玄学优势，而是在项目当前快照里，它的综合基准分和代际新鲜度更占优。这件事的反常点也在这里：本地 LLM 的门槛，正在从“我能不能装上”，变成“我凭什么相信这个推荐”。
whichllm 把本地模型选择做成一张账本
whichllm 是一个命令行工具。它会检测本机的 NVIDIA、AMD、Apple Silicon，也支持 CPU-only 环境，再从 HuggingFace 拉取模型数据，按硬件适配、速度估算和基准表现排序。
它不是只问“显存塞不塞得下”。它问的是：塞得下的模型里，哪个更可能值得跑。
| 问题 | whichllm 给出的处理方式 |
|---|---|
| 怎么装 | pipx install whichllm，也支持 Homebrew / pip |
| 怎么用 | 输入 whichllm 自动推荐；--gpu "RTX 4090" 可模拟显卡 |
| 怎么接系统 | 支持普通表格、--json 输出，方便进脚本和流水线 |
| 怎么跑起来 | whichllm run 可下载并启动聊天；snippet 可生成 Python 代码 |
| 适合谁 | 本地 LLM 玩家、开发者、准备买显卡跑模型的人 |
它合并 LiveBench、Artificial Analysis、Aider、Vision、Chatbot Arena、Open LLM Leaderboard 等基准来源，再按证据强弱打折。
证据分 direct、variant、base、interpolated、self-reported。直连模型 ID 的分数更可信；继承、插值、自报分数会降权。
这个设计很接地气。HuggingFace 上有太多改名、重打包、衍生模型。模型卡写得漂亮，不等于模型真强。榜单分数也不是天然可比。
硬件侧，它会估算权重、KV cache、激活开销、框架开销。速度则参考显存带宽、量化效率和后端系数。MoE 模型还会区分总参数和 active 参数：质量更接近看总量，速度更接近看激活参数。
对开发者来说，这类工具最直接的用法不是“替你做最终决定”，而是缩短初筛时间。少下一堆模型，少跑几轮无效实验。
对准备买显卡的人，它更像采购前的模拟器。先用 --gpu 看不同显卡能跑什么，再决定是现在下单，还是把预算往后放。别为了一个纸面 70B，买回一套低体验组合。
它不是 Ollama，也不是 LM Studio
whichllm 容易被误会成另一个本地模型平台。不是。
Ollama 和 LM Studio 更像运行、管理和交互入口。OpenRouter 更偏云端模型路由。本地 benchmark 工具更适合你已经选定模型后，自己跑任务验证。
whichllm 站在更前面：帮你决定“先试哪几个”。
| 工具类型 | 更擅长什么 | 不擅长什么 |
|---|---|---|
| whichllm | 推荐、规划、硬件匹配、启动入口 | 不能替代真实任务测试 |
| Ollama / LM Studio | 本地运行、模型管理、聊天体验 | 不负责完整解释推荐逻辑 |
| OpenRouter | 云端多模型调用和路由 | 不是本地硬件选型工具 |
| 本地 benchmark 工具 | 针对自有任务做验证 | 前期筛模型成本仍高 |
这个差别很关键。
本地 LLM 的真实痛点，已经不是“模型不够多”。恰恰相反，是模型太多，名字太像，量化版本太碎，榜单太杂。
一个 Q4、Q5、Q8 的差别，不只是文件大小。上下文长度、后端兼容、显存 offload、tok/s、任务类型，都会改变体验。
所以 whichllm 做对的地方，是把选择成本显性化。它不是把复杂性消灭了，而是把复杂性排成表，让人能先看清。
“没有度量衡，市场只剩吆喝。”这句话放在今天的本地 LLM 生态里并不夸张。参数量、下载量、模型卡、榜单截图，都可能变成吆喝。whichllm 至少试图给这些吆喝加一把尺。
但尺不是天生公正。尺是谁造的，刻度怎么定，仍然要看。
推荐系统也会变成新的黑箱
我不太买账的，是把 whichllm 当成最终答案。
它依赖 HuggingFace API、缓存、模型元数据和后端兼容性。它也依赖榜单质量，以及作者对不同 benchmark 的权重设定。
这意味着它只能给出“目前信息下更合理的推荐”。不能给出“对你永远最优的模型”。
写代码、视觉理解、多轮聊天、长上下文，本来就是不同问题。一个模型在 Aider 上好，不代表它在你的客服知识库里好。一个模型 tok/s 高，也不代表回答更稳。
接下来最该看的，不是它能不能列出更多模型，而是四件事：
- 推荐理由是否足够透明，能不能解释分数来自 direct 还是 variant。
- 硬件估算是否和真实运行接近，特别是 KV cache、长上下文和部分 offload。
- 权重设定能不能让用户调整，而不是只能接受默认排序。
- 和 Ollama、LM Studio、脚本流水线的衔接是否稳定。
开发团队如果要把本地模型塞进产品原型，比较现实的做法是：用 whichllm 做第一轮候选，再拿自己的任务集做小规模验证。别只看第一名。
个人玩家也一样。想买显卡跑模型，可以先模拟几档硬件，看推荐结果是否跨档变化明显。如果只是从“勉强能跑”变成“稍微能跑”，采购就可以缓一缓。
whichllm 的方向是对的。它承认了一个事实：本地 AI 的瓶颈不只在模型能力，也在选择能力。
不过推荐一旦变得好用，就会获得新的控制权。今天它帮你过滤噪音，明天它也可能定义什么叫“值得跑”。这不是阴谋论，是所有推荐系统都会遇到的老问题。
本地 LLM 不缺模型名号，缺可信排序。whichllm 给了一杆秤。下一步要盯紧的，是秤砣怎么放。