FedFed: Feature Distillation against Data Heterogeneity in Federated Learning

Federated learning (FL) typically faces data heterogeneity, i.e., distribution shifting among clients. Sharing clients' information has shown great potentiality in mitigating data heterogeneity, yet incurs a dilemma in preserving privacy and promoting model performance. To alleviate the dilemma, we raise a fundamental question: \textit{Is it possible to share partial features in the data to tackle data heterogeneity?} In this work, we give an affirmative answer to this question by proposing a novel approach called {\textbf{Fed}erated \textbf{Fe}ature \textbf{d}istillation} (FedFed). Specifically, FedFed partitions data into performance-sensitive features (i.e., greatly contributing to model performance) and performance-robust features (i.e., limitedly contributing to model performance). The performance-sensitive features are globally shared to mitigate data heterogeneity, while the performance-robust features are kept locally. FedFed enables clients to train models over local and shared data. Comprehensive experiments demonstrate the efficacy of FedFed in promoting model performance.

Paper

Similar papers

Peer review

Reviewer ezSw5/10 · confidence 4/52023-06-20

Summary

This paper proposes a novel approach called Federated Feature Distillation (FedFed) to mitigate the data heterogeneity problem while preserving privacy. In particular, FedFed partitions data into performance-sensitive features and performance-robust features based on the information bottleneck method. Only performance-sensitive features are shared among clients as they contain minimal private information and significantly contribute to performance. Moreover, incorporating the differential privacy (DP) mechanism can provide an additional layer of privacy protection. In summary, this work is interesting, and the authors provide some theoretical analyses to support their claims.

Strengths

This study mitigates the issue of data heterogeneity in Federated Learning (FL) by utilizing a promising approach to information-sharing. Empirical evidence shows that the proposed method is effective in enhancing model performance.

Weaknesses

The reviewer believes the evaluation of the privacy leakage is insufficient. The details are as follows: 1. In Section 4.4, the authors conducted a model inversion attack to infer private data using shared features. However, quantitative measurement is missing in this evaluation. Previous studies [1, 2] have utilized metrics such as peak signal-to-noise ratio (PSNR) and Frechet inception distance (FID) to assess the quality of reconstructed data. We recommend that the authors include some quantitative results to strengthen the empirical evidence. 2. Federated learning is known to leak private information when sharing model parameters [3,4]. The FedFed method, which shares both model parameters and features, creates an opportunity for attackers to exploit these two types of information for privacy attacks. However, the experiment showed that the attacks only targeted the privacy information contained in the features, which is not a comprehensive representation of potential privacy leaks. 3. Tables 1, 2, 3, and 4 demonstrate that the FedFed method achieves a higher Top-1 accuracy than FedAvg. However, it's worth considering whether this increased accuracy comes at the cost of higher privacy leakage. [1] The Secret Revealer: Generative Model-Inversion Attacks Against Deep Neural Networks. https://openaccess.thecvf.com/content_CVPR_2020/html/Zhang_The_Secret_Revealer_Generative_Model-Inversion_Attacks_Against_Deep_Neural_Networks_CVPR_2020_paper.html [2] Knowledge-Enriched Distributional Model Inversion Attacks. https://openaccess.thecvf.com/content/ICCV2021/html/Chen_Knowledge-Enriched_Distributional_Model_Inversion_Attacks_ICCV_2021_paper.html [3] Comprehensive Privacy Analysis of Deep Learning: Passive and Active White-box Inference Attacks against Centralized and Federated Learning. https://ieeexplore.ieee.org/abstract/document/8835245?casa_token=1iwvBNyN5q4AAAAA:BdxQzounj3eoNv0HIcdMoW7nCaM6xWJFPwZQIosqhvpiXWNaJd-q0MeW_xmiZJkZGVmZXDRE [4] Beyond Inferring Class Representatives: User-Level Privacy Leakage From Federated Learning. https://ieeexplore.ieee.org/abstract/document/8737416?casa_token=zyEVcT_x3oQAAAAA:FfpfqLHOsQJ33Br2OqnYE6fRI3EIgdNPlCSUOC74Yu6qhFjcgJvqHwFLAsPaShPaigK3sjz1

