本地跑大模型，显存到底怎么算？

很多人买了显卡才发现：能开机不代表能干活。作者做工具的初衷很实在——不是为了精确到小数点后几位，而是让你在掏钱之前，看清那些藏在量化级别、上下文长度里的隐性成本。

这个工具解决什么问题

本地部署大语言模型（LLM）有个老大难问题：网上建议都对，但不够用。

"显存越大越好""选英伟达"——这种话没错，可当你真要在几张具体显卡之间做选择，手动对比显存档位、不同量化精度、还要考虑上下文窗口时，这些建议就失效了。

作者的原话是：「我想让这些权衡在买硬件之前就看得见。」

这就是他做 Local AI VRAM Calculator 的直接动机。不是算着玩，是为了避免"技术上能跑，但实际不匹配 workload"的尴尬。

输入什么，输出什么

工具界面很克制。你需要填的：

• 显卡（从网站快照里选，或手动填显存档位）
• 系统内存
• 量化级别
• 上下文长度
• 主要 workload 类型

输出端给三样东西：一个粗略的适配评分、选中显卡的特定备注、以及基于 workload 的模型推荐。

但作者真正花心思的是「估算拆解」——不是甩给你一个总数字，而是把显存占用拆成五项：模型权重、KV 缓存、运行时开销、总显存需求、存储需求。

这样调上下文长度或量化级别时，你能立刻看到哪块在膨胀。作者的经验是：「很多情况下，瓶颈根本不在你预想的地方。」

估算的诚实性

工具对数字的诚实度有明确分级。有些估算基于配置，有些是启发式（heuristic），界面会标注清楚该对哪个结果抱多大信心。

上下文选择器的上限也有讲究：它受限于当前加载进工具的模型元数据。实际可用最大值 = 网站 curated 模型快照 + 你手动导入的公开 Hugging Face 模型。

作者列了一组粗略 guideline，强调这不是铁律，但能帮你避开明显糟糕的配置：

• 7B 模型 + 4-bit 量化 + 4K 上下文 → 约需 6-8GB 显存
• 13B 模型 + 4-bit 量化 + 4K 上下文 → 约需 10-12GB 显存
• 70B 模型 + 4-bit 量化 + 4K 上下文 → 约需 40-48GB 显存

这些数字的用意很明确：让你在动手之前，对"这套配置能不能跑"有个体感。

为什么砍掉了多显卡选项

作者原本做了多 GPU 支持，后来删了。

原因很简单：两张卡的行为不像一块更大的显存池。有些运行时能把工作拆到多设备，但很多 workflow 仍然要求模型主要塞进单张卡。性能还取决于后端支持、互联行为等难以泛化的细节。

他的判断是：单卡估算更诚实。如果一套配置在单卡上说不通，工具不该暗示加张卡就能自动解决。

这件事为什么值得关注

本地 AI 正在从极客玩具变成正经的生产力选项。但硬件采购的决策链条里，信息断层太严重了——厂商给的是峰值算力，社区给的是碎片化经验，中间缺一层"我的具体场景到底需要什么"。

这个工具的价值不在于它算得多准，而在于它把"显存去哪了"这件事可视化。当你能拆开看模型权重占多少、KV 缓存随上下文怎么膨胀、运行时开销有没有被低估，采购决策就从猜变成了算。

作者之前写过用 Tailscale 访问私有 LLM 的实践。那篇文章讲的是"连得上"，这个工具讲的是"跑得动"。两条线合起来，就是本地 AI 从能用到好用的完整拼图。

目前工具还在 Beta，模型快照和导入机制会随社区反馈迭代。但对已经在看显卡的人来说，它至少解决了一个真问题：在掏钱之前，先看清那些藏在参数表里的隐性成本。