如果你想在本地跑一个 LLM又不想买完显卡以后才拍大腿机器到底该配多大显存、多少内存这个问题其实有一个很实用的工具可以帮你提前算清楚本地 LLM 硬件需求计算器。它的核心价值不是推荐某个固定配置而是你只要输入参数量、精度、上下文长度、并发请求这些变量就能估算出最低需要的显存和内存。特别适合正在选显卡、准备自建本地推理服务或者想用旧电脑跑小模型的场景。我也确实看过作为 Show HN 项目出现的同类型工具。这篇文章不是替某个具体工具做广告而是把这类硬件需求计算器背后的估算逻辑完整拆一遍。看懂以后即使你手边没有任何现成计算器用一张纸也能算个大概更重要的是你会知道哪些变量最容易把预算带偏。1. 先看懂“本地 LLM 硬件需求计算器”到底在算什么1.1 本地 LLM 的部署门槛不是只看模型文件大小很多人第一次碰本地大模型习惯先看模型文件大小。比如下载一个 4GB 的模型文件就觉得 8GB 显存肯定够。这个判断很容易翻车。原因很简单模型文件代表的是模型权重也就是静态参数这只是整个估算的起点。推理过程中框架还需要存储临时中间激活值、KV 缓存以及加载 CUDA 上下文和计算图这些都会继续占用显存。也就是说模型文件 4GB 时运行态显存很可能是 6GB 到 8GB甚至更高。所以第一件要纠正的事情是不要用“模型文件大小”当作硬件需求。要用“权重大小 KV 缓存 运行时开销”三层加起来才算完整的显存需求。这正好是硬件需求计算器要解决的核心问题。你输入模型规模和推理参数它把三层开销列出来让你大致知道这台机器能不能承载目标任务。1.2 计算器输入什么、输出什么以及为什么变量越全越有参考价值一个相对完整的本地 LLM 硬件估算通常需要这些输入模型参数量比如 7B、13B、70B。量化精度比如 FP16、INT8、INT4 或 BF16。上下文长度比如 2048、8192、32768。单次请求的最大输出 token 数。并发请求数量通常在做服务化部署时需要。GPU 型号或显存大小、内存大小用来判断是否放得下。输出则分成几个关键指标权重占用的显存、KV 缓存占用、预估总显存、预估内存以及剩余空间是否够用。变量越全参考价值越高。你只输入模型参数量得到的数字是最大口径再加精度数字会具体很多再加上下文和并发才能匹配真实使用。这里我想强调一个经验判断如果你拿计算器算完发现“刚好够”那实际部署时大概率会紧张。因为真实使用中还有后台任务、浏览器、显卡驱动、推理引擎的临时缓冲不可能做到计算器上的精确值。一般建议在估算结果上再留 20% 到 30% 余量尤其显存这种不可扩展的资源。注意如果算出来是“勉强放下模型”不要直接按这个配置去买机器。结合你自己的任务习惯把上下文长度、并发数收敛后再重新估算一次得到的结论才值得参考。2. 把公式手推一遍权重、KV 缓存、运行时开销各占多少2.1 模型权重参数量与精度的乘法关系模型权重的估算公式很简单参数量乘以每个参数占用的字节数。一个参数在 FP32 下占 4 字节FP16 或 BF16 下占 2 字节INT8 下占 1 字节INT4 下占 0.5 字节。常见组合可以用一张表说清楚参数精度每参数字节数7B 权重估算13B 权重估算70B 权重估算FP324 字节约 28GB约 52GB约 280GBFP16 / BF162 字节约 14GB约 26GB约 140GBINT81 字节约 7GB约 13GB约 70GBINT40.5 字节约 3.5GB约 6.5GB约 35GB实际量化打包后文件还要包含 embedding 和少量元数据所以 INT4 的稳定数值通常会高于表里直接乘出来的理论值。7B 模型使用 Q4 量化后常见文件大约 4GB 出头13B 大约 8GB 上下70B 大约 40GB 向上。这些数值是常见情况不同量化方式会有几 GB 差异落地时以模型仓库的实际文件为准。精度不仅影响效果还直接影响能不能把权重放进显存。你在硬件需求计算器里改一个精度选项结果差别可能接近一倍。这也是很多本地推理用户宁可接受 INT4 量化也要把模型塞进中端显卡的原因。2.2 KV 缓存上下文越长占的显存越容易被低估权重之后第二块较大的开销是 KV 缓存也就是推理过程中用来缓存历史 Key 和 Value 的临时数据。KV 缓存大小和模型结构、上下文长度强相关。粗略来看上下文长度翻倍KV 缓存就可能翻倍模型层数和注意力头数越多单个 token 的缓存也越大。在常见 7B 到 13B 模型上4K 上下文的 KV 缓存大约占用 1GB 到 3GB 不等如果开到 32K 甚至更长上下文这部分可以达到 8GB 甚至更高具体看模型是否使用 GQA、是否做分组注意力。70B 级别或层数更深的模型KV 缓存增长更快几十 GB 并不夸张。这也解释了为什么会看到很多报错场景模型明明只有 4GB显存也够 8GB但一开长上下文就 OOM。因为 KV 缓存没算进去。做知识库 RAG、Agent 多轮对话、长文档分析时上下文长度很容易冲到几千上万 token这部分内存绝不能忽略。2.3 显存预留CUDA 上下文、激活、并发输出都要占地方最后还有一块属于运行态开销包括推理框架加载的计算图、中间激活值、CUDA context、临时张量以及并发请求共享时产生的额外缓冲。这块没有固定值通常根据框架和模型规模影响 1GB 到 4GB 左右。小模型小框架可能 1GB 多就够大模型、长输出、并发推理时开销会明显上升。如果你的计算器只算权重和 KV 缓存没有留运行开销结果就是偏乐观。完整估算公式可以写成预计显存占用 模型权重大小 KV 缓存大小 运行态开销 余量举个例子。7B 模型FP16 的话权重约 14GB2K 上下文 KV 缓存按 1GB 到 2GB 算运行态留 1GB 到 2GB总需求在 17GB 左右。所以单卡 16GB 会比较紧张20GB 以上更稳妥。如果改用 INT4 量化权重降到 4GB 出头同样条件下总需求大约在 7GB 到 9GB8GB 显存就能试但长上下文时要谨慎。3. 用 7B、13B、70B 三档模型对号入座看配置3.1 7B 档位入门学习、Agent 原型、轻量 API 服务7B 模型是目前本地部署最常被尝试的档位非常适合验证流程跑通 Ollama、理解 API 调用、做 Agent 原型、接入 RAG 做小型知识库。如果只是做功能验证INT4 量化后 8GB 显存已经有机会启动显存 12GB 会更宽裕适合同时跑长上下文或多个请求。CPU 方案至少要 16GB 内存32GB 会更稳但速度仍会受限于内存带宽。如果你还要在同一台机器上同时跑 ComfyUI 或其他图像生成工具那么 LLM 单独算出来的数字不能直接采信两套任务会争抢同一块显存。这种情况要么把 LLM 调小要么用 API 服务把任务分到不同机器不然很容易出现其中一个任务中途被杀。3.2 13B 档位代码补全、知识库 RAG、长文档处理13B 模型通常比 7B 更聪明在处理代码、长文本、复杂指令时优势明显但硬件门槛也上了一个台阶。INT4 量化后权重约 8GB 到 9GB再加上上下文和运行态12GB 显存可以尝试想稳定一点建议 16GB 到 24GB。如果长期跑 16K 以上长上下文显存 24GB 更合理。这个档位也是很多人的纠结点7B 太快但质量一般13B 质量好一点但显卡价格明显上升。我的思路是先确认自己的核心任务是不是真的需要更强的语言理解。如果只是对话模板、简单抽取7B 完全够如果是代码补全或长文档知识库13B 值得多花预算。对纯 CPU 用户13B INT4 量化后内存需求约 16GB 以上但实际跑起来建议 32GB 内存否则加载完系统就开始频繁交换整个机器都会卡。3.3 70B 档位高质量对话和并发服务先别只算权重70B 模型基本进入个人工作站的边界。INT4 量化后权重就有 40GB 上下加上 KV 缓存和运行态单卡 48GB 是起步想跑长上下文或者多人并发80GB 以上的设备更稳妥。如果只有普通消费卡也不是完全不能跑可以靠 CPU 卸载、多卡张量并行或直接把部分层压缩到内存。但这种模式在推理速度上下降明显适合能接受等待的场景不适合作为并发服务。这里特别提醒一个误区不要因为 Ollama 能自动调度 GPU 和 CPU 混合内存就认为任何机器都能凑合跑大模型。能加载不意味着能接受速度70B 级别在不平衡配置上的速度可能连处理简单聊天都要好几秒甚至更久。生产环境一定要看吞吐和延迟指标而不是“能回复”就行。4. 换到不同硬件平台计算器的结论要再修正一版4.1 Nvidia GPU 方案显存够还要看带宽和推理引擎Nvidia GPU 是本地 LLM 调试最省心的平台。除了显存大小还要看显存带宽和推理引擎。用 RTX 4060 和 A6000 比显存分别是 8GB 和 48GB但速度差异还来自带宽、Tensor Core、驱动和引擎支持。使用 vLLM、TensorRT-LLM 等推理引擎时量化格式、batch 策略、PagedAttention 都会影响吞吐。计算器只帮你判断硬件需求大概落在哪个区间真正能跑多快还需要一轮小型压力测试。对新手来说选 Nvidia 卡时优先保证显存比估算结果多 20%这样后续调整上下文和量化空间还有余量。4.2 Mac 统一内存方案能跑不代表不换盘内存大小才是第一指标如果你用的是 Mac情况不同。Apple Silicon 的内存是 CPU 与 GPU 共享显存不再单独划分所以跑 LLM 时重点看总内存比如 16GB、32GB、64GB。这类机器能不能跑某个模型判断标准也是“模型权重 KV 缓存 系统占用”是否小于内存。系统本身和后台应用通常还会占用 4GB 到 8GB所以 16GB 内存的 M 系列 Mac能比较流畅跑的是 7B INT4跑到 13B INT4 时整体内存已经很紧张再开浏览器和 IDE 就会明显吃力。很多人在 Mac 上跑 LLM会先试 llama.cpp 家族和 Ollama再结合 MLX 等原生框架。不同推理引擎的调度方式和量化支持不一样同一个模型在不同工具里表现差别不小。如果你经常在 Mac 上做本地推理建议每换一个引擎都用同一个长任务测一下速度和内存占用而不是只看启动成功。4.3 纯 CPU 方案能加载和能推理是两件事纯 CPU 方案看着门槛最低内存够大似乎就能跑。实际瓶颈在内存带宽和 CPU 算力。同一个 7B INT4 模型在高带宽内存的服务器 CPU 上可能跑出能接受的 token 速度在普通笔记本上可能只有几个 token 每秒。如果只是做离线批量任务、对延迟不敏感纯 CPU 能接受但如果要做交互式对话、代码补全这种需要等待反馈的场景CPU 方案体验很差。所以当计算器告诉你“内存够用”不要急着下结论还要看机器的内存通道数和带宽。单位时间能搬运多少 token才是 CPU 推理的真正限制。5. 按计算结果配好机器还是慢或报错按这套顺序排查5.1 上线前先跑三个冒烟测试短上下文、单请求、小并发不管计算器算得多合理落地之后都要先做冒烟测试。我的建议分三层推进先跑一个短上下文、单请求确认模型能启动、输出结构正常。再跑一个长上下文或长输出确认 KV 缓存和显存余量是否足够。最后做小并发测试模拟实际业务状态。每一步都要记录两个指标单个请求的延迟和整体资源占用。卡住、OOM、半路断掉都要先看日志再改参数。低配置机器尤其要遵守这个顺序。不要一上来就开最大并发正常情况下可能直接把人机交互通道挤爆。5.2 遇到 OOM 或速度不达标按优先级调整参数当出现显存不够或速度不达标时不要盲目怀疑模型文件损坏。通常按这个顺序调整降低上下文长度先恢复稳定性。降低并发数或 batch 大小让每次请求占用的临时缓存更少。换更低精度的量化比如从 INT8 降到 INT4。关闭其他占显存的应用比如 ComfyUI、浏览器硬件加速。再确认推理引擎和 CUDA 版本是否匹配。前两步最容易见效也最不影响模型质量。很多情况下真正的问题不是模型精度太低而是上下文长度和并发数量超过硬件余量。排查时最容易被忽略的是“其他进程占用了显存”。你可以通过 nvidia-smi 先看显存占用如果已经有别人或别的服务占了几 GB那么本地 LLM 的可用空间就比估算值小得多。5.3 长期本地部署的额外准备磁盘、模型目录、日志和任务队列配置通过验证阶段后后面要考虑的就不是“能不能跑”而是“好不好长期跑”。磁盘需要给模型仓库、缓存、日志预留足够空间。一个 7B 模型即使只有 4GB 权重实际下载时可能需要双份临时空间磁盘剩余太少会导致加载失败。目录结构建议固定例如把模型权重放在统一目录下载工具缓存和日志分开方便后面换版本和排查。批量任务场景下一定要设计好输出文件命名和失败重试机制不然任务一多日志和结果就混乱了。如果你准备把本地推理服务化再补上 API 超时、请求队列、健康检查这些内容。硬件计算器只能告诉你“放不放得下”但这些工程性问题决定它能不能在真实业务里稳定运行。6. 如果我想自己写一个硬件估算脚本核心逻辑怎么落地6.1 一个最简估算函数如果你不满足于用现成计算器完全可以自己写一个小脚本。核心逻辑就是前面说的公式权重、KV 缓存、运行态、余量。def estimate_llm_memory( params_b: float 7, bits: int 4, context_tokens: int 4096, kv_cache_mb_per_1k: float 500, runtime_gb: float 2.0, reserve_ratio: float 0.2, ): # 权重参数量 * 每参数字节数 weight_gb params_b * 1e9 * (bits / 8) / 1e9 # KV 缓存随上下文长度变化需要按模型结构调整 kv_gb kv_cache_mb_per_1k / 1024 * context_tokens / 1024 total weight_gb kv_gb runtime_gb return total * (1 reserve_ratio) print(estimate_llm_memory())我给的kv_cache_mb_per_1k是一个很粗的默认值。真实使用中不同模型的隐藏层大小、层数、是否使用 GQA都会让 KV 缓存差出几倍。所以脚本只能作为快速筛选不能代替实际加载后的观察。6.2 输入参数校验和输出格式化很重要自己写估算工具时最值得注意的不是公式而是输入校验。参数量如果是负数、精度填了不支持的类型、上下文长度填了 0都会导致计算结果完全没意义。比较实用的做法是做一个参数白名单精度只允许 FP32、FP16、BF16、INT8、INT4上下文长度限制在合理范围内。输出格式建议同时提供 Markdown 表格和 JSON方便在终端里看也方便接脚本。if bits not in (32, 16, 8, 4): raise ValueError(bits must be 32, 16, 8, or 4)这个习惯在写工具时很小但能避免你或用户拿着错误数字去配机器。6.3 更进一步从模型配置里读取真实参数如果你想做一个更好用的工具可以不用让用户手动填参数量而是给定模型目录然后读取模型配置文件里的num_hidden_layers、hidden_size、num_key_value_heads、vocab_size等字段自动计算出更准确的 KV 缓存。这种做法的优点是很贴近真实模型不用靠经验值猜。代价是要处理不同的模型格式。Hugging Face 格式、GGUF 格式、不同框架的配置字段不完全一样需要写兼容层。对个人项目来说先做成手动输入参数的小工具已经很够用。等用户量多了再考虑自动解析模型路径、读取模型信息。这个路径比较稳不会一上来就把时间耗在兼容性上。任何时候计算器给出的数字都只是“估算”不是“保证”。当你把工具从开发机挪到生产环境或者把模型换了一个量化版本都要重新跑一次小样本测试。这样即使估算偏差也不会在真实任务里临时翻车。最后说一点实际感受本地 LLM 硬件需求计算器有没有用有用但前提是别把它的输出当作终点。把它当成第一次估算的起点输入尽量贴近真实使用习惯算出基础值后留出余量再用三轮冒烟测试验证这条路比盲目买大显存卡更省钱也比纯靠感觉配机器更靠谱。真正碰过几次之后你会发现很多本地推理问题不是模型能力不够而是前置资源和输入条件没有排清楚。硬件计算器解决的是“排清楚”的第一步后面还要靠日志、资源监控和任务规划来兜底。尤其是做 Agent、RAG、长对话这类场景权重占多少已经不重要了KV 缓存和上下文策略才是决定体验的关键。