70B大模型需要多少显存？推理与微调全解析

部署或微调一个70B参数的大模型，到底需要多少显存？这是每个想要落地大模型应用的团队都会遇到的核心问题。结论先行：16-bit精度下服务一个70B模型需要约141 GB显存用于存放权重，FP8精度降至73 GB，4-bit量化仅需40 GB；而每1000个在途token还需要约0.33 GB的KV缓存。微调方面，QLoRA约需50 GB，LoRA约150 GB，全量微调配合AdamW优化器则高达1.1 TB。

这些数字来自Llama 3.3 70B的配置文件与Hugging Face上的真实检查点大小，Qwen2.5 72B的计算结果几乎一致。

推理时显存都花在哪里了？

GPU显存被三部分占用：模型权重、KV缓存、以及CUDA上下文与推理引擎本身的工作预留区。

权重是最直观的部分——磁盘上的检查点有多大，加载到内存中就有多大。以下是同一模型的三种公开版本：

精度	Hugging Face检查点	内存中权重
16-bit (BF16)	meta-llama/Llama-3.3-70B-Instruct	141.1 GB
8-bit (FP8)	RedHatAI/Llama-3.3-70B-Instruct-FP8-dynamic	72.7 GB
4-bit (AWQ INT4)	casperhansen/llama-3.3-70b-instruct-awq	39.8 GB

量化版本的实际大小会比"参数量×位数"计算结果高出几个GB，原因是嵌入层和输出层仍保持16-bit精度。这两层合计21亿参数，占4.2 GB，此外4-bit格式还需要存储缩放因子。

工作预留区方面，vLLM默认通过--gpu-memory-utilization将GPU显存的90%纳入规划，剩余部分才作为KV缓存使用，因此后文中的KV缓存数据应视为上限。

KV缓存到底有多大？

每个token约需0.33 MB，且随并发请求数线性增长。计算公式为：2（键和值）× 层数 × KV头数 × 头维度 × 2字节。Llama 3.3 70B有80层、8个KV头、头维度128，因此每个token消耗 2×80×8×128×2 = 327,680字节。Qwen2.5 72B结构相同，开销一致。

实际流量中的表现：

• 单次8,192 token的对话占用2.7 GB缓存
• 同时处理32个此类对话需要85.9 GB，是4-bit权重的两倍多
• 单个请求如果使用完整的131,072 token上下文窗口，需要43 GB

8个KV头这个设计非常关键。Llama 3采用分组查询注意力，64个查询头共享8个KV头。如果每个查询头对应一个KV头，缓存会膨胀8倍，达到每token约2.6 MB。

常见的经验法则是在权重基础上加20%覆盖缓存及其他开销，对于35 GB的4-bit权重，这大约是7 GB，仅能容纳约21,000个token——够几个对话，但撑不住繁忙的服务端点。更合理的做法是根据实际流量计算：峰值并发请求数 × (输入+输出token数) × 0.33 MB。

vLLM支持通过--kv-cache-dtype fp8将缓存以FP8格式存储，占用减半至每token约0.16 MB，但建议先在自己的评测集上验证质量。

分组查询注意力（GQA） 是Llama 3、Qwen2.5等现代大模型默认采用的注意力变体。标准多头注意力（MHA）中每个查询头都配有一个独立的键头和一个值头，KV缓存与查询头数量成正比；而GQA将多个查询头分组，共享同一组KV头，从而大幅压缩缓存体积。Llama 3.3 70B设置64个查询头、8个KV头，相当于8个查询头共用1个KV头，KV缓存因此缩减到MHA的1/8。这种设计在几乎不损失模型质量的前提下，把长上下文与高并发场景的显存开销降到了可接受范围。作为对比，多查询注意力（MQA）让所有查询头共享1个KV头，压缩更激进但质量损失更明显；GQA是质量与效率之间的折中，已被Llama 2 70B、Llama 3全系、Mistral、Qwen2等主流模型广泛采用。

多头潜在注意力（MLA） 是DeepSeek^广告系列模型提出的另一种注意力结构，它先将键和值投影到一个低维潜在向量再进行缓存，进一步把每token的KV开销降到GQA的几分之一。由于MLA的KV形状与GQA完全不同，本文给出的“每token 0.33 MB”公式并不适用于MLA模型，需要按照其潜在维度与层数单独推导。选型时如果目标模型使用MLA，务必查阅官方配置文件中的kv_lora_rank等字段重新计算。

哪些GPU配置可以服务70B模型？

只要权重能放进总显存的90%以内并留有缓存空间，任何配置都可以。以下是值得考虑的方案：

配置	权重	KV缓存可用	最大在途token	每小时价格
1×A100 80GB, 4-bit	39.8 GB	32.2 GB	约98,000	$1.09
1×RTX PRO 6000 96GB, 4-bit	39.8 GB	46.6 GB	约142,000	$1.35
1×H200 141GB, FP8	72.7 GB	54.2 GB	约165,000	$3.59
2×H100 80GB, FP8	72.7 GB	71.3 GB	约218,000	$5.20
1×B200 180GB, FP8	72.7 GB	89.3 GB	约272,000	$5.50
1×B300 288GB, 16-bit	141.1 GB	118.1 GB	约360,000	$6.94
4×H100 80GB, 16-bit	141.1 GB	146.9 GB	约448,000	$10.40

