Server-Effective Privacy Enhancement in Federated Learning

Abstract

Techniques are disclosed for training a global model using gradients provided by a collection of client devices to a remote system during a reporting window, wherein each client device randomly determines a reporting time within the reporting window to provide the gradients to the remote system. Various embodiments include each client device determining a corresponding gradient by processing data using a local model stored locally at the client device, wherein the local model corresponds to the global model.

Description

Background Art

[0001] The data used to train the global model can be distributed across many client devices. Federated learning techniques can use this distributed data to train the global model. For example, each client device can generate gradients by processing data using a local model stored locally on the client device. These gradients can be used to train the global model without requiring the data used to generate the gradients. In other words, the data used to train the global model can be stored locally on the device by transmitting the gradients used to update the global model (without transmitting the data itself). Summary of the Invention

[0002] The technology disclosed herein involves training a global model using data generated locally at a collection of client devices (e.g., gradients generated locally at each client device using a local model stored locally at each corresponding client device), where the client devices provide update data at response times selected by each client device. In other words, the global model can be updated based on randomness independently generated by each individual client device participating in the training process.

[0003] In some embodiments, a remote system (e.g., a server) can select a set of client devices for updating a global model. For example, the remote system can randomly (or pseudo-randomly) select the set of client devices. Additionally or alternatively, the remote system can determine a reporting window for receiving updates (e.g., gradients) from the selected client devices. The remote system can transmit the reporting window to each of the selected client devices, and each of the client devices can determine a reporting time within the reporting window to provide updates to the remote system. For example, the remote system can select client devices A and B from a group of client devices A, B, C, and D for updating a global model. The remote system can determine a reporting window from 9:00 AM to 9:15 AM. Client device A can determine (e.g., randomly or pseudo-randomly) a reporting time of 9:03 AM within the reporting window. At 9:03 AM, client device A can provide the remote system with gradient A generated by processing data using a corresponding local model stored locally at client device A. The remote system can use gradient A to update one or more portions of the global model. Similarly, client device B can determine (e.g., randomly or pseudo-randomly) a reporting time within the reporting window of 9:10 a.m. At 9:10 a.m., client device B can transmit to the remote system gradient B generated by processing the data using a corresponding local model stored locally at client device B. The remote system can use gradient B to update one or more portions of the global model.

[0004] Additionally or alternatively, in some embodiments, at 9:03 AM, client device A can provide a gradient A' generated by processing data using the global model to the remote system. The remote system can use gradient A' to update one or more portions of the global model. Similarly, at 9:10 AM, client device B can transmit a gradient B' generated by processing data using the global model to the remote system. The remote system can use gradient B' to update one or more portions of the global model.

[0005] Additionally or alternatively, each client device selected from the set of client devices can determine whether to participate in training the global model. For example, the selected client device can determine (e.g., by a virtual coin flip) whether to participate in a round of training the global model. If the client device determines to participate, the client device can then determine a reporting time and transmit locally generated gradients to the remote system at the reporting time. Additionally or alternatively, if the client device determines not to participate, the client device may not determine a reporting time and / or not transmit locally generated gradients to the remote system.

[0006] In some embodiments, the remote system can determine a set of first client devices corresponding to a first reporting window and a set of second client devices corresponding to a second reporting window. For example, data from client devices around the world can be used to update the global model. In some embodiments, the set of first client devices can be selected based on the geographic location of the client devices (e.g., client devices physically located in the same city, state, time zone, country, continent, and / or group(s) of client devices based on additional or alternative locations). Additionally or alternatively, the reporting window can be determined based on device availability at the corresponding physical location (e.g., when most client devices are available but idle in the middle of the night and / or additional or alternative reporting window(s)). In some embodiments, the remote system can determine the set of second client devices based on a second physical location. Similarly, the second reporting window can be determined based on device availability in the second physical location.

[0007] Thus, various embodiments describe techniques for ensuring privacy when training a global model using distributed data generated locally at many client devices. Classical techniques require significant server-side overhead to train a global model using distributed data while maintaining data privacy. In contrast, data privacy is coordinated at the client devices, and the techniques disclosed herein require little or no server-side coordination to protect data privacy when training a global model. Consequently, data privacy can be enhanced while reducing server-side resource usage (e.g., processor cycles, memory, power consumption, etc.).

[0008] Additionally or alternatively, the client device can randomly determine the time to transmit locally generated gradients to the server within a reporting window. Selecting the number of client devices and the size of the reporting window can ensure that the server receives gradients at a fairly constant rate. In other words, allowing the client device to randomly select reporting times within a sufficiently large reporting window can result in a uniform distribution of gradients throughout the reporting window. This uniform distribution of gradients can ensure that network resources are not overwhelmed when training the global model. For example, a uniform distribution of gradients can ensure more even utilization of network bandwidth and can prevent spikes in bandwidth utilization that prevent the system from receiving gradients, more even memory and / or processor usage that can prevent spikes in the system from (temporarily) processing additional gradients, and / or more even utilization of additional or alternative network resources. Additionally or alternatively, more even utilization of network resources increases the number of gradients that can be immediately used to train the global model, thereby limiting the number of gradients that need to be queued for later training.

[0009] The above description is provided only as an overview of some embodiments disclosed herein. These and other embodiments of the technology are disclosed in additional detail below.

[0010] It should be understood that all combinations of the foregoing concepts and additional concepts described in more detail herein are considered to be part of the subject matter disclosed herein. For example, all combinations of the claimed subject matter appearing at the end of this disclosure are considered to be part of the subject matter disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 An example environment is described in which embodiments described herein may be implemented.

[0012] Figure 2 An example of training a global model according to various embodiments described herein is described.

[0013] Figure 3 is a flow chart illustrating an example process for training a global model at a remote system according to various embodiments disclosed herein.

[0014] Figure 4 is a flow chart illustrating an example process for transferring gradients from a client device to a remote system according to various embodiments disclosed herein.

[0015] Figure 5 An example architecture of a computer system is schematically depicted. DETAILED DESCRIPTION

[0016] Differentially private stochastic gradient descent (DP-SGD) can form a fundamental building block for learning about sensitive data in many applications. Two standard methods, privacy amplification through subsampling and privacy amplification through shuffling, can allow for adding lower noise to DP-SGD than through naive schemes. The key assumption in both methods is that the elements in the dataset can be uniformly sampled or arranged—constraints that can become prohibitive when the data is processed in a decentralized or distributed manner.

[0017] Iterative methods such as DP-SGD can be used in the setting of federated learning (FL), where data is distributed across multiple devices (clients). In some embodiments, a (multiple) random check-in distributed protocol can be utilized, which may rely only on random participation decisions made locally and independently by each client. Random check-in can have similar privacy / accuracy trade-offs as privacy amplification through subsampling / shuffling. However, random check-in may not require server-initiated communication and / or knowledge of the population size.

