FastCLIP: A Suite of Optimization Techniques to Accelerate CLIP Training with Limited Resources

## Abstract

Abstract Existing studies of training state-of-the-art Contrastive Language-Image Pretraining (CLIP) models on large-scale data involve hundreds of or even thousands of GPUs due to the requirement of a large batch size. However, such a large amount of resources is not accessible to most people. While advanced compositional optimization techniques for optimizing global contrastive losses have been demonstrated effective for removing the requirement of a large batch size, their performance on large-scale data remains underexplored and not optimized. To bridge the gap, this paper explores several aspects of CLIP training with limited resources (e.g., up to tens of GPUs). First, we introduce FastCLIP, a general CLIP training framework built on advanced compositional optimization techniques while designed and optimized for the distributed setting. Our framework is equipped with an efficient gradient reduction strategy to reduce communication overhead. Second, to further boost training efficiency, we investigate three components of the framework from an optimization perspective: the schedule of the inner learning rate, the update rules of the temperature parameter and the model parameters, respectively. Experiments on different strategies for each component shed light on how to conduct CLIP training more efficiently. Finally, we evaluate the performance of FastCLIP and the state-of-the-art training baseline (OpenCLIP) on different compute scales up to 32 GPUs on 8 nodes, and three data scales ranging from 2.7 million, 9.1 million to 315 million image-text pairs to demonstrate the significant improvement of FastCLIP in the resource-limited setting.
We release the code of FastCLIP at https://github.com/Optimization-AI/fast_clip .

## 1 Introduction

Contrastive Language-Image Pretraining (CLIP) (Radford et al., ) is a popular approach for vision-language representation learning (Cherti et al., ; Sun et al., ; Chen et al., ; Li et al., ; Qiu et al., ). The method effectively embeds data from the image and language modality into a joint embedding space by optimizing a contrastive loss in a self-supervised manner. It has demonstrated strong performance on various downstream tasks (e.g., zero-shot classification and retrieval) and has been adopted in various applications, including text-to-image generation (Ramesh et al., ; Zhou et al., ; Crowson et al., ), image captioning (Yu et al., ; Mokady et al., ),
and evaluation of image generation quality (Hessel et al., ). Its popularity is further fueled by releases of web-scale datasets (Schuhmann et al., ; ; Gadre et al., ; Fang et al., ).

However, vanilla mini-batch based methods for self-supervised contrastive learning are known to require a large batch size to obtain satisfactory performance (Chen et al., ; ). Theoretically, it has been shown that the optimization error of mini-batch based contrastive learning methods inversely depends on the batch size (Yuan et al., ). Empirically, state-of-the-art CLIP models are typically trained using a large batch size on a large number of GPUs (e.g., 84k batch size and 1024 Nvidia A100 GPUs in OpenCLIP (Cherti et al., )).
Such a large amount of resources is not accessible to most researchers and practitioners in academia and small companies. Recently, Yuan et al. () proposed an algorithm named SogCLR to address the large batch size issue, which leverages finite-sum coupled compositional optimization (FCCO) techniques to optimize a global contrastive loss (GCL) that contrasts each anchor data with all other data in a compositional structure. A key feature of compositional optimization is the inner and outer steps where the inner steps maintain and update a sequence of estimators to track the inner functions on the solution path, which can be interpreted as an SGD update with a learning rate called the inner learning rate (Wang & Yang, ). Later, SogCLR has been leveraged by Qiu et al. () to design the iSogCLR algorithm for optimizing a robust global contrastive loss (RGCL) with individualized learnable temperatures for training CLIP models.
However, these algorithms are not fully optimized for large-scale training of CLIP models since they were examined only on small-scale datasets.

This paper aims to scale up the advanced optimization algorithms for optimizing global contrastive losses of CLIP training on large-scale data with limited compute resources. We introduce a distributed training framework named FastCLIP by employing data parallelism such that each worker computes the gradient estimator using their respective data and then reduces (averages) them through communication, based on which the model is updated. A novel gradient reduction strategy is designed, which requires less communication than the existing distributed framework. This distributed training framework lays the foundation for scaling up CLIP training with limited resources. To further boost the efficiency of our framework, we investigate its three aspects from an optimization perspective: the schedule of the inner learning rate (LR) of compositional optimization, the update rule of the temperature parameter, and the update rule of the model parameters, respectively.

- •
Previous studies (Yuan et al., ; Qiu et al., ) set the inner LR to a constant value less than but close to one, which could slow down the training for large-scale data at earlier iterations. Inspired by the learning rate schedule of existing optimizers of Deep Learning (Loshchilov & Hutter, ), we examine a cosine decay schedule for the inner LR by comparing its performance with the constant schedule.
- •
For the update rule of the temperature parameter, we compare four different strategies in the FastCLIP framework, including a heuristic approach based on the gradient of GCL, a constant strategy as used in SogCLR, learning individualized temperatures as used in iSogCLR, and learning global temperature by optimizing a new RGCL with a single learnable temperature.
- •
For the update rule of the model parameters, we compare the performance of commonly-used optimizers for CLIP training in the FastCLIP framework, including AdamW (Loshchilov & Hutter, ), LAMB (You et al., ), Lion (Chen et al., ) and SGD with momentum (Polyak, ).

Moreover, in order to study the scaling capability of FastCLIP,
we compare the performance of FastCLIP and state-of-the-art baseline OpenCLIP (Ilharco et al., ) on three data scales and four compute scales. The data scales include 2.7 million (CC3M (Sharma et al., )), 9.1 million (CC12M (Changpinyo et al., )), and 315 million (LAION400M (Schuhmann et al., )) image-text pairs(^1^11Our downloaded versions of these datasets are smaller than their original versions because some web links are not valid anymore.).
The compute scales include 1, 2, 4, and 8 nodes, with 4 GPUs on each node.

Figure: (a) 1 Node, Medium
Refer to caption: x1.png

The contributions of this paper are summarized as follows:
(1) We propose FastCLIP, an efficient distributed framework to scale up CLIP training with limited computing resources. (2) We study the performance of different strategies for three components of FastCLIP, providing insights on how to conduct CLIP training more efficiently.
(3) We compare the performance of FastCLIP on different data scales and compute scales. The results show that FastCLIP consistently outperforms state-of-the-art training baseline OpenCLIP by a large margin. A quick comparison between FastCLIP and OpenCLIP on different data scales and compute scales are shown in Figure 1, with more detailed results presented in Section 6.

## 2 Related Works

CLIP training in the distributed setting: Radford et al. () train CLIP models in a distributed setting, but few details regarding the implementation are provided. Ilharco et al. () develop OpenCLIP, an open-source implementation of CLIP. They leverage the PyTorch distributed data-parallel module (Li et al., ) to automatically communicate features and gradients. EVA-CLIP (Sun et al., ; ) scales the number of parameters of the image encoder in CLIP up to 18 billion by applying several techniques from the system perspective, including the ZeRO optimizer (Rajbhandari et al., ) and global half-precision training with DeepSpeed (Rasley et al., ). The key difference between existing works and this work is that they all use a simple mini-batch based contrastive loss, which suffers from the issue of requiring a large batch size. This in turn requires hundreds and even thousands of GPUs. For example, CLIP uses 592 V100 GPUs, OpenCLIP uses 1024 A100 GPUs, and EVA-CLIP uses 256 A100 GPUs. Our work focuses on scaling up CLIP training in a resource-limited setting with only tens of GPUs. We make unique efforts to reduce communication overhead and optimize algorithmic components.

Benchmark for CLIP training: Cherti et al. () study the scaling performance of CLIP training. They measure the performance of CLIP across different model sizes and dataset sizes, and study the relationships between downstream task performance and resource consumption. Gadre et al. () investigate the impact of different data filtering strategies on the trained model’s downstream performance. They conduct experiments across different data scales ranging from 12.8 million to 12.8 billion and provide insights on how to curate CLIP’s training data. Cui et al. () examine the impact of data quality, supervision strategies (e.g., additional image supervision), and model architectures. Li et al. () explore different aspects of CLIP training under a limited training budget, including the impact of the quality and quantity of the training data, different model architectures, and different existing training strategies. Different from these works, we study different algorithmic components of CLIP training in an advanced optimization framework for optimizing the global contrastive loss.

Improved CLIP training: Many works have studied efficient CLIP training with limited resources. Yuan et al. () propose SogCLR to improve the performance of contrastive learning with small batch size. Our work scales up SogCLR in the distributed setting and incorporates several algorithmic strategies to accelerate its training speed. Besides the algorithm, other directions are also explored for more efficient CLIP training, including augmenting mini-batch based contrastive losses (Li et al., ; Zhai et al., ; Mu et al., ; Li et al., ; Mo et al., ; Lee et al., ; Goel et al., ), model compression (Wu et al., ; Li et al., ; Fang et al., ), and system optimization (Chen et al., ; Sun et al., ; Rajbhandari et al., ).

Temperature scheme:
The temperature parameter in contrastive losses plays an important role in CLIP training. Many techniques have been proposed to update or set the temperature parameter.
Radford et al. () treat the temperature as part of the learnable parameters in the mini-batch contrastive loss. Zhang et al. () propose to use different temperatures for positive and negative samples to independently control intra-anchor and inter-anchor hardness-awareness. Kukleva et al. () study a cosine decay schedule for setting the temperature. Huang et al. () propose to set the temperature parameter proportional to the alignment between positive pairs.
Qiu et al. () propose a robust global contrastive loss (RGCL) with individualized temperatures inspired by Distributionally Robust Optimization and optimize it with the iSogCLR algorithm which extends SogCLR. However, their performance on large-scale data remains unknown. This work focuses on comparing different global contrastive losses for learning the temperature parameter and discovers a new strategy by learning a global temperature in the RGCL that yields better performance for large-scale data.

Optimizers for CLIP training: Different optimizers for updating the learnable parameters have been employed in CLIP training, including AdamW (Loshchilov & Hutter, ) used by Radford et al. (); Cherti et al. (); Gadre et al. (); Chen et al. (); Li et al. (); Qiu et al. (), and LAMB (You et al., ) used by Sun et al. (); Xie et al. (); Huang et al. (). A recently proposed optimizer named Lion (Chen et al., ) also provides promising results for this task (Chen et al., ; Wortsman et al., ).
In this work, we compare the performance of AdamW, LAMB and Lion to determine which optimizer is most suitable in FastCLIP for training CLIP models from scratch. We also include SGD with momentum (Polyak, ) for comparison.

## 3 Preliminaries

Notations: Given a dataset $\mathcal{S}$ of $n$ images $\bm{x}_{i}$ and their corresponding text descriptions $\bm{z}_{i}$: $\mathcal{S}=\{(\bm{x}_{1},\bm{z}_{1}),\ldots,(\bm{x}_{n},\bm{z}_{n})\}$, we aim to learn an image encoder and a text encoder (jointly represented by $\bm{w}$) from the data. We use $\bm{e}_{1,i}=\bm{e}_{1}(\bm{w},\bm{x}_{i})\in\mathbb{R}^{d}$ and $\bm{e}_{2,i}=\bm{e}_{2}(\bm{w},\bm{z}_{i})\in\mathbb{R}^{d}$ to denote the encoded vector of the input $\bm{x}_{i}$ and $\bm{z}_{i}$, respectively. And we use $\bm{e}_{i}=(\bm{e}_{1,i}^{\top},\bm{e}_{2,i}^{\top})^{\top}$ to denote the concatenation of $\bm{e}_{1,i}$ and $\bm{e}_{2,i}$. Denote by $\mathcal{B}\subset\mathcal{S}$ a mini-batch of image-text pairs. With slight abuse of notation, we also use $\mathcal{B}$ (and $\mathcal{S}$) to denote the indices of the image-text pairs it contains. $\mathcal{S}_{i-}:=\mathcal{S}\backslash\{i\}$ denotes the subset of $\mathcal{S}$ without $i$-th pair.
We consider the data parallel setting such that $\mathcal{S}$ is partitioned evenly across $K$ workers denoted by $\mathcal{S}_{1},\ldots,\mathcal{S}_{K}$. For a function $\ell(\cdot,\cdot)$, let $\nabla_{1}\ell(\cdot,\cdot)$ and $\nabla_{2}\ell(\cdot,\cdot)$ denote the partial gradient in terms of the first and second argument, respectively.