有两种配置纸面上可行、实际却会失败：2×80GB GPU跑16-bit精度，权重加载后仅剩2.9 GB，所有请求合计约9,000 token；2×24GB GPU跑4-bit精度，仅剩3.4 GB，约10,000 token。两者都能加载模型，但几乎没有余量来实际服务请求。

精度选择还会限制硬件。FP8在Hopper和Blackwell架构GPU（H100、H200、B200、B300）上原生支持，但A100没有FP8硬件支持，只能用4-bit检查点。

选型规则：先根据质量评测确定精度，再用峰值并发请求数乘以总token数和0.33 MB，选能满足需求的最便宜配置。如果单个请求就需要完整的128K上下文，权重之外还需要至少43 GB缓存。

微调70B模型需要多少显存？

远超推理需求，因为训练需要为每个更新的参数保留梯度和优化器状态。ZeRO论文指出，混合精度训练配合Adam优化器需要每参数16字节：2字节用于16-bit权重，2字节用于梯度，12字节用于FP32主副本加上Adam的两个动量估计。

• 全量微调：705.5亿参数 × 16字节 = 1,129 GB。bitsandbytes的8-bit优化器将每个动量估计从4字节压缩到1字节，降至每参数10字节，即706 GB。
• LoRA：16-bit基础模型冻结占141.1 GB，每个线性层添加rank-16适配器约2.07亿可训练参数（占模型0.3%），FP32配Adam每参数16字节，共3.3 GB。
• QLoRA：基础模型以4-bit NF4存储，线性层占34.2 GB，双量化缩放常数约1.1 GB，16-bit嵌入和输出层4.2 GB，合计39.5 GB，加上同样的3.3 GB适配器。

激活值另算，取决于序列长度。配合梯度检查点，每层仅保留输入：4,096 token × 8,192隐藏维度 × 2字节 × 80层 = 每个4,096-token序列5.4 GB。128,256词表的FP32 logits再加约2.1 GB。估算每GPU每序列约7.5 GB。

方法	激活前	含单个4,096-token序列	最小可行配置	每小时价格
QLoRA	43 GB	约50 GB	1×A100 80GB / 1×H100 / 1×RTX PRO 6000	起价$1.09
LoRA	144 GB	约152 GB	1×B200 / 1×B300 / 2×H200 / 4×H100	起价$5.50
全量+8-bit Adam	706 GB	8 GPU上约766 GB	8×H200 (1,128 GB)	$28.74
全量+AdamW	1,129 GB	8 GPU上约1,189 GB	8×B200 (1,440 GB)	起价$44.00

跨多GPU需要分片方案，如PyTorch FSDP或DeepSpeed ZeRO-3，让每块GPU只持有权重、梯度和优化器状态的一部分。两台8×H100机器共1,280 GB，全量AdamW训练下每GPU仅剩约9 GB，对多数场景来说太紧张。

ZeRO（Zero Redundancy Optimizer） 是DeepSpeed提出的显存优化技术，其核心思路是把训练状态（权重、梯度、优化器状态）切分到多张GPU上，避免每张卡都保存完整副本。ZeRO分为三个阶段：Stage 1只切分优化器状态，Stage 2额外切分梯度，Stage 3再切分模型权重。本文中“每参数16字节”的估算对应的是未分片时的单卡占用，实际多卡训练时由Stage 2或Stage 3把优化器状态和梯度分摊到各卡，因此8×H200才能容纳706 GB的全量微调需求。PyTorch原生的FSDP（Fully Sharded Data Parallel）实现了与ZeRO-3等价的功能。

需要注意的是，分片并不能减少总显存需求，只是把总需求摊到更多GPU上。此外，分片会引入额外的通信开销：每次前向和反向传播后，各卡需要同步梯度或重新聚合权重分片，因此ZeRO-3在GPU数量增加时通信开销显著上升，实际训练吞吐未必随卡数线性提升。对于70B全量微调，8卡是最低可行规模，想获得更好的吞吐通常需要配合张量并行（TP）与流水线并行（PP）组成3D并行策略。

梯度检查点（Gradient Checkpointing） 是另一项关键显存技术：训练时只保留部分层的激活值，其余层在前向传播时不存储中间结果，反向传播时按需重新计算。这以增加约30%的计算量为代价，把激活值显存从与层数成正比降到接近常数级。本文“每层仅保留输入”的估算正是基于梯度检查点。

能否在单张GPU上微调70B模型？

可以——用QLoRA，任何80 GB以上显存的GPU都行。QLoRA论文曾在单张48 GB GPU上微调65B模型。Llama 3 70B激活前需要约43 GB，在48 GB显卡（如L40S或RTX A6000）上仅余约5 GB，只够短序列。

LoRA在16-bit基础模型上仅在B200或B300单卡可行。全量微调70B模型没有单GPU方案。

如何为自己的模型验算？

