企业官网建设流程全解析

本文收录于专栏gnina系列—— 专栏系统覆盖分子对接引擎选型、GPU 加速虚拟筛选与打分函数评估，点击订阅可跟踪后续更新。

你想用 Vina-GPU 给 AutoDock Vina 对接提速，先会被两件事拦住：一是网上流传的加速比从 21.66 倍、191.68 倍到 403 倍都有，根本分不清哪个版本对哪个基准；二是源码拿到 NVIDIA 卡上编译能过、一跑就段崩。这篇先逐源核清初代、2.0、2.1 三代的论文口径（403 倍只存在于预印本、191.68 倍是不含主机开销的设备端口径），再给出一台消费级 GPU（12 GB）机器上把 Vina-GPU 2.1 跑通的完整六坑修复记录——从 OpenCL 地址空间限定符到示例配置里藏着的作者绝对路径，最后用四个体系实测：单配体 1.4–11.4 秒，比同机 Vina-CUDA 慢 1.1–1.6 倍，方向上复现了论文"CUDA 重写优于 OpenCL 移植"的结论。

关键字：Vina-GPU、分子对接、OpenCL、GPU加速、RILC-BFGS、AutoDock Vina、虚拟筛选、内核移植

目录：§0. 相关教程与核心文献 ｜ §1. 软件介绍与版本沿革 ｜ §2. 原理：蒙特卡洛并行与 RILC-BFGS ｜ §3. 特点与边界 ｜ §4. 文献测评口径逐源核对 ｜ §5. NVIDIA 移植六坑实录 ｜ §6. 四体系实测与同机对照 ｜ §7. 结论与选型建议

§0. 相关教程与核心文献

§1. 软件介绍与版本沿革

Vina-GPU 系列出自南京邮电大学 DeltaGroup 团队，思路是把 AutoDock Vina 的蒙特卡洛迭代局部搜索移植到 OpenCL：大量增加初始随机构象数、砍短每条链的搜索深度，用 GPU 数千计算核消化并行。版本谱系三代：初代 Vina-GPU（Molecules 2022，附 Vina-GPU+ 批量版）→Vina-GPU 2.0（JCIM 2023，把格点缓存搬上 GPU，衍生出 QuickVina2-GPU 与 QuickVina-W-GPU）→Vina-GPU 2.1（TCBB 2024，RILC-BFGS 算法降低局部优化迭代数，是当前主线）。许可证全系 Apache 2.0，对商业集成友好。仓库里同时提供 Windows 预编译版与 Linux 源码——注意预编译版动态链接 boost 1.84，与 Ubuntu 22.04 系统的 1.74 不匹配，Linux 用户基本绕不开源码编译。

§2. 原理：蒙特卡洛并行与 RILC-BFGS

Vina 的原始搜索是串行链：一条蒙特卡洛链反复"变异—打分—BFGS 局部优化—接受/拒绝"。Vina-GPU 把链间并行交给 GPU（每链一工作项），同时用启发式公式按配体原子数自动定search_depth。2.0 的增量是格点缓存上卡（多配体共享预计算格点），2.1 的增量是RILC-BFGS——低复杂度 BFGS 变体，削减最耗时步骤的迭代次数，论文口径对 2.0 平均提速 4.97 倍、EF1% 平均提升 342%。这套演进路线（先并行化、再缓存、再算法级重写）本身是 GPU 移植工程的教学样本。

§3. 特点与边界

特点：命令行与 config 文件兼容 Vina 习惯（center/size/thread/exhaustiveness 等同名参数）；一次编译同时得到主引擎与 QuickVina2/QuickVina-W 两个衍生；OpenCL 理论上跨 NVIDIA/AMD/Intel。边界：OpenCL"理论跨平台"与"实际跨平台"之间隔着 §5 的六个坑——作者的内核代码按 AMD 编译器的宽松地址空间写法编写，NVIDIA 工具链上要手工修补；另外它的内核二进制（Kernel*.bin）与 OpenCL 平台绑定，换卡要重新生成。

§4. 文献测评口径逐源核对

这个系列是"加速比张冠李戴"的重灾区，四组数字必须各归各位：

最常见的两个错误：把 21.66×/50.80× 说成"Vina-GPU 2.1 的成绩"；拿 403×（预印本、四线程基准）当现役数字。引用规则很简单——先问"哪一代、对谁、含不含主机开销"。

§5. NVIDIA 移植六坑实录

实测环境（specs）：

第 0 步：系统依赖：

sudoapt-getinstall-ybuild-essential\libboost-system-dev libboost-thread-dev libboost-serialization-dev\libboost-filesystem-dev libboost-program-options-dev libboost-timer-dev\opencl-headers ocl-icd-opencl-dev

第 1 步：获取源码（仓库在 GitHub，clone 抽风时用 codeload tarball 兜底）：

curl-sLhttps://codeload.github.com/DeltaGroupNJUPT/Vina-GPU-2.1/tar.gz/refs/heads/main-ovg21.tgztarxzf vg21.tgz&&mvVina-GPU-2.1-main Vina-GPU-2.1cdVina-GPU-2.1/AutoDock-Vina-GPU-2.1

第 2 步：Makefile 手术（把绑死作者环境的变量改指系统库，即坑 2 的修法）：

