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

111

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).

stason
fonte
Alguma solução para isso? por que obtenho resultados diferentes ao fazer! cat / proc / meminfo
MiloMinderbinder
Sim, mesmo problema, apenas cerca de 500 MB de memória RAM da GPU ... descrição enganosa :(
Naveen,
2
Experimente as ferramentas de ciência de dados de software livre da IBM (cognitiveclass.ai), pois elas também têm uma GPU gratuita com notebooks jupyter.
AQ de
Retrocedi esta pergunta para um estado em que realmente há uma pergunta nela. Se você fez mais pesquisas e encontrou uma resposta, o local apropriado para isso é na caixa de resposta. É incorreto atualizar a questão com uma solução.
Chris Hayes
@ChrisHayes, entendo sua intenção, mas isso não está certo, já que sua reversão excluiu um monte de detalhes relevantes que agora se foram. Se você gostaria de sugerir uma redação melhor que se encaixa melhor nas regras desta comunidade, faça-o, mas caso contrário, reverta sua reversão. Obrigado. ps eu já postei a resposta .
stason

Respostas:

42

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.

stason
fonte
4
Sua declaração de "No momento em que este documento foi escrito, o Google simplesmente fornece apenas 5% da GPU para alguns de nós, enquanto 100% para os outros. Ponto final." está incorreto - o Colab nunca funcionou assim. Todos os casos diagnosticados de usuários vendo menos do que o complemento total da RAM da GPU disponível para eles se resumiram a outro processo (iniciado pelo mesmo usuário, possivelmente em outro notebook) usando o resto da RAM da GPU.
Ami F
11
Futuros leitores: se você acha que está vendo este ou outros sintomas semelhantes de indisponibilidade da GPU RAM, "Redefinir todos os tempos de execução" no menu Runtime lhe dará uma VM nova garantindo que nenhum processo obsoleto ainda esteja segurando a GPU RAM. Se você ainda vir esse sintoma imediatamente após usar essa opção de menu, registre um bug em github.com/googlecolab/colabtools/issues
Ami F
A sua realidade é claramente diferente da realidade de muitas outras pessoas que continuam votando neste post um ano depois de sua criação. É muito provável que alguns usuários encontrem o que você descreveu, mas não é o caso para todos. Portanto, não tenho certeza de como sua declaração ajuda aqui. Além disso, quando alguém fez essa pergunta exata no repo que você recomendou, ele obteve uma resposta BS e seu tíquete foi fechado: github.com/googlecolab/colabtools/issues/52
stason
2
Caso não tenha ficado claro: não estou descrevendo o que acredito que a implementação se baseia na observação do comportamento do sistema como usuário. Estou descrevendo o que conheço diretamente a implementação. Eu postei esperando que os usuários que veem menos do que a disponibilidade total relatassem isso como um problema (erro do usuário ou bug do sistema) em vez de ler as declarações incorretas acima e presumir que as coisas estão funcionando como planejado.
Ami F
1
Não, as GPUs nunca foram compartilhadas e não há mentiras no exemplo que você vinculou (simplesmente uma suposição e uma explicação do motivo mais comum para o sintoma relatado).
Ami F
22

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.

Nguyễn Tài Long
fonte
1
Acho que reconectei provavelmente 50 vezes no período de alguns dias e sempre obtive os mesmos 95% de uso para começar. Só uma vez vi 0%. Em todas essas tentativas eu estava obtendo cuda de erro de memória uma vez que estava chegando perto de 100%.
stason de
O que você quer dizer com sua atualização? Você ainda pode rodar coisas com 500Mb? Estou com o mesmo problema, estou recebendoRuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84
ivan_bilan
6

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.

Ajaychhimpa1
fonte
2
obrigado, mas sua sugestão não muda nada. Ainda estou obtendo 5% de GPU RAM.
stason
Isso não ajuda. Depois de encerrar e reconectar, a memória da GPU ainda está em 500 MB de ~ 12 GB.
ivan_bilan
4

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.

ivan_bilan
fonte
2

Encontre o pid do Python3 e mate o pid. Por favor, veja a imagem abaixoinsira a descrição da imagem aqui

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

Manivannan Murugavel
fonte
isso ajudará com o problema de memória? você não está matando todas as corridas de outras pessoas, então?
ivan_bilan
isso não ajuda, tenho o mesmo problema:GPU RAM Free: 564MB
ivan_bilan
2

Reinicie o kernel do Jupyter IPython:

!pkill -9 -f ipykernel_launcher
mkczyk
fonte
1
perto, mas sem charuto:GPU RAM Free: 564MB
ivan_bilan
como método mais simples para reiniciar o kernel, você pode apenas clicar em Runtime | Reinicie o tempo de execução ... ou o atalhoCMD/CTRL+M
Agile Bean
2

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.

Kregnach
fonte
2

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

insira a descrição da imagem aqui

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 :) insira a descrição da imagem aqui insira a descrição da imagem aqui

insira a descrição da imagem aqui

Jainil Patel
fonte
Eu posso confirmar isso. Eu tinha um conjunto de dados de 15 GB com principalmente imagens HD (minha unidade tem 30 GB em vez de 15 GB) e executei meu código para redimensionar o conjunto de dados de imagem para 224.224,3 e fui mudado para um tempo de execução de RAM alto. Então, quando comecei a treinar, o uso de RAM subiu para 31,88 gigs.
Anshuman Kumar
Mas gostaria de acrescentar que, depois de terminar esse trabalho, não consegui acessar outra GPU / TPU nas últimas 24 horas. É possível que eu estivesse na lista negra.
Anshuman Kumar
@AnshumanKumar, dê a carga alta no início, caso contrário, ao alterar a configuração você perderá o trabalho feito anteriormente que na RAM. Não usei a configuração alta por 24 horas, então não sei sobre a lista negra.
Jainil Patel
Sim, isso aconteceu comigo. No entanto, o trabalho foi feito.
Anshuman Kumar
1

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.

Ritwik G
fonte