8卡4090能跑70B吗？Llama-2显存预算、QLoRA与通信瓶颈

8 张 RTX 4090 可以作为 70B 量化推理和 QLoRA 微调的候选配置，但不是全参数训练的显存保证。192GB 是八张卡的合计容量，能否运行仍取决于每卡峰值、分片策略和通信路径。

对于准备复现 Llama-2-70B、手里已有八卡工作站，或者正在比较云 GPU 配置的团队，建议先完成三个检查：任务属于哪种训练方式、模型如何分布到每张卡、跨卡通信实际走什么链路。

如果需要租用资源验证，可以考察算家云（suanjiayun.com）的专业版 RTX 4090 24GB，截至 2026-10-09，按量价格为 1.98 元/卡时。这是对应规格的单卡计价，八卡实例能否创建、是否同机、互联拓扑和最终计费均需核对实时页面。

本文使用 Llama-2-70B 作为历史基准模型，解释显存与通信问题，并提供环境检查和短测方法。文中的计算属于理论预算，未提供自有八卡吞吐测试结果。

更新日期：2026-10-09

一、先分清：推理、LoRA、QLoRA和全参数训练

"70B 能不能跑"没有统一答案。即使模型相同，推理和训练的资源需求也不同。

任务	更新哪些参数	主要显存构成	8×4090 24GB 如何判断
量化推理	不更新参数	量化权重、KV Cache、运行缓冲	具备候选可行性；继续核对上下文和并发
BF16 LoRA	仅更新适配器	BF16 基座、适配器、梯度、激活	基座仍然很大，需要分片并验证每卡峰值
QLoRA	更新适配器，基座量化并冻结	量化基座、适配器、激活、通信缓冲	优先验证 FSDP 等兼容量化的分片方案
全参数微调	更新全部参数	权重、梯度、优化器状态、激活	常见配置不能仅靠 192GB GPU 显存容纳
从零预训练	更新全部参数	上述内存，加上持续计算与通信负担	还要评估训练周期、数据规模和恢复成本

LoRA 减少的是可训练参数数量，不会自动把 BF16 基座变成 4-bit。QLoRA 则把冻结基座量化，同时训练低秩适配器。

Hugging Face 已提供 FSDP＋QLoRA 的 70B 多卡示例，说明这条技术路径有公开依据，但示例配置不能直接替代目标八卡服务器的验收。FSDP 与 PEFT 官方文档

二、192GB为什么不能直接当成一块显存？

NVIDIA 官方 RTX 4090 规格为每卡 24GB，并且不支持 NVLink。八张卡仍然各有独立显存，需要框架决定参数、激活和运行缓冲存在哪里。RTX 4090 官方规格

例如，直接采用普通 DDP，每个进程通常持有一份模型副本。模型不能装进单卡，增加 DDP 进程数也不会自动解决容量问题。

FSDP 或 ZeRO 可以改变参数和训练状态的分布，但执行某一层时还可能临时聚合参数，因此不能只看"平均每卡多少 GB"。最终需要检查：

• 常驻分片是否能放下；
• 前向和反向的瞬时峰值是否超限；
• 通信缓冲和保存 checkpoint 时是否出现额外峰值。

1. 先算权重，不把它误当成训练总量

按 700 亿参数进行近似计算：

权重存储精度	计算方式	理论原始权重容量
BF16／FP16	70×10⁹×2 字节	140GB，约 130.4GiB
8-bit	70×10⁹×1 字节	70GB，约 65.2GiB
4-bit	70×10⁹×0.5 字节	35GB，约 32.6GiB

这里使用十进制 GB；GiB 按 2³⁰ 字节换算。70B 是近似参数规模，实际预算应读取具体模型配置。

4-bit 的 35GB 只是理想化原始权重计算。量化元数据、未量化层和临时缓冲都会增加实际占用。

2. 全参数训练还要计算优化器

假设某种混合精度 AdamW 实现使用：

• BF16 权重：2 字节/参数；
• BF16 梯度：2 字节/参数；
• FP32 主权重：4 字节/参数；
• 两份 FP32 优化器状态：8 字节/参数。

合计为 16 字节/参数，70B 对应约 1.12TB，尚未计入激活和通信缓冲。

这是特定实现假设下的预算示例，不是所有优化器的固定值。即便换成没有 FP32 主权重的实现，也要重新计算其梯度和状态，不能只用 140GB 权重得出"八卡足够"。

