GPU Kernel 提交的快慢往往决定了整个任务的墙钟时间。我在接手这个“优化 GPU Kernel 提交与并行效率”的项目之前一直把注意力放在 kernel 内部的线程组织和访存上直到用 Nsight 工具看到完整时间线才意识到真正的问题往往不在 GPU 执行的那一刻而在 host 端把 kernel 发出去的那条路上。这个项目要解决的问题很直接怎么把提交开销压下去怎么让 SM 上的并行效率真正提上来而不是只盯着“占用率数字”自嗨。如果你在做 CUDA 算子优化、搞 GPU 驱动开发或在 K8s 集群里管理 GPU 推理任务这篇文章里的思路和踩坑记录应该都用得上。1. 项目概述这个优化项目到底在解决什么问题1.1 从一次“慢提交”说起我刚拿到这个项目时现象非常典型同一个融合算子在 PyTorch 里通过 CUDA 跑GPU 利用率只有百分之二十出头但算子的计算量明明不小。一开始我怀疑是算法实现问题后来把 kernel 单独摘出来测发现单次 kernel 执行时间很短可整体墙钟时间却很长。这就是典型的 launch-bound 场景——时间全耗在了“提交”上。这类问题在推理场景尤为常见。大模型的逐 token 生成每步都可能 launch 几十个 kernel如果每个 kernel 只是微秒级执行而提交开销要几微秒那大部分时间都在空转。另一个高发场景是图像处理 pipeline每帧几百个 kernel 串行提交帧间隔就是这么一点点拖长的。判断是不是 launch-bound最简单的办法是看 GPU 占用率曲线。占用率低且波形存在明显“锯齿”——波峰对应一次 kernel 执行波谷对应提交/同步间隙——通常就是提交和同步消耗了大头。1.2 先理清几个关键概念这里先把几个容易混淆的概念理清楚。Kernel 在 GPU 上的执行分成两层host 端的发起launch和 device 端的执行。很多资料把“提交”和“执行”混在一起说定位问题时就会找错方向。grid / block / threadCUDA 的线程组织层级。一个 kernel 对应一个 gridgrid 由若干 block 组成block 是发往 SM 的基本载具。warpSM 上真正调度的最小单位是 warp通常是 32 个线程不是 thread。block 会被切成若干个 warp。CTACooperative Thread ArrayCTA 是 block 在另一种语境下的叫法强调 block 内的线程可以协作、同步、共享数据。CTA 与 warp 是两层概念CTA 是逻辑上的协作单位warp 是硬件上的调度单位。一个 CTA 通常包含多个 warpCTA 内部可以同步warp 之间不能直接同步。理解这组关系是做并行优化的前提。很多人问“CTA 和 warp 到底是什么关系”一句话说清CTA 是程序员用blockIdx和__syncthreads()感知到的集体warp 是 GPU 用 warp scheduler 真正逐个调度的一条条线程带。CTA 设计得再大最后也要切成 warp 跑所以想让并行效率高两者都要照顾到。1.3 这个项目能解决什么问题、适合谁项目的核心目标就一句话把 kernel 从“发出去”到“跑完”这段链路上的开销压到最低同时把 SM 上的执行效率拉满。它覆盖的对象很广CUDA 算子开发人员想优化自己写的 kernel但不知道瓶颈在提交还是执行GPU 驱动与底层工具链开发者需要理解 launch 路径上驱动和硬件的协作关系部署工程师在容器、K8s、多卡环境里调 GPU 工作负载经常遇到利用率上不去的问题用 PyTorch 微调大模型的同学如果你发现 GPU 利用率低很可能不是模型实现的问题而是提交模式的问题。对这个项目而言最终交付的不仅是几个被优化的 kernel更是一套定位问题的流程和判断标准。2. Kernel 提交机制拆解从 host 到 device 的完整链路2.1 一次 launch 背后发生了什么从 CPU 视角看一次 kernel launch 要经过这样几步参数传递与校验。运行库检查 CUDA context 是否有效、设备指针是否合法、参数尺寸是否匹配。这段看起来轻但如果你每次 launch 都传一个很大的结构体或者反复做昂贵的错误检查开销会明显放大。命令入队。CUDA driver 把 kernel 入口地址、参数、grid 配置打包成一条命令写入当前 stream 的命令队列。注意这里是异步的CPU 不等待 GPU 执行。硬件前端分发。GPU 的前端单元从命令队列取命令把 grid 切分成 block按照一定策略分配到各个 GPC再由 GPC 分到 SM。SM 调度器取指执行。SM 收到 block也就是 CTA后warp scheduler 把 CTA 切成 warp逐条取指令发射到执行单元。这里有个关键认知只要进入第 3 步host 端其实已经可以返回继续干活了。所以很多人疑问“为什么我 launch 之后马上调cudaDeviceSynchronize会这么慢”——同步会强制 host 等队列里的所有命令执行完而且会暴露所有排队延迟。2.2 提交开销都藏在哪提交开销不是单一数字而是几个部分叠加出来的开销来源典型量级说明API 调用开销1~5 微秒cudaLaunchKernel内部参数校验、上下文绑定、driver 入口处理队列与依赖0~几十微秒默认 stream 串行依赖多 stream 未做事件同步可能隐式同步同步点开销可能毫秒级cudaMemcpy、cudaMalloc、首次访问设备指针都可能隐式同步驱动与硬件调度延迟几微秒命令从 CPU 到 GPU 前端的传输与解析单看一次 launch 只有几微秒确实不算大事。但一个实时渲染管线一帧 launch 几百上千个 kernel光提交开销就能吃掉几毫秒而一帧的预算往往只有 16 毫秒。这时候你就知道为什么提交优化有时候比 kernel 内部优化更出效果了。在实际做这个项目时我用 Nsight Systems 先拉全局时间线一眼就能看出 CPU 侧有大段空白、GPU 侧在等待。这种“CPU 在忙但 GPU 没事干”的图景十有八九是 launch-bound。2.3 降低提交开销的常用手段按性价比排序我推荐这几个方向减少 launch 次数。也就是 kernel fusion把多个 kernel 融合成一个。这不只是把代码粘在一起还要考虑数据依赖和中间结果存放。中间结果尽量留在共享内存或寄存器里少写一次全局内存往往既能省 launch 又能省访存。使用 CUDA Graph。把一串 kernel 和 memcpy 的依赖关系预先捕获成图然后一次提交整张图。固定工作负载下效果立竿见影launch 次数从几百次降到一次图提交。CUDA Graph 对动态 shape 不友好所以更适合 shape 固定的场景比如推理 batch 固定时。多 stream 软流水。把无依赖的任务放进不同 stream让 kernel 之间重叠。stream 不是越多越好硬件并发能力有限开太多反而增加调度压力。消除隐式同步。把cudaMalloc挪到初始化阶段一次分完用 pinned memory 配合异步拷贝把cudaDeviceSynchronize从业务循环里去掉只在确实需要时才同步。这背后的本质逻辑是提交效率的目标是“让 GPU 持续有活干”而不是“让 CPU 尽快把活丢出去”。CPU 丢包快但 GPU 吃不下反而制造排队和空闲的交替。2.4 提交优化的边界条件提交优化也不是无脑压 launch 次数。有一个边界条件需要意识到如果 kernel 本身执行时间很长比如毫秒级那 launch 开销占比就很小优化提交就没有明显收益。另外CUDA Graph 捕获有成本如果 kernel 配置每次都不一样图就要反复重建反而更慢。所以做这一步之前先回答三个问题单次 kernel 执行时间和 launch 时间相比哪个占主导kernel 之间的依赖关系是固定的还是动态的业务循环里是不是存在不必要的同步这套判断做下来基本就能确定提交优化该投入多少精力。3. 并行效率优化让每个线程都忙起来3.1 占用率不是越高越好并行效率优化里最容易踩的坑就是把 occupancy 当成唯一指标。占用率高只说明 SM 上驻留的 block 数量足够多但不代表这些 block 里的 warp 都跑得有效率。SM 的资源由寄存器、共享内存、warp 槽位共同决定。举个例子一个 kernel 如果每个线程用了 64 个寄存器而一个 SM 的寄存器堆通常只有 64K 个 32 位寄存器那能驻留的线程数就会受限。反过来如果你把 block size 调到很大但每个 block 里同步频繁warp 之间的等待也会吃掉收益。实际项目里最常见的组合是 block size 在 128 到 256 之间每个 SM 驻留 block 数量取中间档。但这里没有银弹必须用 profiler 验证。我在优化时通常先算一版理论占用率然后用 Nsight Compute 看 warp stall 原因stall 在访存就补数据复用stall 在 barrier 就缩小 block 或调整同步位置。3.2 访存模式是并行效率的大头我见过的并行效率上不去的 kernel十有八九栽在访存上。两个重点问题一是合并访问。一个 warp 里的 32 个线程访问全局内存时如果地址尽可能落在同一个 128 字节事务内效率就高。反例是线程按 stride 访问或者每个线程访问一个结构体里的某个字段导致一次 warp 访存要拉好几个缓存行。解决办法很笨但很有效调整数据布局把连续线程要访问的数据排在一起。这也是 AoSArray of Structures改成 SoAStructure of Arrays能提升效率的根本原因。二是bank conflict。共享内存分成 32 个 bank同一个 warp 访问同一个 bank 的不同地址就会串行化。经典解法是 padding比如把一个二维数组的行宽从 N 改成 N1把地址错开冲突就没了。用__shfl系列指令做 warp 内数据交换时也要注意 shuffle 索引的分布有些索引模式天生会冲突。一句话总结访存优化不是让每个线程访问得更快而是让每个内存事务搬运得更满。3.3 CTA 与 warp 的关系对优化意味着什么CTA 和 warp 的区别前面提过这里展开讲它对优化的影响。CTA 内部的线程可以用__syncthreads()做同步这就是它能“协作”的根基。但同步有代价一个 CTA 内的所有 warp 都要等最慢的那个 warp 到达。如果 CTA 里各 warp 计算量不均整个 CTA 的执行时间就会被拖到最差 warp 的水平。所以选择 CTA 大小时先问一个问题这块计算到底需不需要块内协作需要协作比如归约、扫描、共享数据复用用适中的 CTA 大小比如 128 或 256让同步成本可控不需要协作比如逐元素算子反而可以考虑用更小的 CTA把调度粒度交还给硬件让 SM 灵活填满 warp 槽位。还有一个容易被忽视的事实一个 SM 上同时驻留的 CTA 数量有限。驻留 CTA 太少时就算每个 CTA 里面线程很多SM 也可能喂不饱。某些架构上一个 SM 最多驻留 32 个 CTA如果每个 CTA 最小 128 线程理论占用率也只有 12.5%。这种配置通常只适合访存密集型 kernel。所以调优时既要看 CTA 大小也要看每个 SM 能装下几个 CTA两个变量要一起扫。3.4 负载均衡与任务划分并行效率还有一个容易被忽视的维度任务划分是否均匀。GPU 上最常见的负载不均来自数据相关分支一个 warp 内有些线程走 if 分支有些走 else 分支两个分支都会被串行执行这就叫 warp divergence。处理思路一般有三种重新设计数据映射让同一个 warp 尽量处理相似的数据用 bitonic sort 或分段排序先做数据重排在分支代价极高时考虑用独立 kernel 分别处理不同分区用 stream 并行执行。负载均衡的判断标准是在 Nsight Compute 里看“Executed Ipc Active”这类指标如果活跃指令占比很低多半是分支发散或驻留不足。4. 实操性能画像与参数调整流程4.1 工具链搭建做性能优化不动 profiler 等于闭眼开车。我为这个项目搭建的最小工具链是这样的Nsight Systems看全局时间线定位 host 端 launch 空白、stream 使用、同步点。它能回答“瓶颈在提交还是执行”。Nsight Compute看单 kernel 内部指标比如 occupancy、warp stall 原因、memory throughput、指令混合。它能回答“kernel 内部瓶颈在访存还是计算”。CUDA Events做常规计时但只作为辅助因为它只能告诉你总耗时没法告诉你是哪一段慢。环境上还要注意 CUDA toolkit 和驱动的版本匹配。不同 toolkit 支持的 compute capability 不一样编译时指定错架构会直接跑不了或明显变慢。我的习惯是先用cudaGetDeviceProperties打印设备名、capability、SM 数量作为所有优化分析的基本盘。4.2 一个真实调优案例拿一个实际优化过的算子举例。输入是 1024×1024 的浮点矩阵做逐元素乘加然后做列方向归约。最初的实现非常直白主循环里先 launch 一个乘加 kernel再 launch 一个归约 kernel两个 kernel 之间还有一次cudaMemcpy把中间结果拷回 host。Nsight Systems 拉出来一看CPU 侧有大段空等GPU 利用率惨不忍睹。改造分三步走。第一步把输入一次性拷到显存结束前一次性拷回彻底干掉循环里的cudaMemcpy。这一步消除了隐式同步也让 GPU 不再频繁等待 host 传输。第二步把两个 kernel 融合成一个乘加结果不写回全局内存而是留在共享内存里紧接着做块内归约最后每个 block 输出一个部分和。这样既省了一次 launch又省了一次全局内存写读访存压力直接减半。第三步如果循环次数固定把整个流程 capture 成 CUDA Graph一次提交。这个案例里循环次数是固定的所以 Graph 非常合适。改造之后单帧的 launch 次数从两千次降到一次图提交墙钟时间下降大约四成。这个案例最明显的收益来自提交优化kernel 内部的融合只是顺带减少了访存。4.3 可直接参考的优化配置模板我整理了一个填参数的模板适合大部分计算密集型 kernelblock size从 128、256、512 扫三档优先看 256。计算密集用 256 通常比较稳访存密集可以试试 128。min blocks per SM通过__launch_bounds__设置给调度器留余量避免编译器为了省寄存器而过度优化。共享内存能用动态共享内存就用动态配合cudaFuncSetAttribute设置上限避免默认上限过低导致 CTA 无法调度。寄存器上限用maxrregcount或__launch_bounds__控制但别一刀切寄存器少到 spill 反而更慢。stream 数量与硬件并发能力匹配消费级显卡一般 2 到 4 个并发 stream 足够再多边际收益很低。这个模板不是真理只是一个起点。每改一项都要回到 Nsight Compute 看 warp stall 分布有没有变用数据说话别靠感觉。4.4 参数扫描与回归对照我习惯把优化过程做成一张“改动对照表”每次只改一个变量记录改动前后的 profiler 关键数据改动项启动次数/帧墙钟时间Occupancy主要 stall 原因原始版本2000基准20%Launch gap去掉 memcpy2000-15%35%Launch gapKernel 融合1000-30%50%MemoryCUDA Graph1-40%50%Memory这张表的价值在于它能帮你回答“到底是哪一步起了作用”这个问题。排查回归问题时也只需要倒查最近一次改动的数据。5. 常见问题与排查技巧实录5.1 CUDA capability 版本不匹配工程里最常见的编译报错就是类似requires device with capability (9, 0) but your GPU has capability (12, 0)。意思很直白编译时指定的 GPU 架构和实际设备不符。新卡要用新的 compute capability老 toolkit 当然不支持。解决方法是显式指定架构。比如在 nvcc 里加-archcompute_120在 PyTorch 环境里设置TORCH_CUDA_ARCH_LIST。如果你用的是老驱动即使新 capability 的卡插在机器上也可能无法用全部特性所以驱动、toolkit、编译架构三者的匹配关系要一次性理清。还有一个容易踩的坑双显卡笔记本Intel 核显 NVIDIA 独显上 CUDA 默认会选择独显但偶尔也会选错设备。用cudaGetDeviceProperties把每个设备的名称、capability 打出来确认一下经常能救你一次。5.2 GPU 崩溃或 D3D 设备移除Windows 下开发很容易碰到“GPU 发生崩溃或 D3D 设备已移除”的报错多半是 TDR 机制触发。单个 kernel 执行时间太长Windows 认为 GPU 卡死就重置设备。这时候丢的不只是这个 kernel整个 CUDA context 都可能失效。应对方法一般是把 kernel 拆小或者在循环里分段执行并检查cudaGetLastError。别做“一跑十分钟”的 kernel。如果必须长时间跑建议把计算拆成多个 kernel用 stream 串起来每个 kernel 执行时间控制在 TDR 阈值以内。TDR 阈值可以在注册表里调但修改有风险谨慎操作。5.3 驱动安装卡在 installing kernelLinux 下装 NVIDIA 驱动卡在 “installing kernel...” 很久这是老话题了。不一定是死机多数情况是 dkms 在编译内核模块。遇到较新内核编译时间可能十几分钟起步如果系统里缺 gcc、make、linux-headers 这些工具链编译会直接失败。正确的做法是装驱动前先确保uname -r对应的 headers 已安装再跑驱动安装。真卡住时别急着重启去/var/log/dkms看日志比盲猜有效得多。如果是远程服务器建议用screen或tmux跑安装脚本避免断连导致安装中断。5.4 容器与集群场景的 GPU 提交问题在 K8s 里申请 GPU 跑训练或推理时提交效率会多一层排队问题。device plugin 只负责把 GPU 分配给你但如果你申请的是整卡一个 pod 里多个进程同时 launch kernel会互相争抢 SM。这种情况下多进程服务 MPS 或者每个进程绑定不同 stream比盲目加 pod 更有效。微调大模型时很多框架默认开多个 stream但 host 端的 launch 线程如果来不及生成命令反而会形成气泡。结论是集群环境下先看 GPU 利用率曲线再决定是加大 batch 还是调整进程数。如果利用率已经很高再加并发只会增加排队延迟。6. 最后分享一点个人体会在优化这个项目的过程中我最大的一个体会是性能优化要先分对层。提交路径的优化靠的是对 host 端行为的管理并行效率的优化靠的是对 SM 内部行为的理解。两者虽然都叫“优化”但工具、手段、判断标准完全不一样。另外一个实操上的小技巧每次改动只改一个变量并记录改动前后的 profiler 数据。很多优化效果来自叠加但如果你不记录就永远说不清是哪一步起了作用。我们团队后来把每次优化都固化成一张“改动对照表”排查回归问题时非常有用。最后想说的是GPU 并行优化这个领域最忌讳的就是凭感觉调参。Nsight Compute 的 warp stall 统计、CUDA Graph 的 replay 开销、stream 深度的排队行为这些数据才是你判断的依据。把这套流程跑熟了你会发现绝大多数性能问题都是有迹可循的只要定位准确改起来往往就是几行代码的事。 GPU Kernel提交与并行效率优化：从launch-bound到CUDA Graph实战
GPU Kernel 提交的快慢往往决定了整个任务的墙钟时间。我在接手这个“优化 GPU Kernel 提交与并行效率”的项目之前一直把注意力放在 kernel 内部的线程组织和访存上直到用 Nsight 工具看到完整时间线才意识到真正的问题往往不在 GPU 执行的那一刻而在 host 端把 kernel 发出去的那条路上。这个项目要解决的问题很直接怎么把提交开销压下去怎么让 SM 上的并行效率真正提上来而不是只盯着“占用率数字”自嗨。如果你在做 CUDA 算子优化、搞 GPU 驱动开发或在 K8s 集群里管理 GPU 推理任务这篇文章里的思路和踩坑记录应该都用得上。1. 项目概述这个优化项目到底在解决什么问题1.1 从一次“慢提交”说起我刚拿到这个项目时现象非常典型同一个融合算子在 PyTorch 里通过 CUDA 跑GPU 利用率只有百分之二十出头但算子的计算量明明不小。一开始我怀疑是算法实现问题后来把 kernel 单独摘出来测发现单次 kernel 执行时间很短可整体墙钟时间却很长。这就是典型的 launch-bound 场景——时间全耗在了“提交”上。这类问题在推理场景尤为常见。大模型的逐 token 生成每步都可能 launch 几十个 kernel如果每个 kernel 只是微秒级执行而提交开销要几微秒那大部分时间都在空转。另一个高发场景是图像处理 pipeline每帧几百个 kernel 串行提交帧间隔就是这么一点点拖长的。判断是不是 launch-bound最简单的办法是看 GPU 占用率曲线。占用率低且波形存在明显“锯齿”——波峰对应一次 kernel 执行波谷对应提交/同步间隙——通常就是提交和同步消耗了大头。1.2 先理清几个关键概念这里先把几个容易混淆的概念理清楚。Kernel 在 GPU 上的执行分成两层host 端的发起launch和 device 端的执行。很多资料把“提交”和“执行”混在一起说定位问题时就会找错方向。grid / block / threadCUDA 的线程组织层级。一个 kernel 对应一个 gridgrid 由若干 block 组成block 是发往 SM 的基本载具。warpSM 上真正调度的最小单位是 warp通常是 32 个线程不是 thread。block 会被切成若干个 warp。CTACooperative Thread ArrayCTA 是 block 在另一种语境下的叫法强调 block 内的线程可以协作、同步、共享数据。CTA 与 warp 是两层概念CTA 是逻辑上的协作单位warp 是硬件上的调度单位。一个 CTA 通常包含多个 warpCTA 内部可以同步warp 之间不能直接同步。理解这组关系是做并行优化的前提。很多人问“CTA 和 warp 到底是什么关系”一句话说清CTA 是程序员用blockIdx和__syncthreads()感知到的集体warp 是 GPU 用 warp scheduler 真正逐个调度的一条条线程带。CTA 设计得再大最后也要切成 warp 跑所以想让并行效率高两者都要照顾到。1.3 这个项目能解决什么问题、适合谁项目的核心目标就一句话把 kernel 从“发出去”到“跑完”这段链路上的开销压到最低同时把 SM 上的执行效率拉满。它覆盖的对象很广CUDA 算子开发人员想优化自己写的 kernel但不知道瓶颈在提交还是执行GPU 驱动与底层工具链开发者需要理解 launch 路径上驱动和硬件的协作关系部署工程师在容器、K8s、多卡环境里调 GPU 工作负载经常遇到利用率上不去的问题用 PyTorch 微调大模型的同学如果你发现 GPU 利用率低很可能不是模型实现的问题而是提交模式的问题。对这个项目而言最终交付的不仅是几个被优化的 kernel更是一套定位问题的流程和判断标准。2. Kernel 提交机制拆解从 host 到 device 的完整链路2.1 一次 launch 背后发生了什么从 CPU 视角看一次 kernel launch 要经过这样几步参数传递与校验。运行库检查 CUDA context 是否有效、设备指针是否合法、参数尺寸是否匹配。这段看起来轻但如果你每次 launch 都传一个很大的结构体或者反复做昂贵的错误检查开销会明显放大。命令入队。CUDA driver 把 kernel 入口地址、参数、grid 配置打包成一条命令写入当前 stream 的命令队列。注意这里是异步的CPU 不等待 GPU 执行。硬件前端分发。GPU 的前端单元从命令队列取命令把 grid 切分成 block按照一定策略分配到各个 GPC再由 GPC 分到 SM。SM 调度器取指执行。SM 收到 block也就是 CTA后warp scheduler 把 CTA 切成 warp逐条取指令发射到执行单元。这里有个关键认知只要进入第 3 步host 端其实已经可以返回继续干活了。所以很多人疑问“为什么我 launch 之后马上调cudaDeviceSynchronize会这么慢”——同步会强制 host 等队列里的所有命令执行完而且会暴露所有排队延迟。2.2 提交开销都藏在哪提交开销不是单一数字而是几个部分叠加出来的开销来源典型量级说明API 调用开销1~5 微秒cudaLaunchKernel内部参数校验、上下文绑定、driver 入口处理队列与依赖0~几十微秒默认 stream 串行依赖多 stream 未做事件同步可能隐式同步同步点开销可能毫秒级cudaMemcpy、cudaMalloc、首次访问设备指针都可能隐式同步驱动与硬件调度延迟几微秒命令从 CPU 到 GPU 前端的传输与解析单看一次 launch 只有几微秒确实不算大事。但一个实时渲染管线一帧 launch 几百上千个 kernel光提交开销就能吃掉几毫秒而一帧的预算往往只有 16 毫秒。这时候你就知道为什么提交优化有时候比 kernel 内部优化更出效果了。在实际做这个项目时我用 Nsight Systems 先拉全局时间线一眼就能看出 CPU 侧有大段空白、GPU 侧在等待。这种“CPU 在忙但 GPU 没事干”的图景十有八九是 launch-bound。2.3 降低提交开销的常用手段按性价比排序我推荐这几个方向减少 launch 次数。也就是 kernel fusion把多个 kernel 融合成一个。这不只是把代码粘在一起还要考虑数据依赖和中间结果存放。中间结果尽量留在共享内存或寄存器里少写一次全局内存往往既能省 launch 又能省访存。使用 CUDA Graph。把一串 kernel 和 memcpy 的依赖关系预先捕获成图然后一次提交整张图。固定工作负载下效果立竿见影launch 次数从几百次降到一次图提交。CUDA Graph 对动态 shape 不友好所以更适合 shape 固定的场景比如推理 batch 固定时。多 stream 软流水。把无依赖的任务放进不同 stream让 kernel 之间重叠。stream 不是越多越好硬件并发能力有限开太多反而增加调度压力。消除隐式同步。把cudaMalloc挪到初始化阶段一次分完用 pinned memory 配合异步拷贝把cudaDeviceSynchronize从业务循环里去掉只在确实需要时才同步。这背后的本质逻辑是提交效率的目标是“让 GPU 持续有活干”而不是“让 CPU 尽快把活丢出去”。CPU 丢包快但 GPU 吃不下反而制造排队和空闲的交替。2.4 提交优化的边界条件提交优化也不是无脑压 launch 次数。有一个边界条件需要意识到如果 kernel 本身执行时间很长比如毫秒级那 launch 开销占比就很小优化提交就没有明显收益。另外CUDA Graph 捕获有成本如果 kernel 配置每次都不一样图就要反复重建反而更慢。所以做这一步之前先回答三个问题单次 kernel 执行时间和 launch 时间相比哪个占主导kernel 之间的依赖关系是固定的还是动态的业务循环里是不是存在不必要的同步这套判断做下来基本就能确定提交优化该投入多少精力。3. 并行效率优化让每个线程都忙起来3.1 占用率不是越高越好并行效率优化里最容易踩的坑就是把 occupancy 当成唯一指标。占用率高只说明 SM 上驻留的 block 数量足够多但不代表这些 block 里的 warp 都跑得有效率。SM 的资源由寄存器、共享内存、warp 槽位共同决定。举个例子一个 kernel 如果每个线程用了 64 个寄存器而一个 SM 的寄存器堆通常只有 64K 个 32 位寄存器那能驻留的线程数就会受限。反过来如果你把 block size 调到很大但每个 block 里同步频繁warp 之间的等待也会吃掉收益。实际项目里最常见的组合是 block size 在 128 到 256 之间每个 SM 驻留 block 数量取中间档。但这里没有银弹必须用 profiler 验证。我在优化时通常先算一版理论占用率然后用 Nsight Compute 看 warp stall 原因stall 在访存就补数据复用stall 在 barrier 就缩小 block 或调整同步位置。3.2 访存模式是并行效率的大头我见过的并行效率上不去的 kernel十有八九栽在访存上。两个重点问题一是合并访问。一个 warp 里的 32 个线程访问全局内存时如果地址尽可能落在同一个 128 字节事务内效率就高。反例是线程按 stride 访问或者每个线程访问一个结构体里的某个字段导致一次 warp 访存要拉好几个缓存行。解决办法很笨但很有效调整数据布局把连续线程要访问的数据排在一起。这也是 AoSArray of Structures改成 SoAStructure of Arrays能提升效率的根本原因。二是bank conflict。共享内存分成 32 个 bank同一个 warp 访问同一个 bank 的不同地址就会串行化。经典解法是 padding比如把一个二维数组的行宽从 N 改成 N1把地址错开冲突就没了。用__shfl系列指令做 warp 内数据交换时也要注意 shuffle 索引的分布有些索引模式天生会冲突。一句话总结访存优化不是让每个线程访问得更快而是让每个内存事务搬运得更满。3.3 CTA 与 warp 的关系对优化意味着什么CTA 和 warp 的区别前面提过这里展开讲它对优化的影响。CTA 内部的线程可以用__syncthreads()做同步这就是它能“协作”的根基。但同步有代价一个 CTA 内的所有 warp 都要等最慢的那个 warp 到达。如果 CTA 里各 warp 计算量不均整个 CTA 的执行时间就会被拖到最差 warp 的水平。所以选择 CTA 大小时先问一个问题这块计算到底需不需要块内协作需要协作比如归约、扫描、共享数据复用用适中的 CTA 大小比如 128 或 256让同步成本可控不需要协作比如逐元素算子反而可以考虑用更小的 CTA把调度粒度交还给硬件让 SM 灵活填满 warp 槽位。还有一个容易被忽视的事实一个 SM 上同时驻留的 CTA 数量有限。驻留 CTA 太少时就算每个 CTA 里面线程很多SM 也可能喂不饱。某些架构上一个 SM 最多驻留 32 个 CTA如果每个 CTA 最小 128 线程理论占用率也只有 12.5%。这种配置通常只适合访存密集型 kernel。所以调优时既要看 CTA 大小也要看每个 SM 能装下几个 CTA两个变量要一起扫。3.4 负载均衡与任务划分并行效率还有一个容易被忽视的维度任务划分是否均匀。GPU 上最常见的负载不均来自数据相关分支一个 warp 内有些线程走 if 分支有些走 else 分支两个分支都会被串行执行这就叫 warp divergence。处理思路一般有三种重新设计数据映射让同一个 warp 尽量处理相似的数据用 bitonic sort 或分段排序先做数据重排在分支代价极高时考虑用独立 kernel 分别处理不同分区用 stream 并行执行。负载均衡的判断标准是在 Nsight Compute 里看“Executed Ipc Active”这类指标如果活跃指令占比很低多半是分支发散或驻留不足。4. 实操性能画像与参数调整流程4.1 工具链搭建做性能优化不动 profiler 等于闭眼开车。我为这个项目搭建的最小工具链是这样的Nsight Systems看全局时间线定位 host 端 launch 空白、stream 使用、同步点。它能回答“瓶颈在提交还是执行”。Nsight Compute看单 kernel 内部指标比如 occupancy、warp stall 原因、memory throughput、指令混合。它能回答“kernel 内部瓶颈在访存还是计算”。CUDA Events做常规计时但只作为辅助因为它只能告诉你总耗时没法告诉你是哪一段慢。环境上还要注意 CUDA toolkit 和驱动的版本匹配。不同 toolkit 支持的 compute capability 不一样编译时指定错架构会直接跑不了或明显变慢。我的习惯是先用cudaGetDeviceProperties打印设备名、capability、SM 数量作为所有优化分析的基本盘。4.2 一个真实调优案例拿一个实际优化过的算子举例。输入是 1024×1024 的浮点矩阵做逐元素乘加然后做列方向归约。最初的实现非常直白主循环里先 launch 一个乘加 kernel再 launch 一个归约 kernel两个 kernel 之间还有一次cudaMemcpy把中间结果拷回 host。Nsight Systems 拉出来一看CPU 侧有大段空等GPU 利用率惨不忍睹。改造分三步走。第一步把输入一次性拷到显存结束前一次性拷回彻底干掉循环里的cudaMemcpy。这一步消除了隐式同步也让 GPU 不再频繁等待 host 传输。第二步把两个 kernel 融合成一个乘加结果不写回全局内存而是留在共享内存里紧接着做块内归约最后每个 block 输出一个部分和。这样既省了一次 launch又省了一次全局内存写读访存压力直接减半。第三步如果循环次数固定把整个流程 capture 成 CUDA Graph一次提交。这个案例里循环次数是固定的所以 Graph 非常合适。改造之后单帧的 launch 次数从两千次降到一次图提交墙钟时间下降大约四成。这个案例最明显的收益来自提交优化kernel 内部的融合只是顺带减少了访存。4.3 可直接参考的优化配置模板我整理了一个填参数的模板适合大部分计算密集型 kernelblock size从 128、256、512 扫三档优先看 256。计算密集用 256 通常比较稳访存密集可以试试 128。min blocks per SM通过__launch_bounds__设置给调度器留余量避免编译器为了省寄存器而过度优化。共享内存能用动态共享内存就用动态配合cudaFuncSetAttribute设置上限避免默认上限过低导致 CTA 无法调度。寄存器上限用maxrregcount或__launch_bounds__控制但别一刀切寄存器少到 spill 反而更慢。stream 数量与硬件并发能力匹配消费级显卡一般 2 到 4 个并发 stream 足够再多边际收益很低。这个模板不是真理只是一个起点。每改一项都要回到 Nsight Compute 看 warp stall 分布有没有变用数据说话别靠感觉。4.4 参数扫描与回归对照我习惯把优化过程做成一张“改动对照表”每次只改一个变量记录改动前后的 profiler 关键数据改动项启动次数/帧墙钟时间Occupancy主要 stall 原因原始版本2000基准20%Launch gap去掉 memcpy2000-15%35%Launch gapKernel 融合1000-30%50%MemoryCUDA Graph1-40%50%Memory这张表的价值在于它能帮你回答“到底是哪一步起了作用”这个问题。排查回归问题时也只需要倒查最近一次改动的数据。5. 常见问题与排查技巧实录5.1 CUDA capability 版本不匹配工程里最常见的编译报错就是类似requires device with capability (9, 0) but your GPU has capability (12, 0)。意思很直白编译时指定的 GPU 架构和实际设备不符。新卡要用新的 compute capability老 toolkit 当然不支持。解决方法是显式指定架构。比如在 nvcc 里加-archcompute_120在 PyTorch 环境里设置TORCH_CUDA_ARCH_LIST。如果你用的是老驱动即使新 capability 的卡插在机器上也可能无法用全部特性所以驱动、toolkit、编译架构三者的匹配关系要一次性理清。还有一个容易踩的坑双显卡笔记本Intel 核显 NVIDIA 独显上 CUDA 默认会选择独显但偶尔也会选错设备。用cudaGetDeviceProperties把每个设备的名称、capability 打出来确认一下经常能救你一次。5.2 GPU 崩溃或 D3D 设备移除Windows 下开发很容易碰到“GPU 发生崩溃或 D3D 设备已移除”的报错多半是 TDR 机制触发。单个 kernel 执行时间太长Windows 认为 GPU 卡死就重置设备。这时候丢的不只是这个 kernel整个 CUDA context 都可能失效。应对方法一般是把 kernel 拆小或者在循环里分段执行并检查cudaGetLastError。别做“一跑十分钟”的 kernel。如果必须长时间跑建议把计算拆成多个 kernel用 stream 串起来每个 kernel 执行时间控制在 TDR 阈值以内。TDR 阈值可以在注册表里调但修改有风险谨慎操作。5.3 驱动安装卡在 installing kernelLinux 下装 NVIDIA 驱动卡在 “installing kernel...” 很久这是老话题了。不一定是死机多数情况是 dkms 在编译内核模块。遇到较新内核编译时间可能十几分钟起步如果系统里缺 gcc、make、linux-headers 这些工具链编译会直接失败。正确的做法是装驱动前先确保uname -r对应的 headers 已安装再跑驱动安装。真卡住时别急着重启去/var/log/dkms看日志比盲猜有效得多。如果是远程服务器建议用screen或tmux跑安装脚本避免断连导致安装中断。5.4 容器与集群场景的 GPU 提交问题在 K8s 里申请 GPU 跑训练或推理时提交效率会多一层排队问题。device plugin 只负责把 GPU 分配给你但如果你申请的是整卡一个 pod 里多个进程同时 launch kernel会互相争抢 SM。这种情况下多进程服务 MPS 或者每个进程绑定不同 stream比盲目加 pod 更有效。微调大模型时很多框架默认开多个 stream但 host 端的 launch 线程如果来不及生成命令反而会形成气泡。结论是集群环境下先看 GPU 利用率曲线再决定是加大 batch 还是调整进程数。如果利用率已经很高再加并发只会增加排队延迟。6. 最后分享一点个人体会在优化这个项目的过程中我最大的一个体会是性能优化要先分对层。提交路径的优化靠的是对 host 端行为的管理并行效率的优化靠的是对 SM 内部行为的理解。两者虽然都叫“优化”但工具、手段、判断标准完全不一样。另外一个实操上的小技巧每次改动只改一个变量并记录改动前后的 profiler 数据。很多优化效果来自叠加但如果你不记录就永远说不清是哪一步起了作用。我们团队后来把每次优化都固化成一张“改动对照表”排查回归问题时非常有用。最后想说的是GPU 并行优化这个领域最忌讳的就是凭感觉调参。Nsight Compute 的 warp stall 统计、CUDA Graph 的 replay 开销、stream 深度的排队行为这些数据才是你判断的依据。把这套流程跑熟了你会发现绝大多数性能问题都是有迹可循的只要定位准确改起来往往就是几行代码的事。