Notatki ze spotkania współpracowników TFF 24.08.2022 r.

Rzadkie wsparcie tensora w TFF:
- EW - Mamy modele Keras, które chcemy przenieść do TFF, mają rzadkie tensory
  - Proste mapowanie do gęstych tensorów skutkuje niedopuszczalnym kosztem pamięci i spowolnieniem w naszym przypadku użycia, więc staramy się tego uniknąć
- ZG o istniejącym rzadkim wsparciu tensora w TFF
  - Problemy wymienione na GitHubie dotyczyły głównie tf.data.Dataset
  - Przeważnie działa inaczej, ale wymaga trochę majsterkowania, szczególnie wrt, agregacji, w których nie możemy po prostu naiwnie zrobić rzadkiej sumy na potrójnej składowej tensorów, która nie przyniosłaby pożądanego rezultatu
- (pytanie o względne znaczenie)
- EW - to nie jest dla nas blokowanie, ale dobra optymalizacja wydajności / zasobów
- ZG - w odniesieniu do problemów z GitHub, może obejść ten problem, ukrywając zbiór danych w obliczeniach TFF, więc nie jest częścią granicy wejścia-wyjścia
- KO - wyjaśnienie, że nasz komentarz „to w większości działa” odnosi się do powszechnej praktyki przedstawiania/obsługi rzadkich tensorów jako krotek gęstych tensorów. Czy próbowałeś również radzić sobie z rzadkimi jako krotkami gęstych tensorów do użytku w zestawach danych?
  - EW - jeszcze nie próbowałem
- KO - rzadki w tej rozmowie pojawił się w dwóch miejscach - dla parametrów modelu, ale także dla rzadkich danych wejściowych - czy oba są równie ważne?
  - EW - idealnie miałby oba
- KO - jeden element działania dla Ewana, który próbuje pracować z krotkami gęstych tensorów, które reprezentują części składowe.
- KO - to nadal pozostawia pytanie o lepsze interfejsy API/pomocniki do obsługi rzadkiego tensora, ale może odblokować ten konkretny przypadek użycia. Myślisz o API?
- EW - najlepiej, gdyby to było po prostu przejrzyste (nie trzeba robić nic specjalnego dla sparse przez klienta używającego TFF i po prostu działa)
  - KO, ZG - w niektórych przypadkach nie jest to oczywiste, np. dla agregacji - istnieje potencjalnie więcej niż jeden sposób agregowania części składowych rzadkich tensorów, wybór najlepiej do klienta
  - KR - prawdopodobnie posiadanie małej rodziny dedykowanych symboli „rzadkiej sumy” jest najbardziej przydatne
  - KO - być może możemy zacząć od prototypowania wersji rzadkiej sumy potrzebnej przez EW i przesłać ją do TFF jako ogólny operator rzadkiej sumy, aby zainicjować to i zbudować na tym (aby kontynuować to offline - może na niezgodzie)
  - EW +1
Propozycja Jeremy'ego, kontynuacja sprzed 2 tygodni:
- Uwaga techniczna TFF: połączenia inicjowane przez klienta
- (do zrobienia dla wszystkich, aby przejrzeć to później, ponieważ zostało udostępnione na krótko przed spotkaniem)
- (Jeremy prezentuje)
- JL - proponowanie abstrakcji „magazynu zadań” do wymiany żądań między „chmurą” a wykonawcami na klienta (np. w przeglądarkach), przy czym te ostatnie pobierają zadania ze scentralizowanego „magazynu zadań”. Czy coś takiego rozważano w innym kontekście?
- KR - tak, w scenariuszach obsługi awarii
  - Jednak bardziej włochate problemy - przeniesienie stanu przez wykonawców jest trudne, nie jestem pewien, jak wiele przenosi się do scenariusza przedstawionego przez Jeremy'ego
- HV - czy wykonawcy na liście mogą być bezpaństwowcami?
  - JL – to bardziej przypominałoby papier SysML na różnych urządzeniach
- (pytanie dotyczące wydajności w tym scenariuszu w porównaniu do przesyłania strumieniowego dwukierunkowego w sposób bardziej zbliżony do natywnego protokołu TFF)
- JL - potwierdź, że istnieją względy dotyczące opóźnień
- dwukierunkowe przesyłanie strumieniowe nie jest obsługiwane w niektórych transportach, więc nie zawsze jest realną opcją
- (zabrakło czasu)
- (kontynuacja za 2 tygodnie - pierwszy punkt agendy następnego spotkania, dołączy Jeremy)