代码之家  ›  专栏  ›  技术社区  ›  stason

谷歌实验室(Google Colaboratory):关于其GPU的误导性信息(一些用户只能获得5%的RAM)

  •  127
  • stason  · 技术社区  · 6 年前

    更新:这个问题与Google Colab的“笔记本设置:硬件加速器:GPU”有关。这个问题是在添加“TPU”选项之前写的。

    读到关于谷歌实验室(Google Colaboratory)提供免费特斯拉K80 GPU的多条激动人心的公告,我试图 fast.ai 关于它的教训是它永远不会完成-内存很快耗尽。我开始调查原因。

    底线是,免费的特斯拉K80并非对所有人都是“免费的”——对一些人来说,只有一小部分是“免费的”。

    我从加拿大西海岸连接到Google Colab,我只得到了0.5GB的24GB GPU RAM。其他用户可以访问11GB的GPU RAM。

    显然,0.5GB GPU RAM对于大多数ML/DL工作来说是不够的。

    如果你不确定你得到了什么,这里是我收集的一个小调试功能(只适用于笔记本的GPU设置):

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

    在运行任何其他代码之前,在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借用的GPU RAM可用性计算中,您是否看到任何缺陷?

    如果在Google Colab笔记本上运行此代码,是否可以确认得到类似的结果?

    如果我的计算是正确的,有没有办法在空闲盒上获得更多的GPU RAM?

    更新:我不知道为什么我们中的一些人得到的是其他用户的20分之一。e、 g.帮助我调试这个的人来自印度,他得到了全部信息!

    笔记 :请不要再发送任何关于如何杀死可能会消耗GPU部分的卡住/失控/并行笔记本电脑的建议。无论您如何分割它,如果您与我处于同一条船上,并且要运行调试代码,那么您将看到您仍然获得总计5%的GPU RAM(截至此次更新)。

    9 回复  |  直到 6 年前
        1
  •  52
  •   stason    5 年前

    所以为了防止再出现十几条答案提示无效的情况,在这条线索的上下文中给建议!kill-9-1,让我们关闭此线程:

    答案很简单:

    在撰写本文时,谷歌只给了我们中的一些人5%的GPU,而给了其他人100%的GPU。时期

    2019年12月更新:问题仍然存在-该问题的投票仍在继续。

    2019年3月更新:一年后,一名谷歌员工@AmiF对现状发表了评论,称问题不存在,任何似乎有此问题的人都需要简单地重置运行时以恢复内存。然而,UPVOUTS仍在继续,对我来说,这表明问题仍然存在,尽管@AmiF提出了相反的建议。

    2018年12月更新:我有一个理论,当谷歌的机器人检测到非标准行为时,谷歌可能会有特定账户的黑名单,或者浏览器指纹。这可能完全是巧合,但在相当长的一段时间内,我在任何碰巧需要重新验证码的网站上都遇到了谷歌重新验证码的问题,在我被允许通过之前,我必须通过几十个谜题,通常需要10多分钟才能完成。这持续了好几个月。突然,从这个月起,我一点谜题都没有了,任何谷歌重新验证码都只需点击鼠标即可解决,就像一年前一样。

    我为什么要讲这个故事?嗯,因为 同时,我在Colab上获得了100%的GPU RAM . 这就是为什么我怀疑,如果你是理论上的谷歌黑名单上的人,那么你就不会被信任免费获得大量资源。我想知道你们中是否有人发现有限的GPU访问和重新验证码噩梦之间存在同样的相关性。正如我所说,这也可能完全是巧合。

        2
  •  24
  •   Nguyễn Tài Long    6 年前

    昨晚我运行了你的代码片段,得到了你想要的:

    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在VM之间共享,因此每次重新启动运行时,都有机会切换GPU,也有可能切换到其他用户正在使用的GPU。

    更新日期: 事实证明,即使GPU内存空闲为504 MB,我也可以正常使用GPU,我认为这是我昨晚遇到ResourceExhaustedError的原因。

        3
  •  7
  •   Ajaychhimpa1    6 年前

    如果执行一个单元格
    !杀死-9-1
    在它中,这将导致清除并重新启动所有运行时状态(包括内存、文件系统和GPU)。等待30-60秒,然后按右上角的CONNECT(连接)按钮重新连接。

        4
  •  3
  •   mkczyk    6 年前

    重新启动Jupyter IPython内核:

    !pkill -9 -f ipykernel_launcher
    
        5
  •  2
  •   Manivannan Murugavel    6 年前

    找到Python3 pid并杀死pid。请参见下图 enter image description here

    注意:只杀死python3(pid=130),不杀死jupyter python(122)。

        6
  •  2
  •   Jainil Patel    5 年前

    只需给google colab一个繁重的任务,它就会要求我们更改为25 gb的ram。

    enter image description here

    示例运行此代码两次:

    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)
    

    然后单击获取更多ram:) enter image description here enter image description here

    enter image description here

        7
  •  2
  •   desertnaut K.A    4 年前

    我不确定这个黑名单是不是真的!核心很可能在用户之间共享。我还进行了测试,结果如下:

    Gen RAM Free: 12.9 GB  | Proc size: 142.8 MB
    GPU RAM Free: 11441MB | Used: 0MB | Util   0% | Total 11441MB
    

    看来我也得到了充分的核心。然而,我运行了几次,得到了相同的结果。也许我会在白天重复检查几次,看看是否有任何变化。

        8
  •  1
  •   Ritwik G    6 年前

    我相信如果我们打开多个笔记本电脑。仅仅关闭它并不能真正停止这个过程。我还不知道怎么阻止它。但我用top找到了运行时间最长、占用内存最多的python3的PID,并将其删除。现在一切都恢复正常了。

        9
  •  0
  •   Ankit Veer Singh    4 年前

    Google Colab资源分配是动态的,基于用户过去的使用情况。假设一个用户最近使用了更多的资源,而一个新用户使用Colab的频率较低,那么他在资源分配方面会得到相对更多的优先权。

    因此,要最大限度地利用Colab,请关闭所有Colab选项卡和所有其他活动会话,重置要使用的会话的运行时。你肯定会得到更好的GPU分配。