Catatan pertemuan kolaborator TFF 8/11/2022

  • Topik agenda yang diusulkan: Jeremy Lewi akan mempresentasikan ide-ide berbasis TFF untuk komponen baru yang dapat dibangun
  • [JL] Berfokus pada skenario analitik gabungan sederhana, menghubungkan TFF dengan lembar Google untuk melakukan rata-rata makan sederhana. Bekerja di Kubernetes, membaca dari lembar.
  • [JL] Salah satu tantangannya adalah saat ini pekerja diharuskan memiliki titik masuk.
    • Hal ini sering tidak terjadi, sehingga memerlukan lapisan transport yang memungkinkan konektivitas dibuat dalam arah yang berlawanan, pekerja memanggil server.
    • Komponen tersebut saat ini tidak berada dalam ekosistem.
  • [BC] Juga melihat perlunya ini. Saat ini menggunakan TFF secara terbatas, cloud internal tempat klien mengunggah data. Tapi, akan membutuhkan sesuatu seperti JL yang dijelaskan di atas untuk bermigrasi ke pengaturan multi-pusat data.
  • [JL] Memikirkan lapisan yang memungkinkan pekerja untuk "menarik" item pekerjaan dari antrian di server - jika itu menggantikan runtime yang ada.
  • [KO] Tidak perlu memikirkan hal ini dalam hal "mengganti" - Anda dapat membuat komputasi authoring dan 98% runtime tetap sama, dan Anda cukup menukar komponen baru yang berfungsi seperti yang Anda usulkan mematikan eksekutor jarak jauh sebagai mekanisme untuk menyampaikan permintaan eksekutor dari atas ke bawah.
  • [BC] Apakah Anda memerlukannya menjadi asinkron, atau apakah itu berfungsi dalam paradigma sinkronisasi yang ada.
  • [BC] Juga, beberapa platform yang ada menggunakan pendekatan "antrian tugas", jadi ini terdengar seperti ide yang mapan.
  • [BC] Memperkenalkan batas waktu mungkin juga akan membantu menjembatani kesenjangan (untuk menangani pekerja yang lambat atau orang yang tersesat).
  • [KO] Sehubungan dengan sinkronisasi vs. asinkron, kami memiliki abstraksi kolektif di TFF yang memerlukan gagasan "kohort". Dengan demikian, perlu ada waktu ketika beberapa klien di luar sana memutuskan bersama untuk bergabung dengan "kohort", dan server perlu berperan dalam mengatur hal ini agar terjadi. Selama itu dilakukan, cara permintaan eksekutor individu diteruskan ke klien kemudian dapat bervariasi. Eksekutor jarak jauh yang memanggil top-down adalah salah satu cara untuk melakukannya, tetapi bukan satu-satunya; pola komunikasi berbasis item pekerjaan seperti yang diusulkan di atas juga pasti bisa masuk ke dalam struktur ini. Sepertinya bahan untuk proposal kecil satu-dua pager untuk disusun seseorang?
  • [JL] Sukarela menulis proposal untuk komponen baru untuk kita semua ulangi.
  • [JL] BTW, apakah ada repo lain yang berdekatan dengan fungsi terkait?
  • [KO] FYI, https://github.com/google/federated-compute juga dari Google, tetapi itu sebagian besar berfokus pada skenario seluler, saat ini tidak terhubung ke TFF, dan tidak berisi fungsi yang Anda gunakan menjelaskan di sini, jadi masuk akal untuk mencoba dan merumuskan proposal kecil di grup ini.
  • [BD] Beberapa pertanyaan yang harus dijawab: hasil caching, kapan harus dikumpulkan.
  • [Hao] Mungkin tidak perlu caching dalam skenario ini jika tidak async
  • [KO] Untuk skenario yang sesuai dengan pola MapReduce sederhana, kami memiliki beberapa dukungan di TFF, lihat https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. Pustaka ini memungkinkan Anda untuk menerjemahkan perhitungan TFF ke dalam bentuk seperti MapReduce yang dapat Anda jalankan pada platform yang lebih sederhana. Namun, ada beberapa kehilangan dalam ekspresi, dan beberapa ide yang dibahas sebelumnya yang membutuhkan beberapa putaran komunikasi bolak-balik antara sevrr dan klien tidak akan diungkapkan dalam kerangka ini. Dan, pengaturan lintas-silo secara unik memungkinkan jenis ide tersebut, karena kita berurusan dengan kelompok klien (silo) yang disediakan dengan baik yang dapat mempertahankan koneksi jangka panjang.
  • [Hao] Bagaimana dengan operasi kolektif, semuanya dikurangi - apakah itu didukung atau kompatibel
  • [KO] Tidak saat ini. Allreduce akan memiliki penggunaan yang agak terbatas, karena meskipun dapat dimanfaatkan dalam satu skenario rata-rata makan, ia mengasumsikan tidak ada pekerjaan yang terjadi di server di antara putaran pemrosesan. Tidak akan berfungsi dalam kasus yang lebih umum. Tetapi, memiliki dua bagiannya - mode penyiaran yang efisien dan mode pengumpulan yang efisien, bahkan mungkin dengan akselerasi perangkat keras, akan menjadi sesuatu yang dapat kita manfaatkan di TFF.
  • [KO] Sepertinya JL siap untuk memulai draf proposal untuk komponen baru, dan yang lain memiliki pendapat tentang apa yang seharusnya ada di dalamnya - mari berkolaborasi (+1 dari semua yang ada di ruangan). Untuk berkumpul kembali dalam 2 minggu, mungkin dengan konsep untuk didiskusikan.