whichllm：本地大模型的智能伯乐

你有没有过这样的经历：花了大价钱升级了显卡，兴冲冲地打开 HuggingFace，却发现推荐给你的模型根本塞不进显存？或者勉强跑起来了，速度却像在幻灯片上播放视频？更大的困惑是，那些评测榜单上的高分模型，在你的机器上真的表现同样出色吗？

whichllm 正是为解决这一困境而生的 CLI 工具——它自动检测你的硬件配置，从 HuggingFace 海量模型库中实时筛选出「能跑且跑得好」的最优选择，并用真实的评测基准数据给出一个 0-100 的综合评分，让你不再靠玄学选模型。

图1：whichllm 在 RTX 4090 上的推荐结果

项目背景：选错模型的代价，远比你想象的大

whichllm 的作者 Andyyyy64 是一个资深的本地 LLM 爱好者，在 GitHub 上持续维护多个 AI 相关项目。这位开发者注意到了本地大模型社区的一个普遍痛点：用户选模型时，往往只能在「显存够不够」和「评测榜单排名」之间二选一，缺少一个能将硬件约束、推理速度、真实评测表现三者综合考量的工具。

当前主流的模型推荐方式存在三个根本性问题：

问题一：「能跑就算」的误导 —— 很多工具只告诉你「这个模型能放进显存」，却完全忽略了同显存下可能有速度更快、评测更好的替代选项。whichllm 在 RTX 4090 上的实测结果最能说明这一点：32B 模型虽然「刚好能塞进去」，但 27B 模型（Qwen3.6-27B，Q5_K_M 量化）不仅显存更宽裕，基准评测分数还更高，排名理应更靠前。一个只看显存的工具会把这两个选项混为一谈，而 whichllm 用综合评分给出了清晰答案。

问题二：榜单数据陈旧且不透明 —— 主流评测榜单往往数月甚至数年不更新，2024 年的模型可能因为延续了更大基座的「祖传高分」，反而排在新一代模型前面。更糟的是，大多数工具不告诉你分数是什么时候采集的。whichllm 对每个分数标注了快照日期，落后于当前代际的评分会被主动降权，榜单的时效性变得透明可查。

问题三：无法预测硬件升级效果 —— 用户想升级显卡时，无法提前知道新显卡能跑什么级别的模型，往往买完才发现容量买错了。whichllm 的 whichllm --gpu "RTX 4090" 可以在买卡之前模拟任意显卡的推荐结果，彻底告别「盲买」。

whichllm 于 2025-2026 年间快速增长至 3600+ GitHub Stars，成为本地 LLM 爱好者选模型的标配工具。

核心功能：不是「能跑吗」，而是「哪个最好」

whichllm 的核心逻辑与传统「显存计算器」截然不同。它先通过 nvidia-ml-py / dbgpu / Metal API 自动检测你的硬件（NVIDIA GPU 型号+显存、AMD GPU、Apple Silicon、CPU 核心数+内存），再从 HuggingFace 实时拉取模型列表，结合本地缓存（TTL 6h）的评测数据（LiveBench、Artificial Analysis、Aider、Chatbot Arena ELO、Open LLM Leaderboard），对每个「能放进显存」的模型打出 0-100 综合分。

综合分的计算考虑了多个维度：

分值上方的标注同样值得关注：~（黄色）表示分数来自家族继承而非本模型直接评测；!sr（亮黄）表示仅来自上传者的自报评测数据；?（红色）表示无任何评测记录，评分完全基于规模推测。

除了默认推荐，whichllm 还提供了多个实用子命令：

其中 whichllm run 的体验尤为亮眼：用户只需指定模型名，工具自动创建隔离的 Python 环境（通过 uv），下载 GGUF 文件，启动 Llama.cpp 推理引擎，并进入交互式对话——整个过程无需用户手动处理任何依赖或路径问题。

图2：whichllm run 自动下载模型并启动对话

技术架构：分层解耦的数据流水线

whichllm 的代码架构清晰分层，共 7 个核心模块：

