Thanks for your advise. I checked all the environment path, I’m pretty sure that I used the same CUDNN dir which is version 7.1.4 and I also build other frameworks with this path.
Following is the warning log I found:
CMake Warning at cmake/Modules_CUDA_fix/upstream/FindCUDA.cmake:1836 (add_library):
Cannot generate a safe runtime search path for target caffe2_gpu because
files in some directories may conflict with libraries in implicit 
directories: 

runtime library [libcudnn.so.7] in /mnt/lustre/sjtu/users/mkh96/tools/cuda-9.0/lib64 may be hidden by files in: 

/users/xxx/miniconda3/envs/pytorch/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
cmake/public/utils.cmake:134 (cuda_add_library) 
caffe2/CMakeLists.txt:227 (torch_cuda_based_add_library)
-- Generating done

CMake Warning:
 Manually-specified variables were not used by the project:   
CUDNN_LIB_DIR

Above was part of the problem building log, /users/xxx/miniconda3/envs/pytorch/lib is my pytorch conda dir.
I use this python to compile pytorch source, but for Gods sake, I DO set CUDNN_LIB_DIR to another dir, because I have mxnet, tensorflow, kaldi, and so many frameworkds to use, all of them share a common environment path.
So, it’s my fault, I didn’t check the log carefully, I should not skip any warnings.
But I still want to mention: Why not use user set environment but search a confused dir ?
User set environment should be the first order, but in the log, the program didn’t take it.
This makes us can not trust your framework, we don’t know when or how some errors or bugs occur, and we would be really confused about those things, waste so many time.
I hope you considering it.