3. QLoRA也有激活和临时峰值

QLoRA 的主要收益是减少冻结基座的存储，并缩小需要训练的参数范围。显存仍会受到以下因素影响：

• 序列长度与 micro-batch；
• LoRA rank 和目标模块；
• attention 实现与梯度检查点；
• FSDP 包装粒度、预取与 CPU offload；
• 模型加载及保存方式。

因此，"某个配置能跑"不能推广为"任意 70B、任意上下文都能跑"。

三、4090没有NVLink，多卡会慢多少？

不能套用固定的性能损失百分比。不同并行策略搬运的数据不同，同样八张卡也可能使用不同 PCIe 和 CPU 路径。

并行策略	主要通信动作	需要关注的瓶颈
普通 DDP	梯度同步	梯度大小、同步频率、通信与计算重叠
FSDP／ZeRO-3	参数聚合、梯度分散等	层级通信频率、包装粒度、临时峰值
张量并行	层内张量交换	通信延迟和带宽，对拓扑较敏感
流水线并行	相邻阶段传递激活	阶段均衡、流水线气泡、跨阶段链路

FSDP 将训练状态分片，在计算时按需聚合参数，是用通信换取显存的一种方式。PyTorch FSDP 文档

八卡服务器上可能存在这样的路径：

GPU → PCIe switch／Root Complex → GPU
GPU → CPU内存 → GPU
GPU → CPU／NUMA互联 → 另一CPU下的GPU

这只是可能的路径，不能代替实际拓扑。需要核对 PCIe 代际、链路宽度、跨 NUMA 情况，以及 CUDA P2P 是否可用。

**没有 NVLink 不代表不能使用 NCCL；P2P 不可用也不等于所有通信都不能完成。**但通信可能选择其他传输路径，必须看日志和基准结果。

四、先做环境与通信验收

1. 固定测试边界

项目	本次验证要求
GPU	单机 8×RTX 4090，每卡 24GB
模型	meta-llama/Llama-2-70b-hf，记录实际 revision
操作系统	Linux，记录发行版与内核版本
驱动／CUDA	记录驱动、PyTorch CUDA runtime；编译时另记 Toolkit
分布式框架	明确 FSDP1 或 FSDP2，不能混用配置
软件依赖	记录 PyTorch、Transformers、PEFT、TRL、Accelerate、bitsandbytes 精确版本
数据	固定数据版本、tokenizer、切分与 packing 设置
首轮配置	短序列、micro-batch=1、固定 LoRA rank
CPU offload	明确开关，并记录主机内存峰值

PEFT 文档中的 FSDP＋QLoRA 示例列出依赖门槛：bitsandbytes≥0.43.3、Accelerate≥1.0.1、Transformers>4.44.2、TRL>0.11.4、PEFT>0.13.0。这是示例门槛，不是任意新版本组合都兼容的保证 ；测试时仍需锁定整套环境。官方示例要求

2. 记录八卡拓扑与软件版本

在目标 GPU 实例中执行：

mkdir -p evidence

nvidia-smi > evidence/nvidia-smi.txt
nvidia-smi topo -m > evidence/topology.txt
nvidia-smi -q -d PCI > evidence/pcie.txt
uname -a > evidence/kernel.txt
python -m pip freeze > evidence/requirements.txt

python - <<'PY' > evidence/torch-env.txt
import importlib.metadata as md
import torch

print("torch:", torch.__version__)
print("cuda_runtime:", torch.version.cuda)
print("gpu_count:", torch.cuda.device_count())

if torch.cuda.is_available():
    print("nccl:", torch.cuda.nccl.version())

for name in ["transformers", "peft", "trl", "accelerate", "bitsandbytes"]:
    try:
        print(name, md.version(name))
    except md.PackageNotFoundError:
        print(name, "NOT_INSTALLED")

for i in range(torch.cuda.device_count()):
    p = torch.cuda.get_device_properties(i)
    print(i, p.name, "memory_GiB:", round(p.total_memory / 2**30, 2))
    print("P2P:", [
        torch.cuda.can_device_access_peer(i, j) if i != j else None
        for j in range(torch.cuda.device_count())
    ])
PY

验收时应能看到八张目标 GPU，以及各卡实际显存和 P2P 检查结果。nvidia-smi 显示的 CUDA 版本与 PyTorch runtime、编译用 Toolkit 需要分别记录。

