Google Colaboratory：有关其 GPU 的误导性信息（某些用户只有 5% 的 RAM 可用）答案

【问题标题】：Google Colaboratory: misleading information about its GPU (only 5% RAM available to some users)Google Colaboratory：有关其 GPU 的误导性信息（某些用户只有 5% 的 RAM 可用）
【发布时间】：2018-07-22 20:13:43
【问题描述】：

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

阅读了多个关于 Google Colaboratory 提供免费 Tesla K80 GPU 的激动人心的公告，我尝试在其上运行 fast.ai 课程，因为它永远不会完成 - 很快就会耗尽内存。我开始调查原因。

归根结底，“免费 Tesla K80”并不是对所有人都“免费”——对某些人来说，只有一小部分是“免费”的。

我从加拿大西海岸连接到 Google Colab，但我只获得了 0.5GB 的本来应该是 24GB 的 GPU RAM。其他用户可以使用 11GB 的 GPU RAM。

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

如果你不确定你得到了什么，这里是我拼凑的小调试功能（仅适用于笔记本的 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 notebook 中执行它会给我：

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？

更新：我不确定为什么我们中的一些人得到的只是其他用户的 1/20。例如帮助我调试的人来自印度，他得到了全部！

注意：请不要再发送任何关于如何杀死可能会消耗部分 GPU 的潜在卡住/失控/并行笔记本的建议。不管你如何分割它，如果你和我在同一条船上运行调试代码，你会发现你仍然可以获得总共 5% 的 GPU RAM（截至本次更新仍然如此）。

【问题讨论】：

有什么解决办法吗？为什么我在做 !cat /proc/meminfo 时会得到不同的结果
是的，同样的问题，大约 500 mb 的 GPU 内存...误导性描述 :(
试试 IBM 开源数据科学工具 (cognitiveclass.ai)，因为他们还有一个带有 jupyter notebooks 的免费 GPU。
我已将此问题回滚到其中实际上存在 question 的状态。如果您进行了更多研究并找到了答案，那么在答案框中是合适的位置。用解决方案更新问题是不正确的。
@ChrisHayes，我理解你的意图，但这是不对的，因为你的回滚删除了一大堆相关细节，这些细节现在已经消失了。如果您想提出更符合该社区规则的更好措辞，请这样做，否则请恢复您的回滚。谢谢你。 p.s.我已经发布了answer。

标签： python machine-learning gpu ram google-colaboratory

【解决方案1】：

Google Colab 资源分配是动态的，基于用户过去的使用情况。假设如果一个用户最近使用的资源比较多，而一个新用户使用 Colab 的频率较低，那么他在资源分配上会相对优先。

因此，要充分利用 Colab，请关闭所有 Colab 选项卡和所有其他活动会话，重置您要使用的会话的运行时间。你肯定会得到更好的 GPU 分配。

【讨论】：

【解决方案2】：

我不确定这个黑名单是否属实！很有可能，核心是在用户之间共享的。我也跑了测试，结果如下：

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

似乎我也得到了完整的核心。但是我运行了几次，我得到了相同的结果。也许我会在白天重复这个检查几次，看看是否有任何变化。

【讨论】：

【解决方案3】：

因此，为了防止在此线程建议的上下文中对 !kill -9 -1 的其他十几个答案暗示无效，让我们关闭此线程：

答案很简单：

在撰写本文时，Google 仅将 5% 的 GPU 分配给我们中的一些人，而将 100% 分配给其他人。期间。

2019 年 12 月更新：问题仍然存在 - 这个问题的支持仍在继续。

2019 年 3 月更新：一年后，一位 Google 员工 @AmiF 对情况发表了评论，称该问题不存在，任何似乎遇到此问题的人都需要简单地重置其运行时以恢复内存。然而，赞成票仍在继续，这对我来说表明问题仍然存在，尽管 @AmiF 的建议相反。

2018 年 12 月更新：我有一种理论认为，当其机器人检测到非标准行为时，Google 可能拥有某些帐户的黑名单，或者浏览器指纹。这可能完全是巧合，但很长一段时间以来，我在任何碰巧需要它的网站上都遇到了 Google Re-captcha 的问题，在我被允许通过之前，我必须经历几十个谜题，通常花了我 10 分钟以上的时间来完成。这持续了好几个月。突然之间，截至本月，我完全没有遇到任何难题，只需单击鼠标即可解决任何谷歌重新验证码，就像几乎一年前一样。

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

【讨论】：

您的声明“截至撰写本文时，Google 仅将 5% 的 GPU 分配给我们中的某些人，而将 100% 分配给其他人。期间。”不正确 - Colab 从来没有这样工作过。所有诊断出的用户看到的可用 GPU RAM 不足的情况都归结为另一个进程（由同一用户启动，可能在另一个笔记本中）使用 GPU 的其余 RAM。
未来的读者：如果您认为您看到这种或类似的 GPU RAM 不可用症状，“运行时”菜单中的“重置所有运行时”将为您提供一个全新的虚拟机，确保没有陈旧的进程仍在继续到 GPU 内存。如果您在使用该菜单选项后仍然立即看到此症状，请在github.com/googlecolab/colabtools/issues 提交错误
如果不清楚：我不是在描述我认为的实现是基于对系统作为用户的行为的观察。我正在描述我直接知道的实现是什么。我发布了希望看到不完全可用性的用户将其报告为问题（用户错误或系统错误），而不是阅读上面的错误陈述并假设事情按预期工作。
换句话说，你是在说你是谷歌员工，你是在暗示 colab 停止歧视用户，从现在开始，如果用户在第一次连接时没有获得 100% 的 GPU RAM并且不是由于同一用户之前的某些使用，您的系统中必须存在您要求报告的错误。你实际上会看到问题，而不是像我在this example 中展示的那样处理它，其中一个人对用户撒谎，给他一个错误的问题原因。 @AmiF。
不，GPU 从未被共享过，并且您链接的示例中没有任何谎言（只是对所报告症状的最常见原因的猜测和解释）。

【解决方案4】：

只需给 google colab 一个繁重的任务，它会要求我们更改为 25 GB 的内存。

示例运行此代码两次：

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)

