1. 计算机视觉学术速递到底在速递什么

第一次看到"计算机视觉学术速递[5.25]"这个标题，很多人会以为是一份简单的论文列表。实际上，这类速递内容的核心价值在于把当天或近期冒出来的新工作做一次快速筛选和归类，帮你在信息过载的环境里抓住真正值得花时间读的东西。计算机视觉这个方向每天都有大量新论文上传，光靠刷列表根本看不过来，所以速递的本质是"降噪"——把Transformer、扩散模型、多模态融合这些热词背后的实际进展挑出来，告诉你哪些是真有新东西，哪些只是换个名字重新包装。

我自己跟踪这个方向有几年了，最大的感受是：Transformer架构从2020年之后几乎渗透到了计算机视觉的每一个子任务里。从最早的ViT把图像切成patch做分类，到Swin Transformer引入窗口注意力解决高分辨率下的计算量问题，再到各种针对特定场景改造的变体，这条技术线已经非常清晰。速递里如果出现Transformer相关的工作，我会优先看它到底改了什么——是改了注意力机制的计算方式，还是改了token的构造方法，还是纯粹在训练策略上做文章。这个判断习惯帮我省了大量时间。

这份速递适合谁看？如果你是刚进实验室的研究生，需要快速了解某个子方向的现状，速递能帮你建立地图感；如果你是在做计算机视觉大作业的本科生，速递里的方法概述和代码线索能让你少走弯路；如果你是已经工作的算法工程师，速递能帮你判断某个新技术值不值得跟进落地。不同基础的人看同一份速递，收获点不一样，但前提是你得知道怎么读。

2. Transformer在视觉任务里的核心逻辑拆解

2.1 从自注意力到视觉token化

Transformer最早是为自然语言处理设计的，核心是自注意力机制。放到计算机视觉里，第一个要解决的问题就是：图像是二维的像素网格，怎么变成Transformer能吃的序列？ViT的做法很直接，把图像切成固定大小的patch，比如16x16，每个patch拉平成一个向量，再经过线性映射变成token。这一步看起来简单，但patch大小的选择直接影响模型能捕捉到的细节粒度。patch越小，token越多，计算量按平方增长；patch越大，token越少，但每个token承载的信息更杂。

我实际跑过ViT的几种配置，patch=16在ImageNet上是个比较平衡的选择，patch=32会明显损失细粒度信息，patch=8则显存吃不消。这个经验在速递里读论文时很有用——看到有人声称用极小的patch取得了好效果，第一反应应该是去看他怎么解决计算量问题的，通常要么是用了稀疏注意力，要么是做了token合并。

Swin Transformer的思路更巧妙，它不搞全局注意力，而是在局部窗口内做自注意力，然后通过移位窗口让不同窗口之间产生信息交换。这个设计把计算复杂度从平方级降到了线性级，让Transformer能处理更高分辨率的输入。速递里如果出现Swin的变体，我会重点关注它的窗口划分策略和移位方式有没有新意。

2.2 视觉Transformer的几种典型改造路线

从速递里读多了会发现，视觉Transformer的改造基本围绕几条路线走。第一条是注意力机制的稀疏化，代表工作包括Swin、Twins、CSWin等，核心思路都是减少需要计算注意力的token对数量。第二条是token的动态管理，比如Token Merging、EViT这类工作，在推理过程中逐步合并或丢弃不重要的token，换取速度提升。第三条是引入卷积的先验，比如Conformer、CMT，把卷积的局部归纳偏置和Transformer的全局建模能力结合起来。

这几条路线背后其实是在回答同一个问题：视觉任务到底需要什么样的注意力？纯全局注意力计算量太大，纯局部注意力又丢了长距离依赖，所以大家都在找中间地带。我个人的判断是，没有一种改造能通吃所有任务。分类任务对全局信息需求高，检测和分割更依赖多尺度特征，所以速递里看到某个方法在分类上刷了新高，不要急着往检测任务上套，先看它的token设计是否支持多尺度。

2.3 速递里怎么快速判断一篇Transformer论文的含金量

