论文原文开头：

Scaling Language-Image Pre-training via Masking

We present Fast Language-Image Pre-training (FLIP), a simple and more efficient method for training CLIP [52]. Our method randomly masks out and removes a large portion of image patches during training. Masking allows us to learn from more image-text pairs given the same wall-clock time and contrast more samples per iteration with similar memory footprint. It leads to a favorable trade-off between accuracy and training time. In our experiments on 400 million image-text pairs, FLIP improves both accuracy and speed over the no-masking baseline. On a large diversity of downstream tasks, FLIP dominantly outperforms the CLIP counterparts trained on the same data. Facilitated by the speedup, we explore the scaling behavior of increasing the model size, data size, or training length, and report encouraging results and comparisons. We hope that our work will foster future research on scaling vision-language learning.

Yuxin-CV回答：

最近自己也学习、参与并踩坑了大clip的训练，所以看kaiming团队的这篇工作还是多少有些感触的。以下只是一些个人的理解，多少会有些偏颇，不妥之处还请大家指正。

首先flip是用float32精度train出来的。文末附录说硬件不支持float16，我觉得这多少有些遗憾。因为当你决定用float32的时候，你就注定不会比一个float16(或者混合精度)的模型更scalable。换个角度，一个混合精度不丢patch的clip，和一个丢了patch但用float32的clip，不好说后者就一定比前者省了很多budget。如果硬件条件允许并给我相同的算力或者预算，我会选择用float16精度train更大(更好)的vanilla clip。

其次就是，这种丢patch的方式在采用float16的前提下是否能稳住大clip的训练，也是一个实际问题，文章似乎也没有直接回答。clip从方法上看似简单直接，但从实操的角度而言，从头开始训练大clip是存在着很多优化问题的。open clip的实验表明，用pytorch amp fp16从头开始训练clip huge是无法顺利完成训练的(最终他们转成bfloat16精度缓解了这个问题，而且发现用bfloat16即更好的数值精度相比普通的混合精度fp16会带来额外的gain，所以float32更应如是。reference: doc, wandb)。我觉得丢patch应该不会让优化变得更容易(这里有一些比较间接的证据吧: 我们试过在mae official的codebase上用pytorch fp16训练1b的mae，中间会崩掉。clip huge也是1b的参数量。vanilla clip本身就比mim难train的多，而丢patch只会让data变得更noisy，更难train)。据我所知，大部分使用GPU的研究者是不会用float32训练clip的，最早OpenAI的clip也是混合精度跑出来的，open clip也只是在不得已的情况下才会上bf16。flip这一套丢patch的方案能不能采用float16顺利完成训练，并真正被广大使用GPU的研究者用起来，我觉得还有待后续的实验。这点也是这个方法是不是真正scalable的关键。

另外就是实验上的一些问题，flip有精度gain的前提是自己丢50%的patch开32k的bsz，而baseline是不丢patch开16k的bsz。16k的bsz对于clip而言可能有点小了，最早OpenAI的clip就是32k的bsz，开源的open clip也是至少32k的bsz。应注意到clip从16k到32k可能是存在phase transition的。文中说实验是拉满256 tpu核心做的，可能预算有限吧，有点遗憾了(作者表示就是不用 activation checkpointing..)。

理想情况下，我比较期待50%的patch开64k的bsz，和不丢patch开32k的bsz的baseline的比较。起码这样的baseline是挑不出什么毛病的，也是clip的一个common setting，不过分。

另一方面，在laion400m上如果训练足够充分，我的经验是bsz从32k到64k没太多gain。而大于64k的bsz就没gain了，反而会招致额外的优化问题(flip文章中报丢50%的patch，bsz从32k开到64k在laion400m上6.4ep的训练涨0.8，6.4ep也太少了，openai的clip和open clip都是在400m的数据集上跑32ep的。Table 2里面看似32ep满血版的对比，也没明确说明不丢patch repro的bsz。我觉得baseline的bsz恰恰是需要highlight出来的)。一言以蔽之，我是不太信服在相同在training steps & bsz下，丢patch能比不patch的baseline要好的。更关键的问题在于，bsz并不是一个真正scalable的维度，通过scale up bsz拿gain很容易饱和。而通过trade off(用丢patch换大bsz)拿gain的策略是迟早会被scale up其他真正scalable的维度干掉的(比如model size和dataset size)。而对float32的使用又会限制model size scaling的上限，所以就仿佛陷入了怪圈...

当然，如果是训练相同的epoch，丢patch确实是省时间的(前提是采用相同的数值精度哈，丢patch+float32能不能比common的不丢patch+混合精度训练省时间还不清楚..)。但是大家都是做pre-train的，you only pre-train once。反正一个月内的pt我都能接受，省时没有省出一个数量级是没有什么吸引力的。从evaluation的角度出发，用的时候大家也不会去丢patch。最近清华的GLM-130B也提供了超大模型模型轻量化一个很好的解。所以在train大model的时候，还是要更关注精度本身。performance先要上去，后面总有办法用起来的。

就大clip训练这个问题本身，我觉得也没必要执着于从头开始训练。至少我们通过实验发现，clip和其他很多任务一样，也是可以从适当的预训练中获益的(更快的收敛速度，更高的精度，更高的sample efficiency，etc)。同时，好的初始表征也能很好的解决大clip训练中的优化问题，这也使我们能用更低的数值精度，训练更大的clip或者开更大的batch size，拿到更多的gain。因为clip是scalable的，它值得我们这样做。

文章中一个亮点是在附录提及了数值精度。我觉得我们在后续研究中也应该都highlight一下这个，因为参数量和数值精度共同决定了模型的真实大小(容量)。当大家采用不同的数值精度时，直接比较模型参数量是不妥的。从这个角度出发，flip在进行system level比较的时候，应该去比使用fp16的、参数量更多的模型会更妥当一些(但是具体怎么比也是个麻烦事儿...所以最好还是相同参数量&数值精度的模型一起比较)。另外，float32对clip精度的提升幅度，目前也还不是很清楚。

