NVIDIA CUDA 13.1 将 Green Contexts 引入 Runtime API：专用 8 个 SM 让关键内核延迟降到 7 微秒 NEWS DETAIL

同一个进程里同时跑多个互相独立的 GPU 组件正变得常见：一个延迟敏感的算子旁边是吞吐型后台内核，数据预处理阶段与模型推理并行，或者一条处理流水线的多个阶段共享同一张 GPU。问题在于，这些组件之间的资源分配很难控制，干扰往往不可预测，而传统 CUDA context 是为"一个应用独占一张 GPU"的时代设计的，创建成本高，还会带来硬件上下文切换开销。

Green Contexts 的思路是让应用显式选择一部分 GPU 执行资源，并把工作直接投递到这些资源上。最典型的用法是 SM 分区：把一组 SM 划给某个 green context，通过它提交的工作就只在这些 SM 上运行，多个工作负载因此可以真正并行而不争抢同一批计算单元。除此之外，green context 还能划分 workqueue 资源——传统模型下，独立的流式工作负载可能映射到相同的底层 workqueue，即使执行资源充足也会被意外串行化；显式分配 workqueue 可以减少这种伪依赖。

这套机制创建和销毁都很轻量，并且创建或销毁一个 green context 不会隐式同步其他无关的 GPU 工作。编程模型也更明确：应用先针对选定资源创建 green context，再从该 context 创建流，提交到这些流上的工作自然归属于对应的资源。CUDA Runtime API 中，green context 用 cudaExecutionContext_t 表示，cudaGreenCtxCreate() 返回的句柄可以直接传给 cudaExecutionCtxStreamCreate()，不再依赖线程本地的隐式设备或 context 状态；需要面向整张 GPU 的接口，则可通过 cudaDeviceGetExecutionCtx() 取得设备级 context。

官方给出的典型场景是通信与 GEMM 重叠，或 Holoscan 这类需要尽快启动的延迟敏感算子。仅靠 CUDA 流优先级并不够：当一个大内核占满所有 SM 时，高优先级内核仍要等已有 block 排空才能拿到 SM，因为流优先级无法抢占正在执行的 block。Green Contexts 把关键 SM 预留出来后，关键内核不必等待，代价是批量内核可用的 SM 变少。

在一张 148 个 SM 的 Blackwell GPU 上，NVIDIA 用同一个"关键内核 + 批量内核"负载对比了三种模式：为关键内核划出 8 个 SM、其余 140 个 SM 跑批量内核时，关键内核延迟为 0.007 毫秒；默认 context 但关键流使用高优先级时为 0.140 毫秒；两条流同为普通优先级时为 3.727 毫秒。也就是说，流优先级相对等优先级已有约 27 倍提升，而 green context 在此之上又消除了约 20 倍的排空等待。

Green Contexts 是可选、增量的能力：现有应用可以继续面向整张 GPU 运行，只在需要更细控制的地方逐步接入。使用门槛是 CUDA 13.1 或更新版本，流程为查询设备资源、为所需分区创建 green context、在该 context 上创建流并按原有流式模型提交工作。除降低延迟外，同一套骨架也可用于构造期望的并发关系，例如让通信内核与 GEMM 内核同时推进。