NexGPU-算力租赁,GPU服务器,GPU云算力,AI服务器租用-新闻博客
Qwen部署要多少显存？结论先给：Qwen 2.5 72B 在 FP16 下仅权重就约 144GB~146GB，需双卡 80GB（TP=2）；INT4 量化后约 38GB~40GB，可落到单卡 80GB/96GB 或双卡 32GB；32B FP16 权重约 63.5GB~64GB，需 80GB 级单卡或双卡，INT4 约 18GB。2026 年私有化部署选型时，AI 开发者与算法工程师最常卡在“显存看着够，实际跑不动”的环节。原因很简单：显存由权重、KV Cache、激活张量与引擎预留四笔账共同构成，只看权重数字极易误判。
动手前先回答三个问题，否则显存数字没有意义：
- 模型档位：72B 还是 32B？两者权重差距近一倍，直接影响卡型选择。
- 上下文长度：Qwen 2.5 原生支持 128K（131,072 tokens），但上下文越长，KV Cache 占用越大，必须提前限定。
- 并发规模：同时处理的请求数越多，KV Cache 总量越大，显存需求会成倍放大。
脱离后两者谈显存，等于只算了一半账。
第一笔账：权重占用，从 FP16 到 INT4 的换算表
权重是显存的大头，也是最容易查到的基准。下表给出 Qwen 2.5 32B 与 72B 在 FP16、FP8、INT4 下的权重占用区间，以及对应的显存缺口判断。
| 模型 | FP16/BF16 | FP8 | INT4（AWQ） | 能否进单卡 80GB |
|---|---|---|---|---|
| Qwen 2.5 32B | 约 63.5~64GB | 约 32GB | 约 18GB | 80GB 可行（FP16 勉强，量化更稳） |
| Qwen 2.5 72B | 约 144~146GB | 未提供 | 约 38~40GB | 单卡不可行（FP16），INT4 可单卡 80GB/96GB |
换算规律很简单：FP16 每 10 亿参数约占 2GB，FP8 减半，INT4 再减半（约 0.5GB/10 亿参数）。该换算为通用经验值，用于粗估，最终以实际加载后的显存读数为准。但注意，32B FP16 需要约 64GB，单张 24GB 或 32GB 消费卡绝对装不下；而 72B FP16 高达约 145GB，单张 80GB 也无法直接加载，需要双卡 80GB 并行，这正是后文 TP=2 的由来。若采用 INT4 量化，72B 可压缩到约 38~40GB，32B 仅约 18GB，单卡 24GB（如 RTX 4090）才有可能跑。
第二笔账：KV Cache 为什么是上下文与并发的乘法
如果说权重是固定支出，KV Cache 就是随上下文长度线性增长、再与并发数相乘放大的浮动支出。Qwen 2.5 原生支持 128K 上下文，但请记住一个数字：单请求在 128K 长度下的 KV Cache 即可超过 40GB。这意味着什么？假设你部署 32B INT4（权重约 18GB），单卡 24GB 只余 6GB 给 KV Cache，连 8K~16K 上下文都撑不住。
并发数对显存的影响是乘法关系：N 个并发请求，KV Cache 总量约为单个请求的 N 倍。如果你设定了 32K 上下文且并发 8，KV Cache 就可能超过 80GB，直接顶爆双卡 80GB 的剩余空间。按单请求超 40GB 线性外推，并发 4 时估算需 160GB 以上（该数字为按线性关系推算的估算值，实际随模型 GQA 配置与量化方式浮动，需实测确认）。这就是为什么很多团队在长文本和并发上来后频繁触发 CUDA out of memory——不是权重问题，而是 KV Cache 这笔浮动账没算清。
第三、四笔账：激活张量与引擎常驻，为什么要留 30%-50% 余量
除了权重和 KV Cache，vLLM 运行时还会占用显存用于激活张量和引擎常驻开销（CUDA context、内存池等）。可用 KV Cache = 总显存 × 利用率 - 权重 - 常驻开销，因此生产部署建议预留 30%-50% 余量，不要卡着权重极限去算。同时注意，vLLM 默认按显存利用率预分配显存，即便权重只在 38GB，剩余空间不足时，上下文或并发上升同样会触发 OOM。
为什么双卡 80GB（TP=2）是 72B 的生产基准形态
把四笔账合起来看，72B FP16 权重约 145GB，双卡 A100/H100 80GB 合计 160GB，减去权重后还剩约 15GB 给 KV Cache 和激活。在限制上下文（如 8K）和低并发（如 4）下勉强能跑，但若要支持较长上下文或更高并发，就需要进一步量化或者扩充到 4 卡。
这也解释了为什么 --tensor-parallel-size 2 是 72B Qwen部署的默认起点：单卡 80GB 物理上无法加载，双卡正好把权重分到两张卡上，显存利用率最高。对于 32B FP16（约 64GB），双卡 80GB 或单卡 80GB/96GB 都可行，但双卡 TP=2 能提供更充裕的 KV Cache 空间。跨卡通信与 TP 切分带来的额外开销，可参考多卡推理优化。
vLLM 启动参数配置顺序：TP、显存利用率、最大序列长度
在实际启动 vLLM 时，参数配置顺序很关键，它决定了显存账能否成立。建议按以下顺序调整：
--tensor-parallel-size（TP 大小）：根据权重精度确定卡数。72B FP16 设为 2，32B FP16 可设为 1 或 2；若量化后权重减小，也可适当降低 TP 以节省跨卡通信开销。--gpu-memory-utilization（显存利用率）：默认 0.90，一般不需要改动。如果后续 OOM，可以适当降低到 0.85，但会挤压 KV Cache 池。--max-model-len（最大序列长度）：必须人工设定，不要依赖默认值。它直接限制 KV Cache 上限，设定过大（比如 128K）会让 KV Cache 池提前占满显存，导致即使短请求也 OOM。
一个典型的 72B 双卡启动命令如下：
vllm serve Qwen/Qwen2.5-72B-Instruct \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.90 \
--max-model-len 32768 \
--enable-prefix-caching--enable-prefix-caching 能在多请求共享前缀时复用 KV Cache，降低显存压力，推荐开启。从 GPU显存怎么选 的角度看，这些参数必须在购买资源前确定，否则很容易出现“显存看着够，实际跑不动”的尴尬。
四档落地路径：从单卡量化验证到双卡 FP16 上线
以下四档是 Qwen部署最常见的落地形态。根据四笔账，可以把落地路径分成四档，每一档的适用场景很清晰：
| 档位 | 配置 | 适用场景 | 上下文与并发约束 |
|---|---|---|---|
| 第一档：单卡 INT4 验证 | 单卡 24GB（如 RTX 4090）跑 32B-INT4，或 80GB/96GB 跑 72B-INT4 | 功能验证、低并发原型 | 上下文 ≤ 8K，并发 ≤ 2 |
| 第二档：单卡 80GB/96GB | 32B FP16 或 72B-INT4 | 中等负载内部 API | 上下文 ≤ 32K，并发 ≤ 8 |
| 第三档：双卡 80GB FP16 | 72B FP16，TP=2 | 生产级 API，追求精度 | 上下文 8K~32K，并发 4~16 |
| 第四档：多卡扩容 | 4×80GB 或更多 | 高并发、长上下文 | 上下文 32K~128K，并发 >16 |
同量级国产模型的显存账算法一致，可对照DeepSeek部署的分档结论。选择哪一档，取决于你的业务对上下文和并发的真实需求。如果只是做问答 demo，第一档就够；如果要支撑生产流量，直接从第三档起步更稳。
用按量资源做一次显存峰值实测：该记录哪些指标
这类峰值实测适合用 NexGPU 一类按量计费、即开即用的 GPU 资源完成，避免为一次验证锁定长期配置。纸上算账不如实测。建议用按量 GPU 资源跑一次峰值测试，记录以下指标，便于后续选型：
- 权重加载后剩余显存（
torch.cuda.mem_get_info） - vLLM 启动后 KV Cache 池大小（日志中可查）
- 固定上下文长度和并发档位下的峰值显存占用
- OOM 触发点：在哪个上下文或并发组合下首次报错
实测时，先设一个保守的 --max-model-len（比如 8K），逐步增加并发，记录显存曲线。关于 vLLM部署 一文列出了启动日志中 KV Cache 池大小的读取位置。
Qwen部署落地检查清单
- [x] 确定模型档位（72B/32B）与精度（FP16/FP8/INT4）
- [x] 估算权重占用（查表或用公式）
- [x] 设定最大上下文长度（
--max-model-len） - [x] 评估并发规模，计算 KV Cache 总量
- [x] 选择卡型与数量（TP 大小），预留 30%-50% 余量
- [x] 填写 vLLM 参数并启动测试
- [x] 实测峰值显存，验证是否 OOM
常见问题
Qwen 2.5 72B 需要多少显存？
72B 在 FP16 下权重约 144~146GB，需双卡 A100/H100 80GB（TP=2）才能生产部署；在 INT4 量化下权重约 38~40GB，单卡 80GB/96GB 或双卡 32GB 可运行，但上下文和并发需严格限制。
Qwen 32B 单卡 24G 能跑吗？
原生 FP16 不行（权重约 64GB）。但使用 AWQ-INT4 量化后权重约 18GB，单卡 24GB（如 RTX 4090）在限制上下文（≤8K）和低并发（≤2）下可以勉强运行，但不适合生产。
vLLM 部署 Qwen tensor parallel size 设多少？
主要看权重能否被单卡容纳。72B FP16 必须设 2（双卡），32B FP16 可设 1（单卡 80GB）或 2（双卡）。量化后权重变小，可适当降低 TP 以减少通信开销。
Qwen 128K 长上下文 KV Cache 占多少显存？
单请求 128K 上下文的 KV Cache 可能超过 40GB，若并发 4 则估算需 160GB 以上。生产上需通过 --max-model-len 限制上下文，或使用多卡+量化组合。
Qwen部署 CUDA out of memory 怎么办？
按顺序排查：先降低 --max-model-len（压缩 KV Cache），再降低并发或减少 --gpu-memory-utilization，最后考虑量化权重或增加 GPU 数量。实测记录峰值显存，找到 OOM 触发点。
在算完四笔账、确定显存档位后，可以用诸如 NexGPU 这类提供不同 GPU 型号、按量计费、即开即用的云端算力平台，先用单卡跑 INT4 量化版验证上下文与并发上限，再切到双卡 80GB 跑 FP16 做同负载对照。借助预制模板，能显著缩短 vLLM 环境准备时间，避免在显存区间未确定前就锁定长期资源。
建议按本文四笔账先估出自己业务的上下文与并发档位对应的显存区间，再用按量资源跑一次峰值实测验证，确认稳定后再决定长期配置。
评论(0)