2022/8/24 の TFF コラボレーターミーティング議事録

• TFF でのスパーステンソルのサポート:

  • EW - TFF に移植したい Keras モデルがある。これらにはスパーステンソルが含まれている

    • 自分たちのユースケースで、高密度テンソルに単純にマッピングすると、許容できないメモリコストと速度低下が生じる。それを回避する方法を探している

  • ZG - TFF に既存のスパーステンソルのサポートについて

    • GitHub で言及されているほとんどの課題は、tf.data.Dataset 関連

    • それ以外はほとんど機能しているが、いくらかの DIY が必要。特に、構成テンソルのトリプルで単純に疎な合計を行うことができない集計に関しては、望ましい結果を得られない

  • （相対的重要性に関する質問）

  • EW - 障害になっていない。パフォーマンス/リソースフットプリント最適化は十分

  • ZG - GitHub 課題については、TFF 計算内にデータセットを隠して入出力の境界に関わらないようにすることで回避可能。

  • KO - 「ほぼ機能する」というコメントは、密なテンソルのタプルとしてスパーステンソルを表現/処理する一般的な慣行を指していることを明確にする。データセットの使用において、スパースを密なテンソルのタプルとして処理したことはあるか？

    • EW - まだ試したことはない

  • KO - この会話のスパースは、モデルパラメータと疎の入力データの 2 つで言及されている。両方とも同等に重要か？

    • EW - 理想的には両方

  • KO - Ewan のアクションアイテムは、構成部分を表す密なテンソルのタプルの操作を試すこと

  • KO - これにより、スパーステンソル処理のためのより優れた API/ヘルパーに関するの疑問が残るが、この特定のユースケースのブロックは解除できる。API についての意見はあるか？

  • EW - 理想的には単にトランスペアレントにできる（顧客が TFF を使ってスパースに特別な操作を行わずに、そのままで動作）

    • KO、ZG - 一部のケースでは、集計などのように明確でないことがある。スパーステンソルの構成部分を集計するには 1 つ以上の方法がある可能性があり、方法の選択は顧客が行うのが理想

    • KR - おそらく専用の小さな “スパースの加算” 記号グループを追加するのが一番対応可能

    • KO - おそらく、EW が必要としてるバージョンのスパース加算をプロトタイプし、これをシードする汎用のスパース加算演算子として TFF にアップストリームし、その上に構築し始めることが可能。（これについてはオフライン - 多分 Discord - でフォローアップ）

    • EW +1

• Jeremy の提案（2 週間前の続き）

  • TFF テックノート: クライアント開始接続

  • （会議直前に共有されたため、各自、後でレビューすること）

  • （Jeremy のプレゼンテーション）

  • JL - 「クラウド」とクライアント単位の Executor
    （ブラウザ内など）間でリクエストを交換するための「タスクストア」抽象化を提案。後者が一元化された「タスクストア」からタスクを引き出す。他のコンテキストで似たようなものを検討したことはないか？

  • KR - はい。障害処理のシナリオで検討したことがある

    • ただし、さらに深刻な問題がある。Executor 間での状態の転送は困難で、どれくらいが Jeremy のシナリオに適用できるかわからない

  • HV - Leaves の Executor はステートレスにできるか？

    • JL - それはクロスデバイスに関する SysML の論文のようになる

  • （このシナリオにおけるパフォーマンスに関する質問。よりネイティブ TFF プロトコルに近い方法での双方向ストリーミングと比較）

  • JL - 遅延の懸念があることを確認

  • 一部のトランスポートでは双方向ストリーミングがサポートされていないため、必ずしも実行可能なオプションとは言えない

  • （時間切れ）

  • （2 週間後に持ち越し - 次回ミーティングのアジェンダの 1 点目に、Jeremy が参加）