Docking moléculaire sur GPU : AutoDock-GPU et moteurs Vina

Le docking moléculaire sur GPU exige des entrées validées, un moteur identifié et une liste de tâches reproductible. Ce guide décrit les contrôles de préparation et de répartition d’un criblage, puis la mesure des résultats et du coût. Il ne propose pas de lanceur interchangeable entre AutoDock-GPU et les moteurs fondés sur Vina.

Ce que nous allons couvrir

• Choisir une image de conteneur compatible et installer le moteur de docking retenu
• Préparer des entrées reproductibles pour le récepteur et les ligands
• Un plan de traitement par lots avec contrôle des résultats et des échecs
• Une liste de mesures et des calculs de coûts
• VRAM, E/S de fichiers et pièges d'erreurs courants

Préparer et valider votre calcul GPU

Vérifiez la configuration disponible et la compatibilité logicielle avant le lancement. Comparez les résultats à une référence et sauvegardez vos entrées et sorties hors de l’instance.

Try Compute now

1) Choisissez votre image

Pour un déploiement en conteneur, évaluez ces deux options de configuration :

A) Utiliser un modèle CUDA compatible et ajouter les outils de docking

• Choisissez une image compatible avec le moteur, le pilote et le GPU retenus. Consignez son empreinte et les versions logicielles ; la présence de CUDA ne suffit pas.
• Suivez les instructions de la version du moteur choisi. Ne mélangez pas les arguments d’AutoDock-GPU avec ceux des moteurs de la famille Vina.

B) Construire une image réutilisable

• Créez une image privée contenant le moteur de docking et les outils Python nécessaires à la préparation.
• Ajoutez des variables d'environnement :
  • NVIDIA_VISIBLE_DEVICES=all
  • NVIDIA_DRIVER_CAPABILITIES=compute,utility
• Le script de démarrage doit afficher les versions et vérifier le répertoire de travail, les entrées et les droits d’écriture avant de lancer les tâches.

Suivez les instructions du fournisseur pour son environnement de conteneurs. Docker imbriqué n’est pas requis pour la procédure décrite ici ; l’accès au GPU dépend de l’environnement hôte et des périphériques attribués.

2) Préparation minimale des entrées reproductible

Disposition du répertoire

Séparez les fichiers du récepteur, les grilles, les ligands et les sorties. Attribuez un identifiant stable et unique à chaque ligand et un nouveau répertoire à chaque exécution ; un ancien résultat ne prouve pas la réussite d’une nouvelle tâche.

Récepteur

• Pour AutoDock-GPU, utilisez les cartes de grille et les ligands prescrits par le moteur. La documentation du projet décrit son interface de traitement par lots. Les autres moteurs ont leurs propres réglages de préparation et de score.
• Consignez dans un fichier README le centre et les dimensions de la zone de recherche, ainsi que les choix de protonation.

Ligands

• Convertissez les ligands au format PDBQT dans une étape distincte de préparation (SMILES/SDF → PDBQT). Conservez un script déterministe qui applique les mêmes règles de protonation, de tautomérie et de calcul des charges.
• Validez d’abord le docking sur un petit jeu de référence, par exemple 10 à 20 ligands, puis examinez les poses et les scores.

3) Valider un lot sur un GPU

Choisissez un moteur et fixez sa version avant de construire un lanceur. Exécutez d’abord un petit jeu de référence avec l’exemple du moteur. Vérifiez les poses, les scores, le statut de sortie et les fichiers attendus.

Utilisez un manifeste reliant chaque tâche à son ligand, son récepteur, ses réglages et une sortie unique. Le lanceur doit appeler le moteur réel, attendre toutes les tâches, relever les échecs et vérifier les fichiers avant d’annoncer une réussite. Une fonction vide ne valide pas un lot. Privilégiez l’interface de traitement par lots du moteur si elle remplit ces conditions.

Choisir le nombre de tâches simultanées

• Commencez par un flux de tâches validé. Augmentez la concurrence seulement si le débit mesuré progresse sans dépasser la mémoire ni modifier la qualité des résultats. Aucun nombre fixe de processus ni objectif d’utilisation ne convient à tous les moteurs.
• Surveillez nvidia-smi pour mesurer la mémoire et l’utilisation du GPU.

4) Répartir les tâches entre GPU

Répartissez le manifeste en ensembles de tâches disjoints. Le choix du GPU et la répartition des entrées sont deux opérations distinctes : changer le GPU visible ne change pas les ligands lus.

Avant le lancement, vérifiez que l’union des partitions couvre toutes les tâches prévues et que leurs intersections sont vides, sauf répliques volontaires identifiées séparément. Donnez à chaque processus sa partition et son répertoire de sortie. Vérifiez la numérotation des GPU utilisée par le moteur et l’environnement.

Comparez les identifiants terminés au manifeste. Distinguez les sorties manquantes, dupliquées et échouées ; des répertoires différents n’empêchent pas le calcul en double.

5) Mesure des performances et calcul des coûts

Enregistrez uniquement ce qui compte :

Consignez le moteur, sa version, le manifeste, la préparation, les paramètres de recherche, les graines, le matériel et le temps écoulé. Comptez séparément les tâches tentées, les résultats validés, les échecs et les répliques volontaires.

Coût par 10 000 ligands

Pour un nombre non nul de tâches validées : coût normalisé pour 10 000 = coût total mesuré × 10 000 / nombre de tâches validées. Précisez s’il s’agit de ligands uniques ou de répliques et incluez le coût facturé des échecs.

Indiquez le débit et le coût globaux avec le nombre de GPU et la définition d’une tâche. Expliquez toute ventilation par GPU ; ne combinez pas le prix de l’instance entière avec un dénominateur limité à un GPU.

6) Paramètres qui influencent le débit

• Paramètres de recherche : utilisez ceux du moteur choisi. Toute réduction de l’effort de recherche impose de répéter les contrôles de qualité.
• Concurrence : mesurez la mémoire et le débit de tâches terminées avant d’ajouter des processus.
• Entrées/sorties : conservez les journaux et résultats nécessaires à la vérification. Réduisez les sorties inutiles après avoir défini ces exigences.
• Graines aléatoires : consignez les graines de chaque exécution et définissez un plan de répétitions pour évaluer la variabilité.

7) Résolution des problèmes

Mémoire GPU épuisée
Réduisez les tâches simultanées ou choisissez une capacité adaptée. Ne réduisez pas silencieusement l’effort de recherche pour faire tenir le calcul.

Toutes les tâches échouent rapidement
Vérifiez les grilles et les options propres au moteur. Relancez un ligand avec des journaux détaillés et comparez le résultat à une référence validée, avec des réglages équivalents.

Scores ou poses inattendus
Vérifiez la préparation des entrées : protonation, tautomères et charges. Appliquez une préparation cohérente et testez-la sur un petit jeu de référence.

GPU peu utilisé
Mesurez la préparation, le docking et l’écriture avant d’ajouter des processus. Confirmez que le moteur s’exécute réellement et produit des résultats validés.

Relevé de méthode

Conservez ensemble le manifeste des entrées, l’empreinte de l’image, la version du moteur, les arguments, les affectations GPU, les graines, les sorties, les durées et les contrôles. Cette liste n’est pas une configuration exécutable.

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

Les modèles personnalisés réutilisent une configuration testée. Vérifiez séparément la compatibilité et la capacité disponible. Sauvegardez les données hors de l’instance et consultez les conditions actuelles de redémarrage et de conservation avant l’arrêt.

‍