Acoplamiento de GPU AutoDock/GPU compatible con Vina a escala

El acoplamiento es un trabajo de rendimiento. Las GPU tienen sentido cuando se preparan entradas limpias y se ejecutan muchas réplicas en paralelo. En esta guía se muestra cómo ejecutar el acoplamiento de una GPU, procesar miles de ligandos por lotes y realizar un seguimiento coste por cada 10 000 ligandos.

Qué cubriremos

• Escogiendo un Plantilla preparada para CUDA en tu arrendador de GPU y trayendo los binarios de acoplamiento
• Mínimo preparación de receptor/ligando que no se desmorona a mitad de carrera
• UN lanzador de lotes que llena la GPU sin hacer de niñera
• UN autoevaluación aprovecha y calcula los costos que puedes copiar
• VRAM, E/S de archivos y trampas de errores comunes

Start in seconds with the fastest, most affordable cloud GPU clusters.

Launch an instance in under a minute. Enjoy flexible pricing, powerful hardware, and 24/7 support. Scale as you grow—no long-term commitment needed.

Try Compute now

1) Elige tu imagen

En la mayoría de los arrendatarios de GPU, su trabajo se ejecuta dentro de una imagen. Dos rutas que funcionan bien:

A) Usa una plantilla CUDA y monta herramientas de acoplamiento (simple)

• Plantilla: Ubuntu 24.04 LTS (CUDA 12.6)
• Instale o monte los binarios de GPU compatibles con AutoDock-GPU/Vina en el contenedor durante el tiempo de ejecución (manténgalos fuera de la imagen).

B) Traiga su propia imagen (la más rápida de reutilizar)

• Crea una imagen privada que contenga tus herramientas de acoplamiento y tu pila de Python para prepararla.
• Añadir variables de entorno:
  • NVIDIA_VISIBLE_DEVICES=Todos
  • NVIDIA_DRIVER_CAPABILITIES=Computación, utilidad
• El script de entrada imprime versiones, crea /trabajo, y espera (o inicia el lote).

Tú sí no necesita Docker‑in-Docker en general, ya que su proveedor pasa el controlador del host a su contenedor.

2) Preparación de entrada mínima que es reproducible

Diseño del directorio

/trabajo
├── receptor/
│ ├── proteína.pdbqt
│ ── grid/ # mapas y configuración
├── ligandos/
│ ├── L000001.pdbqt
│ ├── L000002.pdbqt
│ ──...
── empleos/
── (sale aquí)


Receptor

• Prepárate una vez con tu canalización estándar. Ahorra PDBQT y los archivos de configuración y caja de cuadrícula utilizados por su herramienta de acoplamiento.
• Mantenga un archivo README con el centro/tamaño y cualquier opción de protonación.

Ligandos

• Convertir a PDBQT en un paso de preparación separado (SMILES/SDF → PDBQT). Mantenga un determinista script que establece la protonación, los tautómeros y las cargas de la misma manera cada vez.
• Valida acoplando un panel minúsculo primero (10—20 ligandos) y revisando las poses/puntuaciones.

3) Lanzador de lotes (GPU única)

Este esqueleto ejecuta los ligandos en pequeños fragmentos, mantiene la GPU alimentada y escribe registros que puede analizar más adelante. Sustituya el DOCK_CMD con la llamada exacta de la herramienta (AutoDock-GPU, Vina-GPU, Uni-Dock, etc.).

#! /usr/bin/env bash
establecer -euo pipefail
LIG_DIR=$ {1: -ligandos}
OUT_DIR=$ {2: -trabajos}
N_PAR=$ {3: -8} # procesos simultáneos por GPU (ajuste)
mkdir -p «$OUT_DIR»

# Edita esto según tu comando de acoplamiento. Ejemplos de marcadores de posición:
# autodock_gpu --lrigid receptor/protein.pdbqt --receptor de archivos/grid/maps.fld\
<ligand.pdbqt># --lfile --center_x... --centro_y... --center_z... --tamaño_x... --tamaño_y... --tamaño_z... \
<out.pdbqt># --exhaustividad 8 --out --log <out.log>

DOCK_CMD () {:;}

