2022 年 8 月 24 日 TFF 協力者会議のメモ

TFF でのスパーステンソルのサポート:
- EW - TFF に移植したい Keras モデルがあり、疎なテンソルがあります
  - 単純に密なテンソルにマッピングすると、許容できないほどのメモリコストが発生し、このユースケースでは速度が低下するため、それを回避しようとしています。
- TFF での既存のスパーステンソルサポートに関する ZG
  - GitHub で言及されている問題は主に tf.data.Dataset に関連しています
  - それ以外の場合はほとんど機能しますが、DIY、特に wrt の集計が必要であり、構成要素テンソルのトリプルで単純に疎な合計を行うことができず、望ましい結果が得られません。
- （相対的な重要性についての質問）
- EW - これは私たちにとって妨げではありませんが、優れたパフォーマンス/リソースフットプリントの最適化です
- ZG - GitHubの問題に関しては、TFF計算内にデータセットを隠すことで回避できる可能性があるため、入出力境界の一部ではありません
- KO - 「ほとんど機能する」というコメントは、疎なテンソルを密なテンソルのタプルとして表現/処理する一般的な方法を指していることを明確にします。データセットの使用のために、密なテンソルのタプルとしてスパースを扱ってみましたか?
  - EW - まだ試していません
- KO - この会話ではスパースが 2 つの場所で出てきました - モデルパラメータだけでなく、スパース入力データに対しても - どちらも同じように重要ですか?
  - EW - 両方が理想的
- KO - Ewan が構成要素を表す密なテンソルのタプルを操作するための 1 つのアクションアイテム。
- KO - これはスパーステンソル処理のためのより良い API/ヘルパーについての疑問を残していますが、この特定のユースケースのブロックを解除することができます。 API についての考えはありますか?
- EW - 理想的には、これは透過的である可能性があります (顧客が TFF を使用してスパースに対して特別なことをする必要はなく、それは機能します)
  - KO、ZG - いくつかのケースでは、例えば集約のため、それは明らかではありません - 疎なテンソルの構成部分を集約する方法が複数ある可能性があり、理想的には顧客が選択する必要があります
  - KR - おそらく、専用の「スパースサム」シンボルの小さなファミリを持つことが最も実用的です。
  - KO - おそらく、EW に必要なスパースサムのバージョンをプロトタイピングすることから始めて、これを一般的なスパースサムオペレータとして TFF にアップストリームして、これをシードし、その上に構築することができます (このオフラインでフォローアップするため - 多分不一致で)
  - 東西+1
Jeremy の提案、2 週間前からの続き:
- TFF テクニカルノート: クライアントが開始する接続
- (会議の直前に共有されたばかりなので、後で確認するために全員が Todo を使用)
- （ジェレミーがプレゼンター）
- JL - 「クラウド」とクライアントごとのエグゼキューター (ブラウザーなど) の間でリクエストを交換するための「タスクストア」抽象化を提案し、後者は集中型の「タスクストア」からタスクをプルします。このようなことは、他の文脈で考慮されましたか？
- KR - はい、障害処理シナリオでは
  - ただし、より厄介な問題 - エグゼキューター間の状態転送は困難であり、Jeremy によって提示されたシナリオにどれだけ引き継がれるかわからない
- HV - リーフのエグゼキュータはステートレスにできますか
  - JL - これにより、クロスデバイスに関する SysML ペーパーのようになります。
- (ネイティブ TFF プロトコルにより近い方法での双方向ストリーミングと比較した、このシナリオでのパフォーマンスに関する質問)
- JL - レイテンシに関する考慮事項があることを認めます
- 一部のトランスポートでは双方向ストリーミングがサポートされていないため、常に実行可能なオプションとは限りません
- (時間切れ)
- (2 週間後に続く - 次の会議の議題の最初のポイント、ジェレミーが参加します)