我看过很多针对特定案例特定问题的具体帖子，但没有基本的动机解释。这是什么错误：
RuntimeError: CUDA error: device-side assert triggered
是什么意思？具体来说，被触发的断言是什么，为什么会出现断言，以及我们如何逆向调试问题？
照原样，此错误消息在诊断任何问题时几乎无用，因为它似乎在说“某些触及 GPU 的代码”有问题。 Cuda 的文档在这方面似乎也没有帮助，尽管我可能是错的。 https://docs.nvidia.com/cuda/cuda-gdb/index.html
【问题讨论】：
如果在 CUDA 设备代码运行时检测到设备端错误，则会通过通常的CUDA runtime API error reporting mechanism 报告该错误。设备代码中通常检测到的错误类似于非法地址（例如，尝试取消引用无效指针），但另一种类型是设备端断言。每当设备代码中出现 C/C++ assert() 且断言条件为 false 时，都会生成此类错误。
此类错误是由特定内核引起的。 CUDA 中的运行时错误检查必然是异步的，但可能至少有 3 种可能的方法可以开始调试。
修改源代码以有效地将异步内核启动转换为同步内核启动，并在每次内核启动后进行严格的错误检查。这将识别导致错误的特定内核。此时，只需查看内核代码中的各种断言就足够了，但您也可以使用下面的步骤 2 或 3。
使用cuda-memcheck 运行您的代码。这是一个类似于“用于设备代码的 valgrind”的工具。当您使用cuda-memcheck 运行代码时，它往往会运行得更慢，但运行时错误报告将得到增强。通常最好使用-lineinfo 编译您的代码。在这种情况下，当触发设备端断言时，cuda-memcheck 将报告断言所在的源代码行号，以及断言本身和错误的条件。您可以查看here 来了解如何使用它（尽管会出现非法地址错误而不是assert()，但使用assert() 的过程将是相似的。
也应该可以使用调试器。如果您使用诸如 cuda-gdb 之类的调试器（例如在 linux 上），那么调试器将具有回溯报告，该报告将指示断言在哪一行被击中。
如果 CUDA 代码是从 python 脚本启动的，则cuda-memcheck 和调试器都可以使用。
此时您已经发现了断言是什么以及它在源代码中的位置。为什么它在那里无法笼统地回答。这将取决于开发人员的意图，如果没有注释或其他明显的，您将需要一些方法来以某种方式直觉。 “如何向后工作”的问题也是一个通用的调试问题，并非特定于 CUDA。您可以在 CUDA 内核代码中使用 printf，也可以使用像 cuda-gdb 这样的调试器来协助完成此操作（例如，在断言之前设置断点，并在断言即将执行时检查机器状态 - 例如变量命中）。
【讨论】：
在我的例子中，这个错误是因为我的损失函数只接收到 [0, 1] 之间的值，而我正在传递其他值。
所以，标准化我的损失函数输入，解决这个问题：
saida_G -= saida_G.min(1, keepdim=True)[0]
saida_G /= saida_G.max(1, keepdim=True)[0]
阅读：link
【讨论】：
当我将代码转换为在 CPU 而非 GPU 上工作时，出现以下错误：
IndexError: index 128 is out of bounds for dimension 0 with size 128
所以，也许代码中可能有一个错误，由于某种奇怪的原因导致 CUDA 错误。
【讨论】：