CUDA流（任务队列）容量规则及确定方法技术问询

容量是否按入队项数固定、是否随操作类型变化 #

CUDA流没有按入队项数量设置的统一固定容量，实际可承载的待执行任务数会随操作类型、运行环境动态变化：

• 不同入队操作占用的流内部队列资源不统一：轻量操作（比如空核启动、单设备同地址空间的事件记录/等待、无回调的简单1D内存拷贝）单个占用的队列槽位极少，普通消费级GPU上通常能入队数千项；重操作（跨NUMA节点的设备间内存拷贝、带多参数/动态共享内存配置的核函数启动、宿主侧回调注册、三维跨步内存拷贝）单个占用的资源是轻量操作的3~10倍，此时流的可入队总数量会跌到数百到一千多的区间。
• 容量上限不是驱动硬编码的固定值：CUDA驱动会根据当前CUDA上下文的显存预留、进程的系统资源配额、GPU当前的运行负载动态调整队列的预留空间，不存在跨所有场景通用的固定容量数值，实测到的数千量级只是轻量操作场景下的典型值，不具备普适性。

非饱和压测的流实际容量确认方法 #

除了持续入队直到返回错误的暴力饱和测试，还有三种低侵入的可靠方法：

• 驱动接口直接查询：CUDA 11.0及以上版本可调用cuStreamGetAttribute接口，传入CU_STREAM_ATTRIBUTE_MAX_PENDING_WORK属性枚举，直接获取当前流允许挂起的最大待执行工作量。注意该返回值是驱动内部定义的工作量计数，不是单纯的操作个数，你可以提前测单个目标操作对应的工作量值，换算出该类操作的最大可入队数量。
• 入队阻塞临界点观测：逐批次向流中入队目标操作，每入队固定数量操作后入队一个无业务逻辑的空宿主回调，记录入队操作本身的耗时：当入队总数量远低于流容量时，入队接口会瞬间返回，不会阻塞；当入队数量接近容量上限时，驱动会阻塞入队调用，等待前面已入队的任务执行完成、腾出队列空间后才会返回，这个阻塞临界点对应的入队总数，就是当前场景下流的实际可用容量，该方法不会把队列塞到报错，对运行中业务的干扰极小。
• 驱动日志观测：设置环境变量CUDA_LOG_LEVEL=5开启驱动级调试日志，运行业务入队逻辑，当日志中首次出现队列资源不足、等待队列腾出空间的提示时，对应日志记录的当前队列深度，就是实际业务负载下的流容量阈值，该方法不需要修改业务代码，适配性最强。

实操提示：不要在生产代码中依赖固定的流容量数值做逻辑判断，CUDA大版本迭代、GPU架构升级都可能调整流队列的底层实现，最稳妥的做法是给所有入队操作加返回值检查，遇到队列资源不足的错误码时短暂让出CPU时间片，等待队列腾出空间后重试即可。

内容的提问来源于stack exchange，提问作者einpoklum