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

  • 拟议的议程主题：Jeremy Lewi 将展示他基于 TFF 的可构建新组件的想法
  • [JL] 专注于简单的联合分析场景，将 TFF 与 Google 表格连接以执行简单的联合平均。在 Kubernetes 中运行，从表格中读取。
  • [JL] 一项挑战是工作进程目前需要有入口点。
    • 情况通常并非如此，因此需要一个能够在相反方向上建立连接的传输层，并由工作进程调用服务器。
    • 此类组件当前不在生态系统中。
  • [BC] 也看到了这样做的必要性。目前正在以有限的方式使用 TFF，即客户端上传数据的内部云。但是，需要像 JL 在上面描述的那样迁移到多数据中心设置。
  • [JL] 考虑一个可让工作进程从服务器上的队列中“拉取”工作项的层 - 假如它取代现有的运行时。
  • [KO] 不必从“替换”的角度考虑这一点 – 可以保持计算创作和 98% 的运行时相同，只需换入按照您建议的方式工作的新组件，而不是远程执行器，作为自上而下转发执行器请求的机制。
  • [BC] 需要它采用异步方式，还是在现有的同步范例中工作。
  • [BC] 此外，一些现有平台确实使用了“任务队列”方式，所以这听起来像是一种既定的想法。
  • [BC] 引入超时也可能有助于弥补差距（处理缓慢的工作进程或掉队者）。
  • [KO] 针对同步与异步，我们在 TFF 中有需要“同类群组”概念的集合抽象。因此，需要有一段时间，当一些客户端决定一起加入某个“同类群组”时，服务器将需要在协调这一过程中发挥作用。只要做到了这一点，将各个执行器请求转发给客户端的方式就可以有所不同。自上而下调用的远程执行器是一种方式，但不是唯一方式；像上面提出的那样基于工作项的通信模式也绝对适合这种结构。这似乎是为某人起草的小型一两页提案而准备的材料？
  • [JL] 自愿编写新组件的提案，供我们所有人迭代使用。
  • [JL] 顺便说一下，还有其他具有相关功能的相邻仓库吗？
  • [KO] 仅供参考，https://github.com/google/federated-compute 也来自 Google，但它主要关注移动场景，目前未连接到 TFF，也不包含您在这里描述的功能，因此尝试在这个小组中制定一个小提案绝对有意义。
  • [BD] 需要解决的一些问题：缓存结果、何时聚合。
  • [Hao] 如果不是异步，这个场景可能不需要缓存
  • [KO] 对于符合简单 MapReduce 模式的场景，我们确实在 TFF 中提供了一些支持，请参阅 https://www.tensorflow.org/federated/api_docs/python/tff/backends/mapreduce。该库使您能够将 TFF 计算转换为可以在更简单的平台上执行的类 MapReduce 形式。但是，表现力会有所损失，并且前面讨论的一些需要在服务器和客户端之间进行多轮来回通信的想法在此框架中无法表达。而且，跨孤岛设置以独特的方式使这类想法成为可能，因为我们正在处理可以保持长期连接且配置良好的客户端（孤岛）组。
  • [Hao] 集合运算 AllReduce 如何 - 支持或兼容吗
  • [KO] 目前还不行。Allreduce 的用途有限，虽然它可以在单次联合平均场景中使用，但它假定在两轮处理之间服务器上没有发生任何工作。在更普遍的情况下，这是行不通的。但是，拥有它的两个部分 – 高效的广播模式和高效的聚合模式，甚至可能有硬件加速，将是我们可以在 TFF 中利用的内容。
  • [KO] 听起来 JL 想为一个新组件起草一份提案，其他人对其中的内容也有意见 – 让我们合作吧（在座的各位 +1）。两周后再次召开会议，可能会讨论一个草案。