在实际操作中，用QLoRA+PEFT微调大模型时，因CUDA上下文丢失触发的设备断言错误，是不少人都踩过的坑。下面这份排查与修复方案，希望能帮你一次性解决它。
在实际工作中，用QLoRA对Gemma、Llama、Qwen这类大模型做高效微调时，可能会遇到一个颇具迷惑性的报错：
RuntimeError: device >= 0 && device < num_gpus INTERNAL ASSERT FAILED at "../aten/src/ATen/cuda/CUDAContext.cpp":50 DeferredCudaCallError: CUDA call failed lazily at initialization with error: ...
这个错误并不是模型代码本身有bug，而是CUDA运行时的环境状态出了问题。最常见的情况是，在Jupyter Notebook里只重跑了一个单独的cell，而没有重启整个内核（kernel）。当内核被重启或长时间闲置后，PyTorch的CUDA上下文可能没有正确初始化，但后续代码（比如BitsAndBytesConfig触发的量化权重加载）却试图去访问一个无效的设备索引（比如device=1），而系统实际检测到的GPU数量是0，于是底层断言就炸了。
根本原因与验证方法
说到底，问题出在哪儿？
- 核心诱因：CUDA上下文没准备好，
torch.cuda.device_count()返回了0，但device_map={0: ""}或自动分配逻辑仍试图绑定到不存在的设备上。 - 怎么判断是不是这个坑？：在报错之前，插入下面这段诊断代码跑一下：
import torch print("CUDA a vailable:", torch.cuda.is_a vailable()) print("Number of GPUs:", torch.cuda.device_count()) print("Current device:", torch.cuda.current_device() if torch.cuda.is_a vailable() else "N/A")如果输出的结果是CUDA a vailable: False或者Number of GPUs: 0，那就基本确认了，环境确实没就绪。
推荐修复流程（按优先级排序）
清楚了问题根源，接下来看怎么治。下面按优先级给出一套方案。
1. 强制重置CUDA上下文（最有效）
⚠️ 关键原则：不要只重跑模型加载的那个cell，必须重启内核，然后把整个notebook从头到尾跑一遍
- 在Jupyter里：Kernel → Restart & Run All
- 在VS Code里：点右上角的「Restart Kernel and Run All Cells」
- 这么做，能确保PyTorch、CUDA驱动、显存管理器全部从头初始化，避免任何状态残留。
2. 显式指定可用设备并加固加载逻辑
就算CUDA看起来已经就绪了，也建议在代码里显式检查一下设备，并做好降级容错：
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig
# ✅ 强制初始化CUDA（这是关键一步！）
if torch.cuda.is_a vailable():
torch.cuda.empty_cache()
_ = torch.ones(1).cuda() # 触发上下文建立
model_id = "google/gemma-7b"
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_use_double_quant=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
)
tokenizer = AutoTokenizer.from_pretrained(model_id)
tokenizer.pad_token = tokenizer.eos_token # 确保pad token存在
# ✅ 安全的 device_map：自动适配单卡/多卡，避免硬编码
device_map = "auto" # 替代 {0: ""}，由accelerate自动分配
if not torch.cuda.is_a vailable():
device_map = "cpu"
print("⚠️ CUDA不可用，回退至CPU模式（仅用于调试）")
model = AutoModelForCausalLM.from_pretrained(
model_id,
quantization_config=bnb_config,
device_map=device_map,
trust_remote_code=True,
)
3. 环境与依赖加固（预防性措施）
除了代码层面的修复，环境本身也得保证稳定。先看看你现在用的版本，然后按下面的推荐来升级：
- 升级关键库至兼容版本（截至2026年4月推荐）：
pip install --upgrade \ torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 \ transformers==4.41.0 \ peft==0.12.0 \ accelerate==1.0.0 \ bitsandbytes==0.43.3 - 验证CUDA驱动与PyTorch是否匹配：
print(torch.version.cuda) # 应 ≥ 12.1 print(torch.__version__) # 应含 `+cu121` 后缀 !nvidia-smi | head -n 10 # 确认驱动版本 ≥ 535.x
注意事项与避坑提示
- 不要在已报错的内核里做“缝缝补补”：像
torch.cuda.init()这类手动初始化函数，在PyTorch 2.0+中已经被弃用了，强行调用可能引发更深层的问题。 device_map={0: ""}是过时写法：新版的accelerate要求使用"auto"、"balanced"或明确的设备字符串（如"cuda:0"），空字符串""已经不再支持。- 混合精度需要统一dtype：如果启用bf16，要确保
bnb_4bit_compute_dtype=torch.bfloat16，并且你的GPU支持（A100/H100/V100记得开启TF32）。 - 低显存设备建议：可以加上
--gradient_checkpointing和--low_cpu_mem_usage参数，进一步降低内存峰值。
总结
说白了，device >= 0 && device < num_gpus 这个错误，本质上是CUDA运行时状态没有对上号，跟QLoRA或模型本身关系不大。最靠谱的解法永远是：重启内核 → 全量运行 → 显式校验设备 → 使用device_map="auto"。再配合版本锁定和环境检查，这类问题基本就能降到接近零。训练稳定性不只看算法参数，底层硬件抽象层的健壮初始化同样不可忽视——这一点，是高效微调的基础设施前提。
