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

  • Поддержка разреженных тензоров в 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
  • Предложение Джереми, продолжающееся 2 недели назад:
    • Техническое примечание TFF: соединения, инициированные клиентом
    • (нужно всем просмотреть его позже, так как он был опубликован незадолго до встречи)
    • (выступает Джереми)
    • JL — предлагает абстракцию «хранилище задач» для обмена запросами между «Облаком» и исполнителями для каждого клиента (например, в браузерах), при этом последние извлекают задачи из централизованного «хранилища задач». Рассматривалось ли нечто подобное в каком-либо другом контексте?
    • КР - да, в сценариях обработки отказов
      • Однако более сложные проблемы - передача состояния между исполнителями затруднена, не уверен, насколько это переносится на сценарий, представленный Джереми.
    • HV - могут ли исполнители в листьях быть без гражданства
      • JL - это сделало бы его более похожим на статью SysML о кросс-девайсах.
    • (вопрос о производительности в этом сценарии по сравнению с двунаправленной потоковой передачей, которая больше напоминает собственный протокол TFF)
    • JL - подтвердите, что есть соображения по задержке
    • двунаправленная потоковая передача не поддерживается некоторыми транспортными средствами, поэтому не всегда целесообразно
    • (ушло время)
    • (продолжение через 2 недели - первый пункт повестки дня следующей встречи, Джереми присоединится)