Questions

1. How to conduct the model inversion attack? The reviewer has checked both the experiment section and Appendix E, but some details appear to be missing. 2. Table 14 in the Appendix summarizes the currently available information-sharing methods. According to the authors, the FedFed method provides hierarchical protections to preserve information privacy while overcoming the privacy-performance dilemma. Does this mean that the FedFed method achieves better performance and privacy protection than all the baselines in Table 14? Take Fedproto as an example. This method only exchanges prototypes (i.e., the mean of features) instead of model parameters, while FedFed shares both the model parameters and features. The authors correctly pointed out that FedProto lacks protection on the shared information, but the shared model parameters in FedFed also lack privacy guarantees. Further discussion and empirical results are required to demonstrate the effectiveness of the FedFed method in comparison to previous works.

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

2 fair

Presentation

3 good

Contribution

2 fair

Limitations

The authors correctly pointed out that the performance of FedFed is limited by the storage capacity of clients.

Reviewer wKGY7/10 · confidence 4/52023-07-02

Summary

The paper proposes a method based on feature distillation to tackle data heterogeneity. The main contribution , as I see it, is in identifying performance-robust and performance-sensitive features and sharing the latter among clients to mitigate the impact of heterogeneity.

Strengths

- The method is simple (this is very important) and can be easily used with existing FL algorithms. - DP is incorporated to protect the leakage of privacy-sensitive information when sharing performance-sensitive features.

Weaknesses

- The evaluation is quite limited to vision datasets, which makes me unsure if it is going to generalize across modalities. - Number of clients (K) are also quite limited. In real-world setting 100-1000s of clients are involved in FL process.

Questions

Feature distillation idea is proposed in [1]. Isn't the idea same? Please cite [1]. [1] Romero, A., Ballas, N., Kahou, S. E., Chassang, A., Gatta, C., & Bengio, Y. (2014). Fitnets: Hints for thin deep nets. arXiv preprint arXiv:1412.6550.

Rating

7: Accept: Technically solid paper, with high impact on at least one sub-area, or moderate-to-high impact on more than one areas, with good-to-excellent evaluation, resources, reproducibility, and no unaddressed ethical considerations.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

2 fair

Presentation

2 fair

Contribution

3 good

Limitations

- Do not see discussion on whether performance-sensitive features indeed leak information. - Formal definitions of performance-robust and performance-sensitive features are missing. Please also make a subsection to provide detailed descriptions of how these two types of features are identified. - The experiments are only performed using ResNet-18.

Reviewer bAmN5/10 · confidence 3/52023-07-06

Summary

The paper proposes Federated Feature distillation, a method that addresses the tradeoff between privacy and model performance. It involves extracting performance-robust and performance-sensitive features from local data. The latter is shared among clients after applying differential privacy for privacy preservation. The paper also includes an empirical evaluation demonstrating the effectiveness of the proposed approach.

Strengths

The paper is well-written and easily comprehensible, with clear motivation and contribution. This paper theoretically shows that the proposed method achieves the same level of privacy with a relatively smaller noise compared to sharing the raw data. The proposed method can be seamlessly combined with existing universal methods,

Weaknesses

- Additional communication costs: As sharing globally shared data to all clients, it requires additional communication costs. In F.7 the authors analyze additional communication costs is as same as sending a classifier in approximately 14 communication rounds. But this analysis doesn’t consider the partial participating of federated learning. If we assume the 10% participation rate, sharing the global dataset is equal to the communication costs of 140 communication rounds, which is not small. - More local iterations on training: The presence of a globally shared dataset in FedFed results in each client having a significantly larger amount of local training data, K+1 times more than before. It also results in K+1 times local iterations, which can be computationally expensive for edge devices in federated learning, especially when dealing with massively distributed data in realistic settings. Furthermore, the considerably higher number of local updates in FedFed compared to the approach without FedFed makes it hard to attribute the observed gain in empirical results to a specific factor. It is well-known that increasing local updates can expedite the convergence speed in federated learning. Therefore, the observed gain in empirical results cannot be solely attributed to the FedFed approach, as the increased local iterations inherently provide an advantage. This factor should be taken into consideration when evaluating and comparing the performance of FedFed against other approaches. - There are lines of work that try to share the client data while preserving the privacy inspired by mixup, such as [Shin et al., 2020] and [Yoon et al., 2021]. These methods are not compared as baselines in evaluation results. [Shin et al., 2020] MyungJae Shin, Chihoon Hwang, Joongheon Kim, Jihong Park, Mehdi Bennis, and Seong-Lyun Kim. Xor mixup: Privacy-preserving data augmentation for one-shot federated learning. In ICML, 2020. [Yoon et al., 2021] Tehrim Yoon, Sumin Shin, Sung Ju Hwang, Eunho Yang. Fedmix: Ap- proximation of mixup under mean augmented federated learning. In ICLR, 2021.

