Google Colaboratory：GPUに関する誤解を招く情報（一部のユーザーは5％のRAMしか利用できません）

更新：この質問は、Google Colabの「ノートブック設定：ハードウェアアクセラレータ：GPU」に関連しています。この質問は、「TPU」オプションが追加される前に書かれました。

Google Colaboratoryが無料のTesla K80 GPUを提供していることについての興奮する発表を何度も読んで、私はそれについてfast.aiのレッスンを実行しようとしました。その理由を調べ始めました。

結論としては、「無料のTesla K80」は「無料」ではないということです。一部の場合、「無料」である場合もあります。

カナダ西海岸のGoogle Colabに接続しましたが、24GB GPU RAMであるはずの0.5GBしか取得できません。他のユーザーは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分の1を獲得する理由がわかりません。たとえば、これをデバッグするのを手伝ってくれた人はインド出身で、彼はすべてを手に入れました！

注：GPUの一部を消費している可能性があるスタック/ランアウェイ/パラレルノートブックを強制終了する方法については、これ以上の提案を送信しないでください。どのようにスライスしても、私と同じボートにいてデバッグコードを実行すると、合計5％のGPU RAMがまだ得られることがわかります（この更新の時点では）。

したがって、このスレッドの提案のコンテキストで無効を示唆する別のダースの回答を防ぐために、！kill -9 -1の提案では、このスレッドを閉じましょう。

答えは簡単です：

これを書いている時点では、GoogleはGPUの5％しか私たちに与えていないのに対し、他の人には100％を与えています。限目。

2019年12月の更新：問題はまだ存在しています-この質問の賛成票はまだ続きます。

2019年3月の更新：1年後、Googleの従業員@AmiFが問題は存在しないと述べ、この問題が発生していると思われるユーザーは、ランタイムをリセットしてメモリを回復する必要があると述べています。それでも、賛成票は続きます。これは、@ AmiFの反対の提案にもかかわらず、問題がまだ存在していることを私に伝えています。

2018年12月の更新：ロボットが非標準の動作を検出したときに、Googleが特定のアカウントのブラックリスト、またはブラウザーの指紋を持っている可能性があるという理論があります。まったくの偶然かもしれませんが、かなり長い間、偶然それを必要とするWebサイトでGoogle Re-captchaに問題がありました。完了するまでに10分以上かかります。これは何ヶ月も続いた。今月は突然、まったくパズルがなくなり、ほぼ1年前のように、マウスを1回クリックするだけでgoogleのキャプチャが解決されます。

そして、なぜ私はこの話をしているのですか？まあ、それと同時にColabでGPU RAMの100％が与えられたからです。だから、私の疑いは、理論上のGoogleブラックリストに載っているなら、無料で多くのリソースを与えられるとは信じられないということです。制限されたGPUアクセスと再キャプチャの悪夢の間で同じ相関関係を見つけた方はいるのでしょうか。私が言ったように、それは完全に偶然かもしれません。

昨夜私はあなたのスニペットを実行し、あなたが得たものを正確に取得しました：

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の空き容量が504 MBであっても、GPUを正常に使用できることがわかりました。これは、昨夜のResourceExhaustedErrorの原因であると考えました。

！kill -9 -1が含ま
れているセルを実行すると、ランタイムのすべての状態（メモリ、ファイルシステム、GPUを含む）が完全に消去され、再起動されます。30〜60秒待ってから、右上の[接続]ボタンを押して再接続します。

Googleの誤解を招く説明。あまりにも興奮しすぎたと思います。すべてをセットアップし、データをロードすると、ノートブックに割り当てられているメモリが500Mbしかないため、データを使用して何もできなくなります。

google colabに重いタスクを与えるだけで、25 GBのRAMに変更するよう求められます。

このコードを2回実行する例：

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をkillします。下の画像をご覧ください

注：python3（pid = 130）のみを殺して、jupyter python（122）を殺さないでください。

Jupyter IPythonカーネルを再起動します。

!pkill -9 -f ipykernel_launcher

このブラックリストが真実かどうかはわかりません！コアがユーザー間で共有されることはむしろ可能です。私もテストを実行し、私の結果は次のとおりです。

Gen RAMフリー：12.9 GB | プロセッサーサイズ：142.8 MB GPU RAMフリー：11441MB | 使用済み：0MB | 使用率0％| 合計11441MB

フルコアも取得しているようです。しかし、私はそれを数回実行し、同じ結果を得ました。たぶん、日中にこのチェックを数回繰り返して、変更がないか確認します。

複数のノートブックを開いていると思います。それを閉じるだけでは、実際にはプロセスは停止しません。私はそれを止める方法を理解していません。しかし、私はtopを使用して、最も長く実行されており、ほとんどのメモリを使用しているpython3のPIDを見つけ、それを強制終了しました。すべてが正常に戻りました。