Google Colaboratory: Irreführende Informationen zur GPU (einigen Nutzern stehen nur 5% RAM zur Verfügung)


110

Update: Diese Frage bezieht sich auf Google Colabs "Notebook-Einstellungen: Hardwarebeschleuniger: GPU". Diese Frage wurde geschrieben, bevor die Option "TPU" hinzugefügt wurde.

Als ich mehrere aufgeregte Ankündigungen über Google Colaboratory las, das eine kostenlose Tesla K80-GPU bereitstellte, versuchte ich, fast.ai zu lernen, damit es nie fertig wird - schnell geht der Speicher aus. Ich begann zu untersuchen, warum.

Das Fazit ist, dass "free Tesla K80" nicht für alle "kostenlos" ist - für einige ist nur ein kleiner Teil davon "kostenlos".

Ich stelle von West Coast Canada aus eine Verbindung zu Google Colab her und erhalte nur 0,5 GB eines angeblich 24 GB GPU-RAM. Andere Benutzer erhalten Zugriff auf 11 GB GPU-RAM.

Offensichtlich reichen 0,5 GB GPU-RAM für die meisten ML / DL-Arbeiten nicht aus.

Wenn Sie nicht sicher sind, was Sie erhalten, finden Sie hier eine kleine Debug-Funktion, die ich zusammengestellt habe (funktioniert nur mit der GPU-Einstellung des Notebooks):

# 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()

Wenn ich es in einem Jupiter-Notizbuch ausführe, bevor ich einen anderen Code ausführe, habe ich folgende Möglichkeiten:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util  95% | Total 11439MB

Die glücklichen Benutzer, die Zugriff auf die vollständige Karte erhalten, werden sehen:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 11439MB | Used: 0MB | Util  0% | Total 11439MB

Sehen Sie einen Fehler in meiner Berechnung der GPU-RAM-Verfügbarkeit, die von GPUtil ausgeliehen wurde?

Können Sie bestätigen, dass Sie ähnliche Ergebnisse erhalten, wenn Sie diesen Code auf dem Google Colab-Notizbuch ausführen?

Wenn meine Berechnungen korrekt sind, gibt es eine Möglichkeit, mehr von diesem GPU-RAM auf die kostenlose Box zu bekommen?

Update: Ich bin mir nicht sicher, warum einige von uns 1/20 von dem bekommen, was andere Benutzer bekommen. zB die Person, die mir beim Debuggen geholfen hat, kommt aus Indien und bekommt das Ganze!

Hinweis : Bitte senden Sie keine weiteren Vorschläge zum Beenden der potenziell festgefahrenen / außer Kontrolle geratenen / parallelen Notebooks, die möglicherweise Teile der GPU verbrauchen. Egal wie Sie es schneiden, wenn Sie sich im selben Boot wie ich befinden und den Debug-Code ausführen würden, würden Sie sehen, dass Sie immer noch insgesamt 5% des GPU-RAM erhalten (ab diesem Update noch).


Irgendeine Lösung dafür? Warum bekomme ich dabei unterschiedliche Ergebnisse? cat / proc / meminfo
MiloMinderbinder

Ja, das gleiche Problem, nur etwa 500 MB GPU-RAM ... irreführende Beschreibung :(
Naveen

2
Probieren Sie die Open Source Data Science-Tools von IBM (kognitive Klasse.ai) aus, da diese auch über eine kostenlose GPU mit Jupyter-Notebooks verfügen.
AQ

Ich habe diese Frage auf einen Zustand zurückgesetzt, in dem tatsächlich eine Frage enthalten ist. Wenn Sie mehr recherchiert und eine Antwort gefunden haben, befindet sich der entsprechende Ort im Antwortfeld. Es ist falsch, die Frage mit einer Lösung zu aktualisieren.
Chris Hayes

@ ChrisHayes, ich verstehe Ihre Absicht, aber das ist nicht richtig, da Ihr Rollback eine ganze Reihe relevanter Details gelöscht hat, die jetzt verschwunden sind. Wenn Sie eine bessere Formulierung vorschlagen möchten, die besser zu den Regeln dieser Community passt, tun Sie dies bitte, aber ansonsten setzen Sie bitte Ihren Rollback zurück. Danke dir. ps Ich habe die Antwort bereits gepostet .
Stason

Antworten:


41

Um zu verhindern, dass ein weiteres Dutzend Antworten im Kontext dieses Thread-Vorschlags für! Kill -9 -1 ungültig werden, schließen wir diesen Thread:

Die Antwort ist einfach:

Zum jetzigen Zeitpunkt gibt Google einigen von uns nur 5% der GPU, den anderen 100%. Zeitraum.

Update Dezember 2019: Das Problem besteht weiterhin - die positiven Stimmen dieser Frage bleiben weiterhin bestehen.

Update März 2019: Ein Jahr später kommentierte ein Google-Mitarbeiter @AmiF den Stand der Dinge und erklärte, dass das Problem nicht besteht. Jeder, der dieses Problem zu haben scheint, muss einfach seine Laufzeit zurücksetzen, um den Speicher wiederherzustellen. Die positiven Stimmen gehen jedoch weiter, was für mich bedeutet, dass das Problem trotz des gegenteiligen Vorschlags von @ AmiF immer noch besteht.

Update Dezember 2018: Ich habe die Theorie, dass Google möglicherweise eine schwarze Liste bestimmter Konten oder möglicherweise Browser-Fingerabdrücke hat, wenn seine Roboter ein nicht standardmäßiges Verhalten feststellen. Es könnte ein totaler Zufall sein, aber für einige Zeit hatte ich ein Problem mit Google Re-Captcha auf jeder Website, die es erforderte, wo ich Dutzende von Rätseln durchgehen musste, bevor ich oft durchgelassen wurde Ich brauche mehr als 10 Minuten, um das zu erreichen. Dies dauerte viele Monate. Ab diesem Monat bekomme ich plötzlich überhaupt keine Rätsel mehr und jedes Google-Re-Captcha wird mit nur einem Mausklick gelöst, wie es vor fast einem Jahr war.

Und warum erzähle ich diese Geschichte? Nun, weil ich gleichzeitig 100% des GPU-RAM auf Colab erhalten habe . Aus diesem Grund habe ich den Verdacht, dass Ihnen nicht vertraut wird, wenn Sie auf einer theoretischen schwarzen Liste von Google stehen, dass Ihnen viele Ressourcen kostenlos zur Verfügung gestellt werden. Ich frage mich, ob einer von Ihnen die gleiche Korrelation zwischen dem eingeschränkten GPU-Zugriff und dem Re-Captcha-Albtraum findet. Wie gesagt, es könnte auch ein Zufall sein.


4
Ihre Aussage: "Zum jetzigen Zeitpunkt gibt Google einigen von uns nur 5% der GPU, den anderen 100%. Zeitraum." ist falsch - Colab hat noch nie so gearbeitet. Alle diagnostizierten Fälle, in denen Benutzer weniger als das gesamte zur Verfügung stehende GPU-RAM sehen, haben sich auf einen anderen Prozess beschränkt (der vom selben Benutzer, möglicherweise in einem anderen Notebook, gestartet wurde) und den Rest des GPU-RAM verwendet.
Ami F

11
Zukünftige Leser: Wenn Sie glauben, dass diese oder ähnliche Symptome der Nichtverfügbarkeit des GPU-RAM auftreten, erhalten Sie mit "Alle Laufzeiten zurücksetzen" im Menü "Laufzeit" eine neue VM, die sicherstellt, dass keine veralteten Prozesse mehr am GPU-RAM festhalten. Wenn Sie dieses Symptom sofort nach Verwendung dieser Menüoption immer noch sehen, melden Sie bitte einen Fehler unter github.com/googlecolab/colabtools/issues
Ami F

Ihre Realität unterscheidet sich deutlich von der Realität vieler anderer, die diesen Beitrag ein Jahr später nach seiner Erstellung weiter abstimmen. Es ist sehr wahrscheinlich, dass einige Benutzer tatsächlich auf das stoßen, was Sie beschrieben haben, aber dies ist nicht bei allen der Fall. Ich bin mir also nicht sicher, wie Ihre Aussage hier hilft. Außerdem, als jemand genau diese Frage in dem von Ihnen empfohlenen Repo stellte, bekam er eine BS-Antwort und sein Ticket wurde geschlossen: github.com/googlecolab/colabtools/issues/52
stason

2
Falls es unklar war: Ich beschreibe nicht, was meiner Meinung nach die Implementierung auf der Beobachtung des Verhaltens des Systems als Benutzer basiert. Ich beschreibe, was ich direkt von der Implementierung weiß. Ich habe in der Hoffnung gepostet, dass Benutzer, die weniger als die vollständige Verfügbarkeit sehen, dies als Problem melden (entweder Benutzerfehler oder Systemfehler), anstatt die obigen falschen Aussagen zu lesen und davon auszugehen, dass die Dinge wie beabsichtigt funktionieren.
Ami F

1
Nein, GPUs wurden nie geteilt, und das von Ihnen verknüpfte Beispiel enthält keine Lügen (lediglich eine Vermutung und Erklärung des mit Abstand häufigsten Grundes für das gemeldete Symptom).
Ami F

22

Letzte Nacht habe ich dein Snippet laufen lassen und genau das bekommen, was du hast:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util  95% | Total 11439MB

aber heute:

Gen RAM Free: 12.2 GB  I Proc size: 131.5 MB
GPU RAM Free: 11439MB | Used: 0MB | Util   0% | Total 11439MB

Ich denke, der wahrscheinlichste Grund ist, dass die GPUs von VMs gemeinsam genutzt werden. Bei jedem Neustart der Laufzeit haben Sie also die Möglichkeit, die GPU zu wechseln, und es besteht auch die Wahrscheinlichkeit, dass Sie zu einer wechseln, die von anderen Benutzern verwendet wird.

AKTUALISIERT: Es stellt sich heraus, dass ich die GPU normal verwenden kann, selbst wenn die GPU RAM Free 504 MB beträgt, was ich als Ursache für ResourceExhaustedError angesehen habe, den ich letzte Nacht bekommen habe.


1
Ich glaube, ich habe mich innerhalb weniger Tage wahrscheinlich 50 Mal neu verbunden und hatte anfangs immer die gleiche Auslastung von 95%. Nur einmal habe ich 0% gesehen. Bei all diesen Versuchen bekam ich einen Cuda-Speicherfehler, als er sich 100% näherte.
Stason

Was meinst du mit deinem Update? Kannst du noch Sachen mit 500Mb laufen lassen? Ich habe das gleiche Problem, ich RuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84
bekomme

6

Wenn Sie eine Zelle ausführen, in der sich gerade
! Kill -9 -1
befindet, wird der gesamte Laufzeitstatus (einschließlich Speicher, Dateisystem und GPU) gelöscht und neu gestartet. Warten Sie 30-60 Sekunden und drücken Sie die CONNECT-Taste oben rechts, um die Verbindung wiederherzustellen.


2
Danke, aber Ihr Vorschlag ändert nichts. Ich bekomme immer noch 5% des GPU-RAM.
Stason

Das hilft nicht. Nach dem Beenden und erneuten Verbinden ist der GPU-Speicher immer noch bei 500 MB von ~ 12 GB.
ivan_bilan

4

Irreführende Beschreibung seitens Google. Ich war auch zu aufgeregt darüber, denke ich. Richten Sie alles ein, laden Sie die Daten, und jetzt kann ich nichts mehr damit anfangen, da meinem Notebook nur 500 MB Speicher zugewiesen sind.


3

Geben Sie Google Colab eine schwere Aufgabe. Sie werden aufgefordert, auf 25 GB RAM umzusteigen.

Geben Sie hier die Bildbeschreibung ein

Beispiel: Führen Sie diesen Code zweimal aus:

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)

dann klicke auf mehr RAM bekommen :) Geben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein


Ich kann das bestätigen. Ich hatte einen 15-Gig-Datensatz mit hauptsächlich HD-Bildern (mein Laufwerk hat 30 Gigs anstelle von 15 Gigs) und ich habe meinen Code ausgeführt, um die Größe des Bilddatensatzes auf 224.224.3 zu ändern, und ich wurde auf eine hohe RAM-Laufzeit umgestellt. Dann, als ich anfing zu trainieren, stieg die RAM-Nutzung auf 31,88 GB.
Anshuman Kumar

Ich möchte jedoch hinzufügen, dass ich nach Abschluss dieses Auftrags in den letzten 24 Stunden nicht mehr auf eine andere GPU / TPU zugreifen konnte. Möglicherweise wurde ich auf die schwarze Liste gesetzt.
Anshuman Kumar

@AnshumanKumar, geben Sie die hohe Last am Anfang nur sonst, wenn Sie die Konfiguration ändern, verlieren Sie zuvor erledigte Arbeit, die in RAM. Ich habe 24 Stunden lang keine hohe Konfiguration verwendet, daher weiß ich nichts über Blacklisting.
Jainil Patel

Ja, das ist mir passiert. Die Arbeit wurde jedoch erledigt.
Anshuman Kumar

2

Finde die Python3-PID und töte die PID. Bitte sehen Sie das Bild untenGeben Sie hier die Bildbeschreibung ein

Hinweis: Töte nur Python3 (pid = 130), nicht Jupyter Python (122).


Wird dies bei dem Speicherproblem helfen? Tötest du dann nicht alle Runs anderer Leute?
ivan_bilan

das hilft nicht, habe das gleiche Problem:GPU RAM Free: 564MB
ivan_bilan

2

Starten Sie den Jupyter IPython Kernel neu:

!pkill -9 -f ipykernel_launcher

1
schließen, aber keine Zigarre:GPU RAM Free: 564MB
ivan_bilan

Als einfachere Methode zum Neustarten des Kernels können Sie einfach auf Runtime | klicken Starten Sie die Laufzeit neu ... oder die VerknüpfungCMD/CTRL+M
Agile Bean

2

Ich bin mir nicht sicher, ob diese schwarze Liste wahr ist! Es ist eher möglich, dass die Kerne von Benutzern gemeinsam genutzt werden. Ich habe auch den Test durchgeführt und meine Ergebnisse sind die folgenden:

Gen RAM Free: 12,9 GB | Prozessgröße: 142,8 MB GPU RAM Frei: 11441 MB | Verwendet: 0MB | Util 0% | Insgesamt 11441 MB

Es scheint, dass ich auch vollen Kern bekomme. Ich habe es jedoch ein paar Mal ausgeführt und das gleiche Ergebnis erzielt. Vielleicht werde ich diese Überprüfung einige Male im Laufe des Tages wiederholen, um festzustellen, ob sich etwas ändert.


1

Ich glaube, wenn wir mehrere Notizbücher geöffnet haben. Nur das Schließen stoppt den Prozess nicht. Ich habe nicht herausgefunden, wie ich es aufhalten kann. Aber ich habe top verwendet, um die PID des Python3 zu finden, der am längsten lief und den größten Teil des Speichers verwendete, und ich habe ihn getötet. Jetzt ist alles wieder normal.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.