Appunti dall'incontro del 24/08/2022 dei collaboratori del TFF

  • Supporto tensore sparso in TFF:
    • EW - Abbiamo modelli Keras che vogliamo trasferire su TFF, hanno tensori sparsi
      • La semplice mappatura su tensori densi comporta costi di memoria inaccettabili e lentezza nel nostro caso d'uso, quindi stiamo cercando di evitarlo
    • ZG sul supporto del tensore sparso esistente in TFF
      • Problemi menzionati su GitHub principalmente relativi a tf.data.Dataset
      • Per lo più funziona diversamente, ma richiede alcune aggregazioni fai-da-te, in particolare scritte, in cui non possiamo semplicemente fare ingenuamente una somma sparsa sul triplo dei tensori costituenti, che non avrebbe il risultato desiderato
    • (domanda sull'importanza relativa)
    • EW - questo non è un blocco per noi, ma una buona ottimizzazione dell'impronta delle prestazioni/risorse
    • ZG - per quanto riguarda i problemi di GitHub, potrebbe aggirare nascondendo il set di dati all'interno del calcolo TFF, quindi non fa parte del confine input-output
    • KO - chiarire che il nostro commento "per lo più funziona" si riferisce alla pratica comune di rappresentare/gestire tensori sparsi come tuple di tensori densi. Hai provato a gestire sparse come tuple di tensori densi anche per l'utilizzo dei set di dati?
      • EW - non ho ancora provato
    • KO - scarso in questa conversazione è emerso in due punti - per i parametri del modello, ma anche per i dati di input sparsi - sono entrambi ugualmente importanti?
      • EW - idealmente avrebbe entrambi
    • KO - un elemento d'azione per Ewan per provare a lavorare con tuple di tensori densi che rappresentano le parti costituenti.
    • KO - questo lascia ancora una domanda su API/aiutanti migliori per la gestione dei tensori sparsi, ma può sbloccare questo particolare caso d'uso. Pensieri sull'API?
    • EW - idealmente potrebbe essere semplicemente trasparente (non è necessario fare nulla di speciale per sparse da parte del cliente che utilizza TFF e funziona e basta)
      • KO, ZG - in alcuni casi, non è ovvio, ad esempio, per aggregazione - esiste potenzialmente più di un modo per aggregare le parti costituenti dei tensori sparsi, una scelta idealmente a carico del cliente
      • KR - probabilmente avere una piccola famiglia di simboli dedicati a "somma sparsa" è più perseguibile
      • KO - forse possiamo iniziare con la prototipazione della versione di sparse sum necessaria da EW e a monte di TFF come operatore di somma sparse generico per creare questo e costruire su quello (per dare seguito a questo offline - forse su discord)
      • EW +1
  • La proposta di Jeremy, continuando da 2 settimane fa:
    • Nota tecnica TFF: connessioni avviate dal client
    • (da fare per tutti di rivederlo più tardi poiché è stato appena condiviso poco prima dell'incontro)
    • (Jeremy si presenta)
    • JL - proponendo l'astrazione del “task store” per lo scambio di richieste tra un “Cloud” e gli esecutori per-client (es. nei browser), con questi ultimi che estraggono le attività da un “task store” centralizzato. Qualcosa del genere è stato considerato in qualche altro contesto?
    • KR - sì, negli scenari di gestione degli errori
      • Problemi più complicati, però: il trasferimento dello stato tra gli esecutori testamentari è difficile, non sono sicuro di quanto si riporti allo scenario presentato da Jeremy
    • HV - gli esecutori testamentari nei fogli possono essere apolidi
      • JL - questo lo renderebbe più simile al documento SysML su cross-device
    • (domanda sulle prestazioni in questo scenario, rispetto allo streaming bidirezionale in un modo che ricorda più da vicino il protocollo TFF nativo)
    • JL - ack che ci sono considerazioni di latenza
    • streaming bidirezionale non supportato in alcuni trasporti, quindi non sempre un'opzione praticabile
    • (scaduto il tempo)
    • (continua tra 2 settimane - primo punto all'ordine del giorno per il prossimo incontro, Jeremy si unirà)