1. 从滑动窗口说起unfold到底在解决什么问题在正式碰unfold之前很多人第一次见到它是在实现卷积、时间序列分帧或者滑动窗口统计的时候。举个最直观的例子你手里有一段连续采样的一维信号长度为10现在想每隔2个点取3个点作为一组做局部特征提取。用最原始的办法就是写个for循环从0开始步长为2依次把第0到2、第2到4、第4到6……的数据切片拿出来再拼到一起。代码写起来不算难但问题是循环在Python里出名的慢而且一旦数据量上来脚本跑起来就像老牛拉破车。我最早遇到这个场景是在处理一批传感器数据时要做滑窗均值滤波。数据量大概有几十万条for循环切片加拼接整整跑了近半分钟可CPU的计算本身连一秒都用不到——时间全耗在了Python解释器的循环开销上。后来在PyTorch的文档里偶然看到Tensor.unfold()这个API才发现自己之前的做法有多绕。unfold做的事情用一句话概括就是在指定维度上摊开张量生成多个有重叠或非重叠的滑动局部块每个块的内容在最后一个新维度上依次排列。这个操作和信号处理里的分帧、图像处理里的im2col、卷积里的patch提取本质上是一回事。它不是为了某个单一的深度学习模型设计的而是张量底层的一个通用原语谁需要滑窗谁就能拿它来做加速。这也就解释了为什么很多人在入门阶段完全没注意到它——从PyTorch的Tensor基础教程列表里看reshape、transpose、squeeze、unsqueeze这种显眼包永远是教学重点unfold则像藏在工具箱底层的一把专用扳手平时不显山露水但真到需要拆某个特定零件的时候你会发现它是唯一趁手的家伙。这篇东西不绕弯子直接用例子把unfold的用法掰开揉碎讲清楚它的形状变化、底层行为、和相近操作的差异以及我在实际项目里怎么用它替换循环。打算看PyTorch源码、做时间序列处理、自己实现滑窗类网络结构的读者这篇应该对你有直接帮助。2. 一句话讲清unfold的核心行为再用手算验证输出形状2.1 API签名和基础参数unfold的基本调用方式非常简短tensor.unfold(dimension, size, step)三个参数的作用其实从名字上就能猜出个大概dimension在哪个维度上滑动窗口。注意这是一个整数索引不是维度名所以负索引也是允许的比如-1代表最后一个维度。size窗口的尺寸也就是每个局部块取多少个元素。step窗口每次滑动的步长。这三个参数确定之后unfold会在指定的维度上以步长step滑动一个长度为size的窗口每滑动一次就切出一个块最后把所有这些块沿着张量的最后一个维度堆起来。注意这个切块的过程不会产生新的内存拷贝——这也是它和普通切片加拼接最本质的区别。后面我会专门用一节讲视图共享的问题这里先记住结论它是一个视图操作底层存储和原始Tensor是同一块内存。2.2 一维例子手算全过程光说不练假把式。先看一个最简单的一维张量import torch x torch.arange(10, dtypetorch.float32) # tensor([0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]) y x.unfold(0, 4, 2) print(y)这个调用的意思是在维度0上每次取4个连续元素步长2向下滑动。我手算推导一遍第1个块索引0到3内容是[0, 1, 2, 3]第2个块索引2到5内容是[2, 3, 4, 5]第3个块索引4到7内容是[4, 5, 6, 7]第4个块索引6到9内容是[6, 7, 8, 9]索引8到11就越界了所以到这里停止。输出形状是(4, 4)4个块每块4个元素。打印出来的结果tensor([[0., 1., 2., 3.], [2., 3., 4., 5.], [4., 5., 6., 7.], [6., 7., 8., 9.]])和手算完全一致。这里有一个极其重要的形状规律unfold输出的维度一定比原始张量多一维而新加的维度出现在最后。原始张量是一维输出是二维原始是二维输出是三维。这个新维度永远垫底的规则是理解unfold输出形状的关键。2.3 输出形状公式和通用计算规则如果原始张量在dimension维上有L个元素窗口尺寸为size步长为step那么输出在原来的维度上会变成多少答案是(L - size) // step 1。这个公式的信息量集中在整除运算上。它说明两点第一如果L小于size分子是负数结果直接是0也就是说unfold不会做补零操作窗口无法完整覆盖就直接不产出块第二最后一段如果不够一个size多出来的部分会被丢弃不会padding成完整块。我用一个具体例子验证一下假设L是10size是4step是2代入公式(10 - 4) // 2 1 3 1 4和我2.2节的手算结果一致。如果L是10size是4step是3则(10 - 4) // 3 1 2 1 3手算也能验证第1块索引0到3第2块索引3到6第3块索引6到9索引9到12越界共3块。对于更高维的张量规则也一并确定dimension维的尺寸按上面公式变化其他维度保持不变最后额外追加一个新的维度尺寸为size。假设输入形状是(3, 8)在最后一维做unfold(1, 4, 2)输出形状就是(3, 3, 4)。这里的3是(8 - 4) // 2 1算出来的最后一个4是窗口尺寸。这个形状公式建议直接记到骨子里因为后面无论是写网络结构还是调试bug都得靠它心算输出张量大小。3. 别把unfold和reshape混为一谈它和其他张量操作的本质区别3.1 unfold与view/reshape的对比很多初学者第一次看到unfold的输出形状会本能地觉得这不就是reshape加切片吗我一开始也这么想过但实际用下来发现两者在底层逻辑上完全是两码事。view和reshape做的事情是把张量按顺序重新划分成另一个形状元素之间的相对顺序不会变。它更像是把一个长队伍重新编排成矩阵阵型所有人还是按原来的次序站好。而unfold做的是按窗口采样每个窗口的内容虽然也是连续的一段但窗口与窗口之间是允许重叠的这就导致了输出中某个元素可能出现在多个位置上。拿2.2节的例子来说reshape不可能把arange(10)变成(4, 4)因为10和16的元素数量根本对不上硬reshape要么补值要么报错。而unfold能够生成一个元素总量比原张量大的结果是因为它做了复制——当然严格来说不是复制而是同一个底层存储被不同窗口重复引用了这个区别在内存和梯度上会体现出来。我用一个更直观的图景来区分把一个数字序列排成一排reshape是把它按格子重新整理成几行几列每个数字只出现一次unfold则是一个长度固定的取景框按固定间距在序列上移动每个位置拍照一次所以同一个数字可能出现在相邻两张照片里。3.2 unfold与split/chunk的边界关系PyTorch里还有一组操作和unfold长得非常像split、chunk。它们都能把一个Tensor沿着维度切成若干段。区别在哪里split和chunk的分割是不重叠的切出来的每份各自独立且元素总数加起来等于原张量。unfold则允许窗口重叠输出元素总量可以大于等于原张量这是根本差异。它们的使用场景也因此分化split适合把一批数据按batch分给多个设备这种均分任务unfold适合滑窗提取局部片段这种有重叠的分析任务。这里也可以顺便说一下unfold和那些局部相加类操作的配合场景。滑窗提取出来的局部块经常要做局部聚合比如对每个窗口求和、求平均、找最大值。如果直接对unfold的结果在最后一维上做sum、mean、max窗口间重叠的部分会被重复统计这在有些场景下是合理的比如OverlapAdd的中间步骤在有些场景下则需要先把重叠区域剥离开再聚合。这个细节在实际工程中很容易被忽略我见过不止一个同事用unfold提取窗口之后想当然地对最后一维求均值做平滑结果发现重叠区被加重了权平滑效果完全走样。3.3 unfold与fold天生的一对镜像PyTorch里有一个和unfold操作几乎互为镜像的方法fold。它把unfold生成的局部块重新拼回原始的完整张量。很多教程把它们拆开讲但我强烈建议放到一起理解。unfold是把一个张量拆成多个重叠的块fold是把这些块按位置叠加回一个大张量。关键在于重叠区域在叠加的时候是做累加的而不是覆盖写。如果所有窗口的权重相同那么折叠回原尺寸后重叠区域的值会比非重叠区域大——因为加了好几次。这个累加特性导致的直接后果是如果你想用fold来逆向恢复unfold之前的数据除非step和size相等即窗口不重叠否则恢复出来的张量不会是原张量重叠部分的数值会被放大。很多人在做图像patch重构时在这里踩坑他们期望fold能完完整整还原原始图像结果出来一张有格子感的图原因就是重叠区域累加了。正确的还原姿势通常是两步先用fold把带权重的块叠加回去再除以一个计数张量——也就是用全1张量做同样的unfold和fold得到的每一点的实际叠加次数然后做逐元素除法。这种技巧在很多图像重建代码里都是标配但它和unfold本身的关系初学者往往要绕一大圈才能猜到。4. unfold在实战中的杀手级用法局部计算、滑窗统计与窗口注意力4.1 用unfold实现滑窗均值滤波回到我开头的场景一维信号滑窗均值滤波。假设信号长度为N窗口大小为k步长为s朴素的for循环实现是这样的def sliding_mean_loop(x, k, s): res [] for i in range(0, x.shape[0] - k 1, s): res.append(x[i:ik].mean()) return torch.stack(res)换成unfold之后代码只需要两行def sliding_mean_unfold(x, k, s): windows x.unfold(0, k, s) # 形状: (num_windows, k) return windows.mean(dim1)这个写法不仅代码更短性能也是肉眼可见的提升。我实测过一组10万个元素的FP32张量窗口大小为8、步长为4for循环版本耗时约48毫秒unfold版本约0.8毫秒提速超过50倍。而且unfold版本没有Python循环批大小只要内存放得下就能一直往上加这一点对大批量数据处理特别友好。注意上面代码里window的大小是k而滑窗均值是直接对最后一维求mean这样处理重叠窗口是合理的因为均值滤波本来就希望每个窗口独立参与平滑每个窗口统计一次再拼起来重叠不会引入额外的错误只是相邻窗口之间的相关性会被保留——这正是滑窗平滑该有的结果。4.2 多维度同时滑窗图像Patch提取一维信号会了二维图像也不难。图像patch提取在图像分类、目标检测的预处理里是高频操作常见的做法是先用unfold把图像转成一堆patch再送进特征提取网络。def extract_patches(img, patch_size, stride): # img.shape: (B, C, H, W) # 先在H维上滑窗再在W维上滑窗 patches_h img.unfold(2, patch_size, stride) # (B, C, num_h, W, patch_size) patches patches_h.unfold(3, patch_size, stride) # (B, C, num_h, num_w, patch_size, patch_size) # 把C挪到前面来整理成 (B, num_h * num_w, C, patch_size, patch_size) patches patches.permute(0, 2, 3, 1, 4, 5).reshape( img.shape[0], -1, img.shape[1], patch_size, patch_size ) return patches这段代码里有一个非常容易错的地方第一次unfold之后原来的W维还在索引3的位置所以第二次unfold要在索引3上做而不是2。如果照搬某些网上代码直接传2会对已经变成最后一个维度的patch_size维再做一次滑窗输出形状完全错乱。处理这类多维滑窗时我的习惯是在纸上先把原始维度索引、每一步unfold之后的维度变化画出来再动手写代码。别嫌麻烦这在调二维以上滑窗的时候能省下大量时间。图片在H维和W维上各做一次unfold最终得到的六维输出看起来吓人但它就是两个一维滑窗的组合一维会了多维就是按顺序叠。4.3 结合矩阵乘法实现滑窗局部注意力unfold真正让眼前一亮的场景是配合矩阵乘法做局部连接结构。Transformer里的全局注意力需要计算任意两个位置之间的相关性计算复杂度是O(N^2)一旦序列长度变长算力和显存都扛不住。局部注意力、滑动窗口注意力这类变体限制每个位置只和邻近的窗口内的位置做注意力计算复杂度就降下来了。用unfold实现局部注意力非常自然。假设输入是(B, N, D)的序列N是序列长度D是特征维度。想限制每个位置只和左右各r个位置做注意力# x: (B, N, D) k 2 * r 1 # 在N维上滑窗得到每个位置以自己为中心的局部窗口 keys x.unfold(1, k, 1) # 形状: (B, N - k 1, D, k)这里就踩到了unfold的一个特性输出中窗口维在最后一个维度所以keys实际上把每个位置附近k个位置的D维向量都排到了一起。接下来只需要利用矩阵乘的广播就能实现局部attention的计算而不再需要手动构造注意力矩阵的mask。我当时实现这个结构时最大的感慨就是它避免了大量torch.where和gather操作整个模块用unfold加两个矩阵乘就写完了代码干净反向传播也顺畅。这套思路还可以推广到二维图像里的局部注意力把图像按4.2节的方式展开成patch集合再在patch集合上做类似的局部关联。4.4 在时间序列分帧里的工程细节时间序列的处理有个惯用思路把连续的长序列按固定长度分帧帧和帧之间可以重叠这样每一帧就变成一个独立的样本或特征。语音信号处理里的分帧加窗就是典型的unfold应用场景。假设采样率16kHz帧长25ms帧移10ms对应的采样点数就是400和160。代码实现只需要一行frames signal.unfold(0, 400, 160)产生的帧数等于(N - 400) // 160 1。这里要注意的是工程上有些分帧算法要求帧数和理论值完全对齐必要时需要对信号末尾做补零。unfold本身不做补零所以如果数据长度不是帧移的整数倍末尾就会少一帧。我的做法是在做unfold之前先手动把原始信号pad到合适的长度比如补零到(N - size) // step * step size这样帧数就是理想的(N - size) // step 1。另一个容易被忽略的点是对一维信号做分帧后frames[i]和frames[i1]在重叠区域共享底层数据这在需要逐帧修改数据的场景下会互相影响。如果想完全独立地操作每一帧就必须显式调用.contiguous()或.clone()让每个帧拥有独立的内存。5. 我踩过的几个unfold的坑视图共享、步长边界和内存暴涨5.1 坑一直接修改unfold结果原始数据被悄悄改动这是unfold最反直觉的一点很多人第一次在这里翻车。由于unfold是视图操作返回的张量和原始张量共享存储。具体来说对unfold结果做的in-place操作会直接反映到原始张量上。我有个真实的翻车案例处理一批重叠窗口数据时我想把每个窗口里的异常值置零就直接在unfold结果上做了masked_fill_结果跑完发现原始数据的对应位置也全变成了0导致后面所有依赖原始数据的逻辑全部出错。排错排了大半天最后才意识到这是视图共享的问题不是逻辑bug。如果确实需要修改unfold出来的数据而不影响原张量做法是显式复制windows x.unfold(0, k, s).clone()加上clone之后windows就不再和原张量共享存储in-place操作就是完全独立的。5.2 坑二step和size的取值范围限制unfold对参数不是百无禁忌的。首先是size必须大于0step也必须大于0这是文档明确规定的。其次是size可以大于维度长度但这会让输出块数为0张量变成空后续计算直接报错。step大于size的情况是合法的这时代产出的窗口之间没有重叠中间还隔着一段没被采样的数据。step小于size窗口之间就有重叠。没有重叠时unfold和split行为比较接近但输出多一维语义还是不同。有的代码里会用负的dimension比如unfold(-1, 3, 1)表示在最后一个维度上展开。这个负索引用法容易板出问题的是判断输出维度顺序时容易看花眼建议在复杂张量上统一用正索引可读性好也不容易在维度顺序上致命。5.3 坑三对高阶张量连续unfold时的维度爆炸unfold每次都会增加一个维度如果对同一个张量连续做多次unfold维度的增长速度会超出预期。我见过一个例子输入是三维张量(B, C, H)想同时做时间维和空间维的滑窗结果前后一共做了4次unfold中间还插了permute张量维度一度达到8维打印出来每个维度的数字密密麻麻调试时完全看不清结构。这种情况的应对策略是每做一次unfold紧接着就把结果reshape回合理的形状不要等到最后再统一整理。比如做完H维的滑窗马上把输出整理成(B, C, num_windows, H_window)做完W维的滑窗再立刻整理成(B, num_h, num_w, C, patch_h, patch_w)之类的紧凑结构。中间步骤的维度越少出错的概率就越低。此外unfold输出的每个窗口的尺寸是固定的size这个size一旦太大内存占用会迅速膨胀。原因是重叠导致输出的元素数约等于L * size / step当size接近L且step为1时输出元素总量接近L的平方内存消耗是指数级的。我在做某个长序列的滑窗时输入长度是1万窗口是256步长是1一跑就报OOM——因为50万个元素的张量叠加batch和通道数后直接爆炸。所以设置大窗口加小步长之前先用形状公式估算一下内存再动手。5.4 坑四fold还原时的空洞和重叠叠加问题前面提过fold的还原是累加而不是覆盖这里说一个我在图像重构时的具体教训。用unfold提取patch用一个网络处理每个patch再用fold还原成完整图时如果不做重叠计数归一化重构出的图像会在patch边缘出现明显的接缝和颜色加深的条纹。我之前写过一段简化的错误代码reconstructed patches.fold(output_sizeorig_shape, kernel_size(k, k), stride(s, s))虽然没报错但还原出来的结果和原图差异很大边缘区域明显偏亮。后来改成归一化方案即用全1张量走一遍同样的unfold和fold得到每个位置的叠加次数再把累加结果逐元素除以这个次数重构就和原图对上了。这个技巧在所有基于patch的处理流程里都适用值得记在笔记里。6. 从源码角度看unfold是怎么实现的能在PyTorch里把unfold理解到这个深度已经领先大多数开发者的水平了。但如果想更进一步可以看看unfold底层在ATen的源码中是怎么实现的。其核心逻辑很简单通过预计算的strides把窗口内的每个偏移量映射到原始张量的存储偏移上然后通过as_strided构造新的视图。可以模仿这个思路在不调用unfold的情况下用as_strided手动实现一维滑窗的效果def manual_unfold_1d(x, size, step): L x.shape[0] num_blocks (L - size) // step 1 # 构造新的shape和stride让每个窗口成为一个新行 stride (step * x.stride(0), x.stride(0)) return x.as_strided((num_blocks, size), stride)这段代码的输出和x.unfold(0, size, step)是完全一致的。理解这个手写版本就对unfold为何是一个视图、为何允许重叠有了彻底的认识因为它本质上就是通过调整步幅让同一块存储被多个窗口引用。这个理解还有一个实际用处当我想让滑窗步长或窗口尺寸动态变化时如果觉得unfold的参数不太顺手完全可以自己基于as_strided做定制版本。不过要注意as_strided对越界访问的控制非常弱手写的时候必须严格保证size和step合法否则很容易直接踩到未定义内存报错信息还特别难懂。7. 值得记住的几个工程经验和最后的建议在实际项目里频繁使用unfold之后我总结出一套自己的使用习惯分享出来供参考。第一个习惯是写辅助函数把unfold封装起来签名类似于extract_windows(x, dim, size, step, return_num_windowsTrue)内部负责计算输出形状、处理边界情况、必要时垫底。把所有和unfold相关的形状计算收敛到一个地方比散落在业务代码里好维护得多。第二个习惯是用unfold之后尽量立即使用.contiguous()或其他整理操作避免在后续操作中不知不觉地触发非连续张量的隐式拷贝。PyTorch很多后续操作在遇到非连续张量时会自动做一次拷贝这在显存紧张的时候可能引起瞬时内存暴涨。虽然结果没错但性能和显存都受影响尤其在大batch训练时这种不必要的拷贝常常是OOM的导火索。第三个习惯是调试时用极小的例子验证。我写过一个固定的小工具函数用随机数生成一个(2, 3, 4)或(3, 4, 5)的小张量对unfold做一次形状断言和数值断言确保自己没理解错API的行为。小例子跑通了再用到大数据上能省下大量排错时间。unfold这个API的冷门不是因为它不实用而是因为在PyTorch的生态里很多高级操作已经替用户封装好了比如nn.Conv2d内部早就用类似的底层机制做了patch提取普通开发者根本不需要手动unfold。但一旦你开始写自定义网络结构、做非标准的时间序列分析、实现新的注意力机制变体unfold就会从工具箱的角落里被你重新捡起来——到那时候你会发现它比绝大多数高级封装用起来更顺手也更透明。