Peut-on arrêter un notebook GPU et reprendre la même expérience ?

Il est 18 h. Un notebook a enfin chargé le modèle et produit des résultats à examiner. Si vous arrêtez la session, vous risquez de passer une partie du lendemain à reconstruire l’environnement et recharger le modèle. Si vous la laissez tourner, un accélérateur rare peut rester inutilisé toute la nuit.

Google a annoncé GKE Workspaces le 4 novembre. L’environnement de développement open source tourne dans le cluster Google Kubernetes Engine de l’équipe. Un tableau de bord dans le navigateur peut y lancer JupyterLab ou VS Code avec les ressources configurées. Le projet s’appuie sur Kubeflow Workspaces et explique comment mettre en pause puis reprendre les sessions compatibles. L’équipe doit savoir de quel état elle aura besoin le lendemain et ce qui doit rester alloué pour le préserver.

Image recadrée de la démonstration des notebooks reprenables de GKE Workspaces, Apache 2.0. Source de l’image · Licence.

Un fichier notebook et une session active préservent des éléments différents

Mettre un notebook GPU en pause. Illustration originale de Telli.sh.

Enregistrer un notebook conserve les cellules que vous avez écrites et les sorties sauvegardées. Un disque peut rendre des jeux de données et des points de reprise accessibles à un nouveau processus. Cela ne capture pas automatiquement tout ce qui existe dans une session active. Une expérience peut contenir des variables initialisées, un modèle chargé sur un accélérateur et un état intermédiaire long à reconstituer.

Google décrit l’usage de GKE Pod Snapshots pour conserver l’état des environnements compatibles en cours d’exécution tout en libérant les ressources de calcul. Les fichiers de travail restent sur le stockage persistant. À la reprise, il faut disposer du snapshot et d’une capacité compatible. La pause se rapproche ainsi d’une reprise de l’expérience, avec des contraintes liées à l’environnement, davantage que de la réouverture d’un fichier.

La reproductibilité et le confort améliorent des aspects distincts du travail. Un snapshot aide la personne qui veut reprendre la session sous peu. Un notebook reproductible et un point de reprise applicatif facilitent la répétition de l’expérience par quelqu’un d’autre ou dans un autre environnement. Conservez les deux lorsque l’expérience est importante.

Une équipe de recherche peut mettre une session GPU en pause entre deux réunions tout en enregistrant le code dans le dépôt et en conservant les artefacts du modèle dans un espace durable. Si le snapshot ne se restaure pas, elle dispose d’une solution de repli. Un entraînement long peut aussi enregistrer des points de reprise à intervalles réguliers même si son environnement permet la mise en pause.

Un environnement arrêté peut encore coûter

Évaluer la facture réelle. Illustration originale de Telli.sh.

Le gain économique immédiat vient de la possibilité d’éviter de mobiliser du calcul quand personne ne travaille. La facture dépend de ce que fait le cluster après l’arrêt de la session. Un nœud peut continuer à tourner parce que d’autres pods l’utilisent. Une réservation peut conserver un coût ou un engagement. Les disques persistants et les snapshots stockés restent dans le système.

Prenons un exemple hypothétique. Une chercheuse laisse un accélérateur par ailleurs inutilisé alloué pendant douze heures après son départ. La pause donne à la plateforme la possibilité de libérer ces douze heures d’accélérateur. C’est une possibilité de réaffecter de la capacité. L’effet financier dépend des modalités d’allocation et de facturation du nœud et de l’accélérateur. Si le nœud reste en ligne pour une autre tâche, la pause peut surtout faciliter la planification.

Une comparaison équilibrée tient aussi compte du temps. Créer un snapshot consomme des ressources, restaurer un état volumineux prend du temps et l’accélérateur voulu peut être indisponible au moment de reprendre. Sur un cluster très sollicité, céder l’équipement à une autre personne peut être utile même si l’équipe s’est déjà engagée à payer pour une réserve de capacité.

Consignez la fin du travail actif, l’arrêt de l’environnement et le moment où le nœud redevient disponible. Mesurez ensuite le moment où la personne peut exécuter la cellule suivante après sa demande de reprise. Ces repères indiquent à l’équipe plateforme si une règle de mise en pause restitue une capacité significative sans imposer une file d’attente en début de journée.

L’équipe plateforme reste responsable du cadre d’utilisation