Questions

- What is the model's performance when trained solely on the constructed global dataset ($D^s$)? - Are the models ($w_k^t$) trained in the Feature Distillation phase identical to the global model ($\phi_k^t$) in the local training phase? If they are the same, do the empirical results, in both cases with and without FedFed, initialize the global model in the local training phase with the identical parameters? - In section F.3, it is observed that sharing the partial feature with DP achieves higher accuracy compared to sharing the raw data with DP, which seems counterintuitive. What is the underlying insight or explanation for this phenomenon?

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

2 fair

Limitations

Limitation about storage overhead is stated while potential societal impact has not been addressed.

Reviewer LGae6/10 · confidence 3/52023-07-10

Summary

The paper introduces a federated learning framework (FedFed) to tackle data heterogeneity by utilizing an information-sharing approach. The method partitions data into performance-sensitive features and performance-robust features, based on their contribution to model performance. The performance-sensitive features are shared globally to mitigate data heterogeneity, while the performance-robust features are kept locally. The method employs DP to protect performance-sensitive features before sending them to the server.

Strengths

+ Improving how to handle data heterogeneity in federated learning is a timely and important problem. + The idea of tackling data heterogeneity from the Information Bottleneck perspective is interesting. + The solution appears to significantly boost training performance of various FL algorithms and (in most cases) reduces the required number of communication rounds, while maintaining privacy.

Weaknesses

- Overall the practicality of the method is unclear. - The evaluation only considers a single task and uses synthetic non-IID data. - The evaluation should include additional baselines.

Questions

This is an interesting approach but it's unclear how practical it is. The method appears to have several overheads that are not quantified: the computation overhead to generate the performance-robust/sensitive features and to train the local classifier, communication overhead to collect protected features from clients to construct a global dataset and send the dataset back to the clients, and storage overhead to save the models and the private and public datasets on each client. This might make the method not feasible for edge devices with limited capabilities. The experimental results focus on image classification task, with no experiments with other tasks. Also, the experiments rely on extreme non-IID partitions ( α=0.1 and α=0.05 ). It would be useful to test the method with different levels of heterogeneity (e.g., α=0.5 and α=1) and with datasets with natural non-IID partitions like Stack Overflow or Reddit. The evaluation should consider other baselines. It is good that FedFed can be applied on top of FL algorithms. But other extensions to those algorithms should be considered as a baseline too: an obvious one was mentioned by the authors, where the full data + random noise is shared. This baseline will tell us how much better FedFed is than the naive solution. The authors mentioned that this will result in an accuracy loss, but, without evidence to support this. The hyperparameters used in the experiments are not clear, and we don't know if they were tuned to get the best performance for each algorithm or not. The client selection hyperparameter is not mentioned. It is not clear how many clients will be sampled from the $K$ clients and what the selection method is. The method is described as an extension on top of FL algorithms, but the paper does not explain how the extension can be used with other algorithms. In fact, algorithm 1 depicts FedFed as a new FL algorithm and not an extension. It is not clear where $\mathcal{D}^s$ is used, which is why the entire algorithm is proposed! Note that there is a typo in eq. 8. The preliminaries section should introduce information bottleneck. Other questions that come up: 1. FedFed uses eq. 8 in the local update; but how does it extend SCAFFOLD, FedProx, and FedNova since they modify the local update as well? 2. The reported FedNova performance in table 1 does not seem to agree with the performance reported in their paper, where they always outperformed FedAvg; why is that? 3. Why the local epochs E was set to 1 and 5? Why 5 local epochs is not used with the experiment with 100 clients? 4. How many clients were sampled at every round? What is the value of the client selection hyperparameter? *I acknowledge I have read the authors' rebuttal and answers to my questions.*

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

