Google Colaboratory: informações enganosas sobre sua GPU (apenas 5% de RAM disponível para alguns usuários)

atualização: esta questão está relacionada às "Configurações do Notebook: acelerador de hardware: GPU" do Google Colab. Esta pergunta foi escrita antes de a opção "TPU" ser adicionada.

Lendo vários anúncios entusiasmados sobre o Google Colaboratory que fornece a GPU Tesla K80 gratuita, tentei executar a lição fast.ai sobre ele para nunca terminar - ficando rapidamente sem memória. Comecei a investigar o porquê.

O resultado final é que “Tesla K80 grátis” não é “grátis” para todos - para alguns, apenas uma pequena parte dele é “grátis”.

Eu me conecto ao Google Colab da Costa Oeste do Canadá e recebo apenas 0,5 GB do que deveria ser uma GPU RAM de 24 GB. Outros usuários têm acesso a 11 GB de GPU RAM.

Claramente, 0,5 GB de GPU RAM é insuficiente para a maioria dos trabalhos de ML / DL.

Se você não tem certeza do que obtém, aqui está uma pequena função de depuração que juntei (funciona apenas com a configuração de GPU do 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()

Executá-lo em um notebook jupyter antes de executar qualquer outro código me dá:

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

Os sortudos usuários que obtiverem acesso ao cartão completo verão:

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

Você vê alguma falha no meu cálculo da disponibilidade de RAM da GPU, emprestada da GPUtil?

Você pode confirmar que obtém resultados semelhantes se executar este código no notebook do Google Colab?

Se meus cálculos estiverem corretos, há alguma maneira de obter mais dessa GPU RAM na caixa gratuita?

atualização: Não sei por que alguns de nós recebem 1/20 do que outros usuários recebem. por exemplo, a pessoa que me ajudou a depurar isso é da Índia e ele fica com a coisa toda!

nota : por favor, não envie mais sugestões sobre como eliminar os notebooks potencialmente presos / em fuga / paralelos que podem estar consumindo partes da GPU. Não importa como você o divide, se você estiver no mesmo barco que eu e executar o código de depuração, verá que ainda obterá um total de 5% de GPU RAM (nesta atualização ainda).

Portanto, para evitar outra dúzia de respostas sugerindo inválido no contexto desta sugestão de tópico para! Kill -9 -1, vamos fechar este tópico:

A resposta é simples:

No momento em que este livro foi escrito, o Google simplesmente fornece apenas 5% da GPU para alguns de nós, enquanto 100% para os outros. Período.

atualização de dezembro de 2019: O problema ainda existe - os votos positivos desta questão continuam.

Atualização de março de 2019: Um ano depois, um funcionário do Google @AmiF comentou sobre o estado das coisas, afirmando que o problema não existe, e qualquer pessoa que pareça ter esse problema precisa simplesmente redefinir o tempo de execução para recuperar a memória. No entanto, os votos positivos continuam, o que para mim indica que o problema ainda existe, apesar da sugestão de @AmiF em contrário.

Atualização de dezembro de 2018: tenho uma teoria de que o Google pode ter uma lista negra de certas contas, ou talvez impressões digitais do navegador, quando seus robôs detectam um comportamento não padrão. Pode ser uma coincidência total, mas por algum tempo eu tive um problema com o Google Re-captcha em qualquer site que exigisse, onde muitas vezes eu teria que passar por dezenas de quebra-cabeças antes de conseguir passar levando mais de 10 minutos para realizar. Isso durou muitos meses. De repente, a partir deste mês, não recebo mais quebra-cabeças e qualquer re-captcha do Google é resolvido com apenas um clique do mouse, como costumava ser há quase um ano.

E por que estou contando essa história? Bem, porque ao mesmo tempo recebi 100% da GPU RAM no Colab . É por isso que suspeito que, se você está em uma lista negra teórica do Google, não está sendo confiável para receber muitos recursos de graça. Eu me pergunto se algum de vocês encontra a mesma correlação entre o acesso limitado à GPU e o pesadelo do Re-captcha. Como eu disse, também pode ser totalmente uma coincidência.

Ontem à noite, executei seu snippet e descobri exatamente o que você conseguiu:

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

mas hoje:

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

Acho que o motivo mais provável é que as GPUs são compartilhadas entre as VMs, então cada vez que você reiniciar o tempo de execução, você terá a chance de trocar a GPU, e também há probabilidade de você trocar para uma que está sendo usada por outros usuários.

ATUALIZADO: Acontece que posso usar a GPU normalmente mesmo quando a GPU RAM Free é de 504 MB, o que eu pensei ser a causa do ResourceExhaustedError que recebi ontem à noite.

Se você executar uma célula que contém apenas
! Kill -9 -1
, isso fará com que todo o estado do tempo de execução (incluindo memória, sistema de arquivos e GPU) seja apagado e reiniciado. Aguarde 30-60s e pressione o botão CONNECT no canto superior direito para reconectar.

Descrição enganosa por parte do Google. Eu também fiquei muito animado com isso, eu acho. Configurei tudo, carreguei os dados e agora não estou conseguindo fazer nada com isso porque tenho apenas 500Mb de memória alocada no meu Notebook.

Encontre o pid do Python3 e mate o pid. Por favor, veja a imagem abaixo

Observação: mate apenas python3 (pid = 130), não jupyter python (122).

Reinicie o kernel do Jupyter IPython:

!pkill -9 -f ipykernel_launcher

Não tenho certeza se essa lista negra é verdade! É bem possível que os núcleos sejam compartilhados entre os usuários. Também executei o teste e meus resultados são os seguintes:

Gen RAM Free: 12,9 GB | Tamanho do processo: 142,8 MB GPU RAM Livre: 11441 MB | Usado: 0MB | Util 0% | Total 11441 MB

Parece que também estou obtendo o núcleo completo. No entanto, executei algumas vezes e obtive o mesmo resultado. Talvez eu repita esta verificação algumas vezes durante o dia para ver se há alguma alteração.

basta dar uma tarefa pesada ao colab do google, ele vai nos pedir para mudar para 25 gb de ram.

exemplo, execute este código duas vezes:

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)

em seguida, clique em obter mais ram :)

Eu acredito que se tivermos vários notebooks abertos. O simples fato de fechar não interrompe o processo. Não descobri como impedir. Mas usei o top para encontrar o PID do python3 que estava rodando por mais tempo e usando a maior parte da memória e o matei. Tudo voltou ao normal agora.