- Поддержка разреженных тензоров в TFF:
- EW — у нас есть модели Keras, которые мы хотим перенести в TFF, у них разреженные тензоры.
- Простое сопоставление с плотными тензорами приводит к неприемлемым затратам памяти и замедлению в нашем случае использования, поэтому мы стремимся избежать этого.
- ZG о существующей поддержке разреженных тензоров в TFF
- Проблемы, упомянутые на GitHub, в основном связаны с tf.data.Dataset.
- В основном работает иначе, но требует некоторых самостоятельных агрегаций, особенно с точки зрения, когда мы не можем просто наивно вычислить разреженную сумму по тройке составляющих тензоров, что не дало бы желаемого результата.
- (вопрос об относительной важности)
- EW - для нас это не блокировка, а хорошая оптимизация производительности/ресурсоемкости.
- ZG — что касается проблем с GitHub, можно обойти это, скрыв набор данных внутри вычисления TFF, чтобы он не был частью границы ввода-вывода.
- KO — поясняем, что наш комментарий «это в основном работает» относится к общепринятой практике представления/обработки разреженных тензоров в виде кортежей плотных тензоров. Пробовали ли вы также работать с разреженными кортежами плотных тензоров для использования наборов данных?
- ЭВ - еще не пробовал
- КО - разреженность в этом разговоре возникла в двух местах - для параметров модели, но и для разреженных входных данных - оба одинаково важны?
- РЭБ - в идеале было бы и то, и другое
- KO — одно действие для Юэна, чтобы попытаться работать с кортежами плотных тензоров, которые представляют составные части.
- KO - это все еще оставляет вопрос о лучших API/помощниках для обработки разреженных тензоров, но может разблокировать этот конкретный вариант использования. Мысли об API?
- EW - в идеале это может быть просто прозрачным (не нужно делать ничего особенного для разреженного клиента, использующего TFF, и это просто работает)
- КО, ЗГ - в некоторых случаях неочевидно, например, для агрегации - потенциально существует более одного способа агрегирования составных частей разреженных тензоров, выбор в идеале должен делать заказчик
- KR - вероятно, наличие небольшого семейства специальных символов «разреженной суммы» наиболее действенно.
- KO — возможно, мы можем начать с прототипирования версии разреженной суммы, необходимой для EW, и воспроизвести ее в TFF в качестве общего оператора разреженной суммы, чтобы заполнить это и построить на этом (чтобы продолжить это в автономном режиме — возможно, на разногласиях)
- РЭБ +1
- EW — у нас есть модели Keras, которые мы хотим перенести в TFF, у них разреженные тензоры.
- Предложение Джереми, продолжающееся 2 недели назад:
- Техническое примечание TFF: соединения, инициированные клиентом
- (нужно всем просмотреть его позже, так как он был опубликован незадолго до встречи)
- (выступает Джереми)
- JL — предлагает абстракцию «хранилище задач» для обмена запросами между «Облаком» и исполнителями для каждого клиента (например, в браузерах), при этом последние извлекают задачи из централизованного «хранилища задач». Рассматривалось ли нечто подобное в каком-либо другом контексте?
- КР - да, в сценариях обработки отказов
- Однако более сложные проблемы - передача состояния между исполнителями затруднена, не уверен, насколько это переносится на сценарий, представленный Джереми.
- HV - могут ли исполнители в листьях быть без гражданства
- JL - это сделало бы его более похожим на статью SysML о кросс-девайсах.
- (вопрос о производительности в этом сценарии по сравнению с двунаправленной потоковой передачей, которая больше напоминает собственный протокол TFF)
- JL - подтвердите, что есть соображения по задержке
- двунаправленная потоковая передача не поддерживается некоторыми транспортными средствами, поэтому не всегда целесообразно
- (ушло время)
- (продолжение через 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":"Другое"
}]