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

Question

Mise à jour : cette question est liée à l'article "Paramètres de l'ordinateur portable" de Google Colab : Accélérateur matériel : GPU". Cette question a été écrite avant l'ajout de l'option "TPU".

Après avoir lu de nombreuses annonces enthousiastes sur le fait que Google Colaboratory fournissait gratuitement le GPU Tesla K80, j'ai essayé d'exécuter fast.ai pour qu'il ne se termine jamais, manquant rapidement de mémoire. J'ai commencé à chercher pourquoi.

L'essentiel est que la "Tesla K80 gratuite" n'est pas "gratuite" 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 dispose que de 0,5 Go de ce qui est censé être une RAM de 24 Go pour le GPU. Les autres utilisateurs ont accès à 11 Go de mémoire vive du GPU.

Il est clair que 0,5 Go de RAM du GPU est insuffisant pour la plupart des travaux de ML/DL.

Si vous n'êtes pas sûr de ce que vous obtenez, voici une petite fonction de débogage que j'ai bricolée (elle ne fonctionne qu'avec le paramètre GPU de l'ordinateur 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()

En l'exécutant dans un notebook Jupyter avant d'exécuter tout autre code, j'obtiens :

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 un défaut dans mon calcul de la disponibilité de la RAM du GPU, emprunté à GPUtil ?

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

Si mes calculs sont corrects, y a-t-il un moyen d'obtenir plus de cette mémoire vive du GPU sur la boîte libre ?

mise à jour : je ne sais pas pourquoi certains d'entre nous reçoivent 1/20e de ce que d'autres utilisateurs reçoivent. Par exemple, la personne qui m'a aidé à déboguer ceci est en Inde et il reçoit la totalité !

note : s'il vous plaît, n'envoyez plus de suggestions sur la façon de tuer les ordinateurs portables potentiellement bloqués/en fuite/parallèles qui pourraient consommer des parties du GPU. Quelle que soit la façon dont 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 du GPU (à partir de cette mise à jour encore).

Answer 1

Donc, pour éviter une autre douzaine de réponses suggérant que la suggestion de !kill -9 -1 n'est pas valide dans le contexte de ce fil, fermons ce fil :

La réponse est simple :

À l'heure où nous écrivons ces lignes, Google ne donne que 5 % du GPU à certains d'entre nous, alors que 100 % sont accordés aux autres. Point final.

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

mise à jour mar-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 que toute personne qui semble avoir ce problème doit simplement réinitialiser son runtime pour récupérer la mémoire. Pourtant, les votes positifs continuent, ce qui, pour moi, indique que le problème existe toujours, malgré la suggestion contraire de @AmiF.

Mise à jour déc-2018 : J'ai une théorie selon laquelle Google pourrait avoir une liste noire de certains comptes, ou peut-être des empreintes de navigateur, lorsque ses robots détectent un comportement non standard. Il pourrait s'agir d'une coïncidence totale, mais pendant un certain temps, j'ai eu un problème avec Google Re-captcha sur tout site Web qui se trouvait à le nécessiter, où je devais passer par des dizaines de puzzles avant d'être autorisé à passer, ce qui me prenait souvent plus de 10 minutes à accomplir. Cela a duré plusieurs mois. Tout à coup, depuis ce mois-ci, je n'ai plus de casse-tête du tout et tout re-captcha de 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 que en même temps, on m'a donné 100% de la RAM du GPU sur Colab. . C'est pourquoi je soupçonne que si vous êtes sur une liste noire théorique de Google, on ne vous fait pas confiance pour vous donner 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 du Re-captcha. Comme je l'ai dit, il pourrait aussi s'agir d'une simple coïncidence.

Answer 2

Hier soir, j'ai exécuté votre extrait et j'ai 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 VM, donc à chaque fois que vous redémarrez le runtime, vous avez la possibilité de changer de GPU, et il y a aussi une probabilité 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 la RAM libre du GPU est de 504 Mo, ce que je pensais être la cause de ResourceExhaustedError que j'ai eu la nuit dernière.

Answer 3

Si vous exécutez une cellule qui a juste
!kill -9 -1
dans celui-ci, ce qui aura pour effet d'effacer tout l'état de votre runtime (y compris la mémoire, le système de fichiers et le GPU) et de le redémarrer. Attendez 30 à 60 secondes et appuyez sur le bouton CONNECT en haut à droite pour vous reconnecter.

Answer 4

Description trompeuse de la part de Google. J'étais trop excité à ce sujet aussi, je suppose. J'ai tout configuré, j'ai chargé les données, et maintenant je ne peux rien faire avec, car mon ordinateur portable n'a que 500 Mo de mémoire.

Answer 5

Trouver le pid de Python3 et tuer le pid. Veuillez voir l'image ci-dessous

Note : tuer seulement python3(pid=130) pas jupyter python(122).