Google Colaboratory: вводящая в заблуждение информация о его графическом процессоре (доступно только 5% ОЗУ для некоторых пользователей)

обновление: этот вопрос относится к Google Colab "Настройки ноутбука: Аппаратный ускоритель: GPU". Этот вопрос был написан до добавления опции "ТПУ".

Читая многочисленные восторженные объявления о том, что Google Colab Laboratory предоставляет бесплатный графический процессор Tesla K80, я попытался быстро запустить. Урок, чтобы он никогда не заканчивался - быстро не хватало памяти. Я начал расследовать почему.

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

Я подключаюсь к Google Colab из Западного побережья Канады и получаю только 0,5 ГБ от того, что должно быть 24 ГБ ОЗУ GPU. Другие пользователи получают доступ к 11 ГБ ОЗУ графического процессора.

Очевидно, что 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 isnt 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()

Выполнение этого в блокноте jupyter перед выполнением любого другого кода дает мне:

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

Видите ли вы какие-либо изъяны в моих расчетах доступности ОЗУ графического процессора, заимствованного у GPUtil?

Можете ли вы подтвердить, что получаете аналогичные результаты, если запускаете этот код в блокноте Google Colab?

Если мои расчеты верны, есть ли способ получить больше этой оперативной памяти GPU на бесплатной коробке?

обновление: я не уверен, почему некоторые из нас получают 1/20 от того, что получают другие пользователи. например, человек, который помог мне отладить это из Индии, и он получил все это!

примечание: пожалуйста, не присылайте больше предложений о том, как убить потенциально зависшие/сбежавшие/параллельные ноутбуки, которые могут потреблять части графического процессора. Независимо от того, как вы нарезаете его, если вы находитесь в той же лодке, что и я, и должны были выполнить код отладки, вы увидите, что вы все равно получаете в общей сложности 5% ОЗУ графического процессора (по состоянию на это обновление до сих пор).

Ответы

Ответ 1

Поэтому, чтобы предотвратить еще дюжину ответов, предлагающих недопустимые в контексте этой цепочки предложения! Kill -9 -1, разрешите закрыть эту ветку:

Ответ прост:

На момент написания статьи Google просто отдает только 5% GPU некоторым из нас, тогда как 100% - другим. Период.

март 2019 обновление: год спустя Google наконец заметил эту ветку и послал @AmiF, чтобы дискредитировать ее, подразумевая, что каждый, у кого есть эта проблема, является некомпетентным пользователем, который не может понять, как сбросить время выполнения для восстановления памяти. @AmiF далее предполагает, что, возможно, эта проблема была просто ошибкой в их коде и что мы, пользователи, не можем сказать политику компании против ошибки.

К сожалению, полное раскрытие информации не производится, и нам остается только догадываться о том, что на самом деле может происходить. Очевидно, что коммерческая компания будет иметь оговорки в отношении того, с кем им приятно, и поэтому здесь невозможно избежать дискриминации. Это имеет смысл и очень логично. Поскольку этот ресурс предоставляется бесплатно, мы не можем на самом деле жаловаться, а только спрашиваем, почему некоторые из нас занесены в черный список, в то время как другие из других идентичных установок/локалей - нет.

Так как мой личный аккаунт был удален из черного списка в декабре 2018 года (см. мое обновление ниже), я могу полагаться только на других пользователей, которые все еще находятся в черном списке, чтобы помочь говорить правду. Пока я пишу это обновление, эта тема получила еще одно возражение.

Тем не менее, давайте надеяться, что Google придет конец черного списка, по крайней мере для тех, кто просит, чтобы его исключили из списка. Большинство из нас не делали никаких компрометирующих действий, чтобы оказаться в таком списке, и их просто поймали незрелые мозги машинного обучения, и им не дают возможности доказать свою вину. @AmyF предложила сообщить об этой проблеме на http://github.com/googlecolab/colabtools/issues - если вы сообщите о проблеме и отмахнетесь от ее закрытого билета без расследования, как в этом случае, пожалуйста, опубликуйте ссылку на вашу нерешенную проблему в комментариях этого ответа, чтобы мы могли попросить некоторую ответственность.

И, конечно же, перед тем, как вы проголосуете за этот поток, выполните "Сброс всех времени выполнения" в меню "Время выполнения" в colab и посмотрите, не возникла ли у вас действительно проблема с незаконченными ноутбуками, которые все еще потребляют ОЗУ GPU, и вы политика чёрных списков не оказывает на них никакого влияния.

