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

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).

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.

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.

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.

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.

Trouvez le pid Python3 et tuez le pid. S'il vous plaît voir l'image ci-dessous

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

Redémarrez le noyau Jupyter IPython:

!pkill -9 -f ipykernel_launcher

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.

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

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 :)

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.