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 将加入）