Mini-batch Contrastive Loss (MBCL) and Global Contrastive Loss (GCL): The core idea of CLIP training is to leverage a contrastive loss to push features of paired image and text close to each other (i.e., to maximize the similarity between $\bm{e}_{1,i}$ and $\bm{e}_{2,i}$), while pushing features of non-paired image and text away from each other (i.e., minimizing the similarity between $\bm{e}_{1,i}$ and $\bm{e}_{2,j}$ for $i\neq j$). Mathematically,
let $s_{i,j}$ denote the cosine similarity between $\bm{e}_{1,i}$ and $\bm{e}_{2,j}$. Define

$$ $\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau):=\exp\left((s_{i,j}-s_{i,i})/\tau\right ),\quad\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau):=\exp\left((s_{j,i}-s_{i,i})/ \tau\right),$ $$

where $\tau>0$ is the temperature parameter.
Given a mini-batch $\mathcal{B}$ of image-text pairs, let

$$ $g_{1}(\bm{w},\tau,i,\mathcal{B}):=\frac{1}{|\mathcal{B}|}\sum\nolimits_{j\in \mathcal{B}}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau),\quad g_{2}(\bm{w},\tau,i, \mathcal{B}):=\frac{1}{|\mathcal{B}|}\sum\nolimits_{j\in\mathcal{B}}\ell_{2}( \bm{e}_{i},\bm{e}_{1,j},\tau).$ $$

In the literature, a large number of works (e.g., Cherti et al., ; Gadre et al., ; Sun et al., ), following Radford et al. (), minimize the mini-batch contrastive loss (MBCL):

$$ $\frac{1}{|\mathcal{S}|}\sum\nolimits_{i\in\mathcal{S}}\mathbb{E}_{\mathcal{B} \subset\mathcal{S}_{i-}}\left(\log\left(\frac{1}{|\mathcal{B}|}+g_{1}(\bm{w}, \tau,i,\mathcal{B})\right)+\log\left(\frac{1}{|\mathcal{B}|}+g_{2}(\bm{w},\tau ,i,\mathcal{B})\right)\right),$ (MBCL) $$

which contrasts the $i$-th pair with other pairs within only a mini-batch $\mathcal{B}$. However, this loss suffers from the large-batch size issue, which has been addressed by the Global Contrastive Loss (GCL) (Yuan et al., ) that contrasts the $i$-th pair with all other pairs in the dataset $\mathcal{S}$:

$$ $\frac{\tau}{|\mathcal{S}|}\sum\nolimits_{i\in\mathcal{S}}\left(\log\left( \varepsilon{}+g_{1}(\bm{w},\tau,i,\mathcal{S}_{i-})\right)+\log\left( \varepsilon{}+g_{2}(\bm{w},\tau,i,\mathcal{S}_{i-})\right)\right),$ (GCL) $$

where $\varepsilon{}$ is a small constant.

Robust Global Contrastive Loss (RGCL): To improve CLIP training, Qiu et al. () designed a robust global contrastive loss (RGCL) with individualized temperature parameters inspired by Distributionally Robust Optimization. It is defined as:

$$ $\displaystyle\min_{\tau_{1},\tau_{2}\geq\tau_{0}}\frac{1}{|\mathcal{S}|}\sum_{ i\in\mathcal{S}}$ $\displaystyle\left(\tau_{1,i}\cdot\left(\log\left(\varepsilon{}+g_{1}(\bm{w}, \tau_{1,i},i,\mathcal{S}_{i-})\right)+\rho\right)\right.$ (RGCL) $\displaystyle\;\;\left.+\tau_{2,i}\cdot\left(\log\left(\varepsilon{}+g_{2}(\bm {w},\tau_{2,i},i,\mathcal{S}_{i-})\right)+\rho\right)\right),$ $$

where $\tau_{1}=(\tau_{1,1},\ldots,\tau_{1,n})$, $\tau_{2}=(\tau_{2,1},\ldots,\tau_{2,n})$, $\tau_{0}$ is a small value, $\rho\geq 0$ is a hyperparameter.

Optimization Algorithms. To optimize GCL, Yuan et al. () proposed the SogCLR algorithm based on advanced compositional optimization known as Finite-sum Coupled Compositional Optimization (FCCO) (Wang & Yang, ). Specifically, GCL is formulated as $\frac{1}{n}\sum_{i\in\mathcal{S}}f(g_{i}(\bm{w}))$, where $f(g)=\log(\varepsilon+g)$ and $g_{i}(\bm{w})$ is the inner function inside the log. The main challenge is to compute a gradient estimator using a mini-batch of samples such that the algorithm can converge without requiring a large batch size. The key idea of SogCLR is to maintain and update an estimator for each inner function $g_{i}(\bm{w})$ denoted by $u_{i}$, by using Equation (1). As a result, the gradient at the $t$-th iteration is estimated by $\frac{1}{|\mathcal{B}|}\sum_{i\in\mathcal{B}}\nabla f(u_{i}^{t+1})\nabla\hat{g
}_{i}(\bm{w}^{t})$, where $\mathcal{B}$ is a mini-batch and $\hat{g}_{i}(\bm{w})$ is a mini-batch estimator of $g_{i}(\bm{w})$. To optimize RGCL, Qiu et al. () proposed the iSogCLR algorithm by combining SogCLR with stochastic coordinate updates for the temperature parameters.

## 4 FastCLIP: A Distributed Training Framework of CLIP Models

Figure: Algorithm 1 The FastCLIP Framework (Sketch)

FastCLIP is a distributed training framework for optimizing global contrastive losses (including (GCL) and (RGCL)). Its key updates are built upon the SogCLR algorithm.
The main difference between SogCLR and mini-batch based methods such as CLIP is that SogCLR maintains two scalar sequences $u_{1,i}$ and $u_{2,i}$ to keep track of $g_{1}(\bm{w},\tau,i,\mathcal{S}_{i-})$ and $g_{2}(\bm{w},\tau,i,\mathcal{S}_{i-})$ as stated in Section 3. At iteration $t$, for $i$ selected in the batch $\mathcal{B}^{t}$, $u_{1,i}$ and $u_{2,i}$ will be updated using a moving average estimator with hyperparameter $\gamma_{t}\in(0,1]$:

$$ $u_{1,i}^{t+1}=(1-\gamma_{t})u_{1,i}^{t}+\gamma_{t}g_{1}(\bm{w}^{t},\tau^{t},i, \mathcal{B}_{i-}^{t}),\quad u_{2,i}^{t+1}=(1-\gamma_{t})u_{2,i}^{t}+\gamma_{t} g_{2}(\bm{w}^{t},\tau^{t},i,\mathcal{B}_{i-}^{t}),$ (1) $$

and the gradient estimator is computed by $\frac{1}{|\mathcal{B}^{t}|}\sum_{i\in\mathcal{B}^{t}}\nabla f(u_{i}^{t+1})
\nabla\hat{g}_{i}(\bm{w}^{t})$. The core of FastCLIP (Algorithm 1) is how to compute the gradient estimator in a distributed manner.

Next, we use (GCL) as an example to present our gradient computation strategy that effectively reduces the communication cost. We only present key steps and defer the complete derivation to Appendix A due to space limit.
Let $\mathcal{B}^{t}_{k}$ denote local mini-batch on $k$-th worker. Below, we omit the superscript $t$ and use $\mathcal{B}_{k}$ for simplicity. Note that (GCL) is the sum of two parts: the image part (loss $g_{1}$) and the text part (loss $g_{2}$). Due to their symmetric structure, we only present the gradient of the image part. The gradient estimator of (GCL) is computed by $G_{\bm{w},1,a}+G_{\bm{w},1,b}$:

$$ $\displaystyle G_{\bm{w},1,a}=$ $\displaystyle\tau\cdot\underbrace{\frac{1}{K}\sum_{k=1}^{K}}_{\textsc{All_ Reduce}}\frac{1}{|\mathcal{B}_{k}|}\sum_{i\in\mathcal{B}_{k}}\frac{1}{ \varepsilon+\underbrace{u_{1,i}}_{\textrm{local}}}\cdot\overbrace{\frac{1}{K} \sum_{k^{\prime}=1}^{K}\frac{1}{|\mathcal{B}_{k^{\prime},i-}|}\sum_{j\in \mathcal{B}_{k^{\prime},i-}}\nabla_{1}\ell_{1}(\underbrace{\bm{e}_{i}}_{ \textrm{local}},\underbrace{\hbox{\pagecolor{yellow!15}$\bm{e}_{2,j}$}}_{ \textrm{global}},\tau)\cdot\underbrace{\nabla\bm{e}_{i}}_{\textrm{local}}}^{G_ {\bm{w},1,a,i}},$ $\displaystyle G_{\bm{w},1,b}=$ $\displaystyle\tau\cdot\underbrace{\frac{1}{K}\sum_{k^{\prime}=1}^{K}}_{\textsc {All_Reduce}}\frac{1}{|\mathcal{B}_{k^{\prime}}|}\sum_{j\in\mathcal{B}_{k^{ \prime}}}\cdot\frac{1}{K}\sum_{k=1}^{K}\frac{1}{|\mathcal{B}_{k,j-}|}\sum_{i \in\mathcal{B}_{k,j-}}\frac{1}{\varepsilon+\underbrace{\hbox{\pagecolor{yellow !15}$u_{1,i}$}}_{\textrm{global}}}\nabla_{2}\ell_{1}(\underbrace{\hbox{ \pagecolor{yellow!15}$\bm{e}_{i}$}}_{\textrm{global}},\underbrace{\bm{e}_{2,j} }_{\textrm{local}},\tau)\cdot\underbrace{\nabla\bm{e}_{2,j}}_{\textrm{local}}.$ $$

Both $G_{\bm{w},1,a}$ and $G_{\bm{w},1,b}$ have two averages over $\mathcal{B}$ due to compositional structure of the loss.
For FastCLIP, the inner average (e.g. $G_{\bm{w},1,a,i}$) is computed on a single worker after gathering global parts (shaded, e.g., $\bm{e}_{2,j}$) from all workers. The outer average is then computed using All_Reduce.

Difference from OpenCLIP. Algorithmically, OpenCLIP does not use the $u$ sequence, which is equivalent to setting $\gamma_{t}=1$. In terms of distributed implementation, for computing $G_{\bm{w},1,b}$, OpenCLIP first computes $\frac{1}{\varepsilon+u_{1,i}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau)$ on the worker where $i$-th pair resides, then all workers gather them using Reduce_Scatter and uses them to compute the inner average.

FastCLIP has the same communication and computation cost for computing $G_{\bm{w},1,a}$ as OpenCLIP, but has an effective communication reduction for computing $G_{\bm{w},1,b}$. Specifically, Reduce_Scatter in OpenCLIP requires $\mathcal{O}(K|\mathcal{B}|d)$ communication cost, where $d$ is the feature dimensionality (>512 in practice). While All_Gather of $u_{1,i}$ in FastCLIP requires only $\mathcal{O}(K|\mathcal{B}|)$ communication since each $u_{1,i}$ is a scalar. This leads to a communication reduction, as verified empirically in Sec. 6.

## 5 Improvement of Optimization Components

In this section, we propose different strategies to improve three components of the FastCLIP framework, i.e., the schedule for inner LR $\gamma_{t}$, the update rule of the temperature parameter, and the optimizer for updating the model parameters.

