这一章，专门解决一个 PyTorch 初学者最容易踩的坑：为什么明明只是改个形状，view() 却突然报错？为什么 transpose 之后，模型好像变慢了？为什么加一个 contiguous()，代码又能跑了？

答案不在表面形状里，而在 Tensor 的真实内存布局里。

Tensor 不是一张表。Tensor 是一块 Storage，加上一组解释规则。你看到的是二维、三维、四维；底层看到的是一维连续内存、sizes、strides、storage_offset。

1. Tensor = Storage + 元数据

很多人把 Tensor 理解成“多维数组”。这个说法能入门，但不够深入。PyTorch 真正的设计是：数据放在 Storage 里，TensorImpl 记录如何解释这块数据。

• Storage：真正保存数据的线性内存，可以理解成一个一维仓库。

• sizes：告诉你这个 Tensor 看起来是什么形状。

• strides：告诉你沿着每个维度移动一步，底层要跳过几个元素。

• storage_offset：告诉你从 Storage 的哪个位置开始读。

• dtype / device：告诉你数据类型和所在设备，比如 float32、cpu、cuda:0。

所以，一个 Tensor 的“形状”不是数据本身。它只是解释数据的一种视角。

2. Stride 是什么：它决定 Tensor 怎么读内存

Stride 是理解 Tensor 内存机制的钥匙。官方文档对 stride 的解释很直接：它表示在某个维度上，从一个元素走到下一个元素时，需要跳过多少个底层元素。

比如：

import torch
a = torch.arange(12).reshape(3, 4)
print(a.shape) # torch.Size([3, 4])
print(a.stride()) # (4, 1)

这说明：

• 列方向移动一步，底层只移动 1 个元素。

• 行方向移动一步，底层要移动 4 个元素。

• a[2,3] 的真实位置 = 0 + 2 × 4 + 3 × 1 = 11。

这就是 Tensor 的坐标换算。你写的是 a[2,3]，PyTorch 读的是 Storage[11]。

3. View：不复制数据，只换一种看法

PyTorch 的 View 很强大。它可以让多个 Tensor 共享同一块底层数据，只改变形状、步长或偏移。官方 Tensor Views 文档也明确说明：View Tensor 会共享 base Tensor 的底层数据，这样可以避免显式拷贝。

看一个最经典的例子：

a = torch.arange(12).reshape(3, 4)
b = a.t()
print(a.shape, a.stride()) # (3, 4), (4, 1)
print(b.shape, b.stride()) # (4, 3), (1, 4)

a 和 b 看起来不一样，但很多情况下它们背后还是同一块 Storage。变化的是 stride：

• 原 Tensor：行优先读取，stride 是 (4,1)。

• 转置 View：换成另一种坐标解释，stride 变成 (1,4)。

• 数据没搬家，只是读法变了。

这就是 PyTorch 快的原因之一。很多变形操作不是复制，而是改元数据。

4. contiguous 到底是什么意思

contiguous 的意思是：这个 Tensor 当前的逻辑顺序，和底层 Storage 的物理顺序一致。

对一个二维矩阵来说，最容易理解的连续布局就是：一行挨着一行存。第一行存完，接着存第二行，再接着存第三行。

比如 shape=(3,4)，默认连续布局的 stride 就是 (4,1)。

如果转置后 shape=(4,3)，但 stride=(1,4)，它仍然能正确读数据，只是读的时候会跳来跳去。这个时候它通常不是默认意义上的 contiguous。

官方 contiguous 文档的核心意思是：返回一个内存连续的 Tensor；如果本来已经符合指定内存格式，就直接返回自身。

a = torch.arange(12).reshape(3, 4)
b = a.t()
print(b.is_contiguous()) # False
c = b.contiguous()
print(c.is_contiguous()) # True
print(c.stride()) # (3, 1)

这一步很关键：b.contiguous() 不是简单打个标记。它可能真的复制了一份新数据。

5. 为什么 view() 经常报错

