TensorFlow-Federated中线程池使用率受限的原因是什么？

这种情况主要源于TFF执行器架构的演进节奏、核心场景优先级以及兼容性保障等维度：

• 执行器架构的渐进式迭代
  TFF的执行器体系是逐步扩展的，最初的核心实现围绕单节点执行场景构建，ThreadPool参数是早期为特定执行器（比如本地参考实现执行器）设计的线程调度优化选项。后续新增的执行器（如远程执行器、分布式执行器）在设计时，要么自带了更适配自身场景的线程管理机制（比如依赖底层分布式框架的线程池），要么出于简化架构的考虑，暂未接入通用的ThreadPool配置接口，导致该参数只在最早的那个执行器实现中留存。

• 核心场景的优先级导向
  TFF的核心目标是支撑联邦学习场景的分布式计算，早期单节点执行器更多用于本地调试、原型验证。团队优先投入资源优化分布式执行路径的线程调度，对于单节点场景的通用线程池配置需求优先级较低，因此没有将ThreadPool参数推广到所有执行器实现中。

• 兼容性与最小改动原则
  为避免破坏现有用户代码的兼容性，TFF团队在迭代中倾向于保留旧有接口的原有行为。ThreadRun默认启动新线程的逻辑已经被大量用户代码依赖，而ThreadPool参数作为可选扩展，仅在需要的执行器中启用，既满足了特定场景的优化需求，又不会给整体架构引入不必要的复杂度。

• 线程调度的场景差异化需求
  不同执行器的线程调度需求差异显著：本地单执行器需要轻量线程池来复用线程、降低开销；远程执行器依赖远程节点的调度机制，本地线程池配置意义不大；分布式执行器可能需要跨节点的线程协调逻辑，通用ThreadPool参数无法适配这类场景。因此团队没有强行统一线程池配置接口，而是让各执行器按需实现。

内容的提问来源于stack exchange，提问作者Keith Rush