深度解析：CUDA Graph 如何重塑大模型“推理性能”边界 - 文章 - 开发者社区

 Hello folks，我是 Luga，今天我们来聊一下人工智能应用场景 - 构建大模型推理关键技术 - “

CUDA Graph ” 。

随着 LLM 的参数规模与应用场景以前所未有的速度扩张，推理（Inference）阶段的性能优化，已从单纯追求理论浮点运算（FLOPs）的竞赛，转向一场对系统极致效率的、毫秒必争的“压榨”。

 在传统的推理模式中，CPU 作为控制核心，频繁地向 GPU 下达指令，这种“一问一答”式的交互模式，在面对 LLM 推理任务中海量、细碎的计算核（Kernel）时，其固有的控制开销（Overhead）形成了一道难以逾越的性能墙。


 本文将从“架构”的视角，深入剖析 CUDA Graph 这一关键技术，阐述如何通过从“命令式”到“声明式”的范式转移，将控制权从 CPU 下放至 GPU，从而绕过传统架构的瓶颈，为构建下一代高性能、低延迟的大模型推理服务，奠定了坚实的架构基石。

—01 —

传统推理模式的架构之困：CPU 控制开销的“死亡之谷”


 要理解 CUDA Graph 的革命性，我们必须首先审视其所要颠覆的传统 GPU 执行模型。在一个典型的、未使用 CUDA Graph 的大模型推理流程中，整个系统的运转高度依赖于中央处理器（CPU）的精细调度。


  1、“厨师与帮厨”的命令式架构


 我们可以将这种传统架构，比喻为一个“急性子的主厨（CPU）与一群技艺精湛但需要指令的帮厨（GPU SMs）”的厨房。2者的职责如下：

主厨（CPU）：负责阅读菜谱（执行推理代码），并将每一个烹饪步骤（如矩阵乘法、激活函数、层归一化等）拆解成独立的指令。
帮厨（GPU）：拥有强大的并行处理能力，能够极快地完成任何单一指令（执行一个 CUDA Kernel）。

整个流程是命令式的：即主厨每喊一个指令，帮厨们就迅速完成，然后集体停下来，等待主厨的下一个指令。对于一个包含数千个独立操作的复杂菜肴（一次 LLM 推理），主厨需要不间断地下达数千个指令。问题在于，主厨下达指令本身是需要时间的，这个时间，就是所谓的控制开销。
```
2、控制开销的“四大元凶”
```
在 LLM 推理这种对延迟极度敏感的场景下，CPU 的控制开销主要来源于四个方面，共同构成了性能的“死亡之谷”：
内核启动延迟（Kernel Launch Latency）：CPU 通过 CUDA 驱动程序向 GPU 发起一次 Kernel 启动请求，本身存在微秒级的固定延迟。对于 LLM 推理中大量的小型 Kernel（例如逐元素的激活函数），这些启动延迟累加起来，甚至可能超过 Kernel 实际的执行时间。
CUDA API 调用开销：除了 Kernel 启动，每一次内存分配（cudaMalloc）、数据拷贝（cudaMemcpy）、流同步（cudaStreamSynchronize）等 API 调用，都伴随着 CPU 与 GPU 驱动之间的上下文切换和验证，累积了显著的开销。
CPU 调度抖动（Jitter）：作为通用处理器，CPU 上的推理线程会受到操作系统调度的影响，任何微小的中断或上下文切换，都会导致向 GPU 发送指令的节奏被打乱，引入不确定的延迟。
动态性带来的重复开销：对于每一次新的推理请求，CPU 都需要重复地执行几乎完全相同的逻辑判断、参数计算和 Kernel 启动序列，这在架构上是一种巨大的冗余。

在训练阶段，由于数据批次（Batch Size）较大，计算密集度高，这些微秒级的控制开销尚可被摊销。但在推理阶段，尤其是要求低延迟的在线服务场景（Batch Size 通常为1），这些开销便凸显出来，成为限制系统吞吐量和延迟表现的核心架构瓶颈。CPU 成为了那个最慢的环节，导致 GPU 大量的宝贵计算周期被浪费在空闲等待中。

