近期,我们的点云 Transformer 论文 Swin3D [4] 获得了 Computational Visual Media Journal(CVMJ)的最佳论文奖。CVMJ 是计算机科学领域的知名期刊,2025 年影响因子达到了 18.3,这个奖项还是非常有含金量的。

清华大学胡事民院士在韩国举行的 CVM 2026 上颁发 CVMJ 最佳论文奖,我作为作者代表领奖,倍感荣幸。
刚收到最佳论文获奖通知的时候,我盯着那封邮件看了大半天。
开心当然有。毕竟,这是最佳论文奖。 但更强烈的情绪,其实不是兴奋,而是回味。
因为我脑海里浮现的,不只是这一篇论文,而是它背后的一整条技术路线:PCT [1]、PT [2]、Stratified Transformer [3]、Swin3D [4]、OctFormer [5]、Point Transformer V3 [6],以及这些工作怎样在几年时间里一点点把一条原本并不平坦的路,硬生生走通。
今天,很多人提到点云 Transformer,第一反应大概率是 Point Transformer V3(PTv3):更快、更强、更省,更像 3D 世界里一个顺手、可靠、能扛事的底座。
但如果你只看今天,很容易产生一种错觉,好像 PTv3 是横空出世,这一路都是理所当然、水到渠成。
真实情况恰恰相反。
这条路上,几乎每一步都不轻松。前面的人先证明“这件事能不能做”,后来的人再解决“能不能做大”,再往后的人继续回答“能不能做快、做稳、做成基础设施”。
所以这篇文章,并不只是一篇围绕 Swin3D 的“获奖感受”,我也不想只复述谁又刷新了哪个榜单。我更想借着这个时刻,回顾一下我个人对点云 Transformer 发展历程的亲历与观察:
点云 Transformer 的今天,并不是某一篇论文突然赢了,而是一条研究路线经过反复试错、不断转弯之后,终于长出来的结果。
2020 年底到 2021 年,Vision Transformer(ViT) [9] 把注意力机制带到了视觉研究的舞台中央。点云社区很快意识到,这套东西和点云之间,其实有一种天然的契合。
点云本来就是一个集 合,天然无序;而注意力机制本身具备重排不变的性质,理论上就很适合处理这类数据。
于是,第一波代表性工作很快出现了:PCT [1] 和 PT [2]。

第一阶段的代表性工作 PCT(左)和 PT(右)证明了点云 Transformer 的可行性,但在大规模点云上效率不高。
这两个工作最重要的贡献,不只是把 Transformer “搬”到了点云上,而是第一次非常有说服力地告诉整个领域:
Transformer 不只是能做点云,而且真的能打。
它们在 ModelNet、ShapeNetPart、S3DIS 等经典任务上,把性能推到了一个新的高度,甚至超过了不少之前精心设计的点云神经网络。那一刻,大家基本都确认了一件事:这条路值得继续走。
但第一代点云 Transformer 也很快暴露出一个共同问题。
强,是真的强。
重,也是真的重。
你可以把它理解成,大家第一次把一台高性能发动机装到了点云上,速度上来了,油耗也一起上来了。尤其当任务从物体级走向场景级,点数规模迅速放大到上万以后,计算量和显存开销会很快变得难以承受。
也就是说,第一代工作解决的是“方向对不对”,但还没有解决“这条路怎么走得远”。
它们把门推开了。
可门后面,还是一条很窄的路。
到了 2022 年,在百宁老师、童欣老师、刘洋老师的指导下,研究生杨钰琦、熊剑雨,研究员雨潇、潘浩,还有我,开始认真思考效率问题:
既然 2D 里的 Swin Transformer [10] 用窗口注意力和层级式网络架构很好地解决了 Vision Transformer 的效率问题,那在 3D 点云里,能不能也走这条路?

Vision Transformer 和 Swin Transformer 的架构对比。Swin Transformer 通过窗口注意力和层级式架构显著提升了效率。
这个想法一开始听起来很自然。
但真正做下去才会发现,点云和图像,根本不是一回事。
在图像里,窗口是规整的、均匀的,切出来就是一个个整齐的小块;可在点云里,同样大小的空间窗口,里面的点数可能天差地别。你以为自己是在“分窗口”,其实你面对的是一堆疏密不一、形状各异、带着很强稀疏性的局部区域。

