- 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
- EW - Abbiamo modelli Keras che vogliamo trasferire su TFF, hanno tensori sparsi
- 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à)
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2022-12-06 UTC.
[{
"type": "thumb-down",
"id": "missingTheInformationINeed",
"label":"Mancano le informazioni di cui ho bisogno"
},{
"type": "thumb-down",
"id": "tooComplicatedTooManySteps",
"label":"Troppo complicato/troppi passaggi"
},{
"type": "thumb-down",
"id": "outOfDate",
"label":"Obsoleti"
},{
"type": "thumb-down",
"id": "translationIssue",
"label":"Problema di traduzione"
},{
"type": "thumb-down",
"id": "samplesCodeIssue",
"label":"Problema relativo a esempi/codice"
},{
"type": "thumb-down",
"id": "otherDown",
"label":"Altra"
}]
[{
"type": "thumb-up",
"id": "easyToUnderstand",
"label":"Facile da capire"
},{
"type": "thumb-up",
"id": "solvedMyProblem",
"label":"Il problema è stato risolto"
},{
"type": "thumb-up",
"id": "otherUp",
"label":"Altra"
}]