Appunti dall'incontro dell'8/11/2022 dei collaboratori di TFF

Argomento proposto all'ordine del giorno: Jeremy Lewi presenterà le sue idee basate su TFF per nuovi componenti che potrebbero essere costruiti
[JL] Concentrandosi su semplici scenari di analisi federate, collegando TFF con i fogli Google per eseguire una semplice media feed. Lavorare a Kubernetes, leggere dai fogli.
[JL] Una sfida è che attualmente i lavoratori devono avere punti di ingresso.
- Questo spesso non è il caso, quindi è necessario un livello di trasporto che consenta di stabilire la connettività nella direzione opposta, i lavoratori chiamano un server.
- Tale componente non è attualmente nell'ecosistema.
[BC] Anche questo ha visto la necessità. Attualmente utilizza TFF in modo limitato, cloud interno in cui i clienti caricano i dati. Tuttavia, sarebbe necessario qualcosa come JL descritto sopra per migrare a un'impostazione multi-datacenter.
[JL] Pensare a un livello che consenta ai lavoratori di "estrarre" elementi di lavoro da una coda su un server, se dovesse sostituire il runtime esistente.
[KO] Non devi pensare a questo in termini di "sostituzione": puoi mantenere l'authoring del calcolo e il 98% del runtime invariato e sostituiresti semplicemente il nuovo componente che funziona nel modo in cui proponi invece dall'esecutore remoto come meccanismo per inoltrare le richieste dell'esecutore dall'alto verso il basso.
[BC] Avresti bisogno che fosse asincrono o funzionerebbe all'interno del paradigma di sincronizzazione esistente.
[BC] Inoltre, alcune delle piattaforme esistenti utilizzano un approccio "coda di attività", quindi sembra un'idea consolidata.
[BC] L'introduzione di timeout forse aiuterebbe anche a colmare il divario (per far fronte a lavoratori lenti o ritardatari).
[KO] Per quanto riguarda sync vs. async, abbiamo astrazioni collettive in TFF che richiedono la nozione di "coorte". Pertanto, ci deve essere un momento in cui alcuni dei client là fuori decidono insieme di unirsi a una "coorte" e il server dovrebbe svolgere un ruolo nell'orchestrare che ciò accada. Finché ciò è fatto, il modo in cui le richieste dei singoli esecutori vengono inoltrate ai client può variare. L'esecutore remoto che chiama dall'alto verso il basso è un modo per farlo, ma non l'unico; anche un modello di comunicazione basato su elementi di lavoro come quello proposto sopra potrebbe sicuramente adattarsi a questa struttura. Sembra materiale per una piccola proposta di uno-due cercapersone da far redigere a qualcuno?
[JL] Fare volontariato per scrivere una proposta per un nuovo componente su cui tutti noi possiamo iterare.
[JL] A proposito, ci sono altri repository adiacenti con funzionalità correlate?
[KO] Cordiali saluti, https://github.com/google/federated-compute anche da Google, ma si concentra principalmente su uno scenario mobile, a questo punto non è connesso a TFF e non contiene la funzionalità che stai descrivendo qui, quindi ha decisamente senso provare a formulare una piccola proposta in questo gruppo.
[BD] Alcune domande da affrontare: memorizzazione nella cache dei risultati, quando aggregare.
[Hao] Forse non è necessario memorizzare nella cache in questo scenario se non è asincrono
[KO] Per gli scenari che si adattano a un semplice modello MapReduce, abbiamo del supporto in TFF, vedere https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. Questa libreria ti consente di tradurre i calcoli TFF in un modulo simile a MapReduce che potresti eseguire su una piattaforma più semplice. Tuttavia, c'è una certa perdita di espressività e alcune delle idee discusse in precedenza che richiedevano più cicli di comunicazione avanti e indietro tra sevrr e client non sarebbero esprimibili in questo quadro. Inoltre, l'impostazione cross-silo rende possibile questo tipo di idee in modo univoco, dal momento che abbiamo a che fare con gruppi di clienti ben forniti (silos) che possono mantenere connessioni durature.
[Hao] Che dire delle operazioni collettive, allreduce - sono quelle supportate o compatibili
[KO] Non attualmente. Allreduce avrebbe un uso alquanto limitato, in quanto mentre potrebbe essere sfruttato in un singolo scenario avg alimentato, presuppone che non si stia verificando alcun lavoro sul server tra i round di elaborazione. Non funzionerà in casi più generali. Ma avere le due metà di esso - modalità efficiente di trasmissione e modalità efficiente di aggregazione, forse anche con l'accelerazione hardware, sarebbe qualcosa di cui possiamo trarre vantaggio in TFF.
[KO] Sembra che JL sia pronto a dare il via a una bozza di una proposta per un nuovo componente, e altri hanno opinioni su cosa dovrebbe esserci dentro - collaboriamo (+1 da tutti nella stanza). Riconvocarsi tra 2 settimane, possibilmente con una bozza da discutere.