实用工具
结果
结果会显示在这里。一个模型能不能在你的显卡上跑起来，取决于三个数：量化后的权重、随上下文长度增长的 KV 缓存，以及推理框架自身的缓冲区。这个计算器针对 24 个常见开源权重模型——Llama、Qwen、DeepSeek-R1 蒸馏版、Mistral、Gemma、Phi——在任意 GGUF 量化、上下文长度和并发数下算出这三项，算法与 llama.cpp（ggml-org/llama.cpp，MIT）以及基于它的 Ollama、LM Studio 分配显存的方式一致。模型结构参数读自各模型在 Hugging Face 上的 config.json。
它是怎么工作的
- 权重 = 参数量 × 该量化的实际每权重比特数，取自 llama.cpp 的 quantize 工具列出的文件大小：Q4_K_M 平均 4.9 比特而不是 4 比特，因为 K 量化会把部分张量保留在更高精度。
- KV 缓存 = 2 × 层数 × KV 头数 × 头维度 × 缓存的 Token 数 × 每个元素的字节数，所以分组查询注意力、缓存类型和上下文长度都会反映在结果里。Gemma 2 和 3 的滑动窗口层只缓存窗口内的内容。
- 运行开销是 CUDA 或 Metal 上下文的 0.5 GB，加上按 llama.cpp 默认 512 Token 微批次计算的计算缓冲区，这也是词表大的模型更占显存的原因。
- 显卡列表中占用低于 90% 标 ✓，90%–100% 标 ≈，装不下标 ✗ ×N，N 是拆分模型需要的同型号显卡数量；Mac 按统一内存的约四分之三计算，这是 macOS 默认允许 GPU 使用的比例。
你的数据去了哪里
哪也没去。本工具完全在你的浏览器里运行：你粘贴的文本由页面处理，不会传输到任何服务器，也不会写进任何日志。
本工具免费且无需登录，运行结果只存在于你当前的页面里，不会被保存到任何地方。
它要花多少
本工具完全免费，不需要登录，也不消耗积分。
常见问题
- 估算有多准？
- 单卡、全部层卸载到 GPU 的情况下，权重和 KV 缓存与 llama.cpp 实际分配的相差不超过几个百分点：Llama 3.1 8B、Q4_K_M、8,192 上下文时，工具给出权重 4.58 GiB、KV 缓存正好 1 GiB，与 llama.cpp 报告的数字一致。实际使用请为驱动、桌面和其他程序预留 5%–10% 的余量。
- “并发序列”是什么意思？和 Ollama 的上下文是什么关系？
- 指服务端同时容纳多少个会话，每个会话有自己的 KV 缓存：Ollama 里是 OLLAMA_NUM_PARALLEL，llama-server 里是 -np。上下文一栏按单个序列填写，所以 8,192 × 4 会缓存 32,768 个 Token，换成 llama-server 的参数就是 -c 32768 -np 4。
- 要不要量化 KV 缓存？
- q8_0 能把缓存减半，损失几乎测不出来，长上下文时很划算；q4_0 只剩四分之一，但可能明显影响质量。在 llama.cpp 里，量化 V 缓存需要开启 Flash Attention，支持的显卡上会自动开启；本估算默认全程使用 Flash Attention。
- 为什么会提示超出原生上下文？
- 每个模型都只训练到一定长度——Qwen3 是 40,960 个 Token，Llama 3.1 是 131,072。超过之后显存估算依然成立，但模型需要 YaRN 之类的 RoPE 缩放才能正常工作，质量通常也会下降，所以工具会在你超出时提醒。
背后的开源项目
本工具是独立实现，并未打包第三方库。ggml-org/llama.cpp（MIT）在代码层面做的是同一件事——如果你需要在自己的程序里实现它，从那里开始，而不是调用一个网页。
ggml-org/llama.cpp也常被称作
- 显存计算器
- 大模型显存需求
- 本地部署 显存
- gguf 显存
- kv cache 计算
- ollama 显存
- llm vram calculator