Configuration publique de CodonFM

Opérez depuis la racine du repository public CodonFM. Supportez uniquement le code public v1 validé et les checkpoints publics Encodon.

Instructions

1. Déterminez si l'utilisateur souhaite des instructions, un checkpoint téléchargé, un environnement de modèle fonctionnel, ou une combinaison de ces éléments.
2. Pour les instructions de configuration ou le travail à l'exécution, inspectez directement les fichiers et la configuration fournis : le runner, la configuration du modèle, le Dockerfile, le launcher, et les requirements. La configuration à l'exécution nécessite un checkout ; une archive source fournie est suffisante pour préparer les instructions.
3. Vérifiez les limites public-v1. Pour une demande non supportée, inspectez MODEL_ARCHITECTURES dans src/config.py, les modules du modèle, et tout script demandé avant d'expliquer la limite et de terminer ce chemin. Les seuls choix d'arguments du runner n'établissent pas le support d'implémentation.
4. Réutilisez les environnements et checkpoints disponibles, et choisissez les chemins explicites du projet de l'utilisateur.
5. Suivez uniquement les chemins demandés ci-dessous. La configuration de l'environnement seule ne nécessite pas un téléchargement de checkpoint ; téléchargez les poids uniquement quand la demande les nécessite et qu'aucun checkpoint local approprié n'est disponible.

Pour les archives source fournies, inspectez les fichiers sélectionnés avec la bibliothèque standard Python 3 disponible (zipfile.ZipFile.namelist() et read()) sans extraire l'archive entière. Si l'extraction est nécessaire, utilisez un répertoire frais de mktemp -d ou tempfile.mkdtemp(). Préservez les checkouts et répertoires temporaires existants ; ne les supprimez ni ne les écrasez pour préparer une inspection source.

L'optional --dryrun du runner nécessite que les dépendances ML soient déjà installées. Il construit la configuration d'exécution, puis s'arrête avant l'exécution. Il n'installe pas les packages, ne valide pas les données CSV, ni ne charge les poids. La préparation des instructions de configuration ne nécessite pas de l'exécuter.

Rapporter les instructions de configuration

Pour les demandes d'instructions, mettez les commandes complètes pour le chemin de configuration demandé en début de réponse compacte et autonome, même lors de la rédaction d'un guide.

• Pour les téléchargements, utilisez les métadonnées de checkpoint fournis pour le repository exact, la révision, le nom de fichier de poids, et config.json. Montrez le répertoire de destination et gardez les poids et la configuration ensemble.
• Pour les conteneurs, précisez les prérequis Docker/GPU, expliquez le remplacement du conteneur existant avant la commande du launcher, et montrez les chemins explicites des données d'hôte et checkpoint ainsi que le montage checkpoint à /data/checkpoints.
• Pour la configuration directe de l'hôte, incluez python3.11 -m venv, python -m pip install -r requirements.txt, une MPLCONFIGDIR inscriptible, la vérification de torch.cuda.is_available(), et les chemins explicites de checkpoints de l'hôte.
• Précisez quelles vérifications ont réellement été exécutées et ce qui reste non vérifié avant l'exécution du modèle. Les seules instructions écrites n'établissent pas un environnement fonctionnel.

Pour une question de compatibilité uniquement, donnez la réponse basée sur la source concernant la disponibilité sans ajouter une procédure d'installation sans rapport.

Vérification préalable au runtime

Pour un environnement fonctionnel, vérifiez le matériel avant d'installer le runtime : utilisez nvidia-smi s'il est disponible, ou vérifiez CUDA via une installation PyTorch existante. L'exécution réelle du modèle nécessite les dépendances ML et une GPU NVIDIA compatible. Comparez le driver avec la version CUDA requise par le runtime sélectionné en utilisant la guidance de compatibilité NVIDIA. Pour la base nvcr.io/nvidia/pytorch:24.10-py3 du Dockerfile, vérifiez aussi les exigences de driver 24.10. Si un prérequis manque, suivez Gestion des défaillances ci-dessous.

Vérification préalable du conteneur

1. Confirmez que Dockerfile, run_dev.sh, et src/runner.py existent.
2. Confirmez que docker info réussit. Docker doit avoir NVIDIA Container Toolkit configuré pour --gpus all ; la seule visibilité GPU de l'hôte n'établit pas l'accès GPU du conteneur. Vérifiez l'accès dans le conteneur lancé ci-dessous.
3. Exécutez bash -n run_dev.sh avant de le lancer.
4. Résolvez les chemins absolus existants de l'hôte pour les données et checkpoints. Passez toujours les deux drapeaux de chemin au launcher plutôt que de vous fier aux défauts /data/codonfm. Créez les répertoires de projet manquants uniquement si nécessaire pour la demande.
5. Vérifiez un conteneur existant avant le lancement :

