推理显存账本（inference memory budget），指的是给一次大模型推理算一笔"分账"：显存到底被谁吃掉了。拆开来看主要是三本账——权重（weights）、KV 缓存（AI 词典：KV Cache">KV Cache）和激活（activations）。搞清这三笔，就能明白为什么上下文一长就 OOM（Out of Memory，显存不足）。
打个比方：显存像一间小饭馆。权重是桌椅厨具，开店前就摆好，占地方但固定不变；KV 缓存是每桌客人的行李，客人越多、坐得越久，堆得越多；激活是后厨操作台上摊开的食材，做饭时铺得满桌都是，做完一道就收走，但高峰期能瞬间把台面占满。
第一本账：权重。 就是模型参数本身，大小 = 参数量 × 每个参数占的字节数。半精度（FP16）每个参数 2 字节，一个 70 亿参数的模型大约 14GB。这笔开销一次加载、长期驻留，跟聊天聊多长没关系。
第二本账：KV 缓存。 大模型生成每一个新词，都要回头看前面所有词。为了不重复计算，前面每个词的 Key 和 Value 张量会被缓存下来，每生成一个词就多存一份。粗略公式是：
每 token 占用 ≈ 2 × 层数 × KV 头数 × 头维度 × 每元素字节数
假设 32 层、32 个 KV 头、头维度 128、FP16，那么每个 token 约 0.5MB。8K 上下文（约 8000 个 token）就是 4GB；如果同时服务 8 个请求，就是 32GB。这笔账随序列长度和并发数线性增长，是长上下文 OOM 的头号凶手。
第三本账：激活。 前向计算途中产生的中间张量，做完就释放。它的峰值出现在"预填充"（prefill，一次性读完整段输入）阶段。其中注意力分数矩阵的大小是序列长度的平方量级，8K 上下文下很容易到 GB 级。现代实现用分块流式计算（如 FlashAttention）避免把它完整写出来，但临时缓冲依旧随长度明显上涨。
| 账本项 | 是什么 | 随什么增长 | 常见瘦身手段 |
|---|---|---|---|
| 权重 | 模型参数 | 不随上下文变 | 量化（FP16→INT8/INT4） |
| KV 缓存 | 缓存的 K/V 张量 | 序列长度、批大小（线性） | GQA/MQA、KV 量化、分页管理、前缀复用 |
| 激活 | 前向中间张量 | 批大小、序列长度（注意力近平方） | 分块计算、算子融合 |
把三笔账加回去看开头那个例子：14GB 权重 + 32GB KV，已经远超一张消费级显卡的容量——权重没变，是 KV 和激活把内存撑爆的。于是就有了两条铁律：上下文和并发不能同时拉满；长上下文的第一优化对象永远是 KV 缓存。
对从业者，这笔账决定三件事：要不要量化、上下文开多长、单卡能扛多少并发。对普通人，它解释了为什么长对话更慢更贵、为什么服务方要给上下文设上限、为什么高峰期要排队。需要提醒的是，具体占用随模型结构、精度和框架实现差异很大，实际容量规划请以官方文档和压测结果为准。