Заметки о встрече сотрудников TFF 11.08.2022 г.

  • Предлагаемая тема повестки дня: Джереми Льюи представит свои идеи на основе TFF для новых компонентов, которые можно построить.
  • [JL] Сосредоточение внимания на простых сценариях федеративной аналитики, соединении TFF с таблицами Google для простого усреднения федерации. Работаю в Kubernetes, читаю с листов.
  • [JL] Одна из проблем заключается в том, что в настоящее время рабочие должны иметь точки входа.
    • Часто это не так, поэтому нужен транспортный уровень, который позволяет установить соединение в обратном направлении, когда рабочие вызовут сервер.
    • Такого компонента в настоящее время нет в экосистеме.
  • [BC] Тоже видел в этом необходимость. В настоящее время ограниченно используется TFF, собственное облако, куда клиенты загружают данные. Но для перехода на настройку с несколькими центрами обработки данных потребуется что-то вроде JL, описанного выше.
  • [JL] Думаем о слое, который позволил бы работникам «извлекать» рабочие элементы из очереди на сервере — если он заменит существующую среду выполнения.
  • [KO] Не нужно думать об этом с точки зрения «замены» — вы можете оставить разработку вычислений и 98% среды выполнения одинаковыми, и вы просто замените новый компонент, который работает так, как вы предлагаете вместо этого от удаленного исполнителя в качестве механизма ретрансляции запросов исполнителя сверху вниз.
  • [BC] Нужно ли вам, чтобы он был асинхронным, или он будет работать в рамках существующей парадигмы синхронизации.
  • [BC] Кроме того, некоторые из существующих платформ используют подход «очереди задач», так что это звучит как устоявшаяся идея.
  • [BC] Введение тайм-аутов также, возможно, помогло бы преодолеть разрыв (чтобы иметь дело с медленными работниками или отставшими).
  • [KO] Что касается синхронизации и асинхронности, у нас есть коллективные абстракции в TFF, которые требуют понятия «когорты». Таким образом, должно быть время, когда некоторые из клиентов вместе решат присоединиться к «когорте», и сервер должен будет сыграть роль в организации этого. Пока это сделано, способ, которым отдельные запросы исполнителя передаются клиентам, может варьироваться. Удаленный исполнитель, который вызывает сверху вниз, является одним из способов сделать это, но не единственным; модель коммуникации на основе рабочих элементов, подобная той, что была предложена выше, также определенно может вписаться в эту структуру. Похоже на материал для небольшого одно-двухстраничного предложения, которое кто-то может составить?
  • [JL] Вызывает желание записать предложение по новому компоненту, чтобы мы все могли его повторить.
  • [JL] Кстати, есть ли другие соседние репозитории с похожими функциями?
  • [KO] К вашему сведению, https://github.com/google/federated-compute также от Google, но он в основном ориентирован на мобильный сценарий, на данный момент он не подключен к TFF и не содержит функций, которые вам нужны. описание здесь, поэтому определенно имеет смысл попытаться сформулировать небольшое предложение в этой группе.
  • [BD] Некоторые вопросы, на которые следует ответить: кэширование результатов, когда агрегировать.
  • [Хао] Возможно, в этом сценарии кэширование не требуется, если оно не асинхронно.
  • [KO] Для сценариев, соответствующих простому шаблону MapReduce, у нас есть некоторая поддержка в TFF, см. https://www.tensorflow.org/federated/api_docs/python/tff/backends/mapreduce . Эта библиотека позволяет преобразовывать вычисления TFF в форму, подобную MapReduce, которую можно выполнять на более простой платформе. Тем не менее, есть некоторая потеря в выразительности, и некоторые из обсуждавшихся ранее идей, требующих многократных циклов обратной связи между sevrr и клиентами, не могут быть выражены в этой структуре. Кроме того, кросс-хранилища уникальным образом делают возможными такие идеи, поскольку мы имеем дело с группами хорошо подготовленных клиентов (хранилищ), которые могут поддерживать длительные соединения.
  • [Хао] Что насчет коллективных операций, allreduce — поддерживаются или совместимы?
  • [КО] Сейчас нет. Allreduce будет иметь несколько ограниченное применение, поскольку, хотя его можно использовать в сценарии с одной подачей avg, он предполагает, что между раундами обработки на сервере не выполняется никакой работы. Не будет работать в более общих случаях. Но наличие двух половинок — эффективного режима вещания и эффективного режима агрегирования, возможно, даже с аппаратным ускорением — было бы чем-то, чем мы могли бы воспользоваться в TFF.
  • [KO] Похоже, что JL готов начать проект предложения по новому компоненту, и у других есть мнения о том, что должно быть в нем — давайте сотрудничать (+1 от всех в комнате). Вновь собраться через 2 недели, возможно, с проектом для обсуждения.