Flower v1.12.0 版本解析SuperExec 日志流、uint64 标识迁移与消息 TTL 机制【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本篇文章基于 FlowerA Friendly Federated AI Framework仓库中 v1.12.0 变更日志 展开系统解读该版本引入的核心能力flwr log远程日志流、Node ID / Run ID 迁移至 uint64、SuperLink 消息 TTL 过期机制、FAB 哈希与安装结构优化、FedRep 基线、Docker 支持增强以及 Python 3.8 支持移除等破坏性变更。读完本文你将掌握 v1.12.0 的关键使用方式命令行、配置项以及其在当前仓库源码中的落地实现位置便于升级或复现。一、版本概览一个承上启下的发布v1.12.02024-10-14是 Flower 演进中的一个重要里程碑它在 1.9 版宣布弃用 Python 3.8 之后正式移除支持将最低版本提升至 Python 3.9推荐 3.11同时为后续的 FlowerTune LLM Leaderboard、SuperExec 运行体系铺路。按官方变更日志该版本由Adam Narozniak、Charles Beauville、Daniel J. Beutel等 15 位贡献者共同完成。从仓库现状看v1.12.0 提到的多项能力至今仍在框架中承担核心职责例如flwr log命令的实现位于 framework/py/flwr/cli/log.py消息 TTL 的超时判断逻辑位于 framework/py/flwr/server/superlink/linkstate/utils.pyFAB 哈希截断常量FAB_HASH_TRUNCATION 8定义于 framework/py/flwr/common/constant.py。以下各节逐一拆解。二、SuperExec 日志流flwr log实时监控远程运行2.1 功能定位与用法v1.12.0 引入了 SuperExec 日志流log streaming能力当 Flower 应用在远端 SuperExec 上执行时开发者可以通过flwr log命令实时查看日志。官方给出的两种调用形态# 仅指定 run-id使用默认连接 flwr log run-id # 显式指定 app 目录与 federation联邦配置 flwr log run-id app-dir federation2.2 源码级实现证据当前仓库中flwr log的实现位于 framework/py/flwr/cli/log.py其核心流程如下命令入口log()接收run_id必选参数以及可选的--stream/--show开关其中--stream为默认行为实时流式输出--show则一次性打印已有日志底层通过 Control API 客户端ControlHttpClient发起StreamLogsRequest(run_id..., after_timestamp...)见stream_logs()并将服务端返回的log_output逐行打印start_stream()内部以after_timestamp游标推进从指定时间点之后继续拉取日志配合KeyboardInterrupt优雅退出实现实时跟随效果连接参数通过read_superlink_connection()读取并支持--federation-config覆盖该选项当前被标记为隐藏并提示忽略。2.3 关联基础设施SuperExec日志流的另一端是 SuperExec 组件。当前仓库在 framework/docker/superexec/Dockerfile 中提供其容器镜像分布式部署示例可见 framework/docker/distributed/server/compose.yml其中superexec-serverapp服务以--runtime-api-address superlink:8000挂接 SuperLink从而把运行中产生的日志回传给控制平面供flwr log拉取。可以推断日志流链路为SuperExec 运行应用 → 日志写入 SuperLink 控制平面 →flwr log通过 Control API 增量拉取。三、标识符迁移Node ID 与 Run ID 全面升级为 uint643.1 变更内容v1.12.0 将 Node ID、Run ID 等字段从有符号 64 位整数sint64迁移为无符号 64 位整数uint64并在所有通信链路上完整支持uint64。对 Python 用户而言这意味着你可以在 config 与 metric 字典中使用大于sint64最大值、小于uint64最大值的int值消息元数据Message Metadata中的run_id、node_id、src_node_id、dst_node_id等均以uint64承载。3.2 仓库中的落地证据在协议定义层面framework/proto/flwr/proto/message.proto 中Metadata消息的run_id字段 1、src_node_id字段 3、dst_node_id字段 4均为uint64framework/proto/flwr/proto/transport.proto 中Scalar的uint64类型字段 6用于在配置与指标字典中传递无符号整数。在运行/控制层面framework/proto/flwr/proto/control.proto 中的run_id、automation_id、series_id等字段同样全面采用uint64。在状态层framework/py/flwr/server/superlink/linkstate/utils.py 提供了int64_to_uint64及配套的字典值转换函数见convert_int64_to_uint64用于数据字典中部分键值的有符号/无符号互转正是这次标识符迁移在持久化与内存状态层的兼容性适配。四、消息 TTLSuperLink 消息自动过期与清理4.1 设计思路v1.12.0 为 SuperLink 中的消息实现了完整的 Time-to-LiveTTL支持每条消息携带ttl字段单位秒与created_at时间戳SuperLink 在消息存取时判断是否过期过期消息自动清理。该机制可通过底层 API 配置高层 API 默认启用。4.2 源码细节元数据定义Metadata消息在 framework/proto/flwr/proto/message.proto 中通过字段 7double ttl承载 TTL 值默认值高层 API 的默认 TTL 定义在 framework/py/flwr/app/constants.py即DEFAULT_TTL 4320012 小时在 framework/py/flwr/app/message/message.py 创建 Message 时以ttl or DEFAULT_TTL生效过期判定framework/py/flwr/server/superlink/linkstate/utils.py 中message_ttl_has_expired()的判定条件为ttl created_at current_time即创建时间 存活时长小于当前时间则视为过期内存状态层framework/py/flwr/server/superlink/linkstate/in_memory_linkstate.py 在消息检索时按created_at ttl计算available_until并对回复消息的 TTL 施加约束回复 TTL 不得超过ins_metadata.created_at ins_metadata.ttl - res_metadata.created_at超出即拒绝附容差MESSAGE_TTL_TOLERANCE从而保证回复不晚于原消息失效的一致性错误语义当查询的消息已过期或不可用时SuperLink 返回携带ErrorCode.MESSAGE_UNAVAILABLE/REPLY_MESSAGE_UNAVAILABLE的错误消息见create_message_error_unavailable_ins_message()与create_message_error_unavailable_res_message()其中错误回复的 TTL 会按剩余存活时间重新计算ttl max(ins_metadata.ttl - (current_time - ins_metadata.created_at), 0)。从源码结构看TTL 机制的核心价值在于避免因节点掉线、消息积压导致的状态无限膨胀为 SuperLink 的长时间运行提供内存/数据库层面的自动回收能力。五、FAB 处理优化文件名哈希与扁平化安装5.1 变更内容v1.12.0 对 Flower App BundleFAB做了两项优化FAB 文件名追加 8 字符哈希flwr install安装后的目录结构从 3 层扁平化为 1 层。5.2 仓库中的实现哈希截断长度常量FAB_HASH_TRUNCATION 8定义于 framework/py/flwr/common/constant.py同时APP_DIR apps定义了应用安装根目录构建侧framework/py/flwr/cli/build.py 计算 FAB 的 SHA-256 哈希并截取前 8 字符附加到文件名安装侧framework/py/flwr/cli/install.py 对 FAB 内容做哈希校验_verify_hashes()并将应用安装到形如apps/publisher.project_name.version.8位哈希的目录见install()中的路径拼接逻辑同时在解析时校验传入的短哈希与真实哈希一致len(fab_shorthash) ! FAB_HASH_TRUNCATION直接拒绝。可以推断追加哈希的动机是消除同名不同内容 FAB 的冲突保证同一发布者、项目名、版本组合下不同内容的 FAB 可共存扁平化安装则缩短路径深度、简化后续flwr run对应用目录的解析。六、新基线FedRep 个性化联邦学习v1.12.0 引入了 FedRep 基线。FedRep论文 Exploiting Shared Representations for Personalized Federated Learning的核心思想是各客户端共享一个全局学习的特征表示representation/body同时在本地维护个性化分类头head在协作与个体适配之间取得平衡。该基线在仓库中的实现位于 baselines/fedrep关键文件与机制如下client_app.pyBaseClient实现标准 FedAvg 客户端FedRepClient覆写get_parameters()只返回_body参数set_parameters()在训练阶段只更新 body 与尚未训练的 head本地仅保留个性化 head 状态client_fn()通过context.run_config[algorithm]取值fedrep或fedavg选择算法并将个性化 head 保存在context.state.parameters_records[FEDREP_HEAD_STATE]constants.py定义默认超参DEFAULT_LOCAL_TRAIN_EPOCHS 10、DEFAULT_FINETUNE_EPOCHS 5、DEFAULT_REPRESENTATION_EPOCHS 1以及 CIFAR-10/CIFAR-100 的归一化均值与标准差strategy.py服务端FedRep策略继承自FedAvg配置文件位于 baselines/fedrep/conf例如 cifar10_5.toml 展示了实验配置结构algorithm、dataset-name、dataset-split、dataset-split-num-classes、dataset-split-seed、dataset-split-fraction等。七、FlowerTune 模板与 LLM 评估管线优化该版本对 FlowerTune 模板与 LLM 评估管线进行了系统打磨涉及 16 个 PR为即将上线的 FlowerTune LLM Leaderboard 做准备覆盖 Finance、Medical、通用 NLP 等多个领域并细化了评估指标与文档。仓库中可参考的 FlowerTune 示例包括examples/flowertune-llm基于 OpenLLaMA Alpaca-GPT4 的联邦指令微调集成 Flower Datasets 下载/切分、PEFT 微调与 Flower 仿真引擎可在单 GPU 上完成仿真训练examples/flowertune-llm-code、examples/flowertune-llm-finance、examples/flowertune-llm-general-nlp、examples/flowertune-llm-medical对应代码、金融、通用 NLP、医疗等垂直领域的联邦 LLM 微调应用仓库还提供 benchmarks/flowertune-llm 基准目录包含评估脚本与结果整理逻辑。这些示例可作为接入后续 FlowerTune Leaderboard 的起点。八、Docker 支持增强与文档更新v1.12.0 在容器化方面做了系统性升级Ubuntu 基础镜像升级至 24.04Docker 镜像新增 SBOM软件物料清单与 gcc补充了包含快速上手指南与分布式 Docker Compose 部署在内的完整 Docker 文档。当前仓库的 Docker 资产包括基础镜像framework/docker/basealpine / ubuntu / ubuntu-cuda 三个变体Python 运行时镜像framework/docker/python/ubuntu各组件镜像framework/docker/superlink、framework/docker/supernode、framework/docker/superexec完整编排示例framework/docker/completecompose.yml、with-state.yml、with-tls.yml、certs.yml分布式部署示例framework/docker/distributedclient 与 server 两个 compose 文件配合证书生成。以 framework/docker/distributed/server/compose.yml 为例部署一个分布式服务端需要同时拉起superlink监听 9092/8000 端口、挂载state/state.dbSQLite 数据库、启用 TLS 证书与superexec-serverapp基于flwr/superexec镜像构建注入应用代码并以--plugin-type serverapp运行二者通过superlink:8000通信。九、其他更新与破坏性变更清单9.1 常规更新flwr new模板改进MLX、NumPy、sklearn、JAX、PyTorch 模板统一了可用性与跨框架一致性文档更新PyTorch Lightning、TensorFlow、Hugging Face、Fastai 等快速上手教程全部迁移到新的flwr run命令FAQ 新增区块链示例示例项目刷新垂直联邦学习、高级 PyTorch、Pandas、Secure Aggregation、XGBoost 等示例被更新Hugging Face 快速上手换用更小的语言模型并移除遗留的仿真示例Flower 术语表glossary新增 glossary 目录为关键联邦学习概念提供清晰定义如 aggregation、client、server、federated-learning、heterogeneity-in-federated-learning 等并欢迎社区贡献扩充Flower 架构讲解页新增逐步介绍各 Flower 组件的架构 explainer 文档收录在框架文档的 EXPLANATIONS 章节源文件位于 framework/docs/source翻译更新多个语言文件随版本同步更新。9.2 破坏性变更升级必读移除 Python 3.8 支持最低版本提升至 Python 3.9。Python 3.8 自 1.9 起被弃用本版本正式移除当前支持范围覆盖 Python 3.9 至 3.12推荐 3.11。CI 与文档均以 Python 3.9 为最低支持版本。升级到 v1.12.0 及之后的版本时请确保运行环境满足该要求。十、升级与验证建议环境检查确认 Python 版本 ≥ 3.9推荐 3.11可通过python --version验证日志监控升级后使用flwr log run-id验证 SuperExec 日志流是否按预期工作flwr log run-id --show可只打印已有日志uint64 兼容性若在 config / metric 中传递大整数注意其取值范围应在[0, 2^64-1]内协议层已全面支持uint64TTL 行为高层 API 默认 TTL 为 12 小时DEFAULT_TTL 43200若你的训练轮次耗时较长或客户端响应缓慢可通过底层 API 调整 TTL避免消息提前过期FAB 安装重新构建并flwr install应用确认新安装目录为apps/publisher.project.version.8位hash扁平结构文档与示例参照 framework/docs/source/changelog/index.md 中的完整变更索引以及更新后的快速上手示例如 examples/quickstart-pytorch验证新命令流程。结语Flower v1.12.0 是一次面向运行体验与协议基础的双重升级flwr log让远程运行可观测uint64 迁移与消息 TTL 让底层协议更稳健FAB 哈希与扁平化安装让应用分发更可靠而 Python 3.8 的移除则为后续演进扫清了兼容负担。理解这些变更不仅有助于平滑升级也能更深入地把握 Flower 当前架构SuperLink / SuperExec / SuperNode Control API的设计脉络。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考