硬件感知的本地LLM选型方法论：从参数规模到实际推理性能

本地部署大语言模型时，开发者常陷入一个误区：将参数规模等同于模型能力。70B 模型一定比 7B 强，这是直觉告诉我们的。然而，当 RTX 4090 的 24GB 显存勉强塞下 Llama 3 70B 的 Q4 量化版本，推理速度却跌至每秒几个 token 时，这种参数优先的选型逻辑便暴露了其局限性。

whichllm 的出现正是为了打破这种错配。它不提供 "能装下什么" 的列表，而是回答 "在你的硬件上什么表现最好"—— 这一问题的答案往往与参数规模无关。

参数规模陷阱：为什么大模型不一定更好

传统选型依赖两个假设：更大的模型能力更强；能装进显存就能运行。这两个假设在本地部署场景下都存在问题。

首先，模型能力并非与参数规模线性相关。Qwen3-32B 在多项基准测试中可能不及 Qwen3.6-27B，后者以更小的体积实现了更高的质量分数。其次，"能运行" 与 "可用" 之间存在巨大鸿沟。一个每秒输出 3 个 token 的模型，在交互场景下几乎无法使用；而量化带来的质量损失可能使大模型的优势荡然无存。

whichllm 的解决思路是引入 "证据分级" 机制。它将基准测试数据分为五个可信度层级：直接匹配（direct）、变体匹配（variant）、基础模型继承（base）、家族插值（line_interp）和上传者自报（self_reported）。每一层级对应不同的置信度折扣，从 1.0 到 0.55 不等。这意味着一个缺乏独立评测数据的 "70B 定制版" 模型，其实际排名可能低于有完整评测的 "14B 官方版"。

VRAM 计算：从简单除法到系统建模

本地部署的首要约束是显存容量。简单的计算方式是：参数量 × 每个参数的字节数。FP16 为 2 字节，Q4_K_M 量化约为 0.5 字节。按此计算，70B 模型在 Q4 量化下需要约 35GB 显存 —— 这解释了为什么 RTX 4090 的 24GB 显存无法原生加载。

但 whichllm 采用的 VRAM 模型更为精细：

VRAM = 权重占用 + KV缓存 + 激活内存 + 框架开销

权重占用即上述简单计算的结果。KV 缓存与上下文长度和注意力头维度相关，长上下文场景下可能达到权重的 20%-30%。激活内存取决于批次大小和隐藏层维度。框架开销（llama.cpp 等）通常预留 500MB 左右。

对于消费级 GPU，关键参数如下：

注意到 Apple Silicon 的速度显著低于同显存容量的独立显卡，这是因为统一内存架构的带宽限制。whichllm 在速度预估中会考虑这一因素，为不同后端（Metal vs CUDA）应用不同的带宽系数。

量化选择：精度与速度的权衡公式

量化是本地部署的核心技术，但并非所有量化方案等价。whichllm 支持的量化类型及其典型字节 / 参数比如下：

• Q8_0: 1.0 字节 / 参数 —— 接近 FP16 质量，显存占用减半
• Q6_K: 0.75 字节 / 参数 —— 质量损失极小
• Q5_K_M: 0.625 字节 / 参数 —— 推荐平衡点
• Q4_K_M: 0.5 字节 / 参数 —— 显存受限时的选择
• Q3_K_M: 0.375 字节 / 参数 —— 质量损失明显

选型时建议遵循 "量化惩罚递减" 原则：在显存允许的情况下，优先选择更高精度的量化方案。whichllm 的评分算法会对低 bit 量化施加乘法惩罚，Q4_K_M 的得分可能仅为 Q6_K 的 85%。

对于 MoE（混合专家）模型，需要区分总参数量与激活参数量。Qwen3-30B-A3B 的 30B 是总参数，实际激活仅 3B，这使得它在消费级硬件上能达到 102 t/s 的速度 —— 尽管其总参数量超过了 RTX 4090 的显存容量。

速度预估：带宽瓶颈与后端差异

本地 LLM 的推理速度主要受内存带宽限制，而非计算能力。这意味着速度预估的核心参数是显存带宽（GB/s）和量化后的数据量。

whichllm 的速度模型考虑以下因素：

1. 带宽基础：RTX 4090 的 1008 GB/s vs Apple M3 Max 的 400 GB/s
2. 量化效率：低 bit 量化通常有轻微的速度优势（数据量减少）
3. 后端差异：llama.cpp（GGUF）vs transformers（AWQ/GPTQ）的 overhead 不同
4. 卸载模式：全 GPU、部分卸载（CPU/GPU 混合）或纯 CPU 的带宽瓶颈位置不同

对于纯 CPU 推理，速度通常降至 5-10 t/s，whichllm 会对此应用 0.5 的评分系数。部分卸载模式（当模型略超显存时）的系数为 0.72，这是显存与速度之间的折中方案。

可落地的选型清单

基于上述方法论，以下是本地 LLM 选型的实操流程：

第一步：确定硬件约束

• 记录 GPU 型号、显存容量、内存带宽
• 确认可用的推理后端（NVIDIA 支持 AWQ/GPTQ，Apple/CPU 建议 GGUF）
• 评估上下文长度需求（影响 KV 缓存）

第二步：计算候选模型范围

• 目标显存占用 ≤ 可用显存 × 0.9（预留 10% 余量）
• 优先选择有 direct/variant 级别基准数据的模型
• 排除证据等级为 self_reported 且分数异常的模型

第三步：量化方案选择

• 显存充足（>1.5 倍模型需求）：Q6_K 或 Q8_0
• 显存适中：Q5_K_M（推荐平衡点）
• 显存紧张：Q4_K_M，但需验证任务质量

第四步：速度验证

• 目标交互速度 ≥ 15 t/s（对话场景）
• 批处理场景可适当降低速度要求
• 使用whichllm run直接测试候选模型

第五步：建立反馈循环

• 记录实际速度 vs 预估速度的差异
• 关注特定任务（代码、数学、多语言）的实测表现
• 定期更新基准数据（whichllm 缓存 24 小时 TTL）

局限性与边界条件

硬件感知选型并非万能。以下场景需要额外注意：

长上下文：当上下文长度超过 8K 时，KV 缓存的显存占用可能超过权重本身，此时需要重新计算 VRAM 需求或启用 KV 缓存压缩。

多模态模型：视觉编码器通常有独立的显存需求，whichllm 的估算可能低估总占用。

框架兼容性：某些量化格式（如 GPTQ）需要特定版本的 transformers 和 auto-gptq，环境配置失败会导致 "理论上能运行" 与 "实际能运行" 的偏差。

动态负载：系统显存可能被其他进程占用，建议在实际部署时预留 15-20% 的显存余量，而非追求理论上的最大模型。

结语

本地 LLM 选型的核心矛盾在于：模型能力的评估是静态的（基于基准测试），而推理体验是动态的（取决于硬件、量化、上下文长度）。whichllm 的价值在于将这两者桥接，用证据分级和硬件建模替代直觉判断。

对于工程团队，建议将 whichllm 的 JSON 输出集成到部署流水线中，实现硬件环境的自动感知和模型推荐的自动化。对于个人开发者，whichllm upgrade命令可以在硬件升级决策前提供数据支持 —— 毕竟，从 RTX 4090 升级到 5090 是否值得，最终取决于你实际能运行的模型在目标硬件上的表现提升。

资料来源

• GitHub: Andyyyy64/whichllm — 硬件感知本地 LLM 选型工具
• Hacker News — 技术社区动态参考

ai-systems