Detectron: Kehabisan memori pada kartu 4GB

Dibuat pada 24 Jan 2018  ·  24Komentar  ·  Sumber: facebookresearch/Detectron

Saya mencoba menjalankan Faster-RCNN pada Nvidia GTX 1050Ti, tetapi saya kehabisan memori. Nvidia-smi mengatakan bahwa sekitar 170MB sudah digunakan, tetapi apakah Faster-RCNN benar-benar menggunakan 3,8GB VRAM untuk memproses gambar?

Saya mencoba Mask-RCNN juga (model dalam tutorial memulai) dan mendapatkan sekitar 4 gambar (5 jika saya menutup browser saya) sebelum crash.

Apakah ini bug atau hanya membutuhkan lebih dari 4GB memori?

INFO infer_simple.py: 111: Processing demo/18124840932_e42b3e377c_k.jpg -> /home/px046/prog/Detectron/output/18124840932_e42b3e377c_k.jpg.pdf
terminate called after throwing an instance of 'caffe2::EnforceNotMet'
  what():  [enforce fail at blob.h:94] IsType<T>(). wrong type for the Blob instance. Blob contains nullptr (uninitialized) while caller expects caffe2::Tensor<caffe2::CUDAContext> .
Offending Blob name: gpu_0/conv_rpn_w.
Error from operator: 
input: "gpu_0/res4_5_sum" input: "gpu_0/conv_rpn_w" input: "gpu_0/conv_rpn_b" output: "gpu_0/conv_rpn" name: "" type: "Conv" arg { name: "kernel" i: 3 } arg { name: "exhaustive_search" i: 0 } arg { name: "pad" i: 1 } arg { name: "order" s: "NCHW" } arg { name: "stride" i: 1 } device_option { device_type: 1 cuda_gpu_id: 0 } engine: "CUDNN"
*** Aborted at 1516787658 (unix time) try "date -d @1516787658" if you are using GNU date ***
PC: @     0x7f08de455428 gsignal
*** SIGABRT (@0x3e800000932) received by PID 2354 (TID 0x7f087cda9700) from PID 2354; stack trace: ***
    @     0x7f08de4554b0 (unknown)
    @     0x7f08de455428 gsignal
    @     0x7f08de45702a abort
    @     0x7f08d187db39 __gnu_cxx::__verbose_terminate_handler()
    @     0x7f08d187c1fb __cxxabiv1::__terminate()
    @     0x7f08d187c234 std::terminate()
    @     0x7f08d1897c8a execute_native_thread_routine_compat
    @     0x7f08def016ba start_thread
    @     0x7f08de52741d clone
    @                0x0 (unknown)
Aborted (core dumped)

enhancement

Komentar yang paling membantu

Satu catatan tambahan: implementasi saat ini menggunakan pengoptimalan memori selama pelatihan, tetapi tidak selama inferensi. Dalam hal inferensi, dimungkinkan untuk secara substansial mengurangi penggunaan memori karena aktivasi perantara tidak diperlukan setelah digunakan. Kami akan mempertimbangkan untuk menambahkan pengoptimalan memori khusus inferensi di masa mendatang.

Semua 24 komentar

Hai @Omegastick , persyaratan memori dari algoritma Faster R-CNN bervariasi tergantung pada sejumlah faktor termasuk arsitektur jaringan tulang punggung dan skala gambar uji yang digunakan.

Misalnya, Anda dapat menjalankan Faster R-CNN dengan konfigurasi default ResNet-50 menggunakan:

python2 tools/infer_simple.py \
  --cfg configs/12_2017_baselines/e2e_faster_rcnn_R-50-FPN_2x.yaml \
  --output-dir /tmp/detectron-visualizations \ 
  --image-ext jpg \
  --wts https://s3-us-west-2.amazonaws.com/detectron/35857389/12_2017_baselines/e2e_faster_rcnn_R-50-FPN_2x.yaml.01_37_22.KSeq0b5q/output/train/coco_2014_train%3Acoco_2014_valminusminival/generalized_rcnn/model_final.pkl \
  demo

yang seharusnya tidak memerlukan lebih dari 3GB untuk dijalankan pada gambar demo.

