<?xml-model href='http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng' schematypens='http://relaxng.org/ns/structure/1.0'?><TEI xmlns="http://www.tei-c.org/ns/1.0">
	<teiHeader>
		<fileDesc>
			<titleStmt><title level='a'>FedAST: Federated Asynchronous Simultaneous Training</title></titleStmt>
			<publicationStmt>
				<publisher>Proceedings of the Uncertainty in Artificial Intelligence Conference</publisher>
				<date>07/19/2024</date>
			</publicationStmt>
			<sourceDesc>
				<bibl> 
					<idno type="par_id">10515279</idno>
					<idno type="doi"></idno>
					<title level='j'>Uncertainty in artificial intelligence</title>
<idno>1525-3384</idno>
<biblScope unit="volume"></biblScope>
<biblScope unit="issue"></biblScope>					

					<author>Baris Askin</author><author>Pranay Sharma</author><author>Carlee Joe-Wong</author><author>Gauri Joshi</author>
				</bibl>
			</sourceDesc>
		</fileDesc>
		<profileDesc>
			<abstract><ab><![CDATA[Federated Learning (FL) enables edge devices or clients to collaboratively train machine learning (ML) models without sharing their private data. Much of the existing work in FL focuses on efficiently learning a model for a single task. In this paper, we study simultaneous training of multiple FL models using a common set of clients. The few existing simultaneous training methods employ synchronous aggregation of client updates, which can cause significant delays because large models and/or slow clients can bottleneck the aggregation. On the other hand, a naive asynchronous aggregation is adversely affected by stale client updates. We propose FedAST, a buffered asynchronous federated simultaneous training algorithm that overcomes bottlenecks from slow models and adaptively allocates client resources across heterogeneous tasks. We provide theoretical convergence guarantees of FedAST for smooth non-convex objective functions. Extensive experiments over multiple real-world datasets demonstrate that our proposed method outperforms existing simultaneous FL approaches, achieving up to 46.0% reduction in time to train multiple tasks to completion.]]></ab></abstract>
		</profileDesc>
	</teiHeader>
	<text><body xmlns="http://www.tei-c.org/ns/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">INTRODUCTION</head><p>Federated Learning (FL) is a distributed learning paradigm where edge devices or clients collaboratively train machine learning (ML) models using privately held local data <ref type="bibr">[McMahan et al., 2017</ref><ref type="bibr">, Kairouz et al., 2021]</ref>. Clients iteratively update their local models, which are periodically sent to a central server for aggregation. The aggregated model is then sent to the clients to begin the next round of local updates. Since its introduction in <ref type="bibr">[McMahan et al., 2017]</ref>, various practical and theoretical aspects of FL, in-cluding client selection <ref type="bibr">[Nishio and</ref><ref type="bibr">Yonetani, 2019, Cho et al., 2022]</ref>, communication challenges <ref type="bibr">[Ang et al., 2020</ref><ref type="bibr">, Chellapandi et al., 2023]</ref>, scalability and fast training <ref type="bibr">[Xie et al., 2019</ref><ref type="bibr">, Wang et al., 2020b]</ref>, have been extensively studied. However, these works almost exclusively assume that the server aims to learn model(s) for a single task. Some FL frameworks attempt to learn models personalized to each client <ref type="bibr">[Mansour et al., 2020</ref><ref type="bibr">, Li et al., 2021</ref><ref type="bibr">, Tan et al., 2022]</ref>, but these models are still intended for the same learning task, e.g., next-word prediction on keyboards.</p><p>Many practical applications need devices to perform a wide range of learning tasks, which require training of multiple ML models. For instance, our phones need language models for keyboard next-word prediction as well as image recommendation models to highlight images more likely to be shared <ref type="bibr">[McMahan et al., 2017]</ref>. <ref type="bibr">Yao et al. [2023]</ref> propose training multiple models in federated smart car networks for different tasks, such as pothole detection and maneuver prediction. Another example can be a chat application requiring speech recognition and response text generator models concurrently, while <ref type="bibr">Le et al. [2022]</ref> suggest federated learning of multiple models for air quality index forecasting. Thus, in this paper, we seek to answer the following question:</p><p>How can we efficiently train models for multiple tasks in a federated setting using a shared pool of clients?</p><p>Simple Solutions that Extend FedAvg. A na&#239;ve approach to training multiple models is sequential training, where the models corresponding to different tasks are trained one at a time, each utilizing all the clients. The total training runtime of this approach scales linearly with the number of tasks. An alternative is for all the clients to train all tasks at the same time. However, with this approach each client will have to keep all models in memory, which is infeasible for resource-limited edge clients such as smartphones. To preserve memory, clients will have to queue the training requests and process them sequentially, again resulting in the runtime linearly increasing with the number of tasks. On the other hand, parallel or simultaneous training (ST) of all arXiv:2406.00302v1 [cs.</p><p>LG] 1 Jun 2024</p><p>the models with time-varying subsets of clients assigned to each task can strike a better trade-off between accuracy and runtime. <ref type="bibr">Bhuyan et al. [2023]</ref>'s approach assigns a disjoint subset of clients to each model in each round, which significantly improves the time taken to reach a target accuracy as compared to sequential training. However, these federated simultaneous training (FST) approaches leave room for significant improvement. There are two particular drawbacks: 1) straggler delays due to synchronous aggregation, and 2) the lack of adaptation to the training progress of heterogeneous tasks, which we address in this work.</p><p>Synchronous Aggregation and Straggler Delays. Conventional FL employs synchronous aggregation, where in each round, the server waits to receive updates from all the participating clients before each aggregation. However, when the clients have diverse hardware and communication capabilities, faster clients must remain idle until slow or straggling clients finish, causing a large wallclock runtime to complete each communication round. This problem is further exacerbated in FL with multiple simultaneous models <ref type="bibr">[Bhuyan et al., 2023</ref><ref type="bibr">, Zhou et al., 2022]</ref>, where the aggregation is synchronized across tasks as well. Therefore, the server has to wait for the slowest client across all the parallel tasks. Solutions proposed to alleviate the straggler problem in the single-model context include allowing faster clients to run more local steps <ref type="bibr">[Wang et al., 2020b]</ref>, aggregating only the client updates that arrive before a timeout <ref type="bibr">[Bonawitz et al., 2019]</ref>, and sub-sampling from the set of available clients <ref type="bibr">[Luo et al., 2022]</ref>. Although these approaches perform well when stragglers appear uniformly at random, they do not work well in the simultaneous training setting because some models (e.g., larger ones) are naturally slower to train. When the multiple models have inherently different training times, synchronized global aggregation rounds are bottlenecked by the slowest client assigned to the most computationally intensive model, leading to large idle times.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Asynchronous Aggregation and Staleness</head><p>Issues. Another solution to the straggler problem is asynchronous aggregation at the server, as proposed in AsyncFL <ref type="bibr">[Xie et al., 2019]</ref>, where the server updates the global model whenever it receives any client update. While asynchronous aggregation has been extensively studied in single-model federated learning <ref type="bibr">[Chen et al., 2020</ref><ref type="bibr">, Wang et al., 2022</ref><ref type="bibr">, Xu et al., 2023</ref><ref type="bibr">, Yu et al., 2023a]</ref>, it has not been well-explored for simultaneous federated training. Although AsyncFL addresses the straggler issue, it suffers from undesired staleness even in the standard FL setting, since the received client updates are often based on outdated models. To alleviate the staleness problem in single-model FL, Nguyen et al. <ref type="bibr">[2022]</ref> proposed storing the incoming client updates in a buffer at the server and aggregating when the buffer is full.</p><p>Adaptive Allocation of Clients to Heterogeneous Tasks.</p><p>In this work, we employ asynchronous buffered aggregation to overcome the straggler issue while controlling staleness. However, extending single-model FL algorithms <ref type="bibr">[Xie et al., 2019</ref><ref type="bibr">, Nguyen et al., 2022]</ref> to the simultaneous training of multiple models is not straightforward -running multiple independent instances of asynchronous FL can be suboptimal. This is because the tasks can have heterogeneous computation complexities and different data heterogeneity that affect both the number of rounds required to achieve a given target accuracy as well as the wall-clock time taken to complete each round. Since a shared set of clients is used to train the models, the training processes are coupled -more resources assigned to one task implies less for the others. Moreover, the optimal resource requirement for each task can change over time according to its data heterogeneity and training progress and may be difficult to predict before training. Therefore, we propose an adaptive algorithm that dynamically reallocates clients across tasks depending on their training progress, and also adapts the buffer size used for asynchronous aggregation of updates.</p><p>Our Contributions. We formalize the FST setting in Section 2 and then make the following main contributions:</p><p>&#8226; We introduce FedAST, a Federated Asynchronous Simultaneous Training algorithm<ref type="foot">foot_0</ref> to simultaneously train models for multiple tasks (Section 3). Our work is one of the first to mitigate the straggler problem faced by synchronous FST methods that extend vanilla FedAvg.</p><p>&#8226; The proposed algorithm addresses the problem of balancing resources across heterogeneous tasks, a unique challenge to the FST framework, using novel dynamic client allocation, and it also dynamically adjusts the buffer size used in asynchronous aggregation to strike the best trade-off between staleness and runtime.</p><p>&#8226; We provide a theoretical convergence analysis of FedAST (Section 4), which improves previous analyses even in the single-model FL setting. It improves upon <ref type="bibr">[Koloskova et al., 2022]</ref> by considering multiple local updates and the buffer, and on <ref type="bibr">[Nguyen et al., 2022]</ref> by relaxing the restrictive assumptions.</p><p>&#8226; We experimentally validate FedAST's performance (Section 5) in terms of its wall-clock training time and model accuracy on multiple real-world datasets compared to synchronous and asynchronous FL baselines.</p><p>We conclude and discuss future work in Section 6.</p><p>Related Work. Only a few recent works <ref type="bibr">[Zhou et al., 2022</ref><ref type="bibr">, Bhuyan and Moharir, 2022</ref><ref type="bibr">, Siew et al., 2023</ref><ref type="bibr">, Bhuyan et al., 2023]</ref> consider federated simultaneous training of multiple models. In <ref type="bibr">[Zhou et al., 2022]</ref>, clients are selected with either Bayesian optimization or reinforcement learning to minimize training time and unfairness in participation. <ref type="bibr">Bhuyan and Moharir [2022]</ref> formulate the client assignment FL as a bandit problem leveraging local training losses as scores. <ref type="bibr">Siew et al. [2023]</ref> introduce biased client sampling, favoring the clients with higher local losses. These methods lack convergence guarantees. <ref type="bibr">Bhuyan et al. [2023]</ref> assign clients uniformly at random or in a round-robin fashion and analyze the convergence assuming convex objective functions and bounded gradients. While these works only consider synchronous aggregation, Chang et al. <ref type="bibr">[2023]</ref> propose a fully asynchronous FST algorithm. Their approach entails solving a non-convex optimization problem to optimize client assignment, which requires information about delays and models that may be difficult to obtain in practice. Also, the obtained bound does not converge to a stationary point in the presence of data heterogeneity and suffers from increased staleness when the number of clients increases. <ref type="bibr">Lastly, Liu et al. [2023]</ref> propose an extension of their singlemodel adaptive asynchronous approach to the multi-model setting. However, they do not carefully handle heterogeneous data distributions across clients and the staleness of updates in their theoretical guarantees for a single model, and they lack these guarantees for multiple models. Also, their method under-utilizes client resources, since after sending a model update to the server, the clients are idle until the next training round.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">PROBLEM FORMULATION</head><p>Notations. For a positive integer c, we define [c] &#8796; {1, . . . , c}. &#8711; denotes stochastic gradients. Bold lowercase letters (e.g., x) denote vectors. |A| denotes the cardinality of set A. &#8741; &#8226; &#8741; denotes the Euclidean norm.</p><p>We now formally introduce the federated simultaneous training (FST) setting, where N clients train M models x 1 , . . . , x M corresponding to M independent tasks. For each task m &#8712; [M ], our goal is to find the model that solves that following optimization problem:</p><p>where f m is the global loss function for task m, and f m,i is the local loss for task m at client i.</p><p>First, we examine a simple extension of FedAvg <ref type="bibr">[McMahan et al., 2017]</ref> to simultaneous training of models for M tasks. At the start of each round, the server randomly partitions the available set of clients across the tasks <ref type="bibr">[Bhuyan et al., 2023]</ref>.</p><p>The server sends the current models {x (tm) m } M m=1 for all the tasks to the corresponding subset of clients. The clients perform local training (Algorithm 1) and return their updates to the server, which synchronously aggregates the updates for each task. This na&#239;ve simultaneous training extension of</p><p>FedAvg performs poorly due to stragglers. The time it takes for a client to return its updates depends on its resources and the size of the model assigned. Since the server waits for the slowest update across all the tasks before commencing the next round, the server waits much longer if a large model is assigned to a slow client. We mitigate this problem via asynchronous training in FedAST, discussed next.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">ALGORITHM DESCRIPTION</head><p>Next, we describe FedAST (Algorithm 2), our proposed Federated Asynchronous Simultaneous Training algorithm, illustrated in Figure <ref type="figure">1</ref> for M = 2 tasks. For each task m &#8712; [M ], the server maintains a round index t m that is initialized to t m = 0, the number of active training requests R Wait until server receives an update &#8710; m 7:</p><p>end if clients (and consequently, more training requests R m ) to tasks with larger inter-client data heterogeneity. To empirically estimate this heterogeneity, the server stores the last</p><p>where &#8710; m is the empirical mean of the &#8710; m,i 's. 3 Further, in our experiments, we empirically observe that the optimal choice of buffer size b m is proportional to the number of active requests R m . See Appendix C.5 for our extensive experiments. Using (2) and these empirical observations, the optimal resource allocation emerges as the solution to the following constraints.</p><p>where the first set of constraints maintains the total computation budget across tasks, and the second set ensures the allocation of a larger number of training requests to clients with higher heterogeneity. We elaborate on the theoretical motivation for the second set of constraints in Section 4, once we establish our convergence results. We also refer the reader to Appendix A for more details on Realloc.</p><p>Sending out New Requests to Reach the New Resource Allocation. To transition from one allocation {R Algorithm 3 Realloc(option,c) Next, we discuss the assumptions used in our analysis.</p><p>Assumption 1 (Smoothness). The loss functions are Lsmooth, i.e., for all i &#8712; [N ], for all m &#8712; [M ], and for all</p><p>Assumption 2 (Bounded Variance). The stochastic gradient at each client is an unbiased, bounded-variance estimator of the true local gradient, i.e., for all</p><p>. Assumption 3 (Bounded Heterogeneity). The local gradients are within bounded distance of the global gradient, such that for all m &#8712; [M ] and x &#8712; R dm , max</p><p>Assumption 4 (Bounded Staleness). The client updates of task m are received within at most &#947; max m server model updates after the server sends the training request.</p><p>These assumptions are standard in the literature. Assumptions 1-3 are commonly used in the synchronous <ref type="bibr">[Wang et al., 2020b</ref><ref type="bibr">, Jhunjhunwala et al., 2022]</ref> and asynchronous <ref type="bibr">[Koloskova et al., 2022</ref><ref type="bibr">, Nguyen et al., 2022]</ref> FL analyses. Assumption 4 is used in the convergence proof to guarantee that none of the requested client updates takes an arbitrarily large time to return to the server and is also common in asynchronous FL works <ref type="bibr">[Koloskova et al., 2022</ref><ref type="bibr">, Nguyen et al., 2022]</ref>. Furthermore, the maximum staleness can be enforced by dropping over-delayed updates in practice during the training.</p><p>Theorem 1 (Convergence of FedAST). Suppose that Assumptions 1 -4 hold, and there are R m active local training requests corresponding to task m &#8712; [M ], and the server and client learning rates,</p><p>Here, b m is the buffer size, and &#964; m is the number of local training steps. Then, the iterates, {{x</p><p>, of Algorithm 2 satisfy:</p><p>where</p><p>Proof. See Section E in the Appendix.</p><p>Comparison with Synchronous FL Analyses. Comparison with Asynchronous FL Analyses. FedBuff <ref type="bibr">[Nguyen et al., 2022]</ref> considers buffered asynchronous aggregation for a single model. <ref type="bibr">Still, comparing [Nguyen et al., 2022, Corollary 1]</ref> and the bound in (4) for M = 1, their convergence result (i) depends on stronger assumptions (bounded gradient norm and uniform arrivals of client updates), and (ii) has worse asynchronous aggregation error. Moreover, our analysis is more general compared to <ref type="bibr">[Koloskova et al., 2022]</ref> as they do not consider multiple local SGD steps and the buffer. Simultaneous asynchronous training is considered by <ref type="bibr">[Chang et al., 2023</ref>], but we observe that they do not achieve convergence unless the data distribution across clients is identical (see <ref type="bibr">[Chang et al., 2023, Eq. (19)</ref>]). We discuss the comparison of FedAST to single-model and simultaneous asynchronous federated training baselines in more detail in Appendix Section B.</p><p>Corollary 1.1 (Asymptotic convergence after setting learning rates).</p><p>&#8730; &#964; m b m , the bound in Theorem 1 reduces to:</p><p>Although the given bound in Corollary 1.1 does not seem to depend on the staleness bound &#947; max (Assumption 4), its effect is implicit in the number of active requests R m and buffer size b m . The maximum staleness is positively correlated with R m and negatively correlated with b m . In our experiments (Appendix C.5), we tune the buffer size to maintain the update staleness at a reasonable level.</p><p>Looking at the bounds in (4) or (5), increasing R m makes the bound worse because to reach the same accuracy in (5), we need to run a higher number of server updates T m . However, increasing R m also shortens the duration between two successive server updates, making the algorithm faster in wall-clock time. We illustrate this effect with a wall-clock comparison to FST baselines below.</p><p>Impact of R m on Wall-clock Time. Suppose the arrival times of all the client updates (assuming there is no queue on the clients) are distributed as Exp(&#955;). The expected time to fill the buffer corresponding to task m is b m /(R m &#955;). Therefore, in FedAST, the expected time to complete one round at the server is inversely proportional to R m . On the other hand, the expected time to finish one round of synchronous simultaneous FedAvg training is</p><p>, which increases with R m . Also, the summation over simultaneously trained tasks shows an exacerbated straggler effect since all the clients wait for the slowest client across all the tasks.</p><p>Design of Realloc (Algorithm 3). Next, we theoretically justify the dynamic allocation of resources across tasks described in Section 3 (Algorithm 3, with option = D), which adjusts the number of active requests ({R m } M m=1 ). Given the limited number of available clients (which limits the total number of active training requests), to achieve the best possible allocation, we minimize the sum of the most dominant terms in the bounds (FedAvg Error-II in (4)) across tasks. We also use the empirical observation that the optimal choice of buffer-size b m scales linearly with R m (Appendix C.5). The resulting optimization problem is</p><p>where R is the budget for the total number of training requests across all tasks in the system depending on the number of available clients. The Realloc function (Algorithm 3) solves the optimization problem (6). See Appendix A for more details.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">EXPERIMENTAL RESULTS</head><p>We outline our experimental setup in Section 5.1, discuss the existing baselines in Section 5.2, and compare the baselines with FedAST under varied settings in Section 5.3.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.1">DATASETS AND IMPLEMENTATION</head><p>We consider image classification tasks with the MNIST <ref type="bibr">[Deng, 2012]</ref>, Fashion-MNIST <ref type="bibr">[Xiao et al., 2017]</ref> and <ref type="bibr">CIFAR-10 [Krizhevsky et al., 2009]</ref> datasets, and next character prediction with the Shakespeare <ref type="bibr">[Caldas et al., 2019]</ref> dataset using the same models as in previous works <ref type="bibr">[Acar et al., 2021</ref><ref type="bibr">, Yu et al., 2023b</ref><ref type="bibr">, Lecun et al., 1998</ref>]. We compare the wall-clock time required by different algorithms to reach some predetermined target test accuracy levels (see Table <ref type="table">1</ref>). In Appendix D.5, we present experiments with other target accuracy levels to show the consistency of our results. We also validate our results with ResNet-18, a larger model, trained for the CIFAR-100 classification task in Appendix D.4. In all experiments, we conduct three Monte Carlo runs with different random seeds and report the average results.   30% of which are available to accept new training requests, independent of the past.</p><p>Modeling Client Delays. As suggested in <ref type="bibr">[Lee et al., 2018</ref><ref type="bibr">, Dutta et al., 2021</ref><ref type="bibr">, Shi et al., 2021</ref><ref type="bibr">, Zhou et al., 2022]</ref>, we use shifted-exponential (exponential plus constant) random variables to model the time taken by a client to complete a local training request and return the update to the server. We pick the run-time generation parameters of each task according to real measurements on NVIDIA GeForce GTX TITAN X GPUs. To simulate hardware heterogeneity across clients, we divide them into 25% slow, 50% normalspeed, and 25% fast clients <ref type="bibr">[Leconte et al., 2023]</ref>. We relegate additional implementation details to the Appendix.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.2">BASELINE ALGORITHMS</head><p>We explain the synchronous and asynchronous baseline methods to which we compare FedAST:</p><p>Synchronous Simultaneous Training. The following synchronous methods differ only in client selection. 1. Sync-ST <ref type="bibr">[Bhuyan et al., 2023]</ref>: randomly partition the client set across tasks at each round;</p><p>2. Sync-Bayes-ST <ref type="bibr">[Zhou et al., 2022]</ref>: Bayesian optimization-based assignment of clients to tasks;</p><p>3. Sync-UCB-ST <ref type="bibr">[Bhuyan and Moharir, 2022]</ref>: client selection as a multi-armed bandit problem.</p><p>In Figure <ref type="figure">2</ref>, we first simultaneously train six CIFAR-10 models and compare the performance of all synchronous baselines and FedAST. As synchronous methods perform poorly due to a severe straggler issue, we augment them with a straggler mitigation method by aggregating only the first k client updates for each task and discarding the rest <ref type="bibr">[Bonawitz et al., 2019]</ref> as the default option. We choose k = 30 by validation experiments across datasets in Appendix D.1. This extra augmentation makes the baselines more competitive. In Figure <ref type="figure">2</ref>, we also add the result of Sync-ST -NoStrag.Mit., which is the Sync-ST  Asynchronous Federated Simultaneous Training. To our knowledge, <ref type="bibr">[Chang et al., 2023]</ref> is the only other work that mainly studies asynchronous simultaneous FL. However, their client selection scheme requires the knowledge of network-wide staleness and smoothness constants, which are hard to estimate. If the tasks have similar model complexity and task difficulty, their client selection is similar to that of FedAST with a buffer size of 1. We thus include this no-buffer version of FedAST (we call it FedAST-NoBuffer) as a baseline.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.3">RESULTS AND INSIGHTS</head><p>We assess the performance of FedAST under various scenarios. In homogeneous-task experiments, where multiple independent copies of the same model are trained simultaneously using the same dataset, we report the average accuracy over time. In heterogeneous-task experiments involving differing tasks and models, efficiently distributing resources to accelerate the completion of all tasks is the main challenge.</p><p>For homogeneous tasks, we use FedAST with the static option (S) and uniform client distribution across tasks. In heterogeneous-task experiments, we use dynamic allocation (option = D) to enhance resource allocation efficiency. To  show the benefits of dynamic allocation over static allocation, we also explore heterogeneous-task scenarios with option = S. Dynamic allocation reduces overall training time by up to 11.9%, with comprehensive results shown in Appendix D.6.</p><p>To quantify the time saved by using FedAST over some competing baseline, we define time gain as</p><p>where T Baseline (T FedAST ) is the simulated time for Baseline (FedAST) to reach the target accuracy.</p><p>Comparison with All Synchronous FST Methods. First, we compare the synchronous baselines discussed in Section 5.2 on the CIFAR-10 dataset (Figure <ref type="figure">2</ref>), where we simultaneously train six identical models. We observe that synchronous methods without straggler mitigation converge very slowly. Among the stragglermitigated synchronous variants that we implement, Figure <ref type="figure">2</ref> shows that Sync-Bayes-ST, has similar performance to Sync-ST because it struggles due to the large search space of the optimization problem, stemming from the exponential number of possible client schedules. Further, we do not observe any performance gains from using Sync-UCB-ST over Sync-ST. Given that Sync-Bayes-ST and Sync-UCB-ST have similar performance as Sync-ST, in subsequent experiments, we choose Sync-ST as the sole synchronous baseline.</p><p>Need for Buffer. As discussed earlier, incorporating the buffer mitigates the negative impact of highly stale updates. Since staleness increases with the number of active clients, asynchronous FL methods without a buffer exhibit limited scalability as the number of clients grows.</p><p>To demonstrate this, in Figure <ref type="figure">3</ref>, we conduct two experiments: 1) training three models for CIFAR-10 simultaneously, and 2) training three models for Fashion-MNIST simultaneously. We plot the final accuracy values varying the ratio of the active clients. We observe that for small active client ratios, FedAST and FedAST-NoBuffer have comparable performance. However, with more active clients, the staleness of the updates increases, resulting in significantly worse performance of the fully asynchronous FedAST-NoBuffer algorithm. Then, in Figure <ref type="figure">4</ref>, we simultaneously train two models, one each for CIFAR-10 and Fashion-MNIST. Observing the unsteady learning curves of FedAST-NoBuffer, we conclude that the buffer makes the system more robust to stale updates.</p><p>Comparison with Sync-ST. Next, we compare FedAST with the chosen synchronous method, Sync-ST. 1) Homogeneous Tasks: We conduct experiments training 2, 4, and 6 identical models for each of MNIST, Fashion-MNIST, CIFAR-10, and Shakespeare datasets. Figure <ref type="figure">5</ref> shows the average finish times of the algorithms, and the significant time gains of our algorithm FedAST over synchronous Sync-ST (even after incorporating straggler mitigation). We observe that the gain increases with the number of simultaneously trained tasks because Sync-ST is especially vulnerable to the straggler problem.</p><p>2) Heterogeneous Tasks: The heterogeneous experiment trains 4 models simultaneously, one each for the MNIST, Fashion-MNIST, CIFAR-10, and Shakespeare datasets.</p><p>Once one model reaches its target accuracy, its training stops, and its clients are reallocated to other tasks. We use FedAST with option = D for dynamic client allocation.</p><p>For the synchronous baseline Sync-ST, we ran 30 different client allocation schemes, including our proposed allocation scheme and uniform allocation across tasks. We report the results achieved with the best-performing scheme.</p><p>Figure <ref type="figure">6</ref> shows learning curves for FedAST and Sync-ST from a single Monte Carlo run. The dashed vertical lines denote the time instants when a model reaches its target accuracy, following which the clients training this model get reallocated to other tasks. Figure <ref type="figure">7</ref> shows the average finish times for 4 simultaneously trained models with FedAST and Sync-ST. For example, with FedAST, the model for MNIST dataset hits its target accuracy at 99, after which the clients training this model get reallocated to the other models. At 619, the training of the final model (for CIFAR-10) is complete. Comparing the finish times for the last model, FedAST provides a 40.1% time gain over Sync-ST.</p><p>We observe that thanks to dynamic client allocation, FedAST automatically detects which tasks have higher heterogeneity across clients and need a larger buffer. We notice that the Shakespeare task is allocated fewer clients because it is estimated to be less heterogeneous, which is true based on the label distribution of data samples across clients. We also repeat this experiment (Appendix D.6) using FedAST with static option (S) to validate the proposed dynamic client allocation strategy. Dynamic client allocation consistently has time gain up to 11.9% compared to the static version.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6">CONCLUSION</head><p>In this paper, we present FedAST, a federated learning framework to simultaneously train multiple models using buffered asynchronous aggregations. We theoretically prove </p><p>Further, given the limited number of available clients, we cannot increase the total number of active local training requests arbitrarily without increasing the staleness. Thus, we employ M m=1 R m = R where R is a constant of how many active training requests we assign in total depending on the number of available clients in the setting. Since the goal of federated simultaneous training is to minimize the objective functions of all tasks concurrently, we propose to adjust {R m } M m=1 by solving,</p><p>The solution of the minimization problem in (7) suggests allocating local training requests, {R m } M m=1 , in proportion to &#963; g,m &#8730; &#951; s m &#951; c m &#964; m for each model m. Using this approach, Algorithm 3 adjusts resource allocation. Further, as the update variance across clients may vary in time during training, we employ adaptive periodical reallocation of resources across models (Line 1 in Algorithm 3). Therefore, we use round indices to denote the changing number of active training requests and buffer sizes.</p><p>As we do not have access to true data heterogeneity levels, we need to estimate it (Line 2 in Algorithm 3). When FedAST is run with option = D (dynamic client allocation option), the server keeps the latest V updates of each model. This requires constant and small memory space kept in the server. To present how variance estimation (EstimateVariances()) works, assume that {&#8710; m,1 , &#8710; m,2 , . . . , &#8710; m,V } M m=1 are the sets of latest received updates of tasks m &#8712; [M ] where each &#8710; m,k for k &#8712; [V ] is the output of k th latest local training (Algorithm 1). As the output of any local training is the average of all calculated stochastic gradients during that local training, we use those outputs as approximations of the gradients calculated on the local data of clients. Algorithm 4 describes EstimateVariances(). It first calculates the mean of the latest updates for each task,</p><p>Then, EstimateVariances() returns sample variance multiplied with other terms (&#951; s m &#951; c m &#964; m ) suggested by ( <ref type="formula">7</ref>) and normalized by the mean update norm (to prevent large models or models with inherently large weights from dominating others),</p><p>Then, Realloc algorithm allocates the number of active training requests proportionally to the square root of these values (Algorithm 3, Line 3). This approach is sensible both theoretically and intuitively. Based on our experimental observations regarding the relationship between the number of active training requests and buffer size, increasing the number of active local training requests necessitates an increase in buffer size. Moreover, a larger buffer proves beneficial in reducing the variance across updates, Algorithm 4 EstimateVariances() Require: The set of latest V updates {&#8710; m,1 , &#8710; m,2 , . . . , &#8710; m,V } M m=1 , server-side learning rates {&#951; s m } M m=1 , client-side learning rates {&#951; c m } M m=1 , and the number of local SGD steps of all models {&#964; m } M m=1 .</p><p>&#9655; Calculate the means of the latest updates</p><p>&#9655; Multiply with other constants suggested by the convergence guarantee (7) 4: Return {&#963; 2 g,m }</p><p>the buffered updates are averaged during the aggregation. Realloc aims to allocate more clients and provide a larger buffer size for tasks with higher heterogeneity. We choose the number of stored latest updates V = 8 and the period of number of total updates from all clients to trigger reallocation in Realloc subroutine c period = 0.75 &#215; M &#215; M m=1 R m in our experiments. The benefits of dynamic allocation (option = D) over static and uniform resource allocation (option = S) are demonstrated when tasks/models are heterogeneous, as shown in Figures <ref type="figure">21</ref><ref type="figure">22</ref><ref type="figure">23</ref><ref type="figure">24</ref><ref type="figure">25</ref><ref type="figure">26</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>B THEORETICAL COMPARISON OF FedAST WITH BASELINES</head><p>We compare FedAST with single-model FL methods, too. <ref type="bibr">[Nguyen et al., 2022]</ref> is the most similar algorithm to FedAST (with single-model). However, even for the single-task case, FedAST differs by employing a uniform client assignment to ensure unbiased participation of clients irrespective of their hardware speeds. This allows us to relax the assumptions to prove the convergence guarantee. <ref type="bibr">[Nguyen et al., 2022]</ref> relies on a strong assumption that the server receives updates from clients uniformly at random and that the norm of gradients is bounded. Moreover, compared to <ref type="bibr">[Koloskova et al., 2022]</ref>, our analysis is more general as FedAST uses multiple SGD steps in local training and a buffer. Some other recent single-model asynchronous FL works, <ref type="bibr">[Zakerinia et al., 2023]</ref> and <ref type="bibr">[Leconte et al., 2023]</ref>, do not have straightforward and efficient simultaneous federated training extensions for multiple models.</p><p>[ <ref type="bibr">Chang et al., 2023]</ref> is another asynchronous simultaneous federated learning method. However, <ref type="bibr">[Chang et al., 2023]</ref> indeed fails to converge to a stationary point asymptotically unless data is homogeneous, and their assumptions include Bounded Gradient Norm and Weak Convexity. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C EXPERIMENTAL SETUP DETAILS</head><p>In our study, we explore a simultaneous federated learning (FL) setting for multiple models. We present the details of our experiments in this section.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C.1 SIMULATION ENVIRONMENT</head><p>We simulate the training with PyTorch on NVIDIA GeForce GTX TITAN X graphics processing units (GPUs) of our internal cluster. We build our code upon the public codes of <ref type="bibr">[Wang et al., 2020a</ref><ref type="bibr">, Yu et al., 2023b]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C.2 SETTING OVERVIEW</head><p>We consider the federated training of M models simultaneously using N clients. N is 1000 in all experiments and M , specified for each experiment explicitly, varies between 2 -6.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C.3 TASKS AND MODELS</head><p>We </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C.4 DATASETS AND DATA DISTRIBUTION</head><p>We consider the data heterogeneity across clients in FL frameworks. We download MNIST, Fashion-MNIST, and CIFAR-10/100 datasets from PyTorch built-in library methods. The train and test splits provided by the library are used without any modifications. To simulate heterogeneous data distribution across clients, we use Dirichlet distribution with &#945; = 0.1 following the approach suggested in Yurochkin et al. <ref type="bibr">[2019]</ref>. We ensure that each client has 300 data points for MNIST, Fashion-MNIST, and CIFAR-10/100 tasks by repeating the train set if necessary. We obtain and preprocess the Shakespeare dataset as described in <ref type="bibr">[Caldas et al., 2019]</ref>. This dataset has inherently heterogeneous distribution across clients as each client corresponds to a unique role from Shakespeare's plays.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C.5 DESIGN PARAMETERS</head><p>In this section, we explain how we choose the design parameters.</p><p>Client dataset sizes, batch sizes, and number of local steps. While distributing CIFAR-10/100, MNIST, and Fashion-MNIST datasets across clients, each client is allocated 300 data points from each dataset. The Shakespeare dataset, however, maintains its original distribution of data points across roles, so clients have different numbers of data samples in the Shakespeare task. For CIFAR-10/100, MNIST, and Fashion-MNIST tasks, we set the batch size to 32 while we employ a batch size of 64 for the Shakespeare task. We fix the number of local steps in local training (&#964; m parameter in Algorithm 1 in the main text) of clients at 27 for all tasks. This makes 3 epochs for CIFAR-10/100, MNIST, and Fashion-MNIST tasks. As the number of data points varies across clients for the Shakespeare dataset, there is no fixed number of epochs. m ) when we use dynamic client allocation option (D). A higher number of simultaneous local training requests leads to a higher staleness because it increases the global model's update frequency at the server. On the other hand, buffer size is inversely related to staleness, given its opposing effect on the aggregation frequency. Based on our experimental observations, selecting the number of active training requests and the buffer size of model m such that their ratio is fixed and below 37, (R m /b m &#8818; 37 or R (tm) m /b tm m &#8818; 37), works well. Selecting the buffer size of FedAST based on this observation avoids the detrimental effects of stale updates while benefiting from fast training thanks to the asynchronous algorithm. We show two experimental results in Figures <ref type="figure">8</ref> and<ref type="figure">9</ref>. In Figure <ref type="figure">8</ref>, we train one Fashion-MNIST and one CIFAR-10 models simultaneously by assigning 175 active training requests to each task and observe that buffer size of 5 strikes a balance between high final test accuracy and fast training to achieve the target accuracy for both tasks. In Figure <ref type="figure">9</ref>, we repeat a similar experiment with MNIST and CIFAR-10 tasks by assigning 105 active training requests to each. This time, we observe that a buffer size of 3 performs the best for both tasks. These experimental results support our buffer size choice. Learning rate and weight decay. We search for the best learning rate and weight decay hyperparameters considering the training speed and final accuracy levels. We seek client-side learning rate within the range of [1 &#215; 10 -3 , 1 &#215; 10], server-side learning rate within [3 &#215; 10 -2 , 3], and weight decays within [1 &#215; 10 -7 , 1 &#215; 10 -2 ]. We observe that client-side learning rates of 6 &#215; 10 -2 and 7 with weight decays of 3 &#215; 10 -4 and 7 &#215; 10 -5 work best respectively for Fashion-MNIST and Shakespeare tasks for all methods. For CIFAR-10 task, a client-side learning rate of 1 &#215; 10 -1 with weight decays of 7&#215;10 -4 and 3&#215;10 -4 perform best for asynchronous and synchronous methods, respectively. For MNIST, we use client-side learning rates of 1 &#215; 10 -1 and 2 &#215; 10 -1 for asynchronous and synchronous methods, respectively, with a weight decay of 3 &#215; 10 -4 . For server-side learning rates, we observe that 1 for synchronous methods (Sync-ST, Sync-Bayes-ST, and Sync-UCB-ST), 0.1 for FedAST, and 0.038 for FedAST-NoBuffer perform well for all tasks.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>C.6 MODELING TRAINING TIMES, MODEL SIZES, AND CLIENT SPEED HETEROGENEITY</head><p>In our experiments, following <ref type="bibr">[Lee et al., 2018</ref><ref type="bibr">, Shi et al., 2021</ref><ref type="bibr">, Zhou et al., 2022</ref><ref type="bibr">, Dutta et al., 2021]</ref>, we employ the shifted-exponential random variables to model the duration between when the server sends a local training request to a client, and when it receives the update of the local training. The exponential component of the distribution reflects the stochastic nature of the device speeds, while the shift component accounts for unavoidable delays such as disk I/O operations.</p><p>Whenever a client i performs local training for task m, we draw a random number from the distribution with a cumulative distribution function (CDF) of,</p><p>where &#946; i,m depends on the speed of client i and the size of the model associated with task m. Then, we multiply this random number by the number of local steps to calculate the simulation time between when the server requests for the local training, and when it receives the update back.</p><p>We quantify the effect of the model sizes based on the average time required to calculate one stochastic gradient for each model on the GPUs of our internal cluster. By our measurements, we set,</p><p>In our experiments, we also take the heterogeneity in the speed of client devices into consideration. We categorize clients into three speed groups: slow (%25), normal-speed (%50), and fast (%25). The speed rates for these categories are inversely proportional to 1.3, 1, and 0.7, such that,</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D ADDITIONAL EXPERIMENTS</head><p>In this section, we present supplementary experiments.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D.1 TUNING PARAMETER k OF THE STRAGGLER MITIGATION TECHNIQUE USED FOR SYNCHRONOUS METHODS (ACCEPTING ONLY THE FIRST-k UPDATES)</head><p>In our experiments, to mitigate the high straggler effect, the server in synchronous methods (Sync-ST, Sync-Bayes-ST, and Sync-UCB-ST) only aggregates the first k client updates for each task and discards the rest, following <ref type="bibr">[Bonawitz et al., 2019]</ref>. To tune parameter k, we run validation experiments with Sync-ST on single CIFAR-10, MNIST, and Fashion-MNIST tasks and evaluated the training performance with respect to simulated time and number of global rounds.</p><p>A larger k results in a longer simulated time per round since we wait for more clients. On the other hand, the variance in aggregated updates on each round becomes smaller since we average more updates. Therefore, the target accuracy is attained faster in terms of the number of global rounds. We also observed that keeping k too small yields lower final accuracy. Navigating these trade-offs, we find that k = 30 strikes an effective balance.  </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D.2 TEST LOSS PLOTS OF FIGURES 3 AND 4 IN THE MAIN TEXT</head><p>We illustrate test loss plots of the experiments in Figures <ref type="figure">3</ref> and<ref type="figure">4</ref> in the main text.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>20% 30% 40% 50% 60%</head><p>The ratio of active clients  </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D.3 TRAINING CURVES OF HOMOGENEOUS EXPERIMENTS</head><p>In Figure <ref type="figure">15</ref>, we provide the average training curves of the homogeneous-task experiment in Figure <ref type="figure">5</ref>.   </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D.5 EXPERIMENTS WITH DIFFERENT TARGET ACCURACY LEVELS</head><p>To see how FedAST and the competitor Sync-ST work with different target accuracy, we conduct the experiment in Figure <ref type="figure">7</ref> with +3% higher and -10% lower target accuracy levels as presented in Table <ref type="table">3</ref>. We observe that proposed FedAST reduces the overall training time by 55.9% and 16.3%, respectively for higher and lower target accuracy levels.</p><p>We conclude that the advantage of FedAST over Sync-ST increases with the difficulty of the task (i.e., reaching higher accuracy).   <ref type="table">3</ref>. Dashed vertical lines show times when tasks reach their target accuracy. The setting is the same as the experiment in Figure <ref type="figure">7</ref>.  <ref type="table">3</ref>. The setting is the same as the experiment in Figure <ref type="figure">7</ref>.  <ref type="table">3</ref>. Dashed vertical lines show times when tasks reach their target accuracy. The setting is the same as the experiment in Figure <ref type="figure">7</ref>.   <ref type="table">3</ref>. The setting is the same as the experiment in Figure <ref type="figure">7</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D.6 PERFORMANCE OF FedAST WITHOUT STATIC RESOURCE ALLOCATION</head><p>We conduct heterogeneous-task experiments to validate the performance gain of dynamic resource allocation (FedAST (D)) over static option (FedAST(S)) with uniform allocation across tasks in heterogeneous settings. For uniform resource allocation, we allocate the same number of active training requests to each task in FedAST(S). To show the consistency of our results, we run experiments at all target accuracy levels in Table <ref type="table">3</ref>. We present the results in Figure <ref type="figure">22</ref> (higher target accuracy), Figure <ref type="figure">24</ref> (the target accuracy in the main text), and Figure <ref type="figure">26</ref> (lower target accuracy). We conclude that our dynamic client allocation based on the variance estimates of the updates reduces the total training time compared to the uniform static client allocation. The advantage of dynamic resource allocation becomes more prominent with more difficult tasks (i.e., higher target accuracy level).   <ref type="table">3</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E PROOFS OF THE CONVERGENCE ANALYSIS OF FedAST WITH STATIC OPTION (S)</head><p>In this section, we present the proofs of the mathematical claims made in the paper. First, we define and explain the notations used in this section. After that, we introduce intermediate lemmas used in the main proof (Section E.2). Then, we present the proofs of Theorem 1 and Corollary 1.1 (Section E.3). Finally, we prove intermediate lemmas (Section E.4). ). The setting is the heterogeneous experiment with lower target accuracy levels in Table <ref type="table">3</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.1 NOTATIONS AND DEFINITIONS</head><p>FedAST enables us to divide the convergence analyses of simultaneous tasks into individual ones. We focus on the convergence analysis of a single task within a simultaneous multi-model setting and the analysis holds for all tasks trained together. For brevity, we provide the proofs for a single task of multiple models trained simultaneously. Therefore, we drop all model indices in our analysis. We also drop time indices from the number of active requests (R) and buffer size (b) terms as they remain the same during the training with the static option of FedAST. Table <ref type="table">4</ref> summarizes all notation. Please note that the analysis presented here holds for every model m &#8712; [M ] simultaneously trained within FedAST framework.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.1.1 The Update Rules of FedAST</head><p>We first revisit the local training and global update rules of FedAST. The notation may vary slightly from those in the main paper due to dropping model indices, but still accurately depicts the same algorithmic procedures, Algorithms 1 and 2 in the main text.</p><p>Local update rule. During local training, clients perform &#964; consecutive local stochastic gradient steps and return the output to the server. When a client receives the t th version of the global model, x (t) , it takes &#964; mini-batch stochastic gradient descent steps (for k = 1, . . . , &#964; ) with following rule:</p><p>where t) and &#8711; denotes stochastic gradients. We define the average of local stochastic gradients as</p><p>. Then, the client returns</p><p>i to the server. The server stores the updates in a buffer.</p><p>Staleness. The server receives the updates of local training requests asynchronously. It means that the received updates may come in a different order than local training requests sent to clients. Therefore, an aggregated update may have been calculated with an older version of the model, and this is called staleness. We quantify the staleness of an update in terms of the number of global rounds passed between the times when the server sends the local training request and receives the update. The staleness is random for each update, depending on client selections for all tasks and all clients' availability, computation, and communication speeds. We denote the staleness of client i's update received at the server at the t th round as &#947; t i . Recall that Assumption 4 (Bounded Staleness) bounds this random value above at &#947; max .</p><p>Global update rule. On each global round t, when the buffer at the server, B (t) , is full (|B (t) | = b, where b is the buffer size), the server aggregates the updates to proceed to the next global round. Here, B (t) is the set of clients whose updates are received after (t -1) th and before t th aggregation. The aggregation rule can be written as follows:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.1.2 Virtual Sequence and Set Definitions</head><p>We utilize the perturbed iterate idea from <ref type="bibr">Koloskova et al. [2022]</ref>, <ref type="bibr">Mania et al. [2017]</ref>.</p><p>First, let us introduce some helpful sets and notations. Consider A (t) , which represents the set of clients chosen by the server to receive the t th version of the model. Recall that the server in FedAST selects the clients uniformly at random with replacement from all clients. The size of this set, |A (t) |, is always equal to the buffer size, b, (except initialization, t = 0) because b new local training requests are made on each round. For instance, if b is set to 3, and the server selects the 2 nd , 16 th , and 31 st clients during the 4 th aggregation round, then A (4) is {2, 16, 31}. The server sends x (4) to the 2 nd , 16 th , and 31 st clients and requests local training with this model. In practical terms, A (t) is a multiset, allowing multiple occurrences of the same client if a client is selected more than once. Throughout the proof, we consider each occurrence of the same client in multiset as a distinct update calculated on that particular client. While we acknowledge a slight abuse of notation, this does not lead to any mathematical flaw, and we believe that this significantly enhances the clarity and comprehensibility of the proof. Now, let us define C (t) as the set of clients that have incomplete local training requests at the time of the t th aggregation because of the asynchronous nature of FedAST. The size of this set, |C (t) |, is always equal to the number of active local training requests, R, because the server sends a new local training request for every update it receives. For instance, if R is 4, and the server has sent local training requests to the 12 th , 27 th , 41 st , and 55 th clients prior to the 5 th aggregation, yet these clients are still processing their updates, then C (5) would be {12, 27, 41, 55}. Note that C (0) is an empty set, as there are no active local training requests before the algorithm starts. It is worth noting that C (t) is a multiset, allowing multiple occurrences of the same client if a client has more than one active local training request (recall that multiple requests are queued at the client side). Each occurrence of a client within this multiset represents a different local training calculated on that client. We again acknowledge a slight abuse of notation, but this does not lead to any mathematical flaw, and we believe that this makes the flow of proof significantly easier.</p><p>Next, we define the virtual sequence z (t) for t = 0, 1, . . . , T as the model that receives local training updates of the global model, x (t) for t = 0, 1, . . . , T , in the correct order. Namely, unlike x (t) , z (t) receives the local training updates in the order in which the server sends those requests. However, it is crucial to note that the local training updates are still calculated with the global model, x (t) . The update rule of the virtual sequence is:</p><p>for t = 0, 1, . . . , T -1 where z (0) &#8796; x (0) .</p><p>Remark 1. Now, we state an observation using the definitions of C (t) , the virtual sequence, and the global model. When the t th aggregation happens at the server, the virtual sequence, z (t) , has received all the updates from all previous local training requests on rounds 0, 1, . . . , t -1. At the same time, the global model, x (t) , has received the same updates except for the updates of clients in C (t) . By the update rules in ( <ref type="formula">9</ref>) and ( <ref type="formula">10</ref>), note that each received update at the server contributes to the global model and virtual sequence equally. Therefore, we can express their difference as:</p><p>Remark 2. If we count the number of occurrences of the round index y among the model versions of assigned updates in set C (t) over all rounds t = 0, . . . , T -1, we can bound this value as:</p><p>where 1 is an indicator function that returns 1 if the statement is true, and returns 0 otherwise. The reasoning for this observation is as follows. On each round, the server selects b clients (since the server selects one new client for each received and buffered update where the buffer size is b) and sends them the up-to-date global model. We also know that all local training requests must be returned to the server within &#947; max rounds by Assumption 4 (Bounded Staleness). Therefore, over the rounds t = 0, . . . , T -1, any round indices can appear at most b&#947; max times in the summation in the left-hand side of the inequality in ( <ref type="formula">12</ref>). We will use this remark later in the proof.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.1.3 Notation</head><p>We define some useful variables used in the proof and present the notation used in FedAST in Table <ref type="table">4</ref>. Also, we again want to remind the reader that we dropped all model indices in the proof as the theoretical results we present here hold for any of multiple tasks trained simultaneously, satisfying Assumptions 1 -4. </p><p>The set of clients which are requested local training, but have not returned their updates to the server yet (Section E.1.2)</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.2 INTERMEDIATE LEMMAS</head><p>We present intermediate lemmas used through the proof.</p><p>Lemma 1. For a set of Q vectors, u 1 , . . . , u Q , where Q is a positive integer,</p><p>Proof. The lemma is a direct consequence of Jensen's inequality with a convex function &#8741;&#8226;&#8741; 2 and uniform random distribution over the set of vectors u 1 , . . . , u Q .</p><p>Lemma 2. Suppose that f i (&#8226;) satisfies Assumption 1 (Smoothness) and Assumption 2 (Bounded Variance) for all i &#8712; [N ], and assume that &#951; c &#8804; 1 L&#964; . Then the iterates of FedAST satisfy,</p><p>where D &#8796; L 2 &#951; 2 c &#964; (&#964; -1). Further, suppose Assumption 3 (Bounded Heterogeneity) holds. Then, the iterates of FedAST satisfy,</p><p>Remark 3. The true gradient at any client using the global model is close to the local update of that client.</p><p>Lemma 3. The iterates of FedAST and defined virtual sequence satisfy,</p><p>Lemma 4. Suppose that f i (&#8226;) satisfies Assumption 2 (Bounded Variance and Unbiased Stochastic Gradients) for all i &#8712; [N ], then the iterates of FedAST satisfy,</p><p>Remark 4. The noisy global update due to stochastic gradients is close to the expected update calculated with full gradients. The buffer and multiple local steps are useful to reduce the variance due to local SGD steps.</p><p>Lemma 5. The iterates of FedAST satisfy,</p><p>Further, suppose Assumption 3 (Bounded Heterogeneity) holds. Then, the iterates of FedAST also satisfy,</p><p>Remark 5. FedAST benefits the global variance reduction thanks to the buffer.</p><p>Lemma 6. The virtual sequence and the iterates of FedAST satisfy,</p><p>Remark 6. As discussed in Remark 1, although the virtual sequence and global model get updates in a different order, they receive the same updates. Therefore, we can bound their difference.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.3 PROOFS OF MAIN STATEMENTS</head><p>We present and prove Theorem 1 and Corollary 1.1 here.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.3.1 Theorem 1 (Convergence bound)</head><p>First we restate the theorem: </p><p>Proof. Using the update rule of the virtual sequence (10) and Assumption (Asm.) 1 (Smoothness), and taking the conditional expectation with respect to z (t) , we have,</p><p>Using Lemmas 3 and 4, we can bound T 1 and T 2 . Then, dividing both sides by &#951; s &#951; c :</p><p>Using Lemma 5, we can bound T 3 :</p><p>where D &#8796; L 2 &#951; 2 c &#964; (&#964; -1). Using the tower property of conditional expectation, telescoping the inequality over the round indices t = 0, 1, . . . , T -1, and using Lemma 6, we get,</p><p>Suppose the learning rates satisfy &#951; s &#8804; &#8730; &#964; b (which also makes &#951; s &#8804; &#964; &#8730; &#964; b) and &#951; c &#8804; min</p><p>&#964; R&#947; max , the following inequality holds:</p><p>Also, notice that z (0) is equal to x (0) by definitions (Section E.1.2) of these sequences and min x f (x) &#8804; f z (T ) .</p><p>Define &#948; &#8796; f x (0) -min x f (x). After reducing high-order terms using the assumptions, &#951; s &#8804; &#8730; &#964; b (which also makes</p><p>&#964; R&#947; max , and incorporating the constants into the O(&#8226;) notation, we have:</p><p>This concludes the proof. T . Then, the bound in Theorem 1 reduces to:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>E.4 PROOFS OF INTERMEDIATE LEMMAS</head><p>Proof of Lemma 2. We borrow the proof technique from <ref type="bibr">[Wang et al., 2020b, C.5</ref>].</p><p>Using the recursive appearances of T recursive in ( <ref type="formula">14</ref>) and ( <ref type="formula">15</ref>):</p><p>Arranging the terms, defining D &#8796; L 2 &#951; 2 c &#964; (&#964; -1), and assuming &#951; c &#8804; 1 L&#964; which makes D &#8804; 1,</p><p>This proves the first part of Lemma 2. Now, averaging it across clients:</p><p>This concludes the proof of Lemma 2.</p><p>Proof of Lemma 3.</p><p>Proof of Lemma 4.</p><p>where (a) follows that the clients in A (t) are selected uniformly at random with replacement among all clients (see Section E.1.2), and (b) follows that t) . This proves the first part of Lemma 5.</p><p>Proof of Lemma 6. We start by using Assumption 1 (Smoothness) and Remark 1.</p><p>Telescoping the inequality over t = 0, . . . , T -1: Global update rule and virtual sequence definition. Although the local update rule remains the same, the global update rule slightly changes for dynamic client allocation due to changing buffer size: t) . Note that ( <ref type="formula">17</ref>) is almost identical to (9), except the varying buffer-size b (t) . Next, we define r i (t) as the index of the global round when a local training request sent to client i in round t returns to the server. Basically, it is the current round index t, added to the future value of staleness that the requested update will have. We need to define a new virtual sequence y (t) , which is different from the z (t) defined earlier.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>F CONVERGENCE OF</head><p>for t = 0, 1, . . . , T -1 where y (0) &#8796; x (0) . Here, A (t) is defined similarly as it was in Section E.1.2. Note that the probability of being in A (t) is equal across clients due to uniform client selection. However, this time, the size of this set does not have to be equal to the buffer size at round t. Due to the new client selection rule (Line 13 in Algorithm 2), the server may assign 0, 1, or 2 clients for each received update. Therefore, we know that 0 &lt; |A (t) | &#8804; 2b (t) .</p><p>Here, we need a simplifying assumption for the purpose of this proof:</p><p>Assumption 5 (b ri(t) Values). We assume that any b ri(t) value is known at the time when a local training request is sent to client i at round t, and these values are independent of any future information including the received updates. We further assume that b ri(t) values are equal (denote b r(t) ) for all clients in A (t) .</p><p>Remark 7. When we keep the period of dynamic client allocation long enough, we observe that most of the assigned local training requests at one round fall in the same window before the next dynamic client allocation happens (Line 8 in Algorithm 2). Hence, based on our empirical observations, what assumption implies holds for most of the local training requests. Further, this assumption can be avoided by taking an average of the updates during aggregation weighted inversely with the number of local training requests sent at the same global round. In other words, one may have avoided this assumption by weighting an update from client i with 1/|A (t-&#947; t i ) | instead of taking average over buffer during aggregation at round t. However, we did not see any practical benefit of this type of weighting in our experiments, and this strange weighting would be just for theoretical purposes. Therefore, we keep the current version.</p><p>We first state the theorem showing the convergence of FedAST with dynamic client allocation option.</p><p>Theorem 2. (Convergence of FedAST with option = D): Suppose Assumptions 1 -5 hold, and the learning rates satisfy</p><p>Then, the iterations of Algorithm 1 (FedAST) with option = D satisfy:</p><p>Proof.</p><p>We will need one extra lemma corresponding to Lemma 6.</p><p>Lemma 7. The new virtual sequence y (t) and the iterates of FedAST satisfy,</p><p>Now, using the update rule of the virtual sequence (18) and Assumption 1 (Smoothness), and taking the conditional expectation with respect to y (t) , we have, E f y (t+1) &#8804; f y (t) + &#8711;f y (t) , E y (t+1) -y (t) + L 2 E y (t+1) -y (t) 2 = f y (t) + &#8711;f y</p><p>(Using Assumption 5)</p><p>(</p><p>Next, using Lemma 3 (with y (t) sequence) and Lemma 4 (with |A (t) |), using 1/&#961; b &#8804; |A (t) |/b r(t) &#8804; 2&#961; b , and dividing both sides by &#951; s &#951; c we obtain,</p><p>Using Lemma 5, we get,</p><p>where D &#8796; L 2 &#951; 2 c &#964; (&#964; -1). Using tower property of conditional expectation, telescoping the inequality over the round indices t = 0, 1, . . . , T -1, and using Lemma 7, we get,</p><p>Suppose the learning rates satisfy &#951; s &#8804; &#961; &#964; R&#947; max , the following inequality holds:</p><p>Also, notice that y (0) is equal to x (0) by definitions (Section F) of these sequences and min x f (x) &#8804; f y (T ) .</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">T</head><p>T -1 t=0 E &#8711;f x (t) 2 &#8804; 11 f x (0) -min x f (x) T &#951; s &#951; c &#961; b (Using ( <ref type="formula">19</ref>))</p><p>Define &#948; &#8796; f x (0) -min x f (x). After reducing high-order terms using the assumptions, &#951; s &#8804; &#961; This concludes the proof.</p><p>Proof of Lemma 7: We start by using Assumption 1 (Smoothness) and observing that Remark 1 still holds with y (t) for the dynamic client allocation option.</p><p>Telescoping the inequality over t = 0, . . . , T -1:</p><p>(Using Remark 2, however, this time,)</p><p>(the maximum appearance can be 2&#947; max b max )</p><p>(Using Remark 2)</p></div><note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0"><p>Our code is provided at https://github.com/ askinb/FedAST.</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_1"><p>Processing the requests in parallel would require clients to keep all the M models in local memory, which can be infeasible.</p></note>
		</body>
		</text>
</TEI>
