Fédéré sans limite : comment la découpe des gradients brise le plafond de mémoire du serverless

Sur AWS Lambda, une fonction ne peut allouer que 10 gigaoctets de mémoire. Or, dès qu’un modèle de deep learning dépasse cette borne, l’agrégation de ses gradients dans une architecture fédérée devient mathématiquement impossible. Ce n’est pas un problème d’optimisation : c’est un mur. Jusqu’ici, toutes les approches serverless pour l’apprentissage fédéré — lambda-FL, LIFL — souffraient de cette contrainte, car chaque nœud d’agrégation devait stocker l’intégralité du gradient en mémoire, quelle que soit la profondeur de l’arborescence.

Le nœud gordien du fédéré sur le cloud fonctionnel

L’apprentissage fédéré (federated learning) promet d’entraîner un modèle collectif sans jamais centraliser les données brutes. Chaque client — un smartphone, un hôpital, une station-bas — calcule localement un gradient, puis un agrégateur combine ces contributions. En théorie, c’est élégant. En pratique, le gradient d’un réseau de type VGG-16 avoisine 500 Mo ; celui d’un transformer de dernière génération dépasse allègrement 10 Go. Et c’est exactement là que les plateformes serverless, conçues pour du code léger et éphémère, rendent les armes.

Les architectures existantes contournent le problème en parallélisant sur les clients : on découpe la population en groupes, chaque sous-groupe a son agrégateur. Mais aucun de ces agrégateurs ne peut éviter de charger le gradient complet en RAM. Résultat : au-delà d’une certaine taille de modèle, le système s’effondre, indépendamment de la topologie choisie.

GradsSharding : on coupe le tensor, pas les clients

Les auteurs du papier arXiv 2604.22072 proposent un renversement simple mais radical. Plutôt que de partitionner les clients, on partitionne le gradient tensor lui-même en M tranches (shards). Chaque tranche est moyennee par une fonction serverless distincte qui reçoit, elle, les contributions de tous les clients pour cette tranche uniquement.

Le point clé repose sur une propriété mathématique : la moyenne FedAvg est élément par élément. Dès lors que chaque composante du gradient est traitée de façon indépendante, le résultat final est bit-à-bit identique à celui d’une agrégation séquentielle ou arborescente. Aucune perte de précision n’introduite par construction.

• La mémoire par fonction est bornée à O(|θ|/M), quel que soit le nombre de clients.
• Pas de dépendance à la taille du modèle côté client : un gradient de 5 Go se découpe aussi proprement qu’un de 43 Mo.
• L’architecture reste déployable au-delà du plafond de 10 Go d’AWS Lambda, chose que lambda-FL et LIFL ne peuvent pas garantir.

Chiffres qui parlent : crossover à 500 Mo, économie à 2,7 fois

Les expérimentations couvrent des modèles de 43 Mo à 5 Go, testés à la fois en HPC et sur des déploiements réels d’AWS Lambda. Deux résultats saillent d’abord :

• Au-dessous d’environ 500 Mo de gradient, les approches arborescentes restent moins coûteuses en appels de fonctions. C’est le point de crossover.
• Dès l’échelle de VGG-16, GradsSharding affiche une réduction de coût de 2,7 fois par rapport aux concurrents, tout en étant la seule architecture qui continue de fonctionner au-delà de la limite de mémoire par fonction.

En d’autres termes, plus le modèle est gros, plus l’avantage se creuse. Et pour les équipes qui veulent entraîner des modèles de classe GPT ou ViT-L/14 en fédéré sur infrastructure serverless, la solution n’était pas là où tout le monde cherchait : il fallait découper le math, pas l’organisation.

Pourquoi cela résonne particulièrement en Afrique francophone

Le contexte africain rend l’apprentissage fédéré particulièrement pertinent : les cadres réglementaires comme le RGPD transposé, la loi nigériane NDPR ou la loi kenyane Data Protection Act 2019 limitent fortement la centralisation des données de santé, de télécoms ou de finance. Un modèle qui s’entraîne sans que les données brues quittent le site opérateur coche la case juridique tout en restant performant.

Ajoutons la réalité infrastructurelle : une grande partie du numérique africain passe par le mobile et le cloud public, rarement par des data centers on-premises. Les fonctions serverless y sont omniprésentes — AWS Africa (Cape Town), Microsoft Azure (Johannesburg) — mais leurs plafonds de mémoire sont les mêmes qu’ailleurs. GradsSharding ouvre donc la porte à des entraînements fédérés de modèles volumineux sur ces infrastructures, là où les approches précédentes butaient.

On pense naturellement aux opérateurs télécoms qui veulent détecter la fraude sans partager les logs d’appels, aux laboratoires hospitaliers qui souhaitent partager des signaux d’imagerie médicale sans violer le secret du patient, ou encore aux plateformes fintech qui cherchent à affiner des modèles de scoring credit sans exposer les données de leurs clients entre pays de la CEDEAO ou de l’UEMOA.

Ouverture

La question que ce papier laisse ouverte n’est pas technique, elle est stratégique : si l’agrégation fédérée devient aussi scalable qu’une simple requête REST, qui possède le modèle résultant, et comment se répartissent les droits d’usage entre les contributeurs de gradients ? La réponse déterminera si l’intelligence artificielle collaborative restera un luxe d’infrastructures ou deviendra un bien commun accessible à toute économie qui dispose d’un réseau mobile et d’une volonté de protéger ses citoyens.

Sources

• arXiv – Shard the Gradient, Scale the Model: Serverless Federated Aggregation via Gradient Partitioning
• AWS Documentation – AWS Lambda Limits