docker ps -a --filter name='^/codon-fm-dev-container$'

Si un conteneur de nom exact est en cours d'exécution, run_dev.sh l'arrête et le supprime ; informez l'utilisateur avant le remplacement. S'il est arrêté, le script ne peut pas réutiliser le nom, alors obtenez une confirmation avant le supprimer avec docker rm codon-fm-dev-container. Si la suppression est refusée, préservez le conteneur, ignorez ce lancement, et rapportez le conflit de nom.

Le script public utilise le réseau/IPC de l'hôte et monte le répertoire SSH de l'utilisateur en lecture seule ; divulguez ceci avant l'exécution. Il n'y a aucun drapeau d'opt-out pour ces paramètres. S'ils entrent en conflit avec les contraintes de l'utilisateur, utilisez le chemin direct de l'hôte quand c'est possible ; sinon rapportez que le lancement du conteneur reste bloqué.

Build et lancement

Définissez CODONFM_REPO_DIR, CODONFM_DATA_DIR, et CODONFM_CHECKPOINT_DIR sur des chemins absolus existants choisis pour le projet.

cd "${CODONFM_REPO_DIR:?Set the repository path}"
bash run_dev.sh \
    --data-dir "${CODONFM_DATA_DIR:?Set the host data path}" \
    --checkpoints-dir "${CODONFM_CHECKPOINT_DIR:?Set the host checkpoint path}"

Le répertoire de checkpoints de l'hôte est monté à /data/checkpoints à l'intérieur du conteneur. L'image est codon-fm-dev ; le conteneur est codon-fm-dev-container.

Utilisez uniquement le code public validé et les versions de dépendances déclarées dans son Dockerfile et requirements.txt. Continuez vers Vérifier le runtime après le lancement ; les téléchargements de checkpoints sont une action demandée séparée.

Exécution directe sans Docker

Utilisez ce chemin quand l'utilisateur préfère l'exécution d'hôte ou que Docker n'est pas disponible. Cela nécessite un driver NVIDIA compatible, Python 3.11 pour les commandes ci-dessous, et un checkout inscriptible. Confirmez que python3.11 --version réussit avant l'installation. Réutilisez un environnement de projet compatible ; sinon créez un environnement virtuel dédié. Définissez CODONFM_CACHE_DIR sur un répertoire de cache inscriptible avant d'exécuter ces commandes :

cd "${CODONFM_REPO_DIR:?Set the repository path}"
python3.11 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
mkdir -p "${CODONFM_CACHE_DIR:?Set a writable cache path}/matplotlib"
export MPLCONFIGDIR="$CODONFM_CACHE_DIR/matplotlib"
python -c "import sys, torch; available = torch.cuda.is_available(); \
print(available, torch.cuda.get_device_name(0) if available else 'CUDA unavailable'); \
sys.exit(0 if available else 1)"

La dernière commande est la vérification GPU directe de l'hôte ; interprétez-la comme décrit sous Vérifier le runtime. Le fichier requirements configure l'index PyTorch CUDA 12.4 pour xFormers. Utilisez les chemins explicites de l'hôte dans les commandes runner suivantes ; aucun montage /data/checkpoints n'est créé sur ce chemin.

Télécharger un checkpoint

Exécutez uniquement pour un checkpoint demandé. Réutilisez d'abord une copie locale appropriée. Vérifiez hf --help et hf download --help dans l'environnement qui effectuera le téléchargement. Si le CLI est manquant, utilisez un environnement virtuel de téléchargement séparé et python -m pip install huggingface_hub ; préservez les versions de dépendances de l'environnement du modèle. La documentation CLI décrit l'installation et les options supportées. Les téléchargements publics non protégés ne nécessitent pas hf auth login.

Définissez CODONFM_CHECKPOINT_DIR sur un répertoire inscriptible absolu dans l'environnement exécutant hf : la racine de checkpoint d'hôte choisie sur l'hôte, ou /data/checkpoints à l'intérieur du conteneur lancé. Les variables shell de l'hôte ne sont pas automatiquement définies à l'intérieur du conteneur. Utilisez les métadonnées fournies pour les noms de fichiers et révisions exacts ; gardez les poids et config.json ensemble.

Pour le checkpoint public 1B :