Le libre-service change la personne qui appuie sur le bouton. Les administrateurs décident encore quelles images lancer, quels accélérateurs demander et comment le cluster gère quotas et isolation. Le dépôt GKE Workspaces indique que le code est sous Apache 2.0 et que Google ne fournit pas de support officiel pour ce produit. L’installation et l’exploitation relèvent donc de l’équipe technique qui envisage de l’adopter.

Une ingénieure en apprentissage automatique peut avoir besoin d’un IDE familier, d’assez de mémoire et d’un accès aux données d’une expérience. La personne qui gère la plateforme doit aussi penser aux identités par défaut, aux permissions de stockage, à l’arrêt des charges et aux images qui peuvent être mises à jour. Ces besoins sont compatibles si les types d’environnements rendent les compromis visibles. Un petit notebook sur CPU et une session d’expérimentation sur GPU peuvent avoir des réglages différents.

L’annonce décrit également des choix d’accélérateurs et des connexions pour des outils ou agents locaux. Consultez les instructions adaptées à votre cluster et à votre besoin avant de considérer ces options comme interchangeables. La restauration liée au matériel, les accès entre clusters et la connexion depuis un environnement local ont chacun leurs prérequis. Commencez par un cas simple où une personne peut inspecter l’environnement et confirmer quel cluster l’exécute.

Testez une mise en pause et une récupération de bout en bout

1. Lisez le guide de déploiement et les exigences actuelles de votre environnement GKE pour les snapshots et les accélérateurs. Configurez un espace de test dont les droits et limites de ressources correspondent au flux prévu.
2. Lancez un notebook reproductible. Enregistrez ses entrées, un point de reprise intermédiaire de l’application et un petit fichier de résultats. Notez l’heure et les ressources allouées avant la pause.
3. Mettez l’espace en pause et vérifiez l’état des ressources du cluster. Contrôlez l’arrêt du pod, la possibilité d’attribuer de nouveau l’accélérateur et le stockage qui subsiste.
4. Reprenez l’espace de travail. Vérifiez les fichiers et l’état actif attendus, puis lancez une cellule qui utilise le modèle chargé. Mesurez le délai entre la demande de reprise et l’obtention d’un notebook utilisable.
5. Essayez la même récupération avec les fichiers enregistrés et le point de reprise applicatif. Vous aurez un plan de repli et une comparaison si le snapshot est lent ou impossible à restaurer.
6. Revoyez les réglages d’inactivité en équipe. Définissez ce qui compte comme inactif et si les tâches longues ont besoin d’un type d’espace distinct ou d’un traitement explicite.

Testez aussi la restauration avec un quota serré ou un cluster chargé. Une démonstration sans accroc sur un cluster vide peut cacher la difficulté à obtenir des ressources lorsque plusieurs personnes reviennent en même temps. L’essai doit montrer le comportement du système quand la capacité se raréfie.

Calculez à quoi servent les heures de GPU

Imaginez un poste de développement utilisé 40 heures par semaine. Une machine allouée en permanence représente 168 heures. Si la plateforme peut libérer le nœud GPU à chaque interruption et ne le remettre en service que pendant ces 40 heures, elle évite 128 heures de nœud alloué avant de compter le coût de la capture et de la reprise. Cet exemple ne suppose aucun tarif cloud ni profil d’utilisation particulier. Il donne une borne haute pour ce mode d’allocation, car un nœud partagé peut encore servir à d’autres travaux.

Pour rendre la comparaison plus réaliste, l’équipe peut utiliser son propre parc de GPU comme référence. Notez pour chaque période d’essai les heures de nœud, l’occupation par d’autres tâches et le volume de données de travail conservé. Mesurez aussi le délai entre la demande de reprise et l’exécution de la prochaine cellule. Si le nœud reste actif pour une deuxième charge, le notebook en pause peut lui rendre de la capacité sans réduire la facture. Ce résultat peut tout de même servir.

Le temps de capture fait partie du calcul. Si une pause est longue et que l’ancien pod reste alloué pendant l’opération, un seuil d’inactivité court peut multiplier les interruptions sans vraie économie. Si la reprise prend plusieurs minutes parce que le mécanisme de mise à l’échelle doit trouver un GPU compatible, une courte pause peut faire perdre plus de temps qu’elle n’en fait gagner. Mesurez plusieurs durées d’inactivité.