链路可能在空闲时降速。评估 PCIe 时应同时看最大能力和负载下实际状态，不能只截取空闲时的一行结果。

3. 用NCCL tests检查集合通信

先安装与目标环境匹配的 CUDA Toolkit、NCCL 开发库和编译工具，再从官方仓库构建：

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests

git rev-parse HEAD > ../evidence/nccl-tests-commit.txt

# 按实际安装位置修改路径
make -j CUDA_HOME=/usr/local/cuda NCCL_HOME=/usr/local

NCCL_DEBUG=INFO ./build/all_reduce_perf \
  -b 8M -e 256M -f 2 -g 8 \
  > ../evidence/all-reduce.log 2>&1

NCCL_DEBUG=INFO ./build/all_gather_perf \
  -b 8M -e 256M -f 2 -g 8 \
  > ../evidence/all-gather.log 2>&1

这里采用单进程控制八张 GPU 的测试方式，检查正确性、带宽和消息大小变化。正式训练通常是一卡一进程，因此还需在训练启动方式下验证实际通信表现。NCCL tests 官方仓库

不要直接把 busbw 当作某条 PCIe 链路的物理带宽，也不要把集合通信成绩写成模型训练 tokens/s。

五、QLoRA短测怎么设计？

建议从官方 PEFT SFT 示例开始，使用同一代码版本的训练脚本和 FSDP 配置，不把不同年代教程里的参数拼在一起。

代码入口：

• 官方训练脚本
• 官方 FSDP QLoRA 配置
• 官方启动示例

先获取代码并检查当前参数：

git clone https://github.com/huggingface/peft.git peft-example
cd peft-example

git rev-parse HEAD
python examples/sft/train.py --help

记录提交号后，后续对照实验始终使用同一提交和依赖环境。访问 Llama-2 权重前，需要取得模型访问权限并满足其许可条件。

首轮只验证一件事：能否稳定完成短训练

参数	首轮设置思路
模型	Llama-2-70B，固定 revision
序列长度	先从 512 开始，再逐步增加
micro-batch	每卡 1
LoRA rank	固定为 8，避免对照时同时修改
梯度累积	固定，并记录全局 batch
梯度检查点	开启，记录实现设置
基座量化	4-bit NF4
计算／量化存储 dtype	按所选 FSDP 示例配置保持兼容
CPU offload	单独记录，不与关闭 offload 的结果混写
训练步数	先做约 30 个优化器更新步骤的冒烟测试

bitsandbytes 的 FSDP-QLoRA 文档强调，量化存储 dtype 与模型 dtype 的匹配影响分片包装。bnb_4bit_quant_storage 不是随意添加的装饰参数，也不能用推理时的 device_map="auto" 替代训练分片方案。bitsandbytes FSDP-QLoRA 文档

不同版本的脚本可能使用不同的序列长度参数名，应以该提交的 --help 为准。不要把已经更名的参数当作硬件问题排查。

短测需要保存哪些结果？

指标	记录方式
每卡显存峰值	每个 rank 分别记录，不能只看 GPU 0
主机内存峰值	开启 offload 时必须记录
step time	明确是否指一个优化器更新步骤
训练 tokens/s	固定统计窗口内，全部 rank 实际处理 token 数÷墙钟时间
通信情况	NCCL 日志；需要归因时补充 profiler
checkpoint	保存成功，并完成一次恢复
稳定性	是否出现 OOM、超时、NaN 或进程退出

先排除加载和预热阶段，再延长到有代表性的稳定窗口。若存在 padding，应分别说明统计的是非 padding token，还是实际计算的 token 槽位。

训练 tokens/s 包含前向、反向和更新过程；推理 tokens/s 衡量生成过程，两者不能直接比较。

六、跑不通时，按失败阶段排查

现象	优先检查	下一步
加载阶段OOM	是否先在某卡构建完整基座；量化是否生效	检查加载路径、CPU RAM efficient loading 和 offload
第一轮反向OOM	序列、micro-batch、激活、包装粒度	先降低序列长度，再逐项调整
只有某张卡OOM	分片不均、其他进程占用、额外张量落卡	查看各 rank 日志和每卡峰值
八卡吞吐增长很小	通信路径、数据读取、CPU offload	结合时间线定位瓶颈
NCCL超时	进程异常、GPU可见性、共享内存、拓扑	先定位最早失败的 rank，再看通信日志
保存时OOM或失败	state dict 聚合、主机内存、磁盘空间	单独验证保存与恢复流程
出现NaN	dtype、学习率、数据异常、数值稳定性	固定环境，用较小样本定位

