大模型 Prompt Prefill 阶段的高效 Batching 与算子排布在大语言模型LLM的整个前向推理生命周期中计算过程被极其鲜明地划分为两个截然不同的物理阶段Prefill 阶段Prompt 预填充 / 上下文理解一次性吃进用户传入的整段 Prompt包含数百到数千个 Token计算全量自注意力产出第一个生成 Token 并将历史 KV 写入 KV CacheDecode 阶段自回归解码 / 吐字每次只吃进前一个生成的单个 Token逐步吐出下一个 Token。这两个阶段的算力特征呈现出两极分化Decode 阶段单 Token 矩阵乘属于典型的访存密集型Memory-Bound算力利用率通常只有 20%~40%Prefill 阶段长序列矩阵乘属于极高密度的计算密集型Compute-Bound能够轻松打满 GPU 的 Tensor Core 浮点算力然而在面对高并发长短不一的 Prompt 请求洪峰时如何对 Prefill 阶段进行高效批处理Batching与算子物理排布Operator Scheduling深入剖析变长打平拼接Flattened VarLen Batching与分块 PrefillChunked Prefill是构建顶级推理引擎的核心基本功。-------------------------------------------------------------------------- | 传统 Padding Batching vs 变长打平 VarLen Batching | -------------------------------------------------------------------------- | [传统 Padding Batching (大量计算浪费 )]: | | Prompt 1 (长度 5): [T1] [T2] [T3] [T4] [T5] | | Prompt 2 (长度 2): [T1] [T2] [PAD] [PAD] [PAD] --- 浪费 60% 计算! | | Prompt 3 (长度 3): [T1] [T2] [T3] [PAD] [PAD] --- 浪费 40% 计算! | -------------------------------------------------------------------------- | 升级为 VarLen 打平拼接 (FlashAttention VarLen) v | [变长打平 VarLen Batching (零 Padding, 100% 算力饱和 )]: | | 1. 打平连续张量: [P1_T1..T5] [P2_T1..T2] [P3_T1..T3] (总长度 10 Token) | | 2. 累积位点描述符 (cu_seqlens): [0, 5, 7, 10] | | - 全程无 1 字节无效 Padding 计算GEMM 算力利用率达到 95% 理论极限! | --------------------------------------------------------------------------1. 传统 Padding 批处理的灾难算力与显存的巨额浪费在传统的批处理框架中为了让不同长度的 Prompt 能够组合成一个规则的三维张量[Batch, Max_Seq_Len, Hidden_Dim]必须以当前 Batch 中最长的那条 Prompt 为基准其余所有较短的 Prompt 必须在尾部疯狂填充毫无意义的PAD标记。假设一个 Batch 内包含 3 个请求长度分别为 10、50、2048所有短请求都被强行 Padding 到了 2048全 Batch 超过 66% 的 GPU 算力与显存带宽都在为虚无的PAD占位符做无用功2. 现代解法变长打平批处理VarLen Flattening现代高性能推理引擎如 FlashAttention-2 VarLen、vLLM、TensorRT-LLM彻底废弃了三维 Padding 张量改用一维变长打平流1D Flattened Stream核心物理排布打平张量Flattened Tokens将当前 Batch 内所有 Prompt 的有效 Token 紧密首尾相接压平为一个连续的二维矩阵[Total_Tokens, Hidden_Dim]其中 $\text{Total_Tokens} \sum \text{Len}_i$累积序列长度切片cu_seqlens维护一个微小的整数数组记录每个请求在打平张量中的起始与终止偏移量。例如cu_seqlens [0, 5, 7, 10]分块注意力 Kernel 直连底层的 FlashAttention VarLen Kernel 直接读取cu_seqlens在 GPU SRAM 内部仅对属于同一个请求内部的 Token 执行自注意力计算跨请求之间互不干扰且绝对没有 1 个 Token 的 Padding 浪费3. 终极架构演进分块 PrefillChunked Prefill / Piggybacking当线上来了一个长达 8192 Token 的超长 Prompt 时如果将其一次性做完 Prefill该计算会在 GPU 上独占运行200ms在这 200ms 期间线上其他几百个正在处于 Decode 吐字阶段的用户请求会被彻底卡死Decode Starvation导致吐字打字机效果出现严重卡顿分块 PrefillChunked Prefill的做法是将 8192 的超大 Prompt 拆解为多个例如 512 的 Chunk在每一个调度步Step中让一个 512 的 Prefill Chunk 与正在运行的 Decode 请求混合打平拼接在同一个 Batch 内Prefill-Decode Co-Execution既把 GPU 算力完全填满又保障了全网 Decode 请求的极速低延迟吐字。精打细算每一颗 Token 在硬件流水线上的排布是构建现代大规模大模型服务底座的最强护城河。
大模型 Prompt Prefill 阶段的高效 Batching 与算子排布在大语言模型LLM的整个前向推理生命周期中计算过程被极其鲜明地划分为两个截然不同的物理阶段Prefill 阶段Prompt 预填充 / 上下文理解一次性吃进用户传入的整段 Prompt包含数百到数千个 Token计算全量自注意力产出第一个生成 Token 并将历史 KV 写入 KV CacheDecode 阶段自回归解码 / 吐字每次只吃进前一个生成的单个 Token逐步吐出下一个 Token。这两个阶段的算力特征呈现出两极分化Decode 阶段单 Token 矩阵乘属于典型的访存密集型Memory-Bound算力利用率通常只有 20%~40%Prefill 阶段长序列矩阵乘属于极高密度的计算密集型Compute-Bound能够轻松打满 GPU 的 Tensor Core 浮点算力然而在面对高并发长短不一的 Prompt 请求洪峰时如何对 Prefill 阶段进行高效批处理Batching与算子物理排布Operator Scheduling深入剖析变长打平拼接Flattened VarLen Batching与分块 PrefillChunked Prefill是构建顶级推理引擎的核心基本功。-------------------------------------------------------------------------- | 传统 Padding Batching vs 变长打平 VarLen Batching | -------------------------------------------------------------------------- | [传统 Padding Batching (大量计算浪费 )]: | | Prompt 1 (长度 5): [T1] [T2] [T3] [T4] [T5] | | Prompt 2 (长度 2): [T1] [T2] [PAD] [PAD] [PAD] --- 浪费 60% 计算! | | Prompt 3 (长度 3): [T1] [T2] [T3] [PAD] [PAD] --- 浪费 40% 计算! | -------------------------------------------------------------------------- | 升级为 VarLen 打平拼接 (FlashAttention VarLen) v | [变长打平 VarLen Batching (零 Padding, 100% 算力饱和 )]: | | 1. 打平连续张量: [P1_T1..T5] [P2_T1..T2] [P3_T1..T3] (总长度 10 Token) | | 2. 累积位点描述符 (cu_seqlens): [0, 5, 7, 10] | | - 全程无 1 字节无效 Padding 计算GEMM 算力利用率达到 95% 理论极限! | --------------------------------------------------------------------------1. 传统 Padding 批处理的灾难算力与显存的巨额浪费在传统的批处理框架中为了让不同长度的 Prompt 能够组合成一个规则的三维张量[Batch, Max_Seq_Len, Hidden_Dim]必须以当前 Batch 中最长的那条 Prompt 为基准其余所有较短的 Prompt 必须在尾部疯狂填充毫无意义的PAD标记。假设一个 Batch 内包含 3 个请求长度分别为 10、50、2048所有短请求都被强行 Padding 到了 2048全 Batch 超过 66% 的 GPU 算力与显存带宽都在为虚无的PAD占位符做无用功2. 现代解法变长打平批处理VarLen Flattening现代高性能推理引擎如 FlashAttention-2 VarLen、vLLM、TensorRT-LLM彻底废弃了三维 Padding 张量改用一维变长打平流1D Flattened Stream核心物理排布打平张量Flattened Tokens将当前 Batch 内所有 Prompt 的有效 Token 紧密首尾相接压平为一个连续的二维矩阵[Total_Tokens, Hidden_Dim]其中 $\text{Total_Tokens} \sum \text{Len}_i$累积序列长度切片cu_seqlens维护一个微小的整数数组记录每个请求在打平张量中的起始与终止偏移量。例如cu_seqlens [0, 5, 7, 10]分块注意力 Kernel 直连底层的 FlashAttention VarLen Kernel 直接读取cu_seqlens在 GPU SRAM 内部仅对属于同一个请求内部的 Token 执行自注意力计算跨请求之间互不干扰且绝对没有 1 个 Token 的 Padding 浪费3. 终极架构演进分块 PrefillChunked Prefill / Piggybacking当线上来了一个长达 8192 Token 的超长 Prompt 时如果将其一次性做完 Prefill该计算会在 GPU 上独占运行200ms在这 200ms 期间线上其他几百个正在处于 Decode 吐字阶段的用户请求会被彻底卡死Decode Starvation导致吐字打字机效果出现严重卡顿分块 PrefillChunked Prefill的做法是将 8192 的超大 Prompt 拆解为多个例如 512 的 Chunk在每一个调度步Step中让一个 512 的 Prefill Chunk 与正在运行的 Decode 请求混合打平拼接在同一个 Batch 内Prefill-Decode Co-Execution既把 GPU 算力完全填满又保障了全网 Decode 请求的极速低延迟吐字。精打细算每一颗 Token 在硬件流水线上的排布是构建现代大规模大模型服务底座的最强护城河。
