27届大模型面试准备六十七大模型推理编译与图优化工程——从计算图到高效内核引言本篇是工程实战深化的第 67 篇。前面我们写过推理引擎内核A59PagedAttention、调度器、显存管理、注意力演进与 KV CacheA36、推理调度与弹性扩缩容A66。它们讨论的都是运行时runtime如何把已经存在的内核高效地排起来。但还有一个前置关卡经常被面试深挖这些内核本身从哪来为什么同一个 Transformer用torch.compile能比 eager 模式快一倍用 TensorRT-LLM 又能再快一截答案在编译期——把计算图翻译成对硬件友好的高效代码。本文聚焦推理编译与图优化计算图/IR、算子融合、布局优化、自动调优AutoTune、代码生成Triton / TVM / XLA以及编译产物如何与 vLLM、TensorRT-LLM 衔接。它是 AI Infra 岗、模型部署岗、以及华为这类自研硬件适配岗的高频考点。训练/推理框架 (PyTorch / JAX) | v 中间表示 IR (计算图: 算子 张量形状) | ---------------------------------------------- | 图级优化 (与硬件无关) | 后端 lowering | 常量折叠 / 死代码消除 | | 算子融合 (fusion) | - TVM / XLA / Triton | 布局优化 (NHWC/NCHW) | | | 符号形状推导 (symbolic shape) | v ---------------------------------------------- | v 自动调优 AutoTune (搜索最优 schedule/ tiling) | v 生成的机器码 (CUDA / ROCm / CPU / 自研 NPU) | v 推理引擎执行 (vLLM / TRT-LLM / SGLang) CUDA Graph一、为什么需要推理编译eager 模式的问题PyTorch eager 模式是逐个算子、逐个 kernel 调用每个算子matmul、LayerNorm、GeLU、残差加都是一次独立的 GPU kernel launch并各自读写全局显存HBM。问题有三kernel launch 开销每次 launch 有微秒级固定成本Transformer 单层数十个算子整模型上千次 launch累计不可忽略。显存带宽浪费element-wise 算子add、激活、归一化算力需求极低却要读 HBM → 算 → 写 HBM瓶颈在带宽而非算力反复读写 HBM 把带宽耗尽。无法跨算子协同eager 模式看不到全局图不能把matmul 的输出直接喂给后续激活而不落 HBM也不能根据整图形状选最优 tiling。编译器的价值就是把算子序列变成更少的、融合的、对硬件友好的 kernel并尽量让中间结果留在寄存器/共享内存SRAM里。二、图级优化手段对比优化手段做什么收益典型实现算子融合 fusion相邻算子合成一个 kernel减少 launch、减少 HBM 读写FlashAttention、epilogues常量折叠编译期算出常量子图去掉冗余计算通用编译器死代码消除 DCE删掉无副作用、无输出的节点减小图通用编译器布局优化选 NHWC/通道最后等内存排布提升访存局部性XLA、OneDNN符号形状推导用 symbolic shape 而非具体值支持动态 batch/seqdynamo、jax量化感知编译把 INT8/FP8 算子下沉到编译低精度推理一体化TensorRT、TVM自动调优 AutoTune搜索最优 tiling/schedule逼近硬件峰值TVM、Ansor三、算子融合从 element-wise 到 FlashAttention融合是最直观的加速。分几个层级一级融合element-wisex bias; gelu(x); layernorm(x)这类逐元素算子合并成一个 kernel输入读一次、输出写一次。典型省掉 2~3 次 HBM 往返。二级融合matmul epilogue矩阵乘的尾部操作加偏置、激活、残差加作为 GEMM 的 epilogue 在输出写回时顺手算完不另起 kernel。三级融合注意力彻底融合 FlashAttention把 QK^T、softmax、PV 全部融合进一个 kernel用 tiling 把 K/V 分块放进 SRAM避免 materialize 巨大的 N×N 注意力矩阵到 HBM。这是融合的极端形态也是 A36 提到的 KV Cache 高效注意力的核心实现。融合的约束融合后寄存器/共享内存占用上升必须保证 kernel 不溢出片上存储且融合顺序不能改变数值结果或仅允许可接受的数值重排。四、自动调优 AutoTune为什么同一个算子在不同卡上最优实现不同GPU 上矩阵乘怎么切分、多少线程一块、怎么用共享内存有海量可行 schedule性能可差数倍。AutoTune 用搜索 代价模型找最优AutoTVM手工写 schedule template定义可调参数tile 大小、unroll 因子、vectorize在真实硬件上跑一组候选、用 XGBoost 学一个代价模型预测再搜索。Ansor自动调度连 template 都不用手写编译器自动派生出合法 schedule sketch再用代价模型 evolutionary search 选优。代价模型不真跑全部候选太慢用轻量模型预测延迟把搜索空间从指数级压到可枚举。对自研硬件如华为昇腾没有现成手工 kernel 库时AutoTune / 编译生成几乎是唯一 scalable 的路径——这也是为什么编译岗在国产芯片适配里至关重要。五、代码生成Triton / TVM / XLA 三种范式Triton目前最火的用 Python 写 GPU kernel方式importtritonimporttriton.languageastltriton.jitdeffused_layernorm_add_kernel(X,Residual,Y,W,B,N,BLOCK:tl.constexpr,):pidtl.program_id(0)offspid*BLOCKtl.arange(0,BLOCK)xtl.load(Xoffs).to(tl.float32)rtl.load(Residualoffs).to(tl.float32)xxr# 残差加融合进同一 kernelmeantl.sum(x)/Nvartl.sum((x-mean)**2)/Nx(x-mean)/tl.sqrt(var1e-5)wtl.load(Woffs);btl.load(Boffs)yx*wb# 归一化 仿射不落 HBMtl.store(Yoffs,y.to(tl.float16))要点Triton 屏蔽了 CUDA 的线程/共享内存细节你只描述分块 访存 计算编译器负责 lowering 到高效 PTX。它让算法工程师也能写出接近 cuBLAS 水平的融合 kernel。TVM更完整的端到端编译栈用 Relay / TensorIR 描述计算图经过 fusion、layout、schedule 搜索生成到 CUDA / ROCm / CPU / 各类 NPU。适合一套模型编译到多种后端。XLA / TorchInductortorch.compile背后是 Dynamo 抓图 → Inductor 生成 Triton/C 代码。对工程落地最省事——几乎不改业务代码就能吃到编译收益。# 一行开启编译优化生产落地最低成本modeltorch.compile(model,modemax-autotune,dynamicTrue)# dynamicTrue 启用 symbolic shape避免每个 batch/seq 重编译六、与推理引擎的衔接编译产物怎么被调度编译生成的是高效 kernel或整图的可执行模块但它不负责请求级调度。衔接关系torch.compile / TRT-LLM 编译 - 高效 kernel / 图执行引擎 | v vLLM / SGLang 调度器 - 连续批处理 PagedAttention 前缀缓存 | v CUDA Graph 捕获重复 launch 序列 - 进一步压低 launch 开销CUDA Graph把一串固定结构的 kernel launch 录成图执行时一次提交消除逐次 launch 开销。注意动态形状/动态控制流会限制 Graph 捕获常与形状专门化配合。TensorRT-LLM在编译期把整层 transformer block 融合成插件并支持投机解码、量化是 NVIDIA 卡上的极致优化路径。动态形状代价形状一变就要重编译很慢所以工业界用形状桶shape bucketing——把相近的 (batch, seq) 归入同一份编译产物避免无限重编译。七、工业落地的坑编译缓存重编译极慢必须按 (模型, 形状桶, 精度) 做缓存CI 里预编译好随镜像下发。数值一致性融合、FP16/FP8 累积顺序改变会让输出和 eager 有微小差异评测时要有精度对齐回归呼应 A62。可调试性编译后栈帧来自 Triton/TVM原生 PyTorch 报错难定位需要保留 source map。国产硬件cuBLAS 没有的卡靠编译器生成 AutoTune 把性能补回来编译岗价值最大。面试速答推理编译解决什么eager 模式 kernel launch 多、HBM 反复读写带宽浪费、无法跨算子协同编译把算子图变成更少/融合/对硬件友好的 kernel。算子融合三级element-wise 融合 → matmulepilogue 融合 → 注意力彻底融合FlashAttention不 materialize N×N 矩阵。AutoTune 是什么搜索最优 tile/schedule用代价模型预测延迟避免全量真跑典型 AutoTVM / Ansor。torch.compile 背后Dynamo 抓计算图 → Inductor 生成 Triton/C 代码dynamicTrue 用符号形状支持动态 batch/seq。编译与推理引擎分工编译产出高效 kernel/图执行模块vLLM 等负责请求级调度连续批、PagedAttentionCUDA Graph 压 launch 开销。动态形状怎么处理符号形状 形状桶shape bucketing避免每个形状重编译。高频追问清单FlashAttention 为什么融合就能省显存N×N 注意力矩阵不落 HBM 后显存复杂度从 O(N²) 变 O(N) 吗代价模型不准时会怎样AutoTune 搜到的最优在真实硬件上不是最优怎么发现Triton kernel 和手写 CUDA 的性能差距通常在哪什么场景必须手写动态 shape 下重编译的触发条件是什么形状桶怎么划分才不亏编译产物的数值和 eager 不一致定位是融合顺序还是精度导致怎么排查CUDA Graph 为什么怕动态控制流捕获失败的兜底方案是什么国产 NPU 没有 cuBLAS编译生成的 kernel 怎么保证性能和正确性量化INT8/FP8是在编译期下沉还是运行时做两者优劣势一个大模型有上百个算子融合策略是贪心还是全局搜索全局最优可解吗推理编译和训练编译如 FSDP 编译的优化目标有何不同 
长河君 · 2026/8/31 23:19:36 · 阅读 1.2k 27届大模型面试准备（六十七）：大模型推理编译与图优化工程——从计算图到高效内核
27届大模型面试准备六十七大模型推理编译与图优化工程——从计算图到高效内核引言本篇是工程实战深化的第 67 篇。前面我们写过推理引擎内核A59PagedAttention、调度器、显存管理、注意力演进与 KV CacheA36、推理调度与弹性扩缩容A66。它们讨论的都是运行时runtime如何把已经存在的内核高效地排起来。但还有一个前置关卡经常被面试深挖这些内核本身从哪来为什么同一个 Transformer用torch.compile能比 eager 模式快一倍用 TensorRT-LLM 又能再快一截答案在编译期——把计算图翻译成对硬件友好的高效代码。本文聚焦推理编译与图优化计算图/IR、算子融合、布局优化、自动调优AutoTune、代码生成Triton / TVM / XLA以及编译产物如何与 vLLM、TensorRT-LLM 衔接。它是 AI Infra 岗、模型部署岗、以及华为这类自研硬件适配岗的高频考点。训练/推理框架 (PyTorch / JAX) | v 中间表示 IR (计算图: 算子 张量形状) | ---------------------------------------------- | 图级优化 (与硬件无关) | 后端 lowering | 常量折叠 / 死代码消除 | | 算子融合 (fusion) | - TVM / XLA / Triton | 布局优化 (NHWC/NCHW) | | | 符号形状推导 (symbolic shape) | v ---------------------------------------------- | v 自动调优 AutoTune (搜索最优 schedule/ tiling) | v 生成的机器码 (CUDA / ROCm / CPU / 自研 NPU) | v 推理引擎执行 (vLLM / TRT-LLM / SGLang) CUDA Graph一、为什么需要推理编译eager 模式的问题PyTorch eager 模式是逐个算子、逐个 kernel 调用每个算子matmul、LayerNorm、GeLU、残差加都是一次独立的 GPU kernel launch并各自读写全局显存HBM。问题有三kernel launch 开销每次 launch 有微秒级固定成本Transformer 单层数十个算子整模型上千次 launch累计不可忽略。显存带宽浪费element-wise 算子add、激活、归一化算力需求极低却要读 HBM → 算 → 写 HBM瓶颈在带宽而非算力反复读写 HBM 把带宽耗尽。无法跨算子协同eager 模式看不到全局图不能把matmul 的输出直接喂给后续激活而不落 HBM也不能根据整图形状选最优 tiling。编译器的价值就是把算子序列变成更少的、融合的、对硬件友好的 kernel并尽量让中间结果留在寄存器/共享内存SRAM里。二、图级优化手段对比优化手段做什么收益典型实现算子融合 fusion相邻算子合成一个 kernel减少 launch、减少 HBM 读写FlashAttention、epilogues常量折叠编译期算出常量子图去掉冗余计算通用编译器死代码消除 DCE删掉无副作用、无输出的节点减小图通用编译器布局优化选 NHWC/通道最后等内存排布提升访存局部性XLA、OneDNN符号形状推导用 symbolic shape 而非具体值支持动态 batch/seqdynamo、jax量化感知编译把 INT8/FP8 算子下沉到编译低精度推理一体化TensorRT、TVM自动调优 AutoTune搜索最优 tiling/schedule逼近硬件峰值TVM、Ansor三、算子融合从 element-wise 到 FlashAttention融合是最直观的加速。分几个层级一级融合element-wisex bias; gelu(x); layernorm(x)这类逐元素算子合并成一个 kernel输入读一次、输出写一次。典型省掉 2~3 次 HBM 往返。二级融合matmul epilogue矩阵乘的尾部操作加偏置、激活、残差加作为 GEMM 的 epilogue 在输出写回时顺手算完不另起 kernel。三级融合注意力彻底融合 FlashAttention把 QK^T、softmax、PV 全部融合进一个 kernel用 tiling 把 K/V 分块放进 SRAM避免 materialize 巨大的 N×N 注意力矩阵到 HBM。这是融合的极端形态也是 A36 提到的 KV Cache 高效注意力的核心实现。融合的约束融合后寄存器/共享内存占用上升必须保证 kernel 不溢出片上存储且融合顺序不能改变数值结果或仅允许可接受的数值重排。四、自动调优 AutoTune为什么同一个算子在不同卡上最优实现不同GPU 上矩阵乘怎么切分、多少线程一块、怎么用共享内存有海量可行 schedule性能可差数倍。AutoTune 用搜索 代价模型找最优AutoTVM手工写 schedule template定义可调参数tile 大小、unroll 因子、vectorize在真实硬件上跑一组候选、用 XGBoost 学一个代价模型预测再搜索。Ansor自动调度连 template 都不用手写编译器自动派生出合法 schedule sketch再用代价模型 evolutionary search 选优。代价模型不真跑全部候选太慢用轻量模型预测延迟把搜索空间从指数级压到可枚举。对自研硬件如华为昇腾没有现成手工 kernel 库时AutoTune / 编译生成几乎是唯一 scalable 的路径——这也是为什么编译岗在国产芯片适配里至关重要。五、代码生成Triton / TVM / XLA 三种范式Triton目前最火的用 Python 写 GPU kernel方式importtritonimporttriton.languageastltriton.jitdeffused_layernorm_add_kernel(X,Residual,Y,W,B,N,BLOCK:tl.constexpr,):pidtl.program_id(0)offspid*BLOCKtl.arange(0,BLOCK)xtl.load(Xoffs).to(tl.float32)rtl.load(Residualoffs).to(tl.float32)xxr# 残差加融合进同一 kernelmeantl.sum(x)/Nvartl.sum((x-mean)**2)/Nx(x-mean)/tl.sqrt(var1e-5)wtl.load(Woffs);btl.load(Boffs)yx*wb# 归一化 仿射不落 HBMtl.store(Yoffs,y.to(tl.float16))要点Triton 屏蔽了 CUDA 的线程/共享内存细节你只描述分块 访存 计算编译器负责 lowering 到高效 PTX。它让算法工程师也能写出接近 cuBLAS 水平的融合 kernel。TVM更完整的端到端编译栈用 Relay / TensorIR 描述计算图经过 fusion、layout、schedule 搜索生成到 CUDA / ROCm / CPU / 各类 NPU。适合一套模型编译到多种后端。XLA / TorchInductortorch.compile背后是 Dynamo 抓图 → Inductor 生成 Triton/C 代码。对工程落地最省事——几乎不改业务代码就能吃到编译收益。# 一行开启编译优化生产落地最低成本modeltorch.compile(model,modemax-autotune,dynamicTrue)# dynamicTrue 启用 symbolic shape避免每个 batch/seq 重编译六、与推理引擎的衔接编译产物怎么被调度编译生成的是高效 kernel或整图的可执行模块但它不负责请求级调度。衔接关系torch.compile / TRT-LLM 编译 - 高效 kernel / 图执行引擎 | v vLLM / SGLang 调度器 - 连续批处理 PagedAttention 前缀缓存 | v CUDA Graph 捕获重复 launch 序列 - 进一步压低 launch 开销CUDA Graph把一串固定结构的 kernel launch 录成图执行时一次提交消除逐次 launch 开销。注意动态形状/动态控制流会限制 Graph 捕获常与形状专门化配合。TensorRT-LLM在编译期把整层 transformer block 融合成插件并支持投机解码、量化是 NVIDIA 卡上的极致优化路径。动态形状代价形状一变就要重编译很慢所以工业界用形状桶shape bucketing——把相近的 (batch, seq) 归入同一份编译产物避免无限重编译。七、工业落地的坑编译缓存重编译极慢必须按 (模型, 形状桶, 精度) 做缓存CI 里预编译好随镜像下发。数值一致性融合、FP16/FP8 累积顺序改变会让输出和 eager 有微小差异评测时要有精度对齐回归呼应 A62。可调试性编译后栈帧来自 Triton/TVM原生 PyTorch 报错难定位需要保留 source map。国产硬件cuBLAS 没有的卡靠编译器生成 AutoTune 把性能补回来编译岗价值最大。面试速答推理编译解决什么eager 模式 kernel launch 多、HBM 反复读写带宽浪费、无法跨算子协同编译把算子图变成更少/融合/对硬件友好的 kernel。算子融合三级element-wise 融合 → matmulepilogue 融合 → 注意力彻底融合FlashAttention不 materialize N×N 矩阵。AutoTune 是什么搜索最优 tile/schedule用代价模型预测延迟避免全量真跑典型 AutoTVM / Ansor。torch.compile 背后Dynamo 抓计算图 → Inductor 生成 Triton/C 代码dynamicTrue 用符号形状支持动态 batch/seq。编译与推理引擎分工编译产出高效 kernel/图执行模块vLLM 等负责请求级调度连续批、PagedAttentionCUDA Graph 压 launch 开销。动态形状怎么处理符号形状 形状桶shape bucketing避免每个形状重编译。高频追问清单FlashAttention 为什么融合就能省显存N×N 注意力矩阵不落 HBM 后显存复杂度从 O(N²) 变 O(N) 吗代价模型不准时会怎样AutoTune 搜到的最优在真实硬件上不是最优怎么发现Triton kernel 和手写 CUDA 的性能差距通常在哪什么场景必须手写动态 shape 下重编译的触发条件是什么形状桶怎么划分才不亏编译产物的数值和 eager 不一致定位是融合顺序还是精度导致怎么排查CUDA Graph 为什么怕动态控制流捕获失败的兜底方案是什么国产 NPU 没有 cuBLAS编译生成的 kernel 怎么保证性能和正确性量化INT8/FP8是在编译期下沉还是运行时做两者优劣势一个大模型有上百个算子融合策略是贪心还是全局搜索全局最优可解吗推理编译和训练编译如 FSDP 编译的优化目标有何不同