Google Colaboratory: thông tin sai lệch về GPU của nó (chỉ có 5% RAM cho một số người dùng)


110

cập nhật: câu hỏi này liên quan đến "Cài đặt máy tính xách tay: Trình tăng tốc phần cứng: GPU" của Google Colab. Câu hỏi này được viết trước khi tùy chọn "TPU" được thêm vào.

Đọc nhiều thông báo hào hứng về việc Google Colaboratory cung cấp GPU Tesla K80 miễn phí, tôi đã cố gắng chạy fast.ai bài học về nó để nó không bao giờ hoàn thành - nhanh chóng hết bộ nhớ. Tôi bắt đầu điều tra lý do tại sao.

Điểm mấu chốt là “Tesla K80 miễn phí” không phải là “miễn phí” cho tất cả - đối với một số người, chỉ một phần nhỏ của nó là “miễn phí”.

Tôi kết nối với Google Colab từ Bờ Tây Canada và tôi chỉ nhận được 0,5GB dung lượng được cho là RAM GPU 24GB. Những người dùng khác có quyền truy cập vào 11GB RAM GPU.

Rõ ràng là 0,5GB RAM GPU là không đủ cho hầu hết các công việc ML / DL.

Nếu bạn không chắc mình nhận được gì, đây là chức năng gỡ lỗi nhỏ mà tôi đã tổng hợp lại (chỉ hoạt động với cài đặt GPU của máy tính xách tay):

# 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()

Thực thi nó trong sổ ghi chép jupyter trước khi chạy bất kỳ mã nào khác cho tôi:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util  95% | Total 11439MB

Những người dùng may mắn có quyền truy cập vào thẻ đầy đủ sẽ thấy:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 11439MB | Used: 0MB | Util  0% | Total 11439MB

Bạn có thấy lỗ hổng nào trong tính toán của tôi về tính khả dụng của RAM GPU, mượn từ GPUtil không?

Bạn có thể xác nhận rằng bạn nhận được kết quả tương tự nếu bạn chạy mã này trên sổ ghi chép Google Colab không?

Nếu tính toán của tôi là đúng, có cách nào để lấy thêm RAM GPU đó trên hộp miễn phí không?

cập nhật: Tôi không chắc tại sao một số người trong chúng ta nhận được 1/5 những gì người dùng khác nhận được. Ví dụ: người đã giúp tôi gỡ lỗi này đến từ Ấn Độ và anh ấy đã nắm được toàn bộ!

lưu ý : vui lòng không gửi thêm bất kỳ đề xuất nào về cách loại bỏ các máy tính xách tay có khả năng bị kẹt / chạy / chạy song song có thể đang ngốn các bộ phận của GPU. Cho dù bạn cắt nó như thế nào, nếu bạn ở cùng thuyền với tôi và đang chạy mã gỡ lỗi, bạn sẽ thấy rằng bạn vẫn nhận được tổng cộng 5% RAM GPU (tính đến bản cập nhật này vẫn còn).


Bất kỳ giải pháp cho điều này? tại sao tôi nhận được kết quả khác nhau khi thực hiện cat / proc / meminfo!
MiloMinderbinder