После прекращения голосования мы узнаем, что эта политика дискриминации была отменена. К сожалению, на данный момент это не тот случай, поэтому комментарии @AmyF ниже весьма сомнительны.

Обновление от декабря 2018 года: у меня есть теория, что Google может иметь черный список определенных учетных записей или, возможно, отпечатки пальцев браузера, когда его роботы обнаруживают нестандартное поведение. Это может быть полное совпадение, но в течение некоторого времени у меня была проблема с Google Re-captcha на любом веб-сайте, который требовал его, когда мне приходилось проходить десятки головоломок, прежде чем мне позволили пройти, часто мне нужно 10+ мин, чтобы выполнить. Это продолжалось много месяцев. Внезапно, начиная с этого месяца, я не вижу никаких загадок, и любая повторная проверка Google разрешается одним щелчком мыши, как это было почти год назад.

И почему я рассказываю эту историю? Ну, потому что в то же время мне дали 100% ОЗУ GPU на Colab. Вот почему я подозреваю, что если вы находитесь в теоретическом черном списке Google, то вам не доверяют, что вам предоставят много ресурсов бесплатно. Интересно, найдет ли кто-нибудь из вас такую же корреляцию между ограниченным доступом к графическому процессору и кошмаром Re-captcha? Как я уже сказал, это также может быть совпадением.

Ответ 2

Прошлой ночью я запустил ваш фрагмент и получил именно то, что получил:

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 RAM Free составляет 504 МБ, что, как я думал, является причиной ResourceExhaustedError, которую я получил вчера вечером.

Ответ 3

Если вы выполните ячейку, которая
! kill -9 -1
в нем, что приведет к очистке и повторному запуску всего вашего состояния времени выполнения (включая память, файловую систему и графический процессор). Подождите 30-60 секунд и нажмите кнопку CONNECT в правом верхнем углу для повторного подключения.

Ответ 4

Неверное описание со стороны Google. Наверное, я тоже слишком взволнован. Настройте все, загрузите данные, и теперь я не могу ничего с этим сделать из-за того, что для моего ноутбука выделено только 500 МБ памяти.

Ответ 5

Я также получил

GPU RAM бесплатно: 16 МБ | Используется: 11423MB | 100% | Всего 11439 МБ

Я подозреваю, что, хотя каждый пользователь получает выделенную виртуальную машину, все виртуальные машины являются многопользователями общей аппаратной машины... так что делятся 32 ГБ Tesla K80.

Немного разочаровывает.

В результате я отказываюсь от использования google colab! : О (

Ответ 6

Найти Python3 pid и убить pid. Пожалуйста, смотрите изображение ниже

Примечание: убить только python3 (pid = 130), а не jupyter python (122).

Ответ 7

Перезапустить Jupyter IPython Kernel:

!pkill -9 -f ipykernel_launcher

Ответ 8

Я не уверен, если этот черный список правда! Вполне возможно, что ядра распределены между пользователями. Я также провел тест, и мои результаты следующие:

Gen RAM Free: 12,9 ГБ | Размер процессора: 142,8 МБ ОЗУ графического процессора Свободно: 11441 МБ | Используется: 0MB | Использовать 0% | Всего 11441 МБ

Кажется, я тоже получаю полное ядро. Однако я запускал его несколько раз и получал тот же результат. Может быть, я повторю эту проверку несколько раз в течение дня, чтобы увидеть, есть ли какие-либо изменения.

Ответ 9

Я считаю, что если у нас есть несколько ноутбуков, открытые. Просто закрытие его фактически не останавливает процесс. Я не понял, как остановить это. Но я использовал top, чтобы найти PID из python3, который работал наиболее долго и использовал большую часть памяти, и я его убил. Теперь все в порядке.

Ответ 10

Вы можете сбросить все среды выполнения, в некоторых случаях это исправит проблемы с памятью.

Кроме того, я обнаружил, что если у вас открыто несколько проектов Colab, это увеличит вашу оперативную память.

Ответ 11

просто дайте тяжелую задачу гугл колабу, он попросит нас перейти на 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)

затем нажмите на получить больше оперативной памяти :)

Ответ 12

!pkill -9 -f ipykernel_launcher

Это освободило пространство