尧图网站建设 
Flower Runtime 对比指南Simulation Runtime 与 Deployment Runtime 的架构差异、切换方式与选型实践【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本篇技术指南基于 FlowerFriendly Federated AI Framework官方文档中的 Flower Runtime Comparison 参考页展开系统对比 Flower 两种 Runtime——Simulation Runtime仿真 Runtime与Deployment Runtime部署 Runtime——在生命周期、环境、数据、后端、执行模式、通信、服务端与客户端基础设施等维度的关键差异。读完本文你将掌握同一份 Flower App 如何在两种 Runtime 之间无缝切换、各自底层架构Ray 多进程 vs SuperLink/SuperNode 分布式网络如何工作、如何通过flwr run与 Flower 配置文件选择 Runtime以及针对不同阶段研究原型 vs 生产部署的选型建议。一、Flower Runtime 概述同一份 App两种执行方式Flower App 由ServerApp与ClientApp两部分组成二者可以同时运行在Simulation Runtime或Deployment Runtime上。根据官方文档 Flower Runtime Comparison切换 Runtime 无需修改任何应用代码——只需要在执行flwr run命令时通过 Flower CLI 指定不同类型的federation联邦即可。这一点是 Flower 设计哲学的核心研究人员先在本地以仿真方式快速迭代算法验证通过后原封不动地将同一套代码部署到真实设备集群上。两种 Runtime 的执行方式存在显著差异下表继承自原文档概括了在 Flower federation 中以 Simulation Runtime 与 Deployment Runtime 执行同一 Flower App 时的关键特征对比维度Simulation RuntimeDeployment Runtime生命周期阶段适合快速原型验证、算法验证、研究、调试与实验将验证过的用例部署到生产环境、真实世界的隐私保护应用环境本地或远程、单节点或多节点、受控环境分布式、远程数据模拟数据分区、公开或私有数据集、或人工生成数据——与 Flower Datasets 天然契合真实的客户端侧数据位于本地数据库或文件系统中后端使用 Ray 协调的多个 Python 进程/worker多个独立进程或子进程与 SuperLink 和 SuperNodes 协同运行执行模式多进程执行每个进程模拟一个不同的客户端跨物理机器/设备或计算环境的网络并行执行模式通信内存内通信in-memoryRuntime API 使用 HTTPFleet API 使用 gRPC二者均支持 TLS服务端基础设施标准本地 CLI 工作流中flwr run将 run 提交给受管理的本地 SuperLink由其协调仿真 Runtime 和充当模拟 SuperNode的 worker仿真 Runtime 本身也可以在有/无 SuperLink 的情况下启动SuperLink 等待 SuperNodes 连接用户通过 Flower CLI 与 SuperLink 交互服务端 App 执行ServerApp进程在受控环境中初始化并通过内存与 worker 通信ServerApp进程或子进程独立于 SuperLink 运行通过 HTTP 经 Runtime API 与 SuperLink 通信客户端基础设施无需用户管理的客户端基础设施本地 CLI 工作流中受管理的本地 SuperLink 与仿真 Runtime 自包含SuperNodes 通过启用 TLS 的 gRPCFleet API连接 SuperLink可启用节点认证客户端 App 执行每个进程按需执行一个ClientApp可通过多次实例化同一ClientApp模拟大量客户端ClientApp是无状态的以ClientApp进程或子进程初始化独立于 SuperNode 运行通过 HTTP 经 Runtime API 与 SuperNode 通信ClientApp是无状态的以下各节将逐一深入解读这张表中的每个维度。二、核心差异逐维度解析2.1 生命周期阶段与环境从快速迭代到生产部署两种 Runtime 对应 FL 项目的不同生命周期阶段Simulation Runtime定位于开发期快速原型验证、算法验证、研究、调试与实验。其环境为本地或远程、单节点或多节点的受控环境研究者无需管理真实设备群即可在大型客户端队列上运行工作负载。Deployment Runtime定位于生产期将验证过的用例部署为生产环境中的真实隐私保护应用。其环境是分布式的、远程的——SuperLink、SuperNode 与开发机可以分处不同服务器正如 how-to-run-flower-with-deployment-engine 中所说明的真实部署中通常将 SuperLink 与 SuperNodes 运行在与开发 Flower App即执行flwr new与flwr run的机器不同的机器/服务器上。2.2 数据模拟分区与真实客户端数据仿真场景使用模拟数据分区——公开或私有数据集、或人工生成的数据与 Flower Datasets 天然契合。研究者通过划分数据集来模拟不同客户端的数据分布IID 或 Non-IID。部署场景的数据是真实客户端侧数据驻留在客户端本地的数据库或文件系统中永远不会离开客户端设备——这正是联邦学习隐私保护的根基。2.3 后端与执行模式Ray 多进程 vs SuperNode 网络Simulation Runtime 的后端是 Ray。根据 how-to-run-simulations 文档与源码默认后端为RayBackend它使用开源分布式计算框架 Ray 调度、启动并管理ClientApp实例每个后端 worker 是一个 Ray ActorClientAppActor能够在拿到Context与Message后派生出一个ClientApp。执行模式为多进程每个进程模拟一个不同的客户端通过多次实例化同一ClientApp即可模拟成百上千的客户端。Deployment Runtime 的后端是 Flower 自身的分布式基础设施多个独立进程或子进程与 SuperLink、SuperNodes 协同运行。执行模式为跨物理机器/设备的网络并行执行——每个真实设备运行一个 SuperNodeSuperNode 在收到任务时按需启动ClientApp。2.4 通信机制内存通信 vs HTTP/gRPCSimulation Runtime 采用内存内通信in-memory。在本地 CLI 工作流中ServerApp进程与模拟 worker 之间的消息传递发生在同一台机器的内存中无需网络序列化与传输因此延迟极低、迭代速度快。这一机制在源码中有直接体现仿真路径使用 SimulationIoConnection 建立 ServerApp 与 ClientApp 之间的内存连接。Deployment Runtime 采用两种网络协议Runtime API 使用 HTTP自 Flower 1.35 起ServerApp进程与 SuperLink、ClientApp进程与 SuperNode 之间的通信走 Runtime APIFleet API 使用 gRPCSuperNode 与 SuperLink 之间通过 gRPC 通信二者均支持 TLS 加密详细连接拓扑见 ref-flower-network-communication。2.5 服务端与客户端基础设施对比服务端侧仿真模式的标准本地 CLI 工作流中flwr run将 run 提交给受管理的本地 SuperLink即配置中address :local:的 profile由该 SuperLink 协调仿真 Runtime 与充当模拟 SuperNode的 worker。仿真 Runtime 本身也可脱离 SuperLink 独立启动如直接调用run_simulation等底层接口。部署模式中SuperLink 是长期运行的服务端进程等待 SuperNodes 连接用户通过 Flower CLI 与 SuperLink 交互提交 run、查看状态、拉取日志。客户端侧仿真模式不需要任何用户管理的客户端基础设施——本地 CLI 工作流中受管理的本地 SuperLink 与仿真 Runtime 完全自包含。部署模式中SuperNode 是长期运行的客户端守护进程通过启用 TLS 的 gRPCFleet API连接 SuperLink且可以启用节点认证Node authentication进一步加固生产环境安全性。App 执行侧两种 Runtime 下ClientApp都是**无状态stateless**的按需实例化、执行完即销毁。若需保存跨轮状态如内部变量、模型中间结果官方指南 how-to-design-stateful-clients 建议将状态保存到Context对象中。差异在于仿真中ClientApp在受控环境内由 worker 进程执行部署中ClientApp以独立进程/子进程形式运行独立于 SuperNode通过 HTTP Runtime API 通信。三、如何切换 Runtimefederation 配置与flwr run切换 Runtime 的核心机制是Flower 配置文件Flower Configuration中定义的 SuperLink 连接profile。3.1 本地仿真默认行为Flower 默认的本地 profile 使用address :local:。此时执行flwr run .flwr run会把 run 提交给受管理的本地 SuperLink通过 Control APIFlower 在需要时自动启动本地 SuperLink使其在后台保持运行并复用于flwr list、flwr log、flwr stop等命令。这正是Simulation Runtime 的标准工作流参见 how-to-run-flower-locally。提示flwr run默认即使用 Simulation Runtime因此无需任何额外配置即可运行仿真。这也是新手入门如flwr new flwrlabs/quickstart-pytorch生成的 app最直接的体验路径。3.2 切换到部署 Runtime要将同一个 app 切换到 Deployment Runtime需要向flwr run指明一个命名 SuperLink 连接。步骤如下通过flwr config list查看现有 SuperLink 连接与配置文件路径flwr config list在config.toml中追加一个新的 SuperLink 连接节名不能包含点号[superlink.local-deployment] address 127.0.0.1:8000 insecure true以命名连接运行 appflwr run . local-deployment --stream--stream让 CLI 流式展示ServerApp日志以跟踪 run 执行进度。上述操作均出自 how-to-run-flower-with-deployment-engine。3.3 部署 Runtime 的完整工作流以一个 SuperLink 两个 SuperNode 的最小联邦为例启动 SuperLink终端 1flower-superlink --insecure--insecure表示以非加密模式运行仅限本地测试真实部署必须配置 TLS见 how-to-enable-tls-connections。启动两个 SuperNode终端 2、终端 3flower-supernode \ --insecure \ --superlink 127.0.0.1:9092 \ --host 127.0.0.1 \ --port 9094 \ --node-config partition-id0 num-partitions2flower-supernode \ --insecure \ --superlink 127.0.0.1:9092 \ --host 127.0.0.1 \ --port 9095 \ --node-config partition-id1 num-partitions2参数含义--superlink 127.0.0.1:9092连接 SuperLink 的 Fleet API 地址跨机器时替换为公网 IP--host/--portSuperNode 监听 Runtime API 请求的地址与端口同机多节点需用不同端口--node-config传给ClientApp的键值对如分区 ID同一机器不同节点使用不同partition-id即可让各节点使用不同数据分区。随后在任意终端执行flwr run . local-deployment --stream即可将 run 提交到该联邦。结束时可对各终端CtrlC清理进程。四、Simulation Runtime 深度解析基于 Ray 的资源感知多进程仿真4.1 架构Backend 抽象与 RayBackend 实现Simulation Runtime 将派生与管理 ClientApp的职责委托给Backend。源码中 backend.py 定义了Backend抽象基类ABC其核心接口包括build(app_fn)构建后端使 worker 就绪可接受任务num_workers后端并发 worker 数量即可并发处理的 Message 数is_worker_idle()是否有空闲 worker 可运行 ClientAppprocess_message(message, context)将任务提交给后端terminate()终止后端。默认实现为 RayBackend其职责包括初始化 Rayray.init默认关闭 Dashboard、校验客户端资源、创建BasicActorPoolActor 池并调度ClientAppActor执行任务。从源码可见其默认资源分配raybackend.py 中_validate_client_resources当配置中未指定client_resources时默认每个客户端分配{num_cpus: 2, num_gpus: 0.0}——即默认模拟两个 SuperNode、每个 backend worker 分配 2 个 CPU 核心。这印证了文档中默认模拟两个 SuperNode 的队列、每个 worker 分配两个 CPU 核的描述。4.2 执行特性资源感知、批量化、自管理、瞬时性文档 how-to-run-simulations 将 Simulation Runtime 的 ClientApp 执行归纳为四个特性Resource-aware资源感知每个 backend worker 被分配系统计算与内存的一部分可在仿真开始时定义从而控制仿真并行度。Batchable可批量化当待执行 ClientApp 数量超过 backend worker 数时任务进入队列资源释放即执行通常以 N 为一批N worker 数。Self-managed自管理用户无需手动启动 ClientAppSimulation Runtime 全权编排。Ephemeral瞬时性ClientApp 仅在应用需要时如app.train()被物化执行完即销毁并释放资源。4.3 资源定制永久配置与按次覆盖方式一永久设置默认仿真配置flwr federation simulation-config命令CLI 注册见 cli/app.py可永久修改本地 SuperLink 的默认仿真配置。例如设置 100 个 SuperNode、每个 ClientApp 分配 4 CPU 与 25% GPUflwr federation simulation-config \ --num-supernodes 100 \ --client-resources-num-cpus 4 \ --client-resources-num-gpus 0.25方式二按次覆盖通过flwr run的--federation-config参数以单字符串形式按次覆盖语法与上一条命令一致但省略--前缀flwr run . --federation-confignum-supernodes256 client-resources-num-cpus14.4 并行度计算资源与并行 ClientApp 数量的关系假设每个 ClientApp 需要num_cpus个 CPU 与num_gpus比例的 GPU系统拥有SYS_CPUS个 CPU 与SYS_GPUS个 GPU则最大并行 ClientApp 数 N 满足N min( floor(SYS_CPUS / num_cpus), floor(SYS_GPUS / num_gpus) )文档中的具体示例10 CPU 1 GPU每个 ClientApp 需 1 CPU 25% GPU最多 4 个 ClientApp 并行受 VRAM 限制10 CPU 2 GPU最多 8 个并行VRAM 受限6 CPU 4 GPU最多 6 个并行CPU 受限10 CPU 0 GPU连单个 ClientApp 的资源都无法满足仿真无法启动。注意num_cpus大于等于 1 的整数与num_gpus非负实数按单个 ClientApp 设置。若想让每个 ClientApp 独占一块 GPU设num_gpus1.0若需要两块完整 GPU设num_gpus2。同时要理解资源分配是软约束——只用于控制并行度并不真正限制 ClientApp 实际使用的算力/显存若实际显存超出设定可能导致其他并发实例 OOM 崩溃。4.5 限制仿真占用的系统资源默认情况下 Simulation Runtime 可使用全部系统资源所有 CPU、所有 GPU。如需限制可通过init-args配置 Ray 初始化参数flwr federation simulation-config --init-args-num-cpus 1 --init-args-num-gpus 0上述配置将 Backend 初始化为仅 1 个 CPU、0 GPU即使系统有更多资源也不会被用于仿真最终同一时刻只运行一个 ClientApp。为获得最高性能官方建议不要设置--init-args-{...}参数。4.6 多节点仿真突破单机限制Simulation Runtime 支持跨多个计算节点运行基于默认的 RayBackend。步骤所有节点具备相同的 Python 环境、代码副本与数据集副本若使用 Flower Datasets 分区需保证第 i 个分区在所有节点完全一致在头节点执行ray start --head输出会给出其他节点接入的命令在从节点执行类似ray start --address192.168.1.132:6379的命令接入在头节点正常执行flwr run。若希望限制某节点提供给仿真的资源可在ray start后追加--num-cpusNUM_CPUS与--num-gpusNUM_GPUS。仿真结束后在各节点执行ray stop拆除集群。五、Deployment Runtime 深度解析SuperLink、SuperNode 与三大 API5.1 组件架构根据 explanation-flower-architectureFlower 将服务端与客户端各拆分为长期运行的网络进程 短期运行的任务进程两部分服务端SuperLink长期运行转发任务指令、回收任务结果SuperExec长期运行按需调度、启动、管理 ServerApp 进程ServerApp短期运行包含项目特定的服务端逻辑客户端选择、配置、聚合。客户端SuperNode长期运行连接 SuperLink、请求并执行任务、返回结果SuperExec长期运行按需调度 ClientApp 进程ClientApp短期运行包含本地训练、评估等客户端逻辑。SuperExec默认由 SuperLink/SuperNode 自动启动subprocess 隔离模式在 process 隔离模式下SuperExec 作为外部独立进程运行如独立 Docker 容器便于依赖隔离。5.2 三种网络 API 与默认端口部署模式下存在三种核心 API见 ref-flower-network-communication组件默认端口API用途SuperLink8000Runtime APISuperExec 与 ServerApp 进程使用SuperLink9092Fleet APISuperNodes 使用gRPCSuperLink8000Control API用户通过 Flower CLI 与之交互SuperNode9094Runtime APISuperExec 与 ClientApp 进程使用通信模式要点CLI → SuperLinkControl APIflwrCLI 是用户与已部署联邦交互的唯一入口无法直接与 SuperNodes 交互CLI 是 HTTP 客户端SuperLink 是 HTTP 服务器。SuperNode → SuperLinkFleet APISuperNode 是 gRPC 客户端SuperLink 是 gRPC 服务器SuperNode 只需出站连接即可接入。ServerApp/ClientApp → Runtime APIApp 进程通过 HTTP 拉取/推送 Message并拉取 FABFlower App Bundle与回传 Context。TLS 方面Fleet API 与 Control API 应始终使用 TLS本地测试可用--insecureRuntime API 链接可通过 SuperLink/SuperNode 的--ssl-certfile、--ssl-keyfile、--ssl-ca-certfile加密App 进程用--root-certificates校验服务端证书。多节点时各进程组SuperLink SuperExec ServerApp、SuperNode SuperExec ClientApp必须各自位于可信网络内。5.3 多租户Multi-run能力部署模式下同一联邦一个长期 SuperLink 多个长期 SuperNode可同时承载多个 Flower App 项目Multi-run/多租户。不同 run 可以选用不同模型、超参、聚合策略甚至不同 ML 框架PyTorch、TensorFlow 等且一个 SuperNode 只有在被某次 run 选中时才会运行对应的 ClientApp——不同项目可在不同客户端子集上运行。六、选型建议与 FAQ 要点6.1 何时选择哪种 Runtime选择 Simulation Runtime处于原型开发、算法验证、研究实验、调试阶段没有现成设备群希望在开发机上以尽量快的速度跑通大规模客户端队列需要模拟不同数据异构性、客户端可用性、隐私预算等场景追求低延迟内存通信与零网络配置。选择 Deployment Runtime算法已通过验证需要迁移到生产环境客户端数据真实分布在设备/数据库/文件系统上需要真实隐私保护需要跨地域、跨机器的真实网络并行需要多租户共享同一联邦基础设施需要节点认证与 TLS 加固。两种 Runtime 共享同一套ClientApp/ServerApp代码因此可以从仿真平滑演进到部署先本地仿真验证再以命名 SuperLink 连接方式直接运行同一 app。6.2 常见问题要点来自仿真文档 FAQClientApp 可以有状态吗可以将变量/参数/结果保存到Context对象的state属性参考 how-to-design-stateful-clients。一台机器能跑多个仿真吗可以但各仿真互不知晓对方资源占用使用 GPU 时建议为每个仿真设置不同的CUDA_VISIBLE_DEVICES。CPU/GPU 资源设置会限制实际使用吗不会资源仅用于控制并发 worker 数量需自行确保 ClientApp 有足够资源执行负载。ClientApp 在 GPU 上 OOM 怎么办将num_gpus调高如先设num_gpus1独占 GPU用nvidia-smi观察实际 VRAM 占用后计算合理值TensorFlow 用户建议设置TF_FORCE_GPU_ALLOW_GROWTH1。如何确定合适的 num_cpus/num_gpus先用偏大的值如num_cpus8、num_gpus1跑几个 round用htop/nvidia-smi监控利用率再逐步下调以提升并行度。可以给不同 ClientApp 分配不同资源吗不可以所有 ClientApp 共享同一num_cpus/num_gpus配置应以内存占用最大的 ClientApp 为准。ServerApp 的 GPU 使用会被计算吗不会Simulation Runtime 只管理 ClientApp 的资源ServerApp 的算力需求需自行纳入考量。能否指定 ClientApp 运行在特定资源上目前截至 flwr 1.13.0资源放置由 RayBackend 统一管理不可自定义实现自定义 Backend 是达成资源放置的途径。七、结语Simulation Runtime 与 Deployment Runtime 是 Flower 面向联邦学习全生命周期的两条执行路径前者以 Ray 为后端提供资源感知、可批量化、自管理、瞬时性的内存级多进程仿真让算法研究在开发机上以极低成本快速迭代后者以 SuperLink、SuperNode、SuperExec 为骨架提供基于 HTTP/gRPC 的真实网络部署、TLS 安全与多租户能力。得益于二者共用同一套ClientApp/ServerApp抽象开发者仅需修改federation配置即可在两种 Runtime 间无缝切换。更多细节可继续阅读仓库内的 how-to-run-simulations、how-to-run-flower-with-deployment-engine、ref-flower-network-communication 与 explanation-flower-architecture以及仿真后端核心实现 raybackend.py 与 backend.py。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flower Runtime 对比指南：Simulation Runtime 与 Deployment Runtime 的架构差异、切换方式与选型实践
Flower Runtime 对比指南Simulation Runtime 与 Deployment Runtime 的架构差异、切换方式与选型实践【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本篇技术指南基于 FlowerFriendly Federated AI Framework官方文档中的 Flower Runtime Comparison 参考页展开系统对比 Flower 两种 Runtime——Simulation Runtime仿真 Runtime与Deployment Runtime部署 Runtime——在生命周期、环境、数据、后端、执行模式、通信、服务端与客户端基础设施等维度的关键差异。读完本文你将掌握同一份 Flower App 如何在两种 Runtime 之间无缝切换、各自底层架构Ray 多进程 vs SuperLink/SuperNode 分布式网络如何工作、如何通过flwr run与 Flower 配置文件选择 Runtime以及针对不同阶段研究原型 vs 生产部署的选型建议。一、Flower Runtime 概述同一份 App两种执行方式Flower App 由ServerApp与ClientApp两部分组成二者可以同时运行在Simulation Runtime或Deployment Runtime上。根据官方文档 Flower Runtime Comparison切换 Runtime 无需修改任何应用代码——只需要在执行flwr run命令时通过 Flower CLI 指定不同类型的federation联邦即可。这一点是 Flower 设计哲学的核心研究人员先在本地以仿真方式快速迭代算法验证通过后原封不动地将同一套代码部署到真实设备集群上。两种 Runtime 的执行方式存在显著差异下表继承自原文档概括了在 Flower federation 中以 Simulation Runtime 与 Deployment Runtime 执行同一 Flower App 时的关键特征对比维度Simulation RuntimeDeployment Runtime生命周期阶段适合快速原型验证、算法验证、研究、调试与实验将验证过的用例部署到生产环境、真实世界的隐私保护应用环境本地或远程、单节点或多节点、受控环境分布式、远程数据模拟数据分区、公开或私有数据集、或人工生成数据——与 Flower Datasets 天然契合真实的客户端侧数据位于本地数据库或文件系统中后端使用 Ray 协调的多个 Python 进程/worker多个独立进程或子进程与 SuperLink 和 SuperNodes 协同运行执行模式多进程执行每个进程模拟一个不同的客户端跨物理机器/设备或计算环境的网络并行执行模式通信内存内通信in-memoryRuntime API 使用 HTTPFleet API 使用 gRPC二者均支持 TLS服务端基础设施标准本地 CLI 工作流中flwr run将 run 提交给受管理的本地 SuperLink由其协调仿真 Runtime 和充当模拟 SuperNode的 worker仿真 Runtime 本身也可以在有/无 SuperLink 的情况下启动SuperLink 等待 SuperNodes 连接用户通过 Flower CLI 与 SuperLink 交互服务端 App 执行ServerApp进程在受控环境中初始化并通过内存与 worker 通信ServerApp进程或子进程独立于 SuperLink 运行通过 HTTP 经 Runtime API 与 SuperLink 通信客户端基础设施无需用户管理的客户端基础设施本地 CLI 工作流中受管理的本地 SuperLink 与仿真 Runtime 自包含SuperNodes 通过启用 TLS 的 gRPCFleet API连接 SuperLink可启用节点认证客户端 App 执行每个进程按需执行一个ClientApp可通过多次实例化同一ClientApp模拟大量客户端ClientApp是无状态的以ClientApp进程或子进程初始化独立于 SuperNode 运行通过 HTTP 经 Runtime API 与 SuperNode 通信ClientApp是无状态的以下各节将逐一深入解读这张表中的每个维度。二、核心差异逐维度解析2.1 生命周期阶段与环境从快速迭代到生产部署两种 Runtime 对应 FL 项目的不同生命周期阶段Simulation Runtime定位于开发期快速原型验证、算法验证、研究、调试与实验。其环境为本地或远程、单节点或多节点的受控环境研究者无需管理真实设备群即可在大型客户端队列上运行工作负载。Deployment Runtime定位于生产期将验证过的用例部署为生产环境中的真实隐私保护应用。其环境是分布式的、远程的——SuperLink、SuperNode 与开发机可以分处不同服务器正如 how-to-run-flower-with-deployment-engine 中所说明的真实部署中通常将 SuperLink 与 SuperNodes 运行在与开发 Flower App即执行flwr new与flwr run的机器不同的机器/服务器上。2.2 数据模拟分区与真实客户端数据仿真场景使用模拟数据分区——公开或私有数据集、或人工生成的数据与 Flower Datasets 天然契合。研究者通过划分数据集来模拟不同客户端的数据分布IID 或 Non-IID。部署场景的数据是真实客户端侧数据驻留在客户端本地的数据库或文件系统中永远不会离开客户端设备——这正是联邦学习隐私保护的根基。2.3 后端与执行模式Ray 多进程 vs SuperNode 网络Simulation Runtime 的后端是 Ray。根据 how-to-run-simulations 文档与源码默认后端为RayBackend它使用开源分布式计算框架 Ray 调度、启动并管理ClientApp实例每个后端 worker 是一个 Ray ActorClientAppActor能够在拿到Context与Message后派生出一个ClientApp。执行模式为多进程每个进程模拟一个不同的客户端通过多次实例化同一ClientApp即可模拟成百上千的客户端。Deployment Runtime 的后端是 Flower 自身的分布式基础设施多个独立进程或子进程与 SuperLink、SuperNodes 协同运行。执行模式为跨物理机器/设备的网络并行执行——每个真实设备运行一个 SuperNodeSuperNode 在收到任务时按需启动ClientApp。2.4 通信机制内存通信 vs HTTP/gRPCSimulation Runtime 采用内存内通信in-memory。在本地 CLI 工作流中ServerApp进程与模拟 worker 之间的消息传递发生在同一台机器的内存中无需网络序列化与传输因此延迟极低、迭代速度快。这一机制在源码中有直接体现仿真路径使用 SimulationIoConnection 建立 ServerApp 与 ClientApp 之间的内存连接。Deployment Runtime 采用两种网络协议Runtime API 使用 HTTP自 Flower 1.35 起ServerApp进程与 SuperLink、ClientApp进程与 SuperNode 之间的通信走 Runtime APIFleet API 使用 gRPCSuperNode 与 SuperLink 之间通过 gRPC 通信二者均支持 TLS 加密详细连接拓扑见 ref-flower-network-communication。2.5 服务端与客户端基础设施对比服务端侧仿真模式的标准本地 CLI 工作流中flwr run将 run 提交给受管理的本地 SuperLink即配置中address :local:的 profile由该 SuperLink 协调仿真 Runtime 与充当模拟 SuperNode的 worker。仿真 Runtime 本身也可脱离 SuperLink 独立启动如直接调用run_simulation等底层接口。部署模式中SuperLink 是长期运行的服务端进程等待 SuperNodes 连接用户通过 Flower CLI 与 SuperLink 交互提交 run、查看状态、拉取日志。客户端侧仿真模式不需要任何用户管理的客户端基础设施——本地 CLI 工作流中受管理的本地 SuperLink 与仿真 Runtime 完全自包含。部署模式中SuperNode 是长期运行的客户端守护进程通过启用 TLS 的 gRPCFleet API连接 SuperLink且可以启用节点认证Node authentication进一步加固生产环境安全性。App 执行侧两种 Runtime 下ClientApp都是**无状态stateless**的按需实例化、执行完即销毁。若需保存跨轮状态如内部变量、模型中间结果官方指南 how-to-design-stateful-clients 建议将状态保存到Context对象中。差异在于仿真中ClientApp在受控环境内由 worker 进程执行部署中ClientApp以独立进程/子进程形式运行独立于 SuperNode通过 HTTP Runtime API 通信。三、如何切换 Runtimefederation 配置与flwr run切换 Runtime 的核心机制是Flower 配置文件Flower Configuration中定义的 SuperLink 连接profile。3.1 本地仿真默认行为Flower 默认的本地 profile 使用address :local:。此时执行flwr run .flwr run会把 run 提交给受管理的本地 SuperLink通过 Control APIFlower 在需要时自动启动本地 SuperLink使其在后台保持运行并复用于flwr list、flwr log、flwr stop等命令。这正是Simulation Runtime 的标准工作流参见 how-to-run-flower-locally。提示flwr run默认即使用 Simulation Runtime因此无需任何额外配置即可运行仿真。这也是新手入门如flwr new flwrlabs/quickstart-pytorch生成的 app最直接的体验路径。3.2 切换到部署 Runtime要将同一个 app 切换到 Deployment Runtime需要向flwr run指明一个命名 SuperLink 连接。步骤如下通过flwr config list查看现有 SuperLink 连接与配置文件路径flwr config list在config.toml中追加一个新的 SuperLink 连接节名不能包含点号[superlink.local-deployment] address 127.0.0.1:8000 insecure true以命名连接运行 appflwr run . local-deployment --stream--stream让 CLI 流式展示ServerApp日志以跟踪 run 执行进度。上述操作均出自 how-to-run-flower-with-deployment-engine。3.3 部署 Runtime 的完整工作流以一个 SuperLink 两个 SuperNode 的最小联邦为例启动 SuperLink终端 1flower-superlink --insecure--insecure表示以非加密模式运行仅限本地测试真实部署必须配置 TLS见 how-to-enable-tls-connections。启动两个 SuperNode终端 2、终端 3flower-supernode \ --insecure \ --superlink 127.0.0.1:9092 \ --host 127.0.0.1 \ --port 9094 \ --node-config partition-id0 num-partitions2flower-supernode \ --insecure \ --superlink 127.0.0.1:9092 \ --host 127.0.0.1 \ --port 9095 \ --node-config partition-id1 num-partitions2参数含义--superlink 127.0.0.1:9092连接 SuperLink 的 Fleet API 地址跨机器时替换为公网 IP--host/--portSuperNode 监听 Runtime API 请求的地址与端口同机多节点需用不同端口--node-config传给ClientApp的键值对如分区 ID同一机器不同节点使用不同partition-id即可让各节点使用不同数据分区。随后在任意终端执行flwr run . local-deployment --stream即可将 run 提交到该联邦。结束时可对各终端CtrlC清理进程。四、Simulation Runtime 深度解析基于 Ray 的资源感知多进程仿真4.1 架构Backend 抽象与 RayBackend 实现Simulation Runtime 将派生与管理 ClientApp的职责委托给Backend。源码中 backend.py 定义了Backend抽象基类ABC其核心接口包括build(app_fn)构建后端使 worker 就绪可接受任务num_workers后端并发 worker 数量即可并发处理的 Message 数is_worker_idle()是否有空闲 worker 可运行 ClientAppprocess_message(message, context)将任务提交给后端terminate()终止后端。默认实现为 RayBackend其职责包括初始化 Rayray.init默认关闭 Dashboard、校验客户端资源、创建BasicActorPoolActor 池并调度ClientAppActor执行任务。从源码可见其默认资源分配raybackend.py 中_validate_client_resources当配置中未指定client_resources时默认每个客户端分配{num_cpus: 2, num_gpus: 0.0}——即默认模拟两个 SuperNode、每个 backend worker 分配 2 个 CPU 核心。这印证了文档中默认模拟两个 SuperNode 的队列、每个 worker 分配两个 CPU 核的描述。4.2 执行特性资源感知、批量化、自管理、瞬时性文档 how-to-run-simulations 将 Simulation Runtime 的 ClientApp 执行归纳为四个特性Resource-aware资源感知每个 backend worker 被分配系统计算与内存的一部分可在仿真开始时定义从而控制仿真并行度。Batchable可批量化当待执行 ClientApp 数量超过 backend worker 数时任务进入队列资源释放即执行通常以 N 为一批N worker 数。Self-managed自管理用户无需手动启动 ClientAppSimulation Runtime 全权编排。Ephemeral瞬时性ClientApp 仅在应用需要时如app.train()被物化执行完即销毁并释放资源。4.3 资源定制永久配置与按次覆盖方式一永久设置默认仿真配置flwr federation simulation-config命令CLI 注册见 cli/app.py可永久修改本地 SuperLink 的默认仿真配置。例如设置 100 个 SuperNode、每个 ClientApp 分配 4 CPU 与 25% GPUflwr federation simulation-config \ --num-supernodes 100 \ --client-resources-num-cpus 4 \ --client-resources-num-gpus 0.25方式二按次覆盖通过flwr run的--federation-config参数以单字符串形式按次覆盖语法与上一条命令一致但省略--前缀flwr run . --federation-confignum-supernodes256 client-resources-num-cpus14.4 并行度计算资源与并行 ClientApp 数量的关系假设每个 ClientApp 需要num_cpus个 CPU 与num_gpus比例的 GPU系统拥有SYS_CPUS个 CPU 与SYS_GPUS个 GPU则最大并行 ClientApp 数 N 满足N min( floor(SYS_CPUS / num_cpus), floor(SYS_GPUS / num_gpus) )文档中的具体示例10 CPU 1 GPU每个 ClientApp 需 1 CPU 25% GPU最多 4 个 ClientApp 并行受 VRAM 限制10 CPU 2 GPU最多 8 个并行VRAM 受限6 CPU 4 GPU最多 6 个并行CPU 受限10 CPU 0 GPU连单个 ClientApp 的资源都无法满足仿真无法启动。注意num_cpus大于等于 1 的整数与num_gpus非负实数按单个 ClientApp 设置。若想让每个 ClientApp 独占一块 GPU设num_gpus1.0若需要两块完整 GPU设num_gpus2。同时要理解资源分配是软约束——只用于控制并行度并不真正限制 ClientApp 实际使用的算力/显存若实际显存超出设定可能导致其他并发实例 OOM 崩溃。4.5 限制仿真占用的系统资源默认情况下 Simulation Runtime 可使用全部系统资源所有 CPU、所有 GPU。如需限制可通过init-args配置 Ray 初始化参数flwr federation simulation-config --init-args-num-cpus 1 --init-args-num-gpus 0上述配置将 Backend 初始化为仅 1 个 CPU、0 GPU即使系统有更多资源也不会被用于仿真最终同一时刻只运行一个 ClientApp。为获得最高性能官方建议不要设置--init-args-{...}参数。4.6 多节点仿真突破单机限制Simulation Runtime 支持跨多个计算节点运行基于默认的 RayBackend。步骤所有节点具备相同的 Python 环境、代码副本与数据集副本若使用 Flower Datasets 分区需保证第 i 个分区在所有节点完全一致在头节点执行ray start --head输出会给出其他节点接入的命令在从节点执行类似ray start --address192.168.1.132:6379的命令接入在头节点正常执行flwr run。若希望限制某节点提供给仿真的资源可在ray start后追加--num-cpusNUM_CPUS与--num-gpusNUM_GPUS。仿真结束后在各节点执行ray stop拆除集群。五、Deployment Runtime 深度解析SuperLink、SuperNode 与三大 API5.1 组件架构根据 explanation-flower-architectureFlower 将服务端与客户端各拆分为长期运行的网络进程 短期运行的任务进程两部分服务端SuperLink长期运行转发任务指令、回收任务结果SuperExec长期运行按需调度、启动、管理 ServerApp 进程ServerApp短期运行包含项目特定的服务端逻辑客户端选择、配置、聚合。客户端SuperNode长期运行连接 SuperLink、请求并执行任务、返回结果SuperExec长期运行按需调度 ClientApp 进程ClientApp短期运行包含本地训练、评估等客户端逻辑。SuperExec默认由 SuperLink/SuperNode 自动启动subprocess 隔离模式在 process 隔离模式下SuperExec 作为外部独立进程运行如独立 Docker 容器便于依赖隔离。5.2 三种网络 API 与默认端口部署模式下存在三种核心 API见 ref-flower-network-communication组件默认端口API用途SuperLink8000Runtime APISuperExec 与 ServerApp 进程使用SuperLink9092Fleet APISuperNodes 使用gRPCSuperLink8000Control API用户通过 Flower CLI 与之交互SuperNode9094Runtime APISuperExec 与 ClientApp 进程使用通信模式要点CLI → SuperLinkControl APIflwrCLI 是用户与已部署联邦交互的唯一入口无法直接与 SuperNodes 交互CLI 是 HTTP 客户端SuperLink 是 HTTP 服务器。SuperNode → SuperLinkFleet APISuperNode 是 gRPC 客户端SuperLink 是 gRPC 服务器SuperNode 只需出站连接即可接入。ServerApp/ClientApp → Runtime APIApp 进程通过 HTTP 拉取/推送 Message并拉取 FABFlower App Bundle与回传 Context。TLS 方面Fleet API 与 Control API 应始终使用 TLS本地测试可用--insecureRuntime API 链接可通过 SuperLink/SuperNode 的--ssl-certfile、--ssl-keyfile、--ssl-ca-certfile加密App 进程用--root-certificates校验服务端证书。多节点时各进程组SuperLink SuperExec ServerApp、SuperNode SuperExec ClientApp必须各自位于可信网络内。5.3 多租户Multi-run能力部署模式下同一联邦一个长期 SuperLink 多个长期 SuperNode可同时承载多个 Flower App 项目Multi-run/多租户。不同 run 可以选用不同模型、超参、聚合策略甚至不同 ML 框架PyTorch、TensorFlow 等且一个 SuperNode 只有在被某次 run 选中时才会运行对应的 ClientApp——不同项目可在不同客户端子集上运行。六、选型建议与 FAQ 要点6.1 何时选择哪种 Runtime选择 Simulation Runtime处于原型开发、算法验证、研究实验、调试阶段没有现成设备群希望在开发机上以尽量快的速度跑通大规模客户端队列需要模拟不同数据异构性、客户端可用性、隐私预算等场景追求低延迟内存通信与零网络配置。选择 Deployment Runtime算法已通过验证需要迁移到生产环境客户端数据真实分布在设备/数据库/文件系统上需要真实隐私保护需要跨地域、跨机器的真实网络并行需要多租户共享同一联邦基础设施需要节点认证与 TLS 加固。两种 Runtime 共享同一套ClientApp/ServerApp代码因此可以从仿真平滑演进到部署先本地仿真验证再以命名 SuperLink 连接方式直接运行同一 app。6.2 常见问题要点来自仿真文档 FAQClientApp 可以有状态吗可以将变量/参数/结果保存到Context对象的state属性参考 how-to-design-stateful-clients。一台机器能跑多个仿真吗可以但各仿真互不知晓对方资源占用使用 GPU 时建议为每个仿真设置不同的CUDA_VISIBLE_DEVICES。CPU/GPU 资源设置会限制实际使用吗不会资源仅用于控制并发 worker 数量需自行确保 ClientApp 有足够资源执行负载。ClientApp 在 GPU 上 OOM 怎么办将num_gpus调高如先设num_gpus1独占 GPU用nvidia-smi观察实际 VRAM 占用后计算合理值TensorFlow 用户建议设置TF_FORCE_GPU_ALLOW_GROWTH1。如何确定合适的 num_cpus/num_gpus先用偏大的值如num_cpus8、num_gpus1跑几个 round用htop/nvidia-smi监控利用率再逐步下调以提升并行度。可以给不同 ClientApp 分配不同资源吗不可以所有 ClientApp 共享同一num_cpus/num_gpus配置应以内存占用最大的 ClientApp 为准。ServerApp 的 GPU 使用会被计算吗不会Simulation Runtime 只管理 ClientApp 的资源ServerApp 的算力需求需自行纳入考量。能否指定 ClientApp 运行在特定资源上目前截至 flwr 1.13.0资源放置由 RayBackend 统一管理不可自定义实现自定义 Backend 是达成资源放置的途径。七、结语Simulation Runtime 与 Deployment Runtime 是 Flower 面向联邦学习全生命周期的两条执行路径前者以 Ray 为后端提供资源感知、可批量化、自管理、瞬时性的内存级多进程仿真让算法研究在开发机上以极低成本快速迭代后者以 SuperLink、SuperNode、SuperExec 为骨架提供基于 HTTP/gRPC 的真实网络部署、TLS 安全与多租户能力。得益于二者共用同一套ClientApp/ServerApp抽象开发者仅需修改federation配置即可在两种 Runtime 间无缝切换。更多细节可继续阅读仓库内的 how-to-run-simulations、how-to-run-flower-with-deployment-engine、ref-flower-network-communication 与 explanation-flower-architecture以及仿真后端核心实现 raybackend.py 与 backend.py。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考