Notas da reunião de 8/11/2022 dos colaboradores do TFF

  • Tópico de agenda proposto: Jeremy Lewi apresentará suas ideias baseadas em TFF para novos componentes que podem ser construídos
  • [JL] Com foco em cenários simples de análise federada, conectando TFF com planilhas do Google para fazer médias alimentadas simples. Trabalhando no Kubernetes, lendo planilhas.
  • [JL] Um desafio é que atualmente os trabalhadores são obrigados a ter pontos de ingresso.
    • Isso muitas vezes não é o caso, então precisa de uma camada de transporte que permita que a conectividade seja estabelecida na direção oposta, os trabalhadores chamando um servidor.
    • Tal componente não está atualmente no ecossistema.
  • [BC] Também vi a necessidade disso. Atualmente usando TFF de forma limitada, nuvem interna onde os clientes fazem upload de dados. Mas, precisaria de algo como o JL descrito acima para migrar para uma configuração de vários datacenters.
  • [JL] Pensando em uma camada que permitiria aos trabalhadores “puxar” itens de trabalho de uma fila em um servidor - caso ela substitua o tempo de execução existente.
  • [KO] Não precisa pensar nisso em termos de “substituição” - você pode manter a autoria da computação e 98% do tempo de execução iguais, e você apenas trocaria o novo componente que funciona da maneira que você propõe desligar o executor remoto como um mecanismo para retransmitir solicitações do executor de cima para baixo.
  • [BC] Você precisaria que fosse assíncrono ou funcionaria dentro do paradigma de sincronização existente.
  • [BC] Além disso, algumas das plataformas existentes usam uma abordagem de “fila de tarefas”, então isso parece uma ideia estabelecida.
  • [BC] A introdução de tempos limite também ajudaria a preencher a lacuna (para lidar com trabalhadores lentos ou retardatários).
  • [KO] Com relação a sincronia vs. assíncrona, temos abstrações coletivas em TFF que requerem a noção de “coorte”. Como tal, deve haver um momento em que alguns dos clientes decidam juntos se juntar a uma “coorte”, e o servidor precisa desempenhar um papel na orquestração para que isso aconteça. Desde que isso seja feito, a maneira pela qual as solicitações de executores individuais são retransmitidas aos clientes pode variar. O executor remoto que chama de cima para baixo é uma maneira de fazer isso, mas não a única; um padrão de comunicação baseado em itens de trabalho como o proposto acima também pode definitivamente se encaixar nessa estrutura. Parece material para uma pequena proposta de uma ou duas páginas para alguém redigir?
  • [JL] Voluntário para escrever uma proposta para um novo componente para todos nós iterarmos.
  • [JL] BTW, existem outros repositórios adjacentes com funcionalidades relacionadas?
  • [KO] FYI, https://github.com/google/federated-compute também do Google, mas isso se concentra principalmente em um cenário móvel, não está conectado ao TFF neste momento e não contém a funcionalidade que você está descrevendo aqui, então definitivamente faz sentido tentar formular uma pequena proposta neste grupo.
  • [BD] Algumas questões a serem abordadas: resultados de cache, quando agregar.
  • [Hao] Talvez não precise de cache neste cenário se não for assíncrono
  • [KO] Para cenários que se encaixam em um padrão MapReduce simples, temos algum suporte no TFF, consulte https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. Essa biblioteca permite traduzir cálculos TFF em um formato semelhante ao MapReduce que você pode executar em uma plataforma mais simples. No entanto, há alguma perda de expressividade, e algumas das ideias discutidas anteriormente que exigiam várias rodadas de comunicação entre o sevrr e os clientes não seriam exprimíveis nessa estrutura. Além disso, a configuração entre silos torna esses tipos de ideias exclusivamente possíveis, pois estamos lidando com grupos de clientes bem provisionados (silos) que podem manter conexões duradouras.
  • [Hao] E as operações coletivas, allreduce - são suportadas ou compatíveis
  • [KO] Não atualmente. O Allreduce teria um uso um tanto limitado, pois, embora pudesse ser aproveitado em um único cenário de alimentação média, ele pressupõe que nenhum trabalho esteja acontecendo no servidor entre as rodadas de processamento. Não funcionará em casos mais gerais. Mas, ter as duas metades - modo eficiente de transmissão e modo eficiente de agregação, talvez até com aceleração de hardware, seria algo que podemos aproveitar no TFF.
  • [KO] Parece que JL está pronto para lançar um rascunho de uma proposta para um novo componente, e outros têm opiniões sobre o que deveria estar nele - vamos colaborar (+1 de todos na sala). Para se reunir novamente em 2 semanas, possivelmente com um rascunho para discutir.