1. 张量复制到底在复制什么
刚接触PyTorch那会儿，我一直以为b = a就是把a的值复制一份给b。直到有一次训练到一半，发现改了一个中间变量的值，结果前面算好的特征全变了，排查了大半天才反应过来——问题出在赋值上。这个坑几乎每个PyTorch新手都会踩，而且踩的时候往往不自知，因为代码不报错，只是结果悄悄错了。
张量复制这件事，表面上看就是“把一个张量变成另一个张量”，但里面牵扯到的东西比想象中多：内存布局、存储共享、计算图、梯度传播、设备迁移，每一个都会影响你最终拿到的是不是一个“干净”的副本。用错了复制方式，轻则浪费显存，重则让梯度回传出错，模型训练直接跑偏。
这篇内容适合所有正在用PyTorch做深度学习的人——不管你是刚学会torch.tensor()的新手，还是已经能写完整训练循环的老手，张量复制这个基础操作里总有一些细节是你没注意到的。我会把浅拷贝、深拷贝、clone、detach、copy_、设备间复制这些操作掰开揉碎讲清楚，配上可以直接跑的代码和实测结果，让你以后遇到复制相关的bug能一眼定位。
2. 为什么张量复制这么容易出错
2.1 从一次显存爆炸说起
我之前做过一个图像分割的项目，输入是[batch, 3, 512, 512]的张量。中间有个步骤需要保存原始输入用于后续的跳跃连接，我随手写了original = input_tensor，然后对input_tensor做了归一化和裁剪。训练跑起来显存占用比预期高了将近一倍，batch size只能开到原来的一半。
后来用torch.cuda.memory_allocated()一查才发现，original和input_tensor指向的是同一块显存，我以为的“保存”根本没有创建新数据，只是多了一个引用。更麻烦的是，我对input_tensor做的原地操作直接改掉了original的值，跳跃连接拿到的已经是被处理过的数据，模型效果自然好不了。
这个例子说明一个核心问题：PyTorch的张量赋值默认是引用传递，不是值传递。b = a之后，a和b是同一个对象的两个名字，底层共享同一块内存。你改任何一个，另一个跟着变。
2.2 存储、视图与计算图的三层关系
要搞清楚复制，得先理解PyTorch张量的三层结构。
最底层是存储（Storage），它是一块连续的内存区域，真正存放数据的地方。一个存储可以被多个张量共享。
中间层是张量（Tensor），它包含一个指向存储的引用，加上一些元信息：形状（shape）、步长（stride）、偏移量（offset）、数据类型（dtype）。同一个存储可以对应多个张量，每个张量用不同的形状和步长去“看”这块内存，这就是视图（View）。
最上层是计算图（Computation Graph），只有需要梯度的张量才有。它记录了这个张量是怎么算出来的，用于反向传播。
复制操作发生在哪一层，决定了你得到的是什么：
| 操作 | 是否新建存储 | 是否保留计算图 | 是否共享数据 |
|---|---|---|---|
b = a | 否 | 是（同一节点） | 完全共享 |
b = a.view(...) | 否 | 是 | 完全共享 |
b = a.clone() | 是 | 是 | 不共享 |
b = a.detach() | 否 | 否 | 完全共享 |
b = a.clone().detach() | 是 | 否 | 不共享 |
b = a.detach().clone() | 是 | 否 | 不共享 |
b = torch.tensor(a) | 是 | 否 | 不共享 |
这张表建议存下来，遇到复制相关的问题先对照一遍，能省很多排查时间。
2.3 什么时候必须用真正的复制
不是所有场景都需要深拷贝。判断标准很简单：如果你后续会修改其中一个张量，而另一个张量需要保持原值，就必须用真正的复制。
典型场景包括：
- 保存模型输入用于残差连接或跳跃连接
- 在数据增强时保留原始样本
- 需要对比修改前后的张量值
- 将张量存入列表或字典供后续使用
- 多任务学习中不同分支共享底层特征
反过来，如果只是临时读一下值、不做修改，用引用或视图反而更省内存。比如print(a.shape)这种操作，完全不需要复制。
3. clone、detach与copy_的实战区别
3.1 clone：最常用的深拷贝
clone()是PyTorch里最标准的复制方法。它会创建一个新的存储，把原张量的数据完整复制过去，同时保留计算图关系。
import torch a = torch.tensor([1.0, 2.0, 3.0], requires_grad=True) b = a.clone() print(a.data_ptr()) # 例如 140234567890 print(b.data_ptr()) # 例如 140234567891，不同 b[0] = 100.0 print(a) # tensor([1., 2., 3.], requires_grad=True)，不受影响 print(b) # tensor([100., 2., 3.], grad_fn=<CloneBackward>)注意b的grad_fn是CloneBackward，说明计算图被保留了。反向传播时，梯度会通过clone操作传回a。这是clone和detach最本质的区别。
clone的内存开销是实打实的：复制一个[64, 3, 224, 224]的float32张量，大约需要64 * 3 * 224 * 224 * 4字节，也就是约38.5MB。如果模型中间有大量clone操作，显存会涨得很快。
提示：
clone()默认使用与原张量相同的内存格式。如果原张量是非连续（non-contiguous）的，clone出来的张量会是连续的，这会影响后续的view操作是否可用。
3.2 detach：切断计算图但不复制数据
detach()返回一个与原始张量共享存储的新张量，但脱离了计算图。它不复制数据，只是换了一个“不需要梯度”的视角。
a = torch.tensor([1.0, 2.0, 3.0], requires_grad=True) b = a.detach() print(a.data_ptr() == b.data_ptr()) # True，共享存储 print(b.requires_grad) # False b[0] = 100.0 print(a) # tensor([100., 2., 3.], requires_grad=True)，a也被改了这个行为经常让人困惑：明明detach了，怎么改b还会影响a？因为detach只切断计算图，不切断存储共享。要同时切断两者，得用clone().detach()或者detach().clone()。
那clone().detach()和detach().clone()有什么区别？从结果上看，两者得到的张量都不需要梯度、不共享存储。区别在中间过程：clone().detach()先复制（此时还在计算图上），再脱离；detach().clone()先脱离，再复制。前者会短暂创建一个带梯度的中间张量，后者不会。在显存紧张的场景下，detach().clone()更省一点。
3.3 copy_：原地复制到已有张量
copy_()是一个原地操作，把源张量的数据复制到目标张量中，目标张量的存储不变。
a = torch.tensor([1.0, 2.0, 3.0]) b = torch.zeros(3) b.copy_(a) print(b) # tensor([1., 2., 3.]) print(a.data_ptr() == b.data_ptr()) # Falsecopy_的典型用途是模型参数更新、缓冲区填充、设备间数据传输。它的好处是不需要重新分配内存，适合在循环中反复使用同一个目标张量。
但copy_有个坑：如果源张量和目标张量形状不匹配，会报错。而且如果目标张量需要梯度，copy_会破坏计算图，PyTorch会给出警告。所以copy_一般用在torch.no_grad()上下文里。
3.4 三种方法的选型对照
| 需求 | 推荐方法 | 理由 |
|---|---|---|
| 保存中间结果供反向传播用 | clone() | 保留计算图，梯度能正确回传 |
| 只需要值，不需要梯度 | detach().clone() | 省显存，避免意外梯度 |
| 原地更新已有张量 | copy_() | 不重新分配内存，效率高 |
| 临时查看数据 | 直接引用或detach() | 零开销 |
| 跨设备复制 | .to(device)或.cuda() | 自动处理设备迁移 |
4. 设备间复制与性能优化
4.1 CPU与GPU之间的复制
把张量从CPU搬到GPU，或者反过来，是日常操作。.to(device)和.cuda()都会创建新的存储，属于深拷贝。
cpu_tensor = torch.randn(1000, 1000) gpu_tensor = cpu_tensor.to('cuda') print(cpu_tensor.data_ptr() == gpu_tensor.data_ptr()) # False print(gpu_tensor.device) # cuda:0设备间复制的开销主要来自PCIe带宽。以PCIe 3.0 x16为例，理论带宽约16GB/s，实际传输效率大概在10-12GB/s。复制一个100MB的张量，大约需要8-10毫秒。如果训练循环里频繁在CPU和GPU之间倒腾数据，这些毫秒会累积成可观的延迟。
优化建议：尽量在GPU上完成所有计算，只在必要时把结果传回CPU。比如计算loss的时候，如果只需要一个标量值做日志，可以用.item()直接取值，而不是把整个张量搬回CPU。
# 不推荐：整个张量搬回CPU loss_cpu = loss.to('cpu') print(loss_cpu) # 推荐：只取标量值 print(loss.item()).item()只同步一个标量，开销远小于传输整个张量。
4.2 非阻塞复制与重叠计算
PyTorch支持非阻塞复制，通过non_blocking=True参数实现。它的原理是利用CUDA的异步传输能力，让数据传输和GPU计算重叠进行。
gpu_tensor = cpu_tensor.to('cuda', non_blocking=True)但非阻塞复制有个前提：源数据必须是锁页内存（pinned memory）。普通CPU内存是分页的，操作系统可能随时把它换出，CUDA无法安全地异步读取。锁页内存通过pin_memory()创建：
pinned_tensor = cpu_tensor.pin_memory() gpu_tensor = pinned_tensor.to('cuda', non_blocking=True)在DataLoader里，设置pin_memory=True会自动把batch数据放到锁页内存，配合non_blocking=True就能实现数据加载和GPU计算的重叠。这个技巧在数据量大、GPU计算相对较轻的场景下效果明显，能提升10%-30%的吞吐量。
注意：锁页内存会占用物理内存，不能无限使用。一般设置为总内存的10%-20%比较安全。
4.3 原地操作与内存复用
PyTorch提供了一批原地操作，比如add_()、mul_()、zero_()、fill_()。它们直接在原张量的存储上修改，不创建新存储。
a = torch.tensor([1.0, 2.0, 3.0]) a.add_(10) print(a) # tensor([11., 12., 13.])原地操作省内存，但在需要梯度的场景下要格外小心。如果a参与了计算图，原地修改会导致反向传播时用到的值已经不是前向时的值，梯度算错。PyTorch会检测到这种情况并报错：
RuntimeError: a leaf Variable that requires grad is being used in an in-place operation.所以原地操作一般用在torch.no_grad()里，或者用在不需要梯度的张量上，比如模型推理阶段的缓冲区更新。
5. 常见问题与排查技巧
5.1 改了b，a也变了
这是最高频的问题，根本原因是赋值或detach没有创建新存储。
排查方法：打印两个张量的data_ptr()，如果相同，说明共享存储。
print(a.data_ptr(), b.data_ptr())解决方法：根据需求选择clone()或detach().clone()。
5.2 clone之后梯度回传出错
有时候clone之后反向传播报错，提示“梯度形状不匹配”或“试图第二次反向传播”。这通常是因为在clone之后又做了原地操作，或者clone的张量被用在了多个计算路径上。
排查思路：检查clone之后的张量是否被原地修改过。如果有，改成非原地操作，或者先detach再clone。
5.3 显存占用比预期高
如果发现显存占用远超模型参数量，大概率是某处复制了不该复制的张量。用torch.cuda.memory_summary()查看显存分配详情，重点关注那些生命周期很长的中间张量。
常见原因：
- 在循环里反复
clone但没有释放旧张量 - 保存了不需要梯度的中间结果却用了
clone而不是detach().clone() - DataLoader的
pin_memory设置过大
5.4 跨设备复制后计算结果不对
CPU和GPU的浮点运算精度可能略有差异，尤其是float16。如果发现复制到GPU后结果和CPU不一致，先检查dtype是否一致。
print(cpu_tensor.dtype, gpu_tensor.dtype)另外，.to(device)默认会转换dtype吗？不会。它只搬设备，不改类型。如果需要同时改类型，要显式指定：
gpu_tensor = cpu_tensor.to('cuda', dtype=torch.float16)5.5 常见问题速查表
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 改b导致a变化 | 共享存储 | 用clone()或detach().clone() |
| 梯度回传报错 | 原地操作破坏计算图 | 改用非原地操作 |
| 显存异常高 | 不必要的深拷贝 | 用detach()替代clone() |
| 设备复制慢 | 未用锁页内存 | pin_memory()+non_blocking=True |
| 复制后值不对 | dtype或设备不一致 | 检查.dtype和.device |
view报错 | 张量非连续 | 先.contiguous()再view |
6. 几个我踩过的坑和实用建议
第一个坑是关于clone和contiguous的关系。有一次我对一个转置后的张量做clone，然后想用view改变形状，结果报错说张量不连续。原来clone默认保留原张量的内存布局，转置后的张量是非连续的，clone出来还是非连续。解决办法是clone().contiguous()，或者直接用.reshape()代替.view()，reshape会自动处理连续性问题。
第二个坑是关于detach在优化器更新中的使用。手动实现梯度下降时，我写过这样的代码：
with torch.no_grad(): param = param - lr * param.grad这里param - lr * param.grad会创建一个新张量，然后赋值给param。但param原本是模型参数的引用，重新赋值后，模型内部的参数并没有更新，只是局部变量变了。正确做法是用param.data.sub_(lr * param.grad)或者param.copy_(param - lr * param.grad)，保证原地更新。
第三个坑是关于多GPU训练中的复制。用DataParallel时，输入数据会被自动切分并复制到各个GPU上。如果模型里有跨GPU的共享张量，复制行为可能不符合预期。这种场景建议用DistributedDataParallel，它对复制的控制更精细。
最后分享一个调试技巧：在怀疑复制出问题的地方，插入assert检查data_ptr：
assert a.data_ptr() != b.data_ptr(), "a和b共享存储，可能不是真正的复制"这个断言在开发阶段能帮你快速定位问题，上线前去掉即可。养成检查data_ptr的习惯，能避免很多隐蔽的bug。