Đúng vậy, cùng một vấn đề, chỉ khoảng 500 mb ram GPU ... mô tả gây hiểu lầm :(
Naveen

2
Hãy thử các công cụ khoa học dữ liệu mã nguồn mở của IBM (inheritclass.ai) vì chúng cũng có GPU miễn phí với máy tính xách tay jupyter.
AQ

Tôi đã lùi câu hỏi này về trạng thái thực sự có một câu hỏi trong đó. Nếu bạn đã nghiên cứu thêm và tìm thấy câu trả lời, thì vị trí thích hợp cho câu trả lời đó là trong hộp câu trả lời. Cập nhật câu hỏi với một giải pháp là không chính xác.
Chris Hayes

@ChrisHayes, tôi hiểu ý định của bạn, nhưng điều này là không đúng, vì quá trình khôi phục của bạn đã xóa một loạt các chi tiết liên quan giờ đã biến mất. Nếu bạn muốn đề xuất một từ ngữ tốt hơn phù hợp hơn với các quy tắc của cộng đồng này, vui lòng làm như vậy, nhưng nếu không, vui lòng hoàn nguyên việc khôi phục của bạn. Cảm ơn bạn. ps Tôi đã đăng câu trả lời .
stason

Câu trả lời:


41

Vì vậy, để ngăn chặn hàng tá câu trả lời khác đề xuất không hợp lệ trong ngữ cảnh đề xuất chuỗi này thành! Kill -9 -1, hãy đóng chuỗi này:

Đáp án đơn giản:

Khi viết bài này, Google đơn giản chỉ cung cấp 5% GPU cho một số người trong chúng ta, trong khi 100% cho những người khác. Giai đoạn = Stage.

cập nhật tháng 12 năm 2019: Vấn đề vẫn tồn tại - số phiếu ủng hộ của câu hỏi này vẫn tiếp tục.

Cập nhật Mar-2019: Một năm sau, một nhân viên của Google @AmiF đã nhận xét về tình trạng của sự việc, nói rằng sự cố không tồn tại và bất kỳ ai có vẻ gặp sự cố này cần chỉ cần đặt lại thời gian chạy của họ để khôi phục bộ nhớ. Tuy nhiên, số phiếu ủng hộ vẫn tiếp tục, điều này đối với tôi cho thấy rằng vấn đề vẫn tồn tại, bất chấp đề xuất của @ AmiF ngược lại.

cập nhật tháng 12 năm 2018: Tôi có giả thuyết rằng Google có thể có một danh sách đen các tài khoản nhất định hoặc có thể là dấu vân tay của trình duyệt, khi các rô bốt của nó phát hiện ra hành vi không chuẩn. Đó có thể là một sự trùng hợp hoàn toàn, nhưng trong một thời gian khá dài, tôi đã gặp sự cố với Google Re-captcha trên bất kỳ trang web nào yêu cầu nó, nơi tôi phải trải qua hàng tá câu đố trước khi được cho phép, thường mất hơn 10 phút để hoàn thành. Điều này kéo dài trong nhiều tháng. Đột nhiên, kể từ tháng này, tôi không nhận được câu đố nào cả và bất kỳ hình ảnh xác thực lại nào của google đều được giải quyết chỉ với một cú nhấp chuột, như cách đây gần một năm.

Và tại sao tôi lại kể câu chuyện này? Chà, vì đồng thời tôi cũng được cấp 100% RAM GPU trên Colab . Đó là lý do tại sao tôi nghi ngờ rằng nếu bạn nằm trong danh sách đen của Google trên lý thuyết thì bạn không được tin tưởng để được cung cấp nhiều tài nguyên miễn phí. Tôi tự hỏi liệu có ai trong số các bạn tìm thấy mối tương quan tương tự giữa quyền truy cập GPU hạn chế và cơn ác mộng Re-captcha không. Như tôi đã nói, đó cũng có thể là một sự trùng hợp hoàn toàn.


4
Tuyên bố của bạn về "Khi viết bài này, Google chỉ cung cấp 5% GPU cho một số người trong chúng tôi, trong khi 100% cho những người khác. Khoảng thời gian." là không chính xác - Colab chưa bao giờ làm việc theo cách này. Tất cả các trường hợp được chẩn đoán là người dùng thấy ít hơn lượng RAM GPU bổ sung đầy đủ có sẵn cho họ đã chuyển sang một quá trình khác (do cùng một người dùng bắt đầu, có thể trong một máy tính xách tay khác) bằng cách sử dụng phần còn lại của RAM GPU.
Ami F

11
Trình đọc trong tương lai: nếu bạn cho rằng mình đang thấy hiện tượng này hoặc các triệu chứng tương tự của việc RAM GPU không khả dụng, "Đặt lại tất cả thời gian chạy" trong menu Thời gian chạy sẽ giúp bạn có một máy ảo mới đảm bảo không có quy trình cũ nào đang giữ RAM GPU. Nếu bạn vẫn thấy hiện tượng này ngay lập tức sau khi sử dụng tùy chọn menu đó, vui lòng gửi lỗi tại github.com/googlecolab/colabtools/issues
Ami F

Thực tế của bạn rõ ràng khác với thực tế của nhiều người khác, những người tiếp tục bình chọn bài đăng này một năm sau đó sau khi nó được tạo. Rất có thể một số người dùng thực sự gặp phải những gì bạn mô tả, nhưng đây không phải là trường hợp cho tất cả. Vì vậy, tôi không chắc tuyên bố của bạn giúp ích như thế nào ở đây. Bên cạnh đó, khi ai đó hỏi câu hỏi chính xác này trong repo mà bạn đề xuất, anh ấy đã nhận được câu trả lời từ BS và vé của anh ấy đã bị đóng: github.com/googlecolab/colabtools/issues/52
stason 23/03/19

2
Trong trường hợp nó không rõ ràng: Tôi không mô tả những gì tôi tin rằng việc triển khai dựa trên việc quan sát hành vi của hệ thống với tư cách là người dùng. Tôi đang mô tả những gì tôi trực tiếp biết về việc triển khai. Tôi đã đăng bài với hy vọng rằng những người dùng thấy ít hơn đầy đủ tính khả dụng sẽ báo cáo đó là sự cố (lỗi người dùng hoặc lỗi hệ thống) thay vì đọc các tuyên bố không chính xác ở trên và cho rằng mọi thứ đang hoạt động như dự định.
Ami F

1
Không, GPU chưa bao giờ được chia sẻ và không có lời nói dối nào trong ví dụ bạn đã liên kết (chỉ đơn giản là phỏng đoán và giải thích lý do phổ biến nhất cho triệu chứng được báo cáo).
Ami F

22

Đêm qua tôi đã chạy đoạn mã của bạn và nhận được chính xác những gì bạn nhận được:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util  95% | Total 11439MB

nhưng hôm nay:

Gen RAM Free: 12.2 GB  I Proc size: 131.5 MB
GPU RAM Free: 11439MB | Used: 0MB | Util   0% | Total 11439MB

Tôi nghĩ lý do có thể xảy ra nhất là GPU được chia sẻ giữa các máy ảo, vì vậy mỗi khi bạn khởi động lại thời gian chạy, bạn có cơ hội chuyển đổi GPU và cũng có khả năng bạn chuyển sang GPU đang được người dùng khác sử dụng.

CẬP NHẬT: Hóa ra là tôi có thể sử dụng GPU bình thường ngay cả khi GPU trống RAM là 504 MB, điều mà tôi nghĩ là nguyên nhân gây ra lỗi ResourceExhaustedError mà tôi đã nhận vào đêm qua.


1
Tôi nghĩ rằng tôi có thể đã kết nối lại 50 lần trong khoảng thời gian vài ngày và tôi luôn nhận được mức sử dụng 95% như ban đầu. Chỉ một lần tôi thấy 0%. Trong tất cả những lần thử đó, tôi đã nhận được lỗi cuda out memory khi nó gần đến 100%.
stason

Ý bạn là gì với bản cập nhật của bạn? Bạn vẫn có thể chạy công cụ với 500Mb? Tôi có cùng một vấn đề, tôi đang nhận đượcRuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84
ivan_bilan

6

Nếu bạn thực thi một ô chỉ có
! Kill -9 -1
trong đó, điều đó sẽ khiến tất cả trạng thái thời gian chạy của bạn (bao gồm bộ nhớ, hệ thống tệp và GPU) bị xóa sạch và khởi động lại. Chờ 30-60 giây và nhấn nút CONNECT ở trên cùng bên phải để kết nối lại.


2
cảm ơn bạn, nhưng đề xuất của bạn không thay đổi bất cứ điều gì. Tôi vẫn nhận được 5% RAM GPU.
stason

Điều này không giúp ích gì. Sau khi tắt và kết nối lại, bộ nhớ GPU vẫn ở mức 500Mb trong tổng số ~ 12GB.
ivan_bilan

4

Mô tả gây hiểu lầm trên một phần của Google. Tôi cũng rất hào hứng với nó, tôi đoán vậy. Thiết lập mọi thứ, tải dữ liệu và bây giờ tôi không thể làm gì với nó do chỉ có bộ nhớ 500Mb được cấp cho Notebook của tôi.


3

cứ giao việc nặng cho google colab, nó sẽ yêu cầu chúng ta đổi thành 25 gb ram.

nhập mô tả hình ảnh ở đây

ví dụ chạy mã này hai lần:

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)

