Zipeng Xie

> 关于 layernorm 位置的问题可以快速回复一下 > > 我们参考的是 megatron 的代码实现，关于残差的位置在 megatron lm 的 paper 里面有写这样一段话 > > > We further investigated this behavior and empirically demonstrated that rearranging the order of...

 记录了一下两种qkv的计算方法产生不同sbp的问题, @CPFLAME

> 我们推导了一下，发现对齐 huggingface 的写法会导致之前推导的 sbp 出现问题，因为 huggingface 的写法是先做 chunk，而且 chunk 的维度刚好的 sbp.split，这样切完中间隐含了一次通信开销，所以我们觉得这样做可能会带了更多别的问题，你考虑用之前开杰提供的方案试试呢。 > > [#146 (comment)](https://github.com/Oneflow-Inc/libai/issues/146#issuecomment-1054953921) 好的星宇,我看怎么可以正确加载权重后能够对齐

### 不改变模型，改变wieght的加载能得到相同的结果 由于我们已经证明了libai的qkv计算的正确性（换成huggingface的qkv计算导致模型并行时sbp会出问题，目前的解决办法只有直接进行to_global来解决这个问题，而且不知道会不会造成别的问题，也就是说libai中的整套模型的sbp方案是配好的，换成别的计算方式有问题），所以这里考虑用不同的weight加载方式。 两种qkv计算方式： ```python # LiBai中的qkv计算方式： # query_key_value：[batch_size, seq_len, 3*hidden_size] query_key_value = query_key_value.view(bsz, -1, self.num_heads, 3 * self.head_size) #(a) query_key_value = query_key_value.permute(0, 2, 1, 3) #(b) query, key, value...

bert的load_pretrain_weight后输出对齐了 ```python import oneflow as flow import libai from libai.models import build_model from libai.config import LazyCall from load_huggingface_weight import load_huggingface_bert from libai.utils import distributed as dist import transformers import torch...

- [x] libai.model.SwinTransformer -ZhangGuangjun（已经合并） - [x] libai.model.visionTransformer - ZhangGuangjun - huggingface Swin: https://huggingface.co/docs/transformers/v4.20.1/en/model_doc/swin#overview - huggingface Vit：https://huggingface.co/docs/transformers/v4.20.1/en/model_doc/vit#transformers.ViTForImageClassification 参考pr：https://github.com/Oneflow-Inc/libai/pull/284 参考issue：https://github.com/Oneflow-Inc/libai/issues/205 任务内容： - 增加vit和swin的LoadPretrainedModel（LoadPretrainedVit，LoadPretrainedSwin） - vit和swin的单测 @zhanggj821

```python from libai.config import LazyCall, instantiate from flowvision import transforms train_aug = LazyCall(transforms.Compose)( transforms=[ LazyCall(transforms.RandomResizedCrop)( size=(512, 1024), ) ] ) print(instantiate(train_aug)) # (oneflow-dev-gcc7-v2) xiezipeng@vs008:~/libai/xzp$ python test.py # loaded library: /lib/libibverbs.so.1...

> 我怎么感觉两个方案没什么大的区别，而且怎么解决了参数层层传递的问题，这个cfg不也是要层层传？ 呃，区别就是一个需要一个ModuleBase，一个不需要，解决结果就是只在目前的每个layer中传递一个cfg，其他的多出来的参数就不需要传递了，比如mlp中需要新增act、bias、dropout这3个参数的话就只需要加在cfg中，而不需要分别在mlp,transformer,bert中多加3个parameter的位置

然后huggingface是所有layer和model都只看的到config参数在传递，不利于用户复现模型，我们这个算一个折中？ 

> > > 我怎么感觉两个方案没什么大的区别，而且怎么解决了参数层层传递的问题，这个cfg不也是要层层传？ > > > > > > 呃，区别就是一个需要一个ModuleBase，一个不需要，解决结果就是只在目前的每个layer中传递一个cfg，其他的多出来的参数就不需要传递了，比如mlp中需要新增act、bias、dropout这3个参数的话就只需要加在cfg中，而不需要分别在mlp,transformer,bert中多加3个parameter的位置 > > 原来是这个意思，那是不是最后参数位置放一个 `**kwargs` 也能解决拓展参数的问题，用 `DictConfig` 有什么额外的好处么 就是libai的参数一般写在config文件里，所以放到cfg中传递比较好，**kwargs也可以，但是需要在模型中传？