Notatki ze spotkania współpracowników TFF, które odbyło się 8.11.2022 r

  • Proponowany temat agendy: Jeremy Lewi przedstawi swoje oparte na TFF pomysły na nowe komponenty, które można zbudować
  • [JL] Koncentrowanie się na prostych scenariuszach analizy federacyjnej, łączenie TFF z arkuszami Google w celu prostego uśredniania danych. Praca w Kubernetes, czytanie z kartek.
  • [JL] Jednym z wyzwań jest to, że obecnie pracownicy muszą posiadać punkty wejściowe.
    • Często tak nie jest, więc potrzebna jest warstwa transportowa, która umożliwia nawiązanie łączności w przeciwnym kierunku, pracownicy dzwonią do serwera.
    • Taki składnik nie znajduje się obecnie w ekosystemie.
  • [BC] Również widziałem potrzebę tego. Obecnie korzystamy z TFF w ograniczonym zakresie, z wewnętrznej chmury, do której klienci przesyłają dane. Ale potrzebowałby czegoś takiego jak JL opisanego powyżej, aby przeprowadzić migrację do ustawienia z wieloma centrami danych.
  • [JL] Myślenie o warstwie, która umożliwiłaby pracownikom „wyciągnięcie” elementów pracy z kolejki na serwerze – gdyby zastąpiła ona istniejące środowisko wykonawcze.
  • [KO] Nie musisz myśleć o tym w kategoriach „zastępowania” — możesz zachować te same obliczenia i 98% czasu wykonywania, a zamiast tego po prostu zamienisz nowy komponent, który działa tak, jak proponujesz wyłączyć zdalny executor jako mechanizm przekazywania żądań executora top down.
  • [BC] Czy chcesz, aby był asynchroniczny, czy też działałby w ramach istniejącego paradygmatu synchronizacji.
  • [BC] Ponadto niektóre z wychodzących platform stosują podejście „kolejki zadań”, więc brzmi to jak ustalony pomysł.
  • [BC] Wprowadzenie limitów czasu może również pomóc wypełnić lukę (aby poradzić sobie z wolnymi pracownikami lub maruderami).
  • [KO] W odniesieniu do synchronizacji kontra asynchronii, w TFF mamy zbiorowe abstrakcje, które wymagają pojęcia „kohorty”. W związku z tym musi nadejść czas, w którym niektórzy klienci zdecydują się razem dołączyć do „kohorty”, a serwer musiałby odegrać rolę w zorganizowaniu tego, aby to się stało. Dopóki jest to zrobione, sposób, w jaki poszczególne żądania wykonawców są przekazywane do klientów, może się różnić. Zdalny executor, który wywołuje top-down, jest jednym ze sposobów, ale nie jedynym; wzorzec komunikacji oparty na elementach pracy, taki jak zaproponowany powyżej, również z pewnością pasowałby do tej struktury. Wydaje się, że to materiał na małą, dwustronicową propozycję dla kogoś, kto mógłby ją sporządzić?
  • [JL] Wolontariat, aby napisać propozycję nowego komponentu, abyśmy wszyscy mogli ją powtórzyć.
  • [JL] BTW, czy są inne sąsiednie repozytoria o podobnej funkcjonalności?
  • [KO] FYI, https://github.com/google/federated-compute również od Google, ale skupia się głównie na scenariuszu mobilnym, w tym momencie nie jest połączony z TFF i nie zawiera funkcji, których jesteś opisując tutaj, więc zdecydowanie warto spróbować sformułować małą propozycję w tej grupie.
  • [BD] Kilka pytań do rozwiązania: buforowanie wyników, kiedy agregować.
  • [Hao] Być może nie potrzebujesz buforowania w tym scenariuszu, jeśli nie jest asynchroniczny
  • [KO] W przypadku scenariuszy, które pasują do prostego wzorca MapReduce, mamy pewne wsparcie w TFF, zobacz https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. Ta biblioteka umożliwia tłumaczenie obliczeń TFF na formularz podobny do MapReduce, który można wykonać na prostszej platformie. Istnieje jednak pewna utrata wyrazistości, a niektóre z omówionych wcześniej pomysłów, które wymagały wielu rund komunikacji w tę i z powrotem między sevrr a klientami, nie byłyby możliwe do wyrażenia w tej strukturze. A ustawienie między silosami w unikalny sposób umożliwia tego typu pomysły, ponieważ mamy do czynienia z grupami dobrze zaopatrzonych klientów (silosów), którzy mogą utrzymywać długotrwałe połączenia.
  • [Hao] A co z kolektywnymi operacjami, allreduce - czy te są obsługiwane lub kompatybilne?
  • [KO] Obecnie nie. Allreduce miałby nieco ograniczone zastosowanie, ponieważ chociaż można by go wykorzystać w scenariuszu z pojedynczym podawaniem średniej, zakłada, że ​​między rundami przetwarzania na serwerze nie dzieje się żadna praca. Nie będzie działać w bardziej ogólnych przypadkach. Ale posiadanie dwóch połówek - wydajnego trybu rozgłaszania i wydajnego trybu agregacji, być może nawet z akceleracją sprzętową, byłoby czymś, z czego moglibyśmy skorzystać w TFF.
  • [KO] Wygląda na to, że JL jest gotowy do rozpoczęcia szkicu propozycji nowego komponentu, a inni mają opinie na temat tego, co powinno się w nim znaleźć - współpracujmy (+1 od wszystkich w pokoju). Do ponownego spotkania za 2 tygodnie, ewentualnie z projektem do przedyskutowania.