fix display bug

Signed-off-by: Zhi Yiliu <2584074296@qq.com>

Author: tom-jerr

docs/blogs/llm_inference/LLMparallelization.md

@@ -69,3 +69,42 @@ Pipeline Parallelism，Expert Parallelism，Attention-FFN Decoupling
   Attention 的层间并行、冗余参数消除方式与线性层的方式一致，**层内并行的主要差异是 TP 和 SP**
 
 ### Sequence Parallelsim
+
+- 只切分 Q 的序列
+  Q 的切分后的尺寸为$[bs, heads, seq\_len/SP, head\_dim]$，按照 attention 计算：
+  1. 求解 score，Q x K 相当于左矩阵行切，score 尺寸：$[bs, heads, seq\_len/SP, seq\_len]$
+  2. softmax 求解的是最后一个维度，计算元素值相同，得到 attention_weights，
+  3. attention_weights 与 V 进行矩阵乘，还是左矩阵行切运算，元素值相同，计算得到 O 的分块结果
+  4. **将计算的 O 进行 allgather，结果相等**。
+- 只切分 K 的序列
+  score 尺寸是$[bs, heads, seq\_len, seq\_len/SP]$，进一步计算 softmax，由于最后一个维度的数据只有之前的一半长度，而 softmax 的计算跟整个序列相关，直接拼接会导致结果不相等。所以，**单独切 K 序列后拼接，结果不等**
+- 只切分 V 序列
+  得到 attention_weights 尺寸完整，计算 attention_weights x V，因为 V 矩阵被行切，所以 attention_weights 需要列切(Matmul parallelism 的图)，**最后 allreduce 能够获得完整结果**
+
+- 当前常用的方式：QKV 按照相同方式切分，然后对计算结果进行修正，这个方法在 BlockwiseMulti-HeadAttention、ring attention、tree attention、merge attention 中都有应用，softmax 修正：
+  - 每个切分 Qi 要与所有的 Ki、Vi 进行一次计算，得到 Oi
+  - 最后的分块 Oi 结果需要进行修正
+
+#### prefill
+
+推理的 prefill 阶段，Q 的序列长度与 KV 保持一致，**开启 SP 后 GPU 之间需要交换 KV 值与 Q 进行运算**（ring-attention 方式）
+
+- 每个 rank 的 Q 与 KV 匹配计算完后获得三个输出值，然后进行结果修正得到[O_X0, O_X1, O_X2]，X 值为 rank 序号。最后每个 rank 将自己的分块结果进行聚合（加法）运算得到结果 O_X。
+  ![](img/ringattention.png)
+
+#### decode
+
+在 decode 阶段 Q 的长度为 1，若对应的 KV 值分散在各个 GPU 设备中，可以将 Q 复制 N 份与切片的 KV 值进行 attention 计算后，最后将结果 gather 到一个设备上再计算修正结果。
+![](img/decode.jpg)
+
+- 这个方式意味着 GPU0 需要完成最大值、修正运算、求和运算，GPU0 可能成为瓶颈。一种 Tree attention 算法对过程做了改进，提升了通信效率。**就是把 gather 换成多次 allreduce，这种方式在跨节点场景中优势明显**。
+
+### Tensor Parallelism
+
+Attention 的张量并行分为两个部分:QKV 运算、线性投影运算。
+
+QKV 运算的 TP 切分一般**针对 heads 维度**，相当于矩阵的并行的批量运算。
+
+- attention 按照 heads 进行切分
+- linear 按照 hidden_size / heads 进行切分
+  ![](img/tp+sp.jpg)

docs/blogs/llm_inference/cudaopt.md

@@ -112,7 +112,7 @@ warp contexts 的数量决定了 SM 上能同时并发的 block 数量
 - Shared Memory: 共享内存是每个线程块（block）内所有线程共享的内存空间。共享内存的访问延迟远低于全局内存
 - L1 / L2 Cache: L1 缓存是每个 SM 独有的，**而 L2 缓存是所有 SM 共享的**
 
-<img src="img/gpu_memory.jpg" alt="memory_hierarchy"  style="width:600px;" />
+![](img/gpu_hardware.jpg){ width="600px" }
 
 :laughing:**Summary**
 
