diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.09.09~2024.09.23.md b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.09.09~2024.09.23.md new file mode 100644 index 00000000..602e1385 --- /dev/null +++ b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.09.09~2024.09.23.md @@ -0,0 +1,42 @@ +### 姓名 +郑天宇 + +### 实习项目 +自动并行在复杂模型结构下的能力摸底和技术储备 + +### 本周工作 + +1. **对自动并行及工作相关信息进行学习** + + * 学习了动态图，静态图组网，数据并行，张量并行，流水并行 + * 学习了如何使用docker部署paddle，编译，提交rfc、pr等流程 + + +2. **开发了load_state_dict_from_url API，并写了多个单测** + + * 为paddle.hub开发了新的加载 Paddle 序列化对象的API + * 可以通过URL下载并加载 Paddle 序列化对象 + * 可以通过URL下载并解压ZIP格式的模型权重文件，再加载 Paddle 序列化对象 + * 当权重文件存在时，可以直接加载 Paddle 序列化对象 + + +### 下周工作 + +1. 实现在组网时打印每路dp的loss +2. 离线aadiff检查 +3. 在线aadiff检查 +4. zero padding check + +### 导师点评 +郑天宇同学本周在实习项目中展现了良好的学习能力和开发能力。 +学习能力强：郑天宇同学在短时间内迅速学习了自动并行相关的知识，包括动态图、静态图组网、数据并行、张量并行和流水并行，这些内容是并行计算中的核心知识点，对学习自动并行打下了坚实的基础。 +技术掌握迅速：通过学习，郑天宇同学掌握了如何在docker中部署paddle，熟悉了编译、提交RFC和PR等流程，这些都是实际开发中非常重要的技能。 +开发效率高：本周内，郑天宇同学不仅学习了大量新知识，还开发了load_state_dict_from_url API，并编写了多个单元测试。这个功能对PaddleHub的易用性是一个很好的补充，能够提高用户从URL加载模型的便利性。 +计划明确：对于下周的工作，郑天宇同学已经有了清晰明确的计划，包括在组网时打印每路dp的loss、离线aadiff检查、在线aadiff检查和zero padding check，这些都是针对自动并行技术的重要调试和验证步骤。 + +后续建议： +深入理解原理：虽然郑天宇同学已经掌握了基本的概念和操作流程，但建议进一步深入理解自动并行的底层原理，这将有助于在实际项目中更好地解决可能遇到的问题。 +注重测试覆盖：在开发新功能时，确保单元测试能够覆盖尽可能多的场景，特别是边界条件和异常情况，以提高代码的健壮性。 +加强沟通：在实习过程中，遇到任何问题或不确定的地方，建议及时与导师或团队成员沟通，这不仅能更快地解决问题，还能促进知识的共享和团队的协作。 +文档撰写：对于开发的功能和遇到的问题，建议撰写详细的文档，这既能帮助自己回顾和总结，也能为后来的开发者提供有价值的参考。 +总体而言，郑天宇同学本周的表现非常出色，希望继续保持这种学习和工作的热情，相信在接下来的实习中会有更大的收获。 \ No newline at end of file diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.08~2024.10.21.md b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.08~2024.10.21.md new file mode 100644 index 00000000..a76d6728 --- /dev/null +++ b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.08~2024.10.21.md @@ -0,0 +1,31 @@ +### 姓名 +郑天宇 + +### 实习项目 +自动并行在复杂模型结构下的能力摸底和技术储备 + +### 本周工作 + +1. **在线aadiff检查** + + * 学习流水并行，其中主要了解1F1B,ZERO_BUBBLE,VPP的编排方式 + * 制定了1F1B编排方式下的aadiff_check方法 + + +### 下周工作 + +1. 研究如何在ZERO_BUBBLE,VPP编排方式下做aadiff_check +2. 研究他们的共同点，查看是否能采用抽象的方法，统一构建aadiff_check + +### 导师点评 +郑天宇同学本周在实习项目中继续展现了专业的学习能力和问题解决能力。 +深入学习流水并行：郑天宇同学本周专注于流水并行的学习，特别是1F1B、ZERO_BUBBLE、VPP等编排方式，这些都是流水并行中的关键技术。通过学习，郑天宇同学对流水并行的原理和应用有了更深入的理解。 +制定aadiff_check方法：基于学习的流水并行知识，郑天宇同学制定了1F1B编排方式下的aadiff_check方法。这是一个重要的技术贡献，因为aadiff_check是验证自动并行正确性的关键步骤。 +计划明确且有针对性：对于下周的工作，郑天宇同学已经制定了明确且有针对性的计划，包括研究ZERO_BUBBLE和VPP编排方式下的aadiff_check，以及探索这些编排方式的共同点，以尝试采用抽象方法统一构建aadiff_check。这些计划都紧密围绕实习项目的核心目标展开。 + +建议： +加强实践验证：在制定aadiff_check方法后，建议通过实际案例进行验证，确保方法的正确性和有效性。这有助于提升郑天宇同学对自动并行技术的理解和掌握程度。 +注重总结归纳：在学习和研究过程中，建议郑天宇同学注重总结归纳，将学到的知识和经验形成文档或笔记。这不仅有助于自己回顾和复习，也能为后来的学习者提供有价值的参考。 +探索创新点：在研究ZERO_BUBBLE和VPP编排方式下的aadiff_check时，建议郑天宇同学积极探索创新点，尝试提出新的思路和方法，以提升自动并行技术的效率和准确性。 +保持与导师的沟通：在研究过程中，如果遇到任何问题或不确定的地方，建议郑天宇同学及时与导师沟通，寻求帮助和建议。这有助于更快地解决问题，确保研究工作的顺利进行。 +总体而言，郑天宇同学本周的表现非常出色，展现出了扎实的专业知识和良好的学习能力。相信在接下来的实习中，郑天宇同学将继续保持这种积极的学习态度和工作精神，取得更大的进步和成果。 \ No newline at end of file diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.22~2024.11.1.md b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.22~2024.11.1.md new file mode 100644 index 00000000..2a8182cf --- /dev/null +++ b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.22~2024.11.1.md @@ -0,0 +1,20 @@ +### 姓名 +郑天宇 + +### 实习项目 +自动并行在复杂模型结构下的能力摸底和技术储备 + +### 本周工作 + +1. **在线aadiff检查** + + * 了解pir_pass.py、distributed>auto_parallel>static>utils.py、distributed>parallel.py等代码，思考aadiff_check的开发位置 + * 继续了解VPP的编排方式 + + +### 下周工作 + +1. 开始开发aadiff_check的代码 +2. 测试开发的aadiff_check的基础部分代码 + +### 导师点评 \ No newline at end of file diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.28~2024.11.22.md b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.28~2024.11.22.md new file mode 100644 index 00000000..1a9e3fb3 --- /dev/null +++ b/WeeklyReports/Hackathon_7th/08_zty-king/[WeeklyReports]2024.10.28~2024.11.22.md @@ -0,0 +1,21 @@ +### 姓名 +郑天宇 + +### 实习项目 +自动并行在复杂模型结构下的能力摸底和技术储备 + +### 本周工作 + +1. **非均衡切分vpp** + + * 跑通llama模型，了解各个重要的输出信息 + * 验证micro_batch和pp_degree不为整数倍时是否会出错 + * 根据报错调整流水并行vpp模式下的编排代码，使其支持非均衡切分vpp + + +### 下周工作 + +1. 完善支持非均衡切分vpp的代码 +2. vpp去尾工作支持 +3. 局部pipeline支持 + diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/aadiff\346\243\200\346\237\245_2021.10.25.md" "b/WeeklyReports/Hackathon_7th/08_zty-king/aadiff\346\243\200\346\237\245_2021.10.25.md" new file mode 100644 index 00000000..570083b6 --- /dev/null +++ "b/WeeklyReports/Hackathon_7th/08_zty-king/aadiff\346\243\200\346\237\245_2021.10.25.md" @@ -0,0 +1,95 @@ +# Pipelin Parallel学习记载 + +## 1.流水线并行PP评价指标 + +流水并行（Pipeline Parallelism，PP）中，针对流水并行（PP）假设并行的stage 切分为p 份，micro-batches 为m，每个micro-batches 的前向和后向执行时间为tf 和tb。在理想的环境下，前向和后向的合起来理想的执行时间应该是（图1解释下列公式原因，）： +$$ +t_{ideal}=m(tf+tb) +$$ +不过在实际 Pipeline 把网络模型切分成不同 stage（**stage指的是模型的不同阶段**） 放在不同的机器，会导致在正向的 p - 1 和反向的 p – 1 时间内会出现计算等待时间。那这个中间空白的地方，我们叫做 Bubble 空泡。 + +而空泡 Bubble 的产生，是因为算子内并行和算子间并行解决单设备内存不足的问题，模型经过拆分后的上一个 rank 的 stage 需要长期持续处于空闲状态，等待 其他 rank 的 stage 计算完成，才可以开始计算，这极大降低了设备的平均使用率。这种现象被称为**并行空泡（Parallelism Bubble**）。 + +![image-20241025002541833](images/图1.png) + +
图1
+ +总的 bubble 占用的时间跟流水并行 PP 切分策略相关（看图2，这里的p-1与bubble产生的原因有关，可以看到，在前向传播的时候，最开始时，每个stage的计算要等待前一个计算的结果，因此，从时间线上看（横轴），最终会多出p-1个前向时钟周期，即每多一个stage，就多一个前向时钟周期，因此，当stage为p时，就多出p-1个前向时钟周期）： +$$ +t_{bubble}=(p-1)(tf+tb) +$$ +![image-20241025002636784](images/图2.png) + +
图2
+ +## 2.流水并行1F1B编排模式 + +### 2.1 1F1B编排模式解读 + +![image-20241024155644457](images/图3.png) + +
图3
+ + 1F1B 示例如图所示，以 GPU3 的 F1（GPU3 的第 2 个 micro-batch 的前向计算）为例，F1 在计算前，F1 的反向 B1（GPU3 的第 1 个 micro-batch 的反向计算）已经计算结束，即可释放 F1 的中间变量，从而 F2 可以复用 F1 中间变量的显存。**释放不必要的中间变量，峰值显存下降，设备资源利用率显著提升，但bubble数没变** + + + +### 2.2 分析1F1B中bubble来源 + + 为了在bubble中添加check操作，来检查forward是否正常进行，首先需要分析bubble是如何产生的，才能知道在哪里会产生bubble，以及什么会影响到bubble的个数 + +​ **1.设备数与num_micro_batches数确定时，分析时序图是否唯一** + +​ 当设备数为4个，num_micro_batches为4时分析理想1f1b和非理想1f1b两种情况的时序图： + +![image-20241024224556795](images/非理想1f1b时序图.png) + +
非理想1f1b时序图
+ +![image-20241024223821441](images/理想1f1b时序图.png) + +
理想1f1b时序图
+ +​ **分析结果：** + +​ 从上面两个图可以看到，同样采用1f1b的思想，即当一个micro_batche的forward部分做完就立刻做其backward，并且对于每一个设备来说，他们的job顺序都没有改变——举个例子，1F1B在编排时，会产生对于GPU1来说，在**warmup阶段**会编排warmup_num=pp_degree(纯pp下，使用的设备数)-pp_stage(纯pp下，设备编号)，对于GPU1来说，就是4-1=3，即先编排3个foward，对应图中的1，2，3；接着在**Stabilization阶段**会编排num_micro_batches-warmup_num个1F1B，对应GPU1来说就是4-3=1，即编排1组连续的FB；最后**warmdown阶段**因为foward部分做完了，所以对应的，还需要编排warmup_num个backword。可以看到非理想的1f1b下，每个设备的job顺序也是按照这个来排列的，但是job发生的时间有所不同。 + +​ 分析可知，虽然时序图不唯一，但是我们可以发现，两种时序图对应的最终计算结果是一致的，因此我们想要在bubble时期插入操作，则强制让其按理想的1f1b时序图来执行即可，例如在GPU1的第三个forward后面插入3个周期的check操作。 + + + +​ **2.设备数与num_micro_batches数确定时，forward和backward时钟周期不一致，分析1F1B时序图变化** + +![image-20241024231404936](images/backward为2个时钟周期时序图.png) + +
backward为2个时钟周期时序图
+ +​ **分析结果：** + +​ 分析可知，此时bubble的个数变多了，每个设备上的bubble数，从原来的6个变成了9个，从bubble产生的原因可知，是因为前向产生了3个forward的等待，后向产生了3个backward的等待，因此产生的bubble数为`3*t_f+3*t_b`，该公式对于任意的forward和backward的时钟周期都成立，因此也可以将其用数学公式规律化。 + + + +### 2.3 分析1F1B中bubble_check插入位置 + +![image-20241024233326719](images/bubble_check插入位置分段分析图.png) + +
bubble_check插入位置分段分析
+ +​ 观察上图，与理想1f1b时序图有些差别，但是对比两图可以发现，同样满足1F1B的编排方式，因为1F1B的编排可分为3个阶段，**warmup阶段**、**Stabilization阶段**、**warmdown阶段（自己编的名字）**而此时bubble_check的插入位置即可表示如下： + + 1. 在**warmup阶段**，在原来排列好的job前，插入`pp_stage-1`个bubble_check + + 2. 在**Stabilization阶段**，在原来排列好的job前和后，分别插入`pp_degree-pp_stage`个bubble_check + + 3. 在最后的**warmdown阶段**，在原来排列好的job后面，插入`pp_stage-1`个bubble_check + + + +**再考虑一种num_micro_batches>pp_degree** + +![image-20241025000830757](images/num_micro_batches>pp_degree时bubble_check插入位置分析图.png) + +
num_micro_batches>pp_degree时bubble_check插入位置分析
+ +可以看到，规律还是如上公式所示。 \ No newline at end of file diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/backward\344\270\2722\344\270\252\346\227\266\351\222\237\345\221\250\346\234\237\346\227\266\345\272\217\345\233\276.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/backward\344\270\2722\344\270\252\346\227\266\351\222\237\345\221\250\346\234\237\346\227\266\345\272\217\345\233\276.png" new file mode 100644 index 00000000..8ed0d3aa Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/backward\344\270\2722\344\270\252\346\227\266\351\222\237\345\221\250\346\234\237\346\227\266\345\272\217\345\233\276.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/bubble_check\346\217\222\345\205\245\344\275\215\347\275\256\345\210\206\346\256\265\345\210\206\346\236\220\345\233\276.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/bubble_check\346\217\222\345\205\245\344\275\215\347\275\256\345\210\206\346\256\265\345\210\206\346\236\220\345\233\276.png" new file mode 100644 index 00000000..0d53fe62 Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/bubble_check\346\217\222\345\205\245\344\275\215\347\275\256\345\210\206\346\256\265\345\210\206\346\236\220\345\233\276.png" differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225328417.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225328417.png new file mode 100644 index 00000000..c6cfd7d4 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225328417.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225506353.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225506353.png new file mode 100644 index 00000000..ec0dc180 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225506353.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225559015.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225559015.png new file mode 100644 index 00000000..debb60a5 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123225559015.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123230953781.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123230953781.png new file mode 100644 index 00000000..ed844cb4 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123230953781.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123232840181.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123232840181.png new file mode 100644 index 00000000..b59d02ee Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241123232840181.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124103722524.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124103722524.png new file mode 100644 index 00000000..7fae3d4a Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124103722524.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124111004558.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124111004558.png new file mode 100644 index 00000000..f80b3db6 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124111004558.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124112056125.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124112056125.png new file mode 100644 index 00000000..b0b997da Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124112056125.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124113523802.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124113523802.png new file mode 100644 index 00000000..05bbab5d Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124113523802.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124114209209.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124114209209.png new file mode 100644 index 00000000..1d97e7d2 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124114209209.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124114441312.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124114441312.png new file mode 100644 index 00000000..3c125f4b Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124114441312.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115253020.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115253020.png new file mode 100644 index 00000000..b9bf3965 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115253020.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115829008.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115829008.png new file mode 100644 index 00000000..be4334b7 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115829008.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115904947.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115904947.png new file mode 100644 index 00000000..a29e3120 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124115904947.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124141649721.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124141649721.png new file mode 100644 index 00000000..e9f4424f Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124141649721.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124144220992.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124144220992.png new file mode 100644 index 00000000..1cfd9cc9 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124144220992.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124145032346.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124145032346.png new file mode 100644 index 00000000..d568a174 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124145032346.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124145113551.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124145113551.png new file mode 100644 index 00000000..213079ef Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124145113551.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124160839318.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124160839318.png new file mode 100644 index 00000000..786f5bae Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124160839318.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124161359887.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124161359887.png new file mode 100644 index 00000000..115003f6 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124161359887.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124175210563.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124175210563.png new file mode 100644 index 00000000..578d42de Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124175210563.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124180222897.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124180222897.png new file mode 100644 index 00000000..1e5f3312 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124180222897.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124215059155.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124215059155.png new file mode 100644 index 00000000..64224fef Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124215059155.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124230509006.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124230509006.png new file mode 100644 index 00000000..4cc11d22 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241124230509006.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241125001507875.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241125001507875.png new file mode 100644 index 00000000..e0017a87 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241125001507875.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241125001534796.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241125001534796.png new file mode 100644 index 00000000..2daea8c2 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241125001534796.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202049863.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202049863.png new file mode 100644 index 00000000..9f03d30b Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202049863.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202121386.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202121386.png new file mode 100644 index 00000000..9eee95a7 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202121386.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202134910.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202134910.png new file mode 100644 index 00000000..46e4ea83 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202134910.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202208364.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202208364.png new file mode 100644 index 00000000..966e6a94 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202208364.png differ diff --git a/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202512056.png b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202512056.png new file mode 100644 index 00000000..4d1387d5 Binary files /dev/null and b/WeeklyReports/Hackathon_7th/08_zty-king/images/image-20241127202512056.png differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/num_micro_batches>pp_degree\346\227\266bubble_check\346\217\222\345\205\245\344\275\215\347\275\256\345\210\206\346\236\220\345\233\276.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/num_micro_batches>pp_degree\346\227\266bubble_check\346\217\222\345\205\245\344\275\215\347\275\256\345\210\206\346\236\220\345\233\276.png" new file mode 100644 index 00000000..2aca45bb Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/num_micro_batches>pp_degree\346\227\266bubble_check\346\217\222\345\205\245\344\275\215\347\275\256\345\210\206\346\236\220\345\233\276.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2761.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2761.png" new file mode 100644 index 00000000..def86df8 Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2761.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2762.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2762.png" new file mode 100644 index 00000000..a55e44e6 Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2762.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2763.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2763.png" new file mode 100644 index 00000000..94c02067 Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\345\233\2763.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/\347\220\206\346\203\2631f1b\346\227\266\345\272\217\345\233\276.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\347\220\206\346\203\2631f1b\346\227\266\345\272\217\345\233\276.png" new file mode 100644 index 00000000..893a12ae Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\347\220\206\346\203\2631f1b\346\227\266\345\272\217\345\233\276.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/images/\351\235\236\347\220\206\346\203\2631f1b\346\227\266\345\272\217\345\233\276.png" "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\351\235\236\347\220\206\346\203\2631f1b\346\227\266\345\272\217\345\233\276.png" new file mode 100644 index 00000000..9a321561 Binary files /dev/null and "b/WeeklyReports/Hackathon_7th/08_zty-king/images/\351\235\236\347\220\206\346\203\2631f1b\346\227\266\345\272\217\345\233\276.png" differ diff --git "a/WeeklyReports/Hackathon_7th/08_zty-king/\351\235\236\345\235\207\350\241\241vpp\345\210\207\345\210\206_2024.11.29.md" "b/WeeklyReports/Hackathon_7th/08_zty-king/\351\235\236\345\235\207\350\241\241vpp\345\210\207\345\210\206_2024.11.29.md" new file mode 100644 index 00000000..d96417a2 --- /dev/null +++ "b/WeeklyReports/Hackathon_7th/08_zty-king/\351\235\236\345\235\207\350\241\241vpp\345\210\207\345\210\206_2024.11.29.md" @@ -0,0 +1,314 @@ +# vpp非均匀切分任务 + +## 1.寻找num_micro_batches具体是外部什么参数 + +num_micro_batches为： + +在PipelinePass类中的def _task_1f1b(self):中定义的self._program.pipeline_opt + +![image-20241123230953781](images/image-20241123230953781.png) + +![image-20241123225559015](images/image-20241123225559015.png) + +也就是梯度累加的步数，其实就是micro_batches的数目 + + + +## 2.当前源码参考 + +#### 2.1 当前的限制条件 + +发现vpp代码中含有acc_step和pp_degree是否整除关系的检查 + +![image-20241123232840181](images/image-20241123232840181.png) + +这里的整除式： +$$ +accumulate\_steps\ \% \ num\_stages == 0 +$$ +表明了一个观点，因为`accumulate_steps`和`num_stages`均是大于0的数，因此当前的限制为accumulate_steps必须为num_stages的整数倍，因此为了加入非均匀vpp，我们需要弱化此处的强约束条件，改为以下条件： +$$ +accumulate\_steps \geq num\_stages +$$ +而分析整除式，可以发现，原来的整除式子，也包含了accumulate_steps和num_stages满足以上关系，但是此时，无需让acc_steps为pp_degree的整数倍，因此我们将条件做到了弱化处理。 + + + +#### 2.2 代码优化部分 + +![image-20241124111004558](images/image-20241124111004558.png) + +分析发现，在整除关系下，这里无需判断两者相等的情况，else对应的公式均适用于所有倍数的情况，下面会给出证明。 + + + +## 3.均匀vpp排列分析 + +为了编排非均匀vpp，我们首先要观察一下均匀vpp的排列方式 + +#### 3.1 各阶段Step分析 + +##### 3.1.1 `accumulate_steps % num_stages`且 `accumulate_steps ！= num_stages` + +![image-20241124144220992](images/image-20241124144220992.png) + +这里我们选择`num_stages`为4，而`accumulate_steps`为4，`hidden_layer`为8，`vpp_degree（num_model_chunks）`为2进行分析： + +​ 因为`vpp`是基于`1F1B`的编排，因此我们同样可以用相同的规律把中间的稳定阶段先选择出来，即`1F1B`的阶段，我没有按照论文里的图来画，但也遵循了排列规则，并且将其画成了对称的形式，这样可以更直观的感受（也为了后面做`aadiff_check`做准备），可以看到，具体情况如上面的黄色框图所示，能够发现此时对于每一个`GPU`来说，编排仍然是呈现对称关系，例如`GPU1`就是左边10个`forward`，右边10个`forward`，中间是几组`1F1B`，那么根据规律我们可以发现，每个设备对应的编排公式如下： + +1. 计算 `warmup_steps` 的初始值： + +$$ +\text{warmup\_steps} = (\text{num\_stages} - \text{stage\_id} - 1) + (\text{num\_stages} - \text{stage\_id} - 1) +$$ + +​ 2.更新 `warmup_steps`： +$$ +\text{warmup\_steps} += (\text{num\_model\_chunks} - 1) \times \text{num\_stages} +$$ +​ 3.计算`steady_steps`: +$$ +total\_num\_steps = accumulate\_steps * num\_model\_chunks +$$ + +$$ +steady\_steps = total\_num\_steps - warmup\_steps +$$ + + + +​ 第3个式子很好理解，由前面知道关系`accumulate_steps>=num_stages`，梯度累加的步数`accumulate_steps`就为`micro_bitch`的数量，对于一个设备来说，要经历的`step`数（forward和backward看为一个step）为`micro_bitch`的数量*该设备上模型的层数（因为每个`micro_bitch`一定会经过这些层），所以得到`total_num_steps`公式如上，而除掉warm_up阶段和尾部的cool_down阶段相对应的f_b个数，剩下的就是在stable阶段进行的f_b个数，所以得到`steady_steps`的公式。 + +​ 那么我们详细来分析一下，1、2两个式子的含义： + +​ 首先，我们需要先分析一下，什么时候能开始我们的stable阶段，也就是稳定的1F1B阶段，我们可以直接看下面这个图： + +![image-20241124113523802](images/image-20241124113523802.png) + +![image-20241124145113551](images/image-20241124145113551.png) + +​ 我们将模型分成了2个大块，并且，每个大块分为了4个小块，第一个大块的4个小块分别放在`GPU1-4`上，第二个大块的4个小块紧接着放在`GPU1-4`上，不难发现，我们的一个`micro_batch`执行的顺序是从`GPU1->GUP4`再返回到`GPU1`，再依次执行到`GPU4`，那么可以发现，我们最早能执行`backward`的时间在第一个`micro_bitch`执行了8层的`forward`之后，即对应上图中的蓝色箭头的位置，此时可以看到我们的第一个`micro_bitch`已经执行了8个`forward`，因此可以开始执行`backward`了，所以`stable`阶段的启动时间就是此刻。 + +​ 那么我们可以看到，第一个出现的`1F1B`就是蓝色箭头左边的`forward`和蓝色箭头右边的`backward`，而执行这对`1F1B`之前，`GPU4`还需要执行1，2，3，4 `micro_batch`在该设备第一个块中的`forward`，原因是，第一个`micro_batch`执行完了第一个大块的4个小块的`forward`因此又要从GPU1-GPU4执行第二个大块的4个小块的`forward`，因此此时为了让设备不空闲，在等待第一个`micro_batch`执行的同时，我们同时执行了第2，3，4个`micro_batch`在GPU4上第一个块的forward，再加上第一个`micro_batch`的第一块的forward，在`1F1B`共执行了4个forward。 + +​ 那么我们分析一下，这个forward的个数与什么有关？ + +​ 由上述原理可知，我们除了GPU4处理的第一个`micro_batch`的forward，我们是在等待第一个`micro_batch`再次到达GPU4时处理了其它的`micro_batch`，因此，该forward个数为`(1+pp_dgree-1)*(num_model_chunks-1)`,这里的`num_model_chunks-1`也很容易理解，如果模型被分为n大块，那么第一个`micro_batch`就只能在第n次达到最后一个GPU时，才能开始执行backward，所以前面一定执行了`（n-1）`轮的`（1+pp_dgree-1）`，又因为最后一个设备执行了 + +`(1+pp_dgree-1)*(num_model_chunks-1)`个forward，那么一定每个设备都执行了`(1+pp_dgree-1)*(num_model_chunks-1)`个forward，所以我们能推出，每个设备在进入stable阶段之前，至少一定有`(1+pp_dgree-1)*(num_model_chunks-1)`个forwad，这就是`公式2`中我们所加的`(num_model_chunks-1)*num_stages`。 + +​ 解释完了公式2，我们再来看看公式1的两个(num_stages - stage_id - 1)是如何产生的呢？ + +​ 首先第一个`(num_stages - stage_id - 1)`为什么会出现，我们要考虑到，在流水并行刚刚启动的时候，`GPU1`会先处理第一个`micro_batch`，然而，可以发现`GPU2-GPU4`此时是完全空闲的状态，因此，说明`GPU1`比其它设备要多处理一个`micro_batch`，其它设备以此类推，因此对于最后一个gpu来说，第一个设备`GPU1`比它多处理的`forward`个数为`（pp_degree-(pp_stage+1)）`,`pp_stage`从0号开始，也就是我们公式中出现的`(num_stages - stage_id - 1)`，第二、三个设备同样满足该公式，因此每个设备多处理的`forward`个数为`(num_stages - stage_id - 1)`，可以看到最后一个设备该数值是0，因为它比任何设备执行都慢，因此不会比其它设备多执行`forward`。 + +​ 其次是第二个`(num_stages - stage_id - 1)`为什么会出现，我们考虑到，GPU4最先进入1F1B，而第一个backward从最后一个设备到达第一个设备的时钟周期个数为`（pp_degree-(pp_stage+1)）`,从最后一个设别到达第二、三个设别的时钟周期也满足这个式子，而在这第一个执行的`backward`到达之前，设备没办法执行`backward`，那么它们就无法进入1F1B的状态，因此仍然处于`warmup`阶段执行对应个数的`forward`，直到第一个`backward`到达才进入stable阶段，因此每个设备在进入stable阶段之前就会再多执行`(num_stages - stage_id - 1)`个`forward`。可以看到最后一个设备该数值是0，因为它立刻执行`backward`不会等待，因此没有多执行的`forward`。 + +​ 所以我们将每个设备在进入stable阶段执行的forward加起来，就是warmup_steps的个数，即`(num_stages - stage_id - 1)+(num_stages - stage_id - 1)+(num_model_chunks-1)*num_stages`得到最终的公式——公式1，公式2。 + +##### 3.1.2 `accumulate_steps == num_stages` + +​ 接下来我们分析两个数相同时，上述式子是否成立，这里我们为了数据多样化，我们选择`num_stages`为3，而`accumulate_steps`为3，`hidden_layer`为9，`vpp_degree（num_model_chunks）`为3进行分析： + +![image-20241124145032346](images/image-20241124145032346.png) + +​ 可以看到，图中`GPU1`没有1F1B阶段，`GPU2`有一对1F1B，`GPU3`有3对1F1B，我们同样用以下三个式子做分析： + +1. 计算 `warmup_steps` 的初始值： + +$$ +\text{warmup\_steps} = (\text{num\_stages} - \text{stage\_id} - 1) + (\text{num\_stages} - \text{stage\_id} - 1) +$$ + +​ 2.更新 `warmup_steps`： +$$ +\text{warmup\_steps} += (\text{num\_model\_chunks} - 1) \times \text{num\_stages} +$$ +​ 3.计算`steady_steps`: +$$ +total\_num\_steps = accumulate\_steps * num\_model\_chunks +$$ + +$$ +steady\_steps = total\_num\_steps - warmup\_steps +$$ + +我们从`GPU3`开始带入，得到如下结果： + +1. +$$ +\text{warmup\_steps} =(3-2-1)+(3-2-1)=0 +$$ +2. +$$ +\text{warmup\_steps} = 0 + (\text{3} - 1) \times \text{3}=6 +$$ +3. +$$ +total\_num\_steps = 3*3 = 9 +$$ + +$$ +steady\_steps = 9-6=3 +$$ + +我们可以看到，跟结果是一样的，我们带入`GPU2`的数值，同样符合，但是我们再带入GPU1的数值： + +1. +$$ +\text{warmup\_steps} =(3-0-1)+(3-0-1)=4 +$$ +2. +$$ +\text{warmup\_steps} = 4 + (\text{3} - 1) \times \text{3}=10 +$$ +3. +$$ +total\_num\_steps = 3*3 = 9 +$$ + +$$ +steady\_steps = 9-10=-1 +$$ + +我们观察上图可以发现，此时`warmup_steps`并不为10，而且`steady_steps`也成了负数，那么是什么原因造成的呢，我们分析如下： + +首先，由公式2的由来可是，每个设备都满足，所以有6个`step`是一定没问题的，那么问题就出现在公式1上面，我们前面分析知道，公式1的产生有两点： + +1. 设备号小的设备放置的模型层号也较小，因此要优先处理`micro_batch`，因此在`num_micro_batches>=pp_degree`时，条件1产生的`step`一定成立 +2. 又由于反向传播从设备号最大的设备开始，而此时设备号低的设备为了让设备空闲可以继续处理后续的`micro_batches`，但此时就需要注意一个问题，如果`num_micro_batches`没那么大，即满足如下关系式： + +$$ +\text{num\_micro\_batches} \times \text{num\_model\_chunks} < (\text{num\_model\_chunks} - 1) \times \text{num\_stages} + (\text{num\_stages} - \text{stage\_id} - 1) + (\text{num\_stages} - \text{stage\_id} - 1) +$$ + +​ 我们知道在我们规定的条件下，上式右边的第1、2项一定满足，而第三项就会因为设备号低的设备还没等到第一个backward，已经处理完所有的`micro_batch的forward`了，条件2式子（即第三项加数不成立) + +那么此时的warmup_steps我们也可以轻易地看出来，其实就是total_num_steps，因此为了保证公式的一致性，我们只需要多加一个条件即可，第三个公式如下： + +4.修正`warmup_steps`: +$$ +\text{warmup\_steps} = \min(\text{warmup\_steps}, \text{total\_num\_steps}) +$$ +这样这4个式子就清晰地展现了均匀vpp各阶段的step数。 + +#### 3.2 对于单个设备的编号编排分析 + +![image-20241124144220992](images/image-20241124144220992.png) + +​ 基于各阶段`step`的分析，我们继续分析可以发现，我们仅看某一个设备，则它对于每个设备上计算不同层的`micro_batch`编号的排列遵循以下公式： + +`forward`排列，其中`micro_step`的范围为`(0，acc_step *num_model_chunks )`： +$$ +\text{virtual\_pp\_stage} = \text{micro\_step} \mod ( \text{num\_stages} \times \text{num\_model\_chunks} ) +$$ + +$$ +\text{virtual\_pp\_stage} = \left\lfloor \frac{\text{virtual\_pp\_stage}}{\text{num\_stages}} \right\rfloor +$$ + +​ 将`vpp_stage`带入计算得到对应的实际步数 + +```python +def _record_fwd_micro_step(self, virtual_pp_rank): + real_micro_step = self._forward_micro_step_counter[virtual_pp_rank] + self._forward_micro_step_counter[virtual_pp_rank] += 1 + return real_micro_step +``` + + + +​ 因为`backward`与`forward`刚好相反，因此其`vpp_stage`要再加上下面这个公式： +$$ +\text{virtual\_pp\_stage} = \text{num\_model\_chunks} - \text{virtual\_pp\_stage} - 1 +$$ +​ 从上面我们也可以看到，其实确定最终`real_micro_step `，即所编排forward任务的实际ID，主要是对`vpp_stage`的编排,因此我们重点分析`vpp_stage`公式是怎么来的,首先我们要明确一点的是，论文的编排思想是——（因为`forward`和`backward`具有对称性，因此我们只看`forward`）对某个设备来说，每编排`pp_degree`个就切换到模型下一层，其实这样非常符合我们的流水并行的特点，我们可以再来看一眼下面这个图： + +![image-20241124113523802](images/image-20241124113523802.png) + +​ 因为经过`pp_degree`个时钟周期后，我们第`i`次输入进去的`micro_batch`就可以进行第`i+1`层的`forward`，所以排列是按照每`pp_degree`个就切换到模型下一层进行排列的，又因为，总模型块数为：`num_model_chunks*pp_degree`，即一个`micro_batch`走完每一块模型（即后面提到的一轮）要走这么多`step`，所以用当前的`micro_step`对其求余数，可以知道当前`micro_batch`处于这一轮的第几个位置，再用得到的相对位置，对`pp_degree`做整除运算向下取整，即可得到当前的micro_step属于的模型大块块号（即在哪一大块上执行），从0开始记录，每记录一个就会将对应数值+1，最终得到图示的编排效果（图示从1开始记录）。 + +## 4.非均匀vpp排列分析 + +我们现在将条件修改为`accumulate_steps>=num_stages`而不在让其为倍数关系，并进行分析 + +### 4.1 第一种情况： + +这里我们选择`num_stages`为4，而`accumulate_steps`为9，`hidden_layer`为8，`vpp_degree（num_model_chunks）`为2进行分析 + +排列1：（论文方法排列）： + +![image-20241127202049863](images/image-20241127202049863.png) + +#### 4.1.1 各阶段Step分析 + +​ 我们首先分析，以下4个式子是否满足各阶段stpe的编排： + +1. 计算 `warmup_steps` 的初始值： + +$$ +\text{warmup\_steps} = (\text{num\_stages} - \text{stage\_id} - 1) + (\text{num\_stages} - \text{stage\_id} - 1) +$$ + +​ 2.更新 `warmup_steps`： +$$ +\text{warmup\_steps} += (\text{num\_model\_chunks} - 1) \times \text{num\_stages} +$$ +​ 3.计算`steady_steps`: +$$ +total\_num\_steps = accumulate\_steps * num\_model\_chunks +$$ + +$$ +steady\_steps = total\_num\_steps - warmup\_steps +$$ + +​ 4.修正`warmup_steps`: +$$ +\text{warmup\_steps} = \min(\text{warmup\_steps}, \text{total\_num\_steps}) +$$ +​ 分析可知，同样成立，例如：`GPU1`的`warmup_steps`计算出来为`3+3+4=10`，则`steady_steps`为`9*2-10=8`,由图可知符合。因此可知，以这4个式子对于`warm_up`和`stable`的`step`个数，对于`均匀与非均匀vpp`的编排都是成立的。 + +#### 4.1.2 各阶段单个设备的编号编排分析 + +​ 其次我们分析编号编排，是否同样满足之前的公式： + + +$$ +\text{virtual\_pp\_stage} = \text{micro\_step} \mod ( \text{num\_stages} \times \text{num\_model\_chunks} ) +$$ + +$$ +\text{virtual\_pp\_stage} = \left\lfloor \frac{\text{virtual\_pp\_stage}}{\text{num\_stages}} \right\rfloor +$$ + +​ 这里我首先给出结论，公式不再满足，需要做变动，其实我们通过公式的来历即可知道，如果继续按照上式求解，那么就会出现，最终余数部分，通过上式计算后，第一步得到的结果，小于`pp_dgree`的均设置为第0块，大于等于`pp_dgree`，小于`pp_dgree*2`的均设置为第1块。然而我们分析一个具体的例子。 + +![image-20241127202134910](images/image-20241127202134910.png) + +​ 上图可以看到，`forward`总步数为`2*9=18`，也就是9个`micro`分别在`GPU1`中的两块模型中进行`forward`，前16步计算的实际`vpp_stage`没问题，但是第17，18步即micro_step为16，17若按上式计算（step从0开始），则最终的`vpp_stage` 均为0，也就是最后的两步均为在模型第0块执行的`forward`，而看图可知，显然不对，应该是一个在第0块，一个在第1块。 + +​ 因此我们提出以下改进： + +``` + remainder = accumulate_steps % num_stages + virtual_pp_stage = micro_step % (num_stages * num_model_chunks) + if micro_step <= (accumulate_steps // num_stages)*(num_stages * num_model_chunks): + virtual_pp_stage = virtual_pp_stage // num_stages + else: + virtual_pp_stage = virtual_pp_stage // remainder + if not forward: + virtual_pp_stage = num_model_chunks - virtual_pp_stage - 1 + return virtual_pp_stage +``` + +​ 我们分析知道了，造成错误的原因是余数部分，因此我们将余数单独处理，即`else`部分，令`remainder`为`acc_step mod pp_degree`，可以看到此时多出来的几个step其实就是以`remainder`为基，以`num_model_chunks`为倍数进行扩张的数据集，而这个扩张后的数据集以`remainder`为基，被分别分到每个`chunk`中，因此这里对`remainder`进行整除预算即可。 + + +### 4.2 第二种情况： + +​ 这里我们选择`num_stages`为4，而`accumulate_steps`为5，`hidden_layer`为8，`vpp_degree（num_model_chunks）`为2进行分析，我们不再做其它分析，因为我已经经过多种情况的验算过，Step的分析和设备编排各forward编号的分析，此处仅仅分析非均匀vpp的优化是否具有普遍现象： + +排列1：（论文方法排列）： + +![image-20241127202512056](images/image-20241127202512056.png) +