大模型服务化部署的显存容量规划，核心结论是：先按模型权重和KV Cache算清楚静态占用，再按并发峰值留出至少30%冗余，最终显存需求往往比多数人预估的高出一倍。不少人第一次部署时拿着模型参数量估算显存，结果上线一压测就OOM，根子在于只算了权重的账，没把推理时的激活值、显存碎片和CUDA context开销算进去，下面从估算方法、场景取舍和应急手段三个维度拆解。
大模型部署显存到底怎么算
模型权重只是起点
业内共识认为,大模型显存占用的第一大头是模型权重，但权重只占服务化部署总显存的一部分，以FP16精度为例，每10亿参数大约需要2GB显存，这是纯权重的基础值，一个7B模型，FP16权重就要占14GB左右，但实际部署时，GPU显存还得承载推理过程中产生的KV Cache、激活值、临时张量，以及CUDA kernel的预留空间。
- 纯权重：参数量 × 2字节（FP16）或 ×4字节（FP32）
- KV Cache：随序列长度和并发数线性增长
- 激活值：受batch size影响明显
- 框架开销：PyTorch、CUDA context、cuDNN等固定吃掉1-2GB
KV Cache是隐性大头
服务化部署和单次推理的差别在于并发,每多一个并发请求，就要为每个请求维护独立的KV Cache，序列越长、模型层数越多，KV Cache增长越凶。KV Cache的计算公式大致是：2 × 层数 × 隐藏维度 × 序列长度 × 精度字节数，举个例子，7B模型的典型配置（32层，隐藏维度4096），在2048序列长度下，每个请求的KV Cache约1GB；如果并发32路，光是KV Cache就要32GB。
这就是为什么很多人本地跑单次推理觉得显存还行,一旦通过API服务对外提供访问，显存立刻告急，服务化部署必须按峰值并发来规划，而不是按单次推理的显存来凑。
大模型服务化部署显存容量规划的完整步骤
第一步：定精度，算权重基线
优先明确部署精度,FP16是默认选择，INT8和INT4量化能显著降低显存占用，但推理质量会有轻微损失。
- FP16：权重显存 = 参数量 × 2GB/10亿参数
- INT8：权重显存 = 参数量 × 1GB/10亿参数
- INT4：权重显存 = 参数量 × 0.5GB/10亿参数
第二步：预估KV Cache峰值
这部分需要结合业务场景的平均序列长度和
最大并发数，对话类应用序列偏长，文档摘要类应用序列更长，短文本分类任务则轻松得多。
| 模型规模 | 序列长度 | 单请求KV Cache（约） | 32并发KV Cache总量（约） |
|---|---|---|---|
| 7B | 2048 | 1GB | 32GB |
| 13B | 2048 | 2GB | 64GB |
| 70B | 4096 | 6GB | 192GB |
数值基于主流Transformer结构的估算,实际值会因层数、注意力头数不同浮动。
第三步：加上框架开销和冗余
GPU显存不能全部用满,预留20%-30%的空闲显存是稳定服务的基础，显存碎片化在长时间运行中不可避免，重新分配和释放会加剧碎片，最终触发OOM，建议按总需求的1.3倍作为最终显存规格。
实际部署中我见到不少团队在规划时卡得很紧,以为算出来的数字正好够用就行，结果上线后遇到稍长的输入、稍大的batch，直接整卡崩溃，服务化部署是长期运转的，不是跑完一个任务就完事。
大模型推理显存不够用的三个主流解法
量化部署：感受最直接的显存压缩
INT8量化能把显存占用直接砍一半，INT4量化更是能降到FP16的四分之一左右，当前主流推理框架如vLLM、TensorRT-LLM、llama.cpp都支持不同程度和粒度的量化，GPTQ和AWQ是服务化部署中用得较多的量化方案，它们在压缩显存的同时尽量保留模型原有精度。
量化不是万能的,较大比例的模型在INT8下损失微小，但INT4对推理质量的影响在专业领域任务上会变得明显，比如法律文书生成、代码补全、数学推理这类对精度敏感的行业应用，选择精度前先用测试集验证效果更稳妥。
模型并行：多个GPU分摊权重
单卡放不下时,最常见的路径是张量并行，将Transformer的权重按层切到多张卡上，每张卡只负责一部分计算，通过高速互联（NVLink或PCIe）通信同步结果，70B模型FP16权重约140GB，用4张40GB显卡就能放下权重加上一部分KV Cache，8张卡则更宽裕。
张量并行会带来通信开销,两张卡的并行效率通常在80%-90%之间，4张卡效率会进一步下滑，如果追求极致的大并发，也可以考虑流水线并行，但实现复杂度高不少，工程团队的维护成本需要考虑进去。
动态批处理和调度：把显存用得更充分
服务化部署场景下,动态批处理（Continuous Batching）能大幅提升显存利用效率，传统批处理必须等最长请求结束后一起返回，动态批处理则把序列级调度做到迭代级，哪个请求的token算完了就立刻释放显存，让下一个请求进来。
配合动态批处理,还可以设置KV Cache的复用策略，比如vLLM支持Prefix Caching，如果多个请求共享相同的系统提示词或前缀，KV Cache可以直接复用，省下不少显存和算力，对客服机器人、RAG应用这类前缀固定的场景，效果尤其明显。
不同规模模型的服务化部署显存规划建议
7B模型本地部署显卡要求
7B是当前本地部署最热门的规模。FP16权重14GB，外加KV Cache和框架开销，单路并发至少需要24GB显存，如果追求流畅的对话体验、支持32路并发，一张48GB的显卡（如RTX 6000 Ada或A6000）会更从容，预算有限的个人开发者，可以选择INT8量化后在24GB显卡上部署，并发控制在8路以内比较稳妥。
13B和70B级别模型的显存规划
13B模型FP16权重需要26GB,加上KV Cache和并发预留，单张40GB显卡只能应对低并发场景，80GB的A100或H100才适合对外提供服务，至于70B级别的开源模型，FP16权重就要140GB，单卡方案基本不存在，直接按4卡或8卡并行规划。
| 模型规模 | 精度 | 权重显存 | 低并发服务建议 | 中等并发服务建议 |
|---|---|---|---|---|
| 7B | FP16 | 14GB | 24GB单卡 | 48GB单卡 |
| 7B | INT8 | 7GB | 12GB单卡 | 24GB单卡 |
| 13B | FP16 | 26GB | 40GB单卡 | 80GB单卡 |
| 70B | FP16 | 140GB | 4×40GB并行 | 8×40GB并行 |
显存扩展的最后一招：CPU Offload
GPU显存实在不够时,可以考虑CPU Offload，把部分参数放到内存里，用到时再取回显存，这个方案的代价是推理速度明显变慢，尤其是参数较大时，PCIe带宽会成为瓶颈。CPU Offload适合延迟不敏感的离线批处理场景，不适合实时交互类服务，用来应急没问题，长期服务化部署还得靠合理的显存规划。
大模型显存容量规划常见误区
以下错误我见的频率最高,列出来提醒大家绕开：
- 只按权重估显存，完全忽略KV Cache和激活值，结果上线就崩
- 高估量化收益，INT4确实省显存但质量下降可能让业务不可用
- 忽视碎片化，长期运行后显存碎片累积，可用显存越来越少
- 不预留冗余，显存卡着100%用，任何流量抖动都会OOM
- 混淆训练和推理需求，训练还要额外存储梯度、优化器状态，显存需求远高于推理
大模型服务化部署常见问题
大模型部署显存不够怎么办？
优先量化到INT8或INT4,这一操作通常能把显存占用降到原来的一半甚至四分之一，如果量化后仍不够，启用模型并行把权重分散到多张卡上，或调低最大序列长度和并发上限，作为兜底方案，CPU Offload能解燃眉之急，但延迟代价较大，多数部署案例都是组合使用量化和并行，以可控的质量损失换取显存容量。
推理和训练对显存的需求差别有多大？
训练的显存开销远高于推理,主要差距来自梯度、优化器状态和中间激活值，以7B模型为例，FP16推理权重仅需14GB，但训练完整模型需要至少4倍于权重的显存来存放优化器状态和梯度，实际训练通常需要4-8张80GB显卡，推理的显存核心在权重和KV Cache，训练的核心在梯度和优化器状态，两者的规划逻辑完全不同。
显存规划中vLLM等推理框架能带来多大差异？
vLLM的PagedAttention机制能显著缓解KV Cache碎片问题，相比传统推理框架可减少接近一半的显存浪费，同等显存下支撑更高并发，TensorRT-LLM则从算子融合角度压缩显存占用并提升吞吐，选对推理框架相当于在不动硬件的前提下把显存利用效率提升一个档次，建议在显存规划时预留框架选型因素，不同框架对同样模型和硬件条件，实际支持的最大并发数可能相差较大，结合具体压测数据做最终决定才是可靠方案。
显存规划的本质是给模型权重、KV Cache和工程开销三者留出足够余量，同时留好性能优化空间。 先按最坏并发估需求，再用量化、并行和调度手段做减法，最终部署时才能稳得住流量、扛得住峰值。