sau đó bấm vào để có thêm ram :) nhập mô tả hình ảnh ở đây nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây


Tôi có thể xác nhận điều này. Tôi có một tập dữ liệu 15 gig chủ yếu là hình ảnh HD (ổ đĩa của tôi có 30 gig thay vì 15gigs) và tôi đã chạy mã của mình để thay đổi kích thước tập dữ liệu hình ảnh thành 224,224,3 và tôi đã được chuyển sang thời gian chạy RAM cao. Sau đó, khi tôi bắt đầu đào tạo việc sử dụng RAM đã lên đến 31,88gigs.
Anshuman Kumar

Nhưng tôi muốn nói thêm rằng sau khi hoàn thành công việc đó, tôi đã không thể truy cập GPU / TPU khác trong 24 giờ qua. Có thể tôi đã bị đưa vào danh sách đen.
Anshuman Kumar

@AnshumanKumar, chỉ cung cấp tải cao khi bắt đầu, nếu không khi thay đổi cấu hình, bạn sẽ mất công việc đã làm trước đó trong ram. Tôi đã không sử dụng cấu hình cao trong 24 giờ nên tôi không biết về danh sách đen.
Jainil Patel

Vâng, điều đó đã xảy ra với tôi. Tuy nhiên, công việc đã được thực hiện.
Anshuman Kumar

