企业官网建设流程全解析

Flower Runtime 对比指南：Simulation Runtime 与 Deployment Runtime 的架构差异、切换方式与选型实践

【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower

本篇技术指南基于 Flower（Friendly 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 时的关键特征对比：

以下各节将逐一深入解读这张表中的每个维度。

二、核心差异逐维度解析

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 Actor（ClientAppActor），能够在拿到Context与Message后派生出一个ClientApp。执行模式为多进程：每个进程模拟一个不同的客户端，通过多次实例化同一ClientApp即可模拟成百上千的客户端。
• Deployment Runtime 的后端是 Flower 自身的分布式基础设施：多个独立进程或子进程与 SuperLink、SuperNodes 协同运行。执行模式为跨物理机器/设备的网络并行执行——每个真实设备运行一个 SuperNode，SuperNode 在收到任务时按需启动ClientApp。

2.4 通信机制：内存通信 vs HTTP/gRPC

• Simulation Runtime 采用内存内通信（in-memory）。在本地 CLI 工作流中，ServerApp进程与模拟 worker 之间的消息传递发生在同一台机器的内存中，无需网络序列化与传输，因此延迟极低、迭代速度快。这一机制在源码中有直接体现：仿真路径使用 SimulationIoConnection 建立 ServerApp 与 ClientApp 之间的内存连接。
• Deployment Runtime 采用两种网络协议：
  • Runtime API 使用 HTTP（自 Flower 1.35 起）：ServerApp进程与 SuperLink、ClientApp进程与 SuperNode 之间的通信走 Runtime API；
  • Fleet API 使用 gRPC：SuperNode 与 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 的 gRPC（Fleet API）连接 SuperLink，且可以启用节点认证（Node authentication），进一步加固生产环境安全性。

App 执行侧：

• 两种 Runtime 下，ClientApp都是**无状态（stateless）**的，按需实例化、执行完即销毁。若需保存跨轮状态（如内部变量、模型中间结果），官方指南 how-to-design-stateful-clients 建议将状态保存到Context对象中。
• 差异在于：仿真中ClientApp在受控环境内由 worker 进程执行；部署中ClientApp以独立进程/子进程形式运行，独立于 SuperNode，通过 HTTP Runtime API 通信。

三、如何切换 Runtime：federation 配置与flwr run

切换 Runtime 的核心机制是Flower 配置文件（Flower Configuration）中定义的 SuperLink 连接（profile）。

3.1 本地仿真（默认行为）

Flower 默认的本地 profile 使用address = ":local:"。此时执行：

flwr run .

flwr run会把 run 提交给受管理的本地 SuperLink（通过 Control API），Flower 在需要时自动启动本地 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 连接。步骤如下：

1. 通过flwr config list查看现有 SuperLink 连接与配置文件路径：

flwr config list

2. 在config.toml中追加一个新的 SuperLink 连接（节名不能包含点号）：

[superlink.local-deployment] address = "127.0.0.1:8000" insecure = true

3. 以命名连接运行 app：

flwr run . local-deployment --stream

--stream让 CLI 流式展示ServerApp日志以跟踪 run 执行进度。上述操作均出自 how-to-run-flower-with-deployment-engine。

3.3 部署 Runtime 的完整工作流

以一个 SuperLink + 两个 SuperNode 的最小联邦为例：

启动 SuperLink（终端 1）：

flower-superlink --insecure

--insecure表示以非加密模式运行（仅限本地测试；真实部署必须配置 TLS，见 how-to-enable-tls-connections）。

启动两个 SuperNode（终端 2、终端 3）：

flower-supernode \ --insecure \ --superlink 127.0.0.1:9092 \ --host 127.0.0.1 \ --port 9094 \ --node-config "partition-id=0 num-partitions=2"

flower-supernode \ --insecure \ --superlink 127.0.0.1:9092 \ --host 127.0.0.1 \ --port 9095 \ --node-config "partition-id=1 num-partitions=2"

参数含义：

• --superlink 127.0.0.1:9092：连接 SuperLink 的 Fleet API 地址（跨机器时替换为公网 IP）；
• --host/--port：SuperNode 监听 Runtime API 请求的地址与端口（同机多节点需用不同端口）；
• --node-config：传给ClientApp的键值对（如分区 ID），同一机器不同节点使用不同partition-id即可让各节点使用不同数据分区。

随后在任意终端执行flwr run . local-deployment --stream即可将 run 提交到该联邦。结束时可对各终端Ctrl+C清理进程。

四、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 可运行 ClientApp；
• process_message(message, context)：将任务提交给后端；
• terminate()：终止后端。

