🤖 machine learning

Centralized vs Decentralized Federated Learning: A trade-off performance analysis

This paper experimentally analyzes the performance trade-offs between Centralized, Decentralized, and Semi-decentralized Federated Learning architectures using the Fedstellar simulator, MNIST dataset, and MLP classifier to address the lack of comparative studies on their respective strengths and limitations.

Original authors: Chaimaa Medjadji, Guilain Leduc, Sylvain Kubler, Yves Le Traon

Published 2026-05-18

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Chaimaa Medjadji, Guilain Leduc, Sylvain Kubler, Yves Le Traon

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you and a group of friends want to learn how to bake the perfect cake. You all have your own secret family recipes (your data), but you don't want to share the actual recipes with anyone because they are too precious. You just want to learn from each other to make a better cake together.

This is exactly what Federated Learning (FL) is: a way for computers (like your friends) to learn together without ever sharing their private data.

The paper you provided compares three different ways this "group baking" can happen. The authors set up a digital kitchen (using a simulator called FedStellar) to see which method works best, how fast it is, and how much "energy" (computer power and internet data) it uses.

Here is the breakdown of the three methods they tested, using simple analogies:

1. The Three Architectures (The Ways to Bake)

Centralized (CFL): The "Head Chef" Model
- How it works: Everyone sends their recipe notes to one Head Chef (a central server). The Head Chef mixes them all together, figures out the perfect new recipe, and sends it back to everyone.
- The Analogy: Imagine a classroom where every student writes their answer on a piece of paper and hands it to the teacher. The teacher grades them, writes the "correct" answer on the board, and the students copy it down.
- Pros: It's fast. The teacher is right there, so the class learns quickly.
- Cons: The teacher gets overwhelmed if there are too many students. Also, if the teacher's desk gets knocked over (server failure), the whole class stops. It also requires a lot of running back and forth to the teacher's desk (high communication cost).
Decentralized (DFL): The "Potluck" Model
- How it works: There is no Head Chef. Instead, you only talk to your immediate neighbors. You swap recipe tips with the person next to you, they swap with the person next to them, and eventually, the whole group learns the best recipe without a central boss.
- The Analogy: Imagine a circle of friends passing a note around. You whisper your tip to your neighbor, they whisper to theirs. No one is in charge; the knowledge spreads organically.
- Pros: Very efficient. No single point of failure. If one person leaves, the group keeps going. It uses less "energy" to send messages because you only talk to neighbors.
- Cons: It takes longer for the "secret" to spread to everyone. It's a bit slower to reach a final agreement.
Semi-Decentralized (SDFL): The "Rotating Captain" Model
- How it works: This is a mix. Sometimes there is a leader, but the leader changes every round. One person acts as the Head Chef for a few minutes, then passes the baton to someone else.
- The Analogy: Imagine a game where you take turns being the team captain. Today, Alice leads the discussion; tomorrow, Bob leads.
- Pros: It tries to get the speed of the Head Chef with the fairness of the Potluck.
- Cons: It's a bit more complicated to manage than the other two.

2. What Did the Experiment Find?

The researchers ran these scenarios with different group sizes (3, 4, 6, and 8 "bakers") and measured two main things: How good was the final cake? (Accuracy) and How much effort did it take? (Time, internet data, and computer power).

Here are the key takeaways:

The "Head Chef" (CFL) is Fast but Fragile:
- It learned the fastest. If you need a result right now, this is the way to go.
- However, as the group got bigger, the quality of the cake actually got worse. Why? Because the "Head Chef" had to split the work among too many people, so each person had less data to learn from.
- It was also the most expensive in terms of internet data used (sending everything to one spot).
The "Potluck" (DFL) is the Best Quality:
- This method produced the best-tasting cake (highest accuracy, around 97-98%) regardless of how many people were in the group.
- It was the most efficient with resources.
- The Catch: It took the longest time to finish. Because everyone was just whispering to neighbors, it took a while for the whole group to agree on the final recipe.
The "Rotating Captain" (SDFL) is the Middle Ground:
- It performed almost as well as the Potluck (DFL) but was sometimes faster at converging (finishing the learning process).
- It was a great balance, offering high performance without needing as many resources as the Head Chef model.

3. The Big Trade-Off

The main lesson from this paper is that there is no "perfect" choice. It depends on what you value most:

Need speed? Choose CFL (Centralized). It's the sprinter.
Need the best results and privacy with a large group? Choose DFL (Decentralized). It's the marathon runner that never gives up.
Want a balance? Choose SDFL (Semi-Decentralized). It's the middle-distance runner.

Summary

The paper concludes that if you have a small group and need quick answers, use a central server. But if you have a huge network of devices (like thousands of IoT sensors) and care about privacy and efficiency, the decentralized or semi-decentralized approaches are much better, even if they take a little longer to finish the job. The authors suggest that in the future, they want to build a "decision tool" to help managers pick the right method for their specific situation.

