EdgeFlowerTune：在真实边缘系统约束下评估联邦大语言模型微调

# EdgeFlowerTune：在真实边缘系统约束下评估联邦大语言模型微调

来源：https://arxiv.org/html/2605.08636

†Jiaxiang Geng¹, †Yiyi Lu¹, †Lunyu Zhao¹, Yan Gao²,³, Nicholas D. Lane²,³, Bing Luo¹

¹杜克昆山大学 ²Flower Labs ³剑桥大学

###### 摘要

联邦微调为利用智能手机和物联网（IoT）设备产生的丰富、多样且持续生成的数据进行大语言模型（LLM）适配提供了一种有前景的范式，同时不损害用户数据隐私。这种边缘侧适配可以提高模型的个人化能力、鲁棒性以及对本地上下文的响应能力。然而，在真实边缘设备上部署联邦 LLM 微调的可行性尚不清楚，因为大多数现有工作主要集中在跨中心（cross-silo）或基于模拟的设置上，忽视了决定方法是否能在真实边缘系统上部署的资源和运行时约束。我们提出了 **EdgeFlowerTune**，这是一个面向部署的基准测试，用于在真实的边缘系统约束下评估联邦 LLM 微调。EdgeFlowerTune 联合评估模型质量和系统成本，包括通信量、挂钟延迟、内存使用、能耗以及对动态边缘条件的鲁棒性。为了在有效性、效率和鲁棒性方面比较不同方法，EdgeFlowerTune 引入了三种互补的协议：**预算内质量（Quality-under-Budget）**、**目标成本（Cost-to-Target）** 和 **鲁棒性（Robustness）**。我们将 EdgeFlowerTune 实例化为一个基于 Flower 和 MobileFineTuner 构建的真实设备平台，涵盖商用 Android 智能手机和 NVIDIA 边缘开发板。基准测试结果发现，仅基于准确率的评估可能导致误导性结论：一旦考虑真实的系统约束，具有相似最终质量的方法在可部署性上可能存在显著差异。EdgeFlowerTune 提供了用于边缘侧联邦 LLM 微调的系统感知评估的可复现基准。

22 脚注：这些作者对本工作贡献同等。

## 1 引言

近年来，大语言模型（LLMs）在各种语言任务上取得了卓越的性能，并成为下游适配和部署的主要基础[19](https://arxiv.org/html/2605.08636#bib.bib1)。这些模型的扩展面临一个关键瓶颈：预计高质量公开数据集将在 2026 年至 2032 年间耗尽[24](https://arxiv.org/html/2605.08636#bib.bib29)。幸运的是，大量有价值的数据正在边缘设备（如智能手机和物联网（IoT）设备）上持续生成[1](https://arxiv.org/html/2605.08636#bib.bib30)。然而，直接从这些边缘设备收集数据进行集中式训练可能会暴露敏感的个人隐私信息，带来隐私风险，并可能违反《通用数据保护条例》（GDPR）等数据保护法规[8](https://arxiv.org/html/2605.08636#bib.bib31)。联邦学习（FL）提供了一种自然的解决方案，它使多个客户端能够在保持训练数据本地的同时，协作训练或适配共享模型[13](https://arxiv.org/html/2605.08636#bib.bib4),[18](https://arxiv.org/html/2605.08636#bib.bib3)。这种范式将边缘数据保留在本地设备中，不与服务器共享原始数据，同时仍允许这些数据为模型训练做出贡献。基于这一理念，近期工作开始将 FL 扩展到边缘设备上的 LLM 微调[5](https://arxiv.org/html/2605.08636#bib.bib47),[27](https://arxiv.org/html/2605.08636#bib.bib26)，通常被称为联邦 LLM 微调。然而，与传统联邦学习相比，联邦 LLM 微调由于模型规模更大，给边缘设备带来了更大的负担，导致对计算、通信、内存和能源的需求显著增加。这些系统成本已成为边缘设备上联邦 LLM 微调和发展的主要瓶颈，也是现有研究工作面临的核心挑战[9](https://arxiv.org/html/2605.08636#bib.bib32)。

为了促进不同联邦 LLM 微调方法的比较，OpenFedLLM 和 FederatedScope-LLM 提供了用于联邦 LLM 微调的端到端框架和基准[30](https://arxiv.org/html/2605.08636#bib.bib8),[14](https://arxiv.org/html/2605.08636#bib.bib7)，而 FlowerTune 则通过涵盖通用 NLP、金融、医疗和代码任务的跨领域排行榜进一步扩大了基准测试的范围[10](https://arxiv.org/html/2605.08636#bib.bib10)。然而，这些现有框架和基准主要关注跨中心设置，强调最终任务质量（如准确率），而 largely 忽视了真实边缘环境施加的系统约束。在边缘环境中考虑联邦 LLM 微调带来了几个新挑战：(1) 一种方法可能取得很好的最终性能，但由于其计算、通信、内存或能源消耗超过了边缘设备的承受能力，因此在边缘部署上仍不切实际。(2) 在比较两种方法时，尚不清楚如何在更高的最终准确率与更好的系统效率之间进行权衡。(3) 边缘环境本质上是动态的：客户端掉线、硬件异构性和滞后效应可能会在训练期间显著影响方法的表现。

为了克服这些挑战，我们提出了 **EdgeFlowerTune**，这是一个在真实边缘系统约束下对 LLM 进行联邦微调的基准测试。EdgeFlowerTune 不仅仅关注哪种方法能获得最高的最终任务得分，而是评估不同方法在真实边缘部署条件下的有效性、效率和鲁棒性。此外，为了实现可信的系统感知评估，我们将 EdgeFlowerTune 实例化为一个基于 Flower 和 MobileFineTuner 构建的真实设备联邦 LLM 微调平台，涵盖包括主流商用智能手机和 NVIDIA 边缘计算开发板在内的异构边缘硬件。

> 图 1：EdgeFlowerTune 概述。候选联邦 LLM 微调方法部署并执行在真实设备边缘平台上，在线监控模型质量和系统成本。收集的指标随后由提出的基准协议进行评估。

我们的贡献总结如下：

*   我们提出了 **EdgeFlowerTune**，一个在真实边缘系统约束下对大语言模型进行联邦微调的基准测试。与主要强调最终任务质量的现有联邦 LLM 微调基准不同，EdgeFlowerTune 以可部署性为核心，从有效性、效率和鲁棒性三个方面进行评估。我们的代码已在 https://github.com/Edge-Intelligence-Lab/EdgeFlowerTune 开源。
*   我们提出了一种端到端的评估工作流程，并引入了三种互补的面向部署的评估协议，即 **预算内质量（Quality-under-Budget）**、**目标成本（Cost-to-Target）** 和 **鲁棒性（Robustness）**，以系统地评估在通信、延迟、内存、能源和系统可变性明确约束下的联邦 LLM 微调方法。
*   我们将 EdgeFlowerTune 实例化为一个基于 Flower 和 MobileFineTuner 构建的真实设备联邦 LLM 微调评估平台，涵盖包括商用智能手机和 NVIDIA 边缘计算开发板在内的异构边缘硬件，从而实现了超越仅模拟或仅服务器评估的可信系统感知基准测试。
*   我们对代表性的联邦 LLM 微调方法进行了基准研究，表明系统感知评估可以显著改变方法结论：在仅基于准确率的评估中表现良好的方法，一旦考虑到真实的边缘约束和系统扰动，可能变得次优。

## 2 EdgeFlowerTune 基准设计

在本节中，我们介绍 EdgeFlowerTune 的基准设计。我们首先介绍端到端的评估工作流程，描述候选联邦 LLM 微调方法如何被部署、在真实边缘设备上执行、在训练期间监控，并最终由基准进行评估。然后，我们定义了三种面向部署的基准协议，用于在真实的边缘系统约束下比较不同方法。

### 2.1 端到端评估工作流程

图 1[1](https://arxiv.org/html/2605.08636#S1.F1) 说明了 EdgeFlowerTune 的端到端评估工作流程。与现有的跨中心基准相比，它具有三个关键特征。首先，每个候选方法必须显式地部署到 EdgeFlowerTune 基准环境中，以便其客户端训练逻辑、服务器端协调、通信模式和微调配置可以在统一的评估栈中执行。其次，微调在真实的异构边缘系统上执行，商用移动设备和边缘计算板作为联邦客户端参与。第三，由于系统行为在训练过程中会演变，EdgeFlowerTune 在整个微调过程中在线记录模型质量和系统成本指标，而不是在训练后从离线测量中估算。收集的执行轨迹随后由基准协议用于在有效性、效率和鲁棒性方面比较不同方法。工作流程的阶段如下：

**阶段 1：方法部署。** 候选联邦 LLM 微调方法首先在 EdgeFlowerTune 基准环境中实例化。该方法定义其本地训练过程、服务器端聚合规则、客户端与服务器之间交换的对象、通信调度和微调配置。为了确保公平比较，所有方法都在相同的基准规范下部署，包括相同的任务、数据分区、基础模型、客户端池、训练预算和系统约束。

**阶段 2：真实设备联邦微调。** 部署的方法随后在真实的 EdgeFlowerTune 系统上执行。在每次通信轮次中，服务器协调客户端选择，分发所需的模型状态或微调参数，收集特定于方法的更新，并执行聚合。选定的客户端使用规定的特定于方法的程序在其私有数据上执行本地 LLM 微调。与仅服务器或基于模拟的评估不同，此阶段使每种方法暴露于实际的边缘系统条件，包括异构设备能力、真实通信链路和运行时资源限制。

**阶段 3：在线指标收集。** 在联邦微调期间，EdgeFlowerTune 持续监控模型质量和系统成本指标。模型质量指标包括特定于任务的分数，如损失和准确率。系统成本指标包括通信量、客户端内存使用、能耗和挂钟时间。这些指标在实际基准执行期间在线收集。

**阶段 4：基于协议的基准测试。** 执行后，收集的质量和系统轨迹传递给基准评估模块。EdgeFlowerTune 使用面向部署的协议（如图 2.2[2](https://arxiv.org/html/2605.08636#S2.SS2) 所示）而不是仅最终任务质量来比较方法。

> 图 2：EdgeFlowerTune 基准协议。协议 A 评估在固定系统预算下可实现的最佳模型质量；协议 B 衡量达到目标质量所需的系统成本；协议 C 量化在边缘系统扰动下的鲁棒性。

### 2.2 EdgeFlowerTune 基准协议

图 2[2](https://arxiv.org/html/2605.08636#S2.F2) 总结了 EdgeFlowerTune 中的三种基准协议。这些协议的目标是从面向部署的角度比较联邦 LLM 微调方法。在真实的边缘环境中，一种方法并不一定仅仅因为获得了更高的最终准确率或更低的困惑度而更好。它可能需要过多的通信，超过移动设备的内存容量，消耗过多能源，或在网络和设备的可变性下变得不稳定。因此，EdgeFlowerTune 沿两个耦合维度评估每种方法：模型质量和系统成本。模型质量使用特定于任务的指标（如损失和准确率）进行测量。系统成本使用真实执行指标进行测量，包括通信量、挂钟时间、客户端内存使用、功耗和能耗。基于这些测量，EdgeFlowerTune 定义了三种互补的协议。每种协议对应一个不同的部署问题，并产生“最佳”方法的不同概念。

**协议 A：预算内质量（Quality-under-Budget）。** 该协议评估在固定系统资源预算下的方法有效性。给定相同的通信量、挂钟时间、内存使用和能耗上限，每个候选方法在允许的预算内执行，EdgeFlowerTune 测量其能达到的最佳模型质量。该协议回答的问题是：**在相同的系统资源上限下，哪种方法能达到最高的最终质量？** 在此协议下，最佳方法是在不违反指定系统预算的情况下提供最高任务质量的方法。

**协议 B：目标成本（Cost-to-Target）。** 该协议评估达到所需质量水平的方法效率。EdgeFlowerTune 不固定资源预算，而是指定一个目标质量阈值，记为 $q^*$，并测量每种方法达到该目标所需的系统成本。成本可以沿多个维度报告，包括总通信量、训练延迟、内存占用和能耗。该协议回答的问题是：**为了达到目标质量，哪种方法成本最低？** 在此协议下，最佳方法是以最小系统成本达到 $q^*$ 的方法。

**协议 C：鲁棒性（Robustness）。** 该协议评估在真实边缘系统扰动下的方法稳定性。EdgeFlowerTune 在标称条件和扰动条件（包括带宽变化、客户端掉线和设备异构性）下比较每种方法。对于每种扰动，基准测量模型质量和系统效率的下降。该协议回答的问题是：**哪种方法在真实的边缘系统变化下保持稳定？** 在此协议下，最佳方法是从标称执行到扰动执行的相对下降最小的方法。

## 3 实验设置

### 3.1 EdgeFlowerTune 平台

为了支持系统感知基准测试，EdgeFlowerTune 被构建为一个真实设备联邦 LLM 微调平台，而不是仅模拟环境。如图 3[3](https://arxiv.org/html/2605.08636#S3.F3) 所示，该平台由 GPU 服务器、跨平台通信层和异构边缘客户端组成。服务器是一台配备两个 NVIDIA A800 GPU 的 Dell PowerEdge T640。它运行 Flower[10](https://arxiv.org/html/2605.08636#bib.bib10) 进行联邦编排，并使用 PyTorch 和 Transformers[28](https://arxiv.org/html/2605.08636#bib.bib33) 进行模型执行和聚合。客户端池涵盖 Android 智能手机和 Linux 边缘计算板[^1]，如表 1[4](https://arxiv.org/html/2605.08636#S3.T1) 所示。Android 客户端使用 MobileFineTuner[11](https://arxiv.org/html/2605.08636#bib.bib34) 执行本地 LLM 微调，一

[^1]: 我们从当前测试台中排除了 iPhone，因为 iOS 积极终止内存密集型后台进程，使得设备上长期运行的 LLM 微调不稳定。