抛开flip文章本身，个人认为目前clip有两个关键问题，一是怎么scale up，在拉满硬件和预算的情况下拿到最多的gain。二是在scale up的过程中怎么稳住大clip的训练。这也是任何一个真正scalable的算法/模型需要面临的永恒的问题，因为真正scalable的算法/模型总能通过scale up特定维度拿到performance gain，而在scale up的过程中就会面临上述两个问题。另一方面，一个真正scalable的算法/模型也是不会在乎一时的trade off的，因为trade off带来的gain总会在特定的phase过后消失。

这篇文章应该会吸引一部分cv研究者关注clip，我觉得这是个好事情。clip是面向未来的一种视觉感知模型(可以参考flip intro的第一段，写的很精炼)。视觉研究发展到现如今，亟待出现能scale up的in-context / few-shot learning和zero-shot learning的算法/模型。而clip是后者的一个非常promising的candidate(实现前者要难得多)。但遗憾的是clip也不是一般玩家可以上手的模型。我觉得如果有足够的budget，做clip以及其周边要比辛辛苦苦刷det seg那零点几个点什么的更有意义。

train一个大clip真的挺不容易的，大多数从业者也没办法自己完成clip的训练。目前想要train出不错的clip，基本都要用开源的laion400m甚至laion2b。目前开源社区的clip(GitHub - mlfoundations/open_clip: An open source implementation of CLIP.)虽然已经比初代openai的clip要好了，但是和真正的sota还是有很大差距的(参考Google家in house的BASIC)。所以大的、好的clip最好还是要尽量开源出来，反哺社区，惠及大家。

信息门上飞二哈回答：

第一个呢，不是kaiming一作的一般不是kaiming的最高水准；

第二个呢，openai这两年在vision方向已经打破了kaiming和fair在20年之前主导的范式了。我觉得那种原封不动训练数据，照搬任务设定和评价标准，在既有框架下修改某些模块或者改变训练方法看数值涨落的模式已经不是最先进的了。openai那种对整个pipeline大刀阔斧地反思改革才是真正值得关注评价的。

这回答不会得罪知乎上一大票喜欢那种小幅修改就能提点的kaiming粉丝吧。。。。

Openmmlab回答：

太长不看系列

Masking Image + CLIP 在海量数据（LAION-400M/2B）上预训练，性能相当，训练算力大幅减少

整体思路

本文是简单有效风格的又一次体现，Masking Image 在 VLP 预训练已经不是新思路了，但是大家都是把模型和结构都是往更复杂的做，比如 reconstruction loss和 contrastive loss 多个任务一起用，FLIP做了一个很简单的事儿，就是在 CLIP 的极简结构上，使用了类似 MAE 的 Mask 方案，显著地减少 Image Encoder 部分的计算量。画图风格依旧是 MoCo 的味道。

不同于 NLP 模型，由于图像往往尺寸比较大，视觉模型对算力需求也会非常大，目前视觉模型的参数也才刚刚到 1B，直接 scale up 模型参数和数据规模的红利还在，目前的瓶颈可能在于硬件（算力）限制（老黄继续冲啊）。

即使是大厂，算力也是会受到单个显卡性能的影响的，假设在相对较大的算力限制的情况下（如 256 张 A100 GPU），目前继续去摘取这个红利的方式一种思路是从偏工程角度优化，使得已有的硬件能训练更大的模型和更多的数据（如 AMP）。另一种思路是，通过预训练算法层面的优化，提升能训练的模型上限。

模型 Scale-up 的方向探索

FLIP 就属于在算法层面继续去优化，使得我们可能可以继续去做 scale-up。这个工作里，在模型尺寸，数据尺寸和训练时长进行了探索。这让我想到了另一篇 ECCV 2022 的工作 ZeroVL [1]，也是在探索如何提升 CLIP 训练的效率，不同点是它从数据采样和 batch size角度出发，在中小数据规模下做的探索。

几个结论：

• FLIP增大模型尺寸继续涨点

• FLIP增大数据规模继续涨点

• FLIP增大训练时长几乎没什么涨点

大家可以继续去探索如何增大模型尺寸和数据规模了。

展望与思考

今年涌现了一批做大模型的工作，如 BEiT-3, EVA 等等，大家都还是在继续去挖掘增大模型尺寸和数据尺寸的红利，无论是直接用 LAION-400M 去训练，还是用 CLIP 模型来蒸馏，基本都是大模型+大数据的核心思路。期待各家大厂继续在 Bigger and Larger 上为学界提供更强的模型。
这里提几个个人感觉有趣的问题和方向：

• VLP 对于广泛的视觉下游任务（检测，分割等）真的是必须的的么？只用 Vision SSL 在这么大的数据量上来做，会不会对视觉下游任务也同样有效甚至更好？（这里不讨论 zero-shot和多模下游任务）

• 模型架构真的重要么？1B 的参数 +400M 的数据是不是无论 CNN 还是 ViT 都是差不多的性能？

• 如何将海量数据和大模型的知识迁移至轻量级模型？

• One-for-all 的预训练模型真的万金油和灵丹妙药么？如果不是，知识驱动的 VLP 或者 Downstream Task-related Pre-training 可能还可以卷一卷。基于 CLIP 的模型在 retrieval 等任务上表现不错，但对于 relation 的建模能力不足，更多类似 bag-of-words, 在relation-aware的多模任务上表现一般，如 [2] 的分析。

  文章转载自知乎，著作权归属原作者，侵删

END

分享

收藏

点赞

在看