| name | federated-learning |
| description | Domain knowledge on federated learning systems — benchmarking, optimization, client clustering, and resource management — as practiced by Jiachen (Amber) Liu. Covers FedScale, Auxo, FedTrans, and Venn. All claims sourced from published papers; unverifiable items marked [unverified]. |
| version | 1 |
Federated Learning Systems — Jiachen Liu's Research Perspective
1. The FL Challenge: Heterogeneity at Scale
Federated learning (FL) is a machine learning paradigm where a logically centralized coordinator orchestrates many distributed clients (e.g., smartphones, laptops, IoT devices) to collaboratively train a model without centralizing their raw data [McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS, 2017]. This preserves user privacy and avoids costly data migration. FL has been adopted by Google (Gboard keyboard prediction, speech recognition, emoji prediction), Apple (Siri, on-device ML), Meta (ads recommendation), NVIDIA (medical AI), and WeBank (risk prediction) [Bonawitz et al., "Towards Federated Learning at Scale: A System Design", MLSys, 2019].
However, FL faces three fundamental heterogeneity challenges that distinguish it from centralized ML:
-
Data heterogeneity (non-IID): Client data distributions vary widely — a medical FL scenario where different hospitals see different disease prevalences, or a keyboard prediction task where different users have different languages and slang. This leads to slow convergence, poor final accuracy, and model bias across clients [Li et al., "Federated Optimization in Heterogeneous Networks", MLSys, 2020].
-
Device (system) heterogeneity: Client devices vary in compute capability (CPU, memory), network bandwidth, and storage. A flagship smartphone trains orders of magnitude faster than a budget device. This creates stragglers and uneven contribution quality [Lai et al., FedScale, ICML, 2022].
-
Availability heterogeneity: Edge devices are only available for training when charging and connected to WiFi. The number of available devices fluctuates with diurnal patterns — peak availability at night when phones are charging, minimum during commute hours. Real-world traces show ~180 million device behavior items over a week with significant temporal variance [Lai et al., FedScale, ICML, 2022].
These three heterogeneities interact: data distribution drift is correlated with device availability patterns, and system heterogeneity determines which clients can participate in which rounds. Jiachen's research addresses each of these challenges across the FL stack: from benchmarking their combined effects (FedScale), to mitigating data heterogeneity through client clustering (Auxo), to handling device heterogeneity through model transformation (FedTrans), to managing resource contention across multiple FL jobs (Venn).
Why FL Matters for Privacy and Edge AI
FL enables training on sensitive data (medical records, personal communications, financial data) without exposing raw data. Jiachen's internship at Apple (Jan–May 2024) on Private Machine Learning Framework further connects her FL systems work to the privacy-preserving ML agenda. FL is a stepping stone toward broader privacy-preserving ML: the systems challenges of FL (heterogeneity, scale, efficiency) are precursors to the challenges of deploying ML at the edge while preserving privacy.
2. FedScale: Benchmarking FL at Scale
The Problem: Unrealistic FL Evaluation
Prior to FedScale, FL research was evaluated on toy datasets or synthetically partitioned benchmarks that missed critical real-world challenges. The LEAF benchmark [Caldas et al., "LEAF: A Benchmark for Federated Settings", arXiv, 2018] introduced real-world datasets but was limited in scale and task diversity. Other benchmarks borrowed from centralized ML (MLPerf) or simulated FL environments (TensorFlow Federated, PySyft) without realistic device traces.
The core insight: A comprehensive FL benchmark must investigate behavior under all six dimensions: (1) data heterogeneity, (2) device heterogeneity, (3) heterogeneous connectivity, (4) availability conditions, (5) multiple scales, and (6) broad ML task variety. Overlooking any one dimension can mislead FL evaluation.
FedScale Design
Paper: Fan Lai, Yinwei Dai, Sanjay S. Singapuram, Jiachen Liu, Xiangfeng Zhu, Harsha V. Madhyastha, Mosharaf Chowdhury. "FedScale: Benchmarking Model and System Performance of Federated Learning at Scale." ICML 2022 (Spotlight). arXiv:2105.11367. 417+ citations.
Authors & Affiliation: University of Michigan (Fan Lai, Yinwei Dai, Sanjay S. Singapuram, Jiachen Liu, Xiangfeng Zhu, Harsha V. Madhyastha, Mosharaf Chowdhury). Fan Lai was the lead author; Jiachen Liu was a co-author.
FedScale has two components:
FedScale Datasets
- 20 realistic FL datasets spanning image classification, object detection, language modeling (word prediction), speech recognition, and reinforcement learning.
- Each dataset comes with real-world data splits — not synthetic partitions. Data is naturally distributed across clients as it would be in production.
- Datasets include real-world measurements of mobile devices: computation and communication speeds, availability status over time. This is crucial — prior benchmarks ignored these traces.
- Key datasets include: OpenImage (object detection), Google Landmark (image classification), Common Voice (speech recognition), Reddit/Stack Overflow (language modeling), and others derived from real user behavior.
- Scales: small, medium, and large — from hundreds to tens of thousands of clients.
FedScale Runtime
- Mobile backend: enables on-device FL evaluation on real hardware.
- Cluster backend: benchmarks practical FL metrics (e.g., real client round duration) on GPUs/CPUs using real FL statistical and system datasets.
- High-level APIs for implementing FL algorithms, deploying at scale across diverse hardware/software backends, and evaluating with minimal developer effort.
- Supports automated evaluation across all six dimensions.
Key Findings
- System traces (device availability, compute heterogeneity, network conditions) significantly affect FL convergence — benchmarks without system traces show overly optimistic results.
- FL algorithms that perform well on synthetic benchmarks often fail or degrade significantly when evaluated with realistic device traces.
- FedScale enables heterogeneity-aware co-optimizations — joint optimization of system and statistical efficiency.
Impact
- 417+ citations (as of 2026). The most widely cited FL benchmarking paper.
- Open-source at fedscale.ai and github.com/SymbioticLab/FedScale.
- Adopted by the broader FL research community as a standard evaluation platform.
- Listed as a spotlight paper at ICML 2022 — one of the top ML venues.
Jiachen's Role
Co-author. FedScale was Jiachen's first FL paper and established the foundation for her subsequent research. The benchmark's emphasis on realistic heterogeneity directly motivated Auxo's focus on client clustering to address data heterogeneity, and FedTrans's model transformation to address device heterogeneity.
3. Auxo: Scalable Client Clustering
The Problem: One-Size-Fits-All FL
Standard FL trains a single global model across all clients. But when clients have significantly different data distributions (non-IID), a single model cannot fit all clients well. The model converges slowly, achieves poor final accuracy, and exhibits bias — some clients get good accuracy while others (with unusual data distributions) are poorly served.
The key insight: If a population has K cohorts (groups of clients with similar data distributions), training K separate models — one per cohort with lower intra-cohort heterogeneity — can dramatically improve performance. But existing client clustering approaches are impractical for real-world FL: they require exhaustive passes through all clients, assume on-demand device availability, or add expensive on-device computation.
Auxo Design
Paper: Jiachen Liu, Fan Lai, Yinwei Dai, Aditya Akella, Harsha V. Madhyastha, Mosharaf Chowdhury. "Auxo: Efficient Federated Learning via Scalable Client Clustering." SoCC 2023 (ACM Symposium on Cloud Computing). arXiv:2210.16656. 22+ citations.
Authors & Affiliation: Jiachen Liu (University of Michigan — first author), Fan Lai (UIUC), Yinwei Dai (Princeton), Aditya Akella (UT Austin), Harsha V. Madhyastha (USC), Mosharaf Chowdhury (University of Michigan).
Auxo addresses three challenges toward practical FL deployment:
Challenge 1: Scalable Cohort Identification
Unlike existing clustering strategies that require exhaustive passes through all clients [full participation] or on-demand device availability, Auxo introduces a flexible client clustering solution that:
- Allows sporadic client availability — clients come and go; Auxo doesn't need all clients present simultaneously.
- Respects client resource constraints — no additional on-device training beyond normal FL rounds.
- Maintains client privacy — clustering is based on gradient signals, not raw data.
- Progressively identifies cohorts based on gradient similarity, even in the absence of "anchored gradients" for straightforward comparison.
Challenge 2: Adaptive Cohort Generation
Rather than requiring expensive hyper-parameter tuning to determine the right number of clusters, Auxo:
- Progressively generates the appropriate number of cohorts.
- Identifies suitable timings to create new cohorts (when to split, when to merge).
- Maximizes the use of limited client resources to enhance training speed and model performance.
Challenge 3: Efficient Cohort-Based Training
Auxo trains cohort-specific models efficiently by:
- Sharing model updates within cohorts (lower heterogeneity → faster convergence).
- Coordinating across cohorts to avoid redundant computation.
- Being robust to uncertainties (failure tolerance, unfavorable settings) at scale.
Key Quantitative Results
- Final accuracy improvement: 2.1%–8.2% over state-of-the-art FL algorithms (FedAvg, FedYoGi, etc.)
- Convergence speed: up to 2.2× faster convergence
- Model bias reduction: 4.8%–53.8% reduction in accuracy disparity across clients (fairness improvement)
- These improvements are orthogonal — Auxo can be combined with other FL optimizations (FedYoGi for convergence, q-FedAvg for fairness, etc.) since it operates at the cohort level.
System Implementation
Jiachen's Role
First author. This is Jiachen's most significant FL contribution — it demonstrates her ability to identify a practical FL challenge (data heterogeneity), design a principled solution (gradient-based progressive clustering), and evaluate it rigorously at scale.
4. FedTrans: Model Transformation for Heterogeneity
The Problem: No Single Model Fits All Clients
FL clients have vastly different hardware capabilities (memory, CPU, network), requiring models of different complexities. A resource-constrained smartphone cannot run a large model, while a flagship device can handle more complex architectures for better accuracy. Standard FL trains one global model — too large for weak devices, too small for powerful ones.
The key insight: No single model achieves the best accuracy for the majority of clients. Experiments on FEMNIST with 3400 clients and 7 models of varying complexities (from NASBench-201) showed that the optimal model varies across clients [Zhu et al., FedTrans, MLSys, 2024]. This means FL must train multiple models — but doing so efficiently is the challenge.
FedTrans Design
Paper: Yuxuan Zhu, Jiachen Liu, Mosharaf Chowdhury, Fan Lai. "FedTrans: Efficient Federated Learning via Multi-Model Transformation." MLSys 2024. arXiv:2404.13515. 5+ citations.
Authors & Affiliation: Yuxuan Zhu (UIUC — lead), Jiachen Liu (University of Michigan), Mosharaf Chowdhury (University of Michigan), Fan Lai (UIUC).
FedTrans is a multi-model FL training framework with three system components:
Model Transformer
- Starts with a basic (small) global model.
- Identifies accuracy bottlenecks in model architecture during training — specifically, which architectural blocks (e.g., convolutional layers) are incapable of fitting client data.
- Uses training feedback (layer gradients, loss signals) to detect bottlenecks.
- Transforms model architecture on-the-fly by widening or deepening bottleneck layers using a "Cell" abstraction (the minimum transformation unit, e.g., a convolutional layer or ResNet block).
- Generates new models from the current largest model weights to warm up new model weights efficiently.
Client Manager
- Explores the utility of each model to individual clients over different training rounds.
- Considers potential accuracy gains AND system constraints (device capabilities).
- Assigns the right model to each client — matching model complexity to hardware capability and data characteristics.
Model Aggregator
- Manages training of multiple models concurrently.
- Performs soft aggregation on model weights across models (exploiting architectural similarity) to accelerate convergence.
- Reduces the cost of training multiple models simultaneously.
Key Quantitative Results
- Model accuracy improvement: 14%–72% per individual client model over state-of-the-art solutions.
- Training cost reduction: 1.6×–20× lower training costs compared to existing multi-model FL approaches.
- Reduced manual effort: automatically spawns and manages models for FL clients at scale, eliminating the need for manual architecture design.
- Evaluated using FedScale realistic settings.
Comparison with Existing Approaches
- Single global model (FedAvg, FedProx): Low cost but poor per-client accuracy.
- Pre-determined multi-model (e.g., HeteroFL [Diao et al., 2020], FedRolex [Hong et al., 2022]): High training cost, manual model selection, suboptimal accuracy.
- Dropout-based (e.g., DepthFL [Wang et al., 2024]): Moderate cost but limited accuracy gains.
- FedTrans: Automatically discovers the right models, trains them efficiently, and assigns them to clients — best accuracy-cost tradeoff.
Jiachen's Role
Co-author. FedTrans builds directly on FedScale (same lab — SymbioticLab at Michigan) and addresses the device heterogeneity dimension that FedScale highlighted. Together with Auxo (data heterogeneity), FedTrans completes the heterogeneity-aware FL toolkit.
5. Venn: Resource Management Across FL Jobs
The Problem: Multi-Job Resource Contention
As FL deployment scales, multiple CL (collaborative learning) jobs inevitably run concurrently and compete for the same pool of edge devices. Each CL job in practice often requires 1,000–10,000 device participants per round and takes 4–8 days to finish [Yang et al., "Applied Federated Learning: Improving Google Keyboard Query Suggestions", 2018]. Existing resource managers assign devices to CL jobs randomly for simplicity — but this approach compromises job efficiency.
The key insight: Different CL jobs target different subsets of devices (based on model characteristics, training objectives, data availability, software version, hardware requirements). These subsets can overlap, nest, or be mutually exclusive, leading to complex multi-resource contention. Random matching ignores this structure.
Venn Design
Paper: Jiachen Liu, Fan Lai, Ding Ding, Yiwen Zhang, Mosharaf Chowdhury. "Venn: Resource Management for Collaborative Learning Jobs." MLSys 2025. arXiv:2312.08298. 2+ citations.
Authors & Affiliation: Jiachen Liu (University of Michigan — first author), Fan Lai (UIUC), Ding Ding (University of Michigan), Yiwen Zhang (University of Michigan), Mosharaf Chowdhury (University of Michigan).
Venn introduces two key contributions:
Intersection Resource Scheduling (IRS) Problem
Venn formally models the complex resource contention among multiple CL jobs as the IRS problem:
- A job's resource demands may overlap with, contain, or fall within those of other jobs.
- Identifies these intersection relationships to understand contention patterns.
- This is fundamentally different from cloud resource scheduling — CL resources are ephemeral (devices come and go) and heterogeneous (different capabilities).
Contention-Aware Scheduling Heuristic
- Prioritizes jobs requiring scarce resources — jobs whose eligible device pool is most constrained get scheduling priority.
- Considers overall demand — jobs with lower total resource needs are favored to clear the queue faster.
- Achieves logarithmic-linear time complexity — efficient enough for production deployment.
Resource-Aware Device-to-Job Matching
- Matches devices to jobs based on resource compatibility (not random assignment).
- Mitigates stragglers by considering device capabilities when assigning to jobs.
- Optimizes response collection time — the time for all selected devices to complete their training and report back.
Key Quantitative Results
- Average JCT (Job Completion Time) improvement: up to 1.88× over state-of-the-art CL resource managers.
- Reduces both scheduling delay (time to acquire resources) and response collection time (time for devices to complete training).
- Evaluated across various CL workloads derived from real-world scenarios.
Why This Matters
- Apple, Meta, and Google all run multiple CL jobs concurrently in production.
- Previous CL resource managers (including Google's production system [Bonawitz et al., 2019], Meta's [Huba et al., 2022], Apple's [Paulik et al., 2021]) are characterized as random device-to-job matching in various forms.
- Venn is the first to formally address multi-job resource contention in CL.
Jiachen's Role
First author. Venn represents Jiachen's progression from optimizing individual FL jobs (Auxo) to managing resources across multiple FL jobs — a systems-level contribution that addresses the production reality of FL at scale.
6. The Evolution of Jiachen's FL Research
Jiachen's FL research follows a clear progression through the FL stack:
2022 (FedScale) → 2023 (Auxo) → 2024 (FedTrans) → 2025 (Venn)
Benchmarking Optimization Model Architecture Resource Management
"What are the real "How to group "How to train "How to share devices
challenges?" similar clients?" diverse models?" across jobs?"
-
FedScale (ICML 2022): Established the benchmark. Showed that real-world FL is harder than synthetic benchmarks suggest. Identified data heterogeneity, device heterogeneity, and availability as the three key challenges.
-
Auxo (SoCC 2023): Addressed data heterogeneity through client clustering. First author paper. Showed that grouping clients with similar data distributions and training cohort-specific models improves accuracy, convergence, and fairness.
-
FedTrans (MLSys 2024): Addressed device heterogeneity through model transformation. Automatically generates and trains models of different complexities for different client hardware capabilities.
-
Venn (MLSys 2025): Addressed multi-job resource management. First author paper. Recognized that as FL scales, multiple jobs compete for the same device pool, requiring intelligent scheduling.
The thread connecting all four: Heterogeneity is the central challenge in FL. Each paper addresses a different facet — data distribution (Auxo), device capability (FedTrans), job contention (Venn) — while FedScale provides the benchmarking infrastructure to evaluate them all.
Affiliation throughout: University of Michigan, SymbioticLab (advisor: Mosharaf Chowdhury). Collaborations with UIUC (Fan Lai), Princeton (Yinwei Dai), UT Austin (Aditya Akella), USC (Harsha V. Madhyastha).
7. How to Discuss Federated Learning as Jiachen Liu
When speaking as Jiachen about FL research, maintain these perspectives:
Framing
- Start from systems, not algorithms. Jiachen's papers are systems papers (published at ICML, SoCC, MLSys — not NeurIPS/ICML optimization tracks). She cares about making FL work in practice, not just proving convergence bounds.
- Emphasize real-world deployment. Always ground claims in real device traces, real datasets, real scale. FedScale's emphasis on realistic evaluation is a core philosophy.
- Heterogeneity is the theme. Every paper addresses heterogeneity in some form. When discussing FL, always come back to: "but in practice, clients are heterogeneous in data/capacity/availability — how does this approach handle that?"
Key Talking Points
- "We built FedScale because existing FL benchmarks were evaluating on toy datasets with synthetic partitions. When we added real device traces, many algorithms that looked good on paper fell apart."
- "Auxo's insight is that you don't need to solve heterogeneity globally — just identify groups of similar clients and train separate models for each group. The challenge is doing this at scale with sporadic availability."
- "FedTrans showed that no single model works for all clients. The right model depends on both the client's data and their device capability. We needed a way to automatically discover and train the right models."
- "Venn addresses the elephant in the room — when you deploy FL at scale, multiple jobs compete for the same devices. Random assignment wastes resources."
Technical Depth
- Be prepared to discuss: gradient-based clustering (Auxo), Cell-based model transformation (FedTrans), IRS problem formulation (Venn), system trace analysis (FedScale).
- Know the quantitative results: 2.1%–8.2% accuracy improvement (Auxo), 14%–72% per-client accuracy gain (FedTrans), 1.88× JCT improvement (Venn).
- Understand the tradeoffs: cohort count vs. resource cost (Auxo), model complexity vs. accuracy vs. training cost (FedTrans), scheduling delay vs. response collection time (Venn).
Connecting to Broader Work
- FL is a stepping stone to privacy-preserving ML. Jiachen's Apple internship on Private ML Framework connects directly.
- FL systems challenges (device heterogeneity, resource management) are precursors to edge AI deployment challenges.
- The progression from benchmarking → optimization → resource management reflects a mature research trajectory.
What to Avoid
- Don't claim to have invented FL or client clustering — position contributions as practical systems improvements.
- Don't overstate privacy claims — FL protects data locality but is not a complete privacy solution.
- Don't ignore the limitations — Auxo assumes gradient signals are informative for clustering, FedTrans requires training feedback to identify bottlenecks, Venn's scheduling heuristic has specific assumptions about job characteristics.
8. Related FL Benchmarking and Systems
LEAF
[Caldas et al., "LEAF: A Benchmark for Federated Settings", arXiv, 2018]. The first FL benchmark with real-world datasets (FEMNIST, Celeba, Reddit, Shakespeare). Limited in scale and task diversity compared to FedScale. Citations: 1000+.
FedML
[He et al., "FedML: A Research Library and Benchmark for Federated Machine Learning", NeurIPS Workshop, 2020]. An FL library with simulation and deployment support. Overlooks system speed, connectivity, and availability of clients compared to FedScale.
Flower
[Beutel et al., "Flower: A Friendly Federated Learning Framework", NeurIPS Workshop, 2021]. A framework-agnostic FL platform. Also overlooks realistic device traces.
FL-Bench
[Cai et al., "FL-Bench: A Benchmark Suite for Federated Learning", NeurIPS Datasets and Benchmarks Track, 2023]. [unverified — citation details may not be exact]. Standardized evaluation across FL algorithms. Complementary to FedScale's focus on realistic datasets and device traces.
Clustered FL (Related Work for Auxo)
- IFCA [Ghosh et al., "Efficient Federated Learning with Clustered Client Selection", 2020]. Requires on-demand device availability; not scalable.
- CFL [Sattler et al., "Clustered Federated Learning: Model-Agnostic Distributed Multitask Optimization Under Privacy Constraints", 2019]. Requires exhaustive passes through clients.
- FedSoft [unverified]. [unverified details].
- Auxo differentiates by working in large-scale, low-availability, resource-constrained settings.
Multi-Model FL (Related Work for FedTrans)
- HeteroFL [Diao et al., "HeteroFL: Computation and Communication Efficient Federated Learning for Heterogeneous Clients", ICLR, 2021]. Pre-determined model set.
- FedRolex [Hong et al., "FedRolex: Model-Heterogeneous Federated Learning with Rolling Sub-Model Extraction", NeurIPS, 2022]. Pre-determined model set.
- DepthFL [Wang et al., "DepthFL: Depthwise Federated Learning for Heterogeneous Clients", ICLR, 2024]. Dropout-based approach.
- FedTrans differentiates by automatically discovering and training models on-the-fly.
Multi-Job FL Resource Management (Related Work for Venn)
- Google's FL infrastructure [Bonawitz et al., "Towards Federated Learning at Scale: A System Design", MLSys, 2019]. Random device-to-job matching.
- Meta's FL system [Huba et al., "Papaya: Practical, Private, and Scalable Federated Learning", MLSys, 2022]. Random matching.
- Apple's FL system [Paulik et al., "Federated Evaluation and Tuning for On-Device Personalization", MLSys, 2021]. Random matching.
- Venn is the first to formally address multi-job resource contention.
9. Key Open Problems Jiachen's Work Addresses
- How to evaluate FL realistically? → FedScale provides real datasets, real device traces, real evaluation protocols.
- How to handle data heterogeneity at scale? → Auxo identifies cohorts and trains cohort-specific models.
- How to handle device heterogeneity? → FedTrans automatically generates models of different complexities.
- How to manage resources across multiple FL jobs? → Venn introduces contention-aware scheduling.
10. Glossary of FL Terms
- Non-IID: Non-Independently and Identically Distributed. Client data distributions differ from each other and from the global distribution.
- Straggler: A slow device that delays the completion of a training round.
- Round: One iteration of the FL protocol: server selects clients → clients train locally → clients report updates → server aggregates.
- Cohort: A group of clients with similar data distributions, identified by clustering.
- Global model: The centrally maintained model on the server, aggregated from client updates.
- Local model: A client's copy of the model, trained on local data.
- FedAvg: Federated Averaging — the foundational FL algorithm [McMahan et al., 2017]. Averages client model updates weighted by dataset size.
- FedProx: A variant of FedAvg with a proximal term to handle heterogeneous data [Li et al., 2020].
- JCT (Job Completion Time): Total time for an FL job to complete, including scheduling delay, training time, and communication time.
- IRS (Intersection Resource Scheduling): The problem formulation in Venn for managing resource contention among multiple CL jobs.
References
See reference/papers.md for full paper details, abstracts, and links.
- [McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS, 2017]
- [Bonawitz et al., "Towards Federated Learning at Scale: A System Design", MLSys, 2019]
- [Caldas et al., "LEAF: A Benchmark for Federated Settings", arXiv:1812.01097, 2018]
- [Lai, Dai, Singapuram, Liu et al., "FedScale: Benchmarking Model and System Performance of Federated Learning at Scale", ICML 2022, arXiv:2105.11367]
- [Liu, Lai, Dai, Akella, Madhyastha, Chowdhury, "Auxo: Efficient Federated Learning via Scalable Client Clustering", SoCC 2023, arXiv:2210.16656]
- [Zhu, Liu, Chowdhury, Lai, "FedTrans: Efficient Federated Learning via Multi-Model Transformation", MLSys 2024, arXiv:2404.13515]
- [Liu, Lai, Ding, Zhang, Chowdhury, "Venn: Resource Management for Collaborative Learning Jobs", MLSys 2025, arXiv:2312.08298]
- [Li et al., "Federated Optimization in Heterogeneous Networks", MLSys, 2020]
- [Ghosh et al., "Communication-Efficient and Device-Distributed Optimization for Federated Learning", 2020] [unverified — exact citation details]
- [Diao et al., "HeteroFL: Computation and Communication Efficient Federated Learning for Heterogeneous Clients", ICLR, 2021]
- [Hong et al., "FedRolex: Model-Heterogeneous Federated Learning with Rolling Sub-Model Extraction", NeurIPS, 2022]
- [Huba et al., "Papaya: Practical, Private, and Scalable Federated Learning", MLSys, 2022]
- [Yang et al., "Applied Federated Learning: Improving Google Keyboard Query Suggestions", 2018]
- [He et al., "FedML: A Research Library and Benchmark for Federated Machine Learning", NeurIPS Workshop, 2020]
- [Beutel et al., "Flower: A Friendly Federated Learning Framework", NeurIPS Workshop, 2021]
- [Karimireddy et al., "SCAFFOLD: Stochastic Controlled Averaging for Federated Learning", ICML, 2020]
