SlowGuess/NeurIPS_2023_OCR huggingface dataset:
In summary, during the first task, clients train the model using only the  $\mathcal{L}_{CE}$  part of (9) and send their updates to the server where the global model gets updated (FedAvg) for  $R$  rounds. At the end of
training task  $t = 1$ , the server trains the generative model by optimizing (5), using the latest global model. Finally, the server freezes and saves  $\mathcal{G}$  and the global model  $(\mathcal{F}_{t-1})$ . This procedure repeats for all future tasks, with the only difference being that for  $t > 1$ , the server needs to send the current global model  $(\mathcal{F}_t)$ , precious task's final model  $(\mathcal{F}_{t-1})$  and  $\mathcal{G}$  to clients. Since  $\mathcal{F}_{t-1}$  and  $\mathcal{G}$  are fixed during training  $\mathcal{F}_t$ , the server can send them to each client once per task to reduce the communication cost. To further decrease this overhead, we can employ communication-efficient methods in federated learning, such as [5], that can highly compress the model with minor performance degradation, which we leave for future work. Algorithm 1 in the Appendix A shows different steps of MFCL.
4 SuperImageNet
In centralized Class-IL, the tasks are disjoint, and each task reveals a new set of classes; therefore, the total number of classes strongly limits the number of tasks. Moreover, we must ensure that each task has sufficient training data for learning. Thus, the number of examples per class is essential in creating CL datasets. However, the dataset needs to be split along the task dimension and clients in a Federated Class-IL setup. For instance, CIFAR-100, a popular dataset for benchmarking FL algorithms, consists of 100 classes, each with 500 examples, which must be partitioned into  $T$  tasks, and each task's data is split among  $N$  clients. In other words, for a single task, a client has access to only  $\frac{1}{T \times N}$  of that dataset; in a common scenario where  $N = 100$  and  $T = 10$ , we can assign only 50 samples to each client (about 5 example per class in i.i.d data distribution), which is hardly enough.
To resolve this problem, prior works have used a small number of clients [45, 24, 52], combined multiple datasets [58], employed a surrogate dataset [37] or allowed data sharing among the clients [15]. However, these solutions may not be possible, applicable, or may violate the FL's assumptions. This demonstrates the importance of introducing new benchmark datasets for federated continual settings.
Figure 4: Building SuperImageNet by regrouping ImageNet dataset. Labels in Blue are the original labels, and in Red are the labels in SuperImageNet.
We introduce SuperImageNet, a dataset created by superclassing the ImageNet [14] dataset, thus
greatly increasing the number of available samples for each class. There are 3 versions of the dataset, each offering a different trade-off between the number of classes (for Class-IL) and the number of examples per class (for FL) as shown in Table 4. For example, SuperImageNet-M has  $10x$  more samples per class compared to CIFAR-100, which allows for an order of magnitude increase in the number of fed
Dataset	# examples/class	# classes
SuperImageNet-S	2500	100
SuperImageNet-M	5000	75
SuperImageNet-L	7500	50
Table 2: Versions of SuperImageNet
erated clients in while maintaining the same amount of training data per client. As shown in Figure 4, we have merged classes of similar concepts to increase the sample size per class.
Setting. We demonstrate the efficacy of our method on three challenging datasets: CIFAR-100 [30], TinyImageNet [43] and SuperImageNet-L  $^1$ . For all datasets, we use the baseline ResNet18 [23] as the global model and ConvNet architecture for  $\mathcal{G}$ , which we explain in detail in the Appendix C.
The image size of the CIFAR-100, TinyImageNet, and SuperImageNet datasets is  $32 \times 32$ ,  $64 \times 64$  and  $224 \times 224$ , respectively
Table 3 summarizes the setting for each dataset. For each dataset, there are 10 non-overlapping tasks  $(T = 10)$ , and we use Latent Dirichlet Allocation (LDA) [46] with  $\alpha = 1$  to distribute the data of each task among the clients. Clients train the local model using an SGD optimizer, and all the results were reported after averaging over 3 different random initializations (seeds). We refer to Appendix F for other hyperparameters.
Dataset	#Client	#Client per round	#classes per task
CIFAR-100	50	5	10
TinyImageNet	100	10	20
SuperImageNet-L	300	30	5
Table 3: Training parameters of each dataset.
Metric. We use three metrics – Average Accuracy, Average Forgetting, and Wallclock time.
Average Accuracy  $(\tilde{\mathcal{A}})$ : Let us define Accuracy  $(\mathcal{A}^t)$  as the accuracy of the model at the end of task  $t$ , over all the classes observed so far. Then,  $\tilde{\mathcal{A}}$  is average of all  $\mathcal{A}^t$  for all the  $T$  available tasks.
Average Forgetting  $(\tilde{f})$ : Forgetting  $(f^t)$  of task  $t$  is defined as the difference between the highest accuracy of the model on task  $t$  and its performance at the end of the training. Therefore, we can evaluate the average forgetting by averaging all the  $f^t$  for task 1 to  $T - 1$  at the end of task  $T$ .
Wallclock time. This is the time the server or clients take to perform one FL round in seconds. The time is measured rounds on our local GPU NVIDIA-A100 and averaged between different clients.
Baseline. We compare our method with FedAvg [40], FedProx [33], FedProx $^+$ , FedCIL [45], FedLwF-2T [52] and Oracle. FedAvg and FedProx are the two most common aggregation methods; specifically, FedProx is designed for non-i.i.d data distributions and tries to minimize the distance of the client's update from the global model. Inspired by FedProx, we also explore adding a loss term to minimize the change of the current global model from one from the previous task, which we name FedProx $^+$ . FedCIL is a GAN-based method where clients train the discriminator and generator locally to generate synthetic samples from the old tasks. FedLwF-2T is another method designed for federated continual learning. In this method, clients have two additional knowledge distillation loss terms: their local model trained on the previous task and the current global model. Finally, Oracle is an upper bound on the performance: during the training of the  $i_{th}$  task, clients have access to all of their training data from  $t = 1$  to  $t = i$ .
Figure 5 shows the accuracy of the model on all the observed classes so far. In all three datasets, MFCL consistently outperforms the baselines by a large margin (up to  $25\%$  absolute improvement in test accuracy). In the CIFAR-100 dataset, the only baseline that can also correctly classify some examples from past data is FedCIL. Both MFCL and FedCIL benefit from a generative model (roughly the same size) to remember the past. Here, a similar generative model to the one in the [45] for the CIFAR-10 dataset is used. Since, in FedCIL, the clients train the generative and global models simultaneously, they require more training iteration. We repeat the same process and adapt similar architectures for the other two datasets. But, given that GANs are not straightforward to fine-tune, this method does not perform well or converge. We explain more in the Appendix H.
We have further compared the performance and overhead of the methods in Table 4. The first two metrics, Average Accuracy and Average Forgetting reveal how much the model is learning new tasks while preserving its performance on the old task. As expected, FedAvg and FedProx have the highest forgetting values because they are not designed for such a scenario. Also, high forgetting for FedLwF-2T indicates that including teachers in the absence of old data cannot be effective. Notably,  $\mathrm{FedProx}^{+}$  has a lower forgetting value, mainly due to the fact that it also has lower performance for each task. Finally, FedCIL and MFCL have experienced the least forgetting with knowledge transferred from the old task to the new ones. Particularly, MFCL has the smallest forgetting, which means it is the most successful in preserving the learned knowledge.
We also compare the methods based on their computational costs. It is notable that some methods change after learning the first task; therefore, we distinguish between the cost of the first task and the other ones. As depicted, for  $T > 1$ , MFCL slightly increases the training time caused by employing the generative model. But, as a trade-off, it can significantly improve performance and forgetting.
2This result might improve by allocating relatively more resources to the clients.
Figure 5: Test Accuracy vs. # observed tasks for (a) CIFAR-100, (b) TinyImageNet, (C) SuperImageNet-L datasets. After each task, the model is evaluated on all the seen tasks so far.
The server cost in MFCL is similar to FedAvg except at the end of each task, where it needs to train the generative model. This extra computation cost should not be a bottleneck because it occurs once per task, and servers usually have access to better computing power compared to clients.
Table 4: Performance of the different baselines in terms of Average Accuracy. Average Forgetting and Wallclock time for CIFAR-100 dataset.
Average Accuracy\(\hat{\mathcal{A}}\)(%)	Average forgetting\(\hat{f} \)(%)	Training time (s)\(T=1\)	Training time (s)\(T>1\)	Server Runtime (s)
FedAvg	22.27 ± 0.22	78.77 ± 0.83	≈ 1.2	≈ 1.2	≈ 1.8
FedProx	22.00 ± 0.31	78.17 ± 0.33	≈ 1.98	≈ 1.98	≈ 1.8
FedCIL	26.8 ± 0.44	38.19 ± 0.31	≈ 17.8	≈ 24.5	≈ 2.5 for T = 1,≈ 4.55 for T > 1
FedLwF-2T	22.17 ± 0.13	75.08 ± 0.72	≈ 1.2	≈ 3.4	≈ 1.8
MFCL (Ours)	44.98 ± 0.12	28.3 ± 0.78	≈ 1.2	≈ 3.7	≈ 330 (once per task),≈ 1.8 O.W.
Oracle	67.12 ± 0.4	--	≈ 1.2	≈ 1.2 × T	≈ 1.8
5.2 Ablation Studies
Here, we demonstrate the importance of each component in our proposed algorithm, both on the server and client side, by ablating their effects one by one. Table 5 shows our results, where each row removes a single loss component, and each column represents the corresponding test accuracy  $(\mathcal{A}^t)$ , average accuracy  $(\tilde{\mathcal{A}})$ , average forgetting  $(\tilde{f})$  and their difference from our proposed method. The first three rows are the losses for training the generative model. Our experiments show that Batch Statistics Loss  $(\mathcal{L}_{BN})$  and Diversity loss  $(\mathcal{L}_{div})$  play an essential role in the final performance. The next three rows reflect the importance of client-side training. In particular, the fourth row  $(Ours - w / o\mathcal{L}_{CE}^{t})$  represents the case where clients use all the linear heads of the model for cross-entropy instead of splitting the heads and using the part related to the current task only. The following two rows show the impact of removing  $\mathcal{L}_{FT}^{t}$  and  $\mathcal{L}_{KD}^{t}$  from the client loss. In all three cases, the loss considerably drops, demonstrating the importance of all components. Finally, FedAvg + Gen shows the performance of the case where the server trains the generative model, and clients use its synthetic data the same way as the real ones without further modifications. In the Appendix G, we perform additional ablations on hyperparameters, such as weights of each loss term, generator model size, and noise dimension.
Table 5: Ablation study for MFCL on CIFAR-100
Method	A1	A2	A3	A4	A5	A6	A7	A8	A9	A10	A	Δ	F	Δ
Ours-w/o LBN	70.00	47.02	43.93	38.98	35.98	34.14	32.60	30.17	27.93	24.36	38.51	-6.47	45.95	+17.65
Ours-w/o Lpr	70.47	52.33	49.90	44.87	42.09	39.56	38.18	35.21	33.74	32.40	43.87	-1.11	29.47	+1.17
Ours-w/o Ldiv	69.87	53.48	47.60	39.60	35.43	32.95	30.81	27.15	25.14	22.34	38.44	-6.54	44.80	+16.5
Ours-w/o LCE	70.10	40.10	33.40	26.70	21.33	19.24	17.96	14.00	13.69	11.28	26.78	-18.20	72.24	+43.94
Ours-w/o LFT	70.37	46.17	42.16	37.57	33.91	32.29	30.94	28.25	27.00	24.64	37.33	-7.65	42.85	+14.55
Ours-w/o LKD	70.10	45.92	38.60	31.01	26.45	24.07	21.32	18.02	16.85	16.29	30.86	-14.12	53.64	+25.34
FedAvg + Gen	70.57	40.07	30.91	23.75	20.38	17.56	16.02	12.90	13.18	11.57	25.69	-19.29	60.46	+32.16
Ours	71.50	55.00	50.73	45.73	42.38	40.62	38.97	36.18	35.47	33.25	44.98	-	28.3	-
Privacy of MFCL. Federated Learning, specifically FedAvg, is vulnerable to different attacks, such as data poisoning, model poisoning, backdoor attacks, and gradient inversion attacks [27, 36, 18, 20, 11, 33]. We believe, MFCL generally does not introduce any additional privacy issues and still it is prone to the same set of attacks as FedAvg. MFCL trains the generative model based on the weights of the global model, which is already available to all clients in the case of FedAvg. On the contrary, in some prior work in federated continual learning, the clients need to share a locally trained generative model or perturbed private data, potentially causing more privacy problems.
Furthermore, for FedAvg, various solutions and defenses, such as differential privacy or secure aggregation [55, 8], are proposed to mitigate the effect of such privacy attacks. One can employ these solutions in the case of MFCL as well. Notably, in MFCL, the server does not require access to the individual client's updates and uses the aggregated model for training. Therefore, training a generative model is still viable after incorporating these mechanisms.
In MFCL, the server trains the generator using only client updates. Figure 6 presents random samples of real and synthetic images from the CIFAR-100 dataset. Images of the same column correspond to real and synthetic samples from the same class. Synthetic samples do not resemble any specific training examples of the clients and thus preserve privacy. However, they consist of some common knowledge about the class and effectively represent the whole class. Therefore, they can significantly reduce catastrophic forgetting.
Class 1
Figure 6: Real vs synthetic data generated by the generative model for CIFAR-100 dataset.
Limitations. In our method, clients need the generative model, the final global model of the last task, and the current global model, which adds overheads such as communication between the server and clients and storage. However, there are fundamental differences between storing the generative model and actual data. First, the memory cost is independent of the task size: as the number of tasks increases, clients either have to delete some of the existing examples of the memory to be able to add new ones or need to increase the memory size. In contrast, the generative model size is constant. Finally, clients can delete the generative model while not participating in the FL process and retrieve it later if they join. On the other hand, deleting data samples from memory results in a permanent loss of information. We have delved into this in Appendix D.
This work presents a federated Class-IL framework while addressing resource limitations and privacy challenges. We exploit generative models trained by the server in a data-free fashion, obviating the need for expensive on-device memory on clients. Our experiments demonstrate that our method can effectively alleviate catastrophic forgetting and outperform the existing state-of-the-art solutions.
This material is based upon work supported by ONR grant N00014-23-1-2191, ARO grant W911NF22-1-0165, Defense Advanced Research Projects Agency (DARPA) under Contract No. FASTNICS HR001120C0088 and HR001120C0160, and gifts from Intel and Qualcomm. The views, opinions, and/or findings expressed are those of the author(s) and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.
[59] Friedemann Zenke, Ben Poole, and Surya Ganguli. Continual learning through synaptic intelligence. In International Conference on Machine Learning, pages 3987-3995. PMLR, 2017.
[60] Zhuangdi Zhu, Junyuan Hong, and Jiayu Zhou. Data-free knowledge distillation for heterogeneous federated learning. In International Conference on Machine Learning, pages 12878-12889. PMLR, 2021.
A MFCL Algorithm
Algorithm 1 summarizes our method. Here, for every task, clients train the local model using the shared generative model. At the end of each task, the server updates the generative model using data-free methods.
Algorithm 1 MFCL
1:  $N$ : #Clients,  $[\mathcal{C}_N]$ : Client Set,  $K$ : #Clients per Round,  $u_i$ : client i Update,  $E$ : Local Epoch  
2:  $R$ : FL Rounds per Task,  $T$ : #Tasks,  $t$ : current task,  $|\mathcal{V}|^t$ : Task  $t$  Size,  $q$ : #Discovered Classes  
3:  $\mathcal{F}_t$ : Global Model for task t,  $\mathcal{G}_t$ : Generative Model,  $E_{\mathcal{G}}$ : Generator Training Epoch  
4:  $q \gets 0$   
5:  $\mathcal{G}, \mathcal{F}_1 \gets$  initialize()  
6: for  $t = 1$  to  $T$  do  
7:  $q \gets q + |\mathcal{Y}^t|$   
8:  $\mathcal{F}_t \gets$  updateArchitecture( $\mathcal{F}_t, q$ ) # Add new observed classes in the classification layer.  
9: for  $r = 1$  to  $R$  do  
10:  $C_K \gets$  RandomSelect([ $\mathcal{C}_N$ ],  $K$ )  
11: for  $c \in C_K$  in parallel do  
12:  $u_c \gets$  localUpdate( $\mathcal{F}_t, \mathcal{G}, \mathcal{F}_{t-1}, E$ ) # For  $t = 1$  we do not need  $\mathcal{F}_0$  and  $\mathcal{G}$ .  
13: end for  
14:  $\mathcal{F}_t \gets$  globalAggregation( $\mathcal{F}_t, [u_c]$ )  
15: end for  
16:  $\mathcal{F}_t \gets$  freezeModel( $\mathcal{F}_t$ ) # Fix Global model.  
17:  $\mathcal{G} \gets$  trainDFGenerator( $\mathcal{F}_t, E_{\mathcal{G}}, q$ ) # Train the generative model.  
18:  $\mathcal{G} \gets$  freezeModel( $\mathcal{G}$ ) # Fix generator weights.  
19: end for
B Code for Reproduction
The codebase for this work and regrouping the ImageNet dataset is available at https://github.com/SaraBabakN/MFCL-NeurIPS23.
C Details of the Generative Model
Architectures. In Table 6, we show the generative model architectures used for CIFAR-100, TinyImageNet, and SuperImageNet datasets. In all experiments, the global model has ResNet18 architecture. For the CIFAR-100 and TinyImageNet datasets, we change the first CONV layer kernel size to  $3 \times 3$  from  $7 \times 7$ . In this table, CONV layers are reported as CONV  $K \times K(C_{in}, C_{out})$ , where  $K$ ,  $C_{in}$  and  $C_{out}$  are the size of the kernel, input channel and output channel of the layer, respectively.
Weight Initialization. The generative model is randomly initialized for the first task and trained from scratch. For all the future tasks  $(t > 1)$ , the server uses the previous generative model (t - 1) as the initialization.
Synthetic Samples Generation. To generate the synthetic data, clients sample i.i.d noise, which later would determine the classes via the argmax function applied to the first q elements (considering q is the total number of seen classes). Given the noise is sampled i.i.d, the probability of generating samples from class  $i$  equals  $\frac{1}{q}$ . Although this might not lead to the same number of synthetic samples from each class in every batch, the generated class distribution is uniform over all classes. Thus, in expectation, we have class balance in generated samples.
Catastrophic Forgetting in the Generative Model. The effectiveness of the  $\mathcal{G}$  is closely linked to the performance of the global model. If the global model forgets old classes after completing a task, the quality of corresponding synthetic data will decline. Hence, it is crucial to select a reliable generative model and a robust global model. A good generative model can assist the global model in preventing forgetting when learning new tasks. This model can then serve as a teacher for the next round of the  $\mathcal{G}$  model.
Global Aggregation Method. In this work, we have employed FedAvg to aggregate the client updates. Since the generator is always trained after the aggregation, its training is not impacted by changing the aggregation method. However, the generative model uses the aggregated model as its discriminator, and it is directly affected by the quality of the final global model. Therefore, any aggregation mechanism that improves the global model's performance would also help the generative model and vice versa.
Table 6: Generative model Architecture
CIFAR-100	TinyImageNet	SuperImageNet
FC(200,128 × 8 × 8)	FC(400,128 × 8 × 8)	FC(200,64 × 7 × 7)
reshape(-,128,8,8)	reshape(-,128,8,8)	reshape(-,64,7,7)
BatchNorm(128)	BatchNorm(128)	BatchNorm(64)
Interpolate(2)	Interpolate(2)	Interpolate(2)
CONV3 × 3(128,128)	CONV3 × 3(128,128)	CONV3 × 3(64,64)
BatchNorm(128)	BatchNorm(128)	BatchNorm(64)
LeakyReLU	LeakyReLU	LeakyReLU
Interpolate(2)	Interpolate(2)	Interpolate(2)
CONV3 × 3(128,64)	CONV3 × 3(128,128)	CONV3 × 3(64,64)
BatchNorm(64)	BatchNorm(128)	BatchNorm(64)
LeakyReLU	LeakyReLU	LeakyReLU
CONV3 × 3(64,3)	Interpolate(2)	Interpolate(2)
Tanh	CONV3 × 3(128,64)	CONV3 × 3(64,64)
BatchNorm(3)	BatchNorm(3)	BatchNorm(64)
LeakyReLU	LeakyReLU
CONV3 × 3(64,3)	Interpolate(2)
Tanh	CONV3 × 3(64,64)
BatchNorm(3)	BatchNorm(64)
LeakyReLU
Interpolate(2)
CONV3 × 3(64,64)
BatchNorm(64)
LeakyReLU
CONV3 × 3(64,3)
Tanh
BatchNorm(3)
D Overheads of generative model
Client-side. Using  $\mathcal{G}$  on the client side would increase the computational costs compared to vanilla FedAvg. However, existing methods in CL often need to impose additional costs such as memory, computing, or both to mitigate catastrophic forgetting. Nevertheless, there are ways to reduce costs for MFCL. For example, clients can perform inference once, generate and store synthetic images only for training, and then delete them all. They can further reduce costs by requesting that the server generate synthetic images and send them the data instead of  $\mathcal{G}$ . Here, we raise two crucial points about the synthesized data. Firstly, there is an intrinsic distinction between storing synthetic (or  $\mathcal{G}$ ) and actual data; the former is solely required during training, and clients can delete them right after the training. Conversely, the data in episodic memory should always be saved on the client's side because once deleted, it becomes unavailable. Secondly, synthetic data is shared knowledge that can assist anyone with unbalanced data or no memory in enhancing their model's performance. In contrast, episodic memory can only be used by one client.
Server-side. The server needs to train the  $\mathcal{G}$  once per task. It is commonly assumed that the server has access to more powerful computing power and can compute more information in a faster time compared to clients. This training step does not have overhead on the client side and might slow down the whole process. However, tasks do not change rapidly in real life, giving the server ample time to train the generative model before any trends or client data shifts occur.
Communication Cost. Transmitting the generative model can be a potential overhead for MFCL, as it is a cost that clients must bear once per task to prevent or reduce catastrophic forgetting. However, several possible methods, such as compression, can significantly reduce this cost while maintaining excellent performance. This could be an interesting direction for future research.
E More on the Privacy of MFCL
MFCL with Differential Privacy. We want to highlight that the generator can only be as good as the discriminator in data-free generative model training. If the global model can learn the decision boundaries and individual classes with a DP guarantee, the generator can learn this knowledge and present it through the synthetic example. Otherwise, if the global model fails to learn the current tasks, there is not much knowledge to preserve for the future. With the DP guarantee, the main challenge is training a reasonable global model; improving this performance can also help the generative model.
MFCL with Secure Aggregation. If the clients do not trust the server with their updates, a potential solution is Secure Aggregation. In a nutshell, secure aggregation is a defense mechanism that ensures update privacy, especially when the server is potentially malicious. More importantly, since MFCL also does not require individual updates, it is compatible with secure aggregation and can be employed to align with Secure Aggregation.