The Inner LR Schedule: We first explore different schedules for $\gamma_{t}$ in Equation (1), which is interpreted as an SGD step with learning rate (LR) $\gamma_{t}$ by Wang & Yang (). They showed in theory that $\gamma_{t}$ should be set to a very small value close to 0 in order to guarantee convergence. However, in practice a large $\gamma_{t}$ value close to 1 is adopted (Yuan et al., ). Ideally, $\gamma_{t}$ should be large to rely more on the current mini-batch at earlier iterations and be smaller to rely more on history in later iterations. To achieve this, we consider a cosine schedule to decrease $\gamma_{t}$:
Let $t$ be the current iteration, $\hat{E}$ be the number of iterations per epoch and $E$ be the number of decay epochs, then we set $\gamma_{t}=0.5\cdot(1+\cos(\pi\lfloor t/\hat{E}\rfloor/E))\cdot(1-\gamma_{
\mathrm{min}})+\gamma_{\mathrm{min}}$.
With this schedule, $\gamma_{t}$ will decrease from 1.0 to $\gamma_{\mathrm{min}}$. Note that $\lfloor t/\hat{E}\rfloor$ denotes the current epoch, which means the value of $\gamma_{t}$ stays unchanged within one epoch.
Also, The number of decay epochs $E$ is a hyperparameter, and it is not necessarily equal to the total number of training epochs. If the current epoch exceeds $E$, $\gamma_{t}$ will be set to $\gamma_{\mathrm{min}}$.

**Table 1: Comparison between different algorithms. In Temperature Scheme, “G” denotes global temperature parameter, while “I” denotes individualized temperature parameters for each data.**
| Algorithm | Loss | FCCO | Distributed | Inner LR Schedule | Temperature Scheme |
| --- | --- | --- | --- | --- | --- |
| OpenCLIP (Ilharco et al., ) | (MBCL) | No | Yes | N/A | G, Learnable |
| SogCLR (Yuan et al., ) | (GCL) | Yes | No | Constant | G, Constant |
| iSogCLR (Qiu et al., ) | (RGCL) | Yes | No | Constant | I, Learnable |
| FastCLIP-v0 | (GCL) | Yes | Yes | Cosine | G, Learnable |
| FastCLIP-v1 | (GCL) | Yes | Yes | Cosine | G, Constant |
| FastCLIP-v2 | (RGCL) | Yes | Yes | Cosine | I, Learnable |
| FastCLIP-v3 | (RGCL-g) | Yes | Yes | Cosine | G, Learnable |

The Temperature Parameter Updates:
At Line 1 of Algorithm 1, the temperature parameter $\tau$ is updated.
The update rule is not explicitly provided due to its variety. We consider four different versions, named v0 to v3. Specifically, v1 sets $\tau$ to a constant as in SogCLR and the other three view $\tau$ as a learnable parameter: v2 leverages the same $\tau$ update as iSogCLR, which maintains individual temperature parameters for each data and updates them using gradient of (RGCL) w.r.t. $\tau$. A potential issue of maintaining and updating individualized temperature is that it may overfit the data and hence harm the generalization for large-scale data. To mitigate this issue, we also consider the following loss, which unifies the individual temperature in (RGCL) into a single global one:

$$ $\min_{\tau\geq\tau_{0}}\frac{\tau}{|\mathcal{S}|}\sum_{i\in\mathcal{S}}\left( \log\left(\varepsilon{}+g_{1}(\bm{w},\tau,i,\mathcal{S}_{i-})\right)+\log\left (\varepsilon{}+g_{2}(\bm{w},\tau,i,\mathcal{S}_{i-})\right)\right)+2\rho\tau.$ (RGCL-g) $$

We refer to this version as v3. We also include a baseline version named v0 that updates $\tau$ using the gradient of an unscaled version of (GCL) that does not multiply $\tau$, similar to the $\tau$ updates in existing works (Radford et al., ; Cherti et al., ) based on (MBCL). The explicit rules of all updates are deferred to Proc. 5 in Appendix A.
Combining the four versions of updating/setting $\tau$ with the cosine inner LR schedule, we get four algorithms FastCLIP-v0 to v3. A comparison between them and existing algorithms is shown in Table 1. Different updates of $\tau$ also lead to slightly different ways of computing the contrastive losses and gradient estimator (Line 1 and Line 1 in Algorithm 1), and the details are deferred to Appendix A due to space limit.

The Optimizer: We compare the performance of four optmizers (i.e., the update rule of model parameters and temperature at Line 1 to 1 in Algorithm 1) in FastCLIP: AdamW (Loshchilov & Hutter, ), LAMB (You et al., ), Lion (Chen et al., ) and SGD with momentum (Polyak, ). The update rules of these optimizers are presented in Proc. 4 in Appendix A for completeness.

Experiment Settings: We conduct experiments in three different settings, which differ in data scale, model architecture (vision encoder in particular), and training environment.
The difference is presented in Table 2. In all settings, we use a 12-layer transformer (Vaswani et al., ) as the text encoder. All the experiments are conducted in a multi-node setting where each node has 4 GPUs. Due to its extreme size, xlarge-scale setting is only used to compare the best version of FastCLIP with OpenCLIP.
The value of $\varepsilon$ is set to 1e-14 for all but the xlarge-scale setting, where we use a large value of 1e-6. This is discussed in Section 6 and Appendix D.

Metrics: To evaluate the performance of the trained models, we leverage the Datacomp Benchmark (Gadre et al., ), which includes 38 zero-shot downstream tasks. The evaluation metric is the average performance, which is called Datacomp. We also report the average performance on two subsets of the tasks: ImageNet and its different variants (IN & Variants), and Retrieval. IN & Variants tasks consist of ImageNet-1k (Deng et al., ) and 6 ImageNet distribution shift datasets (Wang et al., ; Recht et al., ; Hendrycks et al., ; ; Barbu et al., ) (Gadre et al., , Section 3.5). Retrieval tasks consist of Flickr30k (Young et al., ), MSCOCO (Chen et al., ), and WinoGAViL (Bitton et al., ).

**Table 2: Overview of the experiment settings. # Samples denotes the size of the dataset downloaded. Batch Size denotes per-GPU batch size, with global batch size specified in parentheses. H100 has 80GB memory. Some epochs of tested algorithms for the xlarge-scale setting were run on a different system with 16xA100 (40GB) using a local batch size 320. We rename the downloaded 315M subset of LAION400M (Schuhmann et al., ) as LAION315M to indicate its actual size.**
| Setting | Dataset | # Samples/Epochs | Vision Encoder | Batch Size | GPUs |
| --- | --- | --- | --- | --- | --- |
| Medium | CC3M | 2.7M/37 epochs | ResNet50 | 128 (1024) | 8 Tesla T4 |
| Large | CC12M | 9.1M/33 epochs | ViT-B/32 | 256 (2048) | 8 Tesla T4 |
| xLarge | LAION315M | 315M/42 epochs | ViT-B/16 | 640 (5120) | 8 H100 |

### 5.1 Results

In this subsection, we present the experiment results. We report results averaged over 3 runs with different seeds, and standard deviation in parentheses. Training details are provided in Appendix B.

The Inner LR Schedule: We first present results of different $\gamma$ schedules. We compare three pairs of approaches: SogCLR and FastCLIP-v1; iSogCLR and FastCLIP-v2; FastCLIP-v3 with Constant $\gamma$ and FastCLIP-v3, where the former of each pair uses constant $\gamma$ schedule and the latter uses cosine $\gamma$ schedule. SogCLR and iSogCLR are implemented in the same framework as FastCLIP. The results are presented in Table 5.
We can observe that all of the three approaches obtain a significant performance gain when equipped with the cosine schedule. This indicates that cosine schedule performs better than the constant schedule.
Also, when tuning the $\gamma$ value for the two schedules, we observe that constant schedule favors larger $\gamma$ values (0.6 or 0.8), while cosine schedule favors small $\gamma$ value (0.2) in the end (c.f. Table 8 in Appendix B). These results suggest: (1) $\gamma$ needs to be set to a small value as the theory predicts, (2) but instead of being constant, its value should gradually decrease.

The Temperature Parameter Updates: Next, we present the experiment results of different $\tau$ updates. We compare the four versions of FastCLIP. The results are presented in Table 5.
We have the following observations. In the medium-scale setting, the average performance on Datacomp of the four algorithms are close to each other. FastCLIP-v3 has better performance than others either on Retrieval or IN & Variants. In the large-scale setting, FastCLIP-v3 outperforms other algorithms on Datacomp and Retrieval. This demonstrates the effectiveness of FastCLIP-v3. Also we can see that FastCLIP-v0, v2 are comparable to each other while FastCLIP-v1 is generally worse in this setting.

The Optimizer: We use FastCLIP-v3 as the base algorithm and compare the AdamW, LAMB, Lion and SGD with momentum optimizers. The results are presented in Table 5.
We observe that AdamW outperforms other optimizers on most of the metrics in both settings.
This indicates that AdamW should be chosen for FastCLIP training.

## 6 Scaling Performance of FastCLIP

In this section, we compare the performance of FastCLIP using AdamW on different number of nodes in comparison with OpenCLIP. We conduct experiments on 1, 2, 4, and 8 node(s). Except for the number of nodes, other settings are kept the same as the experiment settings specified in Section 5. Training details and additional experiment results are provided in Appendix B and E, respectively.

**Table 3: Performance of different inner LR schedules. Shaded algorithms use the cosine schedule, while the others use the constant schedule. Improvement denotes the absolute difference between two algorithms on the three metrics. ^∗: v3 (Const. $\gamma$) denotes FastCLIP-v3 with constant $\gamma$ schedule.**
| Setting | Algorithm | Datacomp | Retrieval | IN & Variants | Improvement |
| --- | --- | --- | --- | --- | --- |
|  | SogCLR | 23.41 (0.34) | 27.48 (0.24) | 16.90 (0.01) |  |
|  | FastCLIP-v1 | 24.87 (0.13) | 29.28 (0.30) | 18.86 (0.09) | 1.46, 1.80, 1.96 |
|  | iSogCLR | 23.35 (0.63) | 27.92 (0.34) | 17.05 (0.14) |  |
|  | FastCLIP-v2 | 24.10 (0.34) | 29.32 (1.29) | 18.52 (0.37) | 0.75, 1.40, 1.47 |
|  | v3 (Const. $\gamma$)^∗ | 23.60 (0.18) | 27.68 (0.17) | 17.33 (0.22) |  |
| Medium | FastCLIP-v3 | 24.76 (0.26) | 30.36 (0.18) | 19.08 (0.16) | 1.16, 2.68, 1.75 |
|  | SogCLR | 29.91 (0.23) | 30.16 (0.36) | 22.98 (0.07) |  |
|  | FastCLIP-v1 | 30.65 (0.11) | 32.66 (0.12) | 24.26 (0.06) | 0.74, 2.50, 1.28 |
|  | iSogCLR | 30.32 (0.18) | 30.27 (0.41) | 24.96 (0.09) |  |
|  | FastCLIP-v2 | 30.94 (0.20) | 31.84 (0.17) | 25.52 (0.17) | 0.62, 1.57, 0.56 |
|  | v3 (Const. $\gamma$)^∗ | 29.46 (0.39) | 30.33 (0.58) | 23.69 (0.09) |  |
| Large | FastCLIP-v3 | 31.60 (0.46) | 34.88 (0.28) | 24.78 (0.28) | 2.14, 4.55, 1.09 |

Performance:
The results of selected models based on the average Datacomp performance are presented in Figure 4, Subfigures (a) and (b) are the IN & Variants and Retrieval performance in the medium-scale setting, and subfigures (c) and (d) are the results in the large-scale setting. We can observe that FastCLIP-v3 consistently outperforms OpenCLIP across different number of nodes. This clearly illustrates the advantage of GCL family over MBCL. Also, the performance of FastCLIP-v3 plateaus at 2 nodes, which verifies that FastCLIP does not require a large amount of computing resources. In contrast, OpenCLIP has a significant performance gain when scaling from 2 nodes to 8 nodes, meaning that it requires a large amount of computing resources to obtain good performance. Additionally, Figure 1 demonstrates the significant speedup of FastCLIP-v3 over OpenCLIP.

Figure: (a) IN & Variants, Medium
Refer to caption: x10.png