@@ -147,7 +147,7 @@ CUDA 将计算任务组织成一个三级层次结构 。这是一个由程序
 - 网格 (Grid)：为执行单个 Kernel 而启动的所有线程块的集合 。一个 Grid 内的所有线程都可以访问同一个全局内存空间。Grid 内的线程块被假定为独立执行，且执行顺序不确定；它们之间没有直接的同步机制。
 
 线程块和网格可以被组织成一维、二维或三维的结构，这为将计算任务映射到向量、矩阵、体数据等数据结构上提供了极大的便利 。  
-<img src="img/grid.jpg" alt="cuda_hierarchy" style="width:600px;" />
+![](img/grid.jpg){ width="600px" }
 
 ### Kernel 执行流程
 
@@ -176,42 +176,42 @@ CUDA 将计算任务组织成一个三级层次结构 。这是一个由程序
 
   - 合并访问（理想）：Warp 中的线程 i 访问内存地址 base + i。这在处理按行主序存储的矩阵的行时非常常见
 
-    <img src="img/coalesce-smem.png" alt="coalesce" style="width:500px;" />
+    ![](img/coalesce-smem.png){ width="500px" }
 
   - 跨步访问（问题）：线程 i 访问 base + i \* stride。如果步长（stride）很大，这将导致许多独立的、低效的内存事务。这在访问按行主序存储的矩阵的列时很常见
 
-    <img src="img/uncoalesce-smem.png" alt="coalesce" style="width:500px;" />
+    ![](img/uncoalesce-smem.png){ width="500px" }
 
   - 非对齐访问：Warp 访问的起始地址未与内存事务的大小对齐
 
 ### Avoid Bank Conflicts in Shared Memory
 
 :warning: Shared memory is organized into **32 banks**. Each bank is a slice of SRAM that can load or store **4 bytes of data every cycle**.
-<img src="img/smem.jpg" alt="shared_memory" style="width:500px;" />
+![](img/smem.jpg){ width="500px" }
 
 - 当一个 Warp 中的所有 32 个线程访问全局内存中的连续位置时，硬件可以将这 32 个小的请求“合并”成一个单一、大型、高效的内存事务
-  <img src="img/conflict-free.png" alt="bank_conflict" style="width:500px;" />
+  ![](img/conflict-free.png){ width="500px" }
 - 当同一个 Warp 中的两个或更多线程试图访问位于同一个内存银行中的不同地址时，就会发生银行冲突 。此时，这些访问会被串行化处理，从而降低了共享内存的有效带宽
-  <img src="img/bank-conflict.png" alt="bank_conflict" style="width:500px;" />
+  ![](img/bank-conflict.png){ width="500px" }
 
 #### Solutions
 
 - Padding: 在数据结构中插入填充元素，以改变数据在内存中的布局，避免多个线程访问同一银行
-  <img src="img/padding.jpg" alt="padding" style="width:500px;" />
+  ![](img/padding.jpg){ width="500px" }
   - 可能降低 SM 的 occupancy
   - 可能地址访问不对齐，无法使用向量化访问
 - **swizzling:** 重新组织数据的存储方式，使得并行访问时更少冲突(更常用):rocket:
 
   - 某些 swizzling 方法在从 shared memory 读数据到 register 时不能进行 float4 的合并读取
 
-    <img src="img/swizzling.jpg" alt="swizzling" style="width:600px;" />
+    ![](img/swizzling.jpg){ width="600px" }
 
   - 逻辑位置表示元素在矩阵中的逻辑坐标。
   - 物理位置表示其对应元素在实际存储数据的 shared memory 中的位置坐标。
 
     > 当我们说读取矩阵的第 2 行第 3 列的元素，(2,3)就表示逻辑位置，而真正读取数据的时候，我们需要从实际存储数(2,1)的 shared memory 中对应的位置
 
-    <img src="img/smem2.jpg" alt="swizzling2" style="width:600px;" />
+    ![](img/smem2.jpg){ width="600px" }
 
 :warning: 广播 (Broadcast): 如果一个 Warp 中的所有线程访问同一个银行中的完全相同的地址，这是一种广播操作，不会产生冲突
 
@@ -241,4 +241,4 @@ const int b_tile_index =  warp_id % 2 * 32 + lane_id % 8 * 4;
 - 一次性从全局内存中加载一小块 A (BM x BK) 和一小块 B (BK x BN) 到共享内存中
 - 一个线程块内的所有线程就可以在共享内存上快速地进行大量的计算，以完成对应的一小块 C (BM x BN) 的计算
 - 每个线程不再是只计算 C 块中的一个元素，而是负**责计算一个更小的结果网格**（图中是 2x2）。这样做可以进一步提升数据复用率和计算效率
