Notas do encontro dos colaboradores do TFF em 11/08/2022

• Pauta proposta: Jeremy Lewi apresentará ideias baseadas no TFF de novos componentes que podem ser construídos

• [JL] Foco em cenários analíticos federados simples, conectando o TFF ao Planilhas Google para fazer uma média federada simples. Trabalhando com Kubernetes, lendo planilhas.

• [JL] Um desafio é que, atualmente, os workers precisam ter pontos de entrada.

  • Geralmente, esse não é o caso, então precisamos de uma camada de transporte que permite que a conectividade seja estabelecida na direção oposta: os workers chamando um servidor.

  • Atualmente, um componente como esse não existe no ecossistema.

• [BC] Também vimos a necessidade disso. Atualmente, usamos o TFF de maneira limitada, uma nuvem interna em que os clientes carregam os dados. Porém, precisaríamos de algo como JL descreveu acima para migrar para um ambiente com vários datacenters.

• [JL] Estamos pensando em uma camada que permitiria aos workers “buscar” itens de trabalho em uma fila de um servidor – deve substituir o runtime existente.

• [KO] Não precisamos pensar em “substituir” – é possível manter a criação de computações e 98% do runtime da mesma forma, basta trocar pelo novo componente que funciona da forma que você propôs em vez do executor remoto como mecanismo de transmissão das solicitações top-down do executor.

• [BC] Precisaria ser assíncrono ou funcionaria com o paradigma de sincronização existente?

• [BC] Além disso, algumas plataformas existentes usam uma estratégia de “fila de tarefas”, então parece ser uma ideia já estabelecida.

• [BC] A inclusão de tempos limites talvez também possa ajudar a suprir essa lacuna (para lidar com workers lentos ou retardatários).

• [KO] Com relação a síncrono versus assíncrono, temos abstrações de coletivos no TFF que exigem a noção de “coorte”. Dessa forma, precisa haver um momento em que alguns dos clientes decidem entrar em um “coorte”, e o servidor precisaria assumir um papel de orquestração disso. Desde que isso seja feito, a forma como as solicitações do executor individuais são transmitidas para os clientes pode variar. O executor remoto que faz chamadas top-down é uma forma de tratar isso, mas não a única; um padrão de comunicação baseado em itens de trabalho como o que foi proposto acima também pode ser perfeitamente adequado para essa estrutura. Me parece que cabe aqui uma proposta pequena, de uma ou duas páginas, que alguém pode esboçar?

• [JL] Eu me ofereço para escrever uma proposta de um novo componente, com a qual todos nós podemos contribuir depois.

• [JL] A propósito, há algum repositório adjacente com funcionalidade relacionada?

• [KO] Só para constar, https://github.com/google/federated-compute também é do Google, mas se concentra principalmente em um cenário móvel, não está conectado ao TFF nesse momento e não contém a funcionalidade que você descreveu acima, então com certeza faz sentido tentar criar uma pequena proposta neste grupo.

• [BD] Algumas questões a tratar: fazer cache dos resultados, quando agregar.

• [Hao] Talvez não seja necessário fazer cache nesse cenário se não for assíncrono

• [KO] Para cenários em que um padrão MapReduce simples seja adequado, temos um certo suporte no TFF, vejam https://www.tensorflow.org/federated/api_docs/python/tff/backends/mapreduce. Com essa biblioteca, é possível traduzir computações do TFF em uma forma tipo MapReduce que pode ser executada em uma plataforma mais simples. Porém, há uma certa perda da expressividade, e algumas das ideias discutidas anteriormente que exigiam diversas rodadas de comunicação bidirecional entre servidor e clientes não poderiam ser expressadas nesse framework. Além disso, o ambiente intersilos torna possível esses tipos de ideias, já que estamos lidando com grupos de clientes (silos) bem provisionados que podem manter conexões duradouras.

• [Hao] E quanto às operações de coletivos, allreduce – há suporte para elas? São compatíveis?

• [KO] Atualmente, não. O allreduce teria um uso limitado – embora possa ser utilizado em um único cenário de média federada, ele pressupõe que nenhum trabalho esteja ocorrendo no servidor entre as rodadas de processamento. Não vai funcionar na maioria dos casos. Porém, tendo as duas metades disso – modo eficiente de difusão e modo eficiente de agregação, talvez até mesmo com aceleração de hardware – talvez possamos utilizar no TFF.

• [KO] Parece que JL vai criar um esboço da proposta de um novo componente, e os outros têm opiniões do que deve estar nela – vamos colaborar (todos aqui concordam). Vamos nos reencontrar em duas semanas, possivelmente com um esboço para discutirmos.