跑Kimi-K3到底要多大显存？一文讲清楚所有概念

现在越来越多人想自己跑本地模型，但一上来就被各种参数搞晕了——多少B、量化、KV Cache、Prefill、多人并发，到底哪个决定显存大小？

正好Kimi-K3开放了权重，我们就拿它当例子，把账算清楚。

工具地址：Kimi K3官网

一、参数和量化：模型本身有多"重"

模型有多少参数，决定了它最基本的"体重"。

注意：4-bit实际占的会比理论值大一点，因为还有量化scale、分组信息、对齐空间等额外开销。

关键认知：量化只压缩了模型权重，不代表整个推理过程都变成4-bit。 KV Cache、激活值和部分运算数据仍然可能是FP16或FP8。所以模型文件能装入GPU，不等于剩下的显存一定够跑推理。

二、KV Cache：推理时的"工作记忆"

模型生成每个token时，都要参考前面看过的所有内容。如果每生成一个token就把整段对话重新算一遍，速度会慢到没法用。

所以模型会把之前token的Key和Value保存下来，这就是KV Cache。

打个比方： 模型权重是固定放在房间里的书柜，KV Cache是此刻摊在书桌上的资料。书柜够大放得下，但桌面还有多少空间，直接决定了你能同时处理多长的对话。

KV Cache的大小不仅跟token数量有关，还受模型层数、注意力头数、注意力架构和KV Cache精度影响。两个同样32B的模型，即使量化方式相同，KV Cache大小也可能不同。

三、Context Window：一次能装多少token

Context Window是模型一次最多能容纳的token总量，包括：

• 系统提示词
• 历史对话
• 你输入的内容
• 贴入的文件
• 模型要生成的回答

一个重要误区： 模型支持32K Context Window，不代表你可以输入32K token后再另外生成32K token。输入和输出的总量必须一起放在这32K里。

Context Window越大，需要保存的KV Cache通常也越大。同样条件下，32K Context的KV Cache大约是8K Context的四倍。

另一个关键点： 模型标注支持128K或1M Context，不代表每次都必须开满。真正影响显存的是你实际设定和使用的Context长度。模型在8K下跑得动，不代表把设置改成128K后还能装得下。

四、Prefill：读入内容的"预处理阶段"

假设你贴入一份2万token的文件，模型把这些token计算一遍并建立对应KV Cache的过程，就叫Prefill。

Prefill完成后，模型才进入Decode阶段，一个token接一个token地生成答案。

三者的关系是：

• Context Window：能容纳多少token（容量上限）
• Prefill：处理输入token的过程（计算阶段）
• KV Cache：处理完后留下来供后续生成使用的记忆（存储占用）

Prefill不需要额外加到Context Window里，但它会使用激活值和注意力工作空间等临时空间。所以有些模型正常载入、短对话也正常，但一次性贴入很长的文件时，却在Prefill阶段显存爆了（OOM）。

部分推理引擎会用Chunked Prefill（把长输入切成小块处理）来降低瞬时显存峰值，但输入token仍然占用Context，后续需要保留的推理状态也不会消失。

五、并行用户数：单人和多人差别巨大

自己一个人用，通常只需要保存一段对话的KV Cache。

但如果把模型架成API同时服务多人，每个进行中的对话都需要保存自己的推理状态。

假设一段长对话需要2GB KV Cache，十段同样长度的对话同时跑，极端情况下就需要接近20GB。

虽然实际推理引擎会通过各种优化（PagedAttention、Continuous Batching、内存池）提高利用率，但不会让这些数据完全免费。

经验规律： 同一个模型，单人用可以开很长的Context，做成多人服务后，要么缩短每个人的Context，要么加更多GPU。并发数越高，KV Cache和Prefill的临时空间都跟着涨。

六、以Kimi-K3为例：实际算一遍

Kimi-K3是一个MoE（混合专家）模型：

• 总参数量：2.8T（2.8万亿）
• 每个token实际激活：约104B参数
• 使用MXFP4权重和MXFP8激活值
• 支持1M Context Window
• 93层，896个专家，每个token选16个

最容易误解的地方：104B。

104B是每个token实际参与计算的参数量，主要影响运算速度和成本。但完整部署时，全部2.8T参数都必须能被访问到。不能因为每次只激活104B，就把它当成普通104B模型来算显存。

纯权重理论下限：

2.8T × 0.5 byte（4-bit）= 1.4TB

这只是纯权重的理论下限，还没算量化scale、模型元数据、对齐空间、推理引擎、通信缓冲、Prefill临时空间和推理状态。实际需求一定高于1.4TB。

用B300来算：

一张NVIDIA B300有288GB HBM3e。

1.4TB ÷ 288GB ≈ 4.86，所以至少5张B300才能勉强放下理论上的模型权重。

但5张只是数学下限。5张总共只有1.44TB，扣掉约1.4TB的纯权重后几乎没有剩余空间，也不是常见的完整硬件节点配置。模型勉强载入后，很难留出足够空间给Prefill、Context和实际运算。

比较合理的最低配置：8张B300

总显存约2.3TB，通过NVLink和NVSwitch连接。扣除模型权重后，仍有约数百GB空间放量化附加数据、推理状态、Prefill临时空间和一定程度的并发。

但这里的"跑得动"是指： 能把完整模型载入并进行实际推理。如果要让大量用户同时使用完整1M Context，或需要更高并发、更高吞吐量，就需要两台以上DGX B300，甚至上更大型的GB300 NVL72系统。

七、总结：判断显存需求的完整框架

不能只问"这模型几B"，完整的判断维度是：

下次看到一个新模型，按这五个维度问一遍，就能大致判断你的机器能不能跑得动了。