在本地跑大模型最典型的失败路径不是模型推理不出来而是下载完一个 40GB 的权重文件启动脚本时才发现 CUDA out of memory。Local LLM Hardware Calc 要解决的就是这个问题在下载和部署之前根据模型参数量、加载精度、上下文长度和推理框架估算出接近真实的显存、内存和磁盘需求。这个方向很适合做成一个 Python CLI 工具也可以扩展成 Web 页面输入几个参数就能得到硬件需求报告。下面的实现不依赖任何云平台也不需要 GPU 环境只要机器能跑 Python 3.9就能复现整个估算器。你会拿到一个可运行的 Local LLM Hardware Calc 命令行程序并且清楚 12GB 显存、24GB 显存分别能跑什么规模的模型。1. 先理解本地 LLM 的显存消耗分三块很多人在估算本地大模型硬件时只查了一个“模型大小”。比如看到 7B 模型下载文件是 14GB就觉得 24GB 显存的显卡一定能跑。这个判断错在只考虑了权重没有考虑 KV Cache 和框架开销。本地 LLM 推理时的显存消耗大致分三块模型权重、KV Cache、推理框架运行时开销。三者的量级不同增减趋势也不同必须分开计算。1.1 模型权重所有参数都要加载到显存或内存模型权重是最大、最稳定的一块。参数量确定后权重体积主要由加载精度决定。权重体积的计算公式是权重体积GB 参数量 × 每参数占用字节数例如一个 7B 模型按 FP16 加载每个参数占 2 字节7,000,000,000 × 2 14,000,000,000 字节 ≈ 14 GB如果按 INT4 量化加载每个参数约占 0.5 字节同一模型的理论权重体积就变成7,000,000,000 × 0.5 3,500,000,000 字节 ≈ 3.5 GB这就是为什么同样的 7B 模型量化后能放进 12GB 显存FP16 版本却经常 OOM。权重体积是判断硬件能不能跑模型的第一道门槛。这里要注意本地模型的参数量经常不是整数。很多标称 7B 的模型实际参数是 6.74B标称 13B 的模型实际是 13.1B 或 13.5B。条件允许时尽量从 Hugging Face 的 config.json 或模型卡里读真实总参数量而不是只看名字。1.2 KV Cache上下文越长缓存越大Transformer 生成文本时每个 token 都会读取之前所有 token 的 Key 和 Value 缓存。这些缓存需要连续保存在显存或内存里被称为 KV Cache。KV Cache 有两个明显特征随上下文长度线性增长。上下文从 2048 涨到 8192KV Cache 也会放大到原来的 4 倍因为“每个位置都要保存一份 K 和 V”。和模型层数、注意力头数、Head Dim 强相关。模型越深、注意力头越多单 token 的 KV Cache 越大。举一个例子。一个 7B 模型有 32 层32 个 KV HeadHead Dim 是 128KV Cache 使用 FP16 保存时单 token KV Cache 2 × 32 × 32 × 128 × 2 字节 524,288 字节 ≈ 0.5 MiB当上下文长度为 4096 时0.5 MiB × 4096 ≈ 2048 MiB ≈ 2.15 GB所以即使权重体积很小如果给模型配一个 32K 的上下文KV Cache 也会迅速吃满显存。RAG 和 Agent 类应用尤其要注意这一点因为它们的 prompt 往往很长KV Cache 不是可忽略的边角料。1.3 框架开销不是所有显存都能填预测值估算公式算出来的是“理论占用”实际启动推理时显存占用还会更高。常见原因包括CUDA context 会占用一部分显存不同驱动和容器环境差异明显。PyTorch 的缓存分配器会提前申请显存块即使未使用也会在 nvidia-smi 里显示为已占用。vLLM 的 PagedAttention 会按页一次性分配显存不是只用实际 tokens 对应的精确 KV 大小。部分框架为了快速推理会提前创建 CUDA Graph额外占用一块固定显存。因此估算时不能只算权重和 KV Cache还要加一个“框架开销”项。常见做法是按权重体积的一定比例预留同时在最终总量里再保留一些余量。2. 估算公式所有权重、KV Cache 和框架开销的计算基础Local LLM Hardware Calc 的核心不是调用现成 API而是把显存估算拆成几个确定性公式。这部分逻辑写清楚后后面实现 CLI 就只是把公式翻译成代码。