阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/whichllm-local-model-selection/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 它解决的是「哪个能跑」之后的问题
• 两个判断，把它和显存计算器分开
• 买卡之前先模拟一遍
• 装起来和用起来
• 它现在还不够好的地方

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

前两周给一台旧机器装本地模型，3060 12G，想着跑个 7B 总够了吧。Qwen 2.5 7B 行，Llama 3 8B 也行。膨胀了，下个 14B 的 GGUF Q4_K_M，跑起来一秒三个字，那感觉像买了张 4090 回来发现打游戏还得开低画质。

它解决的是「哪个能跑」之后的问题

更烦的是选型这一步。看某个模型排名高，去 Hugging Face 找 GGUF，挑个看着顺眼的量化版本，下载，跑，要么龟速要么爆显存，删掉。这套流程我今年至少走了三遍，每次删的都是「别人说好但我跑不动」的模型。

whichllm 干的事说起来不复杂。跑一下命令，它扫一遍你的 GPU、CPU 和内存，再去 Hugging Face 拉模型列表，按评分从高到低排好，告诉你哪些能跑、大概跑多快。项目 MIT 协议，Python 写的，作者是 GitHub 上的 Andyyyy64，德国人，本职是产品经理。仓库现在六千七百多 Star，三月建的库，最近还在提交。

两个判断，把它和显存计算器分开

「帮你选模型」这四个字太轻了，市面上做这件事的工具不少。它真正拉开差距的是两个判断。

第一个判断，它不看模型大小，看模型好不好。

多数显存计算器的逻辑是，你有多少显存、用哪种量化、最大能塞多大参数，就推那个。至于这个模型本身行不行，它不管。

whichllm 换成合并真实榜单数据来打分，来源包括 LiveBench、Artificial Analysis、Aider、多模态与视觉、Chatbot Arena ELO 和 Open LLM Leaderboard。所以它经常会在同一张卡上推一个参数量更小的新型号，因为新版跑分比老版高，架构更新、训练更好，花差不多的显存和时间能拿到更好的回答。

它还做了时效衰减。过期的榜单分会沿模型族谱被降权，让老一代模型没法靠一份旧分数排到当代表型前面；而且每次排名的下方会打印榜单快照日期，推荐有没有过期，一眼就能看出来。

第二个判断，它知道哪些评分能信，哪些不能信。

每条评测数据都带来源标签，从 direct 到 variant 到 base 到 interpolated 再到 self-reported，分五级并做置信度折扣。结果里分数前面带 ~ 或者一个标记，就说明这个分可能有水分。跑几次会发现，不少看起来很能打的模型前面都挂着 ~，点进去一看果然是家族插值算出来的。

更狠的是查跨家族继承。有人在 Hugging Face 上 fork 一个 70B，改出个小变体，宣称继承了原版的评测分数。它对比参数量，发现差到两倍以上，直接把这条数据拒掉。

顺带说一句显存估算也没有偷懒。显存的组成是权重、KV 缓存、激活和额外开销几块。速度按带宽受限来算，还要算上每种量化的效率、不同后端的系数，以及 MoE 的激活与总量拆分。统一内存和独立显卡部分卸载这两种情况也是分开建模的。

买卡之前先模拟一遍

它有几条子命令，用法都挺直给。

买卡之前的摸底。whichllm --gpu "RTX 5090" 可以模拟目标显卡，看上面能跑什么。有人据此判断升到更大显存之后能上更高的量化档，实测那一档在逻辑推理题上确实更稳。值不值一万多块另说，至少知道钱花在哪。

选模型之前的快速验证。不是每个模型都值得花半小时下载，whichllm plan "llama 3 70b" 会告诉你跑它要什么硬件。想试更大的模型之前先跑一遍，能省掉几次白下载。

写代码集成的时候用 whichllm snippet "qwen 7b"，它直接输出一段 Python，用 llama-cpp-python 加载模型，复制粘贴就能跑，比自己翻文档快。

还有一条 whichllm run，会自动隔离环境、装依赖、下载模型然后进对话，相当于一个零配置的本地模型启动器。习惯在 Ollama 里管模型的人可能用不上，但对不想配环境的人很友好。

另外几个开关值得知道。--fit full-gpu 只显示能完全装进显存的候选，--speed usable 按阈值过滤掉太慢的行。

--vram-headroom 和 --ram-budget 用来避开贴边的估算，--markdown 输出可以直接粘到文档里的表格，多卡可以写成 2x RTX 4090 这种形式。

装起来和用起来

前提是 Python 3.11 以上，命令只有一行。

uvx whichllm@latest

不需要预先安装，第一次跑会自动拉下来，跑完即走。想常驻就换成常驻安装，升级也有一条命令。

uv tool install whichllm
uv tool upgrade whichllm

另外还有两条路，pip install whichllm，macOS 上可以用 brew install andyyyy64/whichllm/whichllm。

它现在还不够好的地方

三件事值得提前知道。

断网就废了一半。数据走 Hugging Face API 实时拉，本地虽然有缓存，模型列表 6 小时过期、评测数据 24 小时过期，没网的时候只能看缓存，新模型压根不知道。

默认输出是为终端观感做的表格，想喂给脚本必须加 --json，不加的话标准输出只是展示，管道里接不上。

最后一条更根本。它告诉你哪个模型在榜单上分高，不等于这个模型在你的具体任务上表现好，写代码和写小说要的肯定不是同一个。它支持按画像过滤，目前覆盖通用、编码、视觉和数学四类，粒度还是偏粗。要是以后能像竞技场那样把编程、绘图、文本分开排，就好用多了。

回到开头那个问题。本地跑大模型，真正费时间的不是下载，是不知道哪个模型能在自己机器上好好干活。它不能替你选出最好的那个，但能让你别选到最烂的那个，省下来的时间刷点什么不好。

仓库在 https://github.com/Andyyyy64/whichllm