2022년 8월 24일 TFF 협력자 회의 메모

  • TFF의 희소 텐서 지원:
    • EW - TFF로 이식하려는 Keras 모델이 있으며 희소 텐서가 있습니다.
      • 조밀한 텐서에 매핑하기만 하면 사용 사례에서 허용할 수 없는 메모리 비용과 속도 저하가 발생하므로 이를 방지하려고 합니다.
    • TFF의 기존 희소 텐서 지원에 대한 ZG
      • GitHub에서 언급된 문제는 주로 tf.data.Dataset과 관련이 있습니다.
      • 대부분 그렇지 않으면 작동하지만 원하는 결과를 얻지 못하는 구성 텐서의 트리플에 대해 순진하게 희소 합계를 할 수 없는 일부 DIY, 특히 wrt 집계가 필요합니다.
    • (상대적 중요성에 대한 질문)
    • EW - 이것은 우리를 차단하지 않지만 우수한 성능/리소스 풋프린트 최적화입니다.
    • ZG - GitHub 문제와 관련하여 TFF 계산 내부에 데이터 세트를 숨겨서 해결할 수 있으므로 입출력 경계의 일부가 아닙니다.
    • KO - "대부분 작동합니다"라는 설명은 희소 텐서를 조밀한 텐서의 튜플로 표현/처리하는 일반적인 관행을 나타냅니다. 데이터 세트 사용을 위해 조밀한 텐서의 튜플과 같은 희소를 처리해 보셨습니까?
      • EW - 아직 시도하지 않았습니다.
    • KO - 이 대화에서 희소성이 두 곳에서 나타납니다. 모델 매개변수와 희소 입력 데이터의 경우 모두 똑같이 중요합니까?
      • EW - 이상적으로는 둘 다
    • KO - Ewan이 구성 요소를 나타내는 조밀한 텐서의 튜플을 사용하여 작업하려고 하는 하나의 작업 항목입니다.
    • KO - 희소 텐서 처리를 위한 더 나은 API/헬퍼에 대한 질문이 남아 있지만 이 특정 사용 사례를 차단 해제할 수 있습니다. API에 대한 생각은?
    • EW - 이상적으로는 이것이 투명할 수 있습니다(TFF를 사용하는 고객이 희소성을 위해 특별한 작업을 수행할 필요가 없으며 제대로 작동함)
      • KO, ZG - 어떤 경우에는 집계가 명확하지 않습니다. 예를 들어, 희소 텐서의 구성 부분을 집계하는 방법이 두 가지 이상 있을 수 있습니다. 고객이 선택하는 것이 이상적입니다.
      • KR - 소규모 전용 ​​"희소 합계" 기호 제품군이 가장 실행 가능합니다.
      • KO - 아마도 EW에 필요한 희소 합계 버전의 프로토타입을 시작하고 이를 일반 희소 합계 연산자로 TFF에 업스트림하여 이를 시드하고 이를 기반으로 구축할 수 있습니다(오프라인에서 후속 조치 - 아마도 불일치)
      • EW +1
  • 2주 전부터 계속되는 Jeremy의 제안:
    • TFF 기술 노트: 클라이언트가 시작한 연결
    • (모임 직전에 공유되었으므로 나중에 모두 검토할 수 있도록 할 일)
    • (제레미가 발표 중)
    • JL - "클라우드"와 클라이언트별 실행기(예: 브라우저) 간에 요청을 교환하기 위한 "작업 저장소" 추상화를 제안합니다. 후자는 중앙 집중식 "작업 저장소"에서 작업을 가져옵니다. 이와 같은 것이 다른 맥락에서 고려된 적이 있습니까?
    • KR - 예, 실패 처리 시나리오에서
      • 더 심각한 문제는 - 실행자 간의 상태 이전이 어렵고 Jeremy가 제시한 시나리오로 얼마나 이월되는지 확실하지 않습니다.
    • HV - 리프의 실행자가 stateless가 될 수 있습니까?
      • JL - 이것은 교차 장치에서 SysML 문서와 더 유사하게 만듭니다.
    • (기본 TFF 프로토콜과 더 유사한 방식으로 양방향 스트리밍과 비교한 이 시나리오의 성능에 대한 질문)
    • JL - 대기 시간 고려 사항이 있음을 확인
    • 일부 전송에서는 양방향 스트리밍이 지원되지 않으므로 항상 실행 가능한 옵션은 아닙니다.
    • (시간 부족)
    • (2주 후 계속 - 다음 회의의 첫 번째 의제, Jeremy가 합류)