2 fair

Presentation

3 good

Contribution

3 good

Limitations

* The paper has discussed the storage limitation but didn't clarify how much extra storage overhead was required and the size of the shared global datasets. * The paper didn't address how much per-round extra communication overhead the method required; although the approach seems to reduce the number of communication rounds significantly in most cases, there were some cases (table 4) that required more communication rounds compared to the other baselines. Moreover, communicating $x_p$ and $\theta$ adds extra communication overhead. Clearly, FedFed gains are not a free lunch, and these limitations must be considered, discussed, and be part of the evaluation.

Reviewer xchj5/10 · confidence 2/52023-07-13

Summary

Authors propose method (Federated Feature distillation) to share partial features in the data to tackle data heterogeneity, while the privacy issue is not compromised too much. FedFed partitions data into performance-sensitive features and performance-robust features. The performance-sensitive features are globally shared to mitigate data heterogeneity, while the performance-robust features are kept for local training.

Strengths

1. Authors claim to propose a new prospect on alleviating date heterogeneity in Federated Learning: sharing partial features. It is a new high-level idea to solve heterogeneity in FL. 2. To achieve the idea, authors further propose a method (FedFed). More specifically, it proposed to partition data into performance-sensitive features and performance-robust features is reasonable. The performance-sensitive features are globally shared to mitigate data heterogeneity, while the performance-robust features are kept locally. This idea is resonable. 3. It outperfroms baselines

Weaknesses

1. Insufficient baselines. I wonder how the choices of baselines are made? FedAvg, FedProx, FedNova and SCAFFOLD are early FL models. The latest among them is proposed in 2020. Why not adopt more recent FL models? For instance, FedGen (ICML 2021)[1]. Besides, I believe there are more FL models in recent years. [1] Zhu et al., Data-Free Knowledge Distillation for Heterogeneous Federated Learning. ICML 2021.

Questions

See weakness

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

2: You are willing to defend your assessment, but it is quite likely that you did not understand the central parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

3 good

Limitations

Yes

Reviewer wKGY2023-08-10

Thanks for the response and for running additional experiments. Another suggestion is to provide concrete yet concise examples when providing definitions for performance-robust and performance-sensitive features. Could you please expand on the following: "while FedFed distills features in the data space"? What are features in the data space, and how are they different from the hidden layer features employed in [R1]?

Authorsrebuttal2023-08-11

Response to New Questions from Reviewer wKGY

