估算推理容量，不能只看模型文件有多大：输入长度、同时生成的请求数和推理框架都会占用显存。下面用 Llama 3 8B 展示 GPU计算节点运行推理服务的显存与并发量估算，并给出可复核的四步方法。
第1步：先算模型权重占用
权重显存可先按“参数量 × 每个参数的字节数”估算。FP16 或 BF16 通常按每参数 2 字节计算；INT8 约为 1 字节；4-bit 权重量化约为 0.5 字节，实际还会有量化尺度等额外开销。
以约 8B 参数的 Llama 3 8B 为例，FP16 权重大约需要 16GB（约 14.9GiB）。4-bit 权重的理论值约为 4GB，实际占用会因量化格式和加载方式增加。量化能释放权重空间，但不代表 KV缓存也同步缩小。
第2步：按上下文长度计算 KV 缓存
自回归模型会为输入和已生成的 token 保存 KV 缓存。常见估算公式为：2 × 层数 × KV头数 × 每头维度 × 每元素字节数 × token数 × 并发序列数。开头的 2 分别代表 Key 与 Value。
以 Llama 3 8B 的常见配置为例：32 层、8 个 KV 头、每头维度 128。若缓存用 FP16，每个 token、每条序列约占 128KiB；单条序列按 4096 token 计算，约需 512MiB。8 条序列合计约 4GiB。上下文设为 8192 token 时，缓存占用大致翻倍；实际还受系统预留和服务端实现影响。
第3步：加入运行开销，算出显存上限
将权重与 KV 缓存相加后，还要为激活值、临时张量、CUDA上下文及推理框架预留空间。不同框架、批处理策略和输入长度会改变这些开销，不能把显卡标称显存全部分给请求。可先把总显存的约 10%—20%作为预留起点，再通过运行时观察调整。
例如，24GB 的 NVIDIA GeForce RTX 4090，加载 FP16 的 Llama 3 8B 后，权重已占去约 14.9GiB，留给 KV 缓存和运行开销的空间有限；若改用 4-bit 权重，可为缓存腾出更多余量，但仍需验证框架开销和实际可用显存。多卡部署时，还要确认权重是否切分；不能简单把各卡显存相加后当作单卡可用空间。
第4步：由显存估算转向并发压测
GPU计算节点运行推理服务的显存与并发量估算，可以先用可用缓存容量除以单条请求的缓存需求，得到理论并发上限，再用目标上下文长度进行压测。上述示例若预留给 KV 缓存约 4GiB、单条请求按 4096 token 约占 512MiB，理论上约可容纳 8 条序列；这只是缓存预算，不是吞吐保证。
- 固定模型、量化方式和推理框架，记录空闲显存与加载后的显存。
- 设定实际输入长度、最大生成长度和批处理上限，逐步增加同时请求数。
- 每档观察显存峰值、生成速度、排队时间和是否发生显存不足；至少覆盖典型长短请求。
- 若延迟或显存接近服务目标边界，降低并发上限，或调整量化、上下文长度及批处理策略。
连续批处理可提高 GPU 忙碌程度，但长请求会增加 KV 缓存占用，也可能拉长其他请求的等待时间。因此应同时报告并发数、输入与输出长度范围、生成吞吐和延迟，而不是只报一个并发数字。GPU计算节点运行推理服务的显存与并发量估算最终应以目标负载下的实测结果为准。
常见问题
显存够用，为什么并发仍然上不去？
并发还受计算吞吐、请求长度、批处理方式和延迟目标限制。显存只说明能否容纳，不等于 GPU 能及时处理所有请求。
上下文长度增加，显存会怎样变化？
在模型与并发序列数不变时，KV 缓存大致随 token 数线性增加；从 4096 增至 8192 token，缓存通常约增至两倍。
量化后能否按比例提升并发？
不能直接按权重缩小比例推算。量化主要减少权重占用，缓存、运行开销和计算瓶颈仍需分别测量。