src/whichllm/
├── cli.py              # Typer CLI 入口（main/plan/run/snippet/hardware）
├── constants.py        # GPU 带宽、量化字节数、算力阈值常量
├── hardware/           # 硬件检测层
│   ├── detector.py      # 统一调度 GPU/CPU/RAM 检测
│   ├── nvidia.py       # nvidia-ml-py（CUDA）检测
│   ├── amd.py          # dbgpu（ROCm，Linux）检测
│   ├── apple.py        # Metal Performance Shaders 检测
│   ├── cpu.py          # CPU 型号 + AVX 支持检测
│   ├── memory.py       # RAM 和磁盘可用空间
│   └── gpu_simulator.py # --gpu 参数解析和合成 GPU 构建
├── models/             # 模型数据层
│   ├── fetcher.py      # HuggingFace API 模型拉取
│   ├── benchmark.py    # 评测榜单数据（ELO/Parquet）解析
│   ├── grouper.py      # 模型家族分组（base_model 归组）
│   ├── cache.py        # 本地 JSON 缓存（TTL 控制）
│   └── benchmark_sources/ # LiveBench/Artificial Analysis 等数据源
├── engine/             # 评分引擎
│   ├── vram.py         # 显存估算（权重+KV+激活+框架开销 ~500MB）
│   ├── compatibility.py # 适配类型判定（全加载/部分卸载/CPU）
│   ├── performance.py   # 推理速度估算（带宽×量化效率）
│   ├── quantization.py  # 量化字节数和质量惩罚
│   └── ranker.py       # 综合评分 + 证据过滤 + profile 筛选
└── output/
    └── display.py      # Rich 表格渲染 / JSON 输出

关键依赖：Typer + Rich（交互式 CLI）、httpx（异步 HTTP 获取 HuggingFace 数据）、nvidia-ml-py（pynvml，NVIDIA GPU 检测）、dbgpu[fuzz]（AMD GPU + ROCm 支持）、psutil（系统资源检测）。

项目使用 Hatchling 构建，支持 uv tool install / pip install / brew install 三种安装路径，依赖管理通过 uv.lock + pyproject.toml 控制，测试框架为 pytest。

局限与争议：它不是万能的

whichllm 并非银弹，用户在上手前需要了解其局限性：

评测数据不完整 —— 部分小众或新发布模型可能完全没有评测记录（标记为 ?），此时评分参考价值有限，只能依赖模型规模进行粗略估算。

速度估算基于理论带宽 —— 实际推理速度受 batch size、上下文长度、框架版本等影响。工具标注 ~（黄色）的速度估算范围不应等同于实测，用户在最终选型时需要保留容错空间。

Apple Silicon / CPU 仅支持 GGUF —— 项目代码中对 Apple Silicon 和 CPU-only 模式强制限制为 GGUF 格式，不支持 AWQ/GPTQ/FP16 推理路径。这意味着 Apple M 系列芯片用户无法利用统一内存的优势运行更高精度的非 GGUF 模型。

缓存带来的数据延迟 —— 本地缓存（models.json TTL 6h、benchmark.json TTL 24h）提升了响应速度，但也意味着新模型上线 HuggingFace 后，需要等待 TTL 过期才能进入推荐范围。使用 --refresh 参数可强制刷新缓存。

行业意义：让本地 AI 民主化

whichllm 的出现填补了一个重要空白：它不只是「显存够不够」的计算器，而是把模型选择这件事从「凭感觉」拉高到了「凭数据」。

从数据看，该项目在 2025-2026 年快速增长，GitHub Stars 已超过 3600，涵盖了从 RTX 4060（8GB）到 H100 的全硬件谱系推荐。对于预算有限但想跑大模型的个人开发者、学生党，以及需要在多台不同配置机器上快速评估可行方案的企业用户，whichllm 提供了一个统一、客观、可脚本化的选型入口。

更重要的是，它推动了本地大模型社区从「盲目追求最大模型」向「理性选择最适合自己硬件的模型」的认知转变。JSON 输出格式（whichllm --json）可以方便地接入各类脚本和 pipeline，形成从选型到部署的完整工作流——这本身就是 AI 民主化进程中的重要一步。