课程导入：推理延迟抖动与CUDA流优先级调优

1.1 学习目标：你将带走什么

本课程面向已经掌握CUDA基础编程、熟悉GPU执行模型，但在实际推理服务中遇到延迟不稳定问题的工程师。完成本章及后续全部内容后，你将具备以下能力：

定位延迟抖动根因：能够从系统层面区分CPU调度、GPU内核执行、显存带宽、PCIe传输、CUDA流并发等环节中，哪一环才是抖动的主要贡献者。
理解CUDA流优先级机制：掌握cudaStreamCreateWithPriority、cudaDeviceGetStreamPriorityRange等API的语义，以及优先级如何影响内核调度顺序。
实施流优先级调优：能够针对推理服务中不同延迟敏感度的请求（如在线P99请求 vs 离线批量请求），设计合理的流优先级分配策略。
建立可观测的调优闭环：使用NVIDIA Nsight Systems、CUDA Events、自定义时间戳等工具，量化调优前后的延迟分布变化，形成可复用的调优方法论。

学习前提：建议你已熟悉CUDA编程模型（kernel启动、内存拷贝、事件同步），并了解GPU硬件架构的基本层次（SM、warp、内存层级）。本课程不涉及底层驱动开发，但会涉及运行时API层面的精细控制。

1.2 核心概念：延迟抖动与CUDA流优先级

在进入具体调优手段之前，必须先建立两个核心概念的精确认知。

延迟抖动（Latency Jitter）指的是推理请求的端到端延迟在时间维度上的波动程度。与平均延迟相比，P99（99分位）延迟更能反映用户体验的“尾部风险”。抖动通常由以下因素叠加产生：

排队延迟：请求在CPU侧等待GPU资源时产生的队列等待时间。
内核执行时间波动：同一模型在不同输入长度、不同GPU频率状态下的执行时间差异。
资源竞争：多个CUDA流或上下文争抢SM、显存带宽、L2缓存。
同步开销：不必要的cudaDeviceSynchronize或隐式同步导致的流水线气泡。

CUDA流优先级是CUDA运行时提供的一种调度提示机制。每个流可以关联一个优先级数值，优先级高的流中的内核会优先被GPU调度器选取执行。但需要注意：

优先级影响的是内核启动顺序，而非抢占能力——正在执行的warp不会被高优先级内核打断。
优先级范围由设备决定，通常通过cudaDeviceGetStreamPriorityRange查询，返回leastPriority（数值最大）到greatestPriority（数值最小）之间的整数。
优先级仅在多个流同时有可执行内核时发挥作用；如果GPU资源充足，低优先级流不会受到额外惩罚。

上图展示了延迟抖动的主要来源以及CUDA流优先级在其中的作用位置。可以看到，优先级调优主要影响的是从流提交到GPU调度器之间的排队行为，它不能消除CPU侧排队抖动，也无法直接改变内核本身的执行时间，但可以通过合理的资源分配策略，让关键请求的等待时间显著缩短。

1.3 整体框架：从现象到根因再到优化

本课程共30章，整体遵循“现象→原理→方法→实践→复盘”的递进结构。第1章为课程导入；第2～5章深入GPU硬件执行模型与CUDA流机制；第6～10章聚焦延迟抖动的测量与分析方法；第11～18章系统讲解流优先级调优的各类策略与变体；第19～24章结合典型推理场景（LLM推理、CV模型、推荐系统等）进行案例实战；第25～28章介绍与优先级调优配合的辅助技术（内存池、图捕获、多上下文管理等）；第29～30章为综合调优复盘与故障排查手册。

模块	章节范围	核心内容	关键产出
基础原理	第1～5章	GPU执行模型、CUDA流语义、优先级机制、硬件调度器行为	建立精确的流与调度心智模型
测量分析	第6～10章	Nsight Systems使用、CUDA Event计时、延迟分布统计、抖动归因方法	可复用的延迟抖动诊断流程
调优策略	第11～18章	优先级分配策略、动态优先级调整、流数量与并发度权衡、与MPS配合	针对不同场景的调优模式库
场景实战	第19～24章	LLM推理、CV预处理流水线、推荐系统、多模型混合部署	各场景的调优案例与代码模板
综合进阶	第25～30章	内存池优化、CUDA图捕获、多上下文隔离、故障排查手册	端到端调优能力与排障经验

1.4 典型案例：一次P99延迟飙升的排查过程

为了让你对后续内容有直观感知，这里先给出一个典型的抖动排查案例。某在线翻译服务在高峰期出现P99延迟从3ms飙升至15ms的问题，初步排查过程如下：

初步定位：使用Nsight Systems抓取时间线，发现GPU利用率仅60%，但请求排队时间长达8ms。
排除内核问题：单独运行翻译模型kernel，平均执行时间稳定在1.2ms，排除算法本身的问题。
发现流竞争：进一步分析发现，服务同时运行着离线批量翻译任务（低优先级需求）和在线实时翻译任务（高优先级需求），但两者使用了相同优先级的CUDA流。
根因确认：离线任务提交的大量kernel占据了GPU调度队列，在线任务kernel被迫等待，造成排队延迟。
解决方案：将在线任务放入高优先级流（priority = greatestPriority），离线任务放入低优先级流（priority = leastPriority），并限制离线任务的并发度。
调优结果：P99延迟回落至3.2ms，离线任务吞吐量仅下降8%，整体服务质量显著提升。

常见误区：初学者容易认为“只要把流优先级调高，延迟就一定会降低”。实际上，如果GPU已经满载（SM占用率接近100%），优先级调度只能改变执行顺序，无法创造额外算力。此时需要配合并发度控制（如限制低优先级流的kernel数量）或资源预留（如MPS的CPU配额）才能见效。本课程第14章将专门讨论这一边界条件。

1.5 本章小结与学习路径建议

本章建立了三个关键认知：第一，延迟抖动是多因素叠加的结果，必须系统化定位；第二，CUDA流优先级是调度提示而非硬性抢占，其效果受GPU负载状态制约；第三，本课程提供了从原理到实战的完整路径，后续章节将逐一展开。

建议你在进入下一章之前，先完成以下准备工作：

确认开发环境中的GPU型号，并运行cudaDeviceGetStreamPriorityRange查询设备支持的优先级范围。
准备一个简单的测试程序，创建两个不同优先级的流，分别提交不同的kernel，观察Nsight Systems中的调度顺序。
回顾你当前推理服务中CUDA流的使用方式——是否所有请求都共用同一个默认流？这往往是抖动的起点。