Google Colaboratory: informations trompeuses sur son GPU (seulement 5% de RAM disponible pour certains utilisateurs)

111

mise à jour: cette question est liée aux "Paramètres du notebook: accélérateur matériel: GPU" de Google Colab. Cette question a été écrite avant l'ajout de l'option "TPU".

En lisant plusieurs annonces enthousiastes à propos de Google Colaboratory fournissant un GPU Tesla K80 gratuit, j'ai essayé d'exécuter une leçon fast.ai dessus pour qu'elle ne se termine jamais - rapidement à court de mémoire. J'ai commencé à chercher pourquoi.

L'essentiel est que «le Tesla K80 gratuit» n'est pas «gratuit» pour tous - pour certains, seule une petite partie est «gratuite».

Je me connecte à Google Colab depuis la côte ouest du Canada et je ne reçois que 0,5 Go de ce qui est supposé être une RAM GPU de 24 Go. Les autres utilisateurs ont accès à 11 Go de RAM GPU.

Il est clair que 0,5 Go de RAM GPU 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 récupérée (ne fonctionne qu'avec le paramètre GPU du notebook):

# 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 notebook jupyter avant d'exécuter tout 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 auront 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 de la disponibilité de la RAM GPU, empruntée à GPUtil?

Pouvez-vous confirmer que vous obtenez des résultats similaires si vous exécutez ce code sur un ordinateur portable Google Colab?

Si mes calculs sont corrects, existe-t-il un moyen d'obtenir plus de RAM GPU sur la boîte gratuite?

mise à jour: je ne sais pas pourquoi certains d'entre nous obtiennent 1 / 20e de ce que les autres utilisateurs obtiennent. par exemple, la personne qui m'a aidé à déboguer ceci est de l'Inde et il obtient le tout!

Remarque : veuillez ne pas envoyer plus de suggestions sur la façon de tuer les ordinateurs portables potentiellement bloqués / emballés / parallèles qui pourraient consommer des parties du GPU. Peu importe comment vous le découpez, si vous êtes dans le même bateau que moi et que vous exécutez le code de débogage, vous verrez que vous obtenez toujours un total de 5% de RAM GPU (à partir de cette mise à jour toujours).

stason
la source
Une solution à cela? pourquoi j'obtiens des résultats différents en faisant! cat / proc / meminfo
MiloMinderbinder
Oui, même problème, juste environ 500 Mo de RAM GPU ... description trompeuse :(
Naveen
2
Essayez les outils de science des données open source d'IBM (cognitiveclass.ai) car ils disposent également d'un GPU gratuit avec des notebooks jupyter.
AQ
J'ai ramené cette question à un état où il y a en fait une question . Si vous avez fait plus de recherches et trouvé une réponse, l'endroit approprié est dans la boîte de réponse. Il est incorrect de mettre à jour la question avec une solution.
Chris Hayes
@ChrisHayes, je comprends votre intention, mais ce n'est pas juste, car votre restauration a supprimé tout un tas de détails pertinents qui ont maintenant disparu. Si vous souhaitez suggérer une meilleure formulation qui correspond mieux aux règles de cette communauté, veuillez le faire, mais sinon, veuillez annuler votre annulation. Je vous remercie. ps j'ai déjà posté la réponse .
stason

Réponses:

42

Donc, pour éviter une autre douzaine de réponses suggérant invalide dans le contexte de cette suggestion de fil à! Kill -9 -1, fermons ce fil:

La réponse est simple:

Au moment d'écrire ces lignes, Google ne donne simplement que 5% de GPU à certains d'entre nous, tandis que 100% aux autres. Période.

Mise à jour déc-2019: Le problème existe toujours - les votes positifs de cette question continuent.

Mise à jour mars 2019: Un an plus tard, un employé de Google @AmiF a commenté l'état des choses, déclarant que le problème n'existe pas, et quiconque semble avoir ce problème doit simplement réinitialiser son exécution pour récupérer de la mémoire. Pourtant, les votes positifs continuent, ce qui me dit que le problème existe toujours, malgré la suggestion de @ AmiF à l'effet contraire.

Mise à jour de décembre 2018: j'ai une théorie selon laquelle Google peut avoir une liste noire de certains comptes, ou peut-être des empreintes digitales de navigateur, lorsque ses robots détectent un comportement non standard. Cela pourrait être une coïncidence totale, mais pendant un certain temps, j'ai eu un problème avec Google Re-captcha sur tout site Web qui l'exigeait, où je devais passer par des dizaines d'énigmes avant d'être autorisé à passer, souvent me prendre plus de 10 minutes à accomplir. Cela a duré plusieurs mois. Tout à coup, à partir de ce mois-ci, je n'ai plus d'énigmes et tout re-captcha Google est résolu en un seul clic de souris, comme c'était le cas il y a presque un an.

Et pourquoi je raconte cette histoire? Eh bien, parce qu'en même temps, on m'a donné 100% de la RAM GPU sur Colab . C'est pourquoi je soupçonne que si vous êtes sur une liste noire théorique de Google, vous n'êtes pas sûr de 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 Re-captcha. Comme je l'ai dit, cela pourrait aussi être une coïncidence.

stason
la source
4
Votre déclaration de "Au moment d'écrire ces lignes, Google ne donne simplement que 5% de GPU à certains d'entre nous, tandis que 100% aux autres. Période." est incorrect - Colab n'a jamais fonctionné de cette façon. Tous les cas diagnostiqués d'utilisateurs voyant moins que le complément complet de RAM GPU à leur disposition se résument à un autre processus (démarré par le même utilisateur, éventuellement dans un autre ordinateur portable) utilisant le reste de la RAM du GPU.
Ami F
11
Futurs lecteurs: si vous pensez voir ce symptôme ou des symptômes similaires d'indisponibilité de la RAM GPU, "Réinitialiser tous les runtimes" dans le menu Runtime vous donnera une nouvelle VM garantissant qu'aucun processus obsolète ne tient toujours la RAM GPU. Si vous voyez toujours ce symptôme immédiatement après avoir utilisé cette option de menu, veuillez signaler
Ami F
Votre réalité est clairement différente de la réalité de nombreux autres qui continuent de voter pour ce poste un an plus tard après sa création. Il est très probable que certains utilisateurs rencontrent effectivement ce que vous avez décrit, mais ce n'est pas le cas pour tous. Je ne sais donc pas comment votre déclaration aide ici. D'ailleurs quand quelqu'un a posé cette question exacte dans le repo que vous avez recommandé, il a obtenu une réponse BS et son ticket a été fermé: github.com/googlecolab/colabtools/issues/52
stason
2
Au cas où cela ne serait pas clair: je ne décris pas ce que je pense que la mise en œuvre est basée sur l'observation du comportement du système en tant qu'utilisateur. Je décris ce que je connais directement de l'implémentation. J'ai posté en espérant que les utilisateurs qui voient une disponibilité inférieure à la pleine disponibilité le signalent comme un problème (erreur utilisateur ou bogue système) au lieu de lire les déclarations incorrectes ci-dessus et de supposer que les choses fonctionnent comme prévu.
Ami F
1
Non, les GPU n'ont jamais été partagés et il n'y a pas de mensonges dans l'exemple que vous avez lié (simplement une estimation et une explication de la raison la plus courante du symptôme signalé).
Ami F
22

Hier soir, j'ai publié votre extrait et j'ai obtenu exactement ce que vous avez:

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 VM, donc chaque fois que vous redémarrez le runtime, vous avez la possibilité de changer de GPU, et il est également probable que vous passiez à celui qui est utilisé par d'autres utilisateurs.

MISE À JOUR: Il s'avère que je peux utiliser le GPU normalement même lorsque le GPU RAM Free est de 504 Mo, ce que je pensais être la cause de ResourceExhaustedError que j'ai eu la nuit dernière.

Nguyễn Tài Long
la source
1
Je pense que je me suis reconnecté probablement 50 fois sur une période de quelques jours et j'ai toujours eu la même utilisation à 95% pour commencer. Une seule fois, j'ai vu 0%. Dans toutes ces tentatives, j'obtenais une erreur de mémoire cuda une fois qu'elle s'approchait de 100%.
stason
Que voulez-vous dire par votre mise à jour? Pouvez-vous toujours exécuter des trucs avec 500 Mo? J'ai le même problème, je reçoisRuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84
ivan_bilan
6

Si vous exécutez une cellule qui contient juste
! Kill -9 -1
, cela entraînera l'effacement et le redémarrage de tout l'état de votre runtime (y compris la mémoire, le système de fichiers et le GPU). Attendez 30 à 60 secondes et appuyez sur le bouton CONNECT en haut à droite pour vous reconnecter.

Ajaychhimpa1
la source
2
merci, mais votre suggestion ne change rien. Je reçois toujours 5% de RAM GPU.
stason
Cela n'aide pas. Après avoir tué et reconnecté, la mémoire du GPU est toujours à 500 Mo sur ~ 12 Go.
ivan_bilan
4

Description trompeuse de la part de Google. J'étais trop excité à ce sujet aussi, je suppose. Configurez tout, chargez les données et maintenant je ne peux rien faire avec cela car seulement 500 Mo de mémoire sont alloués à mon ordinateur portable.

ivan_bilan
la source
2

Trouvez le pid Python3 et tuez le pid. S'il vous plaît voir l'image ci-dessousentrez la description de l'image ici

Remarque: ne tuez que python3 (pid = 130) et non jupyter python (122).

Manivannan Murugavel
la source
cela aidera-t-il avec le problème de mémoire? tu ne tues pas toutes les courses des autres alors?
ivan_bilan
cela n'aide pas, j'ai le même problème:GPU RAM Free: 564MB
ivan_bilan
2

Redémarrez le noyau Jupyter IPython:

!pkill -9 -f ipykernel_launcher
mkczyk
la source
1
proche, mais pas de cigare:GPU RAM Free: 564MB
ivan_bilan
comme méthode plus simple pour redémarrer le noyau, vous pouvez simplement cliquer sur Runtime | Redémarrez le runtime ... ou le raccourciCMD/CTRL+M
Agile Bean
2

Je ne sais pas 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:

Mémoire RAM libre: 12,9 Go | Taille du processus: 142,8 Mo GPU RAM Libre: 11441 Mo | Utilisé: 0MB | Util 0% | Total 11441 Mo

Il semble que je reçois également un noyau complet. Cependant, je l'ai exécuté plusieurs fois et j'ai obtenu le même résultat. Peut-être que je vais répéter cette vérification plusieurs fois au cours de la journée pour voir s'il y a un changement.

Kregnach
la source
2

donnez juste une lourde tâche à google colab, il nous demandera de passer à 25 Go de RAM.

entrez la description de l'image ici

exemple exécutez ce code deux fois:

import numpy as np
from keras.layers import Conv2D, MaxPooling2D, AveragePooling2D
from keras.layers import Dropout, Flatten, Dense
from keras.models import Sequential
from keras.layers.advanced_activations import LeakyReLU
from keras.datasets import cifar10
(train_features, train_labels), (test_features, test_labels) = cifar10.load_data()
model = Sequential()

model.add(Conv2D(filters=16, kernel_size=(2, 2), padding="same", activation="relu", input_shape=(train_features.shape[1:])))
model.add(MaxPooling2D(pool_size=(2, 2), padding='same'))

model.add(Conv2D(filters=32, kernel_size=(3, 3), padding="same", activation="relu"))
model.add(MaxPooling2D(pool_size=(2, 2), padding='same'))

model.add(Conv2D(filters=64, kernel_size=(4, 4), padding="same", activation="relu"))
model.add(MaxPooling2D(pool_size=(2, 2), padding='same'))

model.add(Flatten())

model.add(Dense(25600, activation="relu"))
model.add(Dense(25600, activation="relu"))
model.add(Dense(25600, activation="relu"))
model.add(Dense(25600, activation="relu"))
model.add(Dense(10, activation="softmax"))

model.compile(optimizer='adam', loss='sparse_categorical_crossentropy', metrics=['accuracy'])

model.fit(train_features, train_labels, validation_split=0.2, epochs=10, batch_size=128, verbose=1)

puis cliquez sur obtenir plus de ram :) entrez la description de l'image ici entrez la description de l'image ici

entrez la description de l'image ici

Jainil Patel
la source
Je peux le confirmer. J'avais un jeu de données de 15 gig, principalement des images HD (mon lecteur a 30 Go au lieu de 15 Go) et j'ai exécuté mon code pour redimensionner le jeu de données d'image à 224,224,3 et j'ai été basculé vers un runtime RAM élevé. Puis, lorsque j'ai commencé à m'entraîner, l'utilisation de la RAM est passée à 31,88 Go.
Anshuman Kumar le
Mais j'aimerais ajouter qu'une fois que j'ai terminé ce travail, je n'ai pas pu accéder à un autre GPU / TPU au cours des dernières 24 heures. Il est possible que je sois sur liste noire.
Anshuman Kumar le
@AnshumanKumar, donnez la charge élevée au début seulement sinon en changeant la configuration, vous perdrez le travail effectué précédemment qui en RAM. Je n'ai pas utilisé de configuration élevée pendant 24 heures, donc je ne connais pas la liste noire.
Jainil Patel le
Oui, cela m'est arrivé. Cependant, le travail a été fait.
Anshuman Kumar le
1

Je crois que si nous avons plusieurs cahiers ouverts. Le simple fait de le fermer n'interrompt pas réellement le processus. Je n'ai pas compris comment l'arrêter. Mais j'ai utilisé top pour trouver le PID du python3 qui fonctionnait le plus longtemps et qui utilisait la majeure partie de la mémoire et je l'ai tué. Tout est revenu à la normale maintenant.

Ritwik G
la source