把窗口注意力应用到点云上需要处理点云分布不均的问题,否则计算效率会大大降低。
这时候,问题就不再只是“网络该怎么设计”。
更麻烦的是底层实现、CUDA 优化、内存组织、并行方式,甚至是你对注意力机制计算图本身的理解。
很多技术,最后不是输在想法不够新,而是输在最后一公里太难跑。
也正是项目攻关的关键阶段,Stratified Transformer [3] 也提出了非常接近的路线。作者用非常高水平的 CUDA 技巧,把窗口注意力真正落地到了点云上。
这件事让我们深刻地看到:点云 Transformer 的瓶颈,很多时候不是“想不到”,而是“太难做对”,并且要“快速地做对”。
说实话,当同行做出相似的优秀工作时,我的心情其实很复杂。
一方面会兴奋,因为这证明了方向可行;
另一方面也会焦虑,因为它把这条路的门槛一下子抬高了,甚至把我们原定的技术路线也给堵上了。
Swin3D [4] 就是在这样的背景下逐渐成形的。
好在我们没有放弃,而是想办法百尺竿头、更进一步。 我们一方面通过类似 FlashAttention 的思路,减少中间变量来降低内存消耗(值得一提的是,当时 FlashAttention 还没有出现);另一方面,又针对点云坐标、信号稀疏性和分布不均做了很多精细设计,让窗口注意力在 3D 场景里更高效地跑起来。
更重要的是,Swin3D 不只是一个“单点模型”,我们认真把“预训练 + 微调”这件事带进了 3D 室内场景理解里。在 Structured3D [7] 这样比 ScanNet 大一个数量级的数据上做预训练,再迁移到分割和检测任务,效果显著提升 [4]。
如果说第一代点云 Transformer 证明了注意力机制适合点云,那么 Stratified Transformer [3] 和 Swin3D [4] 真正往前推进的,是另一件更难的事:
让点云 Transformer 开始具备“大规模”和“可预训练”的可能性。
正是因为这个原因,Swin3D 获得了 CVMJ 的最佳论文奖。
但 Swin3D 对我来说,意义远不只是一个奖项。
它让我把一个问题真正想透了:
点云 Transformer 最难的地方,不在于“有没有新想法”,而在于“怎样让它在大规模场景中真正可用”。
Swin3D [4] 和 Stratified Transformer [3] 已经把效率往前推了很多;同期类似的工作还有 SWFormer [12] 和 SST [11] 等。 整体来看,进展是可喜的,但工程难度实在太高了。
你很难像在图像里那样,轻轻松松当个“调包侠”,直接调用几个现成算子就把系统搭起来。
后来我越来越强烈地感觉到,整个领域其实被两个思维定式卡住了。
第一个思维定式是:点云是无序的,所以天然难以高效计算。
第二个思维定式是:既然用了窗口注意力,那窗口就应该是规则的、固定形状的。
我后来在 OctFormer [5] 里做的事情,本质上就是反过来问:
这两个前提,真的非得成立吗?
OctFormer 的核心思路其实非常朴素。
窗口注意力机制真正关心的,未必是窗口“长得像不像立方体”;它更在乎的是,这一组 token 能不能形成合理的局部建模单元。
既然如此,我们为什么一定要固定窗口的几何形状,而不是固定每个窗口里包含的点数?
构造八叉树的过程(a)其实是对点云按照 Z-Order 进行排序的过程(b);在序列化之后的点云上,很容易高效地运行窗口注意力机制(c)。
顺着这个想法,OctFormer [5] 走了一条非常不一样的路。
它借助八叉树(Octree)对点云进行排序,实现点云的序列化,把原本散乱无序的点云,变成具有空间连续性的序列;然后不再要求窗口大小和形状固定,而是保证每个窗口里的点数固定。
这个变化看上去不大,实际意义却非常大。
因为过去最麻烦的问题,恰恰就是不同窗口里的点数极不均衡,导致 Attention 很难高效实现。一旦每个局部窗口里点数相同,Attention 就从一个“点云特制问题”,变成了一个更接近标准张量操作的问题。
OctFormer 的 Octree Attention 甚至只需要大约 10 行 PyTorch 代码就能实现;而当点数超过 20 万时,它至少比当时的 Stratified Attention 快 20 倍。后者的实现则需要几千行 CUDA 代码 [5]。
这不是简单地“拿工程换速度”。
OctFormer [5] 在多个点云任务上同样拿到了非常强的结果。这说明它真正往前推进的,是“点云应该如何被组织成一种更适合 Transformer 处理的结构”。
如果一定要用一句最通俗的话概括 OctFormer,我会说:
不是点云天生无序,而是我们以前很少想过对点云进行排序。
有趣的是,这篇论文是我一个人独立完成的。
当时我刚入职北大,还没有学生,正好有一段相对完整的时间可以和这个问题“单挑”。从 2022 年 9 月到 2023 年 1 月,我几乎每天都在想它:写代码、调试、跑实验、写论文。当时还没有好用的大模型帮忙,vibe 不起来,干的绝对是“古法”科研。
感染新冠发烧的间隙,实验实在做不动了,那就先写论文吧,做点“轻松”的事。
SIGGRAPH 2023 的投稿截止是大年初四。除夕那天,我要开车回老家过年;路上只要家人接替我开车,我就打开电脑,继续写几句。
同样没有休息的,还有那台 8 卡 3090 的服务器。从 2022 年 9 月买回来起,一直到投稿截止前,它几乎一刻也没停过。
后来这篇论文被 SIGGRAPH 2023(Journal Track)接收。回头看,我依然觉得,那几个月的热血过程非常难忘(随后有空,我讲讲我的研究生涯里的另外一个热血时刻)。
这样的时刻,也许不会经常出现。
但一旦出现,足够让我记很多年。
再后来,一个富有才华的博士生吴虓杨联系到我,想继续做新一代点云 Transformer。我们讨论的核心其实很直接:
既然“序列化”这条路已经走通了,能不能把它继续放大?不再执着于那些局部机制上的“小精巧”,而是把规模(Scale)真正拉起来。
Point Transformer V3(PTv3) [6] 给出的答案是:可以,而且效果很好。
PTv3 最有意思的地方在于,它几乎是反论文写作直觉的。
它没有把重点放在“我又发明了一个多复杂的新模块”上,反而强调一件很朴素的事情:
在点云这件事上,很多时候更简单,反而才能更大;更大,反而才更强。
PTv3 把 OctFormer 的 Z-Order 排序思路进一步拓展,使用了 4 种不同的序列化模式,丰富了点云的局部交互。
它把一种序列化方式扩展成四种互补的序列化模式,让点云在不同排序视角下形成更丰富的局部邻接关系。由于点云已经被组织成序列,局部注意力计算也更容易回到标准高效算子的范式里;在实现上,还可以直接调用当时一经出现就迅速流行起来的 FlashAttention 进一步加速。
结果也很直接。
PTv3 [6] 更快了,内存更省了,效果也更强了。论文一作吴虓杨凭借非常出色的实验能力,在室内、室外二十多个下游任务上都拿到了极强的结果。论文最终获得了 CVPR 2024 Oral,在点云领域引起了相当大的反响。论文发表两年来,已经获得超过 900 次引用。
更让我在意的是后来的变化。
最近我注意到,像李飞飞团队的 PointWorld [8] 这样的工作,已经开始把 PTv3 当成基础模型的一部分;不少 3D AIGC 的研究团队,也在采用“序列化”的思路去加速三维生成模型的训练和推理。
当我看到这里时,感受其实很清楚:
一条技术路线一旦既强、又快、又足够通用,它就不再只是一篇论文,而会开始变成基础设施。
而这,往往比“又赢了一次 benchmark”更重要。
这几年,论文越来越多,节奏越来越快,研究焦虑也越来越普遍。
在这样的环境里,最容易被放大的,是“最新”“最强”“最火”的那个名字。久而久之,我们很容易产生一种错觉:仿佛技术进步总是由某一篇论文突然完成的。
但对我来说,点云 Transformer 这条线恰恰说明,事情从来不是这样。
没有 PCT 和 PT,大家不会那么快确认 Transformer 真的适合点云。
没有 Stratified Transformer 和 Swin3D 这一阶段对大规模场景、窗口注意力、工程实现和预训练范式的硬碰硬探索,后面就不会有人真正看清楚,瓶颈到底卡在哪里。
没有这段经历,我也不会在 OctFormer 里去质疑那两个看似理所当然的前提,去尝试对点云进行排序,更不会有后来 PTv3 把点云序列化这条路线继续放大的机会。
所以在我看来,Swin3D 的价值远不只是一个奖项,它更像是这条路线中的一个关键支点。
没有这个支点,后面的很多事情,很可能都会是另一种样子。
如果今天一定要让我用最简单的方式概括点云 Transformer 这些年的演化,我会把它总结成四句话:
先证明它可行。
再证明它能扩展。
再证明它可以高效实现。
最后,把它做成真正能支撑更大模型、更大数据、更多应用的基础架构。
这就是我所经历的点云 Transformer 演化史。
它不是从论文 A 走到论文 B 的引用链。
它更像是一群人围着同一堵墙,轮流去撞,先撞出裂缝,再把裂缝越撬越大,直到后来的人终于可以从那道缝里走过去。
而我很幸运,恰好在那堵墙边上,推过几次。
感谢我的各位优秀合作者,感谢 CVMJ 评委会对 Swin3D 的认可。
本文没有对所有的相关工作进行全面梳理,对于那些没有被提及的工作,我同样非常敬佩和感谢。感谢所有在点云 Transformer 这条路上做过探索的同行。