默认实现为 RayBackend，其职责包括：初始化 Ray（ray.init，默认关闭 Dashboard）、校验客户端资源、创建BasicActorPool（Actor 池）并调度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（自管理）：用户无需手动启动 ClientApp，Simulation Runtime 全权编排。
• Ephemeral（瞬时性）：ClientApp 仅在应用需要时（如@app.train()）被物化，执行完即销毁并释放资源。

4.3 资源定制：永久配置与按次覆盖

方式一：永久设置默认仿真配置

flwr federation simulation-config命令（CLI 注册见 cli/app.py）可永久修改本地 SuperLink 的默认仿真配置。例如设置 100 个 SuperNode、每个 ClientApp 分配 4 CPU 与 25% GPU：

flwr federation simulation-config \ --num-supernodes 100 \ --client-resources-num-cpus 4 \ --client-resources-num-gpus 0.25

方式二：按次覆盖

通过flwr run的--federation-config参数以单字符串形式按次覆盖，语法与上一条命令一致但省略--前缀：

flwr run . --federation-config="num-supernodes=256 client-resources-num-cpus=1"

4.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_gpus=1.0；若需要两块完整 GPU，设num_gpus=2。同时要理解，资源分配是软约束——只用于控制并行度，并不真正限制 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）。步骤：

1. 所有节点具备相同的 Python 环境、代码副本与数据集副本（若使用 Flower Datasets 分区，需保证第 i 个分区在所有节点完全一致）；
2. 在头节点执行ray start --head，输出会给出其他节点接入的命令；
3. 在从节点执行类似ray start --address='192.168.1.132:6379'的命令接入；
4. 在头节点正常执行flwr run。

若希望限制某节点提供给仿真的资源，可在ray start后追加--num-cpus=<NUM_CPUS>与--num-gpus=<NUM_GPUS>。仿真结束后在各节点执行ray stop拆除集群。

五、Deployment Runtime 深度解析：SuperLink、SuperNode 与三大 API

5.1 组件架构

根据 explanation-flower-architecture，Flower 将服务端与客户端各拆分为"长期运行的网络进程 + 短期运行的任务进程"两部分：

• 服务端：SuperLink（长期运行，转发任务指令、回收任务结果）+SuperExec（长期运行，按需调度、启动、管理 ServerApp 进程）+ServerApp（短期运行，包含项目特定的服务端逻辑：客户端选择、配置、聚合）。
• 客户端：SuperNode（长期运行，连接 SuperLink、请求并执行任务、返回结果）+SuperExec（长期运行，按需调度 ClientApp 进程）+ClientApp（短期运行，包含本地训练、评估等客户端逻辑）。

SuperExec默认由 SuperLink/SuperNode 自动启动（subprocess 隔离模式）；在 process 隔离模式下，SuperExec 作为外部独立进程运行（如独立 Docker 容器），便于依赖隔离。

5.2 三种网络 API 与默认端口

部署模式下存在三种核心 API（见 ref-flower-network-communication）：

通信模式要点：

• CLI → SuperLink（Control API）：flwrCLI 是用户与已部署联邦交互的唯一入口（无法直接与 SuperNodes 交互）；CLI 是 HTTP 客户端，SuperLink 是 HTTP 服务器。
• SuperNode → SuperLink（Fleet API）：SuperNode 是 gRPC 客户端，SuperLink 是 gRPC 服务器；SuperNode 只需出站连接即可接入。
• ServerApp/ClientApp → Runtime API：App 进程通过 HTTP 拉取/推送 Message，并拉取 FAB（Flower App Bundle）与回传 Context。

TLS 方面：Fleet API 与 Control API 应始终使用 TLS（本地测试可用--insecure）；Runtime 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 常见问题要点（来自仿真文档 FAQ）

• ClientApp 可以有状态吗？可以，将变量/参数/结果保存到Context对象的state属性，参考 how-to-design-stateful-clients。
• 一台机器能跑多个仿真吗？可以，但各仿真互不知晓对方资源占用；使用 GPU 时建议为每个仿真设置不同的CUDA_VISIBLE_DEVICES。
• CPU/GPU 资源设置会限制实际使用吗？不会，资源仅用于控制并发 worker 数量，需自行确保 ClientApp 有足够资源执行负载。
• ClientApp 在 GPU 上 OOM 怎么办？将num_gpus调高（如先设num_gpus=1独占 GPU），用nvidia-smi观察实际 VRAM 占用后计算合理值；TensorFlow 用户建议设置TF_FORCE_GPU_ALLOW_GROWTH="1"。
• 如何确定合适的 num_cpus/num_gpus？先用偏大的值（如num_cpus=8、num_gpus=1）跑几个 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