Robust Federated Learning Under Real-World Client Churn

# Robust Federated Learning Under Real-World Client Churn
Source: [https://arxiv.org/html/2607.06979](https://arxiv.org/html/2607.06979)
###### Abstract\.

Federated Learning \(FL\) enables training shared models on private, on\-device data, yet current production systems are typically constrained to slow, multi\-day refresh cycles due to the complexity of coordinating massive client populations\. However, for modern applications such as feed ranking, ad\-targeting, and personalized recommendation systems, model*freshness*, the ability to adapt rapidly to new user\-local data, is a critical driver for maximizing application objectives like click\-through\-rate\. This temporal gap leaves models stale and unresponsive to volatile live data distributions, such as viral trends or shifting user intents\. Bridging this gap requires navigating three interlocking constraints that existing FL systems don’t address: transient client availability, highly dynamic data heterogeneity, and the inherent delay between model predictions and observable application outcomes\. We presentFeLiX, a redesign of FL orchestration that optimizes*time\-to\-target*accuracy on live interaction streams\. FeLiX introduces three novel primitives: \(i\)streaming\-aware availability tiers, which use lightweight telemetry to surface ready clients at scale; \(ii\)fresh\-utility selection, a dual\-tier mechanism that scouts for high\-value statistical contributions on devices capable of meeting tight refresh deadlines; and \(iii\)informativeness\-aware, delay\-robust aggregation, which incorporates late, high\-value updates containing ground\-truth outcomes without biasing the global model toward obsolete distributions\. Unlike existing systems that rely on unrealistic oracular knowledge of client availability, FeLiX achieves near\-oracular performance in real\-world settings\. Evaluated across multiple modalities \(CIFAR\-10 and Google Speech\) and realistic low\-availability traces, FeLiX reduces wall\-clock time\-to\-target accuracy by up to2\.37×2\.37\\timeswhile also saving1\.30×1\.30\\timestotal communication bandwidth compared to state\-of\-the\-art Synchronous and Asynchronous FL baselines\. By enabling faster model adaptation under adverse real\-world conditions, FeLiX ensures streaming applications remain in sync with the most recent user interactions\.

††conference:; ;## 1\.Introduction

Federated Learning \(FL\) enables training shared models across large populations of user devices without collecting the raw data centrally\. This paradigm has unlocked machine learning on private, on\-device interaction logs that were previously inaccessible to centralized trainers\(McMahanet al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib28); Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3); Kairouzet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib16)\)\. Such privacy\-preserving decentralization is now critical for various production applications, including personalized recommenders, feed\-ranking, and session\-aware input prediction\. FL has been deployed for mobile keyboard and language prediction\(Hardet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib12); Chenet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib6); Xuet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib49)\), privacy\-preserving healthcare analytics\(Brisimiet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib4); Xuet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib48); Nguyenet al\.,[2022a](https://arxiv.org/html/2607.06979#bib.bib33)\), and large\-scale model personalization\(Yanget al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib50); Xuet al\.,[2024](https://arxiv.org/html/2607.06979#bib.bib56)\), establishing it as the de facto approach for privacy\-sensitive collaborative training across diverse domains\. Historically, these deployments focused on batched, multi\-day refreshes where modest delays between data collection and model updates were acceptable\.

Contemporary on\-device applications, however, increasingly require*fresh*models that adapt on hourly timescales\. User interaction streams are volatile: viral content, news events, promotional campaigns, and short\-lived user intents can shift predictive distributions rapidly\. When model refresh intervals lag behind these shifts, predictive relevance degrades and key application metrics such as click\-through rates and downstream conversions suffer\(Matamet al\.,[2024](https://arxiv.org/html/2607.06979#bib.bib58)\)\. Meeting these goals demands FL systems that minimize*time\-to\-target accuracy*on live streams while operating at production scale\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x1.png)Figure 1\.Existing FL systems stall, mis\-select, or accumulate staleness under transient availability and heterogeneous streaming data, whereas FeLiX continuously trains and reaches target accuracy without trace knowledge through adaptive, low\-overhead orchestration\.Transitioning from slow and batched to agile and streaming FL is difficult because near\-real\-time updates break the core assumptions of existing FL systems\. We highlight three interlocking constraints that render naive extensions of current architectures ineffective:

#### \(1\) Transient client availability\.

Mobile and edge devices are intermittently reachable due to battery, network, and user behavior\. Availability fluctuates at minute\-level granularity and exhibits heavy churn\([M\-Lab,](https://arxiv.org/html/2607.06979#bib.bib30)\)\. As shown in\(Garget al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib54)\), existing mitigations generally fail in three ways: \(a\)*Over\-selection*, where requesting excess clients to participate in each round wastes device compute and bandwidth while increasing server\-side update variance; \(b\)*blocking synchrony*, which converts per\-round latencies from seconds to minutes when aggregation goals are not met; and \(c\)*coarse periodic probing*, which either misses short\-lived availability windows of useful clients or incurs high heartbeat overhead to maintain up\-to\-date status\. These approaches trade away either time\-to\-accuracy or communication budgets, making them unsuitable for large\-scale FL deployments operating with thousands of clients per round\. Approaches that target the statistical variance from partial participation\(Jhunjhunwalaet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib15)\)or study large\-cohort selection effects\(Charleset al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib5)\)improve efficiency but still assume a predictable pool of available clients and do not address minute\-level churn\.

#### \(2\) Evolving client utility and heterogeneity\.

Clients differ not only in their hardware capabilities \(compute speed, memory, network\), but also in the*statistical value*of their recent data\. We define*client utility*as a time\-varying quantity combining data informativeness for the live distribution with the client’s expected compute latency\. Existing selection algorithms often ignore these dynamics\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32); Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3); Nishio and Yonetani,[2019](https://arxiv.org/html/2607.06979#bib.bib34)\), while newer ranking methods rely on the ”oracular” knowledge of availability, which is impractical in deployment\. Not just that, they don’t account for the shifting data distributions of streaming tasks\(Laiet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib19); Abdelmoniemet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib1); Yeet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib57)\)\. Selectors that rank clients using utility estimates derived from infrequent probes or historical traces systematically mis\-rank participants, as these signals quickly become stale and introduce bias that can outweigh their intended benefits\. For example, it may over\-select fast devices with irrelevant data while neglecting slow devices with fresh, informative signals\. Such techniques either require non\-existent oracular deployment traces, coarse\-grained and often stale utility estimates, or frequent probing that incurs prohibitive overhead\. As a result, they suffer rapid degradation in time\-to\-accuracy with shifts in utility\.

#### \(3\) Model freshness vs\. delayed updates\.

In production tasks, the strongest training signal \(the ground\-truth label\) often arrives with some delay; for instance, a recommendation’s conversion may be observed hours after the interaction\. This creates a fundamental trade\-off: updating immediately with proxy feedback maximizes freshness but introduces noise, while waiting for full feedback improves label quality at the cost of staleness\. Existing strategies—like buffered asynchronous aggregation\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32)\)or staleness\-weighting schemes\(Xieet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib47); Rodio and Neglia,[2024](https://arxiv.org/html/2607.06979#bib.bib37); Zhouet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib53)\)—force a choice between convergence speed and statistical robustness\. Incorrect aggregation can destabilize the training process, inflating the wall\-clock time required to reach target accuracy or discarding valuable, though delayed, signals\.

Taken together, these constraints explain why existing synchronous and asynchronous FL systems fail to achieve reasonable time\-to\-target accuracy in streaming settings, at production scale as shown in Fig\.[1](https://arxiv.org/html/2607.06979#S1.F1)\. Synchronous schemes stall or over\-select; asynchronous schemes avoid blocking but accumulate staleness that degrades convergence\(Xieet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib47); Lianet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib25); Liet al\.,[2019b](https://arxiv.org/html/2607.06979#bib.bib21)\); assumed oracular knowledge of availability or heavy\-weight predictors are not tractable; and prohibitive communication costs of frequent probes derail performance\. Empirical studies \(see §[2](https://arxiv.org/html/2607.06979#S2)and Fig\.[4](https://arxiv.org/html/2607.06979#S2.F4)\) show that even modest unavailability or data heterogeneity can worsen the model adaptation time as the complexity of the deployment shifts to hardened production settings\. Not just that, it can substantially degrade performance, even to the point of non convergence, as the unavailability and heterogeneity increase\.

In this work, we frame streaming FL as a constrained optimization problem:*minimize time\-to\-target accuracy on a live interaction stream subject to transient availability, evolving per\-client utility, frequent update delays, and bounded communication overhead\.*This objective focuses our design on policies that treat availability and utility as low\-latency control inputs while ensuring scalability across massive populations, without assuming oracular knowledge of client behaviour\.

We presentFeLiX, a redesigned FL orchestration framework that directly optimizestime\-to\-target accuracyin streaming production settings\. FeLiX treats availability as an evolving signal and couples inexpensive freshness checks with selection logic to optimize convergence\. Our core primitives are:

- ∙\\bulletStreaming\-aware availability tiers:FeLiX organizes clients into dynamic readiness tiers based on lightweight signals \(battery, connectivity\)\. This leverages a client\-server design that minimizes network overhead while ensuring the server possesses high\-fidelity information on client capabilities within tight refresh windows\.
- ∙\\bulletFresh\-utility based selection:We introduce a dual\-tier approach where an*evaluation tier*performs inexpensive forward passes to estimate data informativeness\. This is fused with compute speed to prioritize clients that are both hardware\-performant and reflect the most relevant recent distribution shifts\.
- ∙\\bulletInformativeness\-aware, delay\-robust aggregation:FeLiX employs weights that balance update informativeness with model\-age corrections\. This allows the system to safely incorporate late, high\-value updates with full feedback, ensuring the global model remains robust without being stalled by the long\-tail latencies of the straggler or long unavailable clients\.

We conduct an exhaustive evaluation of FeLiX using real\-world MobiPerf traces and multi\-modal datasets including CIFAR\-10\(Krizhevsky,[2009](https://arxiv.org/html/2607.06979#bib.bib18)\)and Google Speech Commands V2\(Warden,[2018](https://arxiv.org/html/2607.06979#bib.bib40)\)\. We demonstrate that FeLiX achieves a2\.37×2\.37\\timesreduction in time\-to\-target accuracy compared to recent Synchronous and Asynchronous FL baselines, while limiting communication overhead and preserving the predictive power of fresh models\.

## 2\.Background and Motivation

![Refer to caption](https://arxiv.org/html/2607.06979v1/x2.png)Figure 2\.Cross\-device trainers exhibit 2–120 s execution times driven by hardware, data, and WAN variability\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32)\)\. While stragglers delay updates through slow execution, transient device unavailability pauses participation entirely, highlighting a key systems challenge beyond conventional straggler mitigation\.![Refer to caption](https://arxiv.org/html/2607.06979v1/x3.png)Figure 3\.Overview of cross\-device AsyncFL training architecture\. To meet theconcurrency level, clients are asynchronously selected at random to train locally and communicate updates to the server\. The server aggregates the updates to get the new global model wheneveragg\-goalnumber of clients have sent updates\.### 2\.1\.FL Primer and Client Availability

Asynchronous FL\.Federated Learning \(FL\) trains a shared model across many decentralized, privacy\-sensitive clients by keeping raw data local: the server broadcasts global weights, clients perform local training on\-device, and the server aggregates returned updates\(McMahanet al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib28); Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3)\)\. Two execution regimes dominate cross\-device deployments\. In*synchronous*FL \(SyncFL\) the server advances in rounds after collecting an*agg\-goal*number of client updates; in*asynchronous*FL \(AsyncFL\) the server incorporates updates as they arrive and does not block on stragglers\. SyncFL offers conceptual simplicity and bounded staleness but is vulnerable to delays caused by a few slow or unavailable clients; AsyncFL trades that blocking for continuous progress at the cost of needing principled staleness handling\. Convergence analyses of FedAvg under non\-IID data\(Liet al\.,[2019b](https://arxiv.org/html/2607.06979#bib.bib21); Wanget al\.,[2020b](https://arxiv.org/html/2607.06979#bib.bib44)\)reveal that data heterogeneity exacerbates gradient divergence across clients, while adaptive federated optimizers\(Reddiet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib36)\)partially compensate but leave the availability challenge unaddressed\.

AsyncFL emerged to address the wide runtime variability observed in practice: theoretical analyses of asynchronous decentralized SGD\(Lianet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib25)\)and asynchronous federated optimization\(Xieet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib47)\)confirm that async updates converge under mild staleness bounds but can degrade sharply when updates are very stale or derived from strongly non\-IID local data\. mobile devices exhibit long\-tailed training runtimes driven by differences in compute, background load, and network latency as shown in Fig\.[2](https://arxiv.org/html/2607.06979#S2.F2)\. Together, device heterogeneity and application\-driven data generation produce a rapidly evolving trainer runtime distribution\. This variability forces system designers to confront three co\-occurring concerns: \(i\) which clients should the server select at any moment, \(ii\) how to cheaply detect that a client is actually ready to train, and \(iii\) how to incorporate late or intermittent updates without destabilizing learning\. A compact AsyncFL control loop \(selector, weight dispatcher, client training, aggregator/buffer\) exposes these decision points; we illustrate the flow in Fig\.[3](https://arxiv.org/html/2607.06979#S2.F3)\. Clients register themselves with the FL\-server1\. The control\-plane maintains these connections and forwards the client\-id\(s\) to the selector2\. The selector is tasked with maintaining a desired training concurrency \(i\.e\., number of parallely training clients\) throughout the process\. Whenever the training count falls below the concurrency level \(i\.e\., clients return updates\)\. The selector uses its algorithm to return the next client\(s\) to train4so as to meet the concurrency level\. These selected client ID\(s\) are forwarded to the aggregator\.5The weight dispatcher sends the latest server model weights \(W\) to the selected clients\. If the client is available to train, it begins training using fresh global weights \(W\) and data from the applications’ local data\-store\. Upon completion, it returns weight changes w\.r\.t W as updates \(Δ​W\\Delta W\)6to the aggregator\. If the client wasn’t initially available to train or is interrupted while training, the client waits until it becomes available next\. At the FL server, the model updates received from clients are aggregated and put into a temporary buffer\. Once agg\-goal number of updates in the buffer are aggregated, the server model version changes and the buffer is emptied7\. This FL training process continues until convergence\.

Evolving runtime availability\.While foundational FL research and early system prototypes often assumed highly available clients operating in stable, conducive environments, production deployments reveal that this assumption is fundamentally flawed\. In practice, ignoring the reality of intermittent participation degrades performance significantly, inflating time\-to\-accuracy and wasting system resources\. We define*availability*not merely as a device being powered on, but as a multi\-dimensional state meeting strict system\-level and application\-level filters, including WiFi\-only connectivity, sufficient battery levels, and OS\-mandated idle constraints\. Consequently,*unavailability*is the norm; production traces from the Google FL System\(Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3)\), the PAPAYA analytics platform\(Srinivaset al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib55)\), LinkedIn’s FLINT\(Wanget al\.,[2023a](https://arxiv.org/html/2607.06979#bib.bib45)\), and FedScale/MobiPerf\(Laiet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib20);[M\-Lab,](https://arxiv.org/html/2607.06979#bib.bib30)\)report mean client availability ranging from as low as15%to roughly50%of the total population\. In production,unavailability is therefore the norm rather than the exception\.This participation is inherently*transient*, characterized by short\-lived ready windows whose durations are often comparable to the training round itself\. Across different geographies and applications, these dynamics manifest in large peak\-to\-trough swings\. For instance, diurnal effects can cause availability to fluctuate by5×5\\timeswithin a single day, with minima dropping to10%during active usage hours and peaking at80%when devices are idle and charging\. At the system level, these trends create significant orchestration challenges: in the Google FL system, nearly22%of updates arrive too late for aggregation and are rejected, while another2%are interrupted mid\-computation\. Restrictive participation criteria, while necessary for user experience, further contract the eligible pool, sometimes as low as22%of the total devices as shown in MobiPerf\([M\-Lab,](https://arxiv.org/html/2607.06979#bib.bib30)\)\. This exposing a sharp trade\-off between model fairness and system throughput\. These bursty and unpredictable availability patterns mean that naive selection strategies either over\-select to mask dropouts \(increasing variance\) or stall rounds waiting for stragglers, both of which are untenable for streaming applications requiring hourly refreshes\. Prior measurements\(Garget al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib54)\)directly quantify this: even under moderate unavailability \(<<50%\), time\-to\-target accuracy degrades sharply, confirming that availability must be treated as a first\-class orchestration signal rather than a background metric\.

AsyncFL alone cannot fix unavailability\.These runtime and availability characteristics translate into three practical operational effects that motivated AsyncFL and that now motivate streaming\-aware controls\. First, servers often resort to*over\-selection*\(invite many more candidates than needed\) to probabilistically meet an agg\-goal; this wastes device CPU, uplink/downlink network bandwidth and increases variance in server\-side latency\. Second, a client’s local training time may exceed the mean aggregator interval, increasing the chances of interruptions, rejected updates, or partial work\. A natural mitigation is to checkpoint local training state so that a client can resume after an interruption: an approach well\-studied in distributed DNN training\(Mohanet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib31); Eisenmanet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib8); Guptaet al\.,[2024](https://arxiv.org/html/2607.06979#bib.bib11); Wanget al\.,[2023b](https://arxiv.org/html/2607.06979#bib.bib46)\)\. However, in the FL context, checkpointing only preserves progress on the*client*; the client still cannot return any update until device conditions recover, and the global model advances in the meantime, rendering the saved gradients stale on return\. Checkpointing therefore does not close the availability gap\. It defers the problem rather than solving it\. Third, restrictive eligibility filters shrink the effective population and risk selection bias\. Together, these effects show that availability and runtime behavior are not background metrics but*low\-latency control inputs*that selection and aggregation logic must use in order to optimize wall\-clock progress and maintain model quality\.

Finally, while AsyncFL and its improvements such as update buffering reduce blocking, they do not by themselves solve the coupled problems of rapid availability churn, evolving per\-client statistical value, and bounded communication costs\. For example, buffered AsyncFL reduces immediate stalls but requires careful eviction/weighting policies to prevent stale updates from hurting convergence\. Later sections discuss these algorithmic and systems tensions in detail and show why treating readiness and freshness as first\-class, lightweight signals is essential for streaming FL\.

### 2\.2\.FL Orchestration Challenges

Brittle selection algorithms\.Many FL selection strategies attempt to balance synchronization and participation, but practical deployments expose a harsh trade\-off between update staleness and system stalls\. Synchronous FL variants avoid staleness by enforcing global rounds but are highly vulnerable to*stalls*: when availability is intermittent, SyncFL blocks on stragglers or turns to heavy over\-selection, converting per\-round latencies from seconds into minutes and dramatically increasing communication and cost\. Asynchronous and buffered schemes relax blocking by accepting updates computed on older model states \(or by aggregating along a buffer\), which improves throughput\. However, if stale updates are naively aggregated, they will destabilize convergence\. Conversely, discarding late updates sacrifices the valuable statistical signal carried by the slower or transiently available clients\. Recent selector\-based approaches that prioritize high\-utility clients \(for example, OORT and REFL selectors\) or use learned predictors to estimate client utility aim to trade off speed and signal by favoring fast, high\-utility workers\. In practice, these methods typically depend on availability signals or historical traces to estimate utility\. Under bursty availability and rapid population/data shifts those utility estimates age quickly leading to repeated mis\-ranking\. For example, such selecots would over\-select fast but irrelevant devices and neglect informative but ephemeral clients\. These limitations have motivated hybrid approaches like buffered asynchronous aggregation that attempt to retain long\-tail information while reducing stalls, but the tension between timeliness, stability, and privacy\-compatible aggregation remains unresolved\. Variance\-reduction techniques for partial participation\(Jhunjhunwalaet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib15)\)and large\-cohort selection\(Charleset al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib5)\)target statistical stability but still assume a stable, predictable client pool\. Staleness\-aware schemes\(Rodio and Neglia,[2024](https://arxiv.org/html/2607.06979#bib.bib37); Zhouet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib53)\)weight or discount late updates based on model\-version gap, but do not resolve the challenge of detecting and exploiting short availability windows in real time\.

Coarse systems and instrumentation\.Production stacks provide several primitives for large\-scale FL, but their availability signals tend to be either too coarse to support fine\-grained orchestration or too heavyweight to scale\. Such platforms use techniques like client check\-ins, tokens, and over\-selection heuristics to mask dropout and reduce orchestration complexity with client availabilty\. Yet such protocols are explicitly designed around coarse\-grained and slower tradeoffs like accept/reject tokens, windowed selection rather than continuous, low\-latency availability views\. This design choice simplifies robustness but also means a nontrivial fraction of potential updates are delayed or rejected in practice\. At the other extreme, tooling that instruments devices more deeply like pre\-deployment measurement, capability profiling, or continuous heartbeat reporting, can provide the fine\-grained, near\-real\-time availability signals orchestration needs, but at production scale these signals increase reporting overhead, consume device energy, and raise privacy and operational concerns\. Benchmark and integration frameworks make clear how availability and distribution shift in deployment\. They also let researchers replay realistic, time\-varying traces for evaluation\. However, by definition these offline traces cannot supply the compact, cross\-application, real\-time view an orchestrator would need for streaming, hourly refresh tasks\. In short, production systems either expose high\-fidelity signals that are too heavy to maintain continuously, or coarse signals that force servers to choose between blocking \(stalling progress\) and proceeding blindly \(accumulating staleness\)\. Representative system and benchmarking efforts that highlight these tradeoffs include Google FLSys\(Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3)\)and the PAPAYA analytics stack\(Srinivaset al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib55)\), which describe token/check\-in and rejection mechanics for large\-scale mobile FL; the benchmark suite FedScale\(Laiet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib20)\); and the FL integration tooling FLINT\(Wanget al\.,[2023a](https://arxiv.org/html/2607.06979#bib.bib45)\), which emphasizes on\-device measurement and pre\-deployment instrumentation\. Research frameworks such as Flower\(Beutelet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib2)\)and FedML\(Heet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib13)\)enable flexible experimentation but are designed for controlled settings rather than production\-scale streaming deployments with bursty, minute\-level availability dynamics\.

These algorithmic and system\-level gaps are particularly acute forstreaming applications, where the requirement for hourly refreshes clashes with high data heterogeneity and delayed ground\-truth feedback\. In production tasks like recommendation or ad\-targeting, the strongest training signal \(the label\) often arrives hours after the initial interaction\. Existing systems are*unable*to navigate this: they must either update immediately using noisy proxy feedback to maintain freshness, or wait for full labels and suffer extreme model staleness\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x4.png)Figure 4\.Performance gaps in FL widen as we move from ideal conditions \(L1\) to realistic deployments \(L2, L4\)\. Data heterogeneity and client unavailability increase stalls and inefficiency, and methods relying on perfect foresight \(L3\) break down without it \(L4\); closing the gap requires real\-time, low\-cost readiness signals that capture high\-value client updates without oracular knowledge \(L5\)\.
### 2\.3\.Model Adaptation Gap: Oracular vs\. Reality

Opportunity Gap\.To quantify the performance gap with existing FL approaches, we move from an idealized regime to progressively more realistic deployment settings in Fig\.[4](https://arxiv.org/html/2607.06979#S2.F4), exposing the technical reasons behind the widening performance gap\. While an idealized baseline of 100% availability and homogeneous data in Line 1 i\.e\. L1 ensures minimal time\-to\-target accuracy, the introduction of data heterogeneity \(L2\) increases gradient variance, increasing the time\-to\-accuracy even under 100% participation\. The performance is expected to degrade sharply with realistic client behaviour, for instance if client availability drops to 50%\. Here rounds will stall and existing selectors that fail to capture enough informative updates within tight refresh time windows, will suffer\. However, with oracular or trace\-provided client information, despite 50% unavailability, L3 does not drop in its performance significanlty compared to L2\. The most significant performance collapse occurs when we withdraw the oracular foresight\. Many state\-of\-the\-art methods like OORT and REFL rely on retrospective traces or trace\-derived availability predictors to estimate future utility \(L4\)\. Without perfect future knowledge, these systems struggle with low availability, repeatedly stalling during rounds\. Even with over\-selection, they fail to capture the transiently available clients that carry high\-value for model training\. Bridging this gap \(L5\) requires an orchestrator that achieves near\-oracular performance not through foresight, but by exploiting low\-cost, real\-time readiness signals to harvest the high\-value updates as they appear\.

Design Primitives for Streaming FL\.Closing the empirical gap between Line 4 and Line 5 requires a shift in FL orchestration infrastructure: availability and freshness must be treated as*operational control inputs*rather than secondary instrumentation\. To maintain metrics like CTR and conversion in volatile environments, a streaming\-aware FL system must satisfy four design pillars\. First, it requireslow\-latency readiness checksof clients that expose not only availability but also current data informativeness without saturating network bandwidth\. Second, it must employrapid, utility\-aware selectionthat fuses a client’s recent data utility with its hardware speed capability to prioritize contributions that most aggressively reduce time\-to\-target accuracy\. Third, it needsdelay\-robust aggregation semanticsto incorporate late, high\-quality updates containing ground\-truth feedback, which may arrive hours after the initial interaction, without allowing staleness to destabilize the model\. Finally, the system must maintainexplicit communication boundsto ensure that increased visibility of the client population does not compromise device battery or server scalability\.

Together, these design primitives frame streaming FL as a constrained optimization problem:*minimize time\-to\-target accuracy on a live interaction stream subject to transient availability, evolving utility, frequent update delays, and bounded communication\.*This formulation serves as the blueprint for the FeLiX primitives presented in §[3](https://arxiv.org/html/2607.06979#S3)\.

## 3\.FeLiX System

### 3\.1\.Gaps to handle widespread unavailability

The discussion above has a recurring pattern: existing FL systems and algorithms either \(A\) lack low\-cost, near\-real\-time availability mechanisms, \(B\) rely on historic traces or trained predictors that cannot be re\-deployed across applications, or \(C\) handle staleness with heuristics that aggresively discard useful updates\. This produces three concrete, non\-trivial technical problems that this paper addresses:

- ∙\\bulletCompact client availability summaries\.How can the server obtain a low\-cost, privacy\-preserving, actionable view of*currently*active clients under the application\-defined participation criteria? Existing tokens/heartbeats are either too coarse \(low utilization\) or too costly \(frequent reporting\); oracle/trace assumptions are unrealistic in new deployments\(Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3); Wanget al\.,[2023a](https://arxiv.org/html/2607.06979#bib.bib45)\)\.
- ∙\\bulletFresh and evolving client utility estimates\.How can the system efficiently refresh inactive clients’ utilities so that selectors use up\-to\-date state? Our insight is that utilities can be obtained without full training and using lightweight evaluations or probing, but integrating the probes into selection while limiting communication is challenging\(Laiet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib19)\)\.
- ∙\\bulletUtility\-aware and robust aggregation\.How to combine updates with varying staleness at the server so that on\-and\-off but high\-value clients are not excluded, while preserving convergence and avoiding undue noise from stale updates\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32); Abdelmoniemet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib1)\)\.

Motivated by these insigths, we design FeLiX, a system for robust federated learning in environments with high client unavailability and heterogeneity\. FeLiX is the first system to introduce and leverage the concept oftiered client pools\. Clients dynamically move among the pools based on their evolving state \(battery, network, data\) and capabilities \(compute load, speed\) over the long\-running FL training jobs\. The system can opportunistically select best suited clients for model training, evaluation of their utility only, or neither, based on their runtime availability and resource constraints\. This approach aims to maximize each participating client’s contribution to the global model with the goal of minimizing time\-to\-accuracy and communication costs\. FeLiX achieves these goals by augmenting the FL paradigm with three mechanisms, illustrated in Fig\.[5](https://arxiv.org/html/2607.06979#S3.F5)\. First isATierTrack, a lightweight, client\-driven protocol to indicate each client’s change of tier to the control\-plane\.BSecond,TierSelectis a two\-path selection mechanism: a TrainSelector that prioritizes clients to maximize expected learning each round and an EvalSelector that proactively probes stale or unobserved clients to refresh their utility estimates and surface occasionally high\-value but slower devices\. Finally,CTierFusejudiciously balances each update’s quality with their staleness\. The three mechanisms work in cohesion towards the goals, especially in the presence of high client unavailability and heterogeneity\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x5.png)Figure 5\.FeLiXarchitecture for FL\.TierTrackdynamically tiers clients by training capability,TierSelectselects and assigns tasks using tier, data utility, and participation history, andTierFuseweights updates by staleness and expected learning contribution\.Algorithm 1TierTrack Algorithm1:Input:

CC: set of all clients

2:Output:real\-time client status

3:Initialize a data structure

BBto track client availability

4:whiletruedo

5:if

ci∈Cc\_\{i\}\\in Csends a state updatethen

6:ifstate =AVL\_TRAINthen

7:set

B​\[i\]←2B\[i\]\\leftarrow 2
8:elseifstate =AVL\_EVALthen

9:set

B​\[i\]←1B\[i\]\\leftarrow 1
10:elseifstate =UN\_AVLthen

11:set

B​\[i\]←0B\[i\]\\leftarrow 0
12:if

cic\_\{i\}is currently trainingthen

13:checkpoint model for

cic\_\{i\}
14:endif

15:cleanup

cic\_\{i\}
16:endif

17:endif

18:endwhile

### 3\.2\.Streaming\-aware availability tiers

A systematic solution is required to bridge the gap between the fluctuating and low client availability\([M\-Lab,](https://arxiv.org/html/2607.06979#bib.bib30); Wanget al\.,[2023a](https://arxiv.org/html/2607.06979#bib.bib45); Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3)\)on one hand and the lack of near\-real\-time availability tracking in existing systems\. As described previously, fresh information about client state is needed to avoid training stalls and to select the high utility clients\. Both combined help improve the learning progress\. Since the control\-plane directly interfaces with the clients, it is most suited to relay latest client information to the selector\. However, for the mechanism to be effective, it needs to bereal\-time,accurateandlightweight, while scaling to thousands of clients\.

TierTrack\.Our approach, described in Algorithm[1](https://arxiv.org/html/2607.06979#alg1), segregates clients into one of the three client pools based on their capability: \(i\)AVL\_TRAIN: available to train and evaluate, \(ii\)AVL\_EVAL: available only to evaluate, and \(iii\)UN\_AVL: unavailable to participate\. While different applications can define these states differently, the clients would indicate their state to the control plane based on the criteria and their runtime conditions \(compute load, battery status, connectivity, etc\)\. For example, since training is computationally intensive, a client could be classified asAVL\_TRAINonly when it is connected to a charger and on Wi\-Fi \(e\.g\. OORT, G\-FL\)\. However, to tap into under\-utilized clients due to this restrictive criteria, we categorize clients intoAVL\_EVALstate even when they are not connected to a charger, but their battery exceeds a certain threshold, since evaluation is computationally cheaper\.

Instead of periodic heartbeats of current state which is communication heavy, redundant, and unscalable to thousands of clients, the clients proactively notify the control plane whenever their state changes1\( Fig\.[5](https://arxiv.org/html/2607.06979#S3.F5)\)\. To guard against stale or incorrect state information \(e\.g\., when a client silently drops due to network or device failure\), FeLiX employs a lightweight check: Instead of separate messages or a regular heartbeat, it starts a 90\-second timer whenever the aggregator assigns a task; if no response arrives within this window, the client is markedUN\_AVL\. If the client becomesUN\_AVLduring training, it can resume from its last checkpoint once it transitions back toAVL\_TRAIN\(Guptaet al\.,[2024](https://arxiv.org/html/2607.06979#bib.bib11); Eisenmanet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib8); Mohanet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib31)\)\.

Client state updates are tracked in a simple map data structure that2the control plane forwards to the selector\. TierTrack maintains additional metadata for each client to recognize clients who rejoin the cohort during the same training round and preclude them from participating in that round\. This is done to prevent the selector from sampling the same client more than once in a single round, ensuring fairness\(McMahanet al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib28); Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32)\)\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x6.png)Figure 6\.TierSelect: lightweight forward\-pass evaluations refresh stale utilities, the train selector uses these fresh utilities to reduce selection error, and the two together accelerate convergence\.Algorithm 2TierSelect Algorithm1:Global Vars:

CTC\_\{T\}: clients available for train;

CEC\_\{E\}: clients available for eval, but not train;

kt​r​a​i​nk\_\{train\}: train concurrency;

Kt​r​a​i​nK\_\{train\}: concurrency level;

ke​v​a​lk\_\{eval\}: number of evaluations;

Ke​v​a​lK\_\{eval\}: per round evaluation goal

2:Outputs:

STS\_\{T\}: client selected for train;

SES\_\{E\}: client selected for eval

3:procedure𝚃𝚒𝚎𝚛𝚂𝚎𝚕𝚎𝚌𝚝\\mathtt\{TierSelect\}\(Global Vars\)

4:while

kt​r​a​i​n<Kt​r​a​i​nk\_\{train\}<K\_\{train\}do⊳\\trianglerightasync

5:

ST←𝚝𝚛𝚊𝚒𝚗​\_​𝚜𝚎𝚕𝚎𝚌𝚝𝚘𝚛​\(CT,kt​r​a​i​n\)S\_\{T\}\\leftarrow\\mathtt\{train\\\_selector\}\(C\_\{T\},k\_\{train\}\)
6:

kt​r​a​i​n←kt​r​a​i​n\+1k\_\{train\}\\leftarrow k\_\{train\}\+1
7:return

STS\_\{T\}
8:endwhile

9:while

ke​v​a​l<Ke​v​a​lk\_\{eval\}<K\_\{eval\}do⊳\\trianglerightasync

10:

SE←𝚎𝚟𝚊𝚕​\_​𝚜𝚎𝚕𝚎𝚌𝚝𝚘𝚛​\(CE,CT\)S\_\{E\}\\leftarrow\\mathtt\{eval\\\_selector\}\(C\_\{E\},C\_\{T\}\)
11:

ke​v​a​l←ke​v​a​l\+1k\_\{eval\}\\leftarrow k\_\{eval\}\+1
12:return

SES\_\{E\}
13:endwhile

14:endprocedure

15:procedure𝚝𝚛𝚊𝚒𝚗​\_​𝚜𝚎𝚕𝚎𝚌𝚝𝚘𝚛\\mathtt\{train\\\_selector\}\(

CT,kt​r​a​i​nC\_\{T\},k\_\{train\}\)

16:whiletruedo⊳\\trianglerightasync

17:ifrecv update from client

ci∈CTc\_\{i\}\\in C\_\{T\}then

18:

kt​r​a​i​n←kt​r​a​i​n−1k\_\{train\}\\leftarrow k\_\{train\}\-1
19:fetch

𝑢𝑡𝑖𝑙𝑖𝑡𝑦\\mathit\{utility\}of

cic\_\{i\}
20:update

𝑢𝑡𝑖𝑙𝑖𝑡𝑦\\mathit\{utility\}of

cic\_\{i\}in

CTC\_\{T\}
21:sort

CTC\_\{T\}
22:endif

23:endwhile

24:whiletruedo⊳\\trianglerightasync

25:return

CT​\[0\]C\_\{T\}\[0\]
26:endwhile

27:endprocedure

28:procedure𝚎𝚟𝚊𝚕​\_​𝚜𝚎𝚕𝚎𝚌𝚝𝚘𝚛\\mathtt\{eval\\\_selector\}\(

CE,CTC\_\{E\},C\_\{T\}\)

29:whiletruedo⊳\\trianglerightasync

30:

CA←CE\+CTC\_\{A\}\\leftarrow C\_\{E\}\+C\_\{T\}
31:ifrecv update from client

ci∈CAc\_\{i\}\\in C\_\{A\}then

32:fetch

𝑙𝑎𝑠𝑡​\_​𝑢𝑡𝑖𝑙​\_​𝑟𝑜𝑢𝑛𝑑\\mathit\{last\\\_util\\\_round\}of

cic\_\{i\}
33:update

𝑙𝑎𝑠𝑡​\_​𝑢𝑡𝑖𝑙​\_​𝑟𝑜𝑢𝑛𝑑\\mathit\{last\\\_util\\\_round\}of

cic\_\{i\}in

CAC\_\{A\}
34:sort

CAC\_\{A\}
35:endif

36:endwhile

37:whiletruedo⊳\\trianglerightasync

38:return

CE​\[0\]C\_\{E\}\[0\]
39:endwhile

40:endprocedure

### 3\.3\.Tiered Client Selection with Fresh Utilities

Instead of picking random client, recent selectors recognize that*not all clients contribute equally*to global progress\. A client’s contribution depends on \(i\) the richness of its local data \(statistical utility\)\(Chenet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib6); Penget al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib35); Wang and Joshi,[2019](https://arxiv.org/html/2607.06979#bib.bib42); Liet al\.,[2020b](https://arxiv.org/html/2607.06979#bib.bib23)\)and \(ii\) the speed with which it returns updates \(system utility\)\(Laiet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib19); Hubaet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib14)\)\. A combined*client utility*\(for example, the product of statistical and system terms\) is typically estimated after a client participates in training and then used to guide future selections\.

However, in large, realistic deployments only a small subset of clients is available at any time and clients are not chosen every round\. Consequently, stored utilities for non\-participating clients become stale and no longer reflect their current potential\. Stale utilities induce selection bias\. Frequently high\-utility clients are repeatedly favored while other, potentially useful clients are neglected, slowing convergence and harming fairness across clients\.

Existing approaches offer only partial remedies\. OORT inflates utilities for idle clients to encourage exploration, but this often overestimates inactive clients’ contributions\. REFL trains availability predictors and prioritizes less\-available clients, but these models must be retrained for every application, remain imperfect despite local adaptation, and mis\-select clients during early deployment\. As a result, both approaches have limited applicability\.

FeLiX addresses stale utilities efficiently by proactively collecting fresh utility measurements from a dedicated, lightweighteval tier\. Rather than rely on inference or delayed training replies, FeLiX obtains up\-to\-date statistical utilities via short forward\-pass evaluations onAVL\_EVALclients and feeds these fresh values into selection decisions\.

At the core of TierSelect is a compactClientMapthat tracks each client’s latest statistical utility, system metrics, andlast\_utility\_round\. TierTrack updates pool memberships, while TierSelect runs two concurrent selectors: a high\-frequencyeval\_selectorand a lower\-frequencytrain\_selector\(Fig\.[6](https://arxiv.org/html/2607.06979#S3.F6)\)\. The eval selector sends lightweight forward\-pass evaluations to clients inAVL\_TRAINandAVL\_EVALprioritized by most stale first; these complete up to20×20\\timesfaster than full training\(Xuet al\.,[2024](https://arxiv.org/html/2607.06979#bib.bib56)\), and their returned utilities are written to the ClientMap\. The train selector then uses these refreshed utilities to pick top\-utility trainers at the set concurrency level\. Trainers perform full local training and return model updates and utilities, closing the freshness feedback loop\. Sincelast\_utility\_roundis updated after both evals and training, the ClientMap always holds the freshest client observations\.

The eval selector is deliberately rate\-limited \(assign at mosteeeval tasks per round\) to avoid stealing training capacity from available clients\. This balances freshness and resource contention: frequent evals refresh utilities but, if unconstrained, could reduce available trainer choices \(during eval task execution\)\. Eachevalalso adds to the communication cost\. However, timely fresh utilities substantially reduces selection error and more than amortizes the added eval traffic\. For efficiency, selector logic operates only on the currently available sets \(AVL\_TRAIN,AVL\_EVAL\) reported by TierTrack; this keeps rank computations small and ensures only eligible clients are chosen\. The result is a lightweight, fast, and scalable selection strategy that trades off system and data heterogeneity by leveraging fresh client utilities amid high client inactivity and heterogeneity\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x7.png)Figure 7\.TierFuse gives weight based on the staleness and statistical utility of the updates, as both are important to gauge the quality of the update for the global model\.
### 3\.4\.Utility\-aware, delay\-robust aggregation

Round\-based staleness, the gap between the server model version when an update arrives and the version the client trained on is simple to compute and widely used in SyncFL and AsyncFL\. However, staleness alone conflates two causes of age: \(i\) client unavailability and \(ii\) slow computation or communication\. Neither indicates whether an update is still informative\. Prior work often discounts updates solely by staleness, discarding delayed yet useful ones\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32); Xieet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib47)\)\. FeLiX distinguishes these cases by adding a statistical signal: the*utility*of an update, derived from the client’s local loss\. A high loss implies the model is poorly aligned with that client’s data and the update remains valuable; a low loss suggests the update can be safely down\-weighted by age\.

TierFuse encodes the tradeoff between update age and informativeness\. Each updateuiu\_\{i\}carries its stalenessTiT\_\{i\}and local lossLiL\_\{i\}\. Two basis functions: staleness decayα​\(T\)\\alpha\(T\)\(decreasing inTT\) and utility gainβ​\(L\)\\beta\(L\)\(increasing inLL\) are combined using a tradeoff parameterσ∈\[0,1\]\\sigma\\\!\\in\[0,1\]:

wi=σ​α​\(Ti\)\+\(1−σ\)​β​\(Li\),w\_\{i\}=\\sigma\\,\\alpha\(T\_\{i\}\)\+\(1\-\\sigma\)\\,\\beta\(L\_\{i\}\),Δ=∑iwi​ui∑iwi,θ←θ\+η​Δ\.\\Delta=\\frac\{\\sum\_\{i\}w\_\{i\}u\_\{i\}\}\{\\sum\_\{i\}w\_\{i\}\},\\qquad\\theta\\\!\\leftarrow\\\!\\theta\+\\eta\\,\\Delta\.Smooth parameterized forms provide interpretable control:

α​\(T\)=1\(1\+T\)a,β​\(L\)=min⁡\(1\.5−1\(1\+L\)b,1\)\.\\alpha\(T\)=\\frac\{1\}\{\(1\+T\)^\{a\}\},\\qquad\\beta\(L\)=\\min\\\!\\Big\(1\.5\-\\frac\{1\}\{\(1\+L\)^\{b\}\},1\\Big\)\.Hereaacontrols how quickly weight decays with age,bbcontrols how fast utility saturates, andσ\\sigmasets the balance between the two\. This design rewards delayed but informative updates \(highLL\) while still damping very old or low\-utility ones, balancing quality and stability in aggregation\.

Two safeguards make TierFuse robust in practice\. It buffers a short window of recent updates to stabilize normalization and prevent a single extreme update from skewing aggregation\. Updates older than a thresholdTmaxT\_\{\\max\}are clipped or dropped, and optional server\-side weight clipping or L2 normalization further bound any client’s influence\. These lightweight measures require no extra client computation beyond the local loss already produced during training\.

Unlike round\-based schemes \(e\.g\., REFL’s round\-aware approach\), TierFuse explicitly combines update age and statistical utility\. Staleness penalizes divergence risk, while high utility rescues delayed but valuable updates\. This yields a simple, interpretable policy suited for heterogeneous, unreliable deployments—suppressing obsolete noise without discarding late, informative updates\.

## 4\.Implementation

FeLiX is implemented as a compact set of extensions to Cisco’s Flame framework111[https://github\.com/cisco\-open/flame](https://github.com/cisco-open/flame), reusing Flame’s control plane, dispatcher, and transport stack\. It has three plugins: TierTrack monitors client activity, capability and maintains lightweight availability pools; TierSelect implements the two parallel selectors \(frequenteval selectorand less\-frequenttrain selector\) and operates on the small, available\-client view provided by TierTrack; and TierFuse is a buffering\-and\-weighting layer in the optimizer path that applies the mixed staleness/utility weights and emits normalized server updates\.

State is intentionally minimal and colocated in the control plane: a compactClientMapstores per\-client tuples such as\(stat\_utility, system\_metrics, last\_utility\_round, curr\_tier\)\. Clients piggyback their local loss and round duration on replies so selectors and the aggregator can update ClientMap without extra RPCs\. Fast evaluations are implemented as a single forward pass \(empirically upto 20X faster than a full training run\) and write back refreshed statistical utilities to ClientMap, enabling timely, low\-cost updates to selection decisions\.

Aggregation is implemented as a configurable\-size buffer plus simple element\-wise weighting and normalization\. TierFuse reads staleness and loss from the client update, computes weights and produces the server model update; these operations are cheap\. To remain agnostic to communication protocol, we extended Flame’s channel backend with the control semantics needed for availability and eval requests \(the default deployment uses MQTT\), and we keep all extra state in the control plane so that client\-side changes are minimal\.

Overall, FeLiX comprises a set of to\-be\-open\-sourced plugins to Flame to deliver TierTrack, TierSelect, TierFuse and ClientMap, all of which cause minimal runtime disruption and low overhead\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x8.png)

\(a\) Synthetic availability pools\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x9.png)

\(b\) MobiPerf real\-world trace\.

Figure 8\.Client availability traces and three\-tier pools\. The top panel shows the synthetic client availability distributions used in experiments \(high→\\rightarrow100%, 90%; medium→\\rightarrow50%\)\. The bottom panel shows the MobiPerf real\-world trace used to stress low\-availability regimes\. Client pools ofA​V​L​\_​T​R​A​I​NAVL\\\_TRAINandA​V​L​\_​E​V​A​LAVL\\\_EVALbecome especially important here\. Traces and the system drives per\-client activity of evaluation/training tasks for FL training\.StrategyTypeAvail\. knowledgeSelectionAggregationOORTSyncNoneOORTFedAvgOORT∗\\astSyncOracleOORTFedAvgOORT\+AsyncAsyncNoneOORTFedBuffOORT\+Async∗\\astAsyncOracleOORTFedBuffREFL∗\\astSyncTuned PredictorREFL IPSREFL SAAFeLiXAsyncTierTrackTierSelectTierFuseTable 1\.Overview of strategy configurations used to evaluate FeLiX against key baselines in FL\. Regular font indicates prior systems \(OORT\(Laiet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib19)\), REFL\(Abdelmoniemet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib1)\)\); italic rows are adaptations; bold row represents FeLiX\. Oracle \(∗\\ast\) denotes prior knowledge of client traces\.
## 5\.Experiment Setup

We perform the evaluation in a cross\-device FL testbed built on Flame\(Dagaet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib9)\)with MQTT\(Light,[2017](https://arxiv.org/html/2607.06979#bib.bib26)\)\. The testbed colocates the FL server \(control plane, selector, aggregator\) and an emulated population of clients on a multi\-GPU node, following prior emulation\-based FL studies \(e\.g\., FedScale\(Laiet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib20)\), OORT\(Laiet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib19)\), REFL\(Abdelmoniemet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib1)\)\)\. Experiments sweep heterogeneity along three axes: \(i\) data, \(ii\) compute / runtime, and \(iii\) availability, so the results cover a broad range of realistic operating points\. We align Dirichlet parameters, runtime distributions, and availability scenarios with prior work to enable meaningful comparisons\.

Testbed hardware and runtime emulation\.The host machine with with 8 NVIDIA A40 GPUs, 500 GB RAM, and an AMD EPYC 7513 32\-core CPU runs the FL server and up to 300 emulated clients\. Each of the clients are assigned \(i\) per\-round training delays to emulate compute and network differences, and \(ii\) data partitions for data heterogeneity\. Per\-round client durations are sampled from a broad distribution spanning≈\\approx1 to 60 s, matching the device\-speed and latency distribution reported in production\-oriented studies \(Papaya\(Hubaet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib14)\), FedBuff\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32)\)\)\.