[0018] Privacy amplification via random check-in is tailored for distributed learning frameworks and can have broader applicability beyond FL. In some embodiments, privacy amplification via shuffling can be extended to incorporate (∈, δ)-DP local randomizers and improve their guarantees. In practical scenarios, this improvement can allow similar privacy and utility using data from orders of magnitude fewer users.

[0019] Modern mobile devices and web services can significantly benefit from large-scale machine learning, which often involves training on user (client) data. When such data is sensitive, measures must be taken to ensure privacy, and formal guarantees of differential privacy (DP) are perhaps the gold standard.

[0020] Other privacy-enhancing techniques can be combined with DP to achieve additional benefits. For example, cross-device federation (FL) can allow model training while keeping client data decentralized (each participating device maintains its own local dataset and only sends model updates or gradients to the coordination server). However, existing approaches that combine FL and DP make many assumptions that may not be realistic in real-world FL deployments.

[0021] Previous attempts have been made to combine FL and DP research. However, these works and others in the field circumvent a key issue: DP guarantees require very specific sampling or shuffling schemes, for example, assuming that each client participates with a fixed probability in each iteration. While theoretically possible, these schemes are incompatible with the practical constraints and design goals of cross-device FL protocols; citing a comprehensive FL survey, "this sampling procedure is nearly impossible in practice." The fundamental challenge is that the client decides when it is available for training and when it can log in to the server, and by design, the server cannot index specific clients. In fact, it may not even know the size of the participating population.

[0022] The embodiments described herein address these challenges. One goal is to provide strong central DP guarantees for the final model published by FL-like protocols under the assumption of a trusted coordination server. This can be achieved by building on recent work on amplification with shuffling and / or combining it with new analysis techniques for FL-specific challenges (e.g., client-initiated communication, unaddressable global populations, and limited client availability).

[0023] Some embodiments include privacy amplification analysis tailored for distributed learning frameworks. In some embodiments, this can include a novel technique called random check-in, which relies on randomness generated independently by each individual client participating in the training process. It can be shown that distributed learning protocols based on random check-in can achieve privacy gains similar to privacy amplification through subsampling / shuffling, while requiring minimal coordination from the server. While the embodiments disclosed herein are described with respect to distributed DP-SGD within the FL framework, it should be noted that the techniques used are broadly applicable to any distributed iterative method.

[0024] Some embodiments described herein include the use of random check-in, a privacy amplification technique for distributed systems with minimal server-side overhead. Some embodiments can include formal privacy guarantees for our protocol. Additionally or alternatively, it can be shown that random check-in can achieve similar privacy amplification as subsampling and shuffling, while reducing the need for server-side coordination. Furthermore, some embodiments include utility guarantees in the convex case, which can match the optimal privacy / accuracy trade-off of DP-SGD in the central setting. Furthermore, as a byproduct, some embodiments can improve privacy amplification through shuffling. In the case of having ∈n-DP local randomizers, the dependence of the final central DP∈ can be reduced by a factor of Additionally or alternatively, embodiments disclosed herein can extend the analysis to the case where a (∈0, δ0)-DP local randomizer is used. This improvement can be crucial in practice because it allows shuffling protocols based on a wider family of local randomizers, including Gaussian local randomizers.

[0025] In order to introduce the concept of privacy, we define adjacent datasets. If we can modify a sample d of a certain i∈[n] i ∈D obtains D′ from D, then a pair of data sets D, D′, ∈D n They can be called neighbors.

[0026] In some embodiments, if for any pair of adjacent datasets D, D′∈D n And for all events in output range A We make Pr[A(D)∈S′]≤e ε .Pr[A(D′)∈S′]+δ, then differential privacy can be defined as: randomized algorithm A: D n →S is (∈, δ) — differential privacy.

[0027] For meaningful central DP guarantees (i.e., when n>1), ∈ can be assumed to be a small constant and δ<<1 / n. The case δ=0 is often called pure DP (in which case it can be written as ε-DP). Additionally or alternatively, when δ>0, the term roughly DP can be used. Adaptive differential privacy mechanisms naturally arise when constructing complex DP algorithms for, for example, DP-SGD. In addition to the dataset D, the adaptive mechanism also receives as input the outputs of other differential privacy mechanisms. Formally, if for each s′∈S′, the mechanism A(s′, ·) is (∈, δ)-DP, then the adaptive mechanism A: S′ x D n → S is (∈, δ)-DP. In some embodiments, using n=1 gives a local randomizer, which can provide local DP guarantees. Local randomizers can be a building block of local DP protocols, where individuals privatize their data before sending it to an aggregator for analysis.

