更新 req.txt（追加 v1.5 尾轮方案 B 广义化需求）

BMM/req.txt

@@ -1,4 +1,94 @@
 
+《BMM尾轮处理策略对比分析_v1.4》文档还需要优化，尤其在 “五、周长型主导完整推导”中
+1、 在“5.4 数值实例”中说的“例 4（周长型、Batch 与 C 互素的极端整除代价）” 这个对比对于方案B显然有些不公平，真正方案B也不会设计的这么不合理，也不是必须每轮每个核都要用起来，否则这个整除的约束太强了，可以允许尾轮只用到80%的核，但是切分还是所有分块都要重新切分，所有分块都改成新的SingleCoreM、SingleCoreN；请基于这个假设全面审视、重新公式推导、分析对比
+这是一个复杂任务，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《BMM尾轮处理策略对比分析_v1.4》文档增量修改完善写出《BMM尾轮处理策略对比分析_v1.5》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析文件，不要动别的文件；本req.txt文件也应该同步到代码仓的BMM文件夹下
+
+-------------------------------------------
+《BMM尾轮处理策略对比分析_v1.3》文档还需要优化，
+1、你在“七、方案 B 的简化形态 B1 与 B0/B1 相对 A1b 的损失分析”中常说“方案 B 常不可行”，这样说法是不合适的，我看了你的推导逻辑，无非是因为不能整除而产生冗余浪费的问题，这个不能叫不可行，这就是这个方案B的问题，这些场景case，你要给出方案B所能达到的最优性能，然后按公式逻辑推理并分析它与方案A1b的损失是多少
+这是一个复杂任务，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《BMM尾轮处理策略对比分析_v1.3》文档增量修改完善写出《BMM尾轮处理策略对比分析_v1.4》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析文件，不要动别的文件
+-------------------------------------------
+
+《BMM尾轮处理策略对比分析_v1.3》文档还需要优化，
+1、在“7.2 B0/B1 相对 A1b 的损失分析（v1.3 按修正模型重写）” 中有些时候B表示方案B，有些时候B表示Batch，但你都统一用B会有些区分不清楚，请将描述中的B进行规范清晰的描述，如果B表示的是方案就说方案B，如果B表示的是Batch就说Batch
+请修改完善《BMM尾轮处理策略对比分析_v1.3》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析文件，不要动别的文件
+-------------------------------------------
+
+《BMM尾轮处理策略对比分析_v1.2》文档还需要优化，
+1、“2.1 单块时延三项” 中 T_MTE2的分子里为什么是kL1而不是K？应该是K吧，T_MMAD和T_FIXPIPE都是完成整个SingleCoreM、K、SingleCoreN的时间，T_MTE2怎么能只是完成kL1的时间呢？
+2、 “2.5 首轮切分基准（近方形的来源与适用条件）” 这一章节不能简单的用语言这样描述，要有严谨的公式推导和证明，并小结重要结论，这个过程一定要清晰严谨，一定会不断被人挑战，你的推导一定要经得起挑战
+3、“4.3 A1 vs B”中的公式直接这样写看不懂，边长s是不是=sM+sN?那S_A1b和S_B又表示什么？是读入数据的搬移总量吗？搬移总量没有K吗？
+这是一个复杂任务，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《BMM尾轮处理策略对比分析_v1.2》文档增量修改完善写出《BMM尾轮处理策略对比分析_v1.3》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析文件，不要动别的文件
+
+-------------------------------------------
+
+《BMM尾轮处理策略对比分析_v1.1》文档还需要优化，尤其是“7.2 B0/B1 相对 A1b 的损失分析” 章节
+1、“7.2 B0/B1 相对 A1b 的损失分析” 需要在交代清楚一些、分析扎实一些，具体这个损失5.4%、16.6%甚至30%这些数据是如何一步步推导出来的？
+2、我看你的损失分析是基于 “理论，方形近似”的假设基础上，这个假设是否可靠，如果非方形还是一定有损失吗？还是会损失这么多吗？请仔细分析
+3、目前主要的大模型推理中的实际的BMM的case，大多是基于prefill，decode场景下的BMM的case，这些case中，如果是Prefill场景，其BMM的case的B往往在2~128、M典型4k~128k、K典型128~10240、N典型128~10240，如果是Decode场景，其BMM的case的B往往在2~128、M典型1~128、K典型128~10240、N典型128~10240；那么在这些主流的典型的prefill，decode场景下的BMM的case，B0/B1 相对 A1b 的损失分析是怎么样的？
+这是一个复杂任务，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《BMM尾轮处理策略对比分析_v1.1》文档增量修改完善写出《BMM尾轮处理策略对比分析_v1.2》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析文件，不要动别的文件
+-------------------------------------------
+《BMM尾轮处理策略对比分析》文档还需要优化，这个文档也是“ASW_Basic分支分析”下的，应该放在“ASW_Basic分支分析”子目录下，有几点请注意检查，如有必要请对应修改：
+1、ASW_Basic分支 是兜底分支，进入前面几个如特殊分支\转Matmul\MergeBatch\IterBatch\StreamK的case不会进入 ASW_Basic分支 ，自然的，那些case在 几个备选策略下的表现 也可以不对比
+2、请专门对比下，如果完全采用方案B，是否可以先算一个基于B\M\K\N\dtype的条件或门限，当访存Bound时，如果满足条件就直接按整数轮满核切，当算力Bound时，直接按整数轮满核切，这个方案可以叫B1，之前的方案B叫B0
+3、请比较下如果完全采用B0或B1相对于方案A1b哪些场景case会有损失，最大会有多少损失？
+这是一个复杂任务，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《BMM尾轮处理策略对比分析_v1.0》文档增量修改完善写出《BMM尾轮处理策略对比分析_v1.1》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析文件，不要动别的文件
+
+-------------------------------------------
+目前“BMM算子优化分析_Release”目录下的文件有点乱，请按我的要求进行调整
+1、在“BMM算子优化分析_Release”目录下新建一个文件夹叫“ASW_Basic分支分析”，把 “ASW_Basic分支分析” 开头的文件全部放到新建的“ASW_Basic分支分析”文件夹下
+2、把《ASW_Basic分支分析_v1.91》中的 "5.10 尾轮处理的第二种策略：整轮均匀重切" 章节单独拿出来写成一篇独立的分析文档，尽量不要引用《ASW_Basic分支分析_v1.91》或本地其他文档，如果需要引用，则需要将相关推导一并放进来，只能引用外部互联网上的链接或文章
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，新增文档还是以markdown和html格式交付，并同步到仓库，不要动别的文件
+-------------------------------------------
+《ASW_Basic分支分析_v1.9》中的 "5.10 尾轮处理的第二种策略：整轮均匀重切" 章节还需要修改优化
+1、我理解A1a方案应该是A1b方案的子集，A1a方案的尾轮所有切分A1b都应该能取到，A1b应该恒优于A1a吧
+2、我更想 确认的是，能否通过公式推导明确A1b是否也能恒优于方案B？我看到你在总结时说，访存Bound有个场景 B 可能更优？是这样吗？有没有严格的推导证明？请补充分析及公式推导证明
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.9》文档增量修改完善写出《ASW_Basic分支分析_v1.91》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动别的文件
+-------------------------------------------
+
+《ASW_Basic分支分析_v1.8》中的 "5.10 尾轮处理的第二种策略：整轮均匀重切" 章节还需要修改优化
+1、你说计算Bound时，A1b的方案存在16对齐的问题而产生覆盖浪费，好像B就没有这个浪费，这个说法是有问题的，这个16对齐的约束是一样的，不管是A1b的尾轮重切还是B的全部重切，重切后的SingleCoreM、SingleCoreN都是要16对齐的，哪怕重切前一般也是要求SingleCoreM、SingleCoreN要是16的倍数，A0、A1a、A1b、B这几个方案的实现大致方案 要在5.10的开头稍微解释介绍下，你要重新审视下5.10的全部推导公式和过程，刷新分析过程和结论
+2、在5.10章节的SingleCoreM、SingleCoreN分析中都是默认正方形，即SingleCoreM=SingleCoreN，这个结论在5.2章节中有推导，要严格审视下5.2的这个推导是否严谨、是否合理，从第一性原理角度是否好解释这个SingleCoreM=SingleCoreN的结论
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.8》文档增量修改完善写出《ASW_Basic分支分析_v1.9》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动别的文件
+-------------------------------------------
+
+《ASW_Basic分支分析_v1.7》中的 "5.10 尾轮处理的第二种策略：整轮均匀重切" 章节还需要修改优化
+1、在计算Bound A0 vs A1时，如果r>C/2，A1 也不用退化为 A0，A1也可以非整数的切SingleCoreM、SingleCoreN，例如把尾轮的SingleCoreM、SingleCoreN变成原来的0.9倍（实际操作时应该是按16往下减， 例如SingleCoreM_new = SingleCoreM -16）
+2、“三策略决策总表”这个表格非常好，要留着，能不能再推导分析一个直接基于B、M、K、N就能判断到底A0、A1、A2谁最优的表格？尝试分析推理分析总结一下
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.7》文档增量修改完善写出《ASW_Basic分支分析_v1.8》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动那个文件夹
+-------------------------------------------
+
+《ASW_Basic分支分析_v1.7》中的 "5.10 尾轮处理的第二种策略：整轮均匀重切" 章节还需要修改优化
+1、我希望你在算子为算力Bound、访存Bound的不同场景下，分别比较的是在按5.1和5.2计算完BaseM、BaseN、SingleCoreM、SingleCoreN后，策略A0尾轮不再重切、策略A1仅尾轮重切、策略B全部重切，这三个策略的优劣和适用条件分界；先比较A0和A1的优劣并通过公式推导找出适用条件分界，再比较A0和B的优劣并通过公式推导找出适用条件分界，最后比较A1和B的优劣并通过公式推导找出适用条件分界，推导公式一定要完整、逻辑一定要严谨；
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，修改完善《ASW_Basic分支分析_v1.7》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动其他文件
+
+-------------------------------------------
+《ASW_Basic分支分析_v1.6》中的理论最优实现方案希望你进行一些补充分析：
+1、目前的最优实现是在不考虑是否每轮核都能用满的情况下，GM->L1重复读尽量少（SingleCoreM\N尽量大,进而mCnt\nCnt尽量少，重复读就会尽量少）、搬移效率尽量高，这些前提下进行的SingleCoreM\N的确定，由此带来的可能存在尾轮核用不满的情况，然后再针对尾轮是否算力bound或访存bound单独判断尾轮是否独立切分；现在有另外一种后选思路，就是不做尾轮和前面主要轮次的差异化的SingleCoreM、SingleCoreN（即每一轮的每个分块的SingleCoreM、SingleCoreN都一样），具体做法是先按当前理论最优实现方案首次确定SingleCoreM、SingleCoreN后，先算完成全部分块需要全核工作多少轮，例如1.125轮（即第一轮32个核，第二轮只有4个核参与，每个核做SingleCoreM、K、SingleCoreN），如果轮次非整数，直接向上取整(ceil(1.125)=2)，再以向上去整后的轮次（例如2轮，共64核次参与，就是需要切分出B*mCnt*nCnt=64个分块），重新切分SingleCoreM和SingleCoreN以达成这么多分块(例如64分块)，当然在新轮次(分块数)确定后要以重复读尽量少（优先）、搬移效率尽量大（次优先）为优化目标来确定新的SingleCoreM和SingleCoreN，如此一来，相比于不重新切分（也就是尾轮核用不满的情况），在B、M、K、N、dtype满足什么条件下适合做SingleCoreM和SingleCoreN的重新切分？可以按算子是算力Bound还是访存Bound分不同情况讨论；
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.6》文档增量修改完善写出《ASW_Basic分支分析_v1.7》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动那个文件夹
+-------------------------------------------
+
+《ASW_Basic分支分析_v1.5》文档还需要继续完善，请分别细致详细的画出源码的ASW_Basic分支的程序实现流程图、文档理论最优实现的程序实现流程图，从一个case的B、M、K、N、dtype输入开始，直到所有tiling&swizzle实现参数都能被清晰的计算出来
+请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.5》文档增量修改完善写出《ASW_Basic分支分析_v1.6》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动那个文件夹
+-------------------------------------------
+我在看昇腾950PR的Cube核中的Fixpipe中的UnitFlag这个特性，这个UnitFlag特性似乎可以很好的将MMAD矩阵计算写入L0C和L0C->Fixpipe->GM进行很好的流水，好像开了这个特性T_Fixpipe和T_MMAD就可以很好的掩盖了，最多剩一个小小的16*16的尾巴Fixpipe输出不可掩盖，这个小尾巴几乎可以忽略；如果这个UnitFlag特性这么好的话，是不是没有必要在L0C上开double buffer了，因为L0C上开double buffer也是为了将T_Fixpipe和T_MMAD进行流水掩盖，如果这个UnitFlag特性这么好的话，为什么batch_mat_mul_v3算子中还有些在L0C上开double buffer的场景呢？L0C上开double buffer和这个unitFlag特性的适用条件边界在哪里？请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，单独输出一篇分析文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul\BMM相关文件，不要动其他文件
+官方参考文献：
+https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/latest/API/ascendcopapi/docs/zh/api/SIMD-API/%E5%9F%BA%E7%A1%80API/cube_compute_TensorAPI/Mmad%E8%AE%A1%E7%AE%97%E5%85%B3%E9%94%AE%E7%89%B9%E6%80%A7%E8%AF%B4%E6%98%8E/UnitFlag.md
+
+-------------------------------------------
+
+《ASW_Basic分支分析_v1.5》文档还需要继续完善，关于 “SingleCoreM/N 的具体确定过程”的“若 P > 1”这块讲的不清楚，如何开始，只需要检查约束2/3/4就行了吗？满足约束2/3/4的有多个组合怎么办呢？如何选取最优的呢？
+逻辑要连贯要严谨，请修改完善《ASW_Basic分支分析_v1.5》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动那个文件夹
+-------------------------------------------
+ASW_Basic分支是BMM最重要的分支《ASW_Basic分支分析_v1.4》文档还需要继续完善，尤其是实现方案中的与源码的差异对比，例如
+1、源码具体是如何确定BaseM\N的，“再由 cubeBound 模型（L2 供数能力 + 溢出惩罚 + K 向复用）枚举收缩” 这个具体是怎么做的？为什么源码要这么做，出于什么设计和考虑？和文档写的理论最优实现究竟哪个好？为什么？
+2、SingleCoreM/N 源码是怎么做的？“源码用 cubeBound 模型 + balanceRate ≥ 0.9 剪枝，不解耦 SingleCoreM/N 与 BaseM/N” 具体怎么做的？为什么源码要这么做，出于什么设计和考虑？和文档写的理论最优实现究竟哪个好？为什么？
+3、第五章后续其他 mCnt / nCnt 、尾轮问题，也都要详细对比，分析当前源码实现与文档的理论最优实现方案的优劣
+多用公式推导分析清楚，逻辑要连贯要严谨，然后基于《ASW_Basic分支分析_v1.4》文档增量修改完善写出《ASW_Basic分支分析_v1.5》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动那个文件夹
+
+-------------------------------------------
+这个分析很重要，结合 IterBatch 的 case 特征看，“所以源码在 L0C 放不下时用 balance rate 做软门限（而非直接拒绝）是合理的：这批 case 天然偏写出 Bound，L0C 串行的相对损失有限，主要风险在 batch 负载不均导致的尾端拖长——而这正是 ratio ≥ 0.8 所控制的。” 把这个道理详细解释下，用公式推导分析清楚，然后基于《MergeBatch_vs_IterBatch分析_v1.0》文档增量修改完善写出《MergeBatch_vs_IterBatch分析_v1.1》文档，还是以markdown和html格式交付，并同步到仓库，注意仓库有其他人分析的Matmul相关文件，不要动那个文件夹
+-------------------------------------------
 《ASW_Basic分支分析_v1.4》文档 还是有欠考虑的地方
 1、在“五、实现方案”中，目前的结论都是 SingleCoreM/N 、BaseM/N是正方形 感觉有问题，尤其是 要求 SingleCoreM/N 为正方形，如果 M=2048、N=512，如果B不算太小，在L1能放下的条件下，SingleCoreN=512，此时SingleCoreM=2048或1024肯定比SingleCoreM=512要好，此时每Batch重复读更少了，但此时 SingleCoreM/N就不是正方形了，推导上到底是哪里出了问题？
 请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，请进一步修正完善《ASW_Basic分支分析_v1.4》文档，还是以markdown和html格式交付，并同步到仓库