Décidez de l’état à conserver avant d’activer la pause

Le dépôt GKE Workspaces décrit un flux VS Code sans état et un exemple JupyterLab distinct qui conserve son état. Ce dernier montre la restauration d’un notebook sur GPU, notamment avec un modèle Qwen2.5 de 3 milliards de paramètres sur une seule T4. Les snapshots de pods et cet exemple imposent des conditions de compatibilité. La documentation GKE explique le rôle de GKE Sandbox et les configurations de nœuds et d’images compatibles. Avant de vous fier à la restauration GPU, vérifiez que le nouveau nœud fournit le même modèle de GPU pris en charge et un environnement compatible.

Définissez ce que les utilisateurs attendent d’un bouton de pause. Certains s’attendent à retrouver fichiers, sorties et état de l’éditeur. D’autres veulent que la prochaine cellule Python accède à un objet encore en RAM ou à un modèle en VRAM. Un jeu de données partagé peut résider dans un stockage d’objets externe et rester hors du snapshot. Indiquez ce qui peut être restauré, où les fichiers ordinaires sont conservés et ce qu’il faut faire si la reprise échoue.

Un second essai utile consiste à provoquer un échec avant la reprise. Dans un espace de noms de test, rendez la capacité compatible temporairement indisponible. Vérifiez que l’environnement indique clairement son état sans lancer plusieurs restaurations concurrentes. Contrôlez si la personne peut reprendre depuis les fichiers ou les sorties enregistrées quand le processus en mémoire ne revient pas. Supprimez ensuite le snapshot de test et vérifiez l’application des règles de stockage et de conservation.

Rendez les coûts lisibles pour toute l’équipe

Une chercheuse veut reprendre son travail. L’équipe plateforme veut rendre la capacité GPU au parc. L’équipe chargée de la facturation veut savoir si une allocation disparaît réellement. Un même essai peut éclairer ces trois sujets s’il mesure séparément l’inactivité, le placement des nœuds, la taille des snapshots, les reprises réussies et le temps de récupération. Documentez les échecs pour le support et indiquez aux utilisateurs si leur espace est en pause, en attente de capacité ou prêt.

À partir de cette référence, choisissez une règle d’inactivité par catégorie de charge. Une longue session avec un modèle lent à charger peut bénéficier de la conservation de la mémoire entre deux équipes. Une courte expérience lancée à partir d’un script sauvegardé peut se contenter de fichiers persistants et d’un redémarrage propre. Les deux peuvent partager le même parc avec des délais de reprise différents.

Ajoutez un test de reprise à la validation des mises à jour

Une mise à jour de la plateforme peut modifier l’image de démarrage ou le groupe de nœuds qui fournit les GPU. Avant de la mettre à disposition, créez un notebook de test dans l’ancienne configuration et vérifiez ce qui se passe dans la nouvelle. Distinguez une vraie restauration d’une nouvelle session qui rouvre le même fichier. Lisez une valeur qui n’existe que dans le processus de test actif, puis confirmez que les fichiers utilisés par ce processus sont toujours présents.

Si la mise à jour rend les anciens snapshots inutilisables, laissez le temps de sauvegarder les sorties critiques et décrivez la solution de repli. Vérifiez séparément la suppression des snapshots expirés. Un test de restauration montre qu’un environnement précis peut revenir. Un test de nettoyage montre combien d’état ancien subsiste après son abandon.

Préservez le travail le plus difficile à reconstituer

Un environnement devient plus utile quand on peut oublier le cycle de vie de la machine tout en retrouvant son travail. Cela suppose de distinguer fichiers, points de reprise, snapshots et capacité. Conservez l’état minimal qui rend la reprise confortable et veillez à ce que le projet reste reproductible sans sa session initiale.

Si l’équipe sait ce qui reste sur disque, ce qui doit être restauré et à quel moment les ressources sont libérées, elle peut choisir une règle d’inactivité que les personnes utiliseront réellement.

Sources

• Documentation GKE sur les snapshots de pods et la compatibilité

• Exemple de notebook reprenable à la révision de la démonstration

• Annonce et vidéo de présentation de GKE Workspaces du 4 novembre sur le blog Google Open Source

• Code source, état du support et instructions d’installation de GKE Workspaces

---

Pour retrouver facilement la trace des conversations et décisions liées à votre travail, créez un compte Telli.sh.