Datasets and models\.We evaluate two modalities using two datasets:Image \(CIFAR\-10\): 60k images, 10 classes; model is a 12\-layer CNN \(≈\\approx0\.5M parameters\) andSpeech \(Google Speech Commands v2\):≈\\approx105k one\-second clips, 35 labels; model is a ResNet\-derived speech network \(≈\\approx7\.2M parameters\)\. All runs start from the same initialization and use identical configs for parity\.

Client populations, data heterogeneity, and availability\.Data heterogeneity is controlled with Dirichlet partitionsDir​\(α\)\\mathrm\{Dir\}\(\\alpha\)forα∈\{0\.1,1,10,100\}\\alpha\\in\\\{0\.1,1,10,100\\\}\(from strongly non\-IID to near\-IID\)\. To emulate real\-world FL deployments\(Yeet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib57)\), experiments below fix data heterogeneity toα=0\.1\\alpha=0\.1unless stated otherwise\. It is also the most challenging regime to stress availability and FL training\. The image task uses 300 clients; the speech task uses 100 clients\.

Availability scenarios include synthetic population\-level settings \(100%, 90%, 50%\) and a real\-world MobiPerf trace with very low, bursty participation \(∼\\sim10–22% available\)\. Figure[8](https://arxiv.org/html/2607.06979#S4.F8)visualizes the synthetic pools and the MobiPerf trace; traces determine per\-client availability across the experiment runtime\.

Baselines, selector/aggregator variants, and configuration\.We compare FeLiX against existing baseline FL \(OORT, REFL\), and also against their variants which incorporate some of FeLiX’s features: OORT \(SyncFL, unaware of availability\),OORT∗\\ast\(SyncFL \+ oracle TraceAvail\),OORT\+Async\(OORT extended to AsyncFL\),OORT\+Async∗\\ast\(OORT AsyncFL \+ oracle TraceAvail\), REFL∗\\ast\(trace\-tuned availability predictor based selector \+ stale aggregations in SyncFL\), and FeLiX \(availability\-aware selector \+ freshness\-aware aggregator\)\. For clarity each strategy is characterized along three axes: availability knowledge \(none / oracle TraceAvail / predictor / TierTrack\), selection policy \(OORT / REFL IPS / TierSelect\), and aggregation rule \(FedAvg SyncFL / REFL SAA / FedBuff AsyncFL / TierFuse\), as summarized in Table[1](https://arxiv.org/html/2607.06979#S4.T1)\. The oracle TraceAvail is provided only to certain baselines to bound availability\-aware performance; otherwise all strategies share the same per\-client runtime/data settings and local training configurations\.

Metrics\.Primary metrics are wall\-clock time\-to\-accuracy \(target: 70% on both tasks\) and total communication \(bytes moved\)\. Secondary analyses include client utility\-age distributions, per\-round stall durations, and update\-staleness distributions at the aggregator; these are used to attribute measured performance differences to stalls, utility staleness, or staleness in updates\.

![Refer to caption](https://arxiv.org/html/2607.06979v1/x10.png)Figure 9\.Time\-to\-accuracy and communication for CIFAR\-10 under the real\-world, low availability MobiPerf trace\. FeLiX reaches 70% accuracy 1\.76X faster than oracle\-assisted OORT and REFL, while using less total communication \(162\.6 GB vs 211\.4 GB for REFL∗\\ast\) by prioritizing more useful client updates early and handling stale updates better\.![Refer to caption](https://arxiv.org/html/2607.06979v1/x11.png)Figure 10\.For Google Speech under the MobiPerf trace, FeLiX achieves the target accuracy in≈\\approx11\.1 hours, outperforming oracle\-assisted OORT and REFL by≈\\approx1\.45\-1\.48×\\times\. Despite larger model size and heavier evaluation traffic \(≈\\approx583 GB\), FeLiX maintains fast convergence with moderate communication cost\.![[Uncaptioned image]](https://arxiv.org/html/2607.06979v1/x12.png)100% Availability90% Availability50% Availability![Refer to caption](https://arxiv.org/html/2607.06979v1/x13.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x14.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x15.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x16.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x17.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x18.png)Figure 11\.FeLiX reaches 70% accuracy on CIFAR\-10\>4×\>4\\timesfaster versus the best non\-oracle baseline \(OORT\+Async\) as degree of availability decreases, while also yielding≈\\approx40\.2% savings in communication costs\. Extent of synthetic availability decreases from 100% to 90% to 50% from left to right\. Bottom row captures total communication costs for various strategies\.![Refer to caption](https://arxiv.org/html/2607.06979v1/x19.png)Figure 12\.TierTrack provides benefits over oracular knowledge of client availability by reducing time\-to\-accuracy by 5\-7%\.![Refer to caption](https://arxiv.org/html/2607.06979v1/x20.png)\(a\)10% Unavail\. Utility \(higher is better\)
![Refer to caption](https://arxiv.org/html/2607.06979v1/x21.png)\(b\)10% Unavail\. Speed \(lower is better\)
![Refer to caption](https://arxiv.org/html/2607.06979v1/x22.png)\(c\)MobiPerf \(80–90% Unavail\.\) Selector Utility
![Refer to caption](https://arxiv.org/html/2607.06979v1/x23.png)\(d\)MobiPerf \(80–90% Unavail\.\) Trainer Speed

Figure 13\.Analysis of selector utility \(higher is better\) and trainer speed \(lower is better\) across strategies for high and low availability traces\. FeLiX maximizes utility while prioritizing fast trainers\.![Refer to caption](https://arxiv.org/html/2607.06979v1/x24.png)\(a\)Compare TrainSelectors — Selector Utility \(higher is better\)
![Refer to caption](https://arxiv.org/html/2607.06979v1/x25.png)\(b\)Compare TrainSelectors — Trainer Speed \(lower is better\)
![Refer to caption](https://arxiv.org/html/2607.06979v1/x26.png)\(c\)Train vs Eval Selectors — Selector Utility
![Refer to caption](https://arxiv.org/html/2607.06979v1/x27.png)\(d\)Train vs Eval Selectors — Trainer Speed

Figure 14\.FeLiX’s TrainSelector benefits from the EvalSelector, which probes underused clients to reveal high\-utility participants, leading to better utility\-speed tradeoffs\.TierFuse vs FedBuff ![Refer to caption](https://arxiv.org/html/2607.06979v1/x28.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x29.png)![Refer to caption](https://arxiv.org/html/2607.06979v1/x30.png)

Figure 15\.TierFuse vs\. FedBuff\. TierFuse prevents the loss of informative signal by maintaining high contribution weights for late updates\. By reclaiming gradients from the long\-tail of slow or transient clients, FeLiX reduces time\-to\-target accuracy compared to the rigid weighting schemes used in current asynchronous baselines\.
## 6\.Evaluation

We seek to answer the following four concrete questions:

- Q1End\-to\-end \(real\-world\):Can FeLiX provide tangible time\-to\-accuracy and communication cost benefits under high\-unavailability real\-world traces \(MobiPerf\), across image and speech modalities?
- Q2End\-to\-end \(synthetic\):Do gains from FeLiX only occur in sparse availability or do they hold across scenarios of moderate \(50%\) to high \(100%\) availability too? This continues to operate in the maximal data heterogeneity \(Dir​\(α\)=0\.1\\mathrm\{Dir\}\(\\alpha\)\{=\}0\.1\) regime\. Can FeLiX reduce wall\-clock time\-to\-accuracy and total communication?
- Q3FeLiX’s components:What are the end\-to\-end per\-component contributions and overheads of TierTrack \(real\-time availability\), TierSelect \(train \+ eval\-aware selection\), and TierFuse \(freshness\-aware weighting\)?
- Q4Scalability and robustness:How do FeLiX’ tracking, selection and aggregation perform as clients scale?

### 6\.1\.End\-to\-end: Real\-World MobiPerf Trace \(Q1\)

Time\-to\-accuracy\.For CIFAR\-10 on the bursty and very low availability MobiPerf trace, FeLiX yields an impressive1\.76×1\.76\\timesspeedup by reaching the 70% target accuracy versus oracularOORT∗\\astvariants and REFL, the best competing strategies\. This reduction in wall\-clock is due to live availability tracking and task\-aware sampling\. Not only does this avoid long stalls and reduce blind re\-selection, the freshness\-aware aggregation keeps useful updates contributing rather than being ignored\. For the speech task the same pattern holds qualitatively: FeLiX converges in≈\\approx11\.1 h while oracle\-assisted OORT variants and REFL finish in≈\\approx15\.9–16\.3 h \(≈\\approx1\.45–1\.48X slower\)\. The larger absolute times for speech reflect both model and trace interactions, but the relative improvement of FeLiX remains intact across modalities and under the difficult and fluctuating MobiPerf availability\.

Communication cost\.The total communication numbers in Fig\.[9](https://arxiv.org/html/2607.06979#S5.F9)and Fig\.[10](https://arxiv.org/html/2607.06979#S5.F10)must be read together with model sizes and the mix of evaluation and training task messages\. CIFAR\-10 uses a small model \(≈\\approx0\.5M parameters\) so it requires a modest 1\.9 MB per update sent or received\. On the other hand, the speech model is much larger \(≈\\approx7\.5M parameters\) and needs≈\\approx28\.6 MB per exchange\. This translates to an order\-of\-magnitude larger total bandwidth over the run durations\. Under the MobiPerf trace conditions, all strategies for speech require a large \(2–3 TB\) of exchange over the course of 3,000 to 6,000 rounds of aggregations \(based on the strategy\)\. In terms of communication cost, FeLiX sits between theOORT\+Async∗\\astand pure sync variants \(OORT∗\\ast, REFL\) in total bytes while still providing the fastest wall\-clock times\. For CIFAR\-10, FeLiX’s total communication \(162\.6 GB\) is still lower thanOORT\+Async∗\\ast\(270\.0 GB\)\. This gap shows that FeLiX saves a lot communication cost by achieving the target accuracy much sooner by selecting and accepting more helpful client updates early\. This includes the extra communication cost of onevalmessages \(≈\\approx20\.3 GB\) that keep utilities fresh\. For Speech,evaltraffic is more consequential: FeLiX uses≈\\approx583 GB for evaluation tasks because each evaluation task is now 15X costlier due to the larger speech model\. This shows that eval\-task bandwidth must be tuned or compressed in large\-model settings\.

In short, FeLiX consistently reduces time\-to\-target on low availability, real\-world traces for both CIFAR\-10 and Speech modality tasks\. The time\-to\-accuracy and communication\-cost is a trade\-off: faster convergence often means more but more useful message exchanges early on, and evaluation overhead scales with model size\. Minimizing end\-to\-end communication cost therefore requires balancing evaluation tasks and model\-size\-aware optimizations \(e\.g\., smaller proxy evals or compressed eval uploads\) to keep eval overhead small while preserving the wall\-clock gains FeLiX delivers\.

### 6\.2\.End\-to\-end: Synthetic Traces \(Q2\)

Time\-to\-Target Accuracy\.Across the synthetic availability traces in Fig\.[11](https://arxiv.org/html/2607.06979#S5.F11), FeLiX reaches the 70% CIFAR\-10 target faster than all baselines, including those with oracular foresight\. Relative to the strongest non\-oracle strategy \(OORT\+Async\), FeLiX improves time\-to\-accuracy by1\.26×1\.26\\timesat 100% availability,2\.37×2\.37\\timesat 90%, and by\>4×\>4\\timesat 50% availability\. As availability decreases, the lines for availability\-unaware strategies shift toward the bottom\-right, with time\-to\-accuracy increasing from 8 h to over 24 h\. This shift reflects the heavy cost of incorrect selections and synchronization stalls\. While oracular strategies \(OORT\+Async∗\\ast\) remain stable near 8 h by avoiding stalls via trace\-knowledge, FeLiX actually outperforms these oracles\. This performance gain is driven by three synergistic primitives: TierTrack tiering to avoid stalls in real\-time, TierSelect’s dual train\-and\-eval tasks that prioritize utility even in high\-availability regimes, and TierFuse, which extracts informative signal from late updates that other systems would simply discard\.

Communication Efficiency and the Cost of Staleness\.FeLiX significantly reduces the total communication required to reach target accuracy\. When compared to the oracularOORT\+Async∗\\ast, FeLiX saves approximately40\.2%40\.2\\%of total bandwidth\. Notably, as unavailability increases, FeLiX’s total communication cost actually falls by≈9\.7%\\approx 9\.7\\%, as TierSelect dispatches fewer evaluation tasks when client utility remains fresher for longer\.

The comparison with REFL∗\\astreveals a significant efficiency gap\. Although REFL∗\\astis a SyncFL variant, it maintains a large set of trainers ”in\-flight” to accommodate delayed updates and maximize throughput\. However, its rigid policy of discarding any update staler than 5 rounds creates a significant communication overhead\. Empirically, we observe that effectively 25% of REFL’s trainer\-to\-aggregator uplink traffic is discarded for exceeding this threshold\. This is not merely a waste of device uplink traffic; it also represents a loss of the aggregator\-to\-trainer downlink bandwidth used to transmit the model weights initially\. Furthermore, this aggressive pruning harms the model itself, as informative updates from the long\-tail of slower or transiently unavailable clients are lost\. By contrast, FeLiX employs freshness\-aware aggregation to incorporate these updates safely, ensuring that all network communication cost incurred by the system contributes to the final convergence\. This allows FeLiX to beat REFL not only in wall\-clock time but also in total communication cost across all availability regimes\.

### 6\.3\.FeLiX Component Benefits \(Q3\)

To decompose the end\-to\-end gains reported in §[6\.2](https://arxiv.org/html/2607.06979#S6.SS2)and §[6\.1](https://arxiv.org/html/2607.06979#S6.SS1), we inspect three diagnostic metrics at runtime: aggregator stall duration, client utility age \(the latency between a client’s last evaluation and its current selection\), and update staleness at the point of aggregation\. These traces expose the specific failure modes that affect existing strategies\. SyncFL variants without live telemetry suffer from long\-tail round durations as they wait on dropped or straggling clients\. Selection algorithms that do not proactively refresh utility estimates suffer from utility drift, repeatedly re\-selecting historically high\-value clients that are currently unavailable or whose data distribution has shifted\. Finally, standard AsyncFL rules either discard valuable\-but\-late updates or apply a uniform staleness penalty, both of which erode the statistical signal\. We now show how each FeLiX component resolves these failures through a tightly coupled orchestration loop\.

TierTrack: Mitigating the impact of client inactivity\.Integrating TierTrack into the orchestration loop sharply reduces tail latencies by enabling immediate resampling when selected clients become unreachable\. In our CIFAR\-10 experiments, augmenting a stalledOORT\+Asyncbaseline with TierTrack cuts the median \(P50\) round duration from 258\.9s to just 4\.9s, while the P95 tail latency drops from 653\.3s to 21s \(Fig\.[12](https://arxiv.org/html/2607.06979#S5.F12)\)\. This orders\-of\-magnitude improvement occurs because TierTrack operates on live telemetry rather than static traces; it can detect mid\-round drop\-offs—which affected 6–8% of all selections in our traces—and trigger an immediate replacement\. Consequently,OORT\+Async\+TierTrack achieves a 5–7% lower time\-to\-accuracy than even the trace\-informed oracle \(OORT\+Async∗\\ast\), which can avoid stalls but lacks the mechanism to reactively resample when a selected client disappears mid\-computation\.

TierSelect: Maintaining utility freshness via dual\-tier selection\.TierSelect decouples selection into a TrainSelector, which targets high\-progress, responsive clients, and an EvalSelector, which acts as a ”scout” by issuing lightweight evaluation tasks to clients with stale or missing utility estimates\. This dual\-tier approach ensures that the server’s view of the population remains accurate despite bursty availability\. As shown in Fig\.[13](https://arxiv.org/html/2607.06979#S5.F13), the TrainSelector consistently prioritizes clients with higher statistical utility \(median score of 122\.0 vs 118\.1 for OORT\), even when those clients are marginally slower \(median compute of 11\.2s vs 10\.9s\)\. This trade\-off is mathematically advantageous: by selecting more informative gradients, the model requires fewer total rounds to reach the target accuracy\. Simultaneously, the EvalSelector probes low\-utility trainers and reveals their true hardware profiles \(P99<<100\), identifying that these clients are significantly slower \(median 15\.7s\)\. This fresh evidence prevents the system from making blind, repeated re\-selections of low\-yield or hardware\-constrained devices\.

TierFuse: Regaining information from delayed updates\.Rather than applying a destructive staleness penalty or discarding late updates, TierFuse computes a contribution factor that balances a client’s specific statistical utility against its update age\. This allows the system to incorporate informative updates from the ”long\-tail” of the edge ecosystem that would otherwise be lost\. As illustrated in Fig\.[15](https://arxiv.org/html/2607.06979#S5.F15), TierFuse assigns high weights \(≥0\.8\\geq 0\.8\) to over 90% of received updates, preserving their informative signal even when they arrive moderately late\. In contrast, a FedBuff\-style policy, which lacks this informativeness\-aware weighting, assigns such high weights to fewer than 10% of updates, often falling back to a flat moderate weight of≈\\approx0\.5\. By effectively protecting high\-value updates from aggressive staleness discounting, TierFuse increases the per\-update usefulness of every byte transmitted, accelerating convergence under the erratic conditions of streaming FL\.

FeLiX: Combined synthesis of components\.These three components are fundamentally intertwined: TierTrack eliminates stalls to ensure that EvalSelector’s probes reflect actual availability; EvalSelector maintains fresh utility estimates so TrainSelector can accurately prioritize informative clients; and TierFuse ensures that once an update is received—whether fresh or moderately stale—its weight reflects its true contribution to the global model\. Together, they transform availability and freshness from passive observations into active control signals, explaining the substantial wall\-clock and communication gains observed in production\-scale settings\.

### 6\.4\.Scalability and robustness \(Q4\)

Selector and decision latency\.FeLiX is designed to minimize server\-side overhead by offloading availability tracking to the edge\. Per\-decision compute latency remains consistently low \(<0\.5​s<0\.5s\) because the server does not perform an exhaustive, synchronous scan of the entire population\. Instead, the client\-driven tiering ensures the server only ranks the active,*ready*subset of the population, while theEvalSelectorasynchronously estimates live client utility in the background\. This decoupling allows the orchestration logic to scale gracefully; as the population increases from 10 to 300 concurrent clients, we observe no significant increase in selection latency or congestion at the MQTT broker\.

Robustness to heterogeneity\.We evaluate the resilience of FeLiX across varying degrees of statistical and system heterogeneity by sweeping Dirichlet distribution parameters \(α∈\{0\.1,1,10,100\}\\alpha\\in\\\{0\.1,1,10,100\\\}\) and runtime compute distributions \(1 to 60 seconds\)\. As expected, the relative gains of FeLiX are most pronounced in the strongly non\-IID regimes \(α=0\.1\\alpha=0\.1\) and low\-availability settings\. These represent the most challenging and deployment\-relevant scenarios where standard FL systems typically collapse\. In highly heterogeneous environments, the*opportunity cost*of a poor selection is high; missing a transiently available client with high\-utility data results in a significant loss of gradient progress\. FeLiX’s ability to fuse live availability with freshness\-aware aggregation allows it to navigate these sparse availability environments effectively, ensuring that every successful update provides maximum statistical gain\. This robustness demonstrates that FeLiX is not merely faster in idealized settings, but fundamentally more resilient to the adverse conditions of production edge ecosystems\.

## 7\.Related Work

FL Applications\.FL was introduced by McMahanet al\.\(McMahanet al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib28)\)as FedAvg, and\(Kairouzet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib16); Yanget al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib50)\)survey its landscape and open challenges\. Beyond the production recommender and analytics workloads this paper targets, FL has been applied to mobile keyboard prediction\(Hardet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib12); Chenet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib6)\), on\-device language modeling\(Xuet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib49),[2024](https://arxiv.org/html/2607.06979#bib.bib56)\), healthcare analytics\(Brisimiet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib4); Liet al\.,[2019a](https://arxiv.org/html/2607.06979#bib.bib22); Xuet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib48); Nguyenet al\.,[2022a](https://arxiv.org/html/2607.06979#bib.bib33)\), and distribution\-shifted domains\(Penget al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib35)\)\. Privacy threats including membership inference\(Shokriet al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib39)\)and client\-level differential privacy\(Geyeret al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib10)\)motivate the data\-local design that FeLiX inherits; its orchestration layer is orthogonal to these protections\.

FL Convergence, Heterogeneity, and Optimization\.FedAvg convergence under non\-IID data\(Liet al\.,[2019b](https://arxiv.org/html/2607.06979#bib.bib21); Wanget al\.,[2020b](https://arxiv.org/html/2607.06979#bib.bib44)\)identifies data heterogeneity and partial participation as primary theoretical obstacles; heterogeneous FL settings are surveyed in\(Yeet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib57)\)\. Adaptive server\-side optimizers\(Reddiet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib36)\), matched averaging\(Wanget al\.,[2020a](https://arxiv.org/html/2607.06979#bib.bib43)\), ensemble distillation\(Linet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib27)\), and Bayesian non\-parametric fusion\(Yurochkinet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib51)\)improve convergence under heterogeneous data; one\-shot FL\(Liet al\.,[2020a](https://arxiv.org/html/2607.06979#bib.bib24)\)eliminates iterative rounds entirely\. Communication efficiency is targeted by gradient compression\(Konečnỳet al\.,[2016](https://arxiv.org/html/2607.06979#bib.bib17)\), distributed mean estimation\(Sureshet al\.,[2017](https://arxiv.org/html/2607.06979#bib.bib41)\), and adaptive communication scheduling\(Wang and Joshi,[2019](https://arxiv.org/html/2607.06979#bib.bib42)\)\. FeLiX’s weighted aggregation policy is complementary to all of these: it targets update informativeness and model\-age correction rather than modifying the fusion or compression scheme\.

Client Availability, Selection, and AsyncFL\.Section[2](https://arxiv.org/html/2607.06979#S2)analyzes in detail why the leading utility\-aware selectors OORT\(Laiet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib19)\)and REFL\(Abdelmoniemet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib1)\), buffered AsyncFL\(Nguyenet al\.,[2022b](https://arxiv.org/html/2607.06979#bib.bib32); Zhanget al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib52)\), and production FL systems\(Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3); Srinivaset al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib55); Wanget al\.,[2023a](https://arxiv.org/html/2607.06979#bib.bib45)\)fall short under real\-time availability churn\. More broadly, async FL has been studied from decentralized SGD and momentum perspectives\(Lianet al\.,[2018](https://arxiv.org/html/2607.06979#bib.bib25); Xieet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib47); Mitliagkaset al\.,[2016](https://arxiv.org/html/2607.06979#bib.bib29)\), and extended to continual and non\-IID settings\(Shenajet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib38); Chenet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib7)\)\. Staleness handling has received dedicated attention\(Zhouet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib53); Rodio and Neglia,[2024](https://arxiv.org/html/2607.06979#bib.bib37)\); variance from partial participation is targeted by FedVARP\(Jhunjhunwalaet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib15)\)and large\-cohort analysis\(Charleset al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib5)\)\. Nishio and Yonetani\(Nishio and Yonetani,[2019](https://arxiv.org/html/2607.06979#bib.bib34)\)select clients by deadline compliance under resource heterogeneity\. Prior work\(Garget al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib54)\)empirically shows that ignoring real\-time availability substantially increases time\-to\-accuracy, directly motivating the TierTrack tracking design in FeLiX\.

Client Interruption and Local Checkpointing\.A natural response to mid\-training client interruptions is to checkpoint local model state, enabling resumption after conditions recover—a technique well\-developed for distributed DNN training\(Mohanet al\.,[2021](https://arxiv.org/html/2607.06979#bib.bib31); Eisenmanet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib8); Guptaet al\.,[2024](https://arxiv.org/html/2607.06979#bib.bib11); Wanget al\.,[2023b](https://arxiv.org/html/2607.06979#bib.bib46)\)\. In the FL context, however, local checkpointing only defers the problem: the client still cannot return any update until it becomes available again, and the global model continues to advance in the interim, rendering saved gradients stale or model\-incompatible on return\. FeLiX addresses the root cause instead, by exploiting lightweight real\-time readiness signals to harvest updates*before*interruptions occur and by weighting late\-arriving updates by their informative value rather than discarding or blindly accumulating them\.

FL Systems, Frameworks, and Benchmarks\.Production FL platforms\(Bonawitzet al\.,[2019](https://arxiv.org/html/2607.06979#bib.bib3); Hubaet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib14); Srinivaset al\.,[2025](https://arxiv.org/html/2607.06979#bib.bib55)\)address large\-scale cross\-device deployments; FLINT\(Wanget al\.,[2023a](https://arxiv.org/html/2607.06979#bib.bib45)\)provides on\-device measurement; FedScale\(Laiet al\.,[2022](https://arxiv.org/html/2607.06979#bib.bib20)\)benchmarks system performance with realistic traces\. Research frameworks Flower\(Beutelet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib2)\)and FedML\(Heet al\.,[2020](https://arxiv.org/html/2607.06979#bib.bib13)\)support controlled experimentation\. FeLiX is built on the Flame orchestration layer\(Dagaet al\.,[2023](https://arxiv.org/html/2607.06979#bib.bib9)\)and evaluated against real MobiPerf traces\([M\-Lab,](https://arxiv.org/html/2607.06979#bib.bib30)\); unlike offline benchmark or framework tools, it targets production\-scale streaming workloads with bursty, minute\-level availability dynamics\.

## 8\.Conclusion

As production Federated Learning moves from multi\-day batch refreshes toward hourly streaming adaptation, existing orchestration models have proven insufficient\. The interlocking challenges of transient client availability, shifting data utility, and delayed ground\-truth feedback create a freshness gap that degrades critical user\-facing metrics\. This work introducedFeLiX, a redesign of FL orchestration that treats availability and utility not as passive observations, but as high\-frequency control inputs\. By unifying three synergistic primitives:streaming\-aware availability tiers,fresh\-utility selection, andinformativeness\-aware, delay\-robust aggregation, FeLiX bridges the gap between idealized oracular theory and the realities of the practical FL deployments in the mobile\-edge ecosystem\. Our evaluation across multiple modalities and realistic MobiPerf traces demonstrates that FeLiX achieves near\-oracular performance, delivering a2\.37×2\.37\\timesreduction in time\-to\-target accuracy while simultaneously saving1\.30×1\.30\\timesin total communication bandwidth compared to state\-of\-the\-art baselines\. These results confirm that by eliminating synchronization stalls and reclaiming signal from the long\-tail of delayed updates, FeLiX ensures that deployed models remain in sync with volatile live data distributions\. Ultimately, FeLiX provides the necessary framework for high\-scale, privacy\-preserving applications to adapt at the speed of user interaction\.

## References

- A\. M\. Abdelmoniem, A\. N\. Sahu, M\. Canini, and S\. A\. Fahmy \(2023\)Refl: resource\-efficient federated learning\.InProceedings of the Eighteenth European Conference on Computer Systems,pp\. 215–232\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px2.p1.1),[3rd item](https://arxiv.org/html/2607.06979#S3.I1.i3.p1.1),[Table 1](https://arxiv.org/html/2607.06979#S4.T1),[§5](https://arxiv.org/html/2607.06979#S5.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- D\. J\. Beutel, T\. Topal, A\. Mathur, X\. Qiu, J\. Fernandez\-Marques, Y\. Gao, L\. Sani, H\. L\. Kwing, T\. Parcollet, P\. P\. d\. Gusmão, and N\. D\. Lane \(2020\)Flower: a friendly federated learning research framework\.arXiv preprint arXiv:2007\.14390\.Cited by:[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p2.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- K\. Bonawitz, H\. Eichner, W\. Grieskamp, D\. Huba, A\. Ingerman, V\. Ivanov, C\. Kiddon, J\. Konečnỳ, S\. Mazzocchi, B\. McMahan,et al\.\(2019\)Towards federated learning at scale: system design\.Proceedings of machine learning and systems1,pp\. 374–388\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px2.p1.1),[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p1.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p3.2),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p2.1),[1st item](https://arxiv.org/html/2607.06979#S3.I1.i1.p1.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- T\. S\. Brisimi, R\. Chen, T\. Mela, A\. Olshevsky, I\. C\. Paschalidis, and W\. Shi \(2018\)Federated learning of predictive models from federated electronic health records\.International journal of medical informatics112,pp\. 59–67\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- Z\. Charles, Z\. Garrett, Z\. Huo, S\. Shmulyian, and V\. Smith \(2021\)On large\-cohort training for federated learning\.Advances in neural information processing systems34,pp\. 20461–20475\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px1.p1.1),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- M\. Chen, A\. T\. Suresh, R\. Mathews, A\. Wong, C\. Allauzen, F\. Beaufays, and M\. Riley \(2019\)Federated learning of n\-gram language models\.arXiv preprint arXiv:1910\.03432\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- Y\. Chen, Y\. Ning, M\. Slawski, and H\. Rangwala \(2020\)Asynchronous online federated learning for edge devices with non\-iid data\.In2020 IEEE International Conference on Big Data \(Big Data\),pp\. 15–24\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- H\. Daga, J\. Shin, D\. Garg, A\. Gavrilovska, M\. Lee, and R\. R\. Kompella \(2023\)Flame: simplifying topology extension in federated learning\.InProceedings of the 2023 ACM Symposium on Cloud Computing,SoCC ’23\.Cited by:[§5](https://arxiv.org/html/2607.06979#S5.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- A\. Eisenman, K\. K\. Matam, S\. Ingram, D\. Mudigere, R\. Krishnamoorthi, K\. Nair, M\. Smelyanskiy, and M\. Annavaram \(2022\)\{\\\{check\-N\-run\}\\\}: a checkpointing system for training deep learning recommendation models\.In19th USENIX Symposium on Networked Systems Design and Implementation \(NSDI 22\),pp\. 929–943\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p4.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p3.1),[§7](https://arxiv.org/html/2607.06979#S7.p4.1)\.
- D\. Garg, D\. Sanyal, M\. Lee, A\. Tumanov, and A\. Gavrilovska \(2025\)Client availability in federated learning: it matters\!\.InProceedings of the 5th Workshop on Machine Learning and Systems,pp\. 114–121\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px1.p1.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p3.2),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- R\. C\. Geyer, T\. Klein, and M\. Nabi \(2017\)Differentially private federated learning: a client level perspective\.arXiv preprint arXiv:1712\.07557\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- T\. Gupta, S\. Krishnan, R\. Kumar, A\. Vijeev, B\. Gulavani, N\. Kwatra, R\. Ramjee, and M\. Sivathanu \(2024\)Just\-in\-time checkpointing: low cost error recovery from deep learning training failures\.InProceedings of the Nineteenth European Conference on Computer Systems,pp\. 1110–1125\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p4.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p3.1),[§7](https://arxiv.org/html/2607.06979#S7.p4.1)\.
- A\. Hard, K\. Rao, R\. Mathews, S\. Ramaswamy, F\. Beaufays, S\. Augenstein, H\. Eichner, C\. Kiddon, and D\. Ramage \(2018\)Federated learning for mobile keyboard prediction\.arXiv preprint arXiv:1811\.03604\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- C\. He, S\. Li, J\. So, X\. Zeng, M\. Zhang, H\. Wang, X\. Wang, P\. Vepakomma, A\. Singh, H\. Qiu,et al\.\(2020\)Fedml: a research library and benchmark for federated machine learning\.arXiv preprint arXiv:2007\.13518\.Cited by:[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p2.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- D\. Huba, J\. Nguyen, K\. Malik, R\. Zhu, M\. Rabbat, A\. Yousefpour, C\. Wu, H\. Zhan, P\. Ustinov, H\. Srinivas,et al\.\(2022\)Papaya: practical, private, and scalable federated learning\.Proceedings of Machine Learning and Systems4,pp\. 814–832\.Cited by:[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p1.1),[§5](https://arxiv.org/html/2607.06979#S5.p2.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- D\. Jhunjhunwala, P\. Sharma, A\. Nagarkatti, and G\. Joshi \(2022\)Fedvarp: tackling the variance due to partial client participation in federated learning\.InUncertainty in Artificial Intelligence,pp\. 906–916\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px1.p1.1),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- P\. Kairouz, H\. B\. McMahan, B\. Avent, A\. Bellet, M\. Bennis, A\. N\. Bhagoji, K\. Bonawitz, Z\. Charles, G\. Cormode, R\. Cummings,et al\.\(2021\)Advances and open problems in federated learning\.Foundations and trends® in machine learning14\(1–2\),pp\. 1–210\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- J\. Konečnỳ, H\. B\. McMahan, D\. Ramage, and P\. Richtárik \(2016\)Federated optimization: distributed machine learning for on\-device intelligence\.arXiv preprint arXiv:1610\.02527\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- A\. Krizhevsky \(2009\)Learning multiple layers of features from tiny images\.Technical report\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p6.1)\.
- F\. Lai, Y\. Dai, S\. Singapuram, J\. Liu, X\. Zhu, H\. Madhyastha, and M\. Chowdhury \(2022\)Fedscale: benchmarking model and system performance of federated learning at scale\.InInternational conference on machine learning,pp\. 11814–11827\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p3.2),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p2.1),[§5](https://arxiv.org/html/2607.06979#S5.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- F\. Lai, X\. Zhu, H\. V\. Madhyastha, and M\. Chowdhury \(2021\)Oort: efficient federated learning via guided participant selection\.In15th\{\\\{USENIX\}\\\}Symposium on Operating Systems Design and Implementation \(\{\\\{OSDI\}\\\}21\),pp\. 19–35\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px2.p1.1),[2nd item](https://arxiv.org/html/2607.06979#S3.I1.i2.p1.1),[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p1.1),[Table 1](https://arxiv.org/html/2607.06979#S4.T1),[§5](https://arxiv.org/html/2607.06979#S5.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- Q\. Li, B\. He, and D\. Song \(2020a\)Practical one\-shot federated learning for cross\-silo setting\.arXiv preprint arXiv:2010\.01017\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- T\. Li, A\. K\. Sahu, A\. Talwalkar, and V\. Smith \(2020b\)Federated learning: challenges, methods, and future directions\.IEEE signal processing magazine37\(3\),pp\. 50–60\.Cited by:[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p1.1)\.
- W\. Li, F\. Milletarì, D\. Xu, N\. Rieke, J\. Hancox, W\. Zhu, M\. Baust, Y\. Cheng, S\. Ourselin, M\. J\. Cardoso,et al\.\(2019a\)Privacy\-preserving federated brain tumour segmentation\.InMachine Learning in Medical Imaging: 10th International Workshop, MLMI 2019, Held in Conjunction with MICCAI 2019, Shenzhen, China, October 13, 2019, Proceedings 10,pp\. 133–141\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- X\. Li, K\. Huang, W\. Yang, S\. Wang, and Z\. Zhang \(2019b\)On the convergence of fedavg on non\-iid data\.arXiv preprint arXiv:1907\.02189\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p2.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- X\. Lian, W\. Zhang, C\. Zhang, and J\. Liu \(2018\)Asynchronous decentralized parallel stochastic gradient descent\.InInternational Conference on Machine Learning,pp\. 3043–3052\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p2.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p2.7),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- R\. A\. Light \(2017\)Mosquitto: server and client implementation of the mqtt protocol\.Journal of Open Source Software2\(13\),pp\. 265\.Cited by:[§5](https://arxiv.org/html/2607.06979#S5.p1.1)\.
- T\. Lin, L\. Kong, S\. U\. Stich, and M\. Jaggi \(2020\)Ensemble distillation for robust model fusion in federated learning\.Advances in neural information processing systems33,pp\. 2351–2363\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- \[29\]M\-LabMobiPerf data set\.Note:[https://www\.measurementlab\.net/tests/mobiperf/](https://www.measurementlab.net/tests/mobiperf/)Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px1.p1.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p3.2),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- K\. K\. Matam, H\. Ramezani, F\. Wang, Z\. Chen, Y\. Dong, M\. Ding, Z\. Zhao, Z\. Zhang, E\. Wen, and A\. Eisenman \(2024\)\{\\\{quickupdate\}\\\}: A\{\\\{real\-time\}\\\}personalization system for\{\\\{large\-scale\}\\\}recommendation models\.In21st USENIX Symposium on Networked Systems Design and Implementation \(NSDI 24\),pp\. 731–744\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p2.1)\.
- B\. McMahan, E\. Moore, D\. Ramage, S\. Hampson, and B\. A\. y Arcas \(2017\)Communication\-efficient learning of deep networks from decentralized data\.InArtificial intelligence and statistics,pp\. 1273–1282\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p1.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p4.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- I\. Mitliagkas, C\. Zhang, S\. Hadjis, and C\. Ré \(2016\)Asynchrony begets momentum, with an application to deep learning\.In2016 54th Annual Allerton Conference on Communication, Control, and Computing \(Allerton\),pp\. 997–1004\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- J\. Mohan, A\. Phanishayee, and V\. Chidambaram \(2021\)\{\\\{checkfreq\}\\\}: Frequent,\{\\\{fine\-grained\}\\\}\{\\\{dnn\}\\\}checkpointing\.In19th USENIX Conference on File and Storage Technologies \(FAST 21\),pp\. 203–216\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p4.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p3.1),[§7](https://arxiv.org/html/2607.06979#S7.p4.1)\.
- D\. C\. Nguyen, Q\. Pham, P\. N\. Pathirana, M\. Ding, A\. Seneviratne, Z\. Lin, O\. Dobre, and W\. Hwang \(2022a\)Federated learning for smart healthcare: a survey\.ACM Computing Surveys \(Csur\)55\(3\),pp\. 1–37\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- J\. Nguyen, K\. Malik, H\. Zhan, A\. Yousefpour, M\. Rabbat, M\. Malek, and D\. Huba \(2022b\)Federated learning with buffered asynchronous aggregation\.InInternational Conference on Artificial Intelligence and Statistics,pp\. 3581–3607\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px2.p1.1),[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p1.1),[Figure 2](https://arxiv.org/html/2607.06979#S2.F2),[Figure 2](https://arxiv.org/html/2607.06979#S2.F2.4.2),[3rd item](https://arxiv.org/html/2607.06979#S3.I1.i3.p1.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p4.1),[§3\.4](https://arxiv.org/html/2607.06979#S3.SS4.p1.1),[§5](https://arxiv.org/html/2607.06979#S5.p2.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- T\. Nishio and R\. Yonetani \(2019\)Client selection for federated learning with heterogeneous resources in mobile edge\.InICC 2019\-2019 IEEE international conference on communications \(ICC\),pp\. 1–7\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- X\. Peng, Z\. Huang, Y\. Zhu, and K\. Saenko \(2019\)Federated adversarial domain adaptation\.arXiv preprint arXiv:1911\.02054\.Cited by:[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- S\. Reddi, Z\. Charles, M\. Zaheer, Z\. Garrett, K\. Rush, J\. Konečnỳ, S\. Kumar, and H\. B\. McMahan \(2020\)Adaptive federated optimization\.arXiv preprint arXiv:2003\.00295\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- A\. Rodio and G\. Neglia \(2024\)FedStale: leveraging stale client updates in federated learning\.arXiv preprint arXiv:2405\.04171\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p1.1),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- D\. Shenaj, M\. Toldo, A\. Rigon, and P\. Zanuttigh \(2023\)Asynchronous federated continual learning\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition,pp\. 5055–5063\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- R\. Shokri, M\. Stronati, C\. Song, and V\. Shmatikov \(2017\)Membership inference attacks against machine learning models\.In2017 IEEE symposium on security and privacy \(SP\),pp\. 3–18\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- H\. Srinivas, G\. Cormode, M\. Honarkhah, S\. Lurye, J\. Hehir, L\. He, G\. Hong, A\. Magdy, D\. Huba, K\. Wang,et al\.\(2025\)\{\\\{papaya\}\\\}Federated analytics stack: engineering privacy, scalability and practicality\.In22nd USENIX Symposium on Networked Systems Design and Implementation \(NSDI 25\),pp\. 883–898\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p3.2),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p2.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- A\. T\. Suresh, X\. Y\. Felix, S\. Kumar, and H\. B\. McMahan \(2017\)Distributed mean estimation with limited communication\.InInternational conference on machine learning,pp\. 3329–3337\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- E\. Wang, B\. Chen, M\. Chowdhury, A\. Kannan, and F\. Liang \(2023a\)Flint: a platform for federated learning integration\.Proceedings of Machine Learning and Systems5\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p3.2),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p2.1),[1st item](https://arxiv.org/html/2607.06979#S3.I1.i1.p1.1),[§3\.2](https://arxiv.org/html/2607.06979#S3.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1),[§7](https://arxiv.org/html/2607.06979#S7.p5.1)\.
- H\. Wang, M\. Yurochkin, Y\. Sun, D\. Papailiopoulos, and Y\. Khazaeni \(2020a\)Federated learning with matched averaging\.arXiv preprint arXiv:2002\.06440\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- J\. Wang and G\. Joshi \(2019\)Adaptive communication strategies to achieve the best error\-runtime trade\-off in local\-update sgd\.Proceedings of Machine Learning and Systems1,pp\. 212–229\.Cited by:[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- J\. Wang, Q\. Liu, H\. Liang, G\. Joshi, and H\. V\. Poor \(2020b\)Tackling the objective inconsistency problem in heterogeneous federated optimization\.Advances in neural information processing systems33,pp\. 7611–7623\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- Z\. Wang, Z\. Jia, S\. Zheng, Z\. Zhang, X\. Fu, T\. E\. Ng, and Y\. Wang \(2023b\)Gemini: fast failure recovery in distributed training with in\-memory checkpoints\.InProceedings of the 29th Symposium on Operating Systems Principles,pp\. 364–381\.Cited by:[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p4.1),[§7](https://arxiv.org/html/2607.06979#S7.p4.1)\.
- P\. Warden \(2018\)Speech Commands: A Dataset for Limited\-Vocabulary Speech Recognition\.ArXiv e\-prints\.External Links:1804\.03209,[Link](https://arxiv.org/abs/1804.03209)Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p6.1)\.
- C\. Xie, S\. Koyejo, and I\. Gupta \(2019\)Asynchronous federated optimization\.arXiv preprint arXiv:1903\.03934\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p1.1),[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p2.1),[§2\.1](https://arxiv.org/html/2607.06979#S2.SS1.p2.7),[§3\.4](https://arxiv.org/html/2607.06979#S3.SS4.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- J\. Xu, B\. S\. Glicksberg, C\. Su, P\. Walker, J\. Bian, and F\. Wang \(2021\)Federated learning for healthcare informatics\.Journal of healthcare informatics research5,pp\. 1–19\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- M\. Xu, D\. Cai, Y\. Wu, X\. Li, and S\. Wang \(2024\)\{\\\{fwdllm\}\\\}: Efficient federated finetuning of large language models with perturbed inferences\.In2024 USENIX Annual Technical Conference \(USENIX ATC 24\),pp\. 579–596\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§3\.3](https://arxiv.org/html/2607.06979#S3.SS3.p5.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- Z\. Xu, Y\. Zhang, G\. Andrew, C\. A\. Choquette\-Choo, P\. Kairouz, H\. B\. McMahan, J\. Rosenstock, and Y\. Zhang \(2023\)Federated learning of gboard language models with differential privacy\.arXiv preprint arXiv:2305\.18465\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- Q\. Yang, Y\. Liu, T\. Chen, and Y\. Tong \(2019\)Federated machine learning: concept and applications\.ACM Transactions on Intelligent Systems and Technology \(TIST\)10\(2\),pp\. 1–19\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p1.1)\.
- M\. Ye, X\. Fang, B\. Du, P\. C\. Yuen, and D\. Tao \(2023\)Heterogeneous federated learning: state\-of\-the\-art and research challenges\.ACM Computing Surveys56\(3\),pp\. 1–44\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px2.p1.1),[§5](https://arxiv.org/html/2607.06979#S5.p4.3),[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- M\. Yurochkin, M\. Agarwal, S\. Ghosh, K\. Greenewald, N\. Hoang, and Y\. Khazaeni \(2019\)Bayesian nonparametric federated learning of neural networks\.InInternational conference on machine learning,pp\. 7252–7261\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p2.1)\.
- T\. Zhang, L\. Gao, S\. Lee, M\. Zhang, and S\. Avestimehr \(2023\)TimelyFL: heterogeneity\-aware asynchronous federated learning with adaptive partial training\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition,pp\. 5063–5072\.Cited by:[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.
- Z\. Zhou, Y\. Li, X\. Ren, and S\. Yang \(2022\)Towards efficient and stable k\-asynchronous federated learning with unbounded stale gradients on non\-iid data\.IEEE Transactions on Parallel and Distributed Systems33\(12\),pp\. 3291–3305\.Cited by:[§1](https://arxiv.org/html/2607.06979#S1.SS0.SSS0.Px3.p1.1),[§2\.2](https://arxiv.org/html/2607.06979#S2.SS2.p1.1),[§7](https://arxiv.org/html/2607.06979#S7.p3.1)\.