Station d'accueil à grande échelle pour GPU AutoDock‑GPU/compatible VINA

L'amarrage est un travail de haut débit. Les GPU sont utiles lorsque vous préparez des entrées propres et que vous exécutez de nombreuses répliques en parallèle. Ce guide explique comment exécuter la station d'accueil du GPU, regrouper des milliers de ligands et suivre coût par 10 000 ligands.

Ce que nous allons couvrir

• Choisir un Modèle prêt pour CUDA sur votre loueur de GPU et apporter les fichiers binaires d'amarrage
• Minimale préparation de récepteurs/ligands qui ne s'effondre pas à mi-parcours
• UNE lanceur de lots qui remplit le GPU sans faire de baby-sitting
• UNE auto‑évaluation des calculs d'exploitation et de coûts que vous pouvez copier
• VRAM, E/S de fichiers et pièges d'erreurs courants

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) Choisissez votre image

Sur la plupart des loueurs de GPU, votre tâche s'exécute à l'intérieur d'une image. Deux méthodes qui fonctionnent bien :

A) Utilisez un modèle CUDA + montez des outils d'ancrage (simple)

• Modèle : Ubuntu 24.04 LTS (CUDA 12.6)
• Installez ou montez des fichiers binaires GPU compatibles AutoDock‑GPU/VINA dans le conteneur au moment de l'exécution (gardez-les en dehors de l'image).

B) Apportez votre propre image (la plus rapide à réutiliser)

• Créez une image privée contenant vos outils d'ancrage + une pile Python pour la préparation.
• Ajoutez des variables d'environnement :
  • NVIDIA Visible_Devices = Tous
  • NVIDIA Driver_Capabilities=Calcul, utilitaire
• Le script d'entrée imprime les versions, crée /travail, et attend (ou démarre le lot).

Tu le fais pas avez besoin de Docker‑in‑Docker en général lorsque votre fournisseur transmet le pilote hôte à votre conteneur.

2) Préparation minimale des entrées reproductible

Disposition du répertoire

/travail
Recepteur/
proteine.pdbqt
・─ grid/ # cartes et configuration
─ ligands/
│ ─ L000001.pdbQT
│ ─ L000002.pdbQT
│ ─...
─ emplois/
(sorties ici)


Récepteur

• Préparez-vous une fois avec votre pipeline standard. Enregistrer PDBQT et les fichiers grid box/config utilisés par votre outil d'ancrage.
• Conservez un fichier README avec le centre/la taille et tous les choix de protonation.

Ligands

• Convertir en PDBQT dans une étape de préparation distincte (SMILES/SDF → PDBQT). Gardez un déterministe script qui définit la protonation, les tautomères et les charges de la même manière à chaque fois.
• Validez en connectant un petit panneau d'abord (10 à 20 ligands) et en passant en revue les poses/scores.

3) Lanceur par lots (GPU unique)

Ce squelette exécute des ligands en petits morceaux, alimente le GPU et écrit des journaux que vous pourrez analyser ultérieurement. Remplacez le DOCK_CMD avec l'appel exact de votre outil (AutoDock‑GPU, Vina‑GPU, Uni-Dock, etc.).

# ! /usr/bin/env bash
Tuyauterie set -euro
LIG_DIR=$ {1 : -ligands}
OUT_DIR=$ {2 : -jobs}
N_PAR=$ {3 : -8} # processus simultanés par GPU (réglage)
mkdir -p « $OUT_DIR »

# Modifiez ceci dans votre commande d'ancrage. Exemples d'espaces réservés :
# autodock_gpu --récepteur rigide/protéine.pdbqt --file receptor/grid/maps.fld \
<ligand.pdbqt># --file --center_x... --center_y... --center_z... --taille_x... --taille_y... --taille_z... \
<out.pdbqt># --exhaustivité 8 --out --log <out.log>

DOCK_CMD () {: ;}