速递通常只给标题和摘要，怎么在几分钟内判断值不值得精读？我的做法是看三个点。第一，看它改的是哪个环节——是tokenizer、注意力计算、还是训练目标。改tokenizer的工作往往影响面最大，因为下游所有任务都依赖token表示。第二，看实验对比的对象——如果只跟同量级的Transformer比，说服力有限；如果跟卷积网络和Transformer都做了充分对比，可信度更高。第三，看有没有开源代码——速递里如果标注了代码链接，我会优先看代码结构，因为很多论文的方法描述和实际实现之间有gap，读代码比读论文快。

注意：速递里的论文标题经常用很花哨的缩写，比如PDFormer、MultiLevel等，不要被名字唬住，直接看它解决的是什么具体问题。很多工作只是把已有方法换个场景应用，创新度有限。

3. 从速递到实操：Transformer模型复现的关键步骤

3.1 环境准备与依赖选择

看到速递里感兴趣的工作，下一步就是复现。我一般从环境开始，PyTorch是首选，版本建议1.12以上，因为很多新的注意力实现依赖较新的算子。CUDA版本要和PyTorch匹配，这个不用多说，但有个坑是：有些论文用了FlashAttention，需要CUDA 11.6以上，如果你的环境是11.3，要么升级要么找替代实现。

timm库是个好东西，里面集成了大量视觉Transformer的预训练权重和实现，速递里很多工作的backbone都能在timm里找到对应版本。我的习惯是先用timm里的现成模型跑通流程，再根据论文细节做修改。这样比从零写快得多，也不容易在基础结构上出错。

# 典型的环境安装命令 conda create -n vit python=3.9 conda activate vit pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 -f https://download.pytorch.org/whl/torch_stable.html pip install timm==0.9.2 pip install einops # 很多Transformer实现用einops做张量操作

einops这个库值得单独提一下，它让多头注意力的维度变换写起来非常清晰。比如把(batch, seq, dim)变成(batch, heads, seq, dim_per_head)，用rearrange一行就搞定，比permute+view的组合可读性好太多。速递里如果有论文的代码用了einops，读起来会顺畅很多。

3.2 数据准备与预处理要点

计算机视觉任务的数据预处理直接影响最终效果。以分类任务为例，标准的流程是resize到固定尺寸、归一化、可能加一些数据增强。但Transformer对输入尺寸比较敏感，因为位置编码的维度跟序列长度绑定。如果你用预训练权重，输入尺寸最好跟预训练时一致，否则位置编码需要插值。

我踩过的一个坑是：用ViT的预训练权重做迁移学习，输入尺寸从224改成384，直接加载权重会报维度不匹配。解决办法是对位置编码做双线性插值，这个在timm里有现成的函数。速递里如果论文声称支持任意输入尺寸，通常就是用了插值或者可学习的位置编码。

数据增强方面，RandAugment和Mixup是Transformer训练里的常客。我实测下来，RandAugment的强度参数需要根据数据集大小调，小数据集用太强的增强反而掉点。Mixup的alpha值一般设0.8或1.0，对分类任务比较稳。

3.3 模型搭建的核心代码结构

以多头自注意力为例，核心代码其实不复杂，但细节决定成败。下面是一个标准的实现框架：