Satu catatan tambahan: implementasi saat ini menggunakan pengoptimalan memori selama pelatihan, tetapi tidak selama inferensi. Dalam hal inferensi, dimungkinkan untuk secara substansial mengurangi penggunaan memori karena aktivasi perantara tidak diperlukan setelah digunakan. Kami akan mempertimbangkan untuk menambahkan pengoptimalan memori khusus inferensi di masa mendatang.

@Omegastick Diuji pada mesin saya, baik Faster RCNN- resnet 101 dan Mask RCNN- resnet 101 menggunakan memori GPU sekitar 4GB.

@ ir413 Terima kasih, model yang Anda

Akan lebih keren jika inferensi tidak membutuhkan GPU sama sekali.

bagaimana saya bisa menjalankan mask-rcnn dengan GPU memori 2G? ada yang bisa bantu saya ?

Apakah masalah ini karena implementasi Caffe 2 atau Detectron? File mana di Detectron yang harus saya lihat untuk mengatasi masalah ini?

@rbgirshick

Dalam hal inferensi, dimungkinkan untuk secara substansial mengurangi penggunaan memori karena aktivasi perantara tidak diperlukan setelah digunakan. Kami akan mempertimbangkan untuk menambahkan pengoptimalan memori khusus inferensi di masa mendatang.

Apakah sudah ada sesuatu yang diimplementasikan di PyTorch/Caffe2 ? Jika ya di mana kita perlu menggali?

