Expected all tensors to be on the same device, cuda:0 and cpu 这个设备不匹配报错，在断点续训场景里非常高频：模型、数据已经搬到 cuda:0，但是优化器 SGD 内部保存的动量（momentum buffer）张量还留在 CPU。很多人只把 model.to (device)、data.to (device)，却忽略了优化器里的动量缓冲区不会跟着自动迁移；加载 checkpoint 时保存下来的动量张量是什么设备，恢复后它就在哪，直接造成一部分参数在 GPU、动量在 CPU，运算时报错。简单说：model、data、loss 移到 GPU 还不够，优化器里的动量张量也必须同设备，SGD、带动量的优化器都有这个坑，Adam 的 exp_avg 也是同类逻辑。
错误写法、稳妥写法对比表
| 写法 | 代码要点 | 问题 / 说明 |
|---|---|---|
| ❌ 常见踩坑 | model.load_state_dict(ckpt["model"]) opt.load_state_dict(ckpt["opt"]) model.to("cuda:0") | 先加载优化器状态，再移动模型；优化器动量张量留在 CPU |
| ✅ 推荐顺序 | model.to(device) opt = torch.optim.SGD(model.parameters(), lr=..., momentum=0.9) ckpt = torch.load(path) opt.load_state_dict(ckpt["opt"]) | 先建好优化器（参数已经在 cuda），再加载状态，动量张量会跟随参数设备 |
| ✅ 补救方案（动量在 CPU） | 遍历 opt.state 里的张量，手动 .to (device) | 适合老 checkpoint，动量已经保存在 CPU 的情况 |
核心知识点清单
- SGD 开启 momentum>0 后，优化器会为每个参数维护一份动量张量，存在 optimizer.state 字典里
- torch.load 默认按保存时的设备还原张量，不会自动跟随当前 model 的设备
- 优化器本身没有 .to(device) 方法，不会一键把内部缓存迁移 GPU
- 如果你先 load_state_dict 再把 model 挪去 cuda，动量缓冲区不会跟着动，这是恢复训练最经典踩坑顺序
- 无动量 SGD（momentum=0）不会维护动量 buffer，一般不会触发这个报错
手动迁移优化器动量的修复代码片段
device = torch.device("cuda:0")
model = MyModel().to(device)
opt = torch.optim.SGD(model.parameters(), lr=1e-3, momentum=0.9)
ckpt = torch.load("ckpt.pth")
opt.load_state_dict(ckpt["opt"])
把优化器state里所有张量迁移到目标设备
for p_state in opt.state.values():
for k, v in p_state.items():
if torch.is_tensor(v):
p_state[k] = v.to(device)
完整断点续训正确流程
- 实例化模型，立刻执行 model.to(device)
- 初始化优化器（SGD / 带动量），传入 model.parameters ()
- 加载 checkpoint 文件
- 加载模型权重 model.load_state_dict(ckpt["model"])
- 加载优化器状态 opt.load_state_dict(ckpt["opt"])
- 遍历优化器 state，把里面所有张量统一迁移到 device（兜底保险）
- 数据加载后，每个 batch 内 x, y = x.to(device), y.to(device)，再前向传播
排查步骤
- 打印设备：print(next(model.parameters()).device)，确认模型参数在 cuda:0
- 打印动量 buffer 设备：
for s in opt.state.values():
print(s['momentum_buffer'].device)
- 核对顺序：不要先加载优化器状态，再 to cuda
- 区分多卡 DDP 场景：DDP 保存的 checkpoint 和单卡设备逻辑不一样，容易引入额外设备错位
- 确认不是数据加载器的问题：dataloader 返回的 tensor 忘记 .to (device) 也会报一样的报错
【相关 FAQ】
问题 1：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，momentum=0 的 SGD 也会出现这个动量导致的设备报错吗？
回答 1：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，momentum=0 时 SGD 不会生成 momentum_buffer 动量缓存，一般不会因为优化器动量张量引发这个设备冲突报错。
问题 2：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，优化器有没有 .to () 方法直接一键把动量移到 cuda？
回答 2：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，PyTorch 原生优化器没有内置的 .to (device) 接口，只能手动遍历 opt.state 里的张量逐个迁移。
问题 3：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，Adam 优化器恢复训练出现同类设备错位，原理一样吗？
回答 3：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，原理一致，Adam 维护 exp_avg、exp_avg_sq 缓存张量，加载 checkpoint 后缓存还留在 CPU 时，同样需要遍历 state 迁移张量。
问题 4：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，为什么从头训练不会遇到这个问题，只有恢复断点才会？
回答 4：报错 Expected all tensors to be on the same device, cuda:0 and cpu：恢复训练重点检查 SGD 动量缓存，从头训练时优化器在模型已经移到 GPU 之后初始化，新建的动量 buffer 天然在 GPU；断点恢复是加载历史保存的缓存张量，会沿用保存时的设备（CPU），因此更容易踩坑。
【参考资料】
[2026-09-10]（PyTorch optimizer.state device mismatch resume training）PyTorch Discussion
[2026-08-12]（SGD momentum_buffer 断点加载设备错位解决方案）Stack Overflow
[2026-07-05]（checkpoint 保存与恢复，优化器内部张量设备说明）PyTorch 官方文档
【免责声明】
本文基于 PyTorch 原生优化器状态机制整理；DDP、FSDP、梯度检查点、自定义优化器场景下状态存储逻辑会不同；不同 PyTorch 版本对 optimizer.state 的存储结构略有差异；代码仅用于调试参考，正式训练脚本建议增加设备断言校验。
本文来自作者[驰粒传讯官]投稿，不代表乌兰科技网立场，如若转载，请注明出处：https://www.wlcbnews.com/rgzn/202611/755.html
评论列表（4条）
我是乌兰科技网的签约作者“驰粒传讯官”！
希望本篇文章《报错 Expected all tensors to be on the same device, cuda0 and cpu恢复训练重点检查 SGD 动量缓存》能对你有所帮助！
本站[乌兰科技网]内容主要涵盖：互联网行业的追踪与探索
本文概览：Expected all tensors to be on the same device, cuda:0 and cpu 这个设备不匹配报错，在断点续训场景里非常高频：模型、数据已经搬到 cuda:0，但是优化器 SGD 内部保存的动量（momentum buffer）张量还留在 CPU。很多人只把 model.to (device)、data.to (device)，却忽略了优化器里的动量缓冲区不会跟着自动迁移；加载 checkpoint 时保存下来的动量张量是什么设备，恢复后它就在哪，直接造成一部分参数在 GPU、动量在 CPU，运算时报错。简单说：model、data、loss 移到 GPU 还不够，优化器里的动量张量也必须同设备，SGD、带动量的优化器都有这个坑，Adam 的 exp_avg 也是同类逻辑。