WD=$(pwd)sed-i"s|^WORK_DIR=.*|WORK_DIR=$WD|; s|^BOOST_LIB_PATH=.*|BOOST_LIB_PATH=/usr/include|; s|^OPENCL_LIB_PATH=.*|OPENCL_LIB_PATH=/usr|"Makefilesed-i's|^BOOST_INC_PATH=.*|BOOST_INC_PATH=-I/usr/include|; s|^OPENCL_INC_PATH=.*|OPENCL_INC_PATH=-I/usr/include/CL|; s|^SRC=.*|SRC=./lib/*.cpp ./OpenCL/src/wrapcl.cpp|; s|^LIB_PATH=.*|LIB_PATH=-L/usr/lib/x86_64-linux-gnu|'Makefilesed-i's|^LIB1=.*|LIB1=-lboost_program_options -lboost_system -lboost_filesystem -lboost_thread -lOpenCL|'Makefile

第 3 步：NVIDIA 内核补丁（三处地址空间限定符，即坑 4 的修法）：

cdOpenCL/src/kernelssed-i's|const atom_cl\* a = &pa->atoms\[i\];|const __global atom_cl* a = \&pa->atoms[i];|'kernel1.clsed-i's|const float vec_distance_sqr(const float\* a, const float\* b)|const float vec_distance_sqr(const __global float* a, const float* b)|'kernel1.clsed-i'757s/const\tmis_cl\*/const\t__global\tmis_cl*/'quasi_newton.clcd../..

第 4 步：首跑生成内核二进制 + 冒烟（注意先把示例 config 的作者路径改掉，即坑 6）：

makesource-j8# 带运行时内核编译的版本sed-i"s|^opencl_binary_path = .*|opencl_binary_path =$(pwd)|"input_file_example/2bm2_config.txt ./AutoDock-Vina-GPU-2-1--config./input_file_example/2bm2_config.txt# 预期: 打印 Build kernel 1/2 from source → 输出 mode 表(首行约 -8.4 kcal/mol),# 引擎目录生成 Kernel1_Opt.bin / Kernel2_Opt.bin

第 5 步：正式版重编（加载 .bin、跳过运行时编译，正式计时装这个）：

makeclean>/dev/null&&make-j8

六坑按踩中顺序（步骤里已含修法，这里讲清为什么）：

坑 1：预编译版缺 boost 1.84。仓库自带的 Linux 二进制链接libboost_program_options.so.1.84.0，Ubuntu 22.04 只有 1.74——直接报cannot open shared object file，必须源码编译。

坑 2：Makefile 绑死作者环境。WORK_DIR指向作者主目录、BOOST_LIB_PATH指向 boost 源码树（还要现场编译 thread.cpp）。补丁：WORK_DIR 改为当前目录、boost 走系统库（-I/usr/include、-L/usr/lib/x86_64-linux-gnu、-lboost_thread）。

坑 3：普通make不编译 OpenCL 内核。默认目标编译的程序依赖预生成Kernel1_Opt.bin/Kernel2_Opt.bin（仓库里那份是别的平台编的，加载即崩）。正确流程：先make source跑一次生成 .bin，再make clean && make出正式版——正式版直接加载 .bin，跳过运行时编译。

坑 4：OpenCL 地址空间限定符（NVIDIA 严格、AMD 宽松）。三处内核源码要手改：kernel1.cl中const atom_cl*与vec_distance_sqr的签名、quasi_newton.cl的const mis_cl*，各补__global。不改则内核编译直接报changes address space of pointer。

坑 5：OpenCL 版本宏别乱动。内核用了get_global_linear_id（OpenCL 2.0 内建函数）。看到 NVIDIA 平台报 2.0 兼容性问题想改-DOPENCL_1_2？改了反而把这个函数砍掉报 implicit declaration——保持-DOPENCL_2_0，NVIDIA 的 OpenCL 3.0 驱动实际接受该内建。

坑 6：示例 config 藏作者绝对路径。2bm2_config.txt里opencl_binary_path = /home/shidi/Vina-GPU-2.1/...——在本机是空路径，fopen返回 NULL 后代码不做检查直接fseek，段崩且栈帧深埋在SetupBuildProgramWithBinary里。gdb 一把定位；修法是 config 里把该参数指回自己放 .bin 的目录。

§6. 四体系实测与同机对照

四体系（sm_86、SMALL_BOX、thread=8192、exhaustiveness=8 等价配置；3tmn 用去金属受体）：

两个结论：一、同机同体系 Vina-CUDA 比 Vina-GPU 2.1 快 1.06–1.61 倍——论文里"CUDA 重写对 OpenCL 移植平均 3.01 倍"的方向在本机复现，只是幅度温和（消费级卡、小体系、exhaustiveness=8 的场景差异）；二、对 Vina 单核 5.9–9.7 倍，处于文献口径（初代 21.66× 是 20 线程基准、更大 exhaustiveness）的下沿，与 Uni-Dock 篇的"单任务吃不满卡"结论互相印证。能量方面与 Vina CPU 逐体系一致（-11.4 对 -11.42），移植正确。

§7. 结论与选型建议

Vina-GPU 系列的价值在"兼容 Vina 生态 + Apache 2.0 + 一份代码三个衍生引擎"；代价是 OpenCL 移植链路在 NVIDIA 平台的六个坑（本文全部给出一轮修通）。如果你的卡是 NVIDIA 且只求速度，直接用 Vina-CUDA（见下一篇）；如果你的算力是 AMD/Intel 或需要 QuickVina 系衍生，这份 OpenCL 代码修完坑后完全可用——修坑补丁本身也值得提交上游。选型一句话：要兼容选 OpenCL 系，要性能选 CUDA 系，两边都装时用同一套 config 做交叉验证。

系列导航：专栏全集gnina系列—— 上一篇：Uni-Dock 实战测评；下一篇：Vina-CUDA 实战测评。

更多专栏：

我的专栏