Notes de la réunion du 8/11/2022 des collaborateurs de la TFF

Sujet proposé à l'ordre du jour : Jeremy Lewi présentera ses idées basées sur la TFF pour de nouveaux composants qui pourraient être construits
[JL] Se concentrer sur des scénarios d'analyse fédérée simples, en connectant TFF à des feuilles Google pour effectuer une moyenne alimentée simple. Travailler dans Kubernetes, lire à partir de feuilles.
[JL] L'un des défis est qu'actuellement, les travailleurs doivent avoir des points d'entrée.
- Ce n'est souvent pas le cas, il faut donc une couche de transport qui permette d'établir la connectivité dans la direction opposée, les travailleurs appelant un serveur.
- Un tel composant n'est pas actuellement dans l'écosystème.
[BC] a également vu la nécessité de cela. Utilise actuellement TFF de manière limitée, un cloud interne où les clients téléchargent des données. Mais, il faudrait quelque chose comme JL décrit ci-dessus pour migrer vers un paramètre multi-centre de données.
[JL] Penser à une couche qui permettrait aux travailleurs de "tirer" des éléments de travail d'une file d'attente sur un serveur - devrait-elle remplacer le runtime existant.
[KO] Vous n'avez pas à penser à cela en termes de "remplacement" - vous pouvez conserver la même création de calcul et 98 % de l'exécution, et vous échangeriez simplement le nouveau composant qui fonctionne comme vous le proposez à la place désactiver l'exécuteur distant en tant que mécanisme pour relayer les demandes de l'exécuteur de haut en bas.
[BC] Auriez-vous besoin qu'il soit asynchrone, ou cela fonctionnerait-il dans le cadre du paradigme de synchronisation existant.
[BC] De plus, certaines des plates-formes existantes utilisent une approche de "file d'attente de tâches", donc cela ressemble à une idée établie.
[BC] L'introduction de délais d'attente aiderait peut-être aussi à combler l'écart (pour faire face aux travailleurs lents ou aux retardataires).
[KO] En ce qui concerne la synchronisation par rapport à l'asynchrone, nous avons des abstractions collectives dans TFF qui nécessitent la notion de « cohorte ». En tant que tel, il doit y avoir un moment où certains des clients décident ensemble de rejoindre une «cohorte», et le serveur devrait jouer un rôle dans l'orchestration de cela. Tant que cela est fait, la manière dont les demandes d'exécution individuelles sont transmises aux clients peut alors varier. L'exécuteur distant qui appelle de haut en bas est une façon de procéder, mais pas la seule ; un modèle de communication basé sur des éléments de travail comme celui proposé ci-dessus pourrait également parfaitement s'intégrer dans cette structure. Cela ressemble à du matériel pour une petite proposition d'un ou deux pages à rédiger par quelqu'un ?
[JL] Se porter volontaire pour rédiger une proposition de nouveau composant sur lequel nous pourrons tous faire des itérations.
[JL] BTW, existe-t-il d'autres dépôts adjacents avec des fonctionnalités connexes ?
[KO] FYI, https://github.com/google/federated-compute également de Google, mais cela se concentre principalement sur un scénario mobile, il n'est pas connecté à TFF à ce stade et ne contient pas la fonctionnalité que vous êtes décrivant ici, il est donc tout à fait logique d'essayer de formuler une petite proposition dans ce groupe.
[BD] Quelques questions à se poser : mise en cache des résultats, quand agréger.
[Hao] Peut-être n'a-t-il pas besoin de mise en cache dans ce scénario s'il n'est pas asynchrone
[KO] Pour les scénarios qui correspondent à un modèle MapReduce simple, nous avons un certain support dans TFF, voir https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. Cette bibliothèque vous permet de traduire les calculs TFF en un formulaire de type MapReduce que vous pourriez exécuter sur une plate-forme plus simple. Cependant, il y a une certaine perte d'expressivité, et certaines des idées discutées précédemment qui nécessitaient plusieurs cycles de communication aller-retour entre sevrr et les clients ne seraient pas exprimables dans ce cadre. De plus, la configuration inter-silos rend ces types d'idées possibles, car nous avons affaire à des groupes de clients bien approvisionnés (silos) qui peuvent maintenir des connexions durables.
[Hao] Qu'en est-il des opérations collectives, allreduce - sont-elles prises en charge ou compatibles
[KO] Pas actuellement. Allreduce aurait une utilisation quelque peu limitée, car bien qu'il puisse être exploité dans un scénario de moyenne alimentée unique, il suppose qu'aucun travail ne se produit sur le serveur entre les cycles de traitement. Ne fonctionnera pas dans des cas plus généraux. Mais, avoir les deux moitiés - un mode de diffusion efficace et un mode d'agrégation efficace, peut-être même avec une accélération matérielle, serait quelque chose dont nous pouvons tirer parti dans TFF.
[KO] On dirait que JL est prêt à lancer une ébauche de proposition pour un nouveau composant, et d'autres ont des opinions sur ce qui devrait y figurer - collaborons (+1 de tous dans la salle). Se réunir dans 2 semaines, éventuellement avec un projet à discuter.