我完全理解你的困惑——从cudaSetValidDevices的函数名来看，很容易默认它会把未列入的设备彻底“拉黑”，不让任何相关操作碰它们。但实际测试结果和预期不符，这确实容易让人摸不着头脑，我来给你拆解一下背后的原因：

首先要明确**cudaSetValidDevices的实际作用边界**：它的核心是限制CUDA上下文的创建范围，也就是不允许在未指定的设备上创建可用于执行核函数、分配内存的有效上下文，但并不会完全屏蔽对这些设备的基础信息查询或设备切换尝试（只是切换后无法实际使用）。

针对你代码里的各个API表现，具体解释如下：

• cudaGetDeviceCount返回实际设备总数：这个API是直接查询系统中所有具备CUDA能力的硬件设备数量，不受cudaSetValidDevices的限制，因为它不需要和CUDA上下文交互，只是读取系统硬件信息。
• cudaSetDevice(0)返回成功：这个调用只是标记“后续CUDA操作尝试使用设备0”，但并没有实际创建上下文。只有当你执行需要上下文的操作（比如内存分配、核函数启动）时，才会触发错误检查，这时候才会返回cudaErrorInvalidDevice。
• cudaGetDeviceProperties(0)正常返回设备信息：这个API同样只是读取设备的静态硬件属性（比如显存大小、计算能力），不需要创建CUDA上下文，所以即使设备不在有效列表里，也能正常调用并返回数据。

如果你想验证“设备0确实无法被实际使用”，可以在你的代码里加一段实际的CUDA操作测试，比如：

// 在cudaSetDevice(0)之后添加：
float* d_test;
err = cudaMalloc(&d_test, 1024);
std::cout << "cudaMalloc on device 0: " << cudaGetErrorString(err) << "\n";
if (d_test) cudaFree(d_test);

运行这段修改后的代码，你会发现cudaMalloc会返回invalid device错误，这才是cudaSetValidDevices真正生效的地方——它阻止了在未授权设备上创建可工作的CUDA上下文，从而无法执行任何实际的CUDA计算或内存操作。

总结一下：cudaSetValidDevices的设计目标是管控程序可使用的计算资源（即能在哪些设备上运行CUDA任务），而不是完全隐藏设备的存在或禁止查询设备的基础信息。它的限制是针对“可执行的CUDA上下文创建”，而非所有和设备相关的API调用。

内容来源于stack exchange