export -f DOCK_CMD
ls « $LIG_DIR » /*.pdbqt | awk '{print NR, $0}' | pendant la lecture du journal idx ; do
base=$ (nom de 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 »
) et
# accélérateur simple
if (($ (jobs -rp | wc -l) >= N_PAR)) ; puis attendez -n ; fi

fait
attente

echo « C'est fait. Sorties dans $OUT_DIR/ »


Réglage de N_PAR

• Commencez par 4 à 8 processus par GPU, puis augmentez jusqu'à ce que l'utilisation oscille autour d'environ 90 % sans bousculer la VRAM.
• Montre nvidia-smi pour la mémoire et l'utilisation.

4) Scale‑out multiprocesseur

Si votre instance possède Pas de GPU, lancez un lot par GPU et épinglez chaque groupe de processus :

# GPU 0
CUDA_VISIBLE_DEVICES=0 bash dock_batch.sh ligands jobs/gpu0 8 et
# CARTE GRAPHIQUE 1
CUDA_VISIBLE_DEVICES=1 bash dock_batch.sh ligands jobs/gpu1 8 et
attente


Séparez les sorties par GPU pour faciliter l'audit.

5) Auto-évaluation et calcul des coûts

Enregistrez uniquement ce qui compte :

entrées : N_ligands, récepteur, grille (centre/taille), exhaustivité/graine
matériel : modèle GPU/VRAM, CUDA, pilote
code : version de l'outil d'ancrage + drapeaux
métriques : ligands/heure, échecs, wall_hours


Coût par 10 000 ligands

coût_par_10 000 = prix_par_heure × mur_heures × (10_000/N_ligands)


Rapport ligands/heure et coût par 10 000 par GPU. Conservez la ligne de commande complète dans vos méthodes.

6) Boutons pratiques qui permettent de déplacer le débit

• Exhaustivité/étapes de recherche: plus gros levier. Trouvez le réglage le plus bas qui passe avec succès votre test d'enrichissement précoce.
• Taille du lot (N_PAR): augmentez jusqu'à ce que la VRAM ou les changements de contexte vous bloquent. Petites molécules → N_PAR plus élevé.
• E/S: n'écrivez que ce dont vous avez besoin. Évitez les journaux de tâches trop bavards lorsque vous filtrez des millions de personnes.
• Graines: fixez les graines pour des raisons de comparabilité entre les essais ; si vous préférez, répartissez-les au hasard pour la sélection finale.

7) Résolution des problèmes

CHAMBRE GPU
Réduisez le N_PAR, réduisez l'exhaustivité ou passez à un GPU VRAM plus grand.

Toutes les tâches échouent rapidement
Mauvaise grille ou drapeaux incompatibles. Réexécutez un seul ligand avec une journalisation détaillée et comparez-le à un fonctionnement du processeur, dont le fonctionnement a été vérifié.

Des scores ou des poses étranges
Différences de préparation des entrées (protonation/tautomères/charges). Normalisez votre préparation et testez sur un petit ensemble organisé.

GPU inactif
N_PAR est trop faible ou l'outil a de longs stades de pré/post-traitement du processeur. Parallélisez les grilles de préparation ou de pré-étape.

Extrait de méthodes (copier-coller)

matériel :
processeur graphique : « <model>(<VRAM>Go) »
chauffeur : « <NVIDIA driver>»
<CUDA version>cuda : « »
logiciel :
image : « <your docking image or CUDA template>»
<ver><ver>outil : « AutoDock-GPU <ver>| Vina-GPU | Uni-Dock »
entrées :
récepteur : « protein.pdbqt »
grille : {centre : [<x>,<y>,<z>], taille : [<sx>,<sy>,<sz>]}
<path>ligands : « N=<... > de »
courir :
lot :
script : « dock_batch.sh »
N_PAR : <int>
drapeaux : « <exhaustiveness, seed, etc.> »
sorties :
ligands par heure : « <... > »
wall_hours : « <... > »
coût_par_10 000 : « <... > »
échecs : "<count>(<file path>) »


Lecture associée

• Modélisation scientifique sur les GPU cloud : ce qui fonctionne et ce qui ne fonctionne pas

Essayez Compute dès aujourd'hui

Démarrez une instance GPU avec un modèle compatible CUDA (par exemple, Ubuntu 24.04 LTS/CUDA 12.6) ou votre propre image GROMACS. Profitez d'une facturation flexible à la seconde avec modèles personnalisés et la possibilité de démarrer, d'arrêter et de reprendre vos sessions à tout moment. Vous n'êtes pas sûr des exigences du FP64 ? Contactez le support pour vous aider à sélectionner le profil matériel le mieux adapté à vos besoins informatiques.

‍