whichllm - 本地大模型硬體適配推薦工具

解決什麼

本地執行大模型時,開發者面臨三重困境:哪些模型能塞進視訊記憶體、哪個量化版本速度夠用、同等配置下哪個模型效果最好。傳統做法是手算 VRAM 佔用或憑經驗試錯,whichllm 通過自動檢測硬體(NVIDIA/AMD/Intel GPU、Apple 統一記憶體、純 CPU)並即時拉取 HuggingFace 模型庫,結合真實基準測試(LiveBench、Chatbot Arena ELO、Aider 編碼評測等)給出排序推薦,一條命令解決"我的 RTX 4060 該跑哪個模型"的選型問題。

為何火

6000+ stars 的核心原因是精準擊中本地 LLM 玩家的痛點:不再需要在 Reddit/Discord 翻帖子問"3090 能跑 70B 嗎",也不用被"引數越大越好"的誤區坑。專案獨特之處在於證據驅動排序(合併多個權威 Benchmark 而非自編評分)、時效性感知(舊模型即使分數高也會被降權)、架構級估算(區分 MoE 啟用引數與總引數、計算 GQA KV cache 開銷),且支援 --gpu "RTX 5090" 模擬未購硬體的執行效果,讓顯示卡升級決策有資料支撐。

核心功能

• 硬體自動識別:檢測 NVIDIA/AMD/Intel 獨顯、Apple Silicon 統一記憶體、CPU 核心數與 RAM 頻寬
• 智慧排序推薦:綜合 VRAM 適配度、推理速度(tok/s)、基準測試得分(LiveBench/Arena/Aider)三維度排序
• 顯示卡模擬器:whichllm --gpu "RTX 4090" 或 --gpu "2x RTX 4090" 模擬多卡/未購硬體
• 一鍵啟動對話:whichllm run "qwen 2.5 7b" 自動下載 GGUF 並啟動 llama.cpp 聊天
• 程式碼片段生成:whichllm snippet "qwen 7b" 輸出可複製的 Python 推理程式碼
• 任務場景過濾:支援 --task coding/vision/math 篩選特定用途模型
• 保守模式:--gpu-only --speed usable --vram-headroom 1GB 僅推薦完全裝入視訊記憶體且留餘量的模型
• JSON 輸出:--json | jq 用於指令碼化流程

安裝

推薦方式(無需安裝):

uvx whichllm@latest  # 使用 uv 一次性執行最新版

持久化安裝:

pip install whichllm
# 或
brew install andyyyy64/whichllm/whichllm  # macOS Homebrew
# 或
uv tool install whichllm  # uv 工具鏈管理

要求 Python 3.11+,依賴 Typer(CLI 框架)、Rich(終端渲染)、httpx(非同步 HTTP)、nvidia-ml-py(NVIDIA GPU 監控)。

適合誰

1. 本地 LLM 玩家:在消費級顯示卡(RTX 4060/3090/Apple M3)上跑開源模型,需要快速找到"能跑且好用"的版本
2. AI 應用開發者:需在邊緣裝置/工作站部署推理服務,用 --json 輸出整合到自動化選型指令碼
3. 硬體升級決策者:whichllm upgrade "RTX 4090" "RTX 5090" "H100" 對比升級收益,或用 whichllm plan "llama 3 70b" 反查需要什麼顯示卡
4. LM Studio 使用者:官方推薦保守時,用 --gpu-only --vram-headroom 1.5GB 獲得更激進的選項

中文使用者注意:工具需訪問 HuggingFace API 拉取模型後設資料,國內網路可能需梯子;支援離線快取模式(frozen fallbacks),但首次執行建議聯網。

社群評價

暫無足量社群公開討論(HN 帖僅 3 點贊無評論),以下為基於專案本身的中立評估:從 GitHub 資料看,專案在 5 個月內獲得 6000+ stars 且保持活躍(3 天前仍有提交),說明實用性強。README 詳盡展示了與 LM Studio 的對比場景(whichllm 更激進但可調保守),技術文件透明披露了排序邏輯(benchmark 置信度分級、MoE 啟用引數處理),避免了"黑盒推薦"的信任問題。23 位貢獻者和持續的版本迭代(v0.5.15)顯示社群參與度健康,但 21 個 open issues 提示仍有待完善的邊緣場景。

選型對比

vs LM Studio(商業 GUI 工具):

• LM Studio 提供圖形介面和一鍵下載,whichllm 是純命令列但可指令碼化(--json)
• LM Studio 推薦偏保守(留足 VRAM 餘量),whichllm 預設激進(含部分 offload 方案),但可通過 --gpu-only --vram-headroom 對齊保守策略
• whichllm 的排序基於即時 Benchmark 資料,LM Studio 更依賴社群人工整理的相容性列表

vs Ollama(本地模型執行時):

• Ollama 側重"一鍵執行已知模型",whichllm 側重"先幫你選對模型"
• 兩者可互補:whichllm 推薦 → 複製模型名 → ollama run <model>

vs 手動查 HuggingFace Leaderboard:

• 人工查榜單隻能看單一 Benchmark,whichllm 合併 5+ 權威評測並按硬體過濾
• 榜單不考慮硬體適配,whichllm 的 VRAM/速度估算避免"下載後才發現跑不動"

已知坑

1. HuggingFace API 依賴:國內網路可能超時,雖有離線快取但首次執行需聯網;可設定 HF_ENDPOINT 環境變數指向映象站
2. 速度估算為近似值:README 明確標註 ~ 表示估算、? 表示低置信度,實際 tok/s 受驅動版本/後端實現(llama.cpp/vLLM)影響
3. MoE 模型的"虛高"引數:工具已處理(按啟用引數算速度、總引數算質量),但使用者需理解 Qwen3-30B-A3B 的 30B 不等於密集模型的 30B
4. Apple Silicon 的統一記憶體:需手動 --vram <GB> --ram-bandwidth <GB/s> 覆蓋檢測值,因系統 API 返回的可用記憶體可能不準
5. 21 個 open issues:包括部分 AMD GPU 識別問題、某些量化格式(如 EXL2)的支援請求,非關鍵路徑但可能影響小眾硬體使用者