-  <img src="img/tile2.png" alt="tiling" style="width:500px;" />
+  ![](img/tile2.png){ width="600px" }

docs/blogs/llm_inference/img/decode.jpg

@@ -69,15 +69,15 @@
 
 - 向量数据类型与 List 类型不同，除了比较运算符外，它**不应该支持其他的运算符**，如加减乘除等。
 - 实际向量类型是一个`std::vector<float>`，在存储时会将其序列化为二进制字符串存储在 RocksDB 中。
-  <img src="img/vector.png" alt="vector" style="width:200px;">
+  ![](img/vector.png){ width="200px" }
 
 ### 向量存储支持(RocksDB Multi Column Family)
 
 - 这里我们采用向量存储与其他图属性分离的方式，方便后续进行 ANN 索引构建。
 - 为了实现与其他数据的隔离，我们需要将向量数据存储在向量列族中，其他数据存储在默认列族中。
   > :warning:这里的 ID-VID 列族是为了后续实现 ANN 索引创建使用的
 
-<img src="img/rocksdb.png" alt="column_family" style="width:200px;">
+![](img/rocksdb.png){ width="200px" }
 
 ### 向量类型的 Key 结构
 
@@ -100,14 +100,14 @@
 - 向量列：专门用于 VECTOR 类型
 - Schema 属性选项：如 TTL、TTL_COL 等
 
-<img src="img/schema.png" alt="schema" style="width:300px;">
+![](img/schema.png){ width="400px" }
 
 此外，还需修改 RowWriter 和 RowReader 以支持向量列操作：
 
 - RowWriter 将向量数据写入 RocksDB 的 vector 列族
 - RowReader 从 RocksDB 的 vector 列族读取向量数据
 
-<img src="img/rowreader&writer.png" alt="rowwriter" style="width:600px;">
+![](img/rowreader&writer.png){ width="600px" }
 
 ### :skull: 向量属性的 DML 语句(Insert/Update/Delete/Upsert)
 
@@ -118,17 +118,17 @@
 - Storage 节点接收到 Request 后，会生成 Storage 节点的计划，最后调用存储引擎接口将数据写入 RocksDB
 - 返回结果给 Client 端
 
-<img src="img/insert_dml.png" alt="dml" style="width:400px;">
+![](img/insert_dml.png){ width="400px" }
 
 :warning:这里面有一些细节需要注意:
 
 - Storage Cache: storaged 会定期使用心跳拉取 metad 最新的 Schema 信息，更新本地的 Schema 缓存，从而获取最新的 Schema 信息。我们需要确保**向量列的信息也能正确地被缓存和更新(后续还有向量索引的更新)**。
-  <img src="img/storage_cache.png" alt="storage_cache" style="width:200px;">
+  ![](img/storage_cache.png){ width="200px" }
 - 为了确保 DML 操作的一致性，我们在 DML 流程中进行了修改，要求每个请求仅使用一次异步操作将数据写入。具体实现是在数据真正写入的 `Raft::commitLog()` 函数中，通过检查键（Key）的第一个字节（Type），来判断需要写入到哪个列族中。
-  <img src="img/doput.png" alt="doput" style="width:400px;">
+  ![](img/doput.png){ width="400px" }
 - 除了 Graghd 会生成物理计划，实际上 Storaged 也会生成自己的执行计划，这个计划会调用存储引擎的接口将数据写入 RocksDB 中。我们需要为获取向量属性修改相关计划节点(TagNode/EdgeNode)。
   - 为了支持 TagNode/EdgeNode 多向量属性的支持，在 TagNode/EdgeNode 中增加了`std::vector<RowReader> vecReaders_`成员变量，用于读取多个向量属性的值。
-    <img src="img/storage_plan.png" alt="storage_plan" style="width:400px;">
+    ![](img/storage_plan.png){ width="400px" }
 
 ### 向量索引功能(Ann Index in Common)
 
