Google Colab CLI : utiliser un GPU A100 à distance
Découvrez comment piloter Google Colab depuis le terminal, lancer un GPU A100 et mesurer coûts, performances et limites avec le CLI officiel. Guide pratique.
Piloter un GPU A100 dans Google Colab depuis votre terminal
Google Colab, c'est souvent un notebook ouvert dans un navigateur : quelques cellules exécutées à la main, puis une session qui finit par s'arrêter. C'est très bien pour apprendre ou faire tourner des idées en exploration. En revanche, dès que vous voulez automatiser des tests, lancer un modèle depuis votre poste ou simplement garder une trace réutilisable de vos essais, ça devient vite pénible.
Le CLI officiel de Colab change la donne : depuis un terminal, vous pouvez créer une session distante, lancer des commandes, suivre l'utilisation des ressources et exporter l'historique. Dans l'exemple ci-dessous, un GPU A100 a servi à lancer Ollama et à tester un modèle Gemma. Les chiffres relevés peuvent être intéressants, mais ils ne disent rien de la disponibilité garantie ni du débit attendu pour tous les comptes et tous les modèles.
Ce guide montre comment choisir l'outil, s'authentifier, démarrer une instance et surveiller le coût. Il liste aussi les limites à vérifier avant d'intégrer Colab à un flux de travail régulier : quotas, durée de session, confidentialité des données et évolution des offres Google.
Ce que le CLI officiel de Colab change
Le souci n'est pas que l'interface web soit « mauvaise ». Elle reste adaptée à l'apprentissage, aux démos et aux expériences rapides. Le vrai problème arrive quand vous devez répéter les mêmes étapes : préparer l'environnement, lancer un script, récupérer les résultats, puis retrouver combien de temps le GPU a réellement tourné.
Avec un outil en ligne de commande, Colab devient une ressource distante qu'on peut piloter depuis le terminal, plutôt qu'une page web à manipuler. Le CLI officiel propose notamment des commandes pour :
- créer une session ;
- exécuter des commandes dedans ;
- ouvrir un accès SSH selon les modalités disponibles ;
- vérifier l'usage ;
- consulter les journaux.
À garder en tête : ce n'est pas un accès illimité à votre « propre » serveur. Les ressources restent soumises aux règles, quotas et disponibilités de Colab.
Attention aux deux paquets qui se ressemblent
Le nom « colab-cli » est trompeur. Le paquet historique du même nom, disponible sur PyPI, n'est pas le bon outil à utiliser pour piloter des sessions distantes. Cet ancien utilitaire sert surtout à transférer des notebooks vers Google Drive. Selon l'environnement, son installation peut aussi tirer des versions anciennes de dépendances comme click ou typer, et provoquer des conflits.
Pour piloter des sessions, l'outil à utiliser est google-colab-cli. Dans l'environnement décrit ici, la version mentionnée est 0.7.4, avec une exigence de Python 3.12 ou plus. Comme toujours, ces détails peuvent évoluer : avant d'installer, vérifiez la documentation et les métadonnées de la version publiée. Un nom de paquet mal choisi suffit à installer la mauvaise brique.
Pourquoi piloter Colab en ligne de commande ?
Le terminal est pratique si vous voulez :
- intégrer l'exécution à un script local ;
- lancer un benchmark reproductible ;
- garder une trace des commandes.
Et aussi pour mieux observer la machine distante : modèle chargé, mémoire GPU consommée, état de session, et consommation des unités de calcul.
Mais le CLI ne supprime pas les contraintes du service. Une session peut être indisponible, interrompue, ou limitée dans le temps. Il faut donc concevoir vos tâches pour qu'elles puissent être relancées, et sauvegarder les résultats ailleurs. Pour une démo ou une évaluation ponctuelle, c'est souvent acceptable. Pour une API « production » avec disponibilité contractuelle, ce n'est généralement pas le bon choix.
Installer le CLI et démarrer une session A100
La procédure tient en quatre étapes : installer le paquet officiel, autoriser l'accès au compte Google, créer une session, puis vérifier que la machine répond. Prenez le temps de valider la configuration avant de balancer un modèle lourd ou des données importantes.
Installer le paquet officiel
L'exemple ci-dessous utilise uv pour installer l'outil dans un environnement isolé et lui fournir Python 3.12 :
uv tool install --python 3.12 google-colab-cliUne fois l'installation terminée, vérifiez que la commande existe :
colab --helpL'aide doit afficher les commandes fournies par la version installée (par exemple new, exec, usage, log). La liste exacte peut varier. Si vous gérez plusieurs environnements Python, vérifiez que votre terminal pointe bien vers l'installation attendue, pas vers une ancienne commande homonyme.
Autoriser l'accès à votre compte
La première commande qui demande des informations d'usage (par exemple colab usage) peut lancer une procédure OAuth. Le terminal affiche alors une URL à ouvrir. Connectez-vous au compte Google concerné, regardez les autorisations demandées, puis recopiez le code dans le terminal.
Ne partagez pas ce code et évitez de le coller dans un journal public. Comme pour tout outil lié à un compte cloud, assurez-vous que vous utilisez le compte auquel sont rattachés l'abonnement et les ressources nécessaires. Après autorisation, la commande peut afficher un solde d'unités de calcul, un taux de consommation, et le nombre de sessions actives.
Les noms d'options et les droits associés peuvent changer. Une capture d'écran faite par quelqu'un d'autre ne garantit pas que vous verrez les mêmes quotas. Contrôlez ce que votre compte affiche chez vous, et référez-vous aux conditions officielles avant de planifier un travail long.
Créer une session et l'identifier clairement
Pour demander une session A100, l'exemple utilise :
colab new --session gemma-test --gpu A100Le nom gemma-test sert à retrouver la session dans les commandes suivantes. Choisissez un identifiant qui correspond à votre objectif (ou votre projet) : si plusieurs essais tournent en parallèle, un nom clair évite de viser la mauvaise instance.
Dans le test mentionné, l'instance est passée à l'état « READY » en quelques secondes. Ce délai décrit la situation observée à un moment donné, pas un engagement de service. L'allocation dépend notamment de la disponibilité et des règles d'accès du compte. Avant de lancer le téléchargement d'un modèle de plusieurs gigaoctets, vérifiez l'état.
Pour exécuter une commande dans la session, la forme est :
colab exec -s gemma-test "nvidia-smi"Le nom de session est un paramètre déterminant. Prenez aussi l'habitude de vérifier la bonne instance avant toute opération qui consomme du temps ou des unités de calcul.
Lancer un modèle et interpréter les performances
Quand la session est prête, le GPU peut servir à exécuter un modèle de langage, si le logiciel, le format du modèle et la mémoire disponible sont compatibles. Dans l'exemple donné, Ollama a été installé sur l'instance distante, puis le modèle gemma4:26b (GGUF Q4_K_M) a été utilisé pour une inférence.
Le téléchargement du modèle annonçait environ 18 Go. Cette étape a un coût en temps et en ressources, même si le modèle n'est pas forcément gardé en mémoire après l'inférence. Si vous comptez répéter les tests, vérifiez si les fichiers restent sur le disque de la session, ou s'ils devront être re-téléchargés après recréation de l'environnement.
Ce que montrent les mesures rapportées
La machine vue depuis la session correspond à une NVIDIA A100-SXM4-40GB. La commande nvidia-smi donnait 40 960 MiB de mémoire GPU totale, avec environ 20 072 MiB utilisés au moment de la mesure. L'instance disposait aussi, d'après les relevés, de 12 cœurs logiques, d'environ 83,5 Go de mémoire système et de 235,7 Go d'espace NVMe.
Sur une requête de synthèse consacrée à BRCA1, l'auteur rapporte une génération de 369 tokens en 2,16 secondes, soit autour de 179 tokens par seconde. Le contexte était réglé à 32 768 tokens. Ces chiffres ne sont valables que pour ce test : ils dépendent du modèle réellement chargé, de sa quantification, du prompt, du temps de préremplissage, du contexte, de la version d'Ollama et de la manière dont l'outil calcule les tokens par seconde.
Conclusion pratique : évitez d'en faire une comparaison « générale » entre GPU. Un débit sur une requête courte ne prédit pas forcément les performances sur une génération longue, ni le comportement avec plusieurs utilisateurs. Pour comparer deux configurations, gardez tout identique (modèle, quantification, prompt, paramètres), et séparez le temps de chargement du temps de génération.
Vérifier que le modèle utilise réellement le GPU
Disposer d'une instance A100 ne suffit pas à garantir que toute l'inférence passe par le GPU. Voici la commande pour inspecter l'état matériel :
nvidia-smiDans l'exemple, ollama ps indiquait que le modèle tournait à 100 % sur le GPU, avec un contexte de 32 768 tokens. C'est une vérification plus utile que « le nom de la machine », car elle permet de repérer un chargement partiel ou un basculement sur le CPU.
La mémoire affichée varie selon le moment où vous regardez. L'exemple mentionne aussi qu'Ollama libère la mémoire GPU après environ cinq minutes d'inactivité. Pratique pour réduire l'occupation inutile, mais ça veut dire que la requête suivante peut déclencher un nouveau chargement. Si la latence compte, mesurez le scénario réel, y compris après une période d'inactivité.
Enfin, une réponse de modèle n'est pas « automatiquement fiable » parce qu'elle a été produite sur du matériel puissant. L'exemple touche à la santé : une sortie peut être incomplète ou erronée et ne doit pas servir de diagnostic ni remplacer un avis médical. Pour des tests médicaux, utilisez des données autorisées, anonymisez si nécessaire, et faites valider les résultats par des personnes qualifiées.
Surveiller les ressources et maîtriser les coûts
Le côté pratique du démarrage rend la surveillance encore plus importante. Une session laissée active après un test peut continuer à consommer des unités de calcul. Le bon réflexe consiste donc à vérifier le coût et l'état réel de la machine, plutôt que de supposer que le GPU s'arrête tout seul.
Consulter le solde et le taux de consommation
La commande suivante affiche les informations d'utilisation disponibles pour le compte :
colab usageDans l'essai rapporté, le solde est passé de 200 à 197,28 unités après environ une demi-heure : préparation de l'environnement, téléchargement du modèle de 18 Go, puis inférence. Le taux affiché était de 5,30 unités par heure pour la session A100 observée.
Avec ce seul taux, on peut faire un calcul théorique : 200 ÷ 5,30 ≈ 37,7 heures. Mais ce nombre n'est pas une garantie. Le solde de départ, le matériel effectivement attribué, le mode de facturation et les règles du compte peuvent changer. Et le temps de démarrage, l'attente, le téléchargement et l'inactivité peuvent influencer la consommation selon le fonctionnement réel du service.
Le compte rendu mentionne aussi un achat ponctuel de 100 unités pour environ 9,99 dollars. Le prix exact et la durée de validité des unités doivent être vérifiés sur la page de tarification au moment de l'achat : les conditions peuvent évoluer, et la facturation dépend parfois du pays ou du type de compte.
Contrôler l'état de la session et ses ressources
Pour vérifier la session nommée :
colab status -s gemma-testL'état peut apparaître comme « RUNNING » pendant une exécution, puis « IDLE » quand aucune commande n'est en cours. Attention : « IDLE » ne veut pas dire automatiquement que la session est arrêtée ni que la consommation est nulle. Regardez le taux d'usage et la documentation, plutôt que de déduire la facturation à partir d'un seul état.
Pour inspecter le GPU à distance :
colab exec -s gemma-test "nvidia-smi"Et pour vérifier l'état du modèle dans Ollama :
colab exec -s gemma-test "ollama ps"Ces vérifications donnent une vue à plusieurs niveaux : activité côté compte, cycle de vie de la session, charge matérielle, et processus applicatifs. En pratique, cette séparation aide à diagnostiquer les erreurs : si le GPU est disponible mais que le modèle ne remonte pas dans ollama ps, le problème vient très probablement ailleurs que de l'attribution de la carte.
Exporter l'historique et arrêter proprement
Le CLI permet aussi d'exporter les journaux d'exécution vers un notebook :
colab log -s gemma-test -o colab_a100_gemma4_replay.ipynbDans le test, le fichier généré faisait 728 Ko et regroupait les entrées, sorties et traces de l'expérience. C'est pratique pour partager un résultat ou retrouver les paramètres utilisés. Avant de publier, jetez quand même un œil au contenu : les sorties peuvent contenir des données sensibles, des chemins locaux, des infos de compte, ou (plus bêtement) des secrets copiés dans une cellule.
Pour un script ponctuel, lancer une tâche « éphémère » aide à éviter de laisser une session ouverte. La forme rapportée est :
colab run -s gemma-eval --gpu A100 my_benchmark.pyVérifiez la syntaxe supportée par votre version du CLI et observez le comportement exact après exécution. Pour une session interactive, arrêtez l'instance explicitement une fois terminé (par exemple colab stop, si votre version le propose). La règle simple : chaque session lancée doit avoir un propriétaire et une condition d'arrêt claire.
Conclusion : un renfort ponctuel, pas une infrastructure garantie
Le CLI officiel rend Colab plus simple à utiliser depuis un terminal : lancer des expériences, automatiser des tests, garder un historique exploitable. Dans le cas décrit, une session A100 a permis de tester un modèle avec un débit élevé, tout en surveillant l'usage et en exportant les journaux.
La bonne décision dépend de votre besoin. Pour une évaluation ponctuelle, une démonstration ou un benchmark isolé, ça peut éviter de gérer une machine GPU dédiée. Pour un service durable, des données sensibles ou une charge prévisible, il faut comparer le coût total, les garanties de disponibilité, les limites de session et les exigences de conformité d'une infrastructure pensée pour la production.
Avant de lancer votre prochain test, vérifiez le paquet installé, le quota affiché, le GPU réellement attribué et la procédure d'arrêt. Ensuite, mesurez votre propre charge : un débit isolé trouvé ailleurs et pour un autre compte ne vous aidera pas autant que vos mesures.