Thanks for your further professional suggestions! > Q1: provide concrete yet concise examples when providing definitions for performance-robust and performance-sensitive features. **A1:** Following your suggestion, we explicate the definition of performance-sensitive features and performance-robust features from the Information Bottleneck perspective. In brief, - At first, we define what a valid partition is (Definition 1); - Then, following the rules of valid partition, we formalize the two types of features (Definition 2). We will elaborate on the definition and explanation in our revision in terms of the following contents. *Definition 1. [valid partition] A partition strategy is to partition a variable $X$ into two parts in the same measure space such that $X=X_1 + X_2$. We say a partition strategy is valid if it holds: i. $H(X, X_1, X_2)=H(X); ii. H(X|X_1, X_2)=0; iii. I(X_1;X_2)=0$, where $H(\cdot)$ denotes the information entropy and $I(\cdot)$ is the mutual information.* Definition 1 captures the desirable attributes when we partition the features, which are abstracted to be a variable in general. Intuitively, - For i and ii: A valid partition should maintain all information of the original variable $X$ losslessly. That is, neither extra information is introduced nor key information is lost. - For iii: After determining the measure space, we partition the $X$ to be $X=X_1+X_2$. The mutual information of $X_1$ and $X_2$ is none. Here, $X_1$ and $X_2$ can be symmetric. Or saying, there is no overlap between $X_1$ and $X_2$. Built upon the valid partition, we present the definition between performance-sensitive features and performance-robust features, as in Definition 2. *Definition 2. Let $X=X_s + X_r$ be a valid partition strategy. We say $X_s$ is performance-sensitive features such that $I(X; Y|X_s)=0$, where $Y$ is the label of $X$. Accordingly, $X_r$ is the performance-robust feature.* Intuitively, performance-sensitive features contain all label information, while performance-robust features contain all information about the data except for the label information. That is, the features to be partitioned are either performance-sensitive features or performance-robust features. Appreciate again for your kind and constructive suggestion. We believe that our paper will be more clear and readable through your writing-shepherding. > Q2: Could you please expand on the following: "while FedFed distils features in the data space"? What are features in the data space, and how are they different from the hidden layer features employed in [R1]? **A2:** Thanks for your helpful comments. We hope the following explanation would make the difference clear between FedFed and [R1]. - In FedFed, we distil features in the data space, where we partition raw data $\mathbf{x} \in \mathbb{R}^{d}$ into two parts, i.e., $\mathbf{x}=\mathbf{x}_s+\mathbf{x}_r, \mathbf{x}_s \in \mathbb{R}^{d}, \mathbf{x}_r \in \mathbb{R}^{d}$. Thus, the aim of FedFed is to distil $\mathbf{x}_s$ from $\mathbf{x}$. - To perform knowledge distillation (i.e., the teacher-student paradigm), [R1] tries to guide student models to generate outputs similar to teacher models using the learned features $\mathbf{f}$. Here, the learned feature is extracted from the neural network $\phi$, i.e., $\mathbf{f}=\phi(\mathbf{x})$. Thanks again. We will elaborate on the corresponding explanation in the paper. **Reference** [R1] Romero A, Ballas N, Kahou S E, et al. Fitnets: Hints for thin deep nets. arXiv preprint arXiv:1412.6550.

Reviewer wKGY2023-08-12

So does it mean that FedFed reconstructs x_s from x? Does the paper use the term "distil" for input reconstruction? Otherwise, it is not clear how distillation is working in this context, if it is different than knowledge distillation? I would be happy to raise the score if this point is resolved.

Authorsrebuttal2023-08-12

Response to Questions from Reviewer wKGY

**A1:** Thanks for your swift reply, active interaction, and responsible help! Yes, FedFed employs ``distill`` for input reconstruction, i.e., reconstructing $\mathbf{x}_s$ from $\mathbf{x}$ and sharing the DP-protected $\mathbf{x}_s$ to tackle data heterogeneity. We sincerely express our deep and heartfelt appreciation to the reviewer wKGY for the constructive and insightful comments. Really glad to hear the enhanced endorsement of our paper. Your professional suggestions provide immense help to make our paper more clear and concise. We will dedicate our great efforts to improving the next version of our paper. Thanks again!

Reviewer wKGY2023-08-12

Then it is better to call it `input reconstruction`. Based on your rebuttal and additional experiments, I have increased the score.

Reviewer ezSw2023-08-14

Thanks for the detailed answers to my comments. This addresses a few of my concerns, and as a result, I have increased my score from 4 to 5. However, the reviewer remains concerned that sharing partial features in data compromises privacy, and thus it is important to compare the privacy-performance tradeoff of the proposed method with the baselines. The reviewer understands that providing a comprehensive analysis of privacy attacks is beyond the scope of this paper. But it is recommended to highlight the additional privacy leakage as a limitation in the manuscript.

Authorsrebuttal2023-08-14

Response to ezSw

Thanks for your further suggestions. We agree with you that it is important to compare the privacy-performance trade-off of the existing methods. We will highlight the additional privacy leakage in the updated revision. Thank you for dedicating your time to our paper and raising the score.

Reviewer bAmN2023-08-14

Thanks the authors for the response. Although the proposed method requires considerable extra communication cost in some practical settings, other my concerns have been addressed in the rebuttal. I will keep my original score as is.

Authorsrebuttal2023-08-20

Response to LGae

We are happy that we have addressed your concerns. Thank you for the effort you put into improving the quality of our paper. Thanks again for raising the score.

Program Chairsdecision2023-09-21

Decision

Accept (poster)

© 2026 NYSGPT2525 LLC