看到“Show HN: Hardware requirement calculator for local LLMs”这个标题很多人的第一反应可能是“又一个算显存的脚本有什么稀奇的”但真正在本地折腾过大模型的人会明白这个需求远没有看上去那么简单。很多朋友第一次部署本地大模型时都做过类似的事打开一个 8B 模型的页面看到模型文件有 4.7GB以为自己 8GB 显存的显卡稳了结果一跑推理直接 OOM或者生成速度慢到让人怀疑人生。问题出在哪你只看到了权重文件的大小却没有把 KV Cache、推理引擎开销、上下文长度、并发请求算进去。这篇文章要解决的正是这个问题本地 LLM 的硬件需求到底怎么算硬件需求计算器的核心原理是什么更重要的是我不仅会讲清楚这个工具背后的估算逻辑还会给出一个可以直接运行的 Python 估算脚本让你脱离任何在线服务自己也能算出“我到底需要多大的显存和内存”。读完这篇文章你会得到三样东西一套完整的本地 LLM 硬件需求估算公式以后看到任何开源模型心理先有底一个可复制、可运行、可改参数的 Python 估算脚本适合作为本地工具长期使用一份部署层面的避坑清单告诉你在消费级显卡上跑模型最容易错估的变量是什么。本地化部署不是铁板一块的黑盒它的硬件需求完全可以用公式拆开算。只是大多数人没耐心拆于是被各种玄学说法带着走。1. 本地 LLM 部署到底难在哪里先抛一个判断本地 LLM 部署的核心瓶颈90% 的情况下不是算力而是显存容量和内存带宽。很多人以为跑大模型费 GPU是因为要算很久但其实单次推理的延迟在消费级显卡上是可以接受的。真正挡住你的是“装不装得下”的问题。一个 7B 或 8B 参数的模型FP16 精度下权重文件就需要约 14~16GB 显存。而很多消费级显卡比如 RTX 4060 Ti 16GB、RTX 4070 Ti Super 16GB显存刚好卡在这个线附近。如果你再开一个较长的上下文窗口或者同时跑多个请求显存立刻不足。更要命的是 CPU 方案。如果你打算纯用 CPU 推理比如用 llama.cpp 在 Mac 或服务器上跑那么内存带宽直接决定生成速度。同样是 70B 模型在 DDR4 和 DDR5 上跑速度差距可能接近一倍。所以本地 LLM 的硬件需求不是一个“能不能跑”的判断题而是一个“在什么条件下能跑多快、能跑多长上下文”的评估题。硬件需求计算器这类工具的价值就是把这个评估过程自动化让你在买卡、组机器、配服务器之前先知道答案。但这里有一个关键提醒计算器给出的永远是估算值不是精确值。它解决的是“下订单之前”的问题不能替代“下单之后”的真实测试。2. 硬件估算的核心公式显存 权重 KV Cache 开销要理解硬件计算器的工作原理先要记住一条基础公式。无论是哪个网站或项目只要是在做本地 LLM 硬件估算本质上都在算下面这条公式显存需求 ≈ 模型权重内存 KV Cache 内存 推理运行时开销这条公式适用于 GPU 推理也适用于 CPU 方案只不过在 CPU 场景下“显存”要换成“内存”。2.1 模型权重内存怎么算模型权重内存是最容易算的部分公式如下权重内存GB 模型参数量B× 每参数字节数 / 1024^3这里的“每参数字节数”由精度决定。精度类型常用场景每参数字节数FP32几乎不用在推理主要用于训练4 字节FP16完整精度推理质量最高2 字节BF16训练和推理均可动态范围大2 字节INT8量化推理质量损失较小1 字节INT4量化推理显存需求最低约 0.5 字节以 8B 模型为例FP16 / BF168 × 2 16GBINT88 × 1 8GBINT48 × 0.5 4GB这就是为什么同一个 8B 模型有的教程告诉你需要 16GB 显存有的说 8GB 就行还有的说 4GB 也能跑。不是有人在撒谎而是他们用的精度不同。2.2 KV Cache 是隐藏的显存大户模型权重只是故事的开始。Transformer 模型在推理时需要把已生成的 token 对应的 Key 和 Value 缓存下来避免重复计算。这个缓存在长上下文场景下非常占显存。KV Cache 的内存占用与以下因素相关模型层数L注意力头数A每个头的维度D上下文长度S批次大小B即并发请求数每参数字节数P简化估算公式如下KV Cache 内存 ≈ 2 × L × A × D × S × B × P公式里的系数 2 来自 Key 和 Value 两份缓存。这里的 L × A × D 乘起来其实是模型隐藏层维度的两倍很多估算器会直接使用“隐藏层维度 × 层数 × 2”来算。举个例子一个 8B 模型的隐藏层维度通常是 4096层数 32 层如果精度是 FP162 字节上下文长度 8192并发 1KV Cache ≈ 2 × 4096 × 32 × 8192 × 1 × 2 字节 ≈ 4,294,967,296 字节 ≈ 4GB也就是说这个 8B 模型仅 KV Cache 就需要约 4GB。再加上 16GB 的权重总需求已经超过 20GB。这还不是最极端的。如果你把上下文长度拉到 32KKV Cache 会变成约 16GB总需求突破 32GB。很多人觉得自己 24GB 显存的显卡“够用”一跑长文本就 OOM就是因为只算了权重没算 KV Cache。2.3 运行时开销容易被忽略的 1~2GB除了权重和 KV Cache推理框架本身还要占用显存包括 CUDA context、激活值、临时缓冲区等。这个开销因框架而异PyTorch 方案通常偏高llama.cpp 这类优化过的 C 实现可以压得比较低。保守估算时建议预留 1~2GB 的运行时开销。如果你的推理引擎用了 CUDA Graph、FlashAttention 等优化实际开销可能有差异但预留空间永远比精打细算安全。所以完整的显存估算公式可以写成显存需求GB≈ 权重内存 KV Cache 内存 1~2GB 运行时开销3. 影响硬件需求的 6 个关键变量看懂了核心公式再来看那些会让计算结果“漂移”的变量。一个合格的硬件需求计算器应该覆盖下面这些变量如果一个计算器只有参数量输入框那它大概率不靠谱。3.1 精度与量化等级这是影响权重内存最大的单一变量。从 FP16 切到 INT4权重内存直接降为原来的四分之一。但量化不是免费的INT4 在极少场景下可能出现输出质量下降尤其在数学推理、代码生成等任务上会更敏感。实际项目中GGUF 格式的 Q4_K_M、Q5_K_M 是消费级显卡的常用选择质量与显存占用相对均衡。3.2 上下文长度KV Cache 与上下文长度近似线性关系。上下文翻一倍KV Cache 翻一倍。很多人买显卡时只看模型规模不看上下文需求这是一个非常典型的误区。3.3 并发请求数如果你是给团队搭一个本地服务而不是自己一个人用并发数必须算进去。KV Cache 的内存占用会随着并发请求数成倍增长。换句话说同一个模型一个人用和 8 个人同时用硬件需求可能相差 2~3 倍。3.4 推理引擎与部署方式同样一个模型用 Ollama、llama.cpp、vLLM、Transformers 跑显存占用和吞吐表现都不一样。vLLM 等专业推理引擎有 PagedAttention 机制KV Cache 管理更高效可以支持更大的并发Transformers 库最直接但显存占用偏高llama.cpp / Ollama 在 CPU 和 GPU 混合推断方面有优势显存不够时可以分层卸载到内存。这也是为什么网上有人说“8G 显存就能跑 14B 模型”另一个人说“18G 都不够”。他们可能用了不同的推理引擎、不同的量化等级、不同的上下文长度。3.5 CPU 与内存带宽如果你没有 NVIDIA 显卡或者显存不够CPU 推理也是一个选项。但 CPU 推理的瓶颈几乎完全在内存带宽上。举个例子核心数量相同的两颗 CPU如果内存一个跑在 3200MHz一个跑在 5600MHz跑大模型的 token 生成速度会明显不同。估算 CPU 推理速度的粗略公式如下内存带宽吞吐GB/s÷ 模型权重内存GB≈ 每秒能生成的 token 数这个公式高度简化但方向是对的。你的内存带宽 50GB/s模型权重 4GB理论上限就是 12 token/s 左右。实际还要算上计算损耗、缓存缺失、内存延迟等因素通常只能达到理论值的 60%~80%。3.6 显存带宽 vs 显存容量最后补一个容易被搞混的点显存容量决定“能不能装下”显存带宽决定“跑多快”。RTX 4060 Ti 16GB 和 RTX 3090 24GB 的容量不同但在某些小型模型上的生成速度RTX 4060 Ti 未必比 RTX 3090 快多少甚至可能更慢因为显存带宽差距不小。所以在选择硬件时要同时考虑容量和带宽不能只看“显存大就是好”。4. 自己写一个硬件估算脚本Python 实现网上已经有了一些硬件计算器工具但在实际使用中我发现很多工具的可解释性不够强——它给你一个数字却不告诉你这个数字是怎么来的。这里我提供一个可以自己运行的 Python 脚本。一方面你可以根据它理解硬件需求计算器的内部逻辑另一方面它可以直接成为你本地的选型工具。脚本估算的核心逻辑正是上面第 2 节的三部分求和权重内存、KV Cache 内存、运行时开销。# 文件路径llm_hardware_estimator.py # 本地 LLM 硬件需求估算脚本 # 运行环境Python 3.8 def gb_from_bytes(byte_size: int) - float: 将字节数转换为 GB。 return byte_size / (1024 ** 3) def estimate_weight_memory(num_params_b: float, bytes_per_param: float) - float: 估算模型权重内存。 :param num_params_b: 模型参数量单位 B十亿例如 7B、8B、14B :param bytes_per_param: 每参数占用的字节数由精度决定 :return: 权重内存单位 GB return num_params_b * bytes_per_param def estimate_kv_cache_memory( hidden_dim: int, num_layers: int, context_length: int, batch_size: int 1, bytes_per_param: float 2.0, ) - float: 估算 KV Cache 占用的显存/内存。 对大多数 Transformer 模型而言总 KV 参数量约为 2Key Value× num_layers × hidden_dim × context_length × batch_size :param hidden_dim: 模型隐藏层维度 :param num_layers: Transformer 层数 :param context_length: 上下文长度seq_len :param batch_size: 并发请求数 :param bytes_per_param: 精度字节数默认 FP16/BF16 :return: KV Cache 内存单位 GB total_kv_params 2 * num_layers * hidden_dim * context_length * batch_size return gb_from_bytes(total_kv_params * bytes_per_param) def estimate_total_memory( num_params_b: float, hidden_dim: int, num_layers: int, context_length: int, precision: str fp16, batch_size: int 1, runtime_overhead_gb: float 1.5, ) - dict: 综合估算本地 LLM 部署所需的显存/内存。 :param precision: 支持 fp32/fp16/bf16/int8/int4 :param runtime_overhead_gb: 运行时框架额外占用的显存/内存 precision_bytes { fp32: 4.0, fp16: 2.0, bf16: 2.0, int8: 1.0, int4: 0.5, } if precision.lower() not in precision_bytes: raise ValueError(f不支持的精度类型{precision}可选{list(precision_bytes.keys())}) bpp precision_bytes[precision.lower()] weight_mem estimate_weight_memory(num_params_b, bpp) kv_mem estimate_kv_cache_memory( hidden_dimhidden_dim, num_layersnum_layers, context_lengthcontext_length, batch_sizebatch_size, bytes_per_parambpp, ) total_mem weight_mem kv_mem runtime_overhead_gb return { model: f{num_params_b}B, precision: precision.upper(), context_length: context_length, batch_size: batch_size, weight_gb: round(weight_mem, 2), kv_cache_gb: round(kv_mem, 2), runtime_overhead_gb: runtime_overhead_gb, total_gb: round(total_mem, 2), suggested_vram: round(total_mem 2, 2), # 额外 2GB 余量给系统和其他进程 } if __name__ __main__: # 示例 18B 模型FP168K 上下文 result1 estimate_total_memory( num_params_b8, hidden_dim4096, num_layers32, context_length8192, precisionfp16, batch_size1, ) print(示例 18B-FP168K 上下文) for k, v in result1.items(): print(f {k}: {v}) # 示例 28B 模型INT4 量化为 GGUF 后半精度8K 上下文 result2 estimate_total_memory( num_params_b8, hidden_dim4096, num_layers32, context_length8192, precisionint4, batch_size1, ) print(示例 28B-INT48K 上下文) for k, v in result2.items(): print(f {k}: {v}) # 示例 314B 模型INT416K 上下文并发 4 result3 estimate_total_memory( num_params_b14, hidden_dim5120, num_layers40, context_length16384, precisionint4, batch_size4, ) print(示例 314B-INT416K 上下文并发 4) for k, v in result3.items(): print(f {k}: {v})运行方式python llm_hardware_estimator.py预期会输出类似下面的内容实际数字取决于模型配置示例 18B-FP168K 上下文 model: 8B precision: FP16 context_length: 8192 batch_size: 1 weight_gb: 16.0 kv_cache_gb: 4.0 runtime_overhead_gb: 1.5 total_gb: 21.5 suggested_vram: 23.5这里要特别说明hidden_dim 和 num_layers 需要你去查具体模型的 config.json。不同的 8B 模型隐藏层维度和层数并不相同KV Cache 的估算也会因此有差异。这个脚本特意设计成了“透明”的每一步结果都打印出来你可以清楚看到权重占了多少、KV Cache 占了多少、运行时开销占了多少。这也正是本地 LLM 硬件需求计算器应该有的样子。5. 如何解读计算器输出三类结果的含义当你运行脚本或者使用在线硬件计算器时通常会得到几个关键数字。这里我帮你翻译一下这些数字到底意味着什么。5.1 权重内存决定模型精度的下限如果你的总显存连权重都放不下那基本只能选择量化模型或者换一个更小的模型。这个数字是硬约束。一个 14B 模型如果以 FP16 精度运行仅权重就需要 28GB这已经超过了绝大多数消费级显卡的上限。5.2 总显存需求决定推理过程的稳定性总显存需求尤其是“建议显存”那一栏是对实际部署最直接的参考。但请注意这个数字依然不是铁板一块。如果你使用的是支持显存卸载的推理引擎比如 llama.cpp 的 GPU CPU 混合模式那么即使显存小于总需求也能跑只是速度会下降。5.3 建议显存与余量决定你能轻松跑多久计算机推荐给你的是“加上余量”的数字。这个余量很重要因为系统桌面环境可能占几百 MB 到 1GB 显存CUDA 环境初始化需要一部分显存推理过程中的临时激活值无法被上面的公式完全覆盖如果同时开浏览器或其他应用显存竞争会更严重。所以在处理“上不上这条配置”的问题时建议以“建议显存”为准而不是以理论总需求为准。6. 从估算到选型三个典型场景的硬件建议理论讲完了脚本也有了接下来看三个实际场景。这些建议是方向性的具体卡型的选择取决于你的预算、电源、机箱空间等条件。6.1 场景一个人学习跑 8B 模型典型需求体验本地问答、做 RAG 实验、微调小模型。推荐策略16GB 显存起步。8B 模型 FP16 需要约 16GB 权重16GB 显卡可以勉强跑短上下文更稳妥的做法是使用 GGUF Q4_K_M 量化8GB 显存就能获得不错的速度如果预算有限优先选显存大的卡其次才是算力强的卡。6.2 场景二团队调研跑 14B 模型并支持低并发典型需求多个研发同事同时调用 API跑代码生成或文档分析。推荐策略24GB 显存以上。14B 模型 INT4 量化的权重约 7GB但 KV Cache 在长上下文和并发场景下会迅速膨胀建议使用 vLLM 或 SGLang 等推理框架利用 PagedAttention 优化 KV Cache 内存如果要上 32K 长上下文24GB 显存会比较紧张需要考虑张量并行或升级到 48GB 方案。6.3 场景三生产环境跑 70B 模型典型需求面向业务提供中文问答、知识库助手。推荐策略多卡方案成为必需品。70B 模型即使用 INT4 量化权重也接近 35GBKV Cache 在长上下文下很容易超过 15GB单卡 48GB 是入门配置如果只有 24GB 的单卡可以尝试 CPU GPU 混合推理但 Token 生成速度会明显下降需要评估是否能接受。对于以上三个场景都可以用第 4 节的脚本先行模拟把自己平台的 hidden_dim、num_layers、上下文长度、并发数代入得出数字后再决定买什么配置。7. 常见问题与排查思路在实际使用硬件计算器和部署本地模型时下面这些问题是出现频率最高的。问题现象可能原因排查方式解决方案明明权重文件只有 5GB显存却爆了没有算 KV Cache 和运行时开销用脚本分别计算权重、KV Cache、开销缩短上下文长度、降低并发或使用更激进量化同一个模型不同工具给出的显存结果差异大精度、上下文长度、推理引擎假设不同对比各工具的默认参数以自己的部署方案为准代入真实参数重算显存够但生成速度特别慢内存带宽不足或模型没有完全加载到显存查看 GPU 利用率是否打满检查是否有显存卸载升级更高带宽的显卡或减少 GPU/CPU 混合推理长文档分析时 OOM上下文长度超过预设值KV Cache 膨胀查看推理日志中的 max_seq_len 设置限制最大上下文长度或使用流式处理切分文档多用户并发时频繁 OOM并发请求数过高KV Cache 翻倍增长查看服务端并发配置限制并发数或使用 vLLM 的 PagedAttention脚本提示内存不足但系统内存还有富余脚本同时计算显存和内存用户误以为是单内存需求确认输出字段是显存还是系统内存明确目标设备分别评估很多问题的根源都不是“显卡不够好”而是“没有把部署参数固定下来”。同一个模型在上下文长度 2048 和 32768 两种设定下硬件需求可以差出 10GB 以上。8. 最佳实践与工程建议到这里硬件估算的原理已经讲完了。最后给出一组可以长期使用的实践建议尤其适合已经决定走本地部署路线、但还没有明确硬件配置的读者。8.1 先定参数再算硬件不要先买显卡再想怎么跑模型这个顺序是反的。推荐流程是确定要跑哪个模型确定目标精度和量化等级确定最大上下文长度确定并发请求数用计算器脚本估算总需求再根据需求选择硬件。8.2 给显存余量留足 20%生产环境不是实验环境总显存需求算出后建议额外多留 20% 的余量。一方面是因为实际推理的激活值开销不好精确估计另一方面是给后续部署框架升级留出空间。8.3 量化不是越低越好很多人陷入“量化越低越省显存”的误区。INT4 确实省显存但会带来少量质量损失。对一些严谨任务比如代码补全、数学计算损失可能被放大。建议路线是先试 Q5_K_M观察显存占用和输出质量如果显存不足再降到 Q4_K_M如果质量不达标再考虑是否提升精度或换更大显存的硬件。8.4 优先使用成熟的推理框架如果是一个长期运行的本地服务建议优先选择 vLLM、llama.cpp、Ollama 这类成熟的推理框架而不是自己用 Transformers 写一套推理代码。它们的位置映射、显存管理、并发调度都已经过大规模场景验证。8.5 实际验证前不要全信估算计算器给出的永远只是估算。估算值低时可以让人更有信心估算值高时要当作重要警示。但最终一条路只有一条在目标硬件上跑一次真实的推理任务测一下吞吐和延迟。8.6 为 CPU 方案单独做带宽侦察如果是 CPU 推理别只看核心数重点看内存带宽。可以在目标机器上跑一次大内存带宽测试或者直接运行一个小型 LLM 的量化版本实测 token 生成速度再决定是否值得上更大模型。9. 总结本地 LLM 的硬件需求从来不是一个神秘的黑盒。拆到底就是权重内存加 KV Cache 内存再加运行时开销。任何硬件需求计算器本质上都是在围绕这三个变量做自动测算。希望这篇文章能帮你在选卡、配机、搭服务之前先建立一套可量化的评估方法。建议把第 4 节的脚本保存到本地以后遇到新模型时会很有用也可以结合 Ollama、vLLM 之类的工具边测边校准自己的估算参数。最后提醒一句工具可以给你答案但准确的前提是输入正确的变量。下次看到某个模型标称的参数量时不妨多问一句——它是在什么精度、什么上下文长度、什么并发条件下算出来的如果你在本地部署中遇到过类似的问题欢迎在评论区聊聊你用的是哪款显卡、跑了什么模型、实战结果和估算差了多少。别人的实测数据往往比任何计算公式都更有参考价值。