3、张量形状与内存布局：连续内存与非连续内存、strides与内存访问模式、view与reshape的内存影响
张量的形状，说白了就是它的「维度描述」。但形状背后藏着内存布局的秘密。我见过太多同学只盯着 shape 看，结果模型跑起来慢得离谱，显存还莫名其妙地涨。今天咱们就把这块硬骨头啃下来。
3.1 连续内存 vs 非连续内存
先问个问题：一个形状为 (3, 4) 的矩阵，在内存里是怎么存的？
答案是：按行优先（row-major）连续排列。也就是先把第 0 行的 4 个元素排好，再接第 1 行的 4 个，最后是第 2 行。这种排列方式叫 连续内存布局。
连续内存：张量元素在物理内存地址上是相邻的，没有间隙。
非连续内存：元素之间有「空洞」，地址不连续。
我刚开始做模型部署时，遇到过一个坑：用 PyTorch 加载预训练权重，发现显存占用比预期多了 30%。查了半天，原来是某个中间层的输出做了转置操作，导致内存不连续。后续的算子不得不做额外的拷贝，白白浪费了显存。
怎么判断一个张量是否连续？很简单：
import torch
x = torch.randn(3, 4)
print(x.is_contiguous()) # True
y = x.T # 转置
print(y.is_contiguous()) # False
你看，转置后的张量 shape 变了，但底层数据还是原来的排列方式。这就造成了不连续。
3.2 strides 与内存访问模式
strides（步长）是理解内存布局的关键。每个维度都有一个 stride，表示「沿着这个维度移动一步，在内存中需要跳过多少个元素」。
举个例子：
x = torch.randn(3, 4)
print(x.stride()) # (4, 1)
这意味着：
- 从第 0 行到第 1 行，需要跳过 4 个元素（stride[0] = 4）
- 从第 0 列到第 1 列，只需要跳过 1 个元素（stride[1] = 1）
对于转置后的张量：
y = x.T
print(y.stride()) # (1, 4)
stride 反过来了。这意味着沿着行方向移动，只需要跳 1 个元素；沿着列方向移动，反而要跳 4 个。这种「反直觉」的步长，就是非连续内存的根源。
我的经验：在写自定义 CUDA kernel 时，一定要检查输入张量的 stride。我曾经因为没处理非连续输入，导致 kernel 计算结果完全错误——它按连续内存的假设去读数据，读到的全是错位的值。
内存访问模式对性能影响巨大。连续内存访问可以充分利用 CPU/GPU 的缓存行（cache line）和内存带宽。非连续访问则会导致：
- 缓存命中率下降
- 内存带宽利用率降低
- 显存碎片化加剧
我做过一个测试：对一个 (1024, 1024) 的矩阵做逐元素加法，连续版本耗时 0.3ms，非连续版本耗时 2.1ms。差了整整 7 倍。你想想看，如果模型里到处都是非连续张量，性能损失会有多大。
3.3 view 与 reshape 的内存影响
这两个函数看起来差不多，但内存行为天差地别。
| 操作 | 是否共享内存 | 要求连续 | 典型场景 |
|---|---|---|---|
view() |
是（返回视图） | 必须连续 | 形状变换，不改变数据 |
reshape() |
可能共享，可能拷贝 | 不强制连续 | 安全变换，自动处理不连续 |
view() 只改变「怎么看」数据，不改变底层内存。所以它要求输入张量必须是连续的。如果对非连续张量调用 view，会直接报错：
x = torch.randn(3, 4)
y = x.T # 非连续
try:
z = y.view(12) # 报错！
except RuntimeError as e:
print(e) # view size is not compatible with input tensor's size and stride
reshape() 则聪明一些。如果输入连续，它直接返回视图；如果不连续，它会先拷贝一份连续的数据，再返回视图。这个「隐式拷贝」就是显存消耗的隐形杀手。
我曾经踩过的坑：在训练一个 Transformer 模型时，每次 forward 都调用了 reshape 来调整 attention 矩阵的形状。结果显存从 8GB 涨到了 12GB。排查后发现，reshape 在每次调用时都做了内存拷贝，导致中间结果翻倍。改成 view 后，显存立刻降回 8GB。
所以我的建议是：
- 确定张量连续时，优先用
view() - 不确定是否连续，或者需要处理非连续输入时，用
reshape()但要注意显存开销 - 如果频繁调用 reshape，考虑在关键路径上手动
contiguous()一次，避免重复拷贝
3.4 知识体系总览
下面这张图总结了张量形状与内存布局的核心关系：
3.5 实战建议
说了这么多，总结几条我实际项目中的经验：
- 养成检查 is_contiguous() 的习惯。在自定义算子或性能敏感路径上，加个断言或日志，提前发现非连续张量。
- 谨慎使用转置和切片。这些操作几乎都会产生非连续视图。如果后续需要频繁访问，考虑手动 contiguous() 一次。
- view 优先，reshape 兜底。在确定连续的情况下用 view，不确定时用 reshape 但监控显存变化。
- 理解 stride 的含义。写 CUDA kernel 时，stride 就是你的内存访问模式。用对 stride，性能翻倍。
我个人习惯在模型 forward 函数的开头加一行 for name, param in self.named_parameters(): assert param.is_contiguous()。虽然有点粗暴，但能帮我早期发现很多问题。
嗯，关于张量形状和内存布局，今天就聊到这儿。记住一句话：形状是表象，内存布局才是本质。搞懂了 strides 和连续性，你就能真正掌控显存的使用。