关于一个运行时编译错误Async error报错的问题

与上个帖子同样的业务场景,需要在同一进程中利用多个深度学习框架依次训练一个模型结构队列中的模型,目前涉及:tensorflow、torch和jittor。目前,在部分算子上会出现一个以下报错的bug:

RuntimeError: [f 0411 09:17:36.648324 44 executor.cc:590]
Execute fused operator(627/659) failed.
[JIT Source]: /XXXXX/.cache/jittor/jt1.3.2/g++9.3.0/py3.7.10/Linux-5.4.0-74xbd/IntelRCoreTMi7x2c/default/cu11.2.152_sm_61/jit/opkey0_broadcast_to_Tx_float32__DIM_3__BCAST_1___opkey1_broadcast_to_Tx_float32__DIM_3__B___hash_938618f556fac625_op.cc
[OP TYPE]: fused_op:( broadcast_to, broadcast_to, binary.multiply, reduce.add,)
[Input]: float32[10,112112,], float32[100,112112,],
[Output]: float32[100,10,],
[Async Backtrace]: not found, please set env JT_SYNC=1, trace_py_var=3
[Reason]: [f 0411 09:17:36.648064 44 helper_cuda.h:128] CUDA error at /XXXXX/.cache/jittor/jt1.3.2/g++9.3.0/py3.7.10/Linux-5.4.0-74xbd/IntelRCoreTMi7x2c/default/cu11.2.152_sm_61/jit/cublas_matmul_T_float32__Trans_a_N__Trans_b_T__op_S__JIT_1__JIT_cuda_1__index_t_int32__hash_820355a267a6f79_op.cc:143 code=14( CUBLAS_STATUS_INTERNAL_ERROR ) cublasGemmEx(handle
, CUBLAS_OP_T, CUBLAS_OP_N, k, n, m, &alpha, b->ptr(),get_dtype(b->dtype()), ‘T’ == ‘N’ ? k : m, a->ptr(),get_dtype(a->dtype()), ‘N’ == ‘N’ ? m : n, &beta, c->ptr(),get_dtype(c->dtype()), k, computeType, algo)


Async error was detected. To locate the async backtrace and get better error report, please rerun your code with two enviroment variables set:

export JT_SYNC=1
export trace_py_var=3
设置日志中的环境变量后,同样是追踪到matmul_transpose算子

另外,针对此bug,我起初以为是自己的代码问题,逐步检查了代码,并将大多数其他代码注释掉后还是会出现上述报错。奇怪的是,当我将训练这单个模型的三个框架版本的报错代码提取出来单独运行时,程序则可以成功运行。我能想到的能引发这种奇怪不一致的问题的,只可能是同步问题,但由于不清楚底层原理,无法定位原由,烦请各位指导

注:

os.environ[“CUDA_DEVICE_ORDER”] = “PCI_BUS_ID”
os.environ[“CUDA_VISIBLE_DEVICES”] = “0,1”
jittor.flags.use_cuda = 1
jittor.flags.lazy_execution = 0
jittor.flags.use_cuda_managed_allocator = 0

cuda11.2,双显卡
代码报错位置位于自定义训练流程循环每个batch的for循环末尾,从内容上看,与代码无关(之前报错定位在我的一个自定义metric的状态更新处,注释掉后,即定位在末尾的反向传播处),部分代码:

        loss_value = train_loss(out, y_no_one_hot)
        # 后面三句相当于train_optim.step(loss_value)
        train_optim.zero_grad()
        train_optim.backward(loss_value)
        train_optim.step()
        # metrics
        # loss_metric_train.update_state(loss_value)
        # for m in metrics_dict_train.values():
        #     m.update_state(y, out)

您好,可能是由于框架之间的动态链接了不同版本的 cublas 库导致的。

您可以先检查一下运行环境、几个框架的cuda版本、cublas版本是否存在不同。

您好,我检查了一下框架版本,发现确实存在cuda版本的差异,但我仍有两个疑问:

  1. 我的服务器应该是使用了一个稍高版本的驱动版本,从而导致driver API版本为cuda11.2,但实际安装的cuda版本为10.1,导致runtime API版本为10.1。通过搜索得知,一般框架实际使用均以runtime API版本为准(本服务器上tensorflow和torch均使用了cuda10.1),而jittor日志上显示使用了cuda11.2,请问这其中是否包括bug,或是基于什么思想如此设计?
  2. 能否通过某些参数或设置修改jittor使用API的方式或版本?
    谢谢您的解答~

您好,

  1. Tensorflow / pytorch 在构建期间就已经指定了 cuda 版本,而Jittor 会适应用户的系统环境,使用系统默认路径下的 cuda 来编译 gpu 代码。您可以运行 which nvcc 查看默认的 cuda 版本。

  2. 您可以设置环境变量 nvcc_path 来指定 jittor 使用的 cuda 版本

export nvcc_path=/usr/local/cuda-10.1/bin/nvcc
python3.7 -m jittor.test.test_core
#or
nvcc_path=/usr/local/cuda-10.1/bin/nvcc python3.7 -m jittor.test.test_core

您好,根据您的方案,我已将cuda版本统一为10.1,且将gcc、g++版本降级为8,但仍然出现下示报错(与之前的一样),目前看来似乎不是cuda版本不一致引起的:


我进行了进一步的实验,定位了引起该bug的代码层面原因,但我并不知道是什么导致这行代码产生了影响,望解答,谢谢,以下是问题描述:
出于上一条帖子的原因,我将jittor.flags.use_cuda_managed_allocator设置为0,将环境变量CUDA_VISIBLE_DEVICES设置为"0,1",同时使得torch均使用cuda:1的设备,并将main代码包裹在with tf.device(‘/device:gpu:1’):下,本意是希望jittor单独使用gpu0,tf和torch共同使用gpu1。但问题就出在with tf.device(‘/device:gpu:1’):上,当我将它改为gpu:0,问题就不会出现,反之,为1就会出现。
我的import顺序是tensorflow → torch → jittor,我尝试过jittor先import,但是,即使我在import后立刻将flag设置为0,后续框架的导入仍然会直接报无效指针异常。