2022 年 8 月 24 日 TFF 协作者会议笔记

  • TFF 中的稀疏张量支持：
    • EW - 我们有想要移植到 TFF 的 Keras 模型，它们有稀疏张量
      • 在我们的用例中，简单地映射到密集张量会导致不可接受的内存成本和速度缓慢，因此我们希望避免这种情况
    • ZG 关于 TFF 中现有的稀疏张量支持
      • GitHub 上提到的议题大多与 tf.data.Dataset 相关
      • 大多数情况下都有效，但它需要一些 DIY，尤其是涉及到聚合时，我们不能只是天真地对三个构成张量求稀疏和，这样无法获得想要的结果
    • （关于相对重要性的问题）
    • EW - 这对我们来说不是阻塞，而是一个很好的性能/资源占用优化
    • ZG - 关于 GitHub 议题，可以通过在 TFF 计算中隐藏数据集来解决，因此它不是输入输出边界的一部分
    • KO - 澄清我们的““it mostly works”评论是指将稀疏张量表示/处理为密集张量的元组的常见做法。您是否也尝试过在使用数据集时将稀疏作为密集张量的元组来处理？
      • EW - 还没试过
    • KO - 在这次对话中，稀疏出现在两个地方 - 用于模型参数，但也用于稀疏输入数据 - 两者是否同样重要？
      • EW - 理想情况下两者都重要
    • KO - Ewan 尝试使用代表构成部分的密集张量元组的一个操作项。
    • KO - 这仍然留下了一个关于更好的 API/辅助函数用于稀疏张量处理的问题，但可以解锁此特定用例。关于 API 有何想法？
    • EW - 理想情况下，可以是透明的（使用 TFF 的客户无需为稀疏执行任何特殊操作，它就可以生效）
      • KO、ZG - 在某些情况下，它并不明显，例如，对于聚合 – 可能有不止一种方法来聚合稀疏张量的构成部分，最好由客户做出选择
      • KR - 可能有一小群专用的“稀疏和”符号是最可行的
      • KO - 也许我们可以从 EW 所需的稀疏和版本的原型设计开始，并将其作为通用稀疏和算子上传到 TFF 来播种，并以此为基础进行构建（在离线状态下跟进 – 也许在 Discord 上）
      • EW +1
  • Jeremy 的提议，从 2 周前开始继续：
    • TFF 技术笔记：客户端启动的连接
    • （由于会议前不久刚刚分享过，所以大家稍后再看）
    • （Jeremy 在介绍）
    • JL - 提出了 "任务存储区 "的抽象概念，用于在 "云 "和每个客户端执行器（例如，在浏览器中）之间交换请求，后者从中央“任务存储区”中提取任务。在其他情况下是否考虑过类似的事情？
    • KR - 是的，在故障处理场景中
      • 然而，更棘手的问题是 – 跨执行器的状态转移十分困难，不确定有多少会延续到 Jeremy 提出的场景
    • HV - 叶子中的执行器可以是无状态的吗
      • JL - 这将使它更像跨设备的 SysML 论文
    • （关于这种场景下的性能问题，与双向流相比，更接近原生 TFF 协议的方式）
    • JL - 注意到有延迟方面的考虑
    • 某些传输不支持双向流，因此并不总是可行的选择
    • （没时间了）
    • （将在 2 周后继续 – 下次会议议程的第一点，Jeremy 将加入）