你的第二块GPU，买的是缓存不是模型

很多团队在规划 GPU 集群时，习惯按“算力”做预算。第一块 GPU 用来把模型跑起来，第二块 GPU……大多数人以为是为了更大的模型或更高的吞吐。实际未必。多出来的那块 GPU，往往是被缓存吃掉的。

加 GPU 的三个理由

加 GPU 通常有三种意图：

1. 训练更大的模型：需要更多的 FLOPs，这是算力需求。
2. 支撑更多并发请求：需要更大的吞吐，这是带宽和调度需求。
3. 扩展上下文窗口：需要更多的 KV cache，这是显存容量需求。

前两种都很直观，第三种最容易被忽视。当你把对话上下文从 2K 拉到 32K，KV cache 的显存占用会成倍增长，甚至超过模型参数本身。这时候，你加的第二块 GPU，实际上是在为缓存买单。

KV cache 为什么会吃显存

推理时，模型需要为每个 token 维护一组 Key 和 Value 向量，用来计算注意力。序列越长，KV cache 越大。对于一个 7B 参数的模型，如果上下文达到 128K，KV cache 可能占据几十 GB 显存。相比之下，模型权重可能才 14GB。也就是说，缓存才是显存的真正大户。

更麻烦的是，KV cache 无法像模型权重那样做量化压缩？其实也可以，但压缩后精度下降，很多场景不敢用。于是只能靠加卡。

怎么判断该不该加卡

不要只看模型参数大小。算一下峰值显存 = 模型权重 + 激活值 + KV cache。如果 KV cache 占比超过一半，那加卡的主要收益是缓存容量，而不是算力。

用国内的场景来说，爱奇艺的推荐系统、美团的外卖调度，如果要用大模型做实时推理，上下文一拉长，第一块 GPU 立刻捉襟见肘。第二块 GPU 的加入，往往让推理延迟不降反升——因为跨卡通信又成了瓶颈。这时候你要考虑的是换大显存卡，比如 A800 80G 到 H200 141G，而不是简单堆数量。

决策建议

• 先分析推理负载的序列长度分布
• 用 profiler 统计 KV cache 峰值
• 再决定是加整卡、加显存，还是优化缓存策略（如 PagedAttention）

总之，GPU 预算不能只按模型参数量来定。第二块 GPU 很可能不是为模型买的，而是为缓存买的。想清楚这一点，能省不少钱。