Personalized federated learning

Overview

Personalized federated learning (PFL) gives each client its own model, while the data stays on the clients 2103.04628 §1. The motivation is that clients often hold different data distributions, so one global model fits each of them poorly 2103.04628 §1 1907.09173 §1. The objective is to minimize the average loss over the personal models 2103.04628 eq. 2. Earlier personalized methods either exchange large amounts of parameters or share little across clients 2103.04628 §1, §2. The general problem is covered in federated-learning.

A survey splits the field into two strategies: adapt one global model per client, or learn a separate model per client 2103.00710 §II fig. 1. It assumes horizontal FL 2103.00710 §I-A and notes that most PFL work tests only one kind of non-IID skew 2103.00710 §V tab. III.

Four cards are in this wiki for this concept. Three describe methods with different designs, and the fourth is the survey. The method cards use different datasets and baselines, so their numbers are not compared with each other. Other methods the papers compare against, such as Per-FedAvg, pFedMe, LG-FedAvg and APFL, are named below but have no cards here, so their content is not used.

Variants

Server-side hypernetwork (pFedHN)

A hypernetwork on the server maps a trainable embedding for each client to that client's target-network weights 2103.04628 §3.2. The hypernetwork parameters are shared, and only the embeddings are per client, so the server holds a family of personal models 2103.04628 §3.2. The client returns the change in its weights after several local steps, and the server passes that change back through the chain rule to update both the shared parameters and the embedding 2103.04628 §3.2 2103.04628 alg. 1. The hypernetwork is never transmitted 2103.04628 §3.2. Card: Personalized Federated Learning using Hypernetworks.

The method is described in more detail on the hypernetwork page.

Personal classifier head (pFedHN-PC)

The hypernetwork produces only the feature extractor. Each client keeps its own output layer locally, and that layer is never sent to the server 2103.04628 §3.3 2103.04628 eq. 4. The authors use this variant when clients solve different tasks, for example with different numbers of classes 2103.04628 §3.3. Card: the same paper, Personalized Federated Learning using Hypernetworks.

Personal model pulled toward the global model (Ditto)

Each device trains a personal model that is pulled toward the global model by an L2 term with weight λ 2012.04221 §3.1. The global model is trained by an ordinary federated solver, FedAvg in most experiments, and the server averages the global updates 2012.04221 §3.2 2012.04221 alg. 1. The pull is toward the global model at the start of the round. Each device sends back only its global update, so personal models never leave the device and the messages match those of the global solver 2012.04221 §3.2. With λ = 0 the personal model is purely local, and as λ grows the objective approaches the global one 2012.04221 §3.1. The survey files a λ-controlled mix of local and global models under model interpolation 2103.00710 §IV-B. Each device picks λ from a small grid using its own validation data 2012.04221 app. D.2. That rule does not cover devices with exactly 4 or 5 validation points 2012.04221 app. D.2.

Robust aggregators can replace the server's averaging step. In the paper's FEMNIST table, Ditto with clipping is the best entry in five of six columns 2012.04221 tab. 3. Card: Ditto: Fair and Robust Federated Learning Through Personalization.

Shared cloud model with per-user transfer (FedHealth)

FedHealth first builds one cloud CNN from federated updates, then gives each user its own copy by transfer learning 1907.09173 §3.2 alg. 1. Here a "user" is an organisation or a device holder 1907.09173 §3.2. The copy freezes the convolution and max-pooling layers and trains only the fully connected layers 1907.09173 §3.4 §4.2. Its loss is the classification loss plus η times a CORAL term, with η = 0.01 1907.09173 eq. 5 1907.09173 eq. 6 §4.2. The cloud weights reach users under additively homomorphic encryption, and the server later aligns its model with the uploaded user models 1907.09173 §3.3 alg. 1. The aggregation rule is not given, so the server side cannot be rebuilt from the text [arxiv:1907.09173 §3.3]. The alignment term is borrowed from domain adaptation 1907.09173 §3.4, which is covered on domain-adaptation. Card: FedHealth: A Federated Transfer Learning Framework for Wearable Healthcare.

When to use which

Every number above is author-reported, on the paper's own splits and seeds. None of them has been reproduced here.

Implementation sketch

Language-agnostic pseudocode of the common core for pFedHN. Where the paper's printed algorithm and its code disagree on the update sign, the code's sign is used; see Contradictions.