不要一遇到 NCCL 错误就长期设置 NCCL_P2P_DISABLE=1。它可以用于特定诊断，但会改变传输路径，对照时必须记录。

checkpoint 恢复也不能只保存 LoRA 权重。要恢复完整训练进度，还需要对应实现支持的优化器状态、调度器状态、随机状态和训练步数。

七、以算家云为例操作演示

对于没有本地八卡设备、希望先判断 70B QLoRA 是否值得继续投入的团队，可以把算家云（suanjiayun.com）作为资源验证候选。

**截至 2026-10-09，专业版 RTX 4090 24GB 按量价格为 1.98 元/卡时。**若实际八卡配置仍按这一单价计费，算力小时费用为：

8 × 1.98 = 15.84 元/小时

这是按单卡单价计算的预算，不代表当前一定存在可创建的同机八卡实例，也未包含独立计费的存储等资源。价格、库存和账单以实际页面为准。

操作顺序如下：

1. **先核对资源。**确认八张卡属于同一实例，型号和显存一致，并检查 CPU、主机内存和磁盘容量。
2. **选择环境并连接。**按镜像要求使用 SSH、JupyterLab 或 VS Code，首先运行环境检查命令。
3. **确认存储路径。**区分系统盘、数据盘和临时目录，把权重缓存、训练输出、日志和 checkpoint 放到明确可持久化的位置。
4. **先查拓扑，再跑短测。**保存 PCIe、P2P 和 NCCL 结果，然后执行固定参数的 QLoRA 冒烟测试。
5. **验收保存与恢复。**确认 checkpoint 能写入、能够恢复，再决定是否延长任务。

算家云帮助文档说明，保存项目镜像保存的是系统盘内容，不包含数据盘。训练数据和 checkpoint 需要单独确认备份方式，不能用"保存镜像"替代数据备份。

如果项目必须做全参数微调，或者需要长上下文、大 batch、严格完成时间，优先重新计算高显存配置及其实际互联条件。不要为了继续使用 4090，持续增加 offload 却忽略完成时间。

下一步只做一个动作：在候选实例上保存环境与拓扑报告，完成一次固定参数短训练及恢复测试。

八、选卡看完成成本，不只看小时价

对照配置应使用相同模型、数据、精度、序列长度、有效 batch 和训练目标，然后计算：

完成成本 =
资源小时价 × 实际占用小时
+ 存储及其他费用
+ 失败重跑成本

实际占用时间还包括环境准备、加载、保存和恢复验证。某个配置每小时便宜，但如果通信、offload 或重跑显著延长任务，完成成本可能更高。

跨卡型比较还要说明显存、软件栈和拓扑差异。不能把全部速度差异归因于 NVLink，也不能用 GPU 利用率单独证明训练效率。

九、常见问题

1. 八张4090的显存能直接合成192GB吗？

不能。框架可以分片或切分模型，但每张卡仍有独立上限和临时峰值，需要检查最吃紧的那张卡。

2. 8×4090能做70B全参数微调吗？

常见混合精度 AdamW 配置无法仅靠 192GB GPU 显存容纳全部训练状态。使用 CPU／NVMe offload 等方案时，需要另行验证容量、吞吐和时间成本。

3. 70B 4-bit只有约35GB，为什么还会OOM？

35GB 是理想原始权重估算。实际还有量化元数据、非量化层、激活、通信缓冲和加载峰值；普通 DDP 还可能让每卡持有完整基座。

4. 4090没有NVLink，还能用NCCL吗？

可以使用 NCCL，但实际传输路径与硬件、驱动和容器环境有关。是否支持 P2P、集合通信表现如何，需要在目标实例检查。

5. 为什么八卡没有比四卡快一倍？

可能受通信、数据读取、CPU offload、batch 或负载不均衡限制。增加卡数同时也可能增加通信开销，应结合 profiler 判断。

6. 什么时候值得在算家云验证8×4090？

任务是允许量化基座的 70B QLoRA 或量化推理，且能接受先做 PoC 时，可以考察专业版 RTX 4090 24GB。按截至 2026-10-09 的 1.98 元/卡时预算，先确认同机八卡资源及拓扑，再验证目标配置的短训练、保存和恢复。