Training Time:
In addition to the performance on downstream tasks, we also compare the training time of OpenCLIP and FastCLIP-v1 to v3. We use PyTorch (Paszke et al., ) Profiler to record the data. We break down per-iteration training time into 3 parts: computation, pure communication (not overlapped with computation), and others. The results are plotted in Figure 4 (a) and (b). We also break down communication into two parts: communication overlapped with computation and pure communication, which are plotted in Figure 4 (c) and (d).
From subfigures (a) and (b) we can see that the running time of FastCLIP is similar to OpenCLIP when the number of nodes is small (1 and 2), and becomes shorter than OpenCLIP when the number of nodes scales up (4 and 8). This is because OpenCLIP has a longer communication time on 4 and 8 nodes (subfigures (c) and (d)), which demonstrates the effectiveness of our efficient gradient computation/communication strategy described in Section 4.
The above results are obtained from a cluster with InfiniBand interconnect. We also profile the training time of the algorithms on two other clusters with Slingshot interconnect, where we observe the same trend. We defer the additional results to Appendix E due to space limit.
For each algorithm, we also plot its speedup over 1 node in terms of training time in Figure 4 (a) and (b). All algorithms have similar speedup over 1 node and the gap between the ideal speedup (which is number of nodes) and the real speedup becomes larger when the number of nodes scales up. This indicates that training with more resources has a diminishing return.

**Table 6: Summary of existing and our results of training CLIP models on xlarge-scale data.**
| Work | Architecture | Data Size (M) | Batch Size | Samples (B) | IN 0-shot (%) |
| --- | --- | --- | --- | --- | --- |
| Cherti et al. () | ViT-B/16 | 80 | 90112 | 13 | 60.24 |
| Cherti et al. () | ViT-B/16 | 400 | 33792 | 13 | 67.00 |
| Cherti et al. () | ViT-B/16 | 2000 | 90112 | 13 | 68.13 |
| Chen et al. () | ViT-B/32 | 400 | 65536 | 13 | 64.30 |
| OpenCLIP (our impl.) | ViT-B/16 | 315 | 5120 | 13 | 62.90 |
| FastCLIP-v3 | ViT-B/16 | 315 | 5120 | 13 | 64.49 |

Results in the xlarge-scale setting. Moreover, we evaluate the performance of FastCLIP-v3 and OpenCLIP in the xlarge-scale setting with 8 H100 GPUs. We plot the ImageNet-1k top 1 accuracy curve in Figure 4 (a). After seeing 13B examples, OpenCLIP achieves a top1 accuracy of 62.90% on ImageNet-1k,
while FastCLIP-v3 achieves an accuracy of 64.49%, resulting in a 1.59% gain. This result is competitive with the state-of-the-art results of CLIP training using much more compute resources as shown in Table 6. We also note that the result of our OpenCLIP implementation is lower than those reported in other works, e.g., 67% in OpenCLIP paper that uses a batch size of 33,792 and 400M dataset (Cherti et al., ). This is because in our setting we use a smaller dataset (315M) and a smaller batch size (5120).
We provide a discussion of the impact of dataset size and batch size in Appendix C.
For FastCLIP-v3 in the xlarge-scale setting, we found that assigning a larger value of 1e-6 to the constant $\varepsilon$ than the default 1e-14 in loss computation of (RGCL-g) leads to improved ImageNet-1k top 1 accuracy.
We provide a brief discussion of this observation in Appendix D.
We also evaluate the Datacomp performance of FastCLIP-v3 and OpenCLIP in the xlarge-scale setting, which exhibits similar result, as shown in Appendix E.

In summary, the results in this section demonstrate the effectiveness of FastCLIP across different data scales (3 million to 315 million) and compute scales (1 to 8 nodes) in the limited-resource setting.

## 7 Conclusion

In this paper, we have proposed a distributed training framework of CLIP models in a resource-limited setting named FastCLIP. It leverages advanced compositional optimization with a novel gradient computation strategy to reduce the communication cost. We have investigated different optimization components, by proposing new techniques and benchmarking different techniques for each component under different settings to provide valuable insights on which techniques to use. Finally, leveraging the best-performant techniques from the experiment results, we compare the performance of FastCLIP with OpenCLIP on different data scales and compute scales, from 3 million to 315 million image-text pairs and from 1 node to 8 nodes. The results demonstrate that FastCLIP outperforms OpenCLIP by a large margin and achieves a significant speedup. This helps accelerate research in the areas of CLIP training and its various applications, as more researchers would be able to contribute their ideas and train CLIP models without access to a large amount of resources.

## 8 Limitations and Future Work

Due to limited computing resources, we were unable to perform an extensive ablation study on the LAION315M dataset. As a future work, we will consider how to further improve the performance of FastCLIP in various aspects, e.g., reducing communication time, improving the convergence rate, etc.

## Appendix A Details of the FastCLIP Framework

Figure: Procedure 2 contrastive_loss

Figure: Procedure 3 gradient_estimator

Figure: Procedure 4 parameter_update

Figure: Procedure 5 temperature_update

Derivation of gradient of (GCL) w.r.t. $\bm{w}$: Given a global batch $\mathcal{B}$, the gradient of (GCL) w.r.t. $\bm{w}$ is given by $G_{\bm{w},a}+G_{\bm{w},b}$, where

$$ $\displaystyle G_{\bm{w},a}=$ $\displaystyle\tau\cdot\frac{1}{K}\sum_{k=1}^{K}\overbrace{\frac{1}{|\mathcal{B }_{k}|}\sum_{i\in\mathcal{B}_{k}}\frac{1}{\varepsilon{}+u_{1,i}}\cdot\frac{1}{ K}\sum_{k^{\prime}=1}^{K}\frac{1}{|\mathcal{B}_{k^{\prime},i-}|}\sum_{j\in \mathcal{B}_{k^{\prime},i-}}\nabla_{1}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau) \cdot\nabla\bm{e}_{i}}^{G_{\bm{w},a,1,k}}$ $\displaystyle+\tau\cdot\frac{1}{K}\sum_{k=1}^{K}\overbrace{\frac{1}{|\mathcal{ B}_{k}|}\sum_{i\in\mathcal{B}_{k}}\frac{1}{\varepsilon{}+u_{2,i}}\cdot\frac{1} {K}\sum_{k^{\prime}=1}^{K}\frac{1}{|\mathcal{B}_{k^{\prime},i-}|}\sum_{j\in \mathcal{B}_{k^{\prime},i-}}\nabla_{1}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau) \cdot\nabla\bm{e}_{i}}^{G_{\bm{w},a,2,k}}.$ $$

$$ $\displaystyle G_{\bm{w},b}=$ $\displaystyle\tau\cdot\frac{1}{K}\sum_{k=1}^{K}\frac{1}{|\mathcal{B}_{k}|}\sum _{i\in\mathcal{B}_{k}}\frac{1}{\varepsilon{}+u_{1,i}}\cdot\frac{1}{K}\sum_{k^{ \prime}=1}^{K}\frac{1}{|\mathcal{B}_{k^{\prime},i-}|}\sum_{j\in\mathcal{B}_{k^ {\prime},i-}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau)\cdot\nabla\bm{e} _{2,j}$ $\displaystyle+\tau\cdot\frac{1}{K}\sum_{k=1}^{K}\frac{1}{|\mathcal{B}_{k}|} \sum_{i\in\mathcal{B}_{k}}\frac{1}{\varepsilon{}+u_{2,i}}\cdot\frac{1}{K}\sum_ {k^{\prime}=1}^{K}\frac{1}{|\mathcal{B}_{k^{\prime},i-}|}\sum_{j\in\mathcal{B} _{k^{\prime},i-}}\nabla_{2}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau)\cdot\nabla \bm{e}_{1,j}.$ $$

To compute $G_{\bm{w},a}$, we first gather all the $\bm{e}_{2,j}$ and $\bm{e}_{1,j}$ using All_Gather to each worker, then compute $G_{\bm{w},a,1,k}$ and $G_{\bm{w},a,2,k}$ on the $k$-th worker, and average $G_{\bm{w},a,1,k}$ and $G_{\bm{w},a,2,k}$ over each worker using All_Reduce. To compute $G_{\bm{w},b}$, we first switch the inner and outer averages:

$$ $\displaystyle G_{\bm{w},b}=$ $\displaystyle\tau\cdot\frac{1}{K}\sum_{k^{\prime}=1}^{K}\overbrace{\frac{1}{| \mathcal{B}_{k^{\prime}}|}\sum_{j\in\mathcal{B}_{k^{\prime}}}\cdot\frac{1}{K} \sum_{k=1}^{K}\frac{1}{|\mathcal{B}_{k,j-}|}\sum_{i\in\mathcal{B}_{k,j-}}\frac {1}{\varepsilon{}+u_{1,i}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau) \cdot\nabla\bm{e}_{2,j}}^{G_{\bm{w},b,1,k^{\prime}}}$ $\displaystyle+\tau\cdot\frac{1}{K}\sum_{k^{\prime}=1}^{K}\overbrace{\frac{1}{| \mathcal{B}_{k^{\prime}}|}\sum_{j\in\mathcal{B}_{k^{\prime}}}\cdot\frac{1}{K} \sum_{k=1}^{K}\frac{1}{|\mathcal{B}_{k,j-}|}\sum_{i\in\mathcal{B}_{k,j-}}\frac {1}{\varepsilon{}+u_{2,i}}\nabla_{2}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau) \cdot\nabla\bm{e}_{1,j}}^{G_{\bm{w},b,2,k^{\prime}}}.$ $$

Then we gather all the $\bm{u}_{1,i}$ and $\bm{u}_{2,i}$ using All_Gather to each worker, and compute $G_{\bm{w},b,1,k^{\prime}}$ and $G_{\bm{w},b,2,k^{\prime}}$ on the $k^{\prime}$-th worker, then average $G_{\bm{w},b,1,k^{\prime}}$ and $G_{\bm{w},b,2,k^{\prime}}$ over each worker using All_Reduce to get $G_{\bm{w},b}$. For practical consideration, we switch the inner and outer averages in $G_{\bm{w},b,1,k^{\prime}}$ and $G_{\bm{w},b,2,k^{\prime}}$ again so that we can compute them along with $G_{\bm{w},a,1,k}$ and $G_{\bm{w},a,2,k}$ using the same function:

$$ $\displaystyle G_{\bm{w},b,1,k^{\prime}}=$ $\displaystyle\frac{1}{|\mathcal{B}_{k^{\prime}}|}\sum_{j\in\mathcal{B}_{k^{ \prime}}}\cdot\frac{1}{K}\sum_{k=1}^{K}\frac{1}{|\mathcal{B}_{k,j-}|}\sum_{i \in\mathcal{B}_{k,j-}}\frac{1}{\varepsilon{}+u_{1,i}}\nabla_{2}\ell_{1}(\bm{e} _{i},\bm{e}_{2,j},\tau)\cdot\nabla\bm{e}_{2,j}$ $\displaystyle\overset{(*)}{=}$ $\displaystyle\frac{1}{|\mathcal{B}_{k^{\prime}}|}\sum_{j\in\mathcal{B}_{k^{ \prime}}}\cdot\frac{1}{|\mathcal{B}_{j-}|}\sum_{i\in\mathcal{B}_{j-}}\frac{1}{ \varepsilon{}+u_{1,i}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau)\cdot \nabla\bm{e}_{2,j}$ $\displaystyle=$ $\displaystyle\frac{1}{|\mathcal{B}|}\sum_{i\in\mathcal{B}}\frac{1}{\varepsilon {}+u_{1,i}}\cdot\frac{1}{|\mathcal{B}_{k^{\prime}}|}\cdot\frac{|\mathcal{B}|}{ |\mathcal{B}_{j-}|}\sum_{j\in\mathcal{B}_{k^{\prime},i-}}\nabla_{2}\ell_{1}( \bm{e}_{i},\bm{e}_{2,j},\tau)\cdot\nabla\bm{e}_{2,j},$ $$

where $(*)$ uses the fact that the average over local batch and workers is equal to the average over the global batch. Similarly,