2

Tìm pid Python3 và giết pid. Vui lòng xem hình ảnh bên dướinhập mô tả hình ảnh ở đây

Lưu ý: chỉ giết python3 (pid = 130) chứ không phải python jupyter (122).


Điều này sẽ giúp giải quyết vấn đề bộ nhớ? không phải bạn đang giết tất cả các cuộc chạy của người khác sau đó?
ivan_bilan

điều này không giúp đỡ, có cùng một vấn đề:GPU RAM Free: 564MB
ivan_bilan

2

Khởi động lại nhân IPython của Jupyter:

!pkill -9 -f ipykernel_launcher

1
gần, nhưng không có điếu xì gà:GPU RAM Free: 564MB
ivan_bilan

như một phương pháp đơn giản hơn để khởi động lại hạt nhân, bạn chỉ cần nhấp vào Runtime | Thời gian chạy khởi động lại ... hoặc các phím tắtCMD/CTRL+M
Agile Bean

2

Tôi không chắc liệu danh sách đen này có đúng không! Rất có thể, các lõi được chia sẻ giữa những người dùng. Tôi cũng đã chạy thử nghiệm và kết quả của tôi như sau:

Gen RAM miễn phí: 12,9 GB | Kích thước Proc: 142,8 MB RAM GPU Miễn phí: 11441MB | Đã sử dụng: 0MB | Util 0% | Tổng 11441MB

Có vẻ như tôi cũng nhận được đầy đủ lõi. Tuy nhiên, tôi đã chạy nó một vài lần và tôi nhận được kết quả tương tự. Có lẽ tôi sẽ lặp lại việc kiểm tra này một vài lần trong ngày để xem có thay đổi gì không.


1

Tôi tin rằng nếu chúng ta mở nhiều sổ ghi chép. Chỉ đóng nó không thực sự dừng quá trình. Tôi chưa tìm ra cách để ngăn chặn nó. Nhưng tôi đã sử dụng top để tìm PID của python3 đang chạy lâu nhất và sử dụng gần hết bộ nhớ và tôi đã giết nó. Mọi thứ trở lại bình thường bây giờ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.