Google Colaboratory：有关其 GPU 的误导性信息（某些用户只有 5% 的 RAM 可用）
Google Colaboratory: misleading information about its GPU (only 5% RAM available to some users)
更新：这个问题与 Google Colab 的 "Notebook settings: Hardware accelerator: GPU" 有关。本题是在添加"TPU"选项之前写的
阅读关于 Google Colaboratory 提供免费 Tesla K80 GPU 的多个激动人心的公告，我尝试 运行 fast.ai 上它的课，因为它永远不会完成 - 很快 运行内存不足。我开始调查原因。
最重要的是，“免费 Tesla K80”并非对所有人都 "free" - 对于某些人来说，只有一小部分 "free"。
我从加拿大西海岸连接到 Google Colab，但我只得到了 0.5GB 的 24GB GPU 内存。其他用户可以使用 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 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 notebook 上 运行 这段代码，你能确认你会得到类似的结果吗？
如果我的计算是正确的，有没有办法在免费盒子上获得更多的 GPU RAM？
更新：我不确定为什么我们中的一些人得到的是其他用户得到的 1/20。例如帮我调试这个的人来自印度，他搞定了一切！
注意：请不要发送任何关于如何杀死可能消耗部分 GPU 的潜在 stuck/runaway/parallel 笔记本的建议。无论你如何划分，如果你和我在同一条船上并且要 运行 调试代码，你会看到你仍然获得总共 5% 的 GPU RAM（截至此更新仍然） .
昨晚我 运行 你的代码片段并得到了你所得到的：
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 的原因。
我相信如果我们打开多个笔记本。只是关闭它实际上并没有停止这个过程。我还没有想出如何阻止它。但是我使用 top 找到 python3 的 PID，它是 运行 最长的并且使用了大部分内存，然后我将其杀死。现在一切恢复正常。
如果您执行的单元格只有
!kill -9 -1
在其中，这将导致所有运行时状态（包括内存、文件系统和 GPU）被清除并重新启动。等待 30-60 秒，然后按 top-right 处的 CONNECT 按钮重新连接。
找到 Python3 pid 并杀死 pid。请看下图
注意：只杀死 python3(pid=130) 而不是 jupyter python(122).
重启 Jupyter IPython 内核：
!pkill -9 -f ipykernel_launcher
因此，为了防止在该线程建议 !kill -9 -1 的上下文中出现另外一打无效的答案，让我们关闭该线程：
答案很简单：
在撰写本文时，Google 仅向我们中的一些人提供 5% 的 GPU，而向其他人提供 100%。期间.
2019 年 12 月更新：问题仍然存在 - 这个问题的投票仍在继续。
2019 年 3 月更新：一年后，Google 员工 @AmiF 评论了事情的状态，指出问题不存在，任何似乎有此问题的人都需要简单地重置他们的运行时来恢复内存。然而，投票仍在继续，对我来说这表明问题仍然存在，尽管@AmiF 提出了相反的建议。
dec-2018 更新：我有一个理论，当它的机器人检测到非标准行为时，Google 可能有某些帐户的黑名单，或者浏览器指纹。这可能完全是巧合，但很长一段时间以来，我在任何碰巧需要它的网站上都遇到了 Google Re-captcha 的问题，在我找到它之前，我必须经历几十个谜题允许通过，通常需要 10 分钟以上才能完成。这持续了好几个月。突然间，从这个月开始，我完全没有遇到任何难题，任何 google 重新验证码只需单击一下鼠标即可解决，就像将近一年前一样。
我为什么要讲这个故事？好吧，因为 同时我在 Colab 上获得了 100% 的 GPU RAM。这就是为什么我怀疑如果你在理论上的 Google 黑名单上，那么你就不会被信任免费获得大量资源。我想知道你们中是否有人发现有限的 GPU 访问与 Re-captcha 噩梦之间存在相同的相关性。正如我所说，这也可能完全是巧合。
我不确定这个黑名单是不是真的！很有可能，核心在用户之间共享。我运行也测试了，结果如下：
Gen RAM Free: 12.9 GB | Proc size: 142.8 MB
GPU RAM Free: 11441MB | Used: 0MB | Util 0% | Total 11441MB
我好像也满核了。但是我 运行 它几次，我得到了相同的结果。也许我会在白天重复检查几次，看看是否有任何变化。
给google colab一个繁重的任务，它会要求我们换成25gb的ram。
示例运行这段代码两次：
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)
然后点击获取更多内存:)
Google Colab 资源分配是动态的，基于用户过去的使用情况。假设如果一个用户最近使用资源较多，而新用户使用Colab的频率较低，那么在资源分配上会给予他相对更多的优先权。
因此，要充分利用 Colab，请关闭所有 Colab 选项卡和所有其他活动会话，重置您要使用的会话的运行时间。您肯定会获得更好的 GPU 分配。
更新：这个问题与 Google Colab 的 "Notebook settings: Hardware accelerator: GPU" 有关。本题是在添加"TPU"选项之前写的
阅读关于 Google Colaboratory 提供免费 Tesla K80 GPU 的多个激动人心的公告，我尝试 运行 fast.ai 上它的课，因为它永远不会完成 - 很快 运行内存不足。我开始调查原因。
最重要的是，“免费 Tesla K80”并非对所有人都 "free" - 对于某些人来说，只有一小部分 "free"。
我从加拿大西海岸连接到 Google Colab，但我只得到了 0.5GB 的 24GB GPU 内存。其他用户可以使用 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 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 notebook 上 运行 这段代码，你能确认你会得到类似的结果吗？
如果我的计算是正确的，有没有办法在免费盒子上获得更多的 GPU RAM？
更新：我不确定为什么我们中的一些人得到的是其他用户得到的 1/20。例如帮我调试这个的人来自印度，他搞定了一切！
注意：请不要发送任何关于如何杀死可能消耗部分 GPU 的潜在 stuck/runaway/parallel 笔记本的建议。无论你如何划分，如果你和我在同一条船上并且要 运行 调试代码，你会看到你仍然获得总共 5% 的 GPU RAM（截至此更新仍然） .
昨晚我 运行 你的代码片段并得到了你所得到的：
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 的原因。
我相信如果我们打开多个笔记本。只是关闭它实际上并没有停止这个过程。我还没有想出如何阻止它。但是我使用 top 找到 python3 的 PID，它是 运行 最长的并且使用了大部分内存，然后我将其杀死。现在一切恢复正常。
如果您执行的单元格只有
!kill -9 -1
在其中，这将导致所有运行时状态（包括内存、文件系统和 GPU）被清除并重新启动。等待 30-60 秒，然后按 top-right 处的 CONNECT 按钮重新连接。
找到 Python3 pid 并杀死 pid。请看下图
注意：只杀死 python3(pid=130) 而不是 jupyter python(122).
重启 Jupyter IPython 内核：
!pkill -9 -f ipykernel_launcher
因此，为了防止在该线程建议 !kill -9 -1 的上下文中出现另外一打无效的答案，让我们关闭该线程：
答案很简单：
在撰写本文时，Google 仅向我们中的一些人提供 5% 的 GPU，而向其他人提供 100%。期间.
2019 年 12 月更新：问题仍然存在 - 这个问题的投票仍在继续。
2019 年 3 月更新：一年后，Google 员工 @AmiF 评论了事情的状态，指出问题不存在，任何似乎有此问题的人都需要简单地重置他们的运行时来恢复内存。然而，投票仍在继续，对我来说这表明问题仍然存在，尽管@AmiF 提出了相反的建议。
dec-2018 更新：我有一个理论，当它的机器人检测到非标准行为时，Google 可能有某些帐户的黑名单，或者浏览器指纹。这可能完全是巧合，但很长一段时间以来，我在任何碰巧需要它的网站上都遇到了 Google Re-captcha 的问题，在我找到它之前，我必须经历几十个谜题允许通过，通常需要 10 分钟以上才能完成。这持续了好几个月。突然间，从这个月开始，我完全没有遇到任何难题，任何 google 重新验证码只需单击一下鼠标即可解决，就像将近一年前一样。
我为什么要讲这个故事？好吧，因为 同时我在 Colab 上获得了 100% 的 GPU RAM。这就是为什么我怀疑如果你在理论上的 Google 黑名单上，那么你就不会被信任免费获得大量资源。我想知道你们中是否有人发现有限的 GPU 访问与 Re-captcha 噩梦之间存在相同的相关性。正如我所说，这也可能完全是巧合。
我不确定这个黑名单是不是真的！很有可能，核心在用户之间共享。我运行也测试了，结果如下：
Gen RAM Free: 12.9 GB | Proc size: 142.8 MB
GPU RAM Free: 11441MB | Used: 0MB | Util 0% | Total 11441MB
我好像也满核了。但是我 运行 它几次，我得到了相同的结果。也许我会在白天重复检查几次，看看是否有任何变化。
给google colab一个繁重的任务，它会要求我们换成25gb的ram。
示例运行这段代码两次：
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)
然后点击获取更多内存:)
Google Colab 资源分配是动态的，基于用户过去的使用情况。假设如果一个用户最近使用资源较多，而新用户使用Colab的频率较低，那么在资源分配上会给予他相对更多的优先权。
因此，要充分利用 Colab，请关闭所有 Colab 选项卡和所有其他活动会话，重置您要使用的会话的运行时间。您肯定会获得更好的 GPU 分配。