在本地大语言模型部署场景中，「能跑哪些模型」与「哪些模型真正值得跑」之间存在巨大鸿沟。参数规模常被用作唯一筛选标准，但这种方法忽略了量化级别对质量的影响、内存带宽对速度的约束，以及不同基准来源的可信度差异。whichllm 项目通过构建一套完整的多维评估矩阵，将硬件约束、模型质量与推理速度纳入统一框架，为本地 LLM 选型提供了数据驱动的决策依据。
VRAM 估算：从经验判断到精确建模
大多数本地 LLM 选型工具仅检查「模型是否放得下」，但对 VRAM 占用的内部构成缺乏透明度。whichllm 的 vram.py 模块将显存消耗分解为四个可量化组件：权重本身、KV 缓存、激活值与框架开销。这一拆解使得用户能够理解为什么相同参数量的模型在 VRAM 占用上存在差异，以及不同量化级别如何影响整体显存需求。
权重占用取决于模型参数总量与量化位数。以 FP16 加载 7B 参数模型需要约 14GB 显存，而 Q4_K_M 量化后通常降至 4GB 左右。关键在于，不同量化方案并非线性压缩 ——Q5_K_M 相比 Q4_K_M 质量提升显著，但占用增幅远低于两者在参数密度上的比例。whichllm 在 constants.py 中维护了各量化方案的单参数字节数查找表，使得 VRAM 估算具备量化级别敏感性。
KV 缓存占用与上下文长度呈线性关系，同时受注意力头数与键值维度影响。对于 7B 模型以 4096 上下文长度运行，KV 缓存占用约在 1-2GB 范围；当上下文扩展至 32768 时，KV 缓存可能成为显存瓶颈。whichllm 的 plan 命令支持通过 --context-length 参数模拟不同上下文长度下的 VRAM 需求，这对需要长文档处理的场景尤为重要。
激活值占用与 batch size 和序列长度相关，但在单请求场景下通常可控。框架开销（whichllm 默认估算为约 500MB）涵盖了 CUDA 上下文、KV 缓存预分配等运行时内存，这部分往往被用户忽略却在实际部署中导致「明明算得下却跑不起来」的情况。
硬件检测：跨平台兼容性的抽象层
whichllm 的硬件检测模块采用平台特定后端架构。NVIDIA GPU 通过 nvidia-ml-py 库查询驱动级显存与计算能力信息；AMD GPU 在 Linux 环境下通过 ROCm 接口获取硬件参数；Apple Silicon 依赖 Metal 框架报告统一内存与 GPU 核心数；CPU-only 场景则通过标准系统调用获取核心数与 AVX 支持状态。
这种分层设计的核心价值在于统一抽象。ranker.py 接收的硬件信息不包含平台来源细节，仅包含计算能力、显存容量、内存带宽等决策所需参数。这使得评估引擎与具体硬件解耦 —— 同一套排序逻辑适用于 RTX 4090、MacBook M3 Max 或纯 CPU 服务器。
GPU 模拟器（--gpu "RTX 4090" 参数）基于 constants.py 中维护的硬件规格数据库工作。当用户尚未购买硬件但希望规划配置时，模拟器返回与真实硬件检测相同的数据结构，确保离线规划与在线决策使用同一套评估路径。
基准质量：多源融合与置信度衰减
whichllm 整合的基准来源分为两个层级。实时层（LiveBench、AI Index、Aider）每次调用时从源头获取最新数据，权重最高但依赖网络可达性。静态层（Open LLM Leaderboard v2、Chatbot Arena ELO）在 HuggingFace 模型卡片有对应记录时使用，但由于更新周期较长，引入谱系感知衰减机制 —— 旧基准对新型号的评分影响力随时间推移而递减，防止过时评测压制当前最佳模型。
证据解析采用五级分辨率策略。direct 级别要求模型 ID 完全匹配；variant 级别在移除 -Instruct 等后缀后匹配；base_model 级别继承自基础模型的评测结果；line_interp 级别在同一模型家族内按参数规模插值；self_reported 级别为模型上传者自行声明的评测分数，经过最严格的置信度衰减。模型家族分组（grouper.py）通过 base_model 与名称模式识别家族关系，当某分支模型的参数规模与其家族主体差异超过 2 倍时，拒绝继承评分 —— 这防止了蒸馏模型借用原模型评测分数的情况。
量化惩罚同样影响最终评分。Q3 及以下量化版本的乘数折扣最为显著，因为这些级别在保持模型能力方面存在明显损失。评分公式中，基准质量作为核心权重，模型规模提供最大 35 分的对数加成，量化、置信度、运行兼容性等因素作为乘数与加减调整项综合计算。
推理速度：带宽约束与活跃参数建模
推理速度估算以 GPU 内存带宽为第一约束条件。whichllm 的 performance.py 模块查询目标 GPU 的标称带宽（单位：GB/s），然后根据量化方案的每秒参数处理吞吐量常数估算 token 生成速度。对于混合专家（MoE）模型，活跃参数与总参数的比例被纳入计算 —— 一个 30B 总参数的 MoE 模型可能仅有 8B 活跃参数，相同带宽下速度接近 8B 密集模型而非 30B 模型。
后端兼容性同样影响速度估算。llama.cpp-python（GGUF 格式）在 Apple Silicon 与 CPU 场景下为唯一稳定选项；Linux + NVIDIA 环境下支持 AWQ/GPTQ 量化格式，通过 transformers 库加载，速度估算需要考虑这些格式的核函数效率差异。whichllm 的排序输出同时展示每秒 token 数（tok/s）与综合评分，使得用户在速度与质量之间权衡时具备完整信息。
排序逻辑：多目标决策的参数化实现
whichllm 的排序引擎并非简单的「质量优先」或「速度优先」，而是将多个优化目标整合为统一的评分函数。核心公式可概括为：基准质量（经置信度加权）与模型规模（对数缩放）构成基础分，量化级别通过乘法折扣降低分数，运行时兼容性（全部加载、部分卸载、纯 CPU）通过乘数影响最终结果，速度与来源可信度作为细粒度调整项。
这一设计的工程意义在于将决策过程透明化。用户可以明确知道：为什么 27B 的 Qwen3.6 在 RTX 4090 上排序高于 32B 的 Qwen3，尽管后者参数规模更大。关键在于 Qwen3.6 作为新一代模型，在基准评测中的表现优于旧型号，且 Q5_K_M 量化下的质量损失远小于 Q4_K_M 对 Qwen3 的影响。评分差异反映了模型代数进步与量化方案优化的综合效果，而非单一维度的排序。
--profile 参数支持按任务类型筛选排序结果。coding 配置提升编程相关评测的权重；vision 配置将多模态模型纳入考量；math 配置侧重数学推理基准。对于没有明确任务偏好的通用场景，默认配置在各类评测间保持均衡。
工程配置参数清单
基于 whichllm 的设计理念，以下参数可作为本地 LLM 基准测试的配置参考。VRAM 估算中，建议预留框架开销 500MB 作为安全边界；KV 缓存按「层数 × 2 × 头数 × 维度 ÷ 1024³」估算，实际测试时可通过 nvidia-smi 或类似工具验证。基准置信度方面，无评测数据标记为 ~ 或 ?，继承评分乘以 0.78，自报分数乘以 0.55。量化选择上，Q4_K_M 作为质量 - 体积平衡点适合 8-16GB VRAM；Q5_K_M 适合 16-24GB VRAM 且对质量敏感的场景；Q6_K 在 24GB 以上 VRAM 时优于 Q5_K_M。速度估算中，RTX 4090（1008 GB/s）作为基准，30B MoE 模型活跃参数 10B 时约 100 tok/s，7B 密集模型 Q4 约 25-30 tok/s。
资料来源：https://github.com/Andyyyy64/whichllm
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。