然后点击获取更多内存 :)

【讨论】：

我可以确认这一点。我有一个 15 gig 的数据集，其中大部分是高清图片（我的驱动器有 30 gigs 而不是 15gigs），我运行代码将图像数据集的大小调整为 224,224,3，然后切换到高 RAM 运行时。然后当我开始训练时，RAM 使用量上升到 31.88gigs。
但是我想补充一点，一旦我完成了这项工作，在过去的 24 小时内我无法访问另一个 GPU/TPU。我有可能被列入黑名单。
@AnshumanKumar ，仅在开始时给予高负载，否则在更改配置时，您将丢失以前在 ram 中完成的工作。 24小时没用高配置所以不知道黑名单。
是的，这确实发生在我身上。然而工作已经完成了。

【解决方案5】：

昨晚我运行了你的 sn-p 并得到了你得到的结果：

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 RAM Free 为 504 MB，我也可以正常使用 GPU，我认为这是我昨晚得到的 ResourceExhaustedError 的原因。

【讨论】：

我想我在几天的时间里重新连接了大概 50 次，而且我总是得到相同的 95% 的使用率。只有一次我看到 0%。在所有这些尝试中，一旦接近 100%，我就会遇到 cuda 内存不足错误。
你的更新是什么意思？你还能运行 500Mb 的东西吗？我有同样的问题，我收到RuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84

【解决方案6】：

重启 Jupyter IPython 内核：

!pkill -9 -f ipykernel_launcher

【讨论】：

关闭，但没有雪茄：GPU RAM Free: 564MB
作为更简单的内核重启方法，您只需点击Runtime |重新启动运行时...或快捷方式CMD/CTRL+M

【解决方案7】：

找到 Python3 pid 并杀死该 pid。请看下图

注意：只杀死 python3(pid=130) 而不是 jupyter python(122)。

【讨论】：

这对内存问题有帮助吗？那你不是杀了所有其他人的跑步吗？
这没有帮助，遇到了同样的问题：GPU RAM Free: 564MB

【解决方案8】：

如果您执行的单元格只有
!kill -9 -1
在其中，这将导致您的所有运行时状态（包括内存、文件系统和 GPU）被清除并重新启动。等待 30-60 秒，然后按右上角的 CONNECT 按钮重新连接。

【讨论】：

谢谢，但您的建议不会改变任何事情。我仍然获得 5% 的 GPU RAM。
这没有帮助。杀死并重新连接后，GPU 内存在 ~12GB 中仍为 500Mb。

【解决方案9】：

我相信如果我们打开了多个笔记本。只是关闭它实际上并不会停止该过程。我还没想好怎么阻止它。但是我使用 top 来查找运行时间最长并使用大部分内存的 python3 的 PID，然后我将其杀死。现在一切都恢复正常了。

【讨论】：