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

• Suporte ao tensor esparso no TFF:

  • EW – Temos modelos do Keras que queremos migrar para o TFF; esses modelos têm tensores esparsos

    • Simplesmente mapear esses tensores densos traria um custo de memória e uma lentidão inaceitáveis em nosso caso de uso, queremos evitar isso

  • ZG sobre o suporte atual a tensores esparsos no TFF

    • Issues mencionados no GitHub estão relacionados principalmente ao tf.data.Dataset

    • Funciona na maioria dos casos, mas exige um certo trabalho manual, especialmente em relação a agregações em que não podemos fazer uma soma esparsa de forma ingênua da tupla de tensores componentes, pois isso não traria o resultado desejado

  • (Pergunta sobre importância relativa)

  • EW – Isso não é impeditivo para nós, mas uma boa otimização de desempenho/uso de recursos

  • ZG – Com relação aos issues no GitHub, uma solução alternativa é ocultar o dataset dentro da computação do TFF para não fazer parte da fronteira entrada-saída

  • KO – Esclarecer que o comentário “funciona na maioria dos casos” refere-se à prática comum de representar/tratar tensores esparsos como tuplas de tensores densos. Você também tentou lidar com tensores esparsos como tuplas de tensores densos para o uso de datasets?

    • EW – Ainda não tentei

  • KO – Nesta conversa, o termo "esparso" foi mencionado em dois casos: para parâmetros de modelo, mas também para dados de entrada esparsos. Os dois são igualmente importantes?

    • EW – Idealmente, preciso dos dois

  • KO – Um item de ação: Ewan vai tentar trabalhar com tuplas de tensores densos que representem as partes componentes.

  • KO – Isso deixa uma questão sobre APIs/helpers melhores para tratar tensores esparsos, mas isso pode permitir esse caso de uso específico. Alguma sugestão sobre a API?

  • EW – Idealmente, deveria ser transparente (o cliente não precisa fazer nada de especial para tensores esparsos ao usar o TFF, simplesmente funciona)

    • KO, ZG – Em alguns casos, não é óbvio. Por exemplo, para agregação, há possivelmente mais de uma maneira de agregar as partes componentes dos tensores esparsos, uma escolha que idealmente deve ser feita pelo cliente

    • KR – Provavelmente é mais prático ter uma pequena família de símbolos de “soma esparsa” exclusivos

    • KO – Talvez possamos começar fazendo o protótipo da versão da soma esparsa necessária para EW e fazer o upstream para o TFF como um operador genérico de soma esparsa para permitir isso e depois ampliar (vamos prosseguir após o encontro, talvez no Discord)

    • EW – Concordo

• Proposta de Jeremy, retomando de duas semanas atrás:

  • Nota técnica sobre o TFF: conexões iniciadas pelo cliente

  • (Todos devem revisar posteriormente, pois foi compartilhado pouco antes do encontro)

  • (Jeremy está apresentado)

  • JL – Proponho a abstração do “repositório de tarefas” para troca de solicitações entre um executor “na nuvem” e executores por cliente (por exemplo, em navegadores), sendo que estes buscam tarefas em um “repositório de tarefas” centralizado. Algo parecido já foi considerado em algum outro contexto?

  • KR – Sim, em cenários de tratamento de falhas

    • Mais problemas complicados: a transferência de estado entre executores é difícil, não sei o quanto disso aplica-se ao cenário apresentado por Jeremy

  • HV – Os executores nos nós folha podem ser stateless?

    • JL – Isso seria parecido com o artigo SysML sobre interdispositivos

  • (Pergunta sobre desempenho nesse cenário em comparação à transmissão bidirecional de uma forma que lembre mais o protocolo TFF nativo)

  • JL – Reconheço que existem considerações de latência

  • Não há suporte à transmissão bidirecional em alguns transportes, nem sempre é uma opção viável

  • (Acabou o tempo)

  • (Continuaremos em duas semanas – o primeiro tópico da pauta do próximo encontro, Jeremy vai participar)