Google Colaboratory: wprowadzające w błąd informacje o jego GPU (tylko 5% pamięci RAM dostępne dla niektórych użytkowników)

aktualizacja: to pytanie jest związane z „Ustawieniami notebooka: Akcelerator sprzętowy: GPU” Google Colab. To pytanie zostało napisane przed dodaniem opcji „TPU”.

Czytając wiele podekscytowanych ogłoszeń o Google Colaboratory dostarczającym darmowy procesor graficzny Tesla K80, próbowałem działać szybko. A lekcja na ten temat, aby nigdy się nie skończyła - szybko zabrakło pamięci. Zacząłem się zastanawiać, dlaczego.

Najważniejsze jest to, że „bezpłatna Tesla K80” nie jest „bezpłatna” dla wszystkich - dla niektórych tylko niewielka jej część jest „bezpłatna”.

Łączę się z Google Colab z Zachodniego Wybrzeża Kanady i otrzymuję tylko 0,5 GB z tego, co powinno być 24 GB pamięci RAM GPU. Inni użytkownicy uzyskują dostęp do 11 GB pamięci RAM GPU.

Najwyraźniej 0,5 GB pamięci RAM GPU jest niewystarczające dla większości zadań ML / DL.

Jeśli nie jesteś pewien, co otrzymujesz, oto mała funkcja debugowania, którą zeskrobałem razem (działa tylko z ustawieniem GPU notebooka):

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

Wykonanie go w notebooku jupyter przed uruchomieniem jakiegokolwiek innego kodu daje mi:

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

Szczęśliwi użytkownicy, którzy uzyskają dostęp do pełnej karty, zobaczą:

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

Czy widzisz jakąś lukę w moich obliczeniach dostępności pamięci RAM na GPU, pożyczonej od GPUtil?

Czy możesz potwierdzić, że uzyskasz podobne wyniki, jeśli uruchomisz ten kod na notatniku Google Colab?

Jeśli moje obliczenia są prawidłowe, czy jest jakiś sposób, aby uzyskać więcej pamięci RAM GPU w darmowym pudełku?

aktualizacja: nie jestem pewien, dlaczego niektórzy z nas otrzymują 1/20 tego, co otrzymują inni użytkownicy. np. osoba, która pomogła mi w debugowaniu tego, pochodzi z Indii i dostaje wszystko!

Uwaga : nie wysyłaj więcej sugestii, jak zabić potencjalnie zablokowane / niekontrolowane / równoległe notebooki, które mogą zużywać części GPU. Bez względu na to, jak go pokroisz, jeśli jesteś na tej samej łodzi co ja i miałeś uruchomić kod debugowania, zobaczysz, że nadal masz łącznie 5% pamięci RAM GPU (nadal w tej aktualizacji).

Aby więc zapobiec kolejnemu tuzinowi odpowiedzi sugerujących nieprawidłowe w kontekście tej sugestii wątku! Kill -9-1, zamknijmy ten wątek:

Odpowiedź jest prosta:

W chwili pisania tego tekstu Google po prostu przekazuje tylko 5% GPU niektórym z nas, podczas gdy innym 100%. Kropka.

Aktualizacja z grudnia 2019 r .: Problem nadal istnieje - głosy za to pytanie nadal trwają.

Aktualizacja z marca 2019 r .: Rok później pracownik Google @AmiF skomentował stan rzeczy, stwierdzając, że problem nie istnieje, a każdy, kto wydaje się mieć ten problem, musi po prostu zresetować swoje środowisko wykonawcze, aby odzyskać pamięć. Jednak głosy poparcia trwają, co dla mnie oznacza, że ​​problem nadal istnieje, pomimo sugestii @ AmiF, że jest inaczej.