view() 很挑剔。它想做的是“只改元数据，不复制数据”。所以它必须保证新形状能被当前 Storage、stride、offset 正确解释。

一旦当前 Tensor 的内存布局太绕，view() 就可能失败。

a = torch.arange(12).reshape(3, 4)
b = a.t()
# b 是非连续 View
# b.view(12) 可能报错
c = b.contiguous().view(12)

这里要记住一句话：

view() 的底层逻辑是尽量不动数据，只换解释方式。解释不了，就报错。

reshape() 则更灵活。它会先尝试走 view 的无复制路线。如果不行，可能自动复制一份连续内存。

所以 reshape 不是绝对零拷贝。它更方便，但也更容易让你忽略背后的内存复制。

6. TensorImpl 为什么这么重要

从源码角度看，Tensor 本身非常轻。真正关键的是 TensorImpl。PyTorch GitHub 源码里对 TensorImpl 的注释非常清楚：它保存指向 Storage 的指针，也保存 sizes、strides 等描述当前视图的元数据。

你可以把源码链路理解成这样：

• Python 层调用 x.view()、x.stride()、x.contiguous()。

• C++ 层拿到 Tensor / TensorBase。

• Tensor 指向 TensorImpl。

• TensorImpl 里记录 sizes、strides、storage_offset、storage。

• StorageImpl 里才真正管理 data_ptr，也就是底层内存。

所以 view、transpose、narrow、permute 这类操作，很多时候不是在搬数据，而是在创建新的 TensorImpl 视角。

而 contiguous() 的作用，就是在必要时重新申请一块更符合当前逻辑顺序的 Storage，把数据按新顺序拷贝进去。

7. storage_offset：切片为什么经常变成非连续

切片也会改变 Tensor 的元数据。尤其是 storage_offset。

a = torch.arange(12).reshape(3, 4)
b = a[:, 1:3]
print(b.shape) # (3, 2)
print(b.stride()) # 通常仍然是 (4, 1)
print(b.storage_offset())
print(b.is_contiguous())

b 看起来是一个 3×2 的小矩阵，但它在原 Storage 里不是一块紧密排列的数据。每行取中间两列，换到下一行时，中间会跨过没有被选中的元素。

所以它很可能不是 contiguous。

这也是为什么切片之后再 view，经常会遇到报错。

8. memory_format：contiguous 也有格式差异

还有一个容易忽略的点：contiguous 不只有默认一种格式。图像模型里经常遇到 NCHW 和 NHWC 两种布局。PyTorch 支持通过 memory_format 来判断或转换不同的连续格式。

常见写法：

x = torch.randn(8, 3, 224, 224)
print(x.is_contiguous())
print(x.is_contiguous(memory_format=torch.channels_last))
y = x.contiguous(memory_format=torch.channels_last)

对视觉模型来说，channels_last 在某些硬件和算子上可能更友好。后面讲 GPU 性能优化时，我们还会再深入。

9. 常见坑：这些问题都和内存布局有关

这里不要死记 API。你只要抓住一个核心问题：当前 Tensor 是不是只是换了一个视角？如果是，它可能共享 Storage，也可能不是 contiguous。

当你准备做 view、flatten、permute、transpose、模型输入前的 reshape 时，最好先检查：

print(x.shape)
print(x.stride())
print(x.storage_offset())
print(x.is_contiguous())

这四行，比盲目加 contiguous() 更有价值。

10. 总结

以后你看到 Tensor 变形，不要只看 shape。

真正要看的是：

• 它底层是不是同一块 Storage？

• 它的 stride 有没有变？

• 它是不是从 storage_offset 开始读？

• 它的逻辑顺序和物理顺序是否一致？

• 这一步到底是零拷贝，还是偷偷复制了新内存？

PyTorch 的 Tensor 很灵活，也很容易误用。

你理解了 Storage、Stride、Offset，就真正摸到了 Tensor 的底层骨架。

从这一章开始，你不再只是会调 API，而是开始理解 PyTorch 为什么这样设计。