CUDA Green Contexts把关键内核延迟从0.140毫秒压到0.007毫秒

同一块GPU上跑多个任务时，优先级高的关键任务经常被优先级低的批量任务拖慢。而用Green Contexts把GPU资源划分开(关键任务固定分到8个SM，批量任务分到140个SM)之后，关键内核延迟降到0.007毫秒。

这篇文章作者为Kyrylo Perelygin、Shelton Dsouza和Myrto Papadopoulou。

延迟差距从哪来

文章没有说明默认上下文下调度器具体如何处理关键流和批量任务的资源争抢，只给出了结果：相等优先级下延迟高达3.727毫秒，提高关键流优先级后降到0.140毫秒，但仍无法降到微秒级。

Green Contexts的做法不同：它在创建上下文时就把SM静态划分成互不重叠的分区，关键任务和批量任务各自独占一块SM资源。按照这个设计，关键内核发射后不需要和批量任务争抢SM，延迟降到0.007毫秒，比高优先级关键流的方案快一个数量级以上。这是基于静态分区设计目标的推断，文章未进一步解释底层调度细节。

需要注意的是，官方给出的这三组数字(3.727毫秒、0.140毫秒、0.007毫秒)都是在同一块148个SM的Blackwell GPU上测得，划分方式也是同一组(8个SM给关键任务，140个SM给批量任务)，三者可以直接对比;但这组结果是否能推广到其他型号GPU或其他SM划分比例，文章没有给出数据，不宜外推。

使用与迁移

Green Contexts并非新功能。它从CUDA 12.4起就已经在Driver API里可用。从CUDA 13.1开始，Runtime API也能直接访问Green Contexts。对已经在用Driver API调用Green Contexts的项目，逻辑不受影响;对此前只用Runtime API、未接触过Driver API的团队，13.1版本之后多了一条接入路径，具体使用是否更简便，文章未给出对比说明。

适用人群与限制

这个机制主要针对同一GPU上需要跑延迟敏感任务(比如实时推理、通信类关键内核)和吞吐优先的批量任务(比如大批次训练或批量推理)并发混跑的场景。如果GPU上始终只跑单一任务，或者任务之间本身没有严格的延迟优先级区分，Green Contexts带来的收益不明显。

文章未说明SM分区比例(多少SM给关键任务、多少给批量任务)该如何根据实际负载调整，也未提及分区固定后是否支持运行时动态重新划分，这部分留给开发者在实际部署中测试验证。