Google合作实验室：有关其GPU的误导性信息（某些用户只能使用5％的RAM）

更新：此问题与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笔记本中执行该命令即可：

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（截至本次更新）。

因此，为防止在此线程对！kill -9 -1的建议的上下文中再有十几个答案提示无效，让我们关闭此线程：

答案很简单：

在撰写本文时，Google仅向我们中的某些人提供了5％的GPU，而其他人仅提供了100％的GPU。期。

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

2019年3月更新：一年后，一位Google员工@AmiF对事情的状态进行了评论，指出该问题不存在，任何似乎有此问题的人都只需重置其运行时即可恢复内存。然而，支持仍在继续，对我来说，这表明问题仍然存在，尽管@AmiF提出了相反的建议。

2018年12月更新：我有一种理论认为，当Google的机器人检测到非标准行为时，它可能会将某些帐户或浏览器指纹列入黑名单。这可能完全是巧合，但是一段时间以来，我碰巧在任何需要它的网站上都遇到了Google Re-captcha的问题，在该情况下，我通常必须经过数十个难题才能被允许通过花了我10分钟以上才能完成。这持续了好几个月。到本月突然，我一点都没有困惑，任何Google re-captcha都只需单击一下鼠标就可以解决，就像过去大约一年前一样。

为什么我要讲这个故事？好吧，因为同时我在Colab上获得了100％的GPU RAM。这就是为什么我怀疑的是，如果您处于理论上的Google黑名单中，那么您将不会获得免费提供大量资源的信任。我想知道你们中是否有人在有限的GPU访问和Re-captcha噩梦之间找到相同的关联。正如我所说，这也可能完全是巧合。

昨晚我跑了你的代码片段，并得到你所得到的：

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的原因。

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

Google的误导性描述。我想我也为此感到兴奋。设置好所有内容，加载数据，现在由于对笔记本计算机仅分配了500Mb的内存，我无法执行任何操作。

只是给Google colab繁重的工作，它将要求我们将RAM更改为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)

然后点击获得更多的RAM :)

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

注意：仅杀死python3（pid = 130）而不杀死jupyter python（122）。

重新启动Jupyter IPython内核：

!pkill -9 -f ipykernel_launcher

我不确定此黑名单是否正确！内核在用户之间共享是很有可能的。我也进行了测试，结果如下：

Gen RAM Free：12.9 GB | Proc大小：142.8 MB GPU RAM可用：11441MB | 已用：0MB | 利用率0％| 总计11441MB

看来即时通讯也变得完整。但是我跑了几次，结果还是一样。也许我白天会重复几次此检查，看是否有任何变化。

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