Flower v1.20.0 深度解读任意大模型透明传输、对象化消息系统与 SuperNode 架构重构【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本篇基于 Flower 框架 v1.20.0 官方发布说明framework/docs/source/changelog/v1.20.0.md系统梳理 2025-07-29 发布的这一版本中最重要的三项底层能力升级突破 gRPC 2GB 消息上限的大模型分块传输、SuperNode 与 ClientApp 之间的对象化消息体系重构、以及 SuperNode 全面转向NodeState状态管理的架构演进并结合当前仓库源码逐项印证其实现细节帮助使用者理解每个变更背后的原理与迁移要点。版本概览v1.20.0 由 11 位贡献者共同完成。发布说明将变更组织为三大主线特性、若干工程改进与一项不兼容变更可发送/接收任意大的模型如 LLM 权重彻底绕开 gRPC 单消息 2GB 上限SuperNode 与 ClientApp 之间实现对象化object-based消息通信取代旧的消息耦合设计SuperNode 重构为完全依赖NodeState管理信息为未来并发运行多个 ClientApp 铺路附带 FAB 文件 10MB 大小限制、Windows 路径修复、CatBoost 联邦学习示例、Helm 部署文档、用户认证与审计日志文档、gRPC 健康检查默认启用等一系列改进一项不兼容变更已弃用的start_clientAPI 移除了非grpc-bidi传输支持。下文结合仓库源码逐项展开。1. 任意大模型的透明传输自动分块突破 2GB 上限发布说明的核心亮点是Flower 1.20 可以发送和接收远超 gRPC 2GB 单消息限制的任意大模型例如 LLM 权重方式是对发送与接收的消息进行分块chunking且这一过程对用户完全透明——应用开发者无需做任何改动。仓库源码可以印证这一机制的三个关键环节1.1 分块大小常量framework/py/flwr/common/constant.py 定义了对象分块传输的核心参数# Constants for Inflatable FLWR_PRIVATE_MAX_ARRAY_CHUNK_SIZE int( os.getenv(FLWR_PRIVATE_MAX_ARRAY_CHUNK_SIZE, 5242880) ) # 5 MB即单个数组分块默认上限为 5MB5242880 字节并可通过环境变量FLWR_PRIVATE_MAX_ARRAY_CHUNK_SIZE覆盖。5MB 远小于 gRPC 的 2GB 阈值因此任意大的张量/权重数组都会被切分为若干小分块独立传输从根源上规避了单消息体积限制。1.2 ArrayChunk最小传输单元framework/py/flwr/app/message/arraychunk.py 定义了ArrayChunk类型它是实现InflatableObject接口的数据类仅携带一段memoryview数据deflate()将分块内容加上对象头序列化为字节流inflate()从字节流还原分块且明确拒绝子对象ArrayChunkobjects do not have children保证分块是最小、扁平的传输单元。1.3 并行推送与拉取编排framework/py/flwr/supercore/inflatable/inflatable_utils.py 实现了对象树的推送/拉取编排内置inflatable_class_registry注册表把ArrayChunk、Array、ArrayRecord、ConfigRecord、Message、MetricRecord、RecordDict等类名映射到具体类型使对端能按 ID 逐一还原对象push_objects()通过线程池并行推送多个对象并发度由get_num_workers()依据 CPU 核数与FLWR_PRIVATE_MAX_CONCURRENT_OBJ_PUSHES上限取小决定配套定义了ObjectUnavailableError、ObjectPullError、ObjectPushError三类异常并引入PULL_INITIAL_BACKOFF、PULL_BACKOFF_CAP、PULL_MAX_TRIES_PER_OBJECT等退避重试参数保证“先传头、再传体”的异步对象传输在网络抖动下的可靠性。从源码结构看Message与其携带的大数组Array/ArrayRecord被拆分为对象树消息体本身很小重量级的数组数据按 5MB 分块走独立的对象存储通道ObjectStore传输。这正是发布说明中“自动分块、用户无感”结论的落地方式——应用层代码依旧只面向Message编程分块与重组全部发生在框架内部。2. 对象化消息通信SuperNode 与 ClientApp 之间的新消息体系发布说明将这一项描述为对消息系统的重新设计启用 SuperNode 与 ClientApp 之间的对象化通信取代此前的“消息耦合message-coupled”设计引入新的 RPC增强ClientAppIo与 Fleet API以便在 SuperNode 中更好地做对象存储object storage并把ObjectStore从Message中解耦同时提升了模型权重流式传输model weight streaming的模块化程度与命名一致性。其技术脉络可以从两个层面理解存储层消息不再作为“一个整体字节包”与连接绑定而是按对象object粒度存放在 SuperNode 的对象存储中每个对象有独立 ID推送会话push session过期时可按 ID 批量清理消息——framework/py/flwr/supernode/nodestate/nodestate.py 中NodeState._on_push_session_expired()会调用delete_messages()删除过期推送会话所属的消息delete_messages()的文档还特别注明“若不提供任何过滤条件所有消息都将被删除”体现了对象化管理的严谨性传输层ClientAppIoAPI 的 RPC 被相应重构详见下一节客户端只负责按对象 ID 拉取pull/推送push消息的“内容实体”与“消息引用”分离。这一设计带来的直接收益是大模型权重不再需要一次性塞进单条消息权重可以流式地以分块对象形式进出 SuperNode 的对象存储从而与第 1 节的大模型传输能力天然衔接同时ObjectStore与Message解耦后后续扩展如缓存、审计、并发多 ClientApp有了清晰的挂载点。3. SuperNode 重构全面依赖 NodeState 管理状态发布说明指出本版本将 SuperNode 重构为仅依赖NodeState管理所有信息解耦内部组件以改善可维护性与状态处理的清晰度ClientAppIoAPI 的 RPC 也随之重构为未来支持并发运行多个 ClientAppconcurrent ClientApps打下基础。仓库中的抽象基类 framework/py/flwr/supernode/nodestate/nodestate.py 定义了NodeState继承自CoreState的核心契约方法职责set_node_id(node_id)设置节点 IDstore_message(message) - str \| None存储消息返回消息的对象 ID存储失败返回 Noneget_messages(*, run_ids, is_reply, limit)按运行 ID、是否回复消息、数量上限过滤取消息文档强调取出的消息不会在后续调用中重复返回delete_messages(*, message_ids)按对象 ID 删除消息store_run(run)/get_run(run_id)运行Run的存取record_message_processing_start/end(message_id)记录消息处理起止时间get_message_processing_duration(message_id)获取消息处理耗时秒围绕该抽象仓库还配有 in_memory_nodestate.py内存实现与 nodestate_factory.py工厂按配置创建对应实现及对应测试 nodestate_test.py。从源码结构看store_message返回“对象 ID 或 None”、消息按 ID 增删查的接口形态正是第 2 节“对象化消息 ObjectStore 解耦”在状态层的体现SuperNode 的全部运行时信息节点身份、Run、消息对象、处理计时都收敛到NodeState这一单一状态门面组件之间不再各自持有零散状态。发布说明也明确其战略意义——为并发 ClientApp 支持预留了状态隔离的骨架。4. FAB 文件 10MB 大小上限v1.20.0 起FABFlower App 包文件被限制为最大 10MB以防止过大的应用产物。开发者可以通过 Flower 应用目录中的.gitignore排除不必要的文件来缩小 FAB 体积。仓库源码中该限制有三处落点形成“构建时 下发时 启动时”的完整防线常量定义framework/py/flwr/common/constant.py 中FAB_MAX_SIZE 10 * 1024 * 1024 # 10 MB同文件还定义了 FAB 的包含/排除键与模式# FAB include and exclude keys in pyproject.toml FAB_INCLUDE_KEY fab-include FAB_EXCLUDE_KEY fab-exclude构建时校验framework/py/flwr/cli/build.py 在flwr build打包完成后立即校验# Validate FAB size if len(fab_bytes) FAB_MAX_SIZE: raise ValueError( fFAB size exceeds maximum allowed size of {FAB_MAX_SIZE:,} bytes. fTo reduce package size, narrow {FAB_INCLUDE_KEY} or add f{FAB_EXCLUDE_KEY} patterns in [tool.flwr.app]. )错误信息直接给出瘦身指引收窄[tool.flwr.app]中的fab-include或增加fab-exclude模式。服务端校验SuperLink 控制面在接收与下发 FAB 时同样拦截。framework/py/flwr/superlink/servicer/control/control_handlers.py 中远端拉取的 FAB 超过上限会抛出ValueError(Downloaded FAB exceeds the maximum size)StartRun路径上超限时记录错误日志并返回空的StartRunResponseStartAutomation路径则抛出带ApiErrorCode.INVALID_AUTOMATION_REQUEST的FlowerError提示 FAB 不得超过 10485760 字节。结合第 1 节的背景可以推断模型权重已经改走分块对象通道FAB 作为“应用代码包”回归了轻量定位10MB 上限是防止应用包与数据产物混淆的配套治理手段。5. 新增示例CatBoost 联邦二分类本版本新增了 CatBoost 联邦学习快速上手示例对应examples/quickstart-catboost/演示如何用 CatBoost 在Adult Census Income成人人口普查收入数据集上做联邦二分类并采用基于树的 bagging 聚合方式。仓库中的示例结构与代码印证了这一机制examples/quickstart-catboost/quickstart_catboost/client_app.py客户端训练逻辑。每个 ClientApp 用context.node_config中的partition-id/num-partitions加载数据分片用context.run_config中的local-epochs、learning-rate、depth训练一个CatBoostClassifier训练完成后客户端把 CatBoost 模型转换为 oblivious tree oblivious 树字典convert_to_catboost/convert_to_model_dict只截取最后 Niterations 棵新树再回传给服务端num_trees len(model_dict[oblivious_trees]) # Extract the last Niterations trees for sever aggregation model_dict[oblivious_trees] model_dict[oblivious_trees][ num_trees - iterations : num_trees ]同时用ConfigRecord回传 AUC 指标与模型字典封装为Message(reply_tomsg)服务端server_app.py与聚合任务task.py按树级别做 bagging 聚合避免整模型合并。这种“只回传本轮新增树”的做法与 v1.20 的消息/对象化传输体系契合回传内容是结构化的 ConfigRecord 而非二进制权重天然适配 Flower 的 Record 消息模型。完整文件见 examples/quickstart-catboost/含 README.md 与 pyproject.toml。6. 其他值得关注的变更以下变更虽短小但对部署与开发体验有实际影响6.1 Windows 上构建的 FAB 跨平台修复此前在 Windows 上构建的 FAB 因内部相对路径表示方式不同在 UNIX 系统如 Ubuntu上运行时完整性校验会失败。本版本更新了 FAB 内部相对路径的表示方式保证跨操作系统一致。这与 framework/py/flwr/cli/utils_test.py 中对 FAB 工具链的测试共同保障打包行为。6.2pyproject.toml配置指南与flwr new模板改进新增 Flower 应用pyproject.toml配置说明文档解释如何用[tool.flwr.app]等配置项组织应用结合上文第 4 节fab-include/fab-exclude等键都在 framework/py/flwr/common/constant.py 中有对应常量定义flwr new生成的模板在pyproject.toml中加入注释并在README.md中新增指向该配置说明的章节降低新手理解成本。6.3 Ray 后端在 Windows 上的告警当在 Windows 上使用 Ray 后端进行仿真simulation时框架会记录一条告警日志仿真文档也同步加入了“Windows 支持有限”的说明。在 Windows 上做大规模仿真时应留意此限制。6.4 新增 Helm 部署指南文档新增使用 Helm chart 部署 Flower SuperLink 与 SuperNode 的完整指南发布说明指向官方文档站的 Helm Guide面向生产环境部署的用户可直接参照。6.5 用户认证与审计日志文档新增用户认证User Authentication与审计日志Audit Logging配置指南。认证相关的常量可在源码中找到对应framework/py/flwr/common/constant.py 定义了 OIDC 访问/刷新令牌的 metadata 键flwr-oidc-access-token、flwr-oidc-refresh-token以及节点认证所需的公钥头、签名头与时间戳容忍度TIMESTAMP_TOLERANCE 300秒等可作为阅读认证实现时的入口。6.6 gRPC 健康检查默认启用SuperNode 现在默认支持 gRPC health check。仓库中 framework/py/flwr/supernode/main.py 及 CLI flower_supernode.py 包含对应的健康检查服务装配逻辑容器编排Kubernetes/Docker 健康探针可直接依赖标准 gRPC health 端点探活。6.7 其他发布说明还列出了 bugfix、CI/CD 改进、文档更新与一系列“General improvements”说明中未展开具体条目这些属于常规质量与基础设施改进。7. 不兼容变更start_client仅保留grpc-bidi传输本版本唯一明确标注的不兼容变更是已弃用的start_clientAPI 移除了对非grpc-bidi传输的支持并建议改用flower-supernode。源码层面的证据见 framework/py/flwr/compat/client/app.pyif transport is not None and transport ! grpc-bidi: raise ValueError( fTransport type {transport} is not supported. Use grpc-bidi or None (default) instead. )即调用start_client时若传入其他传输类型如grpc-rere会直接抛出ValueError函数入口同时会打印弃用警告并提示$ flower-supernode --help。从源码结构看framework/py/flwr/compat/目录本身定位就是兼容层compatibility shim旧版start_server/start_client程序应迁移到基于 SuperLink/SuperNode 的新部署形态而不是继续依赖这条弃用路径。8. 小结v1.20.0 的技术脉络把发布说明的条目串起来v1.20.0 的三条主线其实是一个整体对象化消息 ObjectStore 解耦消息系统重设计提供了按对象 ID 存取、推送会话管理的基础设施5MB 分块的 InflatableObject 传输构建在此之上让 LLM 级模型权重得以绕过 gRPC 2GB 限制、流式进出 SuperNode且对应用层透明NodeState 单一状态门面把 SuperNode 内部状态收敛使消息对象、Run、节点身份统一可管理为并发 ClientApp 铺路。外围变更FAB 10MB 上限、Windows 路径修复、CatBoost 示例、Helm/认证/审计文档、gRPC 健康检查则分别治理了应用包体积、跨平台一致性、模型生态覆盖与生产部署体验。对于仍在使用旧版start_server/start_client的用户建议关注唯一的不兼容变更start_client仅接受grpc-bidi新部署应转向flower-supernode。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