hf download nvidia/NV-CodonFM-Encodon-1B-v1 \
    NV-CodonFM-Encodon-1B-v1.safetensors config.json \
    --local-dir "${CODONFM_CHECKPOINT_DIR:?Set the checkpoint root}/encodon-1b"

Exemple de petit checkpoint

Pour une petite démonstration, préférez les poids publics originaux Encodon 80M :

hf download nvidia/NV-CodonFM-Encodon-80M-v1 \
    NV-CodonFM-Encodon-80M-v1.safetensors config.json \
    --revision 399ca9fe17b57941a7bebc6788033919b417413c \
    --local-dir "${CODONFM_CHECKPOINT_DIR:?Set the checkpoint root}/encodon-80m"

Le checkpoint est publiquement accessible sans approbation de modèle protégé, et le fichier de poids fait 307 351 588 octets. Il n'a pas besoin d'être dupliqué sur GitHub LFS. Les IDs de modèle -TE- utilisent TransformerEngine dans bionemo-recipes ; utilisez les IDs de modèle originaux avec cette codebase CodonFM publique. Téléchargez uniquement les poids et config.json, et réutilisez un checkpoint local existant.

Les autres IDs de modèle publics supportés sont :

• nvidia/NV-CodonFM-Encodon-80M-v1
• nvidia/NV-CodonFM-Encodon-600M-v1
• nvidia/NV-CodonFM-Encodon-Cdwt-1B-v1

Utilisez --model_name encodon_80m, encodon_600m, ou encodon_1b selon la taille d'architecture. Cdwt-1B utilise encodon_1b car Cdwt est une propriété d'entraînement de checkpoint, pas une architecture séparée.

Pour .safetensors, gardez config.json dans le même répertoire que le fichier modèle. N'inventez jamais un chemin Decodon ou checkpoint non documenté.

Après un téléchargement réussi, confirmez que les fichiers attendus existent, que config.json se parse, et que toute taille d'octet ou checksum fourni correspond. Rapportez les chemins de fichiers absolus et la révision. Une demande checkpoint uniquement s'arrête ici ; elle ne continue pas vers la vérification GPU. Pour une demande combinée, continuez uniquement l'autre chemin demandé.

Vérifier le runtime

Cette section s'applique uniquement aux demandes d'environnement fonctionnel. Pour l'exécution directe de l'hôte, utilisez la vérification GPU à la fin de Exécution directe sans Docker dans l'environnement activé du modèle. Pour un conteneur en cours d'exécution, utilisez un terminal de l'hôte :

docker exec codon-fm-dev-container python -c \
    "import sys, torch; available = torch.cuda.is_available(); \
print(available, torch.cuda.get_device_name(0) if available else 'CUDA unavailable'); \
sys.exit(0 if available else 1)"

Attendez True, un nom de GPU, et un statut de sortie zéro. False ou une exception signifie que la vérification du runtime a échoué ; rapportez le prérequis manquant ou l'erreur. Une vérification CUDA établit l'accès GPU, pas le chargement réussi du checkpoint ou l'exécution du modèle. Terminez la demande d'environnement en rapportant le runtime vérifié, les chemins de checkpoint disponibles, et toute vérification qui reste non effectuée.

Gestion des défaillances

• Si une commande échoue, diagnostiquez la cause rapportée. Réessayez une commande inchangée au maximum une fois pour une défaillance transitoire, comme un timeout de téléchargement. Pour une défaillance persistante, arrêtez ce chemin et rapportez l'erreur et le correctif nécessaire.
• Pour les téléchargements échoués, préservez le cache et les fichiers partiels, réessayez la même commande supportée le cas échéant, et rapportez quels fichiers restent manquants ou non vérifiés. N'inventez pas de drapeaux de retry ou ne prétendez pas qu'un téléchargement incomplet a réussi.
• Si les prérequis du runtime ou les contraintes du conteneur ne peuvent pas être satisfaits, complétez le travail indépendant au sein de la demande : inspectez la source/configuration fournie, préparez les commandes de configuration, ou téléchargez un checkpoint demandé quand c'est possible. Rapportez le travail complété et les prérequis non satisfaits ; ne prétendez pas que le runtime fonctionne.

Limites public-v1

• Supporté : Encodon 80M, 600M, 1B, et Cdwt-1B.
• Non supporté : Decodon, Encodon 5B/10B, génération de séquence, agrégation/fine-tuning missense spécialisé, et scripts/codon_optimize.py.
• CodonFM consomme des séquences codantes. Ce n'est pas un variant caller, un aligner, un annotateur GTF, ou un outil d'analyse VCF général.