用同样的公式对目标模型的配置文件计算即可。以下脚本读取config.json和Hugging Face API的参数计数，输出上述估算值，仅使用Python标准库：

"""Rough GPU memory estimate for serving and fine-tuning a Hugging Face model."""
import json, os, sys, urllib.request

def get(url):
    req = urllib.request.Request(url)
    if os.environ.get("HF_TOKEN"):
        req.add_header("Authorization", f"Bearer {os.environ['HF_TOKEN']}")
    with urllib.request.urlopen(req) as r:
        return json.load(r)

repo = sys.argv[1]
context = int(sys.argv[2]) if len(sys.argv) > 2 else 8192
seqs = int(sys.argv[3]) if len(sys.argv) > 3 else 1
cfg = get(f"https://huggingface.co/{repo}/resolve/main/config.json")
params = get(f"https://huggingface.co/api/models/{repo}")["safetensors"]["total"]

head_dim = cfg.get("head_dim") or cfg["hidden_size"] // cfg["num_attention_heads"]
kv_heads = cfg.get("num_key_value_heads", cfg["num_attention_heads"])
kv_per_token = 2 * cfg["num_hidden_layers"] * kv_heads * head_dim * 2
GB = 1e9

print(f"{repo}: {params / 1e9:.1f}B parameters")
for name, bytes_per_param in [("16-bit", 2), ("8-bit", 1), ("4-bit", 0.5)]:
    print(f"  weights at {name}: {params * bytes_per_param / GB:6.1f} GB")
print(f"  KV cache: {kv_per_token / 1e6:.3f} MB per token, "
      f"{kv_per_token * context * seqs / GB:.1f} GB for {seqs} x {context:,} tokens")
print(f"  full fine-tune, AdamW mixed precision (16 B/param): {params * 16 / GB:,.0f} GB + activations")
print(f"  LoRA on a 16-bit base: {params * 2 / GB:,.0f} GB + adapters + activations")
print(f"  QLoRA on a 4-bit base: {params * 0.5 / GB:,.0f} GB + a few GB + adapters + activations")

对Llama 3.3 70B、32个8,192 token对话运行的结果示例：

unsloth/Llama-3.3-70B-Instruct: 70.6B parameters
  weights at 16-bit:  141.1 GB
  weights at 8-bit:   70.6 GB
  weights at 4-bit:   35.3 GB
  KV cache: 0.328 MB per token, 85.9 GB for 32 x 8,192 tokens
  full fine-tune, AdamW mixed precision: 1,129 GB + activations
  LoRA on a 16-bit base: 141 GB + adapters + activations
  QLoRA on a 4-bit base: 35 GB + a few GB + adapters + activations

8-bit和4-bit行是纯参数计算，实际检查点需加上额外几GB。KV公式假设标准分组查询注意力，采用多头潜在注意力等不同设计的模型需要单独公式。

常见问题

为什么权重能放下但vLLM还是报显存不足？

vLLM在启动时检查KV缓存能否容纳至少一个模型最大长度的请求。Llama 3.3 70B默认131,072 token，需要43 GB，紧凑配置会拒绝启动。将--max-model-len降至实际服务的最大请求长度，或用FP8 KV缓存腾出空间。

混合专家模型的计算方式一样吗？

权重方面按总参数量计算，而非激活参数量。每个专家都必须驻留GPU显存，即使每个token只激活少数几个，因此总参数70B的MoE模型需要的权重内存与稠密70B相同。

70B模型能在单张24GB或32GB GPU上运行吗？

不能完全放入GPU显存，即使4-bit权重也约40 GB。llama.cpp等工具可将部分层放在CPU内存中，但这些层的运行速度受限于CPU内存带宽。

70B模型微调需要多少磁盘空间？

16-bit权重占141 GB。可恢复的全量微调检查点还需加上FP32主权重和两个Adam动量，约每参数12字节，再增加约850 GB。

量化格式的区别：BF16是16-bit浮点，保留完整动态范围，是训练和推理的默认精度；FP8是8-bit浮点，在Hopper及Blackwell架构上有硬件加速，质量损失通常很小；INT8/INT4是整数量化，需要缩放因子将整数还原为浮点，AWQ、GPTQ、bitsandbytes NF4都属于这一类。4-bit NF4（Normal Float 4）是QLoRA论文提出的信息论最优4-bit数据类型，专为正态分布的权重设计，因此在微调场景中被广泛采用。

vLLM中的--gpu-memory-utilization 控制引擎可占用的GPU显存比例，默认0.9。这个值同时包含权重、激活、CUDA上下文等所有开销，剩余的显存才被划为KV缓存。因此文中“KV缓存可用”列实际是0.9×总显存减去权重后的余量。调低该值（如0.85）可给其他进程留出空间，但会减少可服务的并发token数。

PageAttention 是vLLM的核心技术，它借鉴操作系统的虚拟内存分页思想，把KV缓存拆成固定大小的块（block）按需分配，消除了传统实现中因预留最大长度而造成的显存浪费，并把碎片率降到接近零。这也是vLLM能在同样显存下服务更多并发请求的原因。