Google Colaboratory：GPUに関する誤解を招く情報（わずか5％ RAM 一部のユーザーが利用可能）
更新：この質問はGoogle Colabの "Notebook settings：Hardware accelerator：GPU"に関連しています。この質問は "TPU"オプションが追加される前に書かれました。
無料のTesla K80 GPUを提供しているGoogle Colaboratoryに関する複数の興奮した発表を読んで、私は fast.ai それを完全に完了させないためのレッスン - メモリをすぐに使い果たすことを試みました。私はその理由を調べ始めました。
肝心なのは、 "free Tesla K80"はすべての人にとって "free"ではないということです - ほんの少しのスライスでは "free"です。
私はカナダのWest Coastから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
私のGPU RAMの可用性の計算に、GPUtilから借用した欠陥はありますか？
このコードをGoogle Colabノートブックで実行しても同様の結果が得られることを確認できますか？
私の計算が正しければ、フリーボックスでそのGPU RAMをもっと入手する方法はありますか？
更新：私達の何人かが他のユーザーが得るものの20分の1を得る理由はよくわかりません。例えば私がこれをデバッグするのを手伝ってくれた人はインドから来ていて、彼は全部を手に入れました！
note ：GPUの一部を消費している可能性のある、動かなくなったり/暴走したりしている可能性のある並列ノートブックを殺す方法についてこれ以上の提案を送信しないでください。どのようにスライスしても、私と同じボートに入っていてデバッグコードを実行するのであれば、まだ合計5％のGPU RAMが得られることがわかります（この更新時点でまだ）。
したがって、！kill -9 -1へのこのスレッドの提案のコンテキストで無効を示唆するさらに多くの回答を防ぐために、このスレッドを閉じましょう。
答えは簡単です。
この記事の執筆時点で、Googleは単に一部のGPUを5％しか与えていないのに対して、100％を他の人に与えています。期間
2019年3月の更新：1年後、Googleはついにこのスレッドに気づき、@ AmiFを送信して信用を失いました。ランタイムをリセットしてメモリを回復する方法がわからない人。 @AmiFはさらに、この問題はおそらくコードのバグであり、ユーザーは会社のポリシーとバグを区別できないことを示唆しています。
残念ながら、完全な開示は行われておらず、実際に何が起こっているのかを推測するしかありません。明らかに、営利目的の会社は彼らがいい人に留保しているので、ここで差別を避けることは不可能です。それは完全に理にかなっており、非常に論理的です。このリソースは無料で提供されるため、実際に文句を言うことはできませんが、ブラックリストに登録されているのはなぜかを尋ねているだけですが、他の点では同じセットアップ/ロケールから来ている人はそうではありません。
私の個人アカウントは2018年12月にブラックリストから削除されたので（以下の更新を参照）、真実を話すのを助けるためにブラックリストに残っている他のユーザーにのみ頼ることができます。私がこのアップデートを書いているとき、このスレッドはさらに別の賛成を得ました。
そうは言っても、Googleが少なくともブラックリストからの削除を求めている人たちのためにブラックリストを終わらせることを期待しよう。私たちのほとんどは、そのようなリストに掲載するような犯罪行為を行っておらず、未熟な機械学習の頭脳に捕まってしまい、自分が無罪であることを証明する機会を与えられていません。 @AmyFは、この問題を http://github.com/googlecolab/colabtools/issues で報告することを提案しました-問題を報告し、このような調査なしでチケットを閉じたままブラッシュアップした場合- ケース 、この回答のコメントに未解決の問題へのリンクを投稿してください。そうすれば、何らかの説明責任を求めることができます。
そして、もちろん、このスレッドに賛成票を投じる前に、colabのRuntimeメニューで "Reset all runtimes"を実行し、おそらく本当にまだGPU RAMを消費する未完成のノートブックの問題であり、ブラックリストポリシーの影響はまったくありません。
投票が停止すると、この差別ポリシーが廃止されたことがわかります。残念ながら、このアップデートの時点ではそうではありません。@ AmyFのコメントは非常に疑わしいものです。
2018年12月の更新：Googleが特定のアカウントのブラックリスト、またはおそらくロボットが非標準を検出したときにブラウザの指紋を持っているかもしれないという理論があります動作。それは完全に偶然かもしれませんが、かなり長い間、それを必要とするWebサイトでGoogle Re-captchaに問題があり、許可される前に何十ものパズルを通過する必要がありました。達成するのに10分以上かかります。これは何ヶ月も続きました。今月の時点で、私はまったくパズルを取得できず、ほぼ1年前のように、マウスを1回クリックするだけでGoogleの再キャプチャが解決されます。
そして、なぜ私はこの話をしているのですか？それは、同時にColabでGPU RAMの100％が与えられたからです。だからこそ、あなたが理論上のグーグルブラックリストに載っていれば、無料で多くのリソースを与えられるとは信じられないというのが私の疑いです。制限された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 RAM Freeが504 MBの場合でも、私はGPUを普通に使用できることがわかりました。これは、私が昨夜得たResourceExhaustedErrorの原因と考えました。
あるセルを実行すると
！kill -9 -1
その中には、ランタイムのすべての状態（メモリ、ファイルシステム、GPUを含む）がきれいに消去されて再起動される原因となるでしょう。 30〜60秒待ってから、右上にあるCONNECTボタンを押して再接続します。
グーグル側の誤解を招く説明。私はそれについても興奮しすぎたと思います。すべてを設定し、データをロードしたところ、Notebookに割り当てられているメモリが500MBしかないため、データを処理できなくなりました。
Python3 pidを見つけてpidを殺します。下の画像を見てください 
注意：python3（pid = 130）だけを殺して、jupyter python（122）を殺してはいけません。
Jupyter IPython Kernelを再起動します。
!pkill -9 -f ipykernel_launcher
このブラックリストに載っているかどうかはわかりません。それよりも、コアがユーザー間で共有されている可能性があります。私もテストを実行しました、そして、私の結果は以下です：
Gen RAM空き：12.9 GB | Procサイズ：142.8 MB GPU RAM空き容量：11441MB使用済み：0MB使用率0％|合計11441MB
フルコアになっているようです。しかし、私はそれを数回実行しました、そして私は同じ結果を得ました。たぶん私は何か変更があるかどうか見るために日中このチェックを数回繰り返すでしょう。
複数のノートブックを開いていると思います。閉じただけでは、実際にはプロセスが停止しません。私はそれを止める方法を考え出していません。しかし、最長で実行していてほとんどのメモリを使用していたpython3のPIDを見つけるためにtopを使用し、それを殺しました。現在はすべて正常に戻っています。