Notes de la réunion du 24/08/2022 des collaborateurs de la TFF

  • Prise en charge des tenseurs clairsemés dans TFF :
    • EW - Nous avons des modèles Keras que nous voulons porter sur TFF, ils ont des tenseurs clairsemés
      • Le simple mappage sur des tenseurs denses entraîne un coût de mémoire inacceptable et une lenteur dans notre cas d'utilisation, nous cherchons donc à éviter cela
    • ZG sur le support de tenseur clairsemé existant dans TFF
      • Problèmes mentionnés sur GitHub principalement liés à tf.data.Dataset
      • La plupart du temps fonctionne autrement, mais cela nécessite du bricolage, en particulier des agrégations où nous ne pouvons pas simplement faire naïvement une somme clairsemée sur le triple des tenseurs constitutifs, cela n'aurait pas le résultat souhaité
    • (question sur l'importance relative)
    • EW - ce n'est pas bloquant pour nous, mais une bonne optimisation des performances/ressources
    • ZG - en ce qui concerne les problèmes de GitHub, peut contourner en masquant l'ensemble de données à l'intérieur du calcul TFF, de sorte qu'il ne fait pas partie de la limite d'entrée-sortie
    • KO - clarifiant que notre commentaire "ça marche surtout" fait référence à la pratique courante de représenter/traiter des tenseurs clairsemés comme des tuples de tenseurs denses. Avez-vous également essayé de traiter des tuples clairsemés de tenseurs denses pour l'utilisation des ensembles de données?
      • EW - pas encore essayé
    • KO - clairsemé dans cette conversation est apparu à deux endroits - pour les paramètres du modèle, mais aussi pour les données d'entrée clairsemées - sont-ils tous les deux également importants ?
      • EW - aurait idéalement les deux
    • KO - un élément d'action pour Ewan pour essayer de travailler avec des tuples de tenseurs denses qui représentent les parties constituantes.
    • KO - cela laisse encore une question sur les meilleures API/aides pour la gestion des tenseurs clairsemés, mais peut débloquer ce cas d'utilisation particulier. Des réflexions sur l'API ?
    • EW - idéalement, cela pourrait-il simplement être transparent (pas besoin de faire quoi que ce soit de spécial pour le client utilisant TFF et cela fonctionne)
      • KO, ZG - dans certains cas, ce n'est pas évident, par exemple pour l'agrégation - il y a potentiellement plus d'une façon d'agréger les parties constituantes des tenseurs clairsemés, un choix idéalement à faire par le client
      • KR - avoir probablement une petite famille de symboles dédiés à la "somme clairsemée" est le plus exploitable
      • KO - peut-être pouvons-nous commencer par prototyper la version de la somme éparse requise par EW et l'amont vers TFF en tant qu'opérateur de somme éparse générique pour semer ceci, et construire sur cela (pour faire un suivi hors ligne - peut-être sur discord)
      • EO +1
  • La proposition de Jeremy, suite d'il y a 2 semaines :
    • Note technique TFF : Connexions initiées par le client
    • (à faire pour que tous l'examinent plus tard car il vient d'être partagé peu de temps avant la réunion)
    • (Jeremy présente)
    • JL - propose l'abstraction « magasin de tâches » pour échanger des requêtes entre un « Cloud » et les exécuteurs par client (par exemple, dans les navigateurs), ces derniers extrayant des tâches d'un « magasin de tâches » centralisé. Une telle chose a-t-elle été envisagée dans un autre contexte ?
    • KR - oui, dans les scénarios de gestion des pannes
      • Des problèmes plus épineux, cependant - le transfert d'état entre les exécuteurs est difficile, je ne sais pas dans quelle mesure le scénario présenté par Jeremy
    • HV - les exécuteurs testamentaires dans les feuilles peuvent-ils être apatrides
      • JL - cela ressemblerait davantage au document SysML sur plusieurs appareils
    • (question sur les performances dans ce scénario, par rapport au streaming bidirectionnel d'une manière qui ressemble plus au protocole TFF natif)
    • JL - reconnais qu'il y a des considérations de latence
    • le streaming bidirectionnel n'est pas pris en charge dans certains transports, donc pas toujours une option viable
    • (a manqué de temps)
    • (à suivre dans 2 semaines - premier point à l'ordre du jour de la prochaine réunion, Jérémy rejoindra)