@gadcam Ini sudah lama ada di daftar tugas saya, tapi sayangnya prioritasnya berkurang bukannya meningkat :/. Saya pikir caffe2.python.memonger.release_blobs_when_used (https://github.com/pytorch/pytorch/blob/master/caffe2/python/memonger.py#L229) harus mengimplementasikan sebagian besar dari apa yang kita butuhkan. Namun ada beberapa masalah non-sepele yang perlu ditangani:

  • Untuk beberapa jaringan (misalnya Mask R-CNN) beberapa jaring digunakan pada waktu inferensi dan oleh karena itu tidak semua aktivasi dapat dibebaskan dengan penalaran hanya pada satu grafik (karena mereka mungkin diperlukan oleh grafik lain, misalnya, jaring kepala topeng).
  • Fungsi ini memerlukan penggunaan manajer memori caching, yang belum kami uji, jadi mungkin ada masalah hanya dengan menyalakannya.

@rbgirshick Terima kasih atas penjelasan terperinci Anda!

Jadi seperti yang saya pahami, bagi kami release_blobs_when_used bertindak sebagai konverter dari Proto biasa ke yang "dioptimalkan memori".

Untuk beberapa jaringan (misalnya Mask R-CNN) beberapa jaring digunakan pada waktu inferensi dan oleh karena itu tidak semua aktivasi dapat dibebaskan dengan penalaran hanya pada satu grafik (karena mereka mungkin diperlukan oleh grafik lain, misalnya, jaring kepala topeng).

Dikatakan dengan kata lain kita harus mengisi dont_free_blobs dengan blob yang digunakan pada tahap kedua ?

Fungsi ini memerlukan penggunaan manajer memori caching, yang belum kami uji, jadi mungkin ada masalah hanya dengan menyalakannya.

Jadi jika kita ingin mengujinya kita perlu mengatur FLAGS_caffe2_cuda_memory_pool ke cub (atau thc ) tetapi bisakah kita melakukan ini dengan Python ?
Salah satu referensi yang sangat langka yang dapat saya temukan ada di sini https://github.com/pytorch/pytorch/blob/6223bfdb1d3273a57b58b2a04c25c6114eaf3911/caffe2/core/context_gpu.cu#L190

@gadcam

Jadi seperti yang saya pahami, bagi kami release_blobs_when_used bertindak sebagai konverter dari Proto biasa ke yang "dioptimalkan memori".

Ya, itu benar. Ini menganalisis grafik komputasi, menentukan kapan setiap gumpalan tidak lagi digunakan, dan kemudian memasukkan operasi pembebasan memori.

Dikatakan dengan kata lain kita harus mengisi dont_free_blobs dengan gumpalan yang digunakan oleh tahap kedua?

Ya, dengan peringatan bahwa saya tidak yakin seberapa baik digunakan dan/atau diuji fungsi ini...dari kode grepping tampaknya itu tidak benar-benar digunakan. Jadi saya akan ingat bahwa itu mungkin tidak bekerja seperti yang diharapkan.

Jadi jika kita ingin mengujinya, kita perlu mengatur FLAGS_caffe2_cuda_memory_pool ke cub (atau thc) tetapi bisakah kita melakukan ini dengan Python ?

Ya. Saya pikir manajer memori thc baru ditambahkan lebih efisien. Kami perlu menggunakannya sebagai ganti cub untuk kasus penggunaan baru-baru ini (meskipun berbeda).

@rbgirshick Anda benar, sepertinya jalan yang berisiko!

Ya. Saya pikir manajer memori thc yang baru ditambahkan lebih efisien. Kami perlu menggunakannya sebagai ganti cub untuk kasus penggunaan baru-baru ini (meskipun berbeda).

Maksud saya adalah apakah Anda tahu di mana saya dapat menemukan dokumentasi untuk melakukannya atau apakah Anda memiliki contoh? (Saya benar-benar minta maaf untuk bersikeras pada yang ini, mungkin saya melewatkan sesuatu tetapi saya tidak dapat menemukan dokumentasi apa pun tentangnya)

@gadcam tentang dokumentasi, bukan yang saya ketahui. Maaf!

@asaadaldien Saya benar-benar minta maaf telah mengganggu Anda, tetapi Anda tampaknya menjadi salah satu dari sedikit orang yang menyarankan untuk

PASTIKAN caffe2_cuda_memory_pool disetel

ketika kami menggunakan pemonger atau data_parallel_model (untuk referensi ada di sini ).
Apakah Anda memiliki petunjuk tentang cara memastikan kami mengaktifkan manajer memori caching? (Menggunakan Caffe2 dengan Python)

@gadcam Anda dapat mengaktifkan cub cached allocator dengan mengirimkan cub ke caffe2_cuda_memory_pool flag. misalnya:

workspace.GlobalInit([
'--caffe2_cuda_memory_pool=cub',
])

Namun ini hanya diperlukan saat menggunakan pemanger memori dinamis.

@asaadaldien
Saya membutuhkan banyak waktu untuk mencari tahu bagaimana melakukannya karena tidak ada dokumentasi tentang GlobalInit .
Terima kasih banyak atas bantuan Anda! Jadi sekarang saya dapat memulai beberapa eksperimen!

Saya punya solusi sederhana untuk masalah ini.
Anda dapat mengatur 'P2~P5' dan 'rois' sebagai output blob, tidak hanya blob tengah, maka tidak akan dioptimalkan saat menggunakan optimasi memori.

Sepertinya tidak bekerja untuk saya.
Model yang saya uji adalah e2e_keypoint_rcnn_R-50-FPN_s1x.yaml .
Saya mencoba mengujinya terhadap bagian model.net .

Saya menggunakan infer_simple.py untuk tes.

workspace.GlobalInit(['caffe2', '--caffe2_log_level=0', '--caffe2_cuda_memory_pool=thc']) 

dan

dont_free_blobs = set(model.net.Proto().external_output)
expect_frees = set(i for op in model.net.Proto().op for i in op.input)
expect_frees -= dont_free_blobs

opti_net = release_blobs_when_used(model.net.Proto(), dont_free_blobs, selector_fun=None)
model.net.Proto().op.extend(copy.deepcopy(opti_net.op))

test_release_blobs_when_used(model.net.Proto(), expect_frees) 

di mana test_release_blobs_when_used terinspirasi oleh https://github.com/pytorch/pytorch/blob/bf58bb5e59fa64fb49d77467f3466c6bc0cc76c5/caffe2/python/memonger_test.py#L731

def test_release_blobs_when_used(with_frees, expect_frees):
    found_frees = set()
    for op in with_frees.op:
        if op.type == "Free":
            print("OP FREEE", op)
            assert(not op.input[0] in found_frees)  # no double frees
            found_frees.add(op.input[0])
        else:
            # Check a freed blob is not used anymore
            for inp in op.input:
                assert(not inp in found_frees)
            for outp in op.output:
                assert(not outp in found_frees)

    try:
        assert(expect_frees == found_frees)
    except:
        print("Found - Expect frees Nb=", len(found_frees - expect_frees), found_frees - expect_frees, "\n\n\n")
        print("Expect - Found frees Nb=", len(expect_frees - found_frees), expect_frees - found_frees, "\n\n\n")
       #assert(False)

Harap dicatat bahwa dont_free_blobs tidak disetel ke nilai yang benar!

Fungsi ini memberi tahu saya bahwa tidak ada gumpalan tak terduga yang akan dibebaskan dan ada beberapa yang hilang.
(yang normal karena dont_free_blobs tidak benar)
Jadi saya terus menjalankan modelnya.

Dan... tidak ada yang terjadi. Saya memeriksa dengan menggunakan fungsi save_graph : operasi gratis memang ada di sini di tempat yang tepat.

Penggunaan memori untuk input sampel saya dari baris ini adalah 1910 Mo +/- 5 Mo
https://github.com/facebookresearch/Detectron/blob/6c5835862888e784e861824e0ad6ac93dd01d8f5/detectron/core/test.py#L158

Tetapi sesuatu yang sangat mengejutkan terjadi jika saya mengatur manajer memori ke CUB

workspace.GlobalInit(['caffe2', '--caffe2_log_level=0', '--caffe2_cuda_memory_pool=cub']) 

Penggunaan RAM dari baris RunNet ditingkatkan dengan sesuatu seperti 3 Go!! (menggunakan kode biasa atau yang khusus dengan gumpalan Gratis)

Aku gagal memahami apa yang sedang terjadi...

Seperti yang dijelaskan di #507, saya juga menghadapi kesalahan kehabisan memori saat memulai inferensi pada Jetson TX1.
Solusi yang dijelaskan di utas ini, seperti:
python2 tools/infer_simple.py \ --cfg configs/12_2017_baselines/e2e_faster_rcnn_R-50-FPN_2x.yaml \ --output-dir /tmp/detectron-visualizations \ --image-ext jpg \ --wts https://s3-us-west-2.amazonaws.com/detectron/35857389/12_2017_baselines/e2e_faster_rcnn_R-50-FPN_2x.yaml.01_37_22.KSeq0b5q/output/train/coco_2014_train%3Acoco_2014_valminusminival/generalized_rcnn/model_final.pkl \ demo
Juga tidak berfungsi, saya masih kehabisan memori, meskipun saya memiliki total 4 GB RAM yang tersedia (walaupun memori CPU dan GPU digunakan bersama).
Apakah masih ada model yang lebih kecil yang bisa saya coba?
Karena seperti yang dijelaskan @Omegastick , itu hanya membutuhkan memori hingga 2,5 GB, tetapi sepertinya masih tidak muat di Jetson. Ada saran lain yang bisa saya coba?

@johannathiemich saya mendapat masalah yang sama. Tidak ada kesalahan tetapi prosesnya mati. Apakah Anda memecahkan masalah? Saya menggunakan Jetson TX1, juga.

@ ll884856 Ya, sebenarnya saya melakukannya. Saya akhirnya menukar jaring dasar dengan pemeras dan melatih jaring lagi. Namun perlu diingat bahwa kinerjanya jauh lebih buruk daripada dengan tulang punggung ResNet asli.
Apa yang juga dapat Anda coba sebelum mengubah basenet adalah mematikan FPN yang mungkin membantu juga. Tapi itu juga akan mengurangi kinerjanya meskipun saya berharap penurunannya tidak separah itu.
Jika Anda mau, saya dapat memberikan implementasi dan bobot pemerasan saya kepada Anda. Saat ini saya sedang mengerjakan tesis sarjana saya tentang topik ini.

@johannathiemich Terima kasih atas balasan Anda! Sebenarnya, saya baru saja berkecimpung di bidang ini dan saya tidak begitu jelas tentang arsitektur Mask R-CNN. Jika Anda dapat memberi saya implementasi dan bobot Anda, itu akan banyak membantu saya untuk memahami dan mengimplementasikan Mask R-CNN. Email saya adalah [email protected]
Terima kasih !

Ya, Anda dapat melakukan Mask-RCNN pada CPU hanya saja tidak dengan detektor:

Lihat:
https://vimeo.com/277180815

Saya memiliki satu masalah serupa, jadi jika ada orang yang membantu saya di sini, saya akan sangat menghargainya https://github.com/facebookresearch/detectron2/issues/1539 Saya benar-benar tidak mengerti mengapa ini terjadi. Jadi, saya membutuhkan RAM 9,3 GB untuk prediksi 25 gambar dalam satu batch di cpu setelah menyertakan bagian torch.nograd() di dalamnya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat