返回

author = “zidea” title = “随手记个词” date = “2024-10-07” description = “nothing here”

+++

Nebula and Galaxy

Nebula: An Edge-Cloud Collaborative Learning Framework for Dynamic Edge Environments

cloud-based learning和on-device learning无法有效的处理快速的数据变化和资源不懂导致的动态环境，所以提出了Nebula一个端云协同的动态环境

创新点如下：

  • 模块化设计将大型云模型分解成各个模块，并可以灵活的分解和聚合从而实现知识有效聚合
  • 设计了Nebula实现端云协同计算
  • 在模拟和现实测试中具有显著优异性

Motivation

  • 两个问题
    • 外界环境变化导致数据偏移性能下降
    • 运行时动态变化影响推理、通讯速度

image-20241008105943635
image-20241008105943635

（随time slots数据逐渐变化，static场景下性能一般，但是updated下边缘性能也不是特别强，随着进程数量增加推理延迟逐渐增大）

现有的端云协同方法有两类：基于logits的蒸馏和从云端模型中剪枝摘取子模型的方案，但是两者一个需要KD一个需要剪枝，相对来说都比较复杂和消耗时间。

论文所需要面临的挑战：

  • 从云端大模型快速高效导出有紧凑且个性化的模型不容易
  • 个性化的模型在模型结构和参数上都是异构的，所以KD（计算复杂）、简单的聚合（参数冲突）都不是一个可取方案

论文提出的方法能够便捷的支持动态变化，重用其他设备的模型（具体看后面的方法论）

NEBULA

image-20241008143022773
image-20241008143022773

主要分为云端模型原型/训练 和 云端协同适应两阶段（或者说offline和online两阶段）

先大致说一下整体的pipeline

在offline阶段，大型云模型分解为多个可组合的模块，设计模块选择器来组织模块，并与云端的代理数据联合训练，为后续的在线适配阶段做好准备。从而可以从大型云模型中派生出具有不同结构和针对各种边缘设备的专门能力的各种子模型。

在online阶段，星云会定期导出并聚合个性化子模型，首先获取每个设备的本地数据分布和可用资源，在每个设备的资源限制下，我们选择与其目标本地任务相关的最重要的模块，形成个性化的子模型。而且整个过程依旧动态，在边缘执行模型期间，设备可以调整本地模块，以根据资源波动灵活扩展本地模型大小，并使用新收集的数据更新本地子模型以适应数据分布变化。之后定期进行按模块的子模型聚合，以形成更新的云模型，该模型集成了边缘设备学到的新知识，并进一步提供最新的子模型作为回报。

offline stage: ON-CLOUD MODEL PROTOTYPING AND TRAINING

Block-level Model Modularization

方法算是对模型的划分，需要遵循两个原则：

  • 每个模块可以细粒度的派生出个性化的子模型
  • 每个子模型负责一个子任务

对于VGG，其是[Conv, BN, ReLU, Pooling, Dropout]组成的多层模型，因此每个块可以视为一个子模型，每个实现特征提取、分类的功能（同理的对于ResNet）（再者论文并没有讨论Transformer的情况），所以模型可以用如下表示：

$F(x, \omega)=f^{(L)}\circ f^{(L-1)} \circ … f(1)(x, \omega)$

对于每个模块都设计了可替代模块：

image-20241009144801559
image-20241009144801559

此时，每个模块的公式如下：

$f^{(l)}(x^{(l)}, \omega^{(l)}) = Com_{i \in A}{f_i^{(l)}(x^{(l)}, \omega^{(l)})}; g^{(l)}(x^{(l)};\theta^{(l)})$

其中A是所有激活的模块，g是模块选择器（有点像继承学习的思路了）

前面说了对每个模块都有可以替换的模块（这里论文主要强调输入和输出对应相同的模块从而可以屏蔽内部细节，比如砍一些hidden size, conv channel），此外还准备了一些resnet残差层。对于ResNet18，其中有4个模块层，假设每个模块层可以采用16个模型，那么子模型的排列组合就有：$$(2^{16})^4$$

image-20241009150043272
image-20241009150043272

现在创建了这些个模型，接下来就是如何选择和组合子模型。

Module Selector Construction

g是模型选择器，输入x输出模块的概率分布，筛选其中k个模块激活（MoE了属于是）

$f(x;\omega)=\sum_{i\in A}[g(x;\theta)]_i\cdot f_i(x;\omega_i),A=Top-k(g(x;\theta))$

但是如果是上述的方案的话，其实相当于每个自模块都需要经过这样一个过程，从而产生一个依赖以及性能下降，所以采用一个embed做数据的特征提取：

$\mathbf{g}(x;\theta)={\mathbf{g}^{(l)}(h;\theta^{(l)})|h=embed(x;\bar{\theta}),l\in{1,\cdots,L}}.$

从而在数据输入即可决定所有的选择结果。模块设计好之后就是训练问题了。

End-to-end Model Training

论文里面有如下对应关系：

全局模型-全局任务

子模型-子任务

所以首先是使用模块选择器将任务分解为子任务并映射到正确激活的模块。然后进行一个端到端的训练，损失函数如下：

$\mathcal{L}(\hat{\boldsymbol{y}},\boldsymbol{y};\hat{\mathbf{g}})=CrossEntropy(\hat{\boldsymbol{y}},\boldsymbol{y})+\lambda\cdot LoadBalance(\hat{\mathbf{g}}),$

看得出来并不复杂，就是一个交叉熵（对齐标签）以及一个负载均衡（这个在MoE里面叫Z-loss，简而言之就是防止logits值过大导致梯度爆炸以及过于依赖于一个expert）（此外，还采用了一些技术解决topk不可微的问题）

理论上这时候就可以大力出奇迹了，把全局任务数据用来训练这个更大的模型，模型自然会学到合适的路由模块g，模型参数。但是问题在于训练出来的g得到的是所有模块的概率，这意味着需要给每个边缘设备所有的模型（或者较多的模型），对于边缘设备计算负担太大了。所以进一步筛选。

image-20241009204246280

如图所示就是论文想办法解决的计算问题，表格是子任务和模块的概率对应关系，分为微调前和微调后的表，所以问题就变成了一个线性优化，求解最优表格M：

image-20241009205009744
image-20241009205009744

使得掩码之后效果最佳。k1和k2分别表示两个约束，前者表示一个模块的负载程度小于k1，后者表示task最多接受k2个模块。

最后就是对整个模块进行一个Finetune，从global task筛一些不同子任务的数据来微调，损失变成这样：

拿每个层出来的概率分布KL监督一下现在的输出从而对其一下子任务和对应的模块。

Online Stage: EDGE-CLOUD COLLABORATIVE ADAPTATION

前面说实话都是把重心放在云计算上了，相对而言云端同时具有数据和计算能力，然后就轮到边缘的客户端受罪了

基于模块化云模型，在客户端，论文用的基于重要性的子模型推导来提取边缘设备的个性化子模型，并引入按模块加权模型聚合来聚合更新的异构边缘模型。

Personalized Sub-model Derivation

需要满足资源限制+符合本地任务，所以操作为：使用前面提到的模块选择器输出模块的重要性，之后用本地资源分析子模型的资源开销

重要性获取倒是也不复杂，把所有数据根据模块模块选择器进行一下选择得到概率分布即可，然后就能得到对应的子模型了。然后是对资源限制，同样是转换为一个受限的优化问题（多维背包问题，常刷leetcode的应该会熟练一点，找到优先选每个模块层最重要的模块，然后想办法用优化办法解决一下）

当然论文也提到了，客户端可以多放一点子模型（如果资源允许）来实现更加方便的本地动态调整。

Module-wise Sub-model Aggregation

由于每个子模型的参数还是相同的，所以进行一个平均即可，当然，为了更加严谨或者科学性一点用了加权的方式进行，还是用的前面的重要程度来做的（其实思路和我们的比较想，理论上也容易过拟合，但是通过loadbalance的损失避免这个问题了，因此从某个角度上来看，LoadBalance相关的损失不单单可以用来做负载均衡，还能做防止过拟合的特征选择器。

Evaluation

数据集： HAR数据集、CIFAR10 CIFAR100, 语音识别

模型： 3-layer MLP, ResNet18, VGG16, ResNet34

baseline:

  • 边缘端使用预训练的大型云模型，NA:本地不做微调
  • 每个边缘设备在本地调整小模型：LA:每个客户端使用本地数据更新模型, AN每个客户端在云端获得预训练的多分支模型并调整分支使得精度和延迟均衡。
  • 端云协同，利用FedAvg(FA)和HeteroFL(HFL)

实验结果

image-20241014152628327
image-20241014152628327

相较于需要通讯的FA, HFL，具有准确率高而且训练速度快，内存占用小的优势，毕竟这个有数据的交互了。

image-20241014153507428
image-20241014153507428

图12表示随即采样子模型是的准确度，可以看出来论文的方法基于重要性排序没啥问题。13就是敏感性分析。

Galaxy: A Resource-Efficient Collaborative Edge AI System for In-situ Transformer Inference

image-20241015154503253
image-20241015154503253

IEEE International Conference on Computer Communications 2024

用家里面的边缘设备加速服务器端的transformer模型运算

简而言之使用混合设备实现Transformer推理加速

挑战如下：

  • 把单个transformer推理负担并行到边缘设备上
  • 如何决定异构设备的资源
  • 减少分布式推理延迟

贡献

  • 提出HMP架构来加速Transformer推理
  • 设计一个异构性和内存预算感知的工作负载规划算法
  • 基于图块的细粒度优化，利用通讯和计算重叠的概念减轻同步开销（说人话，流水线）
  • 比baseline延迟低

相关工作和观察

image-20241015155145457
image-20241015155145457

模型在30seq_len下的推理速度，A100薄纱Nano-M设备

image-20241015155302956

前两个确实不太行，模型并行还分为张量并行TP和序列并行SP。TP可以划分参数，但是无法并行MLP，MHA等操作（有依赖性）。SP对输入数据分段进行，但是依旧会有数据依赖。

GALAXY DESIGN

整体分为5步：

  • 使用校准数据在边缘设备上进行输入跟踪
  • 基于HMP架构编排设备
  • 根据分析结果生成配置
  • 根据资源异构和内存预算执行并实现协同推理
  • 基于图块的细粒度通讯优化来减轻通讯开销

其实核心在于如何编排模型使得其能实现混合模型并行化

image-20241015161515118
image-20241015161515118

从头到尾根据Transformer的结构有8块并行的特殊设计和改进。

image-20241015184451714
image-20241015184451714

1.对于多头注意力，每个头的计算是独立的，因此可以直接分出来多个头到各个客户端实现张量并行。$Q(x), K(x), V(x)$

2.之后是进行一个attention的计算公式，这里本地计算就好了$softmax(\frac{QK}{\sqrt{n}}V)$

3.完成上述操作之后应该进行一个MLP的操作，通常来说使得需要一个完整的矩阵才能实现上述的一个计算，但是这里依旧是头部分开的状态，具体的操作如下：

image-20241015185228197

所以说可以拆开

上面的三个操作都是不需要彼此之间数据互通和数据依赖的，因此可以并行执行

image-20241015190039208
image-20241015190039208

在Transformer上述计算得到一个输出之后需要进行一个通讯（之后再说）。接下来是MLP的并行，实际上同样可以拆开进行并行。

具体分析是矩阵乘法的一些操作，不赘述了

image-20241015190114685
image-20241015190114685

接下来是序列并行的操作，对于每个token,LayerNorm是对每个token进行操作的，也因此可以进行序列并行，具体的就如图所示的划分。

image-20241015190436892
image-20241015190436892

这个7,8可以理解成map reduce操作了

对于7相当于是把数据进行求和划分，而对于操作8则是进行一个聚合从而把上个阶段的数据集合一下。

image-20241015191519791
image-20241015191519791

总之，相较于TP有着更好的效率，更小的通讯代价（理论上TP也需要上述两个通讯但是论文中实现的通讯原语比TP性能更加），相较于SP能提供资源优势。

Heterogeneity and Memory Aware Workload Planning

考虑到在实际情况下不同设备的内存不同甚至存在有些设备计算较慢而滞后的情况，需要进行合理的模型划分分配：

$$\begin{aligned}&\mathcal{L}(\mathsf{MHA},\mathcal{A})=\max_{d\in{0,1,\ldots,\mathcal{D}-1}}L(\mathsf{MHA},\mathcal{A}d,d),\&\mathcal{L}(\mathsf{MLP},\mathcal{B})=\max{d\in{0,1,\ldots,\mathcal{D}-1}}L(\mathsf{MLP},\mathcal{B}d,d),&\text{(4)}\&\mathcal{L}(\mathsf{CON},\mathcal{S})=\max{d\in{0,1,\ldots,\mathcal{D}-1}}L(\mathsf{CON},\mathcal{S}_d,d).\end{aligned}$$

d表示设备，ABS表示分配，L表示计算时间，所以一段推理的时间是由三个部分的落后者决定的。此外还要解决一下内存能不能放下的问题，因此整体的优化如下：

$$\begin{aligned} \min_{\mathcal{A},\mathcal{B},\mathcal{S}}\bigg(\mathcal{L}(\mathsf{MHA},\mathcal{A})+\mathcal{L}(\mathsf{MLP},\mathcal{B})+\mathcal{L}(\mathsf{CON},\mathcal{S})\bigg), \ \begin{aligned}\text{s.t.}\quad l\cdot(M_{att}\cdot\frac{a_d}{\sum\mathcal{A}}+M_{mlp}\cdot\frac{b_d}{\sum\mathcal{B}})<\text{Budget}_d,\end{aligned}&& \text{(5)} \ \mathrm{where~}d\in{0,1,\cdots\mathcal{D}-1}. \end{aligned}$$

M表示每个块需要的内存占用。通过基准数据来计算各个分区下的延迟。（这里还用了一些其他的方法来解决计算复杂的问题，不赘述了）

Tile-based Communication Optimization

通常来说，在8之前必须把数据全部聚合好才能进行下一步的矩阵乘法，但是这种情况很容易被一个客户端卡住，为此，论文实现了一个很巧妙的通讯方式：

image-20241015193724621

相较于直接对数据进行一个全局的聚合再分出去，这种方式可以把计算和通讯重叠起来从而实现通讯时间下降（这个操作可以借鉴一下）

image-20241015194014033
image-20241015194014033

同理，在进行数据划分也是类似的操作

实验

数据集：

  • GLUE： QNLI的子集

模型：

  • DistilBert
  • Bert-L
  • GPT2-L
  • OPT-L
  • OPT-XL

baseline：

  • TP Megatron-LM
  • SP

设备：

image-20241015194830604
image-20241015194830604

image-20241015194949664
image-20241015194949664

延迟上论文的方法会地一点，但是模型尺寸增加导致的hidden_size增加会影响延迟，客户端越多延迟也会降低。

image-20241015195213566
image-20241015195213566

分别是异构，延迟数据表，客户端数量对计算能力和计算延迟的影响，还有相较于Baseline的加速程度。

Licensed under CC BY-NC-SA 4.0