—02 —

从“命令式”到“声明式”的范式转移

 从本质上而言，CUDA Graph 的出现，并非对传统模式的“小打小闹”，而是一次彻底的架构范式转移：将 GPU 的执行模型，从依赖 CPU 实时指挥的“命令式”，转变为一次性定义、可重复执行的“声明式”模型。


 基于实际的业务特性，CUDA Graph 的核心思想主要将原本在运行时由 CPU 动态执行的指令序列，预先“录制”下来，形成一个固定的、可重用的计算图。这个过程在架构上分为两个阶段：


 1、Step 1：捕获—— 绘制“静态蓝图”


 在此阶段，CPU 仍然像过去一样，按顺序执行一次完整的推理计算流。但此时，CUDA 驱动程序会扮演一个“书记员”的角色。它并不会立即将 Kernel 提交给 GPU 执行，而是将 CPU 发出的所有 CUDA 相关操作（Kernel 启动、内存拷贝、事件同步等），连同它们的参数、依赖关系、执行顺序等记录下来，并在 GPU 驱动内部构建一个有向无环图（DAG）的数据结构。


 这个过程好比主厨不再直接喊菜，而是花时间将一整套复杂的菜谱（例如法国菜“酥皮包鹅肝鸭肉派”）的全部流程，事无巨细地写成一张标准化的流程图（SOP），并交给厨房。这就是所谓的 CUDA Graph。


 2、Step 2：实例化与执行—— 赋予 GPU “肌肉记忆”


 一旦“蓝图”捕获完成，CPU 的角色就发生了根本性的转变，不再需要重复执行成百上千次的 API 调用。在后续的每一次推理请求中，CPU 只需向 GPU 发出一个极其轻量的指令：“执行这张图（Launch Graph）”。


 GPU 驱动在接收到这个单一指令后，会接管全部的控制权。它拥有完整的计算图，可以在 GPU 内部，以最高效、最低开销的方式，调度执行图中定义的所有操作。省去了与 CPU 的反复通信，绕过了操作系统的调度抖动，实现了 Kernel 的背靠背（Back-to-Back）执行。


 这相当于厨房拿到了标准化的 SOP 后，帮厨们便形成了“肌肉记忆”。主厨每次只需喊一声菜名（“来一份酥皮包鹅肝鸭肉派！”），整个厨房便能心领神会，行云流水般地完成所有工序，中间无需主厨再做任何干预。


 通过这种“一次捕获，多次重放”的架构，CUDA Graph 将原本分散在多次 CPU-GPU 交互中的控制开销，一次性地摊销在了初始的捕获阶段，而在至关重要的执行阶段，实现了近乎“零”的 CPU 开销，从而将性能的瓶颈重新交还给 GPU 的计算能力本身。

—03 —

CUDA Graph 在大模型推理中的典型架构应用模式

 在复杂多变的 LLM 推理场景中，应用 CUDA Graph 并非一蹴而就，而是需要根据具体场景，选择合适的架构模式。


  1、静态输入的完全图化


 这是最理想，也是最简单的应用模式。当推理请求的输入形状（如 Batch Size、Sequence Length）是固定的，整个端到端的推理流程，从数据拷贝到计算再到结果回传，都可以被完整地捕获到一个 CUDA Graph 中。


 此模式架构优势主要体现在性能提升最大化，CPU 开销降至最低。适应于离线批处理、性能基准测试，或业务场景中输入形状高度统一的特定任务。


  然而，由于其缺乏灵活性。一旦输入形状改变，整个图就需要被废弃并重新捕获，这在动态性强的在线服务中是不可接受的。


  2、“分段图化”与“动态参数更新”


 在线推理服务的核心挑战是处理动态的输入序列长度。一个完全静态的 CUDA Graph 在此会失效。为此，我们需要采用更灵活的架构策略。这里，我们主要分为如下 3 种架构策略：

架构策略 1：“分段图化”

LLM 的推理过程，可以被清晰地划分为两个阶段：Prefill（对输入 Prompt 的并行处理）和Decoding（逐 Token 的自回归生成）。