@@ -245,15 +245,15 @@ CREATE EDGE ANNINDEX <index_name> ON <tag_name_list>::(<field_name>) [IF NOT EXI
     - `VertexID → VectorID`
   - 最后构建向量索引，并将其加载到内存中。
 
-<img src="img/create_ann_index.png" alt="create_index" style="width:600px;">
+![](img/create_ann_index.png){ width="600px" }
 
 :warning: Storaged 中实际上也会有一个计划，进行真正的索引创建工作：
 
 1. 从 RocksDB 中扫描所有的向量数据
 2. 将 Vertex ID 与 Vector ID 的映射关系存储到 id-vid 列族中(:star2:**这就是为什么我们需要三个列族**)
 3. 构建向量索引并加载到内存中
 
-<img src="img/ann_index_storage_plan.png" alt="ann_index_storage_plan" style="width:600px;">
+![](img/ann_index_storage_plan.png){ width="600px" }
 
 ### :skull::skull:ANN Search
 
@@ -282,17 +282,17 @@ match (v:tag5:tag6) return v order by euclidean(vector(1.0,2.0,3.0), v.vec)  app
 1. 经过优化规则处理后的物理执行计划会执行 `TagAnnIndexScan`，在 storaged 收到请求后，会生成一个内部执行计划，在 IVF 索引上进行搜索，并将结果返回给 graphd
 2. Graphd 调用 storaged 的 `getProp` 算子生成执行计划，以获取节点的非向量属性，最后执行 Limit 和 Project，得到最终结果
 
-<img src="img/ann_search.png" alt="ann_search_overview" style="width:500px;">
+![](img/ann_search.png){ width="600px" }
 
 #### 优化规则
 
 - 对不返回向量距离的语句，优化器工作流程如下图所示:
 
-<img src="img/opt-rule1.png" alt="ann_search_graphd" style="width:400px;">
+![](img/opt-rule1.png){ width="400px" }
 
 - 对返回向量距离的语句，优化器工作流程如下图所示:
 
-<img src="img/opt-rule2.png" alt="ann_search_graphd" style="width:400px;">
+![](img/opt-rule2.png){ width="400px" }
 
 #### 执行流程
 
@@ -302,15 +302,15 @@ match (v:tag5:tag6) return v order by euclidean(vector(1.0,2.0,3.0), v.vec)  app
 
 > 实际上，storaged 接收到 graphd 的请求后会启动它自己的执行器，并在其中生成 storaged 的执行计划，计划执行会从 Ann Index 中获取数据，最后返回结果给 graphd。
 
-<img src="img/ann_search2.png" alt="ann_search_detailed" style="width:600px;">
+![](img/ann_search2.png){ width="600px" }
 
 实际上，在 storaged 中，`AnnIndexScan` 的处理过程与 `IndexScan` 非常相似。
 
 - 需要先进行初始化，然后执行 `doExecute`。实际的数据获取是通过调用 `resetIter` 完成的。
   > 此时是通过 ANN 索引获取结果（这里得到的只是向量 ID，而不是实际的顶点 ID）
 - 随后 `doNext` 只是简单地遍历这些结果，再调用 `AnnIndexVertexScan::getVidByVectorid() `从 RocksDB 中获取实际的 VID 数据，并将 VID 与向量距离数据一并返回给 graphd。
 
-<img src="img/ann_search_storaged.png" alt="ann_index_scan" style="width:200px;">
+![](img/ann_search_storaged.png){ width="300px" }
 
 ## 功能测试
 
@@ -336,7 +336,7 @@ match (v:tag5:tag6) return v order by euclidean(vector(1.0,2.0,3.0), v.vec)  app
     | ANN Search                                       | [Ann Search](https://github.com/vesoft-inc/nebula/pull/6104)                                          |
 
   - tck 测试用例结果：
-    <img src="img/create_ann_index_test.png" alt="create_ann_index_test" style="width:600px;">
+    ![](img/create_ann_index_test.png)
 
 ### 单元测试
 

docs/blogs/llm_inference/img/ringattention.png

@@ -320,9 +320,10 @@ nav:
       - index: blogs/index.md
       - LLM Inference:
           - Introduction for LLM Inference: blogs/llm_inference/Introduction.md
+          - CUDA Optimization: blogs/llm_inference/cudaopt.md
           - Parallelizatoin in ML System: blogs/llm_inference/parallelization.md
+          - Parallelization in LLM Inference: blogs/llm_inference/LLMparallelization.md
           - PageAttention: blogs/llm_inference/pageattention.md
-          - CUDA Optimization: blogs/llm_inference/cudaopt.md
       - nebula:
           - Vistor Pattern in nebula: projects/nebula-vsearch/understanding/1.visitor pattern.md
           - Memory Management in nebula: projects/nebula-vsearch/understanding/2.memory management.md