Catatan dari pertemuan para kolaborator TFF 24/8/2022

  • Dukungan tensor yang jarang di TFF:
    • EW - Kami memiliki model Keras yang ingin kami port ke TFF, mereka memiliki tensor yang jarang
      • Cukup memetakan ke tensor padat menghasilkan biaya memori yang tidak dapat diterima dan kelambatan dalam kasus penggunaan kami, jadi kami ingin menghindarinya
    • ZG pada dukungan tensor sparse yang ada di TFF
      • Masalah yang disebutkan di GitHub sebagian besar terkait dengan tf.data.Dataset
      • Sebagian besar berfungsi sebaliknya, tetapi memerlukan beberapa DIY, terutama agregasi wrt, di mana kita tidak bisa begitu saja secara naif melakukan jumlah yang jarang pada triple tensor konstituen, yang tidak akan mendapatkan hasil yang diinginkan
    • (pertanyaan tentang kepentingan relatif)
    • EW - ini tidak menghalangi kami, tetapi pengoptimalan jejak kinerja/sumber daya yang baik
    • ZG - sehubungan dengan masalah GitHub, mungkin dapat diatasi dengan menyembunyikan kumpulan data di dalam perhitungan TFF, jadi itu bukan bagian dari batas input-output
    • KO - mengklarifikasi bahwa komentar "sebagian besar berfungsi" kami mengacu pada praktik umum untuk mewakili/menangani tensor jarang sebagai tupel tensor padat. Sudahkah Anda mencoba menangani sparse sebagai tupel tensor padat untuk penggunaan kumpulan data juga?
      • EW - belum mencoba
    • KO - jarang dalam percakapan ini telah muncul di dua tempat - untuk parameter model, tetapi juga untuk data input yang jarang - keduanya sama pentingnya?
      • EW - idealnya memiliki keduanya
    • KO - satu item tindakan bagi Ewan untuk mencoba bekerja dengan tupel tensor padat yang mewakili bagian-bagian penyusunnya.
    • KO - ini masih menyisakan pertanyaan tentang API/pembantu yang lebih baik untuk penanganan tensor yang jarang, tetapi dapat membuka blokir kasus penggunaan khusus ini. Pendapat tentang API?
    • EW - idealnya ini hanya transparan (tidak perlu melakukan sesuatu yang khusus untuk jarang oleh pelanggan menggunakan TFF dan itu hanya berfungsi)
      • KO, ZG - dalam beberapa kasus, itu tidak jelas, misalnya, untuk agregasi - berpotensi ada lebih dari satu cara untuk menggabungkan bagian-bagian penyusun dari sparse tensor, pilihan yang idealnya dibuat oleh pelanggan
      • KR - mungkin memiliki keluarga kecil dengan simbol "jumlah jarang" yang paling dapat ditindaklanjuti
      • KO - mungkin kita bisa mulai dengan membuat prototipe versi sparse sum yang dibutuhkan oleh EW dan upstream ke TFF sebagai operator sparse sum generik untuk menyemai ini, dan membangunnya (untuk menindaklanjuti offline ini - mungkin discord)
      • EW +1
  • Proposal Jeremy, melanjutkan dari 2 minggu yang lalu:
    • Catatan Teknis TFF: Koneksi yang dimulai oleh klien
    • (harus dilakukan agar semua orang meninjaunya nanti karena baru saja dibagikan sesaat sebelum rapat)
    • (Jeremy sedang presentasi)
    • JL - mengusulkan abstraksi "penyimpanan tugas" untuk bertukar permintaan antara "Cloud" dan pelaksana per klien (misalnya, di browser), dengan yang terakhir menarik tugas dari "penyimpanan tugas" terpusat. Apakah hal seperti ini telah dipertimbangkan dalam konteks lain?
    • KR - ya, dalam skenario penanganan kegagalan
      • Masalah yang lebih berbulu, meskipun - transfer negara di pelaksana sulit, tidak yakin berapa banyak membawa ke skenario yang disajikan oleh Jeremy
    • HV - dapatkah pelaksana di daun tidak memiliki kewarganegaraan?
      • JL - ini akan membuatnya lebih seperti kertas SysML di lintas perangkat
    • (pertanyaan tentang kinerja dalam skenario ini, dibandingkan dengan streaming dua arah dengan cara yang lebih mirip dengan protokol TFF asli)
    • JL - akui bahwa ada pertimbangan latensi
    • streaming dua arah tidak didukung di beberapa transportasi, jadi tidak selalu merupakan opsi yang layak
    • (kehabisan waktu)
    • (bersambung dalam 2 minggu - poin pertama agenda pertemuan berikutnya, Jeremy akan bergabung)