作为动态性的主要来源，Prefill 阶段的计算图结构与输入序列长度直接相关。而在 Decoding 阶段，由于每次只生成一个 Token，其计算模式是固定且高度重复的。这个阶段非常适合被捕获成一个可重用的 CUDA Graph，我们称之为“Decoding Graph”或“Step Graph”。

通过将固定的 Decoding 阶段图化，我们已经能够优化掉推理过程中绝大部分（通常是95%以上）的 CPU 控制开销。
架构策略 2：“图更新”与“动态参数”

CUDA 提供了 Graph Update 机制，允许在不重新捕获整个图的情况下，修改图中某些节点（如 memcpy 或 Kernel）的参数，例如指向输入/输出数据的内存地址指针。

这在架构上实现了“结构静态，数据动态”。我们可以捕获一个通用的计算图结构，在每次执行前，通过 Graph Update 将其输入/输出指针，动态地指向当前请求的实际数据缓冲区。这避免了为每个请求都重新捕获的巨大开销。
架构策略 3：“装桶与填充”

这是处理动态序列长度的经典工程实践。我们可以预先为一系列离散的、有代表性的序列长度（例如 64, 128, 256, 512...）分别捕获并缓存对应的 CUDA Graph。

在运行时，当接收到一个请求时，我们将其输入序列填充（Pad）到最接近的、更大的那个桶（Bucket）的长度，然后直接调用该桶预先编译好的 Graph。

这是一种典型的空间换时间的架构权衡：通过增加内存占用（缓存多个 Graph），换取了在动态输入下的高性能执行，避免了运行时的编译和捕获开销。
```
3、与高性能库和自定义核的集成
```
CUDA Graph 并非要取代现有的性能优化手段，恰恰相反，它是一种更高层次的“调度与粘合”架构。一个设计良好的推理系统中，CUDA Graph 应该作为顶层的调度器，其图中的节点，调用的正是那些经过极致优化的计算单元。具体：
封装高性能库：对 NVIDIA cuBLAS（矩阵运算）、cuDNN（卷积运算）等官方库的调用。
集成自定义核：封装像 FlashAttention 这样的 state-of-the-art 的自定义 CUDA Kernel，或是 vLLM 中 PagedAttention 的一系列 Kernel 调用。通过将这些高度优化的、但仍需 CPU 调度的 Kernel 序列捕获到 Graph 中，实现了优化的“强强联合”。

综上所述，大模型推理的性能优化，是一场与物理定律赛跑的系统工程。在这场工程体系中，CUDA Graph 提供了一种跳出传统思维框架的、釜底抽薪式的架构解决方案：通过将控制权从 CPU 彻底下放到 GPU，实现了从“命令式”到“声明式”的深刻转变，从根本上消除了长久以来制约 GPU 推理性能的 CPU 控制开销。

因此，从某种角度而言，CUDA Graph 不仅仅是一个 API 或一项孤立的技术，而是一种全新的、面向未来的 GPU 编程与调度哲学。

随着模型结构日趋复杂，业务对延迟的要求愈发严苛，CUDA Graph 所代表的“预编译、图执行”的架构思想，将不再仅仅是一项“可选”的优化，而是成为构建一切高性能、低延迟 AI 推理服务的、不可或缺的架构基石……

今天的解析就到这里，欲了解更多关于 “大模型技术”相关技术的深入剖析，最佳实践以及相关技术前沿，敬请关注我们的微信公众号或视频号：架构驿站（ArchHub），获取更多独家技术洞察！

Happy Coding ~

Reference ：

[1] https://developer.nvidia.com/blog/enabling-dynamic-control-flow-in-cuda-graphs-with-device-graph-launch/

Adiós !

··································

对云原生网关 Traefik 技术感兴趣的朋友们，可以了解一下我的新书，感谢支持！

Hello folks，我是 Luga，Traefik Ambassador，Jakarta EE Ambassador，一个 15 年+ 技术老司机，从 IT 屌丝折腾到码畜，最后到“酱油“架构师。如果你喜欢技术，不喜欢呻吟，那么恭喜你，来对地方了，关注我，共同学习、进步、超越～