LLM VRAM Calculator — Can I Run It?
Estimate how much GPU memory (VRAM) you need to run open-weight LLMs like Kimi K3, DeepSeek R1, Qwen3, or Llama locally. Pick a model, quantization, and context length — the calculator adds up weights, KV cache, and runtime overhead, then shows which GPUs or Macs can fit it. Runs entirely in your browser: no upload, no signup.
2.8T total params · 48B active (MoE) · max 1M context · specs partially estimated
Native format of Kimi K3 / gpt-oss · ~0.53 bytes/param
Estimated memory needed
1.47 TB
Architecture details for this model are estimated — treat results as a ballpark.
Will it fit?
Assumes ~92% of device memory is usable. Multi-GPU counts are for tensor/pipeline parallel serving (vLLM, SGLang); Apple Silicon uses unified memory via llama.cpp or MLX.
使用指南 / 为什么使用此工具 / 常见问题
使用指南
从预设中选择模型（Kimi K3、Kimi K2、DeepSeek V3/R1、GLM-4.5、Qwen3、gpt-oss、Llama 3.x、Gemma 3、Mistral），或自定义参数量。再选择量化方式——FP16、FP8、MXFP4 或 GGUF 量化（如 Q4_K_M）——以及上下文长度。计算器会立即给出所需显存估算，拆分为模型权重、KV 缓存和运行时开销三部分，并附「能不能装下」硬件对照表，覆盖常见显卡（RTX 4090、RTX 5090、A100、H100、H200、B200、MI300X）和统一内存的 Apple Silicon Mac。全部在浏览器本地计算，不上传任何数据。
为什么使用此工具
每一次开源权重模型发布，都会带来同一个问题：我的硬件到底能不能跑？手算很容易出错——需要同时考虑参数量、量化后每权重字节数、随上下文增长的 KV 缓存以及运行时开销。这个计算器为最新的开源模型做好了这套数学，包括 Kimi K3、DeepSeek R1 这类万亿参数 MoE 旗舰（它们的 MLA 压缩 KV 缓存与稠密模型行为完全不同）。在租用 GPU、为本地推理购买 Mac、或下载 1TB 权重文件之前，先算清楚一张 RTX 4090 是否够用，还是需要 8× H100。估算用于规划参考，实际占用因推理框架（llama.cpp、vLLM、SGLang、MLX）而略有差异。
常见问题
- 跑 Kimi K3 需要多少显存？
- Kimi K3 是 2.8 万亿参数的 MoE 模型，原生 MXFP4 格式。仅权重就约 1.4TB，即使按原生量化也需要多卡服务器——大约 8× H200 141GB 起步（取决于上下文长度）。远超任何消费级显卡或 Mac；对绝大多数人来说，使用 K3 的现实方式是托管 API。
- 单卡能跑 DeepSeek R1 吗？
- 完整的 671B 模型不行。Q4 量化后仅权重就约 380GB，需要约 5-6 张 H100 80GB。单卡用户建议使用蒸馏版本（如 R1-Distill-Qwen-32B），Q4_K_M 量化后可在 24GB 显卡上运行。
- 什么是 MXFP4 量化？
- MXFP4 是一种 4 位浮点微缩放格式：权重按块存储、块内共享缩放因子，平均每参数约 0.53 字节。Kimi K3 和 OpenAI 的 gpt-oss 系列原生采用 MXFP4，所以它们的下载体积只有 FP16 的四分之一左右。
- 上下文长度对显存有多大影响？
- 上下文中的每个 token 都要为每一层保存 K 和 V（即 KV 缓存），缓存大小随上下文长度线性增长：稠密 70B 模型在 FP16 下 128K 上下文约需 40GB。采用 MLA 的模型（DeepSeek、Kimi）会大幅压缩这一开销，勾选 FP8 KV 缓存还能再减半。
- GGUF 量化该选哪一档？
- Q4_K_M 是社区默认选择——约 4.8 bit/权重，质量损失可接受。显存充裕时可用 Q5_K_M 或 Q6_K；Q8_0 接近无损；Q3/Q2 仅在实在装不下时使用，4 bit 以下质量下降明显。
- 估算包含 KV 缓存和运行时开销吗？
- 包含。总量 = 权重 + 所选上下文长度的 KV 缓存 + 运行时开销（缓冲区、激活值、碎片，约为权重的 8%，下限 1.5GB）。很多简单计算器只算权重，长上下文场景会明显低估实际占用。
- 这些数字有多准？
- 属于规划级估算，batch size 为 1 时通常与实际相差 10% 以内。实际占用因框架而异：vLLM 会预分配 KV 块，llama.cpp 支持层卸载，MLX 在 Apple Silicon 上与系统共享统一内存。架构细节未完全公开的新模型会标注「估算」。
- 我的数据会被上传吗？
- 不会。计算器是纯前端 JavaScript——模型规格随页面打包，所有计算都在浏览器本地完成。无需注册、无上传、不记录你的输入。