Technical Summary: Centralized vs. Decentralized Federated Learning: A Trade-off Performance Analysis

Problem Statement
Federated Learning (FL) has emerged as a critical paradigm for collaborative model training across distributed edge devices, addressing the challenges of data privacy, limited communication resources, and regulatory constraints associated with the exponential growth of Internet of Things (IoT) data. While FL architectures are generally categorized into Centralized (CFL), Decentralized (DFL), and Semi-Decentralized (SDFL), there is a significant gap in the literature regarding experimental comparisons of these three types. Existing research often focuses on architectural design or specific domain applications (e.g., Blockchain in DFL) but rarely provides a systematic, empirical analysis of the trade-offs between different Key Performance Indicators (KPIs) across CFL, DFL, and SDFL. This lack of comparative data makes it difficult for practitioners to select the optimal architecture based on specific application needs and constraints.

Methodology
To address this gap, the authors conducted a comprehensive experimental analysis using the FedStellar simulator, which is currently the only platform capable of simulating all three FL architectures (CFL, DFL, and SDFL) with high scalability. The experimental setup involved:

Dataset and Model: The MNIST dataset (60,000 handwritten digit images) was partitioned among participants, and a Multilayer Perceptron (MLP) classifier was used for training.
Scalability Testing: The number of participants ( $|N|$ ) was varied from 3 to 8 to investigate the impact of network size on performance.
Configuration: Experiments were run for 10 rounds with 3 epochs per round. The network topology was configured as fully connected to facilitate communication.
KPIs Evaluated: Drawing from a taxonomy proposed by Beltran et al., the study measured specific metrics available within FedStellar, including:
- Model Performance: Accuracy, Precision, Recall, F-score, and Loss.
- Resource Usage: CPU usage percentage.
- Communication: Bytes exchanged between participants.
- Efficiency: Convergence time.

Key Results
The experiments revealed distinct performance trade-offs among the three architectures:

Model Performance and Stability:
- DFL consistently achieved the highest model performance (e.g., ~97.84% accuracy with 3 participants) and maintained this high performance as the number of participants increased. Its decentralized nature allows it to remain resilient to participant count fluctuations.
- SDFL demonstrated performance very close to DFL (e.g., ~96.31% with 3 participants) and also maintained stability as the network scaled.
- CFL showed lower overall accuracy (e.g., ~94.45% with 3 participants) and a notable decline in performance as the number of participants increased. This degradation is attributed to the division of the dataset into smaller subsets per participant, limiting the data available for local training.
Convergence Time:
- CFL was the fastest to converge, achieving performance levels in approximately half the time required by DFL and SDFL. It exhibited greater stability in convergence speed.
- DFL and SDFL required longer convergence times due to the need for coordination and communication among nodes without a central aggregator. Interestingly, DFL showed a decrease in convergence time as the network scaled (from ~43 min to ~31 min for 3 to 8 participants), likely due to smaller local data sizes, whereas CFL and SDFL saw increased convergence times with larger networks.
Resource and Communication Efficiency:
- DFL was identified as the most resource-efficient architecture, requiring the least CPU usage and exchanging the fewest bytes, as it eliminates the need for a central server.
- CFL was the most resource-intensive ("greediest"), particularly regarding communication costs, due to the reliance on a central server for aggregation.
- SDFL offered a middle ground, with resource usage and communication costs closely aligned with DFL, though it required more time than DFL in certain scaling scenarios.

Key Contributions

Experimental Benchmarking: The paper provides one of the first experimental comparisons of CFL, DFL, and SDFL architectures using a unified simulator (FedStellar), moving beyond theoretical or single-architecture studies.
Trade-off Identification: The study explicitly identifies the trade-offs between model accuracy, convergence speed, and resource consumption. It highlights that while DFL offers superior accuracy and scalability, it comes at the cost of slower convergence. Conversely, CFL offers speed but suffers from performance degradation in large-scale networks.
Scalability Insights: The research demonstrates that DFL and SDFL are more resilient to the "data fragmentation" problem inherent in CFL when scaling the number of participants.

Significance and Claims
The authors modestly frame this work as an initial step in addressing the lack of comparative analysis in the FL domain. The significance lies in providing empirical evidence to guide the selection of FL architectures based on specific constraints:

DFL is presented as a promising strategy for scenarios prioritizing high performance and data privacy in scalable networks.
SDFL is identified as a cost-effective solution for larger networks, offering performance comparable to DFL with reduced resource requirements.
CFL remains the optimal choice when speed of convergence is the paramount requirement, despite its lower efficiency and scalability limitations.

The paper concludes that the "best" architecture is context-dependent, relying on factors such as data nature, node count, privacy requirements, and infrastructure constraints. Future work is proposed to expand the range of KPIs and develop a decision-support tool to assist managers in selecting the appropriate FL architecture.

1. The Three Architectures (The Ways to Bake)

2. What Did the Experiment Find?

3. The Big Trade-Off

Summary

More like this