import torch import torch.nn as nn from einops import rearrange class MultiHeadAttention(nn.Module): def __init__(self, dim, heads=8, dropout=0.1): super().__init__() self.heads = heads self.scale = (dim // heads) ** -0.5 self.qkv = nn.Linear(dim, dim * 3) self.proj = nn.Linear(dim, dim) self.dropout = nn.Dropout(dropout) def forward(self, x): qkv = self.qkv(x).chunk(3, dim=-1) q, k, v = map(lambda t: rearrange(t, 'b n (h d) -> b h n d', h=self.heads), qkv) attn = torch.softmax(torch.einsum('b h i d, b h j d -> b h i j', q, k) * self.scale, dim=-1) attn = self.dropout(attn) out = torch.einsum('b h i j, b h j d -> b h i d', attn, v) out = rearrange(out, 'b h n d -> b n (h d)') return self.proj(out)

这段代码里，scale是缩放因子，等于每个头维度的平方根倒数。为什么要缩放？因为点积的方差随维度增长，不缩放的话softmax会进入饱和区，梯度消失。这个细节很多速递里的论文不会提，但实现时不能漏。

位置编码有两种主流做法：可学习的和正弦固定的。可学习的更灵活，但需要足够的数据才能学好；正弦编码不需要训练，外推性稍好。我一般分类任务用可学习的，检测任务用正弦的，因为检测的输入尺寸变化多。

3.4 训练策略与调参经验

Transformer的训练比卷积网络更吃数据和调参。学习率用AdamW，初始值一般设1e-4到5e-4，权重衰减0.05左右。warmup很重要，前5到10个epoch线性升温，避免训练初期不稳定。batch size尽量大，梯度累积可以模拟大batch。

我实测下来，ViT在小数据集上从头训练效果很差，必须用预训练权重。如果速递里的论文声称在小数据集上从头训练取得了好效果，要仔细看它是不是用了很强的正则化或者特殊的训练技巧。常见的手段包括：更强的数据增强、随机深度、层缩放初始化。层缩放初始化这个技巧值得展开说——它把残差分支的权重初始值设得很小，让网络初始状态接近恒等映射，训练更稳定。这个在timm里是默认开启的。

提示：如果你在复现速递里的工作时发现loss不下降，先检查学习率和warmup，再检查位置编码的加载方式，最后检查数据预处理是否跟论文一致。这三个地方是最常见的翻车点。

4. 速递里高频出现的几个方向与实操建议

4.1 多模态融合Transformer的落地思路

速递里经常出现多模态融合的工作，比如遥感语义分割里的多层级多模态融合Transformer。这类工作的核心是把不同来源的数据（比如光学图像和SAR图像）用Transformer做特征交互。实操时的关键点是：不同模态的特征维度和空间分辨率往往不一致，需要先对齐再融合。

我做过的一个项目里，光学图像是RGB三通道，SAR是单通道，分辨率也不一样。做法是分别用两个backbone提特征，然后通过交叉注意力让一个模态的token去查询另一个模态的token。交叉注意力的计算量和token数量平方相关，所以实际部署时要做token采样或者窗口化。速递里如果论文没提计算量优化，落地时大概率要自己补。

融合位置也有讲究。早期融合在输入层做，简单但灵活性差；中期融合在特征层做，最常用；晚期融合在决策层做，适合模态差异极大的情况。我的经验是，遥感任务用中期融合比较多，因为不同模态在特征层还有互补信息，到了决策层信息已经损失太多。

4.2 动态长距离Transformer在时序相关任务中的应用

速递里有一类工作专门处理时序相关的视觉任务，比如交通流预测里的传播延迟感知动态长距离Transformer。这类任务的特点是输入不只是单帧图像，而是带时间维度的序列。Transformer处理序列本来是强项，但视觉序列的长度往往很大，直接做全局注意力不现实。

动态长距离注意力的思路是：不是所有时间步之间都需要交互，只对有关联的时间步计算注意力。传播延迟感知的意思是，某个位置的交通状态变化会延迟影响下游位置，注意力机制要能捕捉这种延迟模式。实操时，这类方法通常需要构造一个延迟矩阵或者学习一个位置间的关联图。

我在做类似任务时的体会是：时间维度的下采样比空间维度更敏感。空间下采样丢的是细节，时间下采样丢的是动态模式。所以如果速递里的方法在时间维度做了激进的下采样，要警惕它是否损失了关键的时序信息。一个折中做法是用空洞卷积在时间维度扩大感受野，同时保持分辨率。

4.3 分类任务中Transformer的微调技巧

分类是计算机视觉大作业里最常见的任务，也是速递里Transformer工作最集中的方向。用预训练的ViT或Swin做微调，有几个实操技巧。第一，分类头要重新初始化，backbone用较小的学习率，分类头用较大的学习率。第二，如果目标数据集跟预训练数据集差异大，可以解冻最后几个block一起微调；差异小的话只调分类头就够了。第三，测试时可以用多裁剪或者中心裁剪加翻转做增强，通常能涨0.5到1个点。

我对比过几种微调策略在小型数据集上的表现，结果如下：

这个表是我在几个公开数据集上跑出来的经验值，具体数字会随数据集变化，但趋势是稳定的。速递里如果论文只报了全量微调的结果，而你的数据量不够，不要硬套，从只调分类头开始试。

5. 常见问题与排查技巧实录

5.1 训练不收敛或loss震荡

这是复现Transformer时最常见的问题。排查顺序我一般是这样：先看学习率是不是太大，Transformer对学习率比卷积网络敏感，1e-3以上很容易震荡；再看warmup是不是太短，前几个epoch的梯度范数往往很大，没有warmup容易把预训练权重带偏；然后看batch size和梯度累积的配置，等效batch size太小会导致梯度噪声大。

还有一个容易被忽略的点是权重衰减的应用范围。LayerNorm的权重和偏置不应该加权重衰减，位置编码也不应该。如果统一加了，训练会不稳定。这个细节在速递里的论文中很少提，但代码里如果没做区分，效果会差。

5.2 显存不够用的几种解法

Transformer的显存占用主要来自注意力矩阵，序列长度的平方级增长。显存不够时，按优先级尝试以下方案：第一，减小batch size，配合梯度累积；第二，用混合精度训练，torch.cuda.amp，通常能省30%到40%显存；第三，用梯度检查点，torch.utils.checkpoint，用计算时间换显存；第四，减小输入分辨率或patch大小；第五，换用更高效的注意力实现，比如FlashAttention。

我实测下来，混合精度加梯度检查点能在单张24G卡上把ViT-Base的输入分辨率从224推到384，代价是训练速度慢大概40%。如果速递里的方法声称在单卡上训练了高分辨率模型，大概率用了这些技巧的组合。

5.3 预训练权重加载失败的排查

加载预训练权重时报错，常见原因有几个。键名不匹配是最多的，比如预训练模型用了backbone.blocks.0.attn.qkv，你的模型用了encoder.layer.0.attention.query，名字对不上。解决办法是打印两边的state_dict键名，写个映射函数。维度不匹配通常出现在分类头或者位置编码上，分类头直接跳过加载，位置编码做插值。

还有一个坑是DataParallel和DistributedDataParallel保存的权重键名会多一个module.前缀，加载时要去掉。这个在单机多卡训练后加载权重时经常遇到。

注意：速递里如果论文提供了预训练权重，先看它的加载脚本，通常作者会处理这些细节。如果没有脚本，就按上面的顺序排查。

5.4 推理速度慢的优化方向

训练完了要部署，推理速度是下一个问题。Transformer的推理瓶颈通常在注意力计算和内存访问。优化方向包括：用ONNX或TensorRT导出做图优化；把注意力换成FlashAttention的实现；对token做剪枝或合并；用知识蒸馏换小模型。

我做过一个对比，同一个Swin-T模型，PyTorch原生推理、ONNX Runtime、TensorRT三种方式的延迟大概是1:0.7:0.4的关系。如果速递里的方法强调实时性，先看它有没有做这些工程优化，没有的话落地时自己补。

6. 速递阅读与项目落地的衔接经验

速递看多了容易陷入一种状态：每天都在读新论文，但手上的项目没什么进展。我的经验是，速递要带着问题读。比如你正在做分割任务，就重点看分割相关的Transformer工作；正在调分类模型，就关注分类的微调技巧。没有问题导向的阅读，信息留存率很低。

另外，速递里的工作从论文到可用代码通常有几个月的时间差。如果某个方法你很感兴趣但找不到代码，可以先去Papers with Code或者GitHub搜一下，很多时候有第三方复现。第三方复现的质量参差不齐，但至少能帮你快速验证想法。我自己在复现速递里的工作时，大概有三分之一的情况是直接用了第三方代码，省了大量时间。

最后分享一个我自己的习惯：每读一篇速递里的论文，我会在笔记里记三行——它解决什么问题、核心方法是什么、我能不能用上。这个习惯坚持下来，半年后回头看，能清楚看到自己的知识增长轨迹，也能快速定位到之前读过但当时没用上的方法。计算机视觉这个方向变化快，但核心问题的变化没那么快，抓住核心问题，速递里的新工作就只是不同的解法而已。