Notas da reunião de 24/08/2022 dos colaboradores do TFF

  • Suporte de tensor esparso em TFF:
    • EW - Temos modelos Keras que queremos portar para TFF, eles têm tensores esparsos
      • Simplesmente mapear para tensores densos resulta em custo de memória inaceitável e lentidão em nosso caso de uso, então estamos tentando evitar isso
    • ZG no suporte de tensor esparso existente no TFF
      • Problemas mencionados no GitHub principalmente relacionados a tf.data.Dataset
      • Principalmente funciona de outra forma, mas requer algumas agregações DIY, particularmente wrt, onde não podemos simplesmente fazer ingenuamente uma soma esparsa no triplo de tensores constituintes, que não teriam o resultado desejado
    • (pergunta sobre importância relativa)
    • EW - isso não é um bloqueio para nós, mas uma boa otimização de desempenho/recursos
    • ZG - com relação aos problemas do GitHub, pode contornar ocultando o conjunto de dados dentro do cálculo do TFF, portanto, não faz parte do limite de entrada-saída
    • KO - esclarecendo que nosso comentário “funciona principalmente” refere-se à prática comum de representar/tratar tensores esparsos como tuplas de tensores densos. Você já tentou lidar com esparsas como tuplas de tensores densos para uso de conjuntos de dados também?
      • EW - ainda não tentei
    • KO - esparso nesta conversa surgiu em dois lugares - para parâmetros de modelo, mas também para dados de entrada esparsos - ambos são igualmente importantes?
      • EW - idealmente teria ambos
    • KO - um item de ação para Ewan tentar trabalhar com tuplas de tensores densos que representam as partes constituintes.
    • KO - isso ainda deixa uma pergunta sobre melhores APIs/auxiliares para manipulação de tensores esparsos, mas pode desbloquear esse caso de uso específico. Considerações sobre a API?
    • EW - idealmente, isso poderia ser apenas transparente (não é necessário fazer nada de especial para esparso pelo cliente usando o TFF e simplesmente funciona)
      • KO, ZG - em alguns casos, não é óbvio, por exemplo, para agregação - há potencialmente mais de uma maneira de agregar as partes constituintes de tensores esparsos, uma escolha idealmente a ser feita pelo cliente
      • KR - provavelmente ter uma pequena família de símbolos dedicados de "soma esparsa" é mais acionável
      • KO - talvez possamos começar prototipando a versão de sparse sum necessária pelo EW e upstream-la para TFF como um operador genérico de sparse sum para semear isso e construir sobre isso (para acompanhar isso offline - talvez em discórdia)
      • EW +1
  • A proposta de Jeremy, continuando de 2 semanas atrás:
    • Nota técnica TFF: conexões iniciadas pelo cliente
    • (fazer para que todos revisem mais tarde, pois foi compartilhado pouco antes da reunião)
    • (Jeremy está apresentando)
    • JL - propondo a abstração “task store” para troca de requisições entre uma “Cloud” e os executores por cliente (p.ex., em navegadores), com estes últimos puxando tarefas de um “task store” centralizado. Algo assim foi considerado em algum outro contexto?
    • KR - sim, em cenários de tratamento de falhas
      • Problemas mais complicados, no entanto - a transferência de estado entre executores é difícil, não tenho certeza de quanto é transferido para o cenário apresentado por Jeremy
    • HV - os executores nas folhas podem ser apátridas
      • JL - isso o tornaria mais parecido com o papel SysML em dispositivos cruzados
    • (pergunta sobre o desempenho neste cenário, comparado ao streaming bidirecional de uma maneira que se assemelha mais ao protocolo TFF nativo)
    • JL - ack que há considerações de latência
    • streaming bidirecional não suportado em alguns transportes, portanto, nem sempre é uma opção viável
    • (acabou o tempo)
    • (continua em 2 semanas - primeiro ponto da agenda para a próxima reunião, Jeremy se juntará)