Notatki ze spotkania 8/11/2022 współpracowników TFF

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.