Google Colaboratory: оманлива інформація про свій графічний процесор (лише 5% оперативної пам’яті доступна для деяких користувачів)

оновлення: це питання пов'язане з "Налаштування ноутбука: Прискорювач обладнання: GPU" Google Colab. Це запитання було написане ще до того, як було додано варіант "ТПУ".

Читаючи декілька схвильованих оголошень про Google Colaboratory, що надають безкоштовний графічний процесор Tesla K80, я спробував провести на ньому fast.ai урок, щоб він ніколи не завершився - швидко не вистачає пам'яті. Я почав розслідувати, чому.

Суть полягає в тому, що "безкоштовний Tesla K80" не є "безкоштовним" для всіх - для деяких лише невеликий його фрагмент є "безкоштовним".

Я підключаюсь до Google Colab із Західного узбережжя Канади, і я отримую лише 0,5 ГБ того, що повинно бути 24 ГБ оперативної пам'яті GPU. Інші користувачі отримують доступ до 11 ГБ оперативної пам’яті GPU.

Очевидно, що 0,5 ГБ оперативної пам’яті GPU недостатньо для більшості робіт з ML / DL.

Якщо ви не впевнені, що отримаєте, ось невелику функцію налагодження я скребив разом (працює лише з налаштуваннями графічного процесора ноутбука):

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

Виконання його в зошиті з юпітером перед запуском будь-якого іншого коду дає мені:

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

Щасливі користувачі, які отримають доступ до повної картки, побачать:

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

Ви бачите якісь недоліки в моєму обчисленні наявності оперативної пам’яті GPU, запозиченої у GPUtil?

Чи можете ви підтвердити, що ви отримуєте подібні результати, якщо ви запускаєте цей код у ноутбуці Google Colab?

Якщо мої підрахунки є правильними, чи є можливість отримати більше тієї оперативної пам’яті GPU у вільній коробці?

оновлення: я не впевнений, чому деякі з нас отримують 1/20 того, що отримують інші користувачі. наприклад, людина, яка допомогла мені налагодити це з Індії, і він отримує все це!

Примітка . Будь ласка, не надсилайте більше пропозицій щодо вбивства потенційно застряглих / втеклих / паралельних ноутбуків, які можуть зайняти частину графічного процесора. Незалежно від того, як ви його нарізаєте, якщо ви знаходитесь в тому ж човні, що і я, і я мав би запустити код налагодження, ви побачите, що ви все одно отримуєте загальну суму 5% оперативної пам'яті GPU (станом на це оновлення досі).

Отже, щоб запобігти черговому десятку відповідей, які вказують на недійсні в контексті цього потоку пропозиції! Kill -9 -1, давайте закриємо цю тему:

Відповідь проста:

На цей час Google просто дає лише 5% GPU деяким з нас, тоді як 100% іншим. Період.

оновлення грудня-2019: Проблема все ще існує - оновлення цього питання продовжується.

оновлення березня 2019 року: Через рік працівник Google @AmiF прокоментував стан речей, заявивши, що проблеми не існує, і будь-хто, хто, схоже, має цю проблему, повинен просто скинути час виконання, щоб відновити пам'ять. Тим не менш, оновлення продовжуються, що, як на мене, це говорить про те, що проблема все ще існує, незважаючи на пропозицію @ AmiF протилежного.

оновлення за грудень 2018 року: я маю теорію про те, що Google може мати чорний список певних облікових записів або, можливо, відбитки пальців браузера, коли його роботи виявляють нестандартну поведінку. Це може бути повним збігом обставин, але я досить довгий час виникла проблема з Google Re-captcha на будь-якому веб-сайті, який трапився до цього, де мені довелося переглядати десятки головоломок, перш ніж мене дозволити. зайнявши у мене 10+ хв. Це тривало багато місяців. Раптом станом на цей місяць я не отримую загадок, і будь-яка повторна команда google вирішується лише одним клацанням миші, як це було майже рік тому.

І чому я розповідаю цю історію? Ну, тому що в той же час мені дали 100% оперативної пам’яті GPU на Colab . Ось чому я підозрюю, що якщо ви перебуваєте в теоретичному чорному списку Google, то вам не довіряють, щоб вам дали багато ресурсів безкоштовно. Цікаво, чи знайде хтось із вас однаковий зв’язок між обмеженим доступом до GPU та кошмаром Re-captcha. Як я вже казав, це може бути і зовсім збігом обставин.

Минулої ночі я запустив ваш фрагмент і отримав саме те, що ви отримали:

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

але сьогодні:

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

Я думаю, що найбільш вірогідною причиною є те, що графічні процесори поділяються між віртуальними відеосигналами, тому кожен раз, коли ви перезапускаєте час виконання, у вас є шанс переключити GPU, а також існує ймовірність переходу на той, який використовують інші користувачі.

ОНОВЛЕНО: Виявляється, я можу нормально використовувати GPU, навіть коли GPU RAM Free становить 504 Мб, що я вважав причиною ResourceExhaustedError, який я отримав минулої ночі.

Якщо ви будете виконувати клітинку, яка щойно містить
! Kill -9 -1
, це призведе до того, що всі стани виконання програми (включаючи пам'ять, файлову систему та GPU) будуть очищені та перезапущені. Зачекайте 30-60-х років і натисніть кнопку З'єднати вгорі праворуч, щоб знову підключитися.

Оманливий опис з боку Google. Я теж занадто схвильований цим, мабуть. Налаштуйте все, завантажте дані, і тепер я нічого не можу з цим зробити, оскільки у моєму ноутбуці було виділено лише 500 Мб пам'яті.

Знайдіть під Python3 і вбийте його. Будь ласка, дивіться зображення нижче

Примітка: вбийте лише python3 (pid = 130), а не jupyter python (122).

Перезапустіть ядро ​​Jupyter IPython:

!pkill -9 -f ipykernel_launcher

Я не впевнений, чи справжній цей чорний список! Цілком можливо, що сердечники поділяються між користувачами. Я також пройшов тест, і мої результати такі:

Gen RAM безкоштовно: 12,9 ГБ | Розмір програми: 142,8 МБ ОЗУ GPU безкоштовно: 11441 МБ | Використовується: 0 Мб | Утиль 0% | Всього 11441MB

Здається, я отримую також повне ядро. Однак я пробіг її кілька разів, і я отримав такий же результат. Можливо, я повторю цю перевірку кілька разів протягом дня, щоб побачити, чи є якісь зміни.

просто дайте важке завдання гугл колабу, він попросить нас змінити до 25 ГБ барана.

Наприклад, запустіть цей код двічі:

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)

потім натисніть, щоб отримати більше оперативної пам’яті :)

Я вірю, якщо у нас відкрито кілька зошитів. Просто закриття його фактично не зупиняє процес. Я не зрозумів, як це зупинити. Але я використав топ, щоб знайти PID python3, який працював найдовше і використовував більшу частину пам'яті, і я вбив його. Зараз все нормально.