# One pFedHN communication round  [alg. 1] [§3.2]
# Input:  hypernet (shared params phi, per-client embeddings v),
#         client i, outer lr alpha, inner lr eta, local steps K

def pfedhn_round(hypernet, i, alpha, eta, K):
    # 1. Server builds the personal weights from the client embedding  [§3.2]
    theta = hypernet.generate(v[i])
    theta_local = copy_of(theta)
    # 2. Client runs K local mini-batch SGD steps  [alg. 1] [§5]
    for step in range(K):
        batch = client_i.sample_minibatch()
        theta_local = theta_local - eta * grad_loss(theta_local, batch)
    # 3. Weight change returned to the server  [§3.2]
    delta = theta - theta_local
    # 4. Chain rule through the hypernetwork, for phi and v[i]  [§3.2]
    grads = vector_jacobian(hypernet, v[i], delta)
    # 5. Step the shared parameters and the embedding  [alg. 1]
    hypernet.phi = hypernet.phi - alpha * grads.phi
    v[i] = v[i] - alpha * grads.v

For pFedHN-PC, the same loop runs on the feature extractor only, and the output layer is updated on the client and never returned §3.3.

Ditto's personal step is a separate loop, run on each selected device after the global update in the round alg. 1 §3.2:

# Ditto personal step on one device  [§3.2]
# w: global model at the start of the round; v: personal model
# lam: pull toward w; eta: step size; s: local steps

def ditto_personal_step(v, w, grad_F, lam, eta, s):
    # Local loss gradient plus the L2 pull toward the global model  [§3.2]
    for _ in range(s):
        v = v - eta * (grad_F(v) + lam * (v - w))
    # v stays on the device; only the global update is sent  [§3.2]
    return v

FedHealth's per-user stage is a different loop. The user copy keeps the convolution and pooling layers fixed, and it minimizes the classification loss plus η times the CORAL loss on its own data alg. 1 eq. 6. The server-side alignment step is not specified in the paper, so it is left out here.

Contradictions

The four cards report numbers on different datasets, splits and baselines, so their results are not comparable. No two papers report conflicting numbers for the same setting. Within each source, the following inconsistencies are noted:

• pFedHN update sign. The printed update in Algorithm 1 has the opposite sign to the code. The paper's surrogate-loss argument matches the code 2103.04628 alg. 1 2103.04628 §3.2. This is recorded from the card's comparison with the code, and the paper does not mention it.
• pFedHN claimed margins. The text claims gains of "2%–10%" over all competitors 2103.04628 §5.1. Computed from the table against the best baseline in each column, pFedHN gains 1.7 to 2.7 points on CIFAR10 and is 4.4 points behind on Omniglot 2103.04628 tab. 1.
• Ditto table values. Ditto's FEMNIST clean accuracy is .834 in Table 1 and .836 in Table 2, and its A1 50% value is .762 and .767 2012.04221 tab. 1 2012.04221 tab. 2. The paper does not explain the difference.
• Ditto λ rule against the released code. The paper selects λ per device from the grids in 2012.04221 app. D.2. The released code instead tries {0.1, 1, 2} at every local step, and its run scripts fix λ = 1 ditto.py run_fashion_clean_ditto_lam1.sh. Reproducing the dynamic-λ numbers needs a flag the scripts do not set by default.
• FedHealth layer count. Section 3.4 describes two fully connected layers with an alignment layer in place of fc2 1907.09173 §3.4. Section 4.2 describes three fully connected layers 1907.09173 §4.2.
• FedHealth headline gain. The abstract's 5.3% is compared with "traditional methods". In the text it is the gap between FedHealth and the shared model with no transfer (99.4 − 94.1) 1907.09173 §4.3. That average is also the average of the best traditional method, SVM 1907.09173 tab. 2. The gain is in percentage points, not a relative improvement.

Papers

• Personalized Federated Learning using Hypernetworks: a server-side hypernetwork produces each client's weights from a learned client embedding, with a personal-classifier variant.
• Ditto: Fair and Robust Federated Learning Through Personalization: each device trains a personal model pulled toward the global model by an L2 term, and the global model is trained by an ordinary federated solver.
• FedHealth: A Federated Transfer Learning Framework for Wearable Healthcare: a shared cloud CNN built from encrypted federated updates, then per-user fine-tuning of the fully connected layers with a CORAL term.
• Towards Personalized Federated Learning: a survey that sorts PFL methods into global-model personalization and learning personalized models, with benchmarks, metrics and open directions. It runs no experiments.