基于真实基准的硬件感知LLM选型：从参数量迷信到证据驱动决策

本地部署大语言模型时，开发者常陷入一个误区：认为参数量越大的模型性能越好，只要 "能装下" 就该选最大的。然而现实往往打脸 —— 一个 70B 模型在 24GB 显存上勉强运行，token 生成速度可能只有 5 t/s，而经过量化的 32B 模型反而能以 30 t/s 流畅输出，且在下游任务上表现相当。这种 "参数量迷信" 的根源在于缺乏将硬件约束与真实性能基准关联的选型工具。

whichllm 正是针对这一痛点设计的硬件感知选型系统。它不依赖静态的 "模型 - 显存" 对照表，而是通过自动检测本地 GPU/CPU/RAM 配置，结合 HuggingFace 实时数据与多源基准测试，为每台机器生成动态排序的推荐列表。其核心洞察在于：能运行的模型不等于值得运行的模型，真正的最优选择需要在硬件适配、推理速度和任务质量之间取得平衡。

硬件检测与 VRAM 估算的工程细节

whichllm 的硬件检测模块支持 NVIDIA（通过 nvidia-ml-py）、AMD（ROCm）、Apple Silicon（Metal）以及纯 CPU 环境。检测不仅获取显存容量，还读取内存带宽、计算能力版本等关键参数，这些信息直接影响后续的推理速度估算。

VRAM 估算采用分层累加模型：VRAM = weights + GQA KV cache + activation + framework overhead。其中 weights 根据量化级别动态计算（Q4_K_M 约 0.5 字节 / 参数，Q8_0 约 1 字节 / 参数），KV cache 考虑 GQA（Grouped Query Attention）配置对内存占用的削减，activation 按上下文长度和批次大小估算，最后预留约 500MB 框架开销。这一公式比简单的 "参数量 × 字节数" 精确得多，能识别出同参数量模型因架构差异（如 MoE 的激活参数 vs 总参数）导致的显存需求变化。

系统根据估算结果将模型分为三类适配状态：Full GPU（全量载入）、Partial Offload（分层卸载到系统内存）、CPU-only（纯 CPU 运行）。每种状态对应不同的性能折扣系数，在最终评分中体现为乘性惩罚（Partial Offload ×0.72，CPU-only ×0.50）。

证据分级的基准评分系统

whichllm 最具特色的设计是其证据分级机制。项目维护者发现，开源生态中存在大量 "分数继承" 乱象：一个小规模微调版本可能借用其基础大模型的基准分数，导致用户误判。为此，系统建立了五级证据置信体系：

• direct：模型 ID 完全匹配基准条目，置信系数 1.0
• variant：后缀匹配（如 - Instruct 变体），置信系数约 0.85
• base_model：从模型卡数据推断基础模型，置信系数约 0.78
• line_interp：同家族内基于参数量的插值估算，置信系数约 0.65
• self_reported：上传者自行声明的分数，置信系数仅 0.55

系统还会主动拒绝不合理的跨家族继承 —— 当某 fork 的参数规模与家族主导成员相差超过 2 倍时，禁止其借用基础模型分数。这种严格的证据管理确保了排名结果的可信度。

基准数据来源包括 LiveBench、Artificial Analysis Index、Aider、Chatbot Arena ELO、Open LLM Leaderboard v2 等，按时效性分为当前层（实时合并）和冻结层（带时间衰减）。旧版模型的分数会随新代模型发布而降级，避免 2024 年的高分模型永远压制 2026 年的新架构。

综合评分与速度估算

最终评分（0-100）由多因子加权构成：基准质量为核心，模型大小提供对数缩放加成（log2 缩放，最高 35 分），量化级别施加乘性惩罚（Q4 约 0.9，Q8 约 0.98），证据置信度和运行时适配状态分别施加 0.55-1.0 和 0.50-1.0 的乘性折扣，推理速度贡献 - 8 到 + 8 的调整分，来源信任度（官方组织加分、已知重打包者减分）提供微调，下载量和点赞数作为置信度足够时的平局决胜因素。

速度估算基于内存带宽模型而非实测，考虑量化效率、后端类型（llama.cpp/transformers）、MoE 激活参数比例、统一内存 vs 独立显存的 PCIe 带宽限制。输出结果附带置信度标记：~表示基于估算范围，?表示低置信度（后端 / 运行时敏感性高）。

可落地的选型参数与监控清单

基于 whichllm 的设计逻辑，可提炼以下实践参数：

硬件评估阶段：

• 显存预算 = 物理 VRAM - 系统预留（建议留 1-2GB 缓冲）
• 带宽阈值：消费级 GPU（RTX 4090 级）约 1000 GB/s，Apple Silicon 统一内存约 400-800 GB/s，纯 CPU 依赖 DDR5 带宽
• 计算能力检查：确保 CUDA 版本与模型算子兼容（如 Flash Attention 要求）

模型筛选阶段：

• 优先选择证据标记为direct的模型，谨慎对待~（继承分数）和!sr（自行报告）标记
• 量化策略：Q4_K_M 适合追求速度，Q5_K_M/Q6_K 平衡质量，Q8_0 接近 FP16 精度
• MoE 模型注意区分总参数量（用于质量评估）和激活参数量（用于速度 / 显存估算）

部署验证阶段：

• 使用whichllm run一键启动候选模型，实测首 token 延迟（TTFT）和生成速度（t/s）
• 对比估算值与实测值的偏差，校准对未来选型的预期
• 监控显存占用峰值，确认无 OOM 风险

升级规划阶段：

• 使用whichllm upgrade对比当前硬件与候选 GPU 的模型选择差异
• 关注带宽提升（如 H100 的 3 TB/s vs RTX 4090 的 1 TB/s）对大型 MoE 模型的加速效果
• 评估统一内存架构（Apple Silicon）对超大规模模型 Partial Offload 场景的适用性

局限与应对

whichllm 的速度估算基于理论带宽模型，未考虑实际运行时内核效率、批次大小、并发请求等因素，输出的是规划范围而非实测基准。建议将估算值作为初筛工具，最终决策前进行实测验证。此外，工具依赖 HuggingFace API 获取模型元数据，离线环境需依赖 curated frozen fallbacks，可能错过最新发布的模型。

资料来源：

• GitHub - Andyyyy64/whichllm 项目文档与源码
• arXiv:2508.00904《Forecasting LLM Inference Performance via Hardware-Agnostic Modeling》

ai-systems