Google Colaboratory: informations trompeuses sur son GPU (seulement 5% RAM disponibles pour certains utilisateurs)
mise à jour: cette question est liée aux "Paramètres du portable: accélérateur matériel: GPU" de Google Colab. Cette question a été écrite avant que l'option "TPU" ne soit ajoutée.
Après avoir lu plusieurs annonces enthousiastes au sujet de Google Colaboratory fournissant gratuitement le GPU Tesla K80, j’ai essayé d’exécuter fast.ai leçon sur ce sujet afin de ne jamais le terminer - manquer rapidement de mémoire. J'ai commencé à chercher pourquoi.
L’essentiel, c’est que la "libre Tesla K80" n’est pas "gratuite" pour tous - pour certains, seule une petite tranche est "gratuite".
Je me connecte à Google Colab depuis la côte ouest du Canada et je n’obtiens que 0,5 Go de ce qui est supposé être une RAM de GPU de 24 Go. Les autres utilisateurs ont accès à 11 Go de RAM GPU.
Il est clair que 0,5 Go de GPU RAM est insuffisant pour la plupart des travaux ML/DL.
Si vous n'êtes pas sûr de ce que vous obtenez, voici une petite fonction de débogage que j'ai grattée (fonctionne uniquement avec le paramètre GPU du portable):
# memory footprint support libraries/code
!ln -sf /opt/bin/nvidia-smi /usr/bin/nvidia-smi
!pip install gputil
!pip install psutil
!pip install humanize
import psutil
import humanize
import os
import GPUtil as GPU
GPUs = GPU.getGPUs()
# XXX: only one GPU on Colab and isn’t guaranteed
gpu = GPUs[0]
def printm():
process = psutil.Process(os.getpid())
print("Gen RAM Free: " + humanize.naturalsize( psutil.virtual_memory().available ), " | Proc size: " + humanize.naturalsize( process.memory_info().rss))
print("GPU RAM Free: {0:.0f}MB | Used: {1:.0f}MB | Util {2:3.0f}% | Total {3:.0f}MB".format(gpu.memoryFree, gpu.memoryUsed, gpu.memoryUtil*100, gpu.memoryTotal))
printm()
L'exécuter dans un cahier Jupyter avant d'exécuter un autre code me donne:
Gen RAM Free: 11.6 GB | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util 95% | Total 11439MB
Les utilisateurs chanceux qui ont accès à la carte complète verront:
Gen RAM Free: 11.6 GB | Proc size: 666.0 MB
GPU RAM Free: 11439MB | Used: 0MB | Util 0% | Total 11439MB
Voyez-vous une faille dans mon calcul du GPU RAM disponibilité, emprunté à GPUtil?
Pouvez-vous confirmer que vous obtenez des résultats similaires si vous exécutez ce code sur le carnet Google Colab?
Si mes calculs sont corrects, y a-t-il un moyen d'obtenir plus de ce GPU RAM sur la boîte libre?
mise à jour: Je ne suis pas sûr de savoir pourquoi certains d’entre nous reçoivent 1/20 de ce que les autres utilisateurs obtiennent. par exemple. la personne qui m'a aidé à déboguer cela vient d'Inde et il obtient le tout!
note : veuillez ne plus envoyer de suggestions sur la manière de tuer les carnets de notes potentiellement bloqués/en fugue/parallèles susceptibles de consommer des parties du GPU. Peu importe comment vous le découpez, si vous êtes dans le même bateau que moi et si vous exécutez le code de débogage, vous constaterez que vous obtenez toujours un total de 5% de GPU RAM (à compter de cette mise à jour). encore).
Donc, pour éviter une autre douzaine de réponses suggérant non valides dans le contexte de cette suggestion de fil à! Kill -9 -1, fermons ce fil de discussion:
La réponse est simple:
A ce jour, Google ne donne que 5% de GPU à certains d'entre nous, alors que 100% aux autres. Période.
Mise à jour de mars 2019 : Un an plus tard, Google a finalement remarqué ce fil et a envoyé @AmiF pour le discréditer, ce qui implique que tout le monde qui a ce problème est un utilisateur incompétent. qui ne savent pas comment réinitialiser leur runtime pour récupérer de la mémoire. @AmiF suggère en outre que ce problème n'était peut-être qu'un bogue dans leur code et que nous, les utilisateurs, ne pouvons pas dire une stratégie d'entreprise par rapport à un bogue.
Malheureusement, aucune divulgation complète n'est faite et nous ne pouvons que deviner ce qui pourrait réellement se passer. De toute évidence, une entreprise à but lucratif aura des réserves quant à son identité à Nice et il est donc impossible d'éviter la discrimination ici. C'est tout à fait logique et très logique. Étant donné que cette ressource est fournie gratuitement, nous ne pouvons pas vraiment nous plaindre, mais nous demandons simplement pourquoi certains d'entre nous sont sur la liste noire, alors que d'autres provenant de configurations/paramètres régionaux identiques ne le sont pas.
Depuis que mon compte personnel a été supprimé de la liste noire en décembre 2018 (voir ma mise à jour ci-dessous), je ne peux compter que sur les autres utilisateurs qui figurent toujours sur la liste noire pour aider à dire la vérité. Au moment où j'écris cette mise à jour, ce fil a reçu un autre vote positif.
Cela dit, espérons que Google finira par mettre un terme à la liste noire au moins pour ceux qui demandent à en être retirés. La plupart d'entre nous n'ont fait aucune activité incriminante pour figurer sur cette liste et se sont tout simplement retrouvés pris au piège par des machines immatures en apprentissage automatique et n'ont aucune chance de prouver leur innocence. @AmyF a suggéré de signaler ce problème à l'adresse http://github.com/googlecolab/colabtools/issues - si vous signalez le problème et que vous vous effacez avec votre ticket fermé sans enquête comme celle-ci - cas , merci de poster le lien vers votre question non résolue dans les commentaires de cette réponse, afin que nous puissions demander un peu de responsabilité.
Et, bien sûr, avant d’invoquer ce fil, veuillez effectuer "Réinitialiser tous les temps d’exécution" dans le menu Runtime de colab et voir si vous aviez peut-être le problème de blocs-notes inachevés qui consomment toujours du GPU RAM et vous n'êtes pas du tout impacté par la politique de mise en liste noire.
Une fois que le vote aura cessé, nous saurons que cette politique de discrimination a été abolie. Malheureusement, à la date de cette mise à jour, ce n'est pas le cas, ce qui rend les commentaires de @ AmyF ci-dessous extrêmement douteux.
Mise à jour de décembre 2018 : J'ai une théorie selon laquelle Google pourrait avoir une liste noire de certains comptes, voire des empreintes digitales de son navigateur, lorsque ses robots détectent une erreur non standard. comportement. C’est peut-être une coïncidence totale, mais pendant un certain temps, j’ai eu un problème avec Google Re-captcha sur n’importe quel site Web qui en avait besoin, où je devais passer par des dizaines de puzzles avant d’être autorisé, souvent. me prendre plus de 10 minutes à accomplir. Cela a duré plusieurs mois. Tout à coup, à partir de ce mois-ci, je ne reçois plus aucune énigme et tout re-captcha de Google est résolu en un simple clic de souris, comme il y a presque un an.
Et pourquoi je raconte cette histoire? Eh bien, parce que au même moment, on m'a donné 100% du GPU RAM sur Colab . C'est pourquoi je soupçonne que si vous êtes sur une liste noire théorique sur Google, on ne vous fait pas confiance pour recevoir beaucoup de ressources gratuitement. Je me demande si l'un d'entre vous trouve la même corrélation entre l'accès limité au GPU et le cauchemar de Re-captcha. Comme je l'ai dit, cela pourrait aussi être une coïncidence.
La nuit dernière, j'ai parcouru votre extrait et obtenu exactement ce que vous avez obtenu:
Gen RAM Free: 11.6 GB | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util 95% | Total 11439MB
mais aujourd'hui:
Gen RAM Free: 12.2 GB I Proc size: 131.5 MB
GPU RAM Free: 11439MB | Used: 0MB | Util 0% | Total 11439MB
Je pense que la raison la plus probable est que les GPU sont partagés entre les machines virtuelles. Ainsi, chaque fois que vous redémarrez le runtime, vous avez une chance de changer de GPU et il est également probable que vous basculiez vers un processeur utilisé par d'autres utilisateurs.
MISE À JOUR: Il se trouve que je peux utiliser le GPU normalement même lorsque le GPU RAM Free est de 504 Mo, ce qui me semblait être la cause de ResourceExhaustedError que j'ai eu la nuit dernière.
Si vous exécutez une cellule qui a juste
! kill -9 -1
, tout l’état de votre environnement d’exécution (mémoire, système de fichiers et GPU compris) sera nettoyé et redémarré. Attendez 30-60s et appuyez sur le bouton CONNECT en haut à droite pour vous reconnecter.
Description trompeuse de la part de Google. Je suis trop excité à ce sujet aussi, je suppose. Tout configurer, j'ai chargé les données, et maintenant je ne peux plus rien y faire car je n'ai que 500 Mo de mémoire allouée à mon portable.
Trouvez le pid Python3 et tuez le pid. S'il vous plaît voir l'image ci-dessous 
Remarque: tuez uniquement python3 (pid = 130) et non Jupyter python (122).
Redémarrez le noyau Jupyter IPython:
!pkill -9 -f ipykernel_launcher
Je ne suis pas sûr si cette liste noire est vraie! Il est plutôt possible que les cœurs soient partagés entre les utilisateurs. J'ai également exécuté le test et mes résultats sont les suivants:
Gen RAM Gratuit: 12,9 Go | Taille du proc: 142,8 Mo de GPU RAM Libre: 11441MB | Utilisé: 0MB | Util 0% | Total 11441MB
Il semble que j'obtienne aussi un noyau complet. Cependant, je l'ai couru plusieurs fois et j'ai obtenu le même résultat. Je vais peut-être répéter cette vérification plusieurs fois au cours de la journée pour voir s’il ya un changement.
Je crois que si nous avons plusieurs cahiers ouverts. Le fait de le fermer n’arrête pas le processus. Je n'ai pas trouvé comment l'arrêter. Mais j'ai utilisé top pour trouver le PID du python3 qui fonctionnait le plus longtemps et utilisait la plus grande partie de la mémoire et je l'ai tué. Tout est revenu à la normale maintenant.