exportar -f DOCK_CMD
ls «$LIG_DIR» /*.pdbqt | awk '{print NR, $0}' | mientras lee idx lig; do
base=$ (nombre base «$lig» .pdbqt)
out="$OUT_DIR/$BASE»
mkdir -p «$out»
(
DOCK_CMD «$lig» «$out» >"$out/run.log» 2>&1 || echo «FAIL $base» >> «$OUT_DIR/failures.txt»
) y
# acelerador simple
if (($ (jobs -rp | wc -l) >= N_PAR)); luego espera -n; fi

terminado
espera

echo «Listo. Salidas en $OUT_DIR/»


Afinación N_PAR

• Comience con 4—8 procesos por GPU y, a continuación, aumentan hasta que la utilización ronde el ~ 90% sin afectar a la VRAM.
• Reloj nvidia-smi para memoria y utilización.

4) Ampliación horizontal de múltiples GPU

Si tu instancia tiene Sin GPU, lanza un lote por GPU y fija cada grupo de procesos:

# GPU 0
CUDA_VISIBLE_DEVICES=0 ligandos bash dock_batch.sh jobs/gpu0 8 &
# GPU 1
CUDA_VISIBLE_DEVICES=1 ligandos bash dock_batch.sh jobs/gpu1 8 &
espera


Mantenga las salidas separadas por GPU para facilitar la auditoría.

5) Autoevaluación y cálculo de costos

Registra solo lo que importa:

entradas: N_ligandos, receptor, cuadrícula (centro/tamaño), exhaustividad/semilla
hardware: modelo de GPU/VRAM, CUDA, controlador
código: versión de la herramienta de acoplamiento + banderas
métricas: ligandos/hora, fallas, wall_hours


Coste por cada 10 000 ligandos

cost_por_10k = precio_por_hora × horas_pared × (10_000/ N_ligandos)


Informe ligandos/hora y coste por 10 000 por GPU. Mantén la línea de comandos completa en tus métodos.

6) Perillas prácticas que mejoran el rendimiento

• Exhaustividad y pasos de búsqueda: la palanca más grande. Busca la configuración más baja que supere tu verificación de enriquecimiento anticipado.
• Tamaño del lote (N_PAR): suba hasta que la VRAM o los cambios de contexto lo detengan. Moléculas pequeñas → N_PAR más alto.
• I/O: escribe solo lo que necesitas. Evite los registros de perplejidad cuando revise millones.
• Semillas: corrija las semillas para que puedan compararse entre las ejecuciones; si lo prefiere, cámbielas de forma aleatoria para la pantalla final.

7) Solución de problemas

ZOOM DE GPU
Reduzca el N_PAR, reduzca la exhaustividad o cambie a una GPU con VRAM más grande.

Todos los trabajos fallan rápidamente
Cuadrícula defectuosa o indicadores incompatibles. Vuelva a ejecutar un único ligando con un registro detallado y compárelo con una ejecución de CPU que se sepa que es correcta.

Puntuaciones o poses raras
Diferencias de preparación de entrada (protonación/tautómeros/cargas). Normaliza tu preparación y prueba en una pequeña colección seleccionada.

GPU inactiva
N_PAR es demasiado bajo o la herramienta tiene etapas de CPU previas y posteriores largas. Paralelice las cuadrículas de preparación o previas a la etapa.

Fragmento de métodos (copiar y pegar)

hardware:
gpu: "<model>(<VRAM>GB)»
conductor: "<NVIDIA driver>»
<CUDA version>cuda: "»
software:
imagen: "<your docking image or CUDA template>»
<ver><ver>herramienta: «Autodock-GPU <ver>| Vina-GPU | Uni-Dock»
entradas:
receptor: «proteína.pdbqt»
cuadrícula: {centro: [<x>,<y>,<z>], tamaño: [<sx>,<sy>,<sz>]}
<path>ligandos: «N=<... > de»
correr:
lote:
script: "dock_batch.sh»
N_PAR: <int>
banderas: «<exhaustiveness, seed, etc.>»
salidas:
ligandos_por_hora: «<... >»
wall_hours: «<... >»
cost_por_10k: «<... >»
fallas: "<count>(<file path>)»


Lectura relacionada

• Modelado científico de GPU en la nube: qué funciona y qué no

Prueba Compute hoy

Inicia una instancia de GPU con una plantilla preparada para CUDA (p. ej., Ubuntu 24.04 LTS/CUDA 12.6) o tu propia imagen de GROMACS. Disfrute de una facturación flexible por segundo con plantillas personalizadas y la posibilidad de iniciar, detener y reanudar las sesiones en cualquier momento. ¿No está seguro de los requisitos de FP64? Póngase en contacto con el servicio de asistencia para que le ayuden a seleccionar el perfil de hardware ideal para sus necesidades informáticas.

‍