最近在整理推理服务部署笔记第四章的内容我单独抽出来说一下。这一章专门讲配置体系核心就是CompilationMode、CUDAGraphMode和-O优化级别这三个选项。为什么愿意花一整章来写因为我真见过有人把 batch size、模型并行度调到很夸张GPU 利用率还是上不去最后发现启动参数里这三个开关完全没动等于一路默认值硬扛。这三个配置不像学习率或上下文长度那么直观它们决定的是模型在 GPU 上到底怎么执行算子怎么编译、kernel 怎么调度、计算图怎么优化。如果你部署的是 7B 以上模型或者对首 token 延迟、吞吐量有要求这一章基本绕不开。下面我按自己实际部署时的理解顺序来拆尽量说人话。1. 配置体系的全貌性能瓶颈不只在模型参数里很多人调优时第一反应是改模型参数、改并行度、改量化位宽这些当然有用。但 GPU 推理的耗时构成比想象中复杂权重参数只是其中一环。真正决定 GPU 能不能跑满的往往是执行链路里那些看不见的调度和编译环节。1.1 一个公式看穿推理耗时的构成我把一次推理的总耗时拆成下面几项t_total ≈ t_compile t_dispatch t_launch t_compute t_transfer t_synct_compile算子或计算图从源码变成可执行机器码的时间主要在第一次请求或预热阶段产生。t_dispatch推理引擎把算子调度到对应后端GPU/CUDA的时间涉及 Python/C 层面的大量函数调用。t_launchCPU 把 kernel 提交到 GPU 的时间也就是常说的 kernel launch 开销。t_computeGPU 真正计算的时间这是模型权重和算力决定的。t_transfer数据在 CPU 和 GPU 之间搬运的时间。t_syncCPU 等待 GPU 完成、或者在流之间做同步的时间。在 eager 执行模式下模型的每一层都要经历“解释算子 - 调度后端 - 启动 kernel - 等待/同步”的完整流程。模型越大、算子越多t_dispatch和t_launch累计起来就越夸张。很多情况下 GPU 没跑满不是计算能力不够而是 CPU 喂数据的速度跟不上或者说 CPU 把时间都耗在了“指挥”上。1.2 三个配置项各自管哪一段CompilationMode、CUDAGraphMode、-O优化级别看似是三个独立开关实际上它们分别卡在执行链路的不同阶段配置项主要影响的耗时作用对象CompilationModet_compile、t_dispatch计算图的构建方式与编译时机CUDAGraphModet_launch、t_syncGPU kernel 的提交与执行方式-O 优化级别t_compute、t_transfer单个算子的机器码质量理解这个对应关系之后再去看框架文档里的各种配置项思路会清楚很多。比如发现 GPU 利用率低先判断瓶颈在调度还是计算再去动对应的开关不要盲目把所有优化选项都打开。1.3 配置之间还有依赖关系这三个配置不是并列关系而是有前后依赖的。CompilationMode如果走的是图模式会把模型结构转换成一张优化后的计算图可能做算子融合、冗余消除、内存规划。而CUDAGraphMode的捕获阶段通常要求网络已经是“编译后/静态”的形态如果还是 eager 模式捕获出来的图可能不稳定或者每次输入形状变化都要重新捕获。-O优化级别则影响编译产物的质量级别越高单个 kernel 的执行效率通常越好但也可能让编译时间暴涨。所以我的建议是先定CompilationMode再决定CUDAGraphMode最后根据实际瓶颈去调-O。顺序反了容易越调越乱。2. CompilationMode模型从“解释执行”到“预编译”的关键开关CompilationMode在不同框架里叫法不一样有的叫 eager/lazy有的叫 0/1/2 分档有的直接叫modeasap。但底层逻辑都是同一件事模型代码什么时候变成真正可执行的机器指令。2.1 Eager 与图模式两种执行模型的天壤之别Eager 模式很好理解就是“写一行跑一行”。模型定义里每个算子被调用时立刻在 GPU 上执行结果立刻返回。好处是调试方便能随时打印中间张量、打断点缺点是每一次算子调用都要走一遍完整的 Python/C 调度链路数千个小算子的调用开销累加起来非常可观。图模式则相反它会先把整个模型结构变成一张计算图然后对图做全局优化比如合并相邻算子、消除无用的中间张量、提前分配内存最后把整张图统一执行。打个比方eager 模式是每到一个路口就停下来看导航图模式是出发前把全程路线规划好一次走完。在推理引擎里图模式带来的收益通常非常明显。算子融合之后很多中间结果不再需要写回显存再读出来可以直接留在寄存器或片上缓存里继续算省掉的不只是调度时间还有显存带宽。这也是为什么大多数生产级推理框架默认都会走某种形式的图模式或编译优化。2.2 首包延迟为什么这么高以及如何用 Warmup 解决图模式有一个绕不开的问题首次执行前需要花时间构图、优化、生成 kernel。如果你打开日志观察会发现服务刚启动时第一个请求特别慢有时候甚至慢到几十秒后面却快得离谱这就是编译带来的首包延迟。很多团队第一次上线时被这个首包延迟吓到以为是配置错了实际上只是没做预热。解决方案很简单服务启动后先用一批有代表性的输入跑几遍把编译和优化触发掉等稳定后再接真实流量。生产环境里我会把 warmup 放到健康检查之前确保 K8s 探针打到的时候服务已经处于“热身完毕”状态。还有一种更激进的做法是启动时直接用CompilationModeasap或“预编译”模式让框架在初始化阶段就把计算图全部构建好而不是等第一个请求来了才 lazy 编译。代价是启动时间会变长但换来的是首包延迟稳定可控。2.3 按业务选型在线、离线、调试三种配置我在不同业务场景里的选择不太一样调试/开发环境CompilationModeeager或者等效的最低级。需要能随时打印中间值、对比数值编译优化反而碍事。在线低延迟服务CompilationModeasap/预编译配合 warmup。首包延迟不能飘必须把编译成本前置。离线批处理/高吞吐任务可以考虑CompilationModefeedback/lazy这类模式。它允许框架根据实际输入 shape 做特化有时候比一上来就全量预编译更高效因为可以把编译资源花在真正用到的形状上。不要以为CompilationMode永远越高越好。在形状特别动态的场景里强制预编译反而会让框架做很多无效的通用优化倒不如让编译过程跟着真实数据走。3. CUDAGraphMode让 GPU 自己编排 Kernel把 CPU 调度开销降到接近零如果说CompilationMode解决的是“图长什么样”的问题那CUDAGraphMode解决的就是“kernel 怎么发出去”的问题。3.1 内核启动开销被忽视的毫秒级浪费很多人不知道往 GPU 上提交一次 kernel 是有成本的。CPU 侧需要做参数校验、命令写入、队列提交整个过程大概要 1 到 10 微秒。听起来不多但一个大模型的 forward 过程包含几百个算子也就是说一次 prefill 就要 launch 几百次 kernel。我测过一个 7B 级别模型eager 模式下单次请求的纯调度开销能到一两毫秒。对于长 prompt、大 batch 的场景这个开销占比还不算致命但对于短 prompt、小 batch 的在线服务调度开销几乎和计算时间打平。这时候 GPU 利用率会很难看因为 GPU 大部分时间在等 CPU 把下一个 kernel 喂进来。CUDAGraphMode的出发点很简单既然这些 kernel 每次执行路径都差不多能不能把它们提前录制成一条完整的执行序列之后每次只提交一次3.2 捕获、实例化、重放CUDA Graph 的三段式流程CUDA Graph 的运作机制可以分为三步捕获Capture在一条独立的 CUDA stream 上执行一遍模型期间所有 kernel 调用和内存操作都会被记录成图节点。实例化Instantiate对捕获到的图做解析和优化生成一个可执行的 graph并分配好工作区内存。重放Replay每次推理时直接提交整个 graphGPU 会按照节点之间的依赖关系自动调度执行CPU 只需要发起一次。用生活化的例子说以前是每个任务都要领导一步步指挥现在是领导把一套标准流程录成视频之后每次只需要按一下播放键视频里的每一个环节会自动按顺序执行。开启CUDAGraphMode之后我实际观察到的收益非常可观。短序列场景下p95 延迟能下降 30% 到 60%GPU 利用率提升十几个百分点都很正常。核心原因就是 CPU 调度链路被大幅压缩了GPU 不再频繁“空转等待”。3.3 为什么 CUDAGraph 不能盲目开启但CUDAGraphMode不是银弹它有一堆限制条件盲目开启可能反而更慢。第一要求静态形状。CUDA Graph 在捕获阶段会把每一次 kernel 的形状参数固定下来。如果 batch size 或 sequence length 变了图里的内存布局就失效了。所以生产环境通常要做 batch size 分桶或长度分桶一个桶一个 graph。第二要求内存地址稳定。图捕获时记录的不仅是 kernel 调用还有内存地址。如果模型在运行时频繁申请释放显存地址一变图就废了。因此大多数框架在启用 CUDAGraph 时会使用预先分配的内存池这也是为什么开启后显存占用会明显上涨。第三不支持动态控制流。捕获期间Python 层的if、for循环会被展开成固定路径。如果模型内部的执行路径依赖输入数据动态变化graph 捕获结果就会不对或者需要反复重新捕获性能反而不如老老实实走 eager。第四和自定义算子可能有冲突。有些自定义 op 并不支持在 CUDA Graph 捕获模式下运行框架只能把它放到 capture 之外执行导致图被拆断优化效果大打折扣。我踩过的坑是模型里有几个动态 shape 的算子比如根据输入长度做不同的处理开启CUDAGraphMode后日志里一片红后来才发现框架在悄悄 fallback等于开关开了但没完全开。4. -O 优化级别编译器愿意为性能付出多少代价-O这个参数对用过 GCC/Clang 的人不陌生它在推理引擎里同样存在只是有时候藏在构建选项里有时候藏在运行时编译配置里。它控制的是编译器在生成机器码时愿意花多大力气做优化。4.1 从 -O0 到 -O3背后是编译器的取舍简单拆解一下常见级别做的事情-O0基本不做优化代码按原始逻辑逐个翻译。编译最快运行最慢适合调试。-O1做一些基础优化比如函数内联、分支优化、死代码消除编译速度和运行速度比较均衡。-O2在 -O1 基础上增加更多循环优化、指令调度、寄存器分配优化。这是大多数生产环境的默认推荐性价比最高。-O3继续加码做更激进的循环展开、向量化、自动并行化。单个算子的执行效率可能最高但编译时间和可执行文件体积也会明显上升。在 GPU 推理场景里-O级别不仅影响 CPU 侧代码也会影响 GPU kernel 的编译质量。比如nvcc或 Triton 后端在生成 PTX/SASS 时不同优化级别生成的指令序列差异很大。-O3下可能针对某个热点循环生成更高效的向量化指令-O0下则完全是“老实人”写法。4.2 一张实测对照表看优化等级的真正收益为了直观说明我拿一套 7B 模型的测试环境跑过一组对比。数据是基于我当时的示例环境量级可以参考但具体数值没必要照抄。优化级别编译时间峰值显存吞吐量首 Token 延迟适用建议-O0约 10 秒12.1 GB350 tokens/s35 ms调试、定位问题时使用-O1约 45 秒12.3 GB480 tokens/s28 ms临时验证、快速迭代-O2约 3 分钟12.8 GB510 tokens/s26 ms生产环境主力选择-O3约 18 分钟13.5 GB520 tokens/s25 ms对延迟极其敏感的场景从 -O0 到 -O2收益非常明显吞吐量能提升 40% 以上但从 -O2 到 -O3收益就只剩 2% 左右代价却是编译时间翻了 6 倍、显存涨了 0.7GB。所以我的经验是生产环境默认用 -O2除非你真的测过 -O3 对某个指标有显著帮助否则别轻易上。4.3 精度与可复现性的隐藏成本-O3还有一个容易被忽略的问题数值可复现性。激进优化会改变浮点运算的结合顺序甚至把多个运算融合成近似数学等价的快速指令结果可能在最后一个比特位上不一样。对于大多数生成任务这种差异无感但如果你的系统要做严格的离线评测、回归对比或者需要对输出做哈希校验高优化级别可能会让“同一份代码两次运行结果不同”排查起来非常痛苦。在我自己的实践里凡是涉及线上效果回归的系统我会固定用同一个优化级别绝不混用。否则你以为模型变了其实只是编译优化等级变了。5. 组合调优不同场景下的配置方案与权衡单独看每一个配置都不难难的是组合。下面是我实际部署时常用的几种组合以及为什么这么选。5.1 在线推理服务的推荐组合线上实时推理要求首包延迟稳定、长尾延迟可控不能因为编译抖动把某个请求拖死。我的推荐组合是CompilationMode预编译/ASAP启动阶段就把计算图构建好CUDAGraphMode开启前提是输入形状做了分桶-O-O2平衡编译时间和运行效率这套组合的关键是必须配合 warmup。服务启动后先用几组具有代表性的输入跑几遍确认编译完成、graph 捕获成功之后再对外宣称健康。否则第一个真实用户的延迟会很难看。5.2 离线批处理的推荐组合离线场景通常不关心首包延迟更关心总吞吐和资源利用率。这类任务往往输入比较规整batch size 可以固定所以CompilationModefeedback/lazy让框架根据实际输入 shape 编译特化版本CUDAGraphMode如果 batch 和序列长度都固定开启如果形状飘忽不定宁可关闭-O-O3如果编译时间可以接受的话离线任务多跑一个小时少跑一个小时都是成本花十几分钟编译换 2% 吞吐提升在某些场景下是划算的但需要自己算账。5.3 调试场景全关做模型调试、算子对比、精度排查时我建议把优化全部关掉CompilationModeeagerCUDAGraphMode关闭-O-O0优化越少行为越贴近代码逻辑发现问题越容易。等确认模型逻辑没问题再逐级打开优化开关定位是哪一层优化带来的问题。很多玄学 bug比如“线上结果和离线评测不一致”都是这么一步步查出来的。5.4 配置矩阵速查表场景CompilationModeCUDAGraphMode-O备注在线低延迟预编译/ASAP开启-O2warmup 必须做在线高吞吐预编译/ASAP开启-O2batch 分桶离线批处理feedback/lazy固定形状则开启-O3自己算编译成本开发调试eager关闭-O0保证可复现严格评测预编译关闭-O2避免数值抖动这套矩阵不是死的但它能帮你少走弯路。实际调整时永远一次只动一个变量别把三个全换了不然出了问题都不知道怪谁。6. 配置生效验证与踩坑排查路线最后聊一个很多人忽略的问题怎么确定配置真的生效了。配置体系最大的陷阱不是选错而是你以为选了实际框架根本没走到那条路径。6.1 用日志和 profiler 确认配置没有静默失效CUDAGraphMode是否开启最直接的标志是日志。捕获成功时一般会出现Capturing graph/Graph captured字样重放时会有Replay graph或类似输出。如果开了配置却一直看不到这些日志那基本可以断定没生效。更硬核的验证方式是用 profiler 看 kernel launch 次数。用nsys或ncu抓一小段推理对比开启前后如果开启CUDAGraphMode后 CPU 侧 kernel launch 事件数量没有大幅下降说明 graph 没真正接管执行。如果显存用量显著上升通常是 graph 内存池在工作反而是个正向信号。6.2 三个常见“改了没反应”的原因结合我自己的踩坑经历最常见的原因有三个代码路径跑的不是你以为的那个分支。很多推理引擎里有 eager fallback 逻辑模型里某个不支持编译的算子会把整条路径打回 eager但配置项本身还是显示开启的。版本不对。有些优化选项在某个框架版本里只是预留接口默认禁用需要重新编译或设额外环境变量才生效。如果你用官方预编译包可能压根没编进对应后端。动态 shape 导致反复重新捕获。表面上看CUDAGraphModeon但如果你的请求形状一直在变化graph 每次都要重新捕获捕获本身的开销比省下的还多表现为“开了反而更慢”。排查这类问题我的做法是先开日志再上 profiler最后做单变量 A/B。不要盯着配置文件猜。6.3 我的 A/B 测试做法一套可复用的验证方法固定 prompt 长度、batch 大小、并发数尽量排除外部干扰。预热 20 个请求后丢弃数据让编译和缓存都稳定下来。持续压测 5 到 10 分钟记录 p50、p95、p99 延迟和吞吐量。切换配置时必须重启进程避免上一组配置的状态残留。用同一份模型权重、同一份输入数据做对比。根据我的经验如果两个配置的吞吐差在 5% 以内大概率不是配置差异而是网络、存储、CPU 争抢等周边因素。别在一个收益很低的优化点上死磕把精力放到真正有瓶颈的地方。最后分享一点自己的体会。这套配置体系最大的价值不是某一个开关而是它逼着你去理解模型在 GPU 上的真实执行链路。搞明白 CompilationMode 管构图、CUDAGraphMode 管调度、-O 管单算子质量之后再遇到 GPU 利用率上不去的难题你会知道该去看哪一段耗时、该动哪个配置而不是像无头苍蝇一样把所有参数都试一遍。先验证再调参比什么都重要。