[0028] As an illustrative example, in some embodiments, a distributed learning setting may involve n clients, where each client j∈[n] is capable of storing a data record d j ∈D, j∈[n], thus forming a distributed data set D=(d1,...,d n In some embodiments, it can be assumed that the coordination server wants to train the parameters θ∈θ of the model using the dataset D to train the model according to a certain loss function l: Dxθ→R +Perform a stochastic gradient descent step. The goal of the server is to protect the privacy of all individuals in D by providing strong DP guarantees, preventing an adversary from observing the final trained model and all intermediate model parameters. In some embodiments, it can be assumed that the server is trusted, all devices adhere to the prescribed protocol (i.e., there are no malicious users), and all server-client communications are privileged (i.e., they cannot be detected or eavesdropped by an external adversary).

[0029] The server can start with model parameters θ1 and generate a series of model parameters θ2, ..., θ over a series of m time slots. m+1 The random check-in technique allows clients to independently decide when to contribute to the model update. If and when the server accepts a client’s contribution, it uses the current parameters θ and its data d to update the model in the form The privatized gradient is sent to the server, where A Idp is a DP local randomizer (e.g., performs gradient clipping and adds Gaussian noise).

[0030] Results of Some Implementations Three different settings inspired by real-world applications are considered: (1) The server uses m < < n time slots, where at most one user update is used in each time slot for a total of m / b mini-batch SGD iterations. It can be assumed that all n users are available for the duration of the protocol, but the server does not have enough bandwidth to process updates from each user; (2) The server uses m ≈ n / b time slots, and all n users are available for the duration of the protocol. On average, b users contribute updates to each time slot, so m mini-batch SGD steps can be taken; (3) As in (2), but each user is only available for a small time window related to the duration of the protocol.

[0031] In some embodiments, privacy-amplified random check-ins can be used in the context of distributed learning. Consider the distributed learning setting described in Section 2, where each client is willing to participate in the training process as long as their data remains private. To improve the privacy of the client by the local randomizer A Idp To provide privacy guarantees, clients can voluntarily update at any time slot of their choosing. This randomization has a similar effect on the uncertainty of individual data used in a particular update as the uncertainty provided by uniform subsampling or shuffling. Informally, random check-ins can be represented as clients in a distributed iterative learning framework that randomize their participation times and decide with some probability whether to participate at all.

[0032] In some embodiments, random check-in can be formally defined as Let A be a distributed learning protocol with m check-in slots. For the set and probability p j∈[0, 1], if client j has probability p j Request the server to execute the command at time step I←uarR j Participate in A, then the client executes the protocol (R j , p j ) sign in, otherwise give up participation. j =1, then it can be alternatively expressed as R j Check in.

[0033] Algorithm 1 (below) presents a distributed learning protocol based on random check-in according to some embodiments. Client j performs (R j , p j ) checks in independently to decide which possible time steps (if any) she is willing to participate in. For all j∈[n], we set R j = [m], and assume that all n clients are available throughout the duration of the protocol. On the server side, at each time step i∈[m], query a random client J among all clients that checked in at time i i : This client receives the current model θ i , use their data Locally compute gradient updates And the local randomizer A will be used Idp A privatized version of the obtained gradients is returned to the server. Clients that checked in at time i but were not selected do not participate in the training process. If there are no clients available at time i, the server adds "dummy" gradients to update the model.

[0034] Algorithm 1 — Distributed DP-SGD with random check-ins (fixed window)

[0035] Algorithm 1 — Server-side Protocol

[0036] Parameters: Local randomizer A ldp : Θ→Θ, total update step m

[0037] Initialize the model θ1∈R p

[0038] Initialize the gradient accumulator g1←0 p

[0039] For i∈[m], execute

[0040] S i ←{j:User(j)check-ins for index i}

[0041] If S i If it is empty,

[0042] / / Virtual gradient

[0043] otherwise

[0044] Sampling J i uar←S i

[0045] Request User(J i ) for the model θ i Make an update

[0046] From User(J i )take over

[0047] (θ i+1 , g i+1 )←Mode Update

[0048] Output θ i+1

[0049] Algorithm 1 — Client-side protocol for user (j)

[0050] Parameter: Check-in window R j , check-in probability p j , loss function l, local randomizer A Idp

[0051] Private input: data point d j ∈D

[0052] If p j -The biased coin returns heads, then

[0053] At time uar←R j Server Sign-in

[0054] If the received model θ I To make an update request,

[0055]

[0056] Will Send to server

[0057] Algorithm 1 — Model Update (θ, g, i)

[0058] Parameters: batch size b, learning rate η

[0059] If imod b=0, then

[0060] return / / Gradient descent step

[0061] otherwise

[0062] return (θ, g) / / skip update

[0063] From a privacy perspective, Algorithm 1 shares an important pattern with DP-SGD: each model update uses noisy gradients obtained from a random subset of the population. However, there are factors that make privacy analysis of random check-in more challenging than existing analyses based on subsampling and shuffling. First, unlike when the randomness in each update is independently and uniformly sampled, there is a correlation here because a client checking in at one step cannot check in at another. Second, with shuffling, similar correlation exists between updates, but here we are able to ensure that each update uses the same number of data points, and here the server does not control the number of clients that will check in at each individual step. Nevertheless, the results below show that random check-in provides a privacy amplification factor comparable to these techniques.

[0064] Theorem 3.2 (Amplification via random check-ins into a fixed window) Assume A ldp is a ε0-DP local randomizer. Let A fix :D n →θ m For each client j∈[n], there is a check-in probability p j = p0 and check-in window R j = [m] The protocol of Algorithm 1. For any δ∈(0,1), Algorithm A fix is (ε,δ)-DP, where Specifically, for ε0≤1 and We obtain In addition, if A ldp is (ε0, δ0)-DP,

[0065] in

[0066] Then A ftx is (ε′, δ′)-DP,

[0067] in

[0068] And δ′=δ+m(e e′ +1)δ0.

[0069] Remark 1 - In some embodiments, the privacy of the above statement can be increased by reducing p0. However, this may also increase the number of virtual updates, which suggests choosing p0 = Θ(m / n). With this choice, an amplification factor of Crucially, however, one does not need to know the population size exactly to obtain the precise DP guarantees mentioned above.

[0070] Note 2 - First Look, Magnification Factor seems better than the typical one obtained via uniform subsampling / shuffling The factor is stronger. Note that a random check-in may provide m updates (compared to n updates via the other two methods). When the server has enough capacity, we can set m=n to recover In some embodiments, one advantage of random check-ins can be that even if the number of updates actually processed is much smaller, it can still benefit from amplification about the full n. In some embodiments, by adaptively fix Repeat n / m times to obtain the following inference and apply high-level synthesis for DP, even when the server is rate-limited (p0=m / n), random check-ins can be extended to recover enlarge.

[0071] Corollary 3.3. For Algorithm A described in Theorem 3.2 fix :D n →Θ m , assuming A ldp is an ε0-DP local randomizer such that and set up And run A ftx of repetitions result in a total of n updates, and an overall central (ε, δ)-DP, where and δ∈(0,1), where Hide the polynomial logarithmic factors in 1 / β and 1 / δ.

[0072] In some embodiments, we can provide a utility analysis of random check-ins. First, we can provide a bound on the expected number of "virtual" updates during the execution of the algorithm described in Theorem 3.2. The result is described below in Proposition 3.4.

[0073] Proposition 3.4 (Dummy updates in random check-ins using fixed windows). For Algorithm A described in Theorem 3.2 fix :D n →Θ m , the expected number of virtual updates performed by the server is at most For c>0, if We get at most An expected virtual update.

[0074] Utility of Convex ERMs — We now instantiate our amplification theorem (Theorem 3.2) in the context of differentially private empirical risk minimization (ERM). For convex ERMs, we can show that DP-SGD combined with the privacy amplification theorem (Theorem 3.2) may be able to achieve the best privacy / accuracy trade-off.

[0075] Theorem 3.5 (Utility Guarantee). Assume that the algorithm A described in Theorem 3.2 ftx :D n →Θ m In the loss is L-Lipschitz and convex in its second parameter and model space Θ with dimension p and diameter R, i.e. sup θ，θ′∈Θ ||θ-θ′||≤R. In addition, yes The distribution on the population risk is defined And make If A lap is the Gaussian noise with variance σ 2 The local randomizer is added and the learning rate of the model update at step i∈[m] is set to Then from A generated for a dataset D containing n iid samples fix (D) Output θ m satisfy In some embodiments, Hide the polynomial logarithmic factors in m.

[0076] Note 3 - It should be noted that when m→n, It is easy to see that Theorem 3.5 achieves the optimal population-risk trade-off.

[0077] This section presents two variants of the main protocol from the previous section. The first variant makes better use of updates provided by each user, but at a slightly increased privacy cost. The second variant allows users to check in a sliding window to model the situation where different users may be available during different time windows.

[0078] In some embodiments, (multiple) variants of Algorithm 1 can be utilized that remove the need for dummy updates at the expense of a slight increase in privacy and / or discard all but one client checking in at each time step. The server-side protocol for this version is given in Algorithm 2 (the client-side protocol is the same as Algorithm 1). Note that in this version, if no client has checked in at a certain step i∈[m], the server simply skips the update. Furthermore, if multiple clients have checked in at a certain time i∈[m], the server requests gradients from all clients and uses the average of the submitted noisy gradients to perform the model update.

[0079] These changes may have the advantage of reducing noise in the model from virtual updates and improving the data efficiency of the algorithm by leveraging gradients provided by all available clients. The corresponding privacy analysis becomes more challenging because (1) the adversary obtains information about time steps at which no clients checked in, and (2) the server uses the potentially non-private count |S of clients that checked in at time i when performing model updates. i |. However, it can be shown that the privacy guarantees of Algorithm 2 are similar to those of Algorithm 1, but with an additional Factors and the restriction that participating clients do not collude. For simplicity, we only analyze the case where each client has a check-in probability p j =1.

[0080] Algorithm 2 — A avg Server-side protocol:

[0081] Parameter: Total update step m

[0082] Initialize the model θ1∈R p

[0083] For i∈[m], execute

[0084] S i ←{j:User(j))check-ins for index i

[0085] If S i If it is empty,

[0086] θ i+1 ←θ i

[0087] otherwise

[0088]

[0089] For j∈S i ,implement

[0090] Request User(j) to model θ i Make an update

[0091] Receive from User(j)

[0092]

[0093] Output θ t+1

[0094] Theorem 4.1 (Amplification via random check-ins with average updates). Assume A ldpis a ε0-DP local randomizer. Let A avg :D n →Θ m is the check-in probability p for each user j∈[n] j = 1 and check-in window R j = [m] The protocol of Algorithm 2 that executes m average model updates. Algorithm A avg is (ε, δ+δ2)-DP, where in Specifically, for ε0≤1, we obtain In addition, if A ldp is (ε0, δ0)-DP,

[0095] in,

[0096] Then A avg is (ε′, δ′)-DP,

[0097] in

[0098] And δ′=δ+δ2+m(e e′ +1)δ1. Our convex ERM on excess population risk provides A avg Utility guarantee of (similar to Theorem 3.5).

[0099] Theorem 4.2 (Utility guarantee of Algorithm 2). Assume that the algorithm described in Theorem 4.1 loss is L-Lipschitz and convex in its second parameter and model space Θ with dimension p and diameter R, i.e. sup θ，θ′εθ ||θ-θ′||≤R. In addition, yes distribution, defining population risk And make If A Idp is the Gaussian noise with variance σ 2 The local randomizer is added, and the learning rate of the model update at step i∈[m] is set to Then from A generated for a dataset D containing n iid samples avg (D) Output θ m satisfy Furthermore, if the loss l is β-smooth in its second parameter and we set the step size Then we make

[0100] Comparison of the effectiveness of Algorithm 2 with that of Algorithm 1: Recall that in Afix We can do this by taking p0 = m / n and For a small fixed ε, in which case the excess risk bound in Theorem 3.5 becomes On the other hand, in A avg In the to obtain a fixed small ε. In this case, the excess risk in Theorem 4.2 is obtained in the convex case by bounded, and in the convex and smooth case by Thus, we observe that as m→n and for m<<n, all bounds recover the optimal population-risk tradeoff, and the unsmoothed loss A fix Provide A avg Better trade-off while smoothing the loss A avg and A fix It should be noted that A ftx (where b = 1) does not yield a better bound on the smooth loss, since each update is based on a single data point. fix , setting b>1 reduces the number of updates to m / b, however if more than one data point is sampled at each time step, then to obtain a smooth loss A fix The excess risk bound for will require extending the privacy analysis to incorporate the changes.

[0101] The second variant we consider removes the requirement that all clients be available for the entire training period. Instead, we assume that the training period consists of n time steps, and each client j∈[n] is available only during a window of m time steps. Clients perform random check-ins to provide updates to the server during their availability window. For simplicity, we assume that clients j∈[n] wake up sequentially, one per time step, so a client will be available in window R j ={j, ..., j+m-1). The server will perform n-m+1 updates starting from time m to provide a warm-up period in which the first m clients perform their random check-ins.

[0102] Theorem 4.3 (Amplification via random check-ins with a smoothing window). Assume A ldp is the ε0-DP local randomizer. For each user j∈[n], the check-in probability p j = 1 and check-in window R j ={j,...,j+m-1} performs a distributed algorithm for n model updates. For any m∈[n], Algorithm A sldw is (ε,δ)-DP, where For ε0<1 and δ<1 / 100, we obtain In addition, if A ldp is (ε0, δ0)-DP,

[0103] in,

[0104] Then A sldw is (ε′, δ′)-DP,

[0105] in

[0106] And δ′=δ+nm(e e′ +1)δ1.

[0107] Remark 4—We can always increase the privacy of the above statement by increasing m. However, this may also increase the number of clients that are not participating in training, because their scheduled check-in time is before the process starts or after the process ends. In addition, the number of empty time slots where the server introduces dummy updates will also increase, which we want to minimize for good accuracy. Therefore, m can introduce a trade-off between accuracy and privacy.

[0108] Proposition 4.4 (Dummy Updates in Random Check-ins Using Sliding Windows). For Algorithm A described in Theorem 4.3 sldw :D n →θ n-m+1 , the expected number of virtual gradient updates performed by the server is at most (n-m+1) / e.

[0109] In some embodiments, privacy amplification can be improved by shuffling. This can be achieved by strengthening the analysis of exchange amplification, which is a central part of shuffle amplification analysis.

[0110] Theorem 5.1 (Amplification via shuffling). is a family of adaptive ε0-DP local randomizers. Let In a given data set Calculate s sequentially by sampling uniform random permutations π through [n] i =A (i) (s 1：i-1 , d π(i) ) and output s 1m For any δ∈(0,1), Algorithm A sl Satisfies (ε, δ)-DP,

[0111] in

[0112] In addition, if A (i) , i∈[n] is (ε0, δ0)-DP,

[0113] in

[0114] Then A sl Satisfies (ε′, δ′)-DP,

[0115] in

[0116] And δ′=δ+n(e e′ +1)δ1.

[0117] For comparison, in the case of δ0=0, the guaranteed generation in some prior art

[0118]

[0119] The rapid growth of connectivity and information sharing has accelerated the adoption of stricter privacy regulations and better privacy-preserving techniques. Therefore, training machine learning models on decentralized data using mechanisms with formal privacy guarantees is highly desirable. However, despite the rapid acceleration of research in both DP and FL, only a small fraction of production ML models are trained using either technique. The implementation described in this paper takes an important step toward addressing this gap.

[0120] For example, embodiments disclosed herein highlight the fact that proving DP guarantees for distributed or decentralized systems can be substantially more challenging than for centralized systems because, in the distributed world, accurately controlling and characterizing randomness in the system can become much more difficult, and such accurate characterization and control of randomness is central to DP guarantees. Specifically, production FL systems do not satisfy the assumptions typically made under state-of-the-art privacy accounting schemes, such as privacy amplification via subsampling. Without such accounting schemes, service providers cannot provide DP claims with small ε. While largely theoretical in nature, embodiments disclosed herein propose an approach informed by the practical constraints of distributed systems that allows for rigorous privacy claims under realistic assumptions.

[0121] Now refer to the figure, Figure 1An example environment 100 is illustrated in which embodiments described herein may be implemented. The example environment 100 includes a remote system 102 and a client device 104. The remote system 102 (e.g., a server) is remote from one or more client devices 104. In some embodiments, the remote system 102 may include a global model training engine 106, a client device engine 108, a report window engine 110, a global model 112, and / or additional or alternative engine(s) or model(s) (not depicted). In some embodiments, the client device 104 may include a report engine 114, a gradient engine 116, a local model 118, and / or additional or alternative engine(s) or model(s) (not depicted).

[0122] In some embodiments, the remote system 102 can communicate with one or more client devices 104 via one or more networks, such as a local area network (LAN) and / or a wide area network (WAN) (e.g., the Internet). In some embodiments, the client devices 104 can include user interface input / output devices, which can include, for example, a physical keyboard, a touch screen (e.g., implementing a virtual keyboard or other text input mechanism), a microphone, a camera, a display screen, and / or speaker(s). The user interface input / output devices can be integrated with one or more client devices 104 of a user. For example, a user's mobile phone can include user interface input / output devices; a stand-alone digital assistant hardware device can include user interface input / output devices; a first computing device can include user interface input device(s), and a separate computing device can include user interface output device(s), etc. In some embodiments, all or aspects of the client devices 104 can be implemented on a computing system that also includes user interface input / output devices. In some embodiments, client device 104 may include an automated assistant (not depicted), and all or aspects of the automated assistant may be implemented on a computing device(s) that is separate and remote from the client device containing the user interface input / output devices (e.g., all or aspects may be implemented "in the cloud"). In some of these embodiments, aspects of the automated assistant may communicate with the client device via one or more networks, such as a local area network (LAN) and / or a wide area network (WAN) (e.g., the Internet).

[0123] Some non-limiting examples of client devices 104 include one or more of the following: a desktop computing device, a laptop computing device, a stand-alone hardware device dedicated at least in part to an automated assistant, a tablet computing device, a mobile phone computing device, a vehicle computing device (e.g., an in-vehicle communication system and an in-vehicle entertainment system, an in-vehicle navigation system, an in-vehicle navigation system), or a user's wearable device including a computing device (e.g., a user's watch with a computing device, a user's glasses with a computing device, a virtual or augmented reality computing device). Additional and / or alternative computing systems may be provided. Client devices 104 may include one or more memories for storing data and software applications, one or more processors for accessing data and executing applications, and other components that facilitate communication over a network. Operations performed by client devices 104 may be distributed across multiple computing devices. For example, computing programs running on one or more computers at one or more locations may be coupled to each other over a network.

[0124] like Figure 1 , the local model 118 can be a local model stored locally at the client device 104 that corresponds to the global model 112. For example, the global model 112 can be a global automatic speech recognition ("ASR") model for generating a textual representation of a spoken utterance, and the local model 118 can be a corresponding ASR model stored locally at the client device 104. Additionally or alternatively, the global model 112 can be a global text prediction model for predicting one or more words as a user types, and the local model 118 can be a corresponding local text prediction model stored locally at the client device 104. Additional or alternative global models and corresponding local models can be used in accordance with the techniques described herein.

[0125] The global model training engine 106 can be used to refine the global model 112. In some embodiments, the global model training engine 112 can process gradients received from one or more client devices 104 at a particular time step and update one or more portions of the global model 112 based on the received gradient(s). For example, in some embodiments, the remote system 102 can receive gradients from a single client device at a time step. The global model training engine 106 can update one or more portions of the global model 112 based on the received gradients. Additionally or alternatively, the remote system 102 can receive multiple gradients from multiple client devices at a single time step (e.g., receiving gradients from each of two client devices, three client devices, and five client devices, ten client devices, and / or an additional or alternative number of client devices). In some embodiments, the global model training engine 106 can select one of the received gradients (e.g., select the first received gradient, select the last received gradient, randomly (or pseudo-randomly) select one of the received gradients, and / or select the received gradient using one or more additional or alternative processes) for use in updating one or more portions of the global model 112. Additionally or alternatively, the global model training engine 106 can update one or more portions of the global model 112 based on more than one of the received gradients (e.g., averaging the gradients received within a time step, averaging the first three gradients received within a time step, etc.). Furthermore, in some embodiments, the global model training engine 106 can update one or more portions of the global model 112 based on each of the received gradients within a time step (e.g., storing the received gradients in a buffer and updating portion(s) of the global model 112 based on each of the received gradients).

[0126] The client device engine 108 can be configured to select the set 104 of client devices. In some embodiments, the client device engine 108 can select each available client device. In some embodiments, the client device engine 108 can select (e.g., randomly or pseudo-randomly) a set of client devices (e.g., select the set of client devices from the available client devices). Additionally or alternatively, the client device engine 108 can select a subset of client devices based on the physical location of the devices, based on historical data indicating device availability, and / or based on additional or alternative characteristics of the device(s). In some embodiments, the client device engine 108 can determine the number of client devices to select (e.g., the client device engine 108 can randomly or pseudo-randomly determine the number of client devices to select). In some embodiments, the client device engine 108 can determine a plurality of sets of client devices. For example, the client device engine 108 can determine a set of two client devices, a set of three client devices, a set of five client devices, a set of ten client devices, a set of one hundred client devices, and / or additional or alternative numbers of client devices.

[0127] The reporting window engine 110 of the remote system 102 can be used to determine a time frame for each selected client device to update the remote system 102. For example, the reporting window engine 110 can determine the size of the reporting window based on the number of client devices selected by the client device engine 108 (selecting a reporting window size that is large enough for the selected number of client devices). Additionally or alternatively, the reporting window can be selected based on historical data indicating when the selected client devices were communicating with the remote system but were otherwise idle. For example, the reporting window engine 110 can select a reporting window in the middle of the night when the devices are more likely to be idle.

[0128] In some embodiments, the reporting engine 114 of the client device 104 can determine whether to provide gradients to the remote system 102 for updating the global model 112 and / or determine a reporting time within a reporting window (e.g., a reporting window generated using the reporting window engine 110) to provide gradients. For example, the reporting engine 114 can determine whether to participate in the current round of training (e.g., randomly determine whether to participate). If the reporting engine 114 determines to participate, the reporting engine 114 can randomly determine a reporting time within the reporting window for the client device 104 to provide gradients to the remote system 102. Conversely, if the reporting engine 114 determines not to participate in training, then no reporting time may be selected from the reporting window and / or no gradients may be transmitted to the remote system 102 within the reporting window.

[0129] In some embodiments, the gradient engine 116 can be used to generate gradients to provide to the remote system 102 for updating the global model 112. In some embodiments, the gradient engine 116 can process data generated locally at the client device 104 using the local model 118 to generate an output. Additionally or alternatively, the gradient engine 116 can generate gradients in a supervised and / or unsupervised manner based on the generated output. For example, the global model 112 and the local model 118 can be a global ASR model and a corresponding local ASR model, respectively. Audio data capturing the spoken utterance can be processed using the local ASR model to generate a candidate text representation of the spoken utterance, the audio data being captured using a microphone of the client device 104. In some embodiments, the client device 104 can prompt the user who spoke the utterance to inquire whether the candidate text representation correctly captures the spoken utterance, and if not, the user can correct the text representation. The gradient can be determined based on the difference between the candidate text representation of the spoken utterance and the corrected text representation of the spoken utterance. As another example, the global model 112 and the local model 118 can be predictive text models for predicting text based on input provided by the user (e.g., for predicting the next word(s) as the user types). In some embodiments, the current document can be processed using a predictive text model to generate candidate next text. The system can determine whether the next text typed by the user matches the candidate next text. In some embodiments, a gradient can be determined based on the difference between the next text typed by the user and the candidate next text. The gradient engine 116 can generate the gradient at the client device 104 using additional or alternative techniques.

[0130] Figure 2 An example 200 of updating a global model according to embodiments disclosed herein is illustrated. In the illustrated example, at step 202, the remote system 102 can select a set of client devices including client device A 104A and client device N 104N. In some embodiments, the remote system 102 can use Figure 1 The client device engine 108 selects a set of client devices. At step 204, the remote system 102 can determine a reporting window indicating a time frame for client devices A and N to provide global model updates. In some embodiments, the remote system 102 can use Figure 1 The reporting window engine 110 of the remote system 102 can determine the reporting window. Additionally or alternatively, at step 206, the remote system 102 can transmit the reporting window to the client device A 104A and the client device N 104N.

[0131] At step 208, the client device A 104A can determine the reporting time within the reporting window received from the remote system 102. In some implementations, the client device A 104A can use Figure 1 The reporting engine 114 of the client device A 104A can determine the reporting time. At step 210, the client device A 104A can transmit the gradient A to the remote system 102. In some embodiments, the client device A 104A can use the gradient engine 116 to determine the gradient A. For example, the gradient A can be generated by processing data using a local model that is stored locally at the client device A and corresponds to the global model. At step 212, the remote system 102 can use the gradient A received from the client device A 104A to update one or more parts of the global model. In some embodiments, the remote system 102 can use Figure 1 The global model training engine 106 uses the gradient A to update the global model 112.

[0132] Similarly, at step 214, the client device N 104N can determine the reporting time within the reporting window received from the remote system 102. In some implementations, the client device N 104N can use Figure 1 The reporting engine 114 of the client device N 104N can determine the reporting time. At step 216, the client device N 104N can transmit the gradient N to the remote system 102. In some embodiments, the client device N 104N can use the gradient engine 116 to determine the gradient N. For example, the gradient N can be generated by processing data using a local model that is stored locally at the client device N and corresponds to the global model. At step 218, the remote system 102 can use the gradient N received from the client device N 104N to update one or more parts of the global model. In some embodiments, the remote system 102 can use Figure 1 The global model training engine 106 uses the gradient N to update the global model 112.

[0133] Figure 2 These are illustrative examples only and are not meant to be limiting. For example, the remote system 102 can receive gradients from additional or alternative client devices, the client devices can determine reporting times in the same step (e.g., client device A determines its corresponding reporting time, while client device N determines its corresponding reporting time), multiple devices can select the same reporting time, etc.

[0134] Figure 3300 is a flowchart illustrating a process 300 for training a global model using a remote system according to various embodiments disclosed herein. For convenience, the operations of the flowchart are described with reference to a system performing the operations. This system may include various components of various computer systems, such as remote system 102, client device 104, and / or one or more components of computing system 510. Furthermore, while the operations of process 300 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, and / or added.

[0135] At block 302, the system selects a set of client devices from a plurality of client devices at a remote system. In some embodiments, the system can use Figure 1 The client device engine 108 may be used to select a set of client devices. Additionally or alternatively, in some embodiments, the system may be able to select a set of multiple client devices.

[0136] At block 304, the system determines a reporting window at the remote system that indicates a time frame for the set of client devices to provide one or more gradients to update the global model. In some embodiments, the system can use Figure 1 The reporting window engine 110 determines the reporting window.

[0137] At block 306 , the system transmits the report window to each client device in the set of selected client devices.

[0138] At block 308, the system receives the locally generated gradients at the remote system and at the corresponding reporting time. In some embodiments, the corresponding reporting time can be determined by each client device in a reporting window. In some embodiments, each locally generated gradient can be generated by processing data generated locally at the corresponding client device using a local model stored locally at the corresponding client device. In some embodiments, each client device can generate the locally generated gradients according to the method described herein. Figure 1 The process 400 transmits the corresponding gradients to a remote system.

[0139] At block 310 , the system updates one or more portions of the global model based on the received gradients.

[0140] Figure 44 is a flowchart illustrating a process 400 for transmitting gradients from a client device to a remote system for updating a global model, according to embodiments disclosed herein. For convenience, the operations of the flowchart are described with reference to a system performing the operations. This system may include various components of various computer systems, such as remote system 102, client device 104, and / or one or more components of computing system 510. Furthermore, while the operations of process 400 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, and / or added.

[0141] At block 402 , the system receives a report window at a client device from a remote system, the report window indicating a time frame for the client device to provide gradients to update a global model.

[0142] At block 404, the system generates a gradient by processing data generated locally at the client device using a local model stored locally at the client device, wherein the local model corresponds to the global model. In some embodiments, the system can use Figure 1 The gradient engine 116 is used to generate the gradient.

[0143] At block 406, the system determines a reporting time within the reporting window. In some embodiments, the system can randomly (or pseudo-randomly) select a reporting time within the reporting window. In some embodiments, the system can use Figure 1 The reporting engine 114 determines the reporting time.

[0144] At block 408 , the system transmits the generated gradients to a remote system at a reporting time.

[0145] Figure 5 5 is a block diagram of an example computing device 510 that can optionally be used to perform one or more aspects of the techniques described herein. The computing device 510 generally includes at least one processor 514 that communicates with a number of peripheral devices via a bus subsystem 512. These peripheral devices may include a storage subsystem 524, which includes, for example, a memory subsystem 525 and a file storage subsystem 526, a user interface output device 520, a user interface input device 522, and a network interface subsystem 516. The input and output devices allow for user interaction with the computing device 510. The network interface subsystem 516 provides an interface to an external network and couples to corresponding interface devices in other computing devices.

[0146] The user interface input device 522 may include a keyboard, a pointing device such as a mouse, trackball, touchpad, or graphic tablet, a scanner, a touch screen incorporated into a display, an audio input device such as a voice recognition system, a microphone, and / or other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and methods for inputting information into the computing device 510 or over a communication network.

[0147] The user interface output device 520 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visual image. The display subsystem may also provide a non-visual display, such as via an audio output device. Generally, the use of the term "output device" is intended to include various possible types of devices and methods for outputting information from the computing device 510 to a user or another machine or computing device.

[0148] The storage subsystem 524 stores programming and data structures that provide the functionality of some or all of the modules described herein. For example, the storage subsystem 524 may include a Figure 3 、 Figure 4 The logic of selected aspects of the processes of, and / or other processes described herein.

[0149] These software modules are typically executed by processor 514 alone or in combination with other processors. The memory subsystem 525 used in the storage subsystem 524 can include multiple memories, including a main random access memory (RAM) 530 for storing instructions and data during program execution and a read-only memory (ROM) 532 in which fixed instructions are stored. The file storage subsystem 526 can provide persistent storage for program and data files and can include a hard drive, a floppy disk drive and associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules implementing the functionality of certain embodiments can be stored by the file storage subsystem 526 in the storage subsystem 524, or in other machines accessible to the processor(s) 514.

[0150] The bus subsystem 512 provides a mechanism for the various components and subsystems of the computing device 510 to communicate with each other as intended. Although the bus subsystem 512 is shown schematically as a single bus, alternative implementations of the bus subsystem may use multiple busses.

[0151] The computing device 510 can be of various types, including a workstation, server, computing cluster, blade server, server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, the Figure 5 The description of the computing device 510 depicted in FIG is intended only as a specific example for illustrating some embodiments. Many other configurations of the computing device 510 may have more Figure 5 The computing devices depicted may have more or fewer components.

[0152] Where the systems described herein collect personal information about users (or generally referred to herein as "participants"), or where personal information may be utilized, users may be provided with the opportunity to control whether programs or features collect user information (e.g., information about the user's social network, social behavior or activities, occupation, the user's preferences, or the user's current geographic location), or to control whether and / or how content that may be more relevant to the user is received from content servers. Furthermore, certain data may be processed in one or more ways prior to storage or use such that personally identifiable information is removed. For example, the user's identity may be processed such that no personally identifiable information about the user can be determined, or where geographic location information is available, the user's geographic location may be generalized (e.g., to a city, zip code, or state level) such that the user's specific geographic location cannot be determined. Thus, users may have control over how information about the user is collected and / or used.

[0153] In some embodiments, a method implemented by one or more processors is provided, the method comprising selecting, at a remote system, a set of client devices from a plurality of client devices. In some embodiments, the method comprises determining, at the remote system, a reporting window, the reporting window indicating a time frame for the set of client devices to provide one or more gradients to update a global model. In some embodiments, the method comprises transmitting, by the remote system, the reporting window to each client device in the set of client devices, wherein transmitting the reporting window causes each client device to at least selectively determine a corresponding reporting time within the reporting window for transmitting a corresponding locally generated gradient to the remote system. In some embodiments, the method comprises receiving, at the corresponding reporting time within the reporting window, corresponding locally generated gradients, wherein each of the corresponding locally generated gradients is generated by a corresponding one of the client devices based on processing data generated locally at the client device using a local model stored locally at the client device to generate a predicted output of the local model. In some embodiments, the method comprises updating one or more portions of the global model based on the received gradients.

[0154] These and other implementations of the technology can include one or more of the following features.

[0155] In some embodiments, the method further includes selecting, at the remote system, an additional set of additional client devices from the plurality of client devices. In some embodiments, the method further includes determining, at the remote system, an additional reporting window, the additional reporting window instructing the additional set of additional client devices to provide one or more additional gradients for updating an additional time frame of the global model. In some embodiments, the method further includes transmitting, by the remote system, the additional reporting window to each additional client device in the additional set of additional client devices, wherein transmitting the additional reporting window causes each additional client device to at least selectively determine a corresponding additional reporting time within the additional reporting window for transmitting corresponding additional locally generated gradients to the remote system. In some embodiments, the method further includes receiving corresponding additional locally generated gradients at the corresponding additional reporting time within the additional reporting window, wherein each of the corresponding additional locally generated gradients is generated by a corresponding one of the additional client devices based on processing additional data generated locally at the additional client device using a local model stored locally at the additional client device to generate an additional prediction output of the local model. In some embodiments, the method further includes updating one or more additional portions of the global model based on the received additional gradients. In some versions of these embodiments, at least one client device in the set of client devices is in an additional set of additional client devices.

[0156] In some embodiments, processing data generated locally at the client device using a local model stored locally at the client device to generate a predicted output for the local model further includes generating a gradient based on the predicted output of the local model and ground-truth data generated by the client device. In some versions of these embodiments, the global model is a global automatic speech recognition ("ASR") model, the local model is a local ASR model, and wherein generating the gradient based on the predicted output of the local model includes processing audio data capturing the spoken utterance using the local ASR model to generate a predicted textual representation of the spoken utterance. In some versions of these embodiments, the method further includes generating the gradient based on the predicted textual representation of the spoken utterance and a ground-truth representation of the spoken utterance generated by the client device.

[0157] In some embodiments, each of the client devices selectively determining at least a corresponding reporting time within a reporting window for transmitting the corresponding locally generated gradient to the remote system includes: for each client device, randomly determining a corresponding reporting time within the reporting window for transmitting the corresponding locally generated gradient to the remote system. In some versions of these embodiments, each of the client devices selectively determining at least a corresponding reporting time within the reporting window for transmitting the corresponding locally generated gradient to the remote system includes: for each client device, determining whether to transmit the corresponding locally generated gradient to the remote system. In some versions of these embodiments, in response to determining to transmit the corresponding locally generated gradient, the method further includes transmitting the corresponding locally generated gradient to the remote system. In some versions of these embodiments, determining whether to transmit the corresponding locally generated gradient to the remote system includes randomly determining whether to transmit the corresponding locally generated gradient to the remote system.

[0158] In some embodiments, receiving corresponding locally generated gradients at corresponding reporting times within a reporting window includes receiving multiple corresponding locally generated gradients at the same reporting time. In some versions of these embodiments, updating one or more portions of the global model based on the received gradients includes determining update gradients based on the multiple corresponding locally generated gradients received at the same reporting time. In some versions of those embodiments, the method further includes updating one or more portions of the global model based on the update gradients. In some versions of these embodiments, determining the update gradients based on the multiple corresponding locally generated gradients received at the same reporting time includes selecting the update gradients from the multiple corresponding locally generated gradients received at the same reporting time. In some versions of these embodiments, selecting the update gradients from the multiple corresponding locally generated gradients received at the same reporting time includes randomly selecting the update gradients from the multiple corresponding locally generated gradients received at the same reporting time. In some versions of these embodiments, determining the update gradients based on the multiple corresponding locally generated gradients received at the same reporting time includes determining the update gradients based on an average of the multiple corresponding locally generated gradients.

[0159] In some embodiments, a method implemented by one or more processors is provided, the method comprising receiving, at a client device, a reporting window from a remote system, the reporting window indicating a time frame for the client device to provide gradients to the remote system to update one or more portions of a global model. In some embodiments, the method comprises processing locally generated data using a local model to generate a predicted output of the local model. In some embodiments, the method comprises generating gradients based on the predicted output of the local model. In some embodiments, the method comprises determining a reporting time within the reporting window to transmit the gradients to a remote server. In some embodiments, the method comprises transmitting the gradients to the remote server at the reporting time.

[0160] In addition, some embodiments include one or more processors (e.g., central processing unit(s) (CPUs), graphics processing unit(s) (GPUs), and / or tensor processing unit(s) (TPUs)) of one or more computing devices, wherein the one or more processors are operable to execute instructions stored in an associated memory, and wherein the instructions are configured to perform any of the methods described herein. Some embodiments also include one or more transitory or non-transitory computer-readable storage media storing computer instructions executable by the one or more processors to perform any of the methods described herein.

Claims

1. A method implemented by one or more processors, the method comprising: selecting, at a remote system, a set of client devices from a plurality of client devices; determining, at the remote system, a reporting window, the reporting window indicating a time frame for the set of client devices to provide one or more gradients to update a global model; transmitting, by the remote system, the reporting window to each client device in the set of client devices, wherein transmitting the reporting window causes each of the client devices to at least selectively determine a corresponding reporting time within the reporting window to transmit a corresponding locally generated gradient to the remote system; receiving the corresponding locally generated gradients at the corresponding reporting time in the reporting window, wherein each of the corresponding locally generated gradients is generated by a corresponding one of the client devices based on processing data generated locally at the client device using a local model stored locally at the client device to generate a predicted output of the local model; updating one or more parts of the global model based on the received gradients; selecting, at the remote system, an additional set of additional client devices from the plurality of client devices; determining, at the remote system, an additional reporting window, the additional reporting window instructing the additional set of additional client devices to provide one or more additional gradients to update an additional time frame for the global model; transmitting, by the remote system, the additional reporting window to each additional client device in the set of additional additional client devices, wherein transmitting the additional reporting window causes each of the additional client devices to at least selectively determine a corresponding additional reporting time within the additional reporting window to transmit a corresponding additional locally generated gradient to the remote system; receiving the corresponding additional locally generated gradients at the corresponding additional reporting time in the additional reporting window, wherein each of the corresponding additional locally generated gradients is generated by a corresponding one of the additional client devices based on processing additional data generated locally at the additional client device using a local model stored locally at the additional client device to generate an additional prediction output of the local model; and One or more additional portions of the global model are updated based on the received additional gradients.

2. The method according to claim 1, wherein Processing data generated locally at the client device using the local model stored locally at the client device to generate the predicted output of the local model further comprises: The gradient is generated based on the predicted output of the local model and real-valued data generated by the client device.

3. The method according to claim 2, wherein: The global model is a global automatic speech recognition (ASR) model, the local model is a local ASR model, and wherein generating the gradient based on the predicted output of the local model comprises: processing audio data capturing a spoken utterance using the local ASR model to generate a predicted text representation of the spoken utterance; and The gradient is generated based on the predicted text representation of the spoken utterance and a ground-truth representation of the spoken utterance generated by the client device.

4. The method according to claim 1, wherein Each of the client devices selectively determining at least the corresponding reporting time within the reporting window to transmit the corresponding locally generated gradient to the remote system includes: For each of the client devices, the corresponding reporting time within the reporting window is randomly determined to transmit the corresponding locally generated gradient to the remote system.

5. The method according to claim 4, wherein Each of the client devices selectively determining at least the corresponding reporting time within the reporting window to transmit the corresponding locally generated gradient to the remote system includes: For each of the client devices: determining whether to transmit the corresponding locally generated gradient to the remote system; and In response to determining to transmit the corresponding locally generated gradient, the corresponding locally generated gradient is transmitted to the remote system.

6. The method according to claim 5, wherein: Determining whether to transmit the corresponding locally generated gradient to the remote system includes: A determination is randomly made whether to transmit the corresponding locally generated gradient to the remote system.

7. The method according to claim 1, wherein At least one client device in the set of client devices is in the additional set of additional client devices.

8. The method according to any one of claims 1 to 7, wherein Receiving the corresponding locally generated gradient at the corresponding reporting time in the reporting window includes receiving a plurality of corresponding locally generated gradients at a same reporting time.

9. The method according to claim 8, wherein Updating one or more parts of the global model based on the received gradients includes: determining an update gradient based on the plurality of corresponding locally generated gradients received at the same reporting time; and The one or more portions of the global model are updated based on the update gradients.

10. The method according to claim 9, wherein: Determining the update gradient based on the plurality of corresponding locally generated gradients received at the same reporting time comprises: The update gradient is selected from the plurality of corresponding locally generated gradients received at the same reporting time.

11. The method according to claim 10, wherein: Selecting the update gradient from the plurality of corresponding locally generated gradients received at the same reporting time comprises: The update gradient is randomly selected from the plurality of corresponding locally generated gradients received at the same reporting time.

12. The method according to claim 9, wherein Determining the update gradient based on the plurality of corresponding locally generated gradients received at the same reporting time comprises: The update gradient is determined based on an average of the plurality of corresponding locally generated gradients.

13. A method implemented by one or more processors, the method comprising: selecting, at a remote system, a set of client devices from a plurality of client devices; determining, at the remote system, a reporting window, the reporting window indicating a time frame for the set of client devices to provide one or more gradients to update a global model; transmitting, by the remote system, the reporting window to each client device in the set of client devices, wherein transmitting the reporting window causes each of the client devices to at least selectively determine a corresponding reporting time within the reporting window to transmit a corresponding locally generated gradient to the remote system; receiving the corresponding locally generated gradients at the corresponding reporting time in the reporting window, wherein each of the corresponding locally generated gradients is generated by a corresponding one of the client devices based on processing data generated locally at the client device using a local model stored locally at the client device to generate a predicted output of the local model; wherein receiving the corresponding locally generated gradient at the corresponding reporting time in the reporting window comprises: receiving a plurality of corresponding locally generated gradients at the same reporting time; and Updating one or more portions of the global model based on the received gradients, wherein updating one or more portions of the global model based on the received gradients comprises: determining an update gradient based on the plurality of corresponding locally generated gradients received at the same reporting time; and The one or more portions of the global model are updated based on the update gradients.

14. The method according to claim 13, wherein Determining the update gradient based on the plurality of corresponding locally generated gradients received at the same reporting time comprises: The update gradient is selected from the plurality of corresponding locally generated gradients received at the same reporting time.

15. The method according to claim 14, wherein Selecting the update gradient from the plurality of corresponding locally generated gradients received at the same reporting time comprises: The update gradient is randomly selected from the plurality of corresponding locally generated gradients received at the same reporting time.

16. The method according to claim 13, wherein: Determining the update gradient based on the plurality of corresponding locally generated gradients received at the same reporting time comprises: The update gradient is determined based on an average of the plurality of corresponding locally generated gradients.

17. A computing system, comprising: a memory storing instructions; as well as One or more processors operable to execute the instructions to perform the method according to any one of claims 1 to 16.

18. A computer-readable storage medium storing instructions executable by one or more processors of a computing system to perform the method according to any one of claims 1 to 16.

Images