- Предлагаемая тема повестки дня: Джереми Льюи представит свои идеи на основе 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 недели, возможно, с проектом для обсуждения.
Если не указано иное, контент на этой странице предоставляется по лицензии Creative Commons "С указанием авторства 4.0", а примеры кода – по лицензии Apache 2.0. Подробнее об этом написано в правилах сайта. Java – это зарегистрированный товарный знак корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2022-12-06 UTC.
[{
"type": "thumb-down",
"id": "missingTheInformationINeed",
"label":"Отсутствует нужная мне информация"
},{
"type": "thumb-down",
"id": "tooComplicatedTooManySteps",
"label":"Слишком сложен/слишком много шагов"
},{
"type": "thumb-down",
"id": "outOfDate",
"label":"Устарел"
},{
"type": "thumb-down",
"id": "translationIssue",
"label":"Проблема с переводом текста"
},{
"type": "thumb-down",
"id": "samplesCodeIssue",
"label":"Проблемы образцов/кода"
},{
"type": "thumb-down",
"id": "otherDown",
"label":"Другое"
}]
[{
"type": "thumb-up",
"id": "easyToUnderstand",
"label":"Прост для понимания"
},{
"type": "thumb-up",
"id": "solvedMyProblem",
"label":"Помог мне решить мою проблему"
},{
"type": "thumb-up",
"id": "otherUp",
"label":"Другое"
}]