$$ $G_{\bm{w},b,2,k^{\prime}}=\frac{1}{|\mathcal{B}|}\sum_{i\in\mathcal{B}}\frac{1 }{\varepsilon{}+u_{2,i}}\cdot\frac{1}{|\mathcal{B}_{k^{\prime}}|}\cdot\frac{| \mathcal{B}|}{|\mathcal{B}_{j-}|}\sum_{j\in\mathcal{B}_{k^{\prime},i-}}\nabla_ {2}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau)\cdot\nabla\bm{e}_{1,j}.$ $$

Deferred Computation in Alg.1: At iteration $t$, for SogCLR and other algorithms with global temperature parameter (except FastCLIP-v0), the gradient estimator for $\bm{w}$ on $k$-th worker is computed as

$$ $\displaystyle G_{\bm{w},a,k}^{t}=\frac{\tau^{t}}{|\mathcal{B}_{k}^{t}|}\sum_{i \in\mathcal{B}_{k}^{t}}$ $\displaystyle\left(\frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{1}\ell_{1}(\bm{e} _{i},\bm{e}_{2,j},\tau^{t})\cdot\nabla\bm{e}_{i}\right)\right.$ (2) $\displaystyle\left.+\frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{1}\ell_{2}(\bm{e} _{i},\bm{e}_{1,j},\tau^{t})\cdot\nabla\bm{e}_{i}\right)\right).$ $$

$$ $\displaystyle G_{\bm{w},b,k}^{t}=\frac{\tau^{t}}{|\mathcal{B}^{t}|}\sum_{i\in \mathcal{B}^{t}}$ $\displaystyle\left(\frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{k}^{t}|}\cdot\frac{|\mathcal{B}^{t}|}{|\mathcal{B}_{i-}^{t}|}\sum _{j\in\mathcal{B}_{k,i-}^{t}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau^{ t})\cdot\nabla\bm{e}_{2,j}\right)\right.$ (3) $\displaystyle\left.+\frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{k}^{t}|}\cdot\frac{|\mathcal{B}^{t}|}{|\mathcal{B}_{i-}^{t}|}\sum _{j\in\mathcal{B}_{k,i-}^{t}}\nabla_{2}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau^{ t})\cdot\nabla\bm{e}_{1,j}\right)\right).$ $$

For FastCLIP-v0, we need to remove the $\tau^{t}$ at the front:

$$ $\displaystyle G_{\bm{w},a,k}^{t}=\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in \mathcal{B}_{k}^{t}}$ $\displaystyle\left(\frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{1}\ell_{1}(\bm{e} _{i},\bm{e}_{2,j},\tau^{t})\cdot\nabla\bm{e}_{i}\right)\right.$ (4) $\displaystyle\left.+\frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{1}\ell_{2}(\bm{e} _{i},\bm{e}_{1,j},\tau^{t})\cdot\nabla\bm{e}_{i}\right)\right).$ $$

$$ $\displaystyle G_{\bm{w},b,k}^{t}=\frac{1}{|\mathcal{B}^{t}|}\sum_{i\in\mathcal {B}^{t}}$ $\displaystyle\left(\frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{k}^{t}|}\cdot\frac{|\mathcal{B}^{t}|}{|\mathcal{B}_{i-}^{t}|}\sum _{j\in\mathcal{B}_{k,i-}^{t}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau^{ t})\cdot\nabla\bm{e}_{2,j}\right)\right.$ (5) $\displaystyle\left.+\frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\left(\frac{1}{| \mathcal{B}_{k}^{t}|}\cdot\frac{|\mathcal{B}^{t}|}{|\mathcal{B}_{i-}^{t}|}\sum _{j\in\mathcal{B}_{k,i-}^{t}}\nabla_{2}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau^{ t})\cdot\nabla\bm{e}_{1,j}\right)\right).$ $$

For iSogCLR and other algorithms with individual temperature parameter, it is computed using a slightly different formula (the $\tau$ part is different)

$$ $\displaystyle G_{\bm{w},a,k}^{t}=\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in \mathcal{B}_{k}^{t}}$ $\displaystyle\left(\frac{\tau_{1,i}^{t}}{\varepsilon{}+u_{1,i}^{t+1}}\left( \frac{1}{|\mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{1}\ell_ {1}(\bm{e}_{i},\bm{e}_{2,j},\tau_{1,i}^{t})\cdot\nabla\bm{e}_{i}\right)\right.$ (6) $\displaystyle\left.+\frac{\tau_{2,i}^{t}}{\varepsilon{}+u_{2,i}^{t+1}}\left( \frac{1}{|\mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{1}\ell_ {2}(\bm{e}_{i},\bm{e}_{1,j},\tau_{2,i}^{t})\cdot\nabla\bm{e}_{i}\right)\right).$ $$

$$ $\displaystyle G_{\bm{w},b,k}^{t}=\frac{1}{|\mathcal{B}^{t}|}\sum_{i\in\mathcal {B}^{t}}$ $\displaystyle\left(\frac{\tau_{1,i}^{t}}{\varepsilon{}+u_{1,i}^{t+1}}\left( \frac{1}{|\mathcal{B}_{k}^{t}|}\cdot\frac{|\mathcal{B}^{t}|}{|\mathcal{B}_{i-} ^{t}|}\sum_{j\in\mathcal{B}_{k,i-}^{t}}\nabla_{2}\ell_{1}(\bm{e}_{i},\bm{e}_{2 ,j},\tau_{1,i}^{t})\cdot\nabla\bm{e}_{2,j}\right)\right.$ (7) $\displaystyle\left.+\frac{\tau_{2,i}^{t}}{\varepsilon{}+u_{2,i}^{t+1}}\left( \frac{1}{|\mathcal{B}_{k}^{t}|}\cdot\frac{|\mathcal{B}^{t}|}{|\mathcal{B}_{i-} ^{t}|}\sum_{j\in\mathcal{B}_{k,i-}^{t}}\nabla_{2}\ell_{2}(\bm{e}_{i},\bm{e}_{1 ,j},\tau_{2,i}^{t})\cdot\nabla\bm{e}_{1,j}\right)\right).$ $$

FastCLIP-v0 computes the following gradient estimator for $\tau$:

$$ $\displaystyle G_{\tau,k}^{t}=$ $\displaystyle\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in\mathcal{B}_{k}^{t}} \frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\cdot\frac{1}{|\mathcal{B}_{i-}^{t}|}\sum _{j\in\mathcal{B}_{i-}^{t}}\nabla_{3}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j},\tau^{t}),$ (8) $\displaystyle+\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in\mathcal{B}_{k}^{t}} \frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\cdot\frac{1}{|\mathcal{B}_{i-}^{t}|}\sum _{j\in\mathcal{B}_{i-}^{t}}\nabla_{3}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j},\tau^{t}).$ $$

FastCLIP-v2 computes the following gradient estimators for $\tau$:

$$ $\displaystyle G_{\tau,1,i}^{t}=$ $\displaystyle\frac{1}{|\mathcal{S}|}\left(\log\left(\varepsilon{}+u_{1,i}^{t+1 }\right)+\rho+\tau_{1,i}^{t}\cdot\frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\cdot \frac{1}{|\mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{3}\ell_ {1}(\bm{e}_{i},\bm{e}_{2,j},\tau_{1,i}^{t})\right),$ (9) $\displaystyle G_{\tau,2,i}^{t}=$ $\displaystyle\frac{1}{|\mathcal{S}|}\left(\log\left(\varepsilon{}+u_{2,i}^{t+1 }\right)+\rho+\tau_{2,i}^{t}\cdot\frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\cdot \frac{1}{|\mathcal{B}_{i-}^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{3}\ell_ {2}(\bm{e}_{i},\bm{e}_{1,j},\tau_{2,i}^{t})\right),$ $$

FastCLIP-v3 computes the following gradient estimator for $\tau$:

$$ $\displaystyle G_{\tau,k}^{t}=$ $\displaystyle\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in\mathcal{B}_{k}^{t}} \left(\log\left(\varepsilon{}+u_{1,i}^{t+1}\right)+\log\left(\varepsilon{}+u_{ 2,i}^{t+1}\right)\right)+2\rho$ (10) $\displaystyle+\tau^{t}\cdot\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in\mathcal{B }_{k}^{t}}\frac{1}{\varepsilon{}+u_{1,i}^{t+1}}\cdot\frac{1}{|\mathcal{B}_{i-} ^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{3}\ell_{1}(\bm{e}_{i},\bm{e}_{2,j },\tau^{t})$ $\displaystyle+\tau^{t}\cdot\frac{1}{|\mathcal{B}_{k}^{t}|}\sum_{i\in\mathcal{B }_{k}^{t}}\frac{1}{\varepsilon{}+u_{2,i}^{t+1}}\cdot\frac{1}{|\mathcal{B}_{i-} ^{t}|}\sum_{j\in\mathcal{B}_{i-}^{t}}\nabla_{3}\ell_{2}(\bm{e}_{i},\bm{e}_{1,j },\tau^{t}).$ $$

## Appendix B Experiment Hyperparameters

Unless otherwise specified, for both FastCLIP and OpenCLIP, we use AdamW as the optimizer. For all settings, we use a cosine learning rate (LR) schedule for updating model parameters, which first linearly increases the LR from 0 to peak LR in the warmup stage, then decreases it following a cosine function. The hyperparameters we use are specified in Table 7. Other hyperparameters regarding the inner learning rate schedule, temperature parameter updates, and the LAMB optimizer will be introduced in the paragraphs that follow.

**Table 7: Hyperparameters for different settings. $\beta_{1},\beta_{2},\epsilon$ are hyperparameters in the AdamW optimizer. lr denotes the peak learning rate. min_lr denotes the learning rate at the end of training. wd denotes the weight decay. warmup denotes the number of iterations in the warmup stage.**
| Setting | $\beta_{1}$ | $\beta_{2}$ | $\epsilon$ | lr | min_lr | wd | warmup |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Medium | 0.9 | 0.999 | 1e-8 | 1e-3 | 0 | 0.1 | 10k |
| Large | 0.9 | 0.98 | 1e-6 | 4e-4 | 0 | 0.1 | 10k |
| xLarge | 0.9 | 0.98 | 1e-6 | 2e-4 | 0 | 0.2 | 13k |

Experiments benchmarking the inner LR schedule: We compare three pairs of approaches: SogCLR and FastCLIP-v1; iSogCLR and FastCLIP-v2; FastCLIP-v3 with constant $\gamma$ and FastCLIP-v3, where the former of each pair uses constant $\gamma$ schedule and the latter uses cosine $\gamma$ schedule. Any two approaches of each pair only differ in $\gamma$ schedule. For approaches using constant $\gamma$ schedule, we tune the value of $\gamma$ in $\{0.2,0.4,0.6,0.8\}$. For approaches using cosine $\gamma$ schedule, we tune the value of $\gamma_{\mathrm{min}}$ (the value $\gamma$ will decay to in the end) in $\{0.2,0.6\}$ and decay epochs in $\{50\%,100\%\}$ of the number of training epochs. The $\gamma$ values for each algorithm are presented in Table 8. Other hyperparameters are kept the same within each pair. For SogCLR and FastCLIP-v1, we set the temperature parameter to 0.03. For iSogCLR and FastCLIP-v2, we set the initial temperature parameter to 0.03, $\rho$ to 9.0, and the learning rate of $\tau$ to 1e-2. For FastCLIP-v3 with constant $\gamma$ schedule and FastCLIP-v3, we set the initial temperature parameter to 0.07, $\rho$ to 6.5 in the medium-scale setting and 8.5 in the large-scale setting, and learning rate of $\tau$ to 2e-4 in the medium-scale setting and 1e-4 in the large-scale setting. For FastCLIP-v3, its learning rate of $\tau$ decays to 1/3 of its original value when $\tau$ becomes smaller than 0.03.

**Table 8: Values of $\gamma$ for different schedules in different settings. For Cosine $\gamma$ schedule, we report the $\gamma$ value along with number of $\gamma$ decay epochs $E$ (c.f. Section 5). ^∗: v3 (Const. $\gamma$) denotes FastCLIP-v3 with constant $\gamma$ schedule.**
|  | Constant $\gamma$ | Cosine $\gamma$ |  |  |
| --- | --- | --- | --- | --- |
| Setting | Algorithm | $\gamma$ | Algorithm | $\gamma_{\mathrm{min}},E$ |
|  | SogCLR | 0.6 | FastCLIP-v1 | 0.2, 18 |
|  | iSogCLR | 0.6 | FastCLIP-v2 | 0.2, 18 |
| Medium | v3 (Const. $\gamma$)^∗ | 0.6 | FastCLIP-v3 | 0.2, 18 |
|  | SogCLR | 0.6 | FastCLIP-v1 | 0.2, 16 |
|  | iSogCLR | 0.8 | FastCLIP-v2 | 0.6, 16 |
| Large | v3 (Const. $\gamma$)^∗ | 0.6 | FastCLIP-v3 | 0.2, 16 |
| xLarge | - | - | FastCLIP-v3 | 0.8, 10 |

Experiments benchmarking the temperature parameter updates: For all algorithms we leverage a cosine $\gamma$ schedule with $\gamma_{\mathrm{min}}=0.2$ and decay epochs $E$ equal to 50% of the number of training epochs. For all algorithms, we tune their initial temperature parameter in $\{0.03,0.05,0.07\}$. For FastCLIP-v2 and -v3, we tune $\rho$ in $[6.0,9.0]$, we also tune the learning rate of $\tau$ in $[1\mathrm{e}-4,1\mathrm{e}-2]$. Other hyperparameters are kept the same for the four algorithms. The tuned initial temperature is 0.07 for FastCLIP-v3 and 0.03 for other algorithms. The $\rho$ values are presented in Table 9. For FastCLIP-v2, the tuned learning rate of $\tau$ is 1e-2 in the medium-scale setting and 1e-4 in the large-scale setting. For FastCLIP-v3, the tuned learning rate of $\tau$ is 2e-4 in the medium-scale setting and 1e-4 in the large-scale setting. For FastCLIP-v3, its learning rate of $\tau$ decays to 1/3 of its original value when $\tau$ becomes smaller than 0.03.

**Table 9: Value of $\rho$ for FastCLIP-v2 and -v3 in different settings.**
| Algorithm | Medium | Large | xLarge |
| --- | --- | --- | --- |
| FastCLIP-v2 | 7.0 | 8.5 | - |
| FastCLIP-v3 | 6.5 | 8.5 | 16.0 |

Experiments benchmarking the optimizer: We use FastCLIP-v3 as the base algorithm. For SGD with momentum, we tune its learning rate of model parameters in [4e-5, 4e0] and weight decay in [1e-6, 0.2]. For all other optimizers, we tune their learning rate of model parameters in [4e-5, 4e-3] and weight decay in [0.01, 0.2]. Other hyperparameters are kept the same as in Temperature Parameter Updates. The tuned learning rate of model parameters and weight decay are reported in Table 10.
Following OpenCLIP (Cherti et al., ), we set the weight decay of the temperature parameter to 0. And following EVA-CLIP (Sun et al., ) in the implementation of LAMB, we set $\alpha$ at Line 4 in Proc. 4 to 1.0 when updating the temperature parameter, leading to the same update as AdamW.

**Table 10: Values of learning rate of model parameters and weight decay for different optimizers. SGDM denotes SGD with momentum.**
|  | Medium | Large |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Hyperparameters | SGDM | LAMB | Lion | AdamW | SGDM | LAMB | Lion | AdamW |
| Learning rate | 1.0 | 2e-3 | 2e-4 | 1e-3 | 2.0 | 2e-3 | 1e-4 | 4e-4 |
| Weight decay | 3e-6 | 0.1 | 0.3 | 0.1 | 3e-6 | 0.1 | 0.3 | 0.1 |

Experiments demonstrating the scaling performance: We tune the learning rate of model parameters of OpenCLIP on 2 nodes in the medium-scale and large-scale setting in $[4\mathrm{e}-5,4\mathrm{e}-3]$, and on 4 nodes in the xlarge-scale setting in $[4\mathrm{e}-5,4\mathrm{e}-4]$. The tuned learning rate of model parameters of OpenCLIP is 1e-3, 4e-4 and 2e-4 in the medium-scale, large-scale and xlarge-scale setting, respectively. Other hyperparameters are set according to Table 7 to 9. In the xlarge-scale setting, we set the learning rate of model parameters of FastCLIP-v3 to the same value as OpenCLIP. For different number of nodes in the medium-scale and large-scale setting, we scale the learning rate of model parameters and temperature parameter linearly in proportion to global batch size and keep other hyperparameters unchanged. For FastCLIP-v3 in the xlarge-scale setting, we set $\rho$ to 16.0 and the learning rate of temperature parameter to 5e-5. We leverage a cosine $\gamma$ schedule with $\gamma_{\mathrm{min}}=0.8$ and decay epochs $E=10$.

Choice of $\gamma_{\mathrm{min}}$ in the xlarge-scale setting: Note that in the xlarge-scale setting we use a larger $\gamma_{\mathrm{min}}$ value than in the medium-scale and large-scale settings.
We find that the batch size impacts how we should set the $\gamma_{\mathrm{min}}$ value. To illustrate this, we conduct two sets of experiments in the large-scale setting on 2 nodes and 8 nodes, respectively. Each set is FastCLIP-v3 with different $\gamma_{\mathrm{min}}$ value. The results are plotted in Figure 5. Comparing a larger $\gamma_{\mathrm{min}}$ (0.8) with a smaller one (0.2) in the same setting, we find that the training can be split into three stages. In the first stage, the two runs have similar performance. In the second stage, larger $\gamma_{\mathrm{min}}$ outperforms the smaller one, while the smaller one catches up with the larger one and outperforms it in the last stage. From Figure 5 we can also observe that with a larger global batch size, the second stage becomes longer. Note that in the medium-scale and large-scale settings we use a global batch size of 1024 and 2048 respectively, while we set it to 5120 in the xlarge-scale setting. We also conjecture that the second stage becomes longer as the data scales up, though we did not validate this due to resource limits. The large batch size and large data scale in the xlarge-scale setting motivate our use of a larger $\gamma_{\mathrm{min}}$ value than in the medium-scale and large-scale settings.

Figure: (a) 2 Nodes, Batch size 2048
Refer to caption: x21.png

## Appendix C The impact of batch size and dataset size on OpenCLIP

The ImageNet-1k top 1 accuracy of OpenCLIP in the xlarge-scale setting (LAION315M for 13B samples, batch size 5120) is 62.90%, while the result of OpenCLIP reported in Cherti et al. () (LAION400M for 13B samples, batch size 33792) is 67.00%. We attribute the gap to smaller batch size and smaller dataset size. We first summarize some existing results that demonstrate the impact of these two factors:

**Table 11: Summary of existing results of training using OpenCLIP.**
| Work | Architecture | Data Size (M) | Batch Size | Samples (B) | Performance (%) |
| --- | --- | --- | --- | --- | --- |
| Cherti et al. () | ViT-B/16 | 80 | 90112 | 13 | 60.24 |
| Cherti et al. () | ViT-B/16 | 400 | 33792 | 13 | 67.00 |
| Cherti et al. () | ViT-B/16 | 2000 | 90112 | 13 | 68.13 |
| Chen et al. () | ViT-B/32 | 100 | 8192 | 1.6 | 48.76 |
| Chen et al. () | ViT-B/32 | 100 | 16384 | 1.6 | 50.95 |
| Chen et al. () | ViT-B/32 | 100 | 32768 | 1.6 | 51.64 |
| Chen et al. () | ViT-B/32 | 100 | 65536 | 1.6 | 51.91 |
| Chen et al. () | ViT-B/32 | 400 | 65536 | 13 | 64.3 |
| OpenCLIP (our impl.) | ViT-B/16 | 315 | 5120 | 13 | 62.90 |

- •
Batch size: We use a smaller batch size of 5120 for the xlarge scale training due to limited compute resources, which is 6 times smaller than the batch size used in Cherti et al. () (33792, with 67% performance of ViT-B/16) and 12.8 times smaller than that in Chen et al. () (65536, with 64.3% performance of ViT-B/32). As reported in existing works, e.g., Chen et al. (), batch size has an important impact on OpenCLIP. The results in the table above clearly demonstrate this. If we fit the performance in Chen et al. () for different batch sizes (rows 4-7 in the table above) with a reciprocal function $p=-a/x+b$, where $x$ is the batch size and $p$ is the ImageNet-1k top 1 accuracy, the results (plotted in Figure 6 (a)) showed that the predicted performance with batch size 5120 has a 5% drop compared with batch size 32768. This is somewhat consistent with that our result using 5120 batch size has a 4.1% drop in performance for OpenCLIP than using 33792 batch size as in Cherti et al. ().
- •
Dataset size: Although we intended to use LIAON400M, due to broken URLs we could only download a subset of the LAION400M dataset, which consists of 315M image-text pairs. This is also a factor contributing to the worse performance of OpenCLIP as Cherti et al. () reported that using 80M data leads to a performance drop by 7% compared with 400M data (rows 1-2 in the table above). If we fit the results in Cherti et al. () for different data sizes with a power function $p=\alpha x^{\beta}+p_{0}$, where $x$ is the dataset size and $p$ is the ImageNet-1k top 1 accuracy. The results (plotted in Figure 6 (b)) showed that the predicted performance of OpenCLIP training ViT-B/16 on a 315M dataset with 13B samples seen and at least 33K batch size is 64.5%. Our OpenCLIP using a smaller batch size of 5120 (last row of the table) achieves 62.90%, which is expected considering the small batch size.

Figure: (a) Results of Chen et al. (). Blue dots: results from Chen et al. (). Red line: fitted using blue dots. Orange dot: predicted result.
Refer to caption: x23.png

## Appendix D The effect of ε 𝜀 \varepsilon italic_ε in ( RGCL-g )

We found that in the xlarge-scale setting, the constant $\varepsilon$ plays an important role in the performance of FastCLIP-v3. In particular, the gradient estimators $G_{\bm{w},a,k}^{t}$ and $G_{\bm{w},b,k}^{t}$ of (RGCL-g) in Equation (2) and (3) are scaled by two factors: $1/(\varepsilon{}+u_{1,i}^{t+1})$ and $1/(\varepsilon{}+u_{2,i}^{t+1})$. Recall that $\bm{u}_{1,i}$ and $\bm{u}_{2,i}$ are approximations of $g_{1}(\bm{w}^{t},\tau^{t},i,\mathcal{S}_{i-})$ and $g_{2}(\bm{w}^{t},\tau^{t},i,\mathcal{S}_{i-})$, respectively. Thus, in the later stage of training many examples (those that are well-learned) will have very small $\bm{u}_{1,i}^{t+1}$ and $\bm{u}_{2,i}^{t+1}$. Then with a very small $\varepsilon$ the scaling factors in the estimated gradient for these samples will be very large, which may suffer from over-optimization for those examples and harm generalization.
In the following figure, we plot the performance of FastCLIP-v3 with two schemes of $\varepsilon$ along with the performance of OpenCLIP (in blue): i) $\varepsilon$= 1e-14 (in orange) and ii) $\varepsilon$= 1e-6 (in green). The value 1e-6 is not tuned due to limited compute resources and the three experiments were run for only 30 epochs (9.45B samples seen). From Figure 7 we can see that with larger $\varepsilon$, both the ImageNet-1k top 1 accuracy and Datacomp Average performance improve by a large margin.

Figure: Figure 7: ImageNet-1k Top 1 accuracy (left) and Datacomp Average performance (right) of FastCLIP-v3 with different $\varepsilon$ in the xlarge-scale setting.
Refer to caption: x25.png

## Appendix E More Experiment Results

### E.1 Optimization Components

We plot the Datacomp average performance curves of different algorithms with constant $\gamma$ schedule and cosine $\gamma$ schedule in Figure 8, which corresponds to Table 5 in Section 5. We plot the Datacomp average performance curves of algorithms with different temperature updates in Figure 9 (a) and (b), which corresponds to Table 5 in Section 5. We plot the Datacomp average performance curves of FastCLIP-v3 with AdamW and LAMB optimizer in Figure 9 (c) and (d), which corresponds to Table 5 in Section 5.

Figure: (a) Medium, FastCLIP-v1
Refer to caption: x28.png

Figure: (a) Temperature, Medium
Refer to caption: x34.png

### E.2 Scaling Performance

In this subsection we provide more results to complement the figures in Section 6.

Performance of OpenCLIP and FastCLIP-v3: The data to plot Figure 4 is presented in Table 13 and Table 14. We also provide the Datacomp performance in Table 12. The Datacomp performance of OpenCLIP and FastCLIP-v3 in the xlarge-scale setting is plotted in Figure 10.

**Table 12: Datacomp Average performance of OpenCLIP and FastCLIP-v3 trained on different number of nodes. Improvement denotes the absolute difference between FastCLIP-v3 and OpenCLIP.**
| Setting | Algorithm | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- | --- |
|  | OpenCLIP | 21.82 (0.59) | 21.84 (0.23) | 21.65 (0.13) | 22.22 (0.37) |
|  | FastCLIP-v3 | 24.54 (0.25) | 24.76 (0.26) | 24.43 (0.20) | 25.23 (0.28) |
| Medium | Improvement | 2.72 | 2.92 | 2.78 | 3.01 |
|  | OpenCLIP | 27.55 (0.46) | 27.91 (0.73) | 28.93 (0.29) | 28.75 (0.59) |
|  | FastCLIP-v3 | 30.81 (0.38) | 31.60 (0.46) | 31.65 (0.13) | 31.45 (0.32) |
| Large | Improvement | 3.26 | 3.69 | 2.72 | 2.70 |

**Table 13: Retrieval performance of OpenCLIP and FastCLIP-v3 trained on different number of nodes. Improvement denotes the absolute difference between FastCLIP-v3 and OpenCLIP.**
| Setting | Algorithm | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- | --- |
|  | OpenCLIP | 24.07 (0.16) | 25.20 (0.22) | 25.07 (0.26) | 26.20 (0.10) |
|  | FastCLIP-v3 | 30.02 (0.57) | 30.36 (0.18) | 30.42 (0.24) | 30.42 (0.24) |
| Medium | Improvement | 5.95 | 5.16 | 5.35 | 4.22 |
|  | OpenCLIP | 29.17 (0.17) | 29.58 (0.62) | 30.25 (0.31) | 30.87 (0.11) |
|  | FastCLIP-v3 | 33.90 (0.28) | 34.88 (0.28) | 34.91 (0.16) | 34.74 (0.31) |
| Large | Improvement | 4.73 | 5.30 | 4.66 | 3.87 |

**Table 14: ImageNet & Variants accuracy of OpenCLIP and FastCLIP-v3 trained on different number of nodes. Improvement denotes the absolute difference between FastCLIP-v3 and OpenCLIP.**
| Setting | Algorithm | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- | --- |
|  | OpenCLIP | 14.16 (0.11) | 14.73 (0.22) | 15.24 (0.26) | 16.03 (0.23) |
|  | FastCLIP-v3 | 18.37 (0.26) | 19.08 (0.16) | 19.21 (0.18) | 19.20 (0.16) |
| Medium | Improvement | 4.21 | 4.35 | 3.97 | 3.17 |
|  | OpenCLIP | 20.51 (0.14) | 21.08 (0.09) | 22.32 (0.23) | 22.77 (0.14) |
|  | FastCLIP-v3 | 23.76 (0.38) | 24.78 (0.28) | 24.79 (0.20) | 24.93 (0.16) |
| Large | Improvement | 3.25 | 3.70 | 2.47 | 2.16 |

Figure: (a) Datacomp, Medium
Refer to caption: x38.png

Training Time Comparison between OpenCLIP and FastCLIP-v3: We present the training time breakdown of OpenCLIP and FastCLIP-v3 in Table 15 and 16 for the medium-scale and large-scale settings, respectively. We can see that as the number of nodes scales up, the computation time of OpenCLIP and FastCLIP-v3 is always close to each other, while the gap in communication time becomes much larger, which is also depicted in subfigures (c) and (d). Even if we exclude the part of communication that overlaps with computation, the gap in pure communication still becomes larger with increasing number of nodes, and thus FastCLIP-v3 has a shorter running time on 4 and 8 nodes.

**Table 15: Comparison between OpenCLIP and FastCLIP-v3 in terms of training time in the medium-scale setting. The shaded results are from FastCLIP-v3, and the others are from OpenCLIP. Computation denotes the whole computation time. Communication denotes the whole communication time. Pure Comm. denotes the communication time that is not overlapped with computation. Overlap denotes the overlapped time between computation and communication.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 867.85 (11.04) | 880.19 (53.45) | 925.47 (27.77) | 1049.90 (32.44) |
| Total | 866.36 (5.89) | 879.91 (52.17) | 917.54 (25.46) | 1028.06 (32.26) |
|  | 770.57 (6.10) | 738.87 (21.58) | 726.07 (1.53) | 742.93 (15.91) |
| Computation | 771.80 (5.53) | 737.93 (21.73) | 725.40 (2.01) | 742.90 (15.90) |
|  | 222.01 (4.43) | 403.40 (130.80) | 548.07 (60.97) | 698.87 (26.24) |
| Communication | 223.34 (5.51) | 400.76 (125.78) | 536.15 (59.29) | 675.43 (25.97) |
|  | 27.18 (1.61) | 68.74 (25.45) | 127.39 (30.29) | 224.71 (16.05) |
| Pure Comm. | 25.50 (2.24) | 64.32 (22.47) | 116.21 (28.48) | 200.97 (15.58) |
|  | 194.84 (2.88) | 334.66 (105.36) | 420.68 (30.80) | 474.16 (10.23) |
| Overlap | 197.84 (3.65) | 336.44 (103.35) | 419.94 (30.83) | 474.46 (10.41) |
|  | 70.09 (8.17) | 72.58 (6.59) | 72.01 (2.73) | 82.26 (0.93) |
| Others | 69.06 (1.67) | 77.66 (8.14) | 75.93 (2.83) | 84.19 (0.86) |

**Table 16: Comparison between OpenCLIP and FastCLIP-v3 in terms of training time in the large-scale setting. The shaded results are from FastCLIP-v3, and the others are from OpenCLIP. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 1125.29 (14.14) | 1234.06 (151.37) | 1396.76 (47.86) | 1564.46 (47.92) |
| Total | 1128.75 (9.75) | 1234.82 (153.86) | 1394.91 (48.35) | 1542.32 (47.87) |
|  | 960.14 (12.00) | 910.77 (10.48) | 891.71 (6.09) | 896.54 (8.02) |
| Computation | 964.16 (9.10) | 910.94 (11.55) | 892.72 (4.72) | 897.59 (9.09) |
|  | 360.34 (15.55) | 655.30 (175.45) | 876.13 (71.52) | 1061.52 (55.08) |
| Communication | 363.38 (16.66) | 652.78 (173.41) | 870.01 (69.56) | 1035.03 (56.84) |
|  | 56.73 (4.09) | 192.89 (129.45) | 379.10 (58.13) | 525.78 (57.22) |
| Pure Comm. | 55.44 (2.23) | 190.56 (127.48) | 371.30 (55.62) | 498.95 (59.72) |
|  | 303.62 (14.70) | 462.41 (46.02) | 497.02 (13.45) | 535.74 (2.33) |
| Overlap | 307.94 (18.14) | 462.22 (45.93) | 498.71 (13.97) | 536.08 (2.99) |
|  | 108.42 (5.54) | 130.40 (12.26) | 125.95 (5.57) | 142.14 (2.08) |
| Others | 109.14 (2.67) | 133.33 (15.30) | 130.89 (4.34) | 145.78 (3.13) |

Training Time of OpenCLIP and FastCLIP in Different Network Environments: The results above (and in Section 6) are obtained from a cluster with InfiniBand interconnect. We conduct additional experiments on two different clusters with Slingshot interconnect. The results are presented below. It can be seen that our gradient reduction strategy has consistent improvement over the strategy used in OpenCLIP in different network environments.

Figure: (a) Total, Medium
Refer to caption: x41.png

The following tables present results used to plot the above figure.

**Table 17: OpenCLIP vs. FastCLIP-v3 (shaded) in the medium-scale setting on Cluster 1 with Slingshot interconnect. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 218.42 (14.87) | 352.99 (2.91) | 410.14 (0.94) | 462.18 (8.12) |
| Total | 221.46 (7.96) | 359.04 (12.21) | 412.67 (1.08) | 447.42 (4.18) |
|  | 157.03 (0.26) | 160.53 (0.09) | 160.11 (0.04) | 160.02 (0.09) |
| Computation | 158.99 (1.75) | 160.88 (0.23) | 160.34 (0.06) | 160.35 (0.08) |
|  | 23.58 (13.49) | 250.21 (2.74) | 313.26 (2.33) | 354.59 (2.33) |
| Communication | 29.88 (14.20) | 251.58 (12.11) | 312.32 (1.28) | 349.45 (4.46) |
|  | 14.28 (11.86) | 149.42 (2.71) | 210.57 (1.51) | 251.45 (2.11) |
| Pure Comm. | 12.13 (5.20) | 150.19 (12.06) | 208.20 (1.29) | 245.39 (4.49) |
|  | 9.31 (1.63) | 100.79 (0.03) | 102.69 (0.87) | 103.14 (0.25) |
| Overlap | 17.75 (9.04) | 101.39 (0.04) | 104.11 (0.09) | 104.06 (0.03) |
|  | 47.12 (2.77) | 43.04 (0.27) | 39.45 (0.69) | 50.72 (9.91) |
| Others | 50.35 (1.03) | 47.97 (0.52) | 44.13 (0.38) | 41.69 (0.40) |

**Table 18: OpenCLIP vs. FastCLIP-v3 (shaded) in the large-scale setting on Cluster 1 with Slingshot interconnect. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 301.54 (22.83) | 510.42 (6.59) | 587.59 (7.53) | 660.99 (23.63) |
| Total | 329.86 (40.84) | 511.80 (6.53) | 586.17 (8.97) | 637.16 (13.73) |
|  | 153.12 (2.47) | 155.06 (0.05) | 154.63 (0.08) | 154.45 (0.05) |
| Computation | 154.22 (3.44) | 155.53 (0.14) | 155.10 (0.05) | 155.19 (0.11) |
|  | 84.86 (23.74) | 389.90 (6.59) | 472.84 (6.84) | 545.75 (18.81) |
| Communication | 110.76 (36.62) | 389.36 (6.43) | 467.79 (9.38) | 520.98 (15.02) |
|  | 58.00 (22.62) | 291.70 (6.63) | 371.31 (7.25) | 443.20 (18.99) |
| Pure Comm. | 79.80 (35.59) | 288.68 (5.59) | 363.71 (8.58) | 416.43 (15.11) |
|  | 26.86 (12.35) | 98.20 (0.07) | 101.53 (0.57) | 102.55 (0.87) |
| Overlap | 30.96 (17.49) | 100.68 (1.06) | 104.08 (0.88) | 104.55 (0.10) |
|  | 90.42 (4.26) | 63.66 (1.09) | 61.66 (0.91) | 63.34 (4.74) |
| Others | 95.84 (7.48) | 67.59 (1.28) | 67.36 (0.49) | 65.54 (1.62) |

**Table 19: OpenCLIP vs. FastCLIP-v3 (shaded) in the xlarge-scale setting on Cluster 1 with Slingshot interconnect. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 511.28 (8.46) | 597.15 (3.50) | 643.54 (4.69) | 725.58 (35.32) |
| Total | 520.66 (6.96) | 597.52 (8.42) | 648.67 (6.48) | 717.43 (24.75) |
|  | 418.29 (0.59) | 442.58 (0.41) | 442.63 (0.19) | 441.86 (0.09) |
| Computation | 419.27 (1.48) | 442.86 (0.10) | 442.99 (0.28) | 442.86 (0.17) |
|  | 24.52 (9.71) | 380.79 (2.92) | 432.24 (4.58) | 514.46 (32.87) |
| Communication | 33.34 (12.27) | 378.48 (7.59) | 436.70 (6.90) | 492.55 (15.62) |
|  | 12.29 (7.00) | 79.79 (3.19) | 127.27 (4.15) | 207.18 (32.94) |
| Pure Comm. | 16.68 (4.62) | 75.38 (6.89) | 127.03 (6.40) | 182.89 (15.91) |
|  | 12.23 (2.73) | 301.00 (0.32) | 304.98 (0.65) | 307.28 (0.52) |
| Overlap | 16.66 (8.19) | 303.11 (0.94) | 309.67 (0.80) | 309.65 (0.69) |
|  | 80.70 (1.53) | 74.78 (0.87) | 73.65 (0.59) | 76.54 (2.76) |
| Others | 84.71 (1.27) | 79.29 (1.84) | 78.65 (0.52) | 91.68 (13.55) |

**Table 20: OpenCLIP vs. FastCLIP-v3 (shaded) in the medium-scale setting on Cluster 2 with Slingshot interconnect. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 218.62 (1.49) | 239.22 (0.18) | 273.94 (1.10) | 278.21 (2.74) |
| Total | 219.67 (4.87) | 239.04 (2.73) | 271.29 (1.17) | 274.94 (4.29) |
|  | 157.47 (1.03) | 160.47 (0.14) | 167.51 (0.89) | 164.75 (0.05) |
| Computation | 157.94 (1.08) | 160.85 (0.15) | 167.94 (1.33) | 164.89 (0.37) |
|  | 31.41 (6.16) | 105.83 (2.74) | 155.37 (1.14) | 165.85 (4.20) |
| Communication | 31.12 (7.51) | 98.51 (2.14) | 150.03 (1.52) | 160.95 (3.00) |
|  | 10.63 (2.02) | 33.37 (1.17) | 62.29 (1.24) | 69.99 (2.41) |
| Pure Comm. | 10.02 (2.23) | 30.41 (2.10) | 55.13 (2.08) | 62.52 (4.06) |
|  | 20.78 (5.31) | 72.46 (1.63) | 93.08 (0.12) | 95.86 (1.96) |
| Overlap | 21.10 (5.28) | 68.10 (0.22) | 94.91 (0.91) | 98.43 (1.17) |
|  | 50.52 (1.01) | 45.37 (0.88) | 44.14 (0.42) | 43.47 (0.88) |
| Others | 51.72 (2.28) | 47.78 (1.46) | 48.22 (0.60) | 47.53 (0.39) |

**Table 21: OpenCLIP vs. FastCLIP-v3 (shaded) in the large-scale setting on Cluster 2 with Slingshot interconnect. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 261.73 (5.81) | 293.85 (7.66) | 341.99 (6.88) | 387.59 (29.84) |
| Total | 260.15 (2.71) | 295.25 (5.15) | 350.30 (12.59) | 365.01 (31.42) |
|  | 158.96 (0.59) | 165.37 (1.34) | 174.27 (1.08) | 169.39 (0.47) |
| Computation | 158.86 (0.71) | 166.24 (0.48) | 173.65 (2.33) | 168.31 (0.63) |
|  | 42.37 (6.16) | 149.25 (8.76) | 205.88 (3.59) | 250.92 (31.40) |
| Communication | 38.83 (2.64) | 148.16 (3.75) | 208.68 (9.40) | 227.15 (31.55) |
|  | 17.33 (3.89) | 58.19 (5.73) | 98.24 (5.08) | 146.62 (32.25) |
| Pure Comm. | 16.45 (0.70) | 54.01 (3.58) | 98.83 (11.70) | 120.91 (30.43) |
|  | 25.04 (3.56) | 91.05 (3.12) | 107.63 (1.83) | 104.30 (1.00) |
| Overlap | 22.39 (2.91) | 94.14 (0.28) | 109.84 (2.31) | 106.24 (1.56) |
|  | 85.44 (2.76) | 70.29 (0.78) | 69.48 (2.97) | 71.58 (3.20) |
| Others | 84.84 (2.27) | 74.99 (2.13) | 77.82 (3.60) | 75.79 (0.83) |

**Table 22: OpenCLIP vs. FastCLIP-v3 (shaded) in the xlarge-scale setting on Cluster 2 with Slingshot interconnect. The meaning of each category is the same as Table 15.**
| Category | 1 Node | 2 Nodes | 4 Nodes | 8 Nodes |
| --- | --- | --- | --- | --- |
|  | 496.14 (0.84) | 516.82 (5.65) | 581.00 (3.16) | 636.00 (16.93) |
| Total | 502.32 (5.29) | 515.99 (0.56) | 582.50 (2.89) | 626.40 (7.16) |
|  | 415.30 (0.10) | 422.40 (0.25) | 433.71 (1.03) | 433.66 (0.41) |
| Computation | 415.34 (0.13) | 422.89 (0.21) | 432.92 (0.22) | 434.92 (0.48) |
|  | 26.49 (0.97) | 145.77 (7.14) | 287.66 (7.36) | 369.86 (12.53) |
| Communication | 25.13 (2.47) | 144.39 (2.93) | 277.56 (1.98) | 362.24 (11.25) |
|  | 9.31 (0.46) | 23.58 (4.66) | 70.29 (1.96) | 123.79 (15.56) |
| Pure Comm. | 8.65 (1.86) | 17.89 (0.62) | 67.45 (3.26) | 111.46 (6.13) |
|  | 17.18 (0.61) | 122.19 (2.57) | 217.36 (8.75) | 246.07 (3.60) |
| Overlap | 16.48 (0.80) | 126.50 (2.31) | 210.11 (3.54) | 250.77 (5.46) |
|  | 71.53 (0.55) | 70.84 (0.88) | 76.99 (2.15) | 78.56 (1.92) |
| Others | 78.33 (3.30) | 75.20 (0.55) | 82.14 (2.26) | 80.01 (0.87) |

## Peer Reviews

confidence: 3
contribution: 2
initial_rating: 3
presentation: 2
questions: See the weaknesses.
soundness: 2
strengths: 1. This paper studies an important problem in CLIP training, "how to efficiently and effectively training CLIP models with limited resources". 

2. This paper designs an efficient distributed training framework based on advanced compositional optimization techniques. It conducts ablation studies on the several key components during training, such as the update rule of learning rate, temperature parameter and model papers, providing valuable insights for future work in optimizing large-scale model training.

3. Experimental results across various compute and data scales demonstrate that FastCLIP significantly outperforms existing methods, such as OpenCLIP, enhancing training efficiency on setups with up to 32 GPUs.
summary: This paper introduces FastCLIP, a distributed training framework designed to optimize CLIP model training using compositional optimization techniques, removing the dependency on large batch sizes for effective model performance. The framework incorporates an efficient gradient reduction strategy to minimize communication overhead and conducts comprehensive ablation studies on various components, including learning rate schedules (constant vs. cosine), temperature parameter update rules, and different optimizers (AdamW, LAMB, Lion, and SGDM).
weaknesses: 1. This paper is not designed for general CLIP training but is instead built on the assumptions and techniques from prior work[1]. As a result, its applicability may be limited to scenarios that align with these specific assumptions, restricting its generalizability to broader CLIP training tasks.

2. The paper primarily builds on existing techniques, such as compositional optimization and gradient reduction strategies, without introducing fundamentally new concepts. While it refines and optimizes these methods for CLIP training, the core ideas themselves are not particularly novel.

3. The paper's writing lacks clarity, making it difficult to follow at times. The structure of the paper would benefit from significant revision to improve its readability and logical consistency.

4. The experiment compares FastCLIP with OpenCLIP, which is designed for large-scale clusters and requires large batch sizes. In contrast, FastCLIP is tested on a relatively smaller cluster (up to 32 GPUs), violating the original conditions under which OpenCLIP was evaluated. Additionally, the results in experiments 4 and 5 are inconsistent, with different methods showing unstable performance. This lack of stability weakens the conclusions and limits the insights that can be drawn for future work.

[1] Yuan Z, Wu Y, Qiu Z H, et al. Provable stochastic optimization for global contrastive learning: Small batch does not harm performance. ICML 2022.

---

confidence: 3
contribution: 2
initial_rating: 5
presentation: 3
questions: How does the performance of FastCLIP vary across different types of GPUs or compute environments?

Could other advanced optimization techniques (e.g., adaptive optimizers beyond AdamW) further enhance the framework's efficiency?

Would additional experiments on extremely large datasets (>1 billion samples) align with the current findings for smaller datasets?
soundness: 3
strengths: - Efficient resource utilization for settings with limited computational resources, making CLIP training more accessible.

- Systematic Optimizations: The paper provides a structured approach to optimizing multiple aspects of CLIP training, including LR schedules, temperature parameter updates, and gradient communication strategies.

- Experimental Validation: Comprehensive testing on various datasets and compute scales effectively shows the benefits of FastCLIP compared to OpenCLIP.
summary: This paper introduces a distributed framework designed to improve the efficiency of CLIP by optimizing resource use and reducing dependency on large batch sizes and numerous GPUs. They use several optimization techniques, including a gradient reduction strategy and a flexible LR schedule, to facilitate efficient CLIP training with limited resources. The study compares FastCLIP to OpenCLIP and demonstrates consistent performance improvements on different scales of data and compute resources.
weaknesses: - Limited Novelty in Optimization Techniques: The optimization techniques applied, such as learning rate decay and gradient reduction, are well-established and may not contribute novel methodological insights.

- Resource Comparison Limitations: The paper does not conduct an extensive ablation study for larger datasets due to resource constraints, which may limit the generalizability of results on extremely large data scales.

- Assumption of Availability of Multiple GPUs: Although designed for resource-limited environments, FastCLIP still requires access to multiple GPUs, which may limit applicability for highly resource-constrained users.

---

confidence: 4
contribution: 2
initial_rating: 3
presentation: 3
questions: 1. See weaknesses.
2. Is there any other significant difference between OpenCLIP and FastCLIP? Seems like they are also using data-parallel.
3. What do the number differences represent in Table 3, 4, 5, and Figure 2? The current comparison is not very straightforward.
4. Should the training accuracy converge?
soundness: 2
strengths: 1. This paper compared CLIP training performances with different temperature parameter updating methods and different optimizers.
2. The appendix provides detailed experiment results and parameter settings.
3. An introduced cosine schedule could provide better training accuracy.
summary: This paper introduced FastCLIP, which uses data-parallel for CLIP training. It claimed to (1) present an efficient gradient reduction strategy to reduce communication overhead, (2) compare inner LR schedule between constant and cosine schedule, (3) compare temperature param update methods and (4) compare optimizers.
weaknesses: 1. Figure 3 is not so clear about the efficiency improvement. The difference between OpenCLIP and FastCLIP is not significant.
2. Figure 4 (a) does not show convergence on the accuracy curve which could be problematic.
3. Figure 4 (b) (c) do not show a significant difference in scalability.
4. The writing style needs improvement, and some part of this paper needs to be summarized. Also, the experiment part needs more details, the authors use many numbers in Table 3, 4, 5 but there is no information on what do they represent, accuracy, or some other metrics.
5. Lack of novelty. This paper compared multiple combinations of existing CLIP training techniques and proposed using data parallelization to scale up the training process. From this summary, existing techniques do not contribute much to novelty except cosine LR schedule, also, data parallelism mentioned in this paper does not show promising results compared to OpenCLIP.

Meta-review: Thank you for your submission to ICLR. This paper introduces FastCLIP, a set of techniques and implementation for efficient training of CLIP in settings with limited resources. To carry this out, the authors developed a gradient reduction strategy to reduce communication requirements, and then investigated aspects of the optimization procedure (e.g., inner learning rate schedule, update rule of the temperature/model parameters).

The reviewers agree with the motivation for this paper, and all appreciate the thorough set of empirical results and ablations. However, the reviewers also had a number concerns, including:
- Limited novelty of the proposed techniques.
- In some cases, there was not a great deal of demonstrated improvement of the proposed method over existing baselines.
- Issues with clarity in the writing and in certain figures.

I encourage you to carefully consider and incorporate these comments from reviewers upon resubmission.

Decision: Reject