Aktualizacja z grudnia 2018 r .: Mam teorię, że Google może mieć czarną listę niektórych kont lub być może odciski palców przeglądarki, gdy jego roboty wykryją niestandardowe zachowanie. To może być całkowity zbieg okoliczności, ale od dłuższego czasu miałem problem z Google Re-captcha na każdej stronie, która tego wymagała, gdzie musiałem rozwiązać dziesiątki zagadek, zanim pozwolono mi przejść, często co zajmuje mi ponad 10 minut. Trwało to wiele miesięcy. Nagle od tego miesiąca nie dostaję żadnych łamigłówek, a każda re-captcha w Google jest rozwiązywana za pomocą jednego kliknięcia myszą, tak jak to było prawie rok temu.

A dlaczego opowiadam tę historię? Cóż, ponieważ w tym samym czasie otrzymałem 100% pamięci RAM GPU na Colab . Dlatego podejrzewam, że jeśli jesteś na teoretycznej czarnej liście Google, nie ufasz, że otrzymasz wiele zasobów za darmo. Zastanawiam się, czy któryś z was znalazł tę samą korelację między ograniczonym dostępem do GPU a koszmarem Re-captcha. Jak powiedziałem, może to być również zbieg okoliczności.

Ostatniej nocy uruchomiłem twój fragment i otrzymałem dokładnie to, co masz:

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

ale dzisiaj:

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

Myślę, że najbardziej prawdopodobnym powodem jest to, że procesory GPU są współdzielone między maszynami wirtualnymi, więc za każdym razem, gdy uruchamiasz ponownie środowisko wykonawcze, masz szansę zmienić GPU, a także istnieje prawdopodobieństwo, że przełączysz się na taki, który jest używany przez innych użytkowników.

AKTUALIZACJA: Okazuje się, że mogę normalnie korzystać z GPU, nawet gdy RAM GPU Wolny wynosi 504 MB, co uważałem za przyczynę ResourceExhaustedError, który dostałem ostatniej nocy.

Jeśli uruchomisz komórkę, która właśnie zawiera
! Kill -9-1
, spowoduje to wyczyszczenie i ponowne uruchomienie całego stanu środowiska wykonawczego (w tym pamięci, systemu plików i GPU). Poczekaj 30-60 sekund i naciśnij przycisk CONNECT w prawym górnym rogu, aby ponownie nawiązać połączenie.

Wprowadzający w błąd opis ze strony Google. Myślę, że też byłem tym zbyt podekscytowany. Skonfigurowałem wszystko, załadowałem dane, a teraz nie mogę nic z tym zrobić, ponieważ do mojego notebooka przydzielono tylko 500 MB pamięci.

Znajdź pid Python3 i zabij pid. Zobacz poniższy obrazek

Uwaga: zabij tylko pythona3 (pid = 130), a nie jupyter python (122).

Zrestartuj jądro Jupyter IPython:

!pkill -9 -f ipykernel_launcher

Nie jestem pewien, czy ta czarna lista jest prawdziwa! Jest raczej możliwe, że rdzenie są dzielone między użytkowników. Przeprowadziłem również test, a moje wyniki są następujące:

Wolna pamięć RAM generacji: 12,9 GB | Rozmiar procesu: 142,8 MB RAM GPU Wolny: 11441 MB | Używany: 0MB | Utylizacja 0% | Razem 11441 MB

Wygląda na to, że mam również pełny rdzeń. Jednak uruchomiłem go kilka razy i otrzymałem ten sam wynik. Może powtórzę to sprawdzenie kilka razy w ciągu dnia, aby sprawdzić, czy jest jakaś zmiana.

po prostu daj ciężkie zadanie Google Colab, poprosi nas o zmianę na 25 GB pamięci RAM.

przykład uruchom ten kod dwukrotnie:

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)

następnie kliknij, aby uzyskać więcej pamięci RAM :)

Myślę, że mamy otwartych wiele zeszytów. Samo zamknięcie go nie zatrzymuje procesu. Nie wymyśliłem, jak to zatrzymać. Ale użyłem top, aby znaleźć PID pythona3, który działał najdłużej i zużywał większość pamięci, i go zabiłem. Teraz wszystko wróciło do normy.