Pilih pertanyaan sebelum membuka trace
Trace lebih baik menjawab pertanyaan yang spesifik: apakah komputasi menunggu data, apakah ada penyalinan yang diulang, atau apakah ada operator kecil yang dipanggil terlalu sering? Tetapkan input, output, dan batas langkah Anda. Untuk pelatihan, tentukan apakah langkah tersebut mencakup backward, pembaruan optimizer, dan pembacaan batch. Untuk inferensi, pisahkan pemuatan model dan permintaan.
Pertahankan skenario singkat yang Anda sudah tahu kebenarannya. Catat bentuk tensor, batch, presisi, mode model, kompilasi jika ada, dan sumber data. Input yang disederhanakan dapat membantu mengisolasi suatu perilaku, tetapi tidak lagi selalu mewakili beban penuh. Sebutkan perbedaan ini dalam catatan.
Tetapkan unit akhir: milidetik per langkah atau contoh yang diproses per detik. Jumlah total peristiwa tidak menggantikan waktu yang berlalu. Bandingkan jendela yang memiliki batas pembacaan dan transfer yang sama.
Bedakan waktu CPU, kerja GPU, dan waktu tunggu
CPU menyiapkan dan meluncurkan operasi; GPU dapat mengeksekusinya nanti. Oleh karena itu, sebuah interval Python dapat berisi peluncuran, penantian, atau keduanya. Dokumentasi CUDA dari PyTorch menyatakan bahwa pengukuran yang akurat harus memperhitungkan asinkronisme ini, terutama melalui sinkronisasi atau event yang sesuai dengan cakupannya.
Untuk pengukuran durasi GPU yang spesifik, event CUDA dapat digunakan. Untuk latensi end-to-end, tunggu selesainya pekerjaan yang termasuk dalam latensi tersebut dan ukur keseluruhan permintaan. Jangan mencampur kedua satuan ini. Sinkronisasi yang ditambahkan di antara setiap operasi dapat menghilangkan tumpang tindih yang nyata dan mengubah program yang ingin Anda pahami.
Dalam profiler, waktu mandiri sebuah operator dan waktu yang mencakup sub-operasi juga menjawab pertanyaan yang berbeda. Lihat kronologi sebelum menjumlahkan baris-baris tabel. Aktivitas yang simultan atau bersarang bukanlah bagian-bagian waktu yang telah berlalu secara terpisah.
Sediakan fase pemanasan dan jendela aktif
Pasal pertama dapat mencakup inisialisasi, pemuatan, atau kompilasi. Putuskan apakah pertanyaan Anda menyangkut pemanasan ini atau fase yang sudah stabil. Simpan kedua pengamatan tersebut ketika keduanya penting bagi penggunaan, alih-alih menghapus biaya awal dari rata-rata yang disajikan sebagai keseluruhan.
Fungsi schedule memungkinkan untuk membedakan penantian, persiapan pengumpulan, dan jendela aktif. Pemanasan profiler bukanlah bukti bahwa model Anda telah mencapai kondisi stabilnya. Periksa juga bentuk yang ditemui dan keadaan cache. Aplikasi dengan masukan yang bervariasi dapat menemui jalur baru setelah beberapa iterasi.
Jadwal pembelajaran yang diusulkan di bawah ini menunggu satu langkah, mempersiapkan satu langkah, dan menangkap dua langkah. Empat langkah cukup untuk menjelaskan mekanismenya, tetapi tidak cukup untuk menetapkan distribusi performa. Dalam kampanye nyata, pilih jendela yang dapat dijustifikasi dan ulangi pengukuran tanpa profiler setelah analisis.
Contoh yang diusulkan: empat langkah dengan batas yang mudah dibaca
Fragmen berikut tidak dijalankan. Fragmen ini mengasumsikan bahwa model, optimizer, loss_fn, loader, dan device tersedia, model berada di device, dan loader menyediakan setidaknya empat batch pasangan x, y. Fragmen ini melakukan pembaruan: gunakan state eksperimental yang memang diperuntukkan bagi hal itu, bukan sesi yang bobotnya harus Anda pertahankan.
Label memisahkan pembacaan CPU, transfer, dan pelatihan. Iterator dibuat sebelum jendela, sehingga sebagian dari proses awalnya berada di luar cakupan. File dipilih dengan nama baru untuk menghindari penimpaan trace. Contoh ini menolak pengumpulan GPU yang tidak tersedia alih-alih diam-diam menyajikan trace CPU sebagai analisis GPU.
Sinyal step() memajukan jadwal setelah setiap langkah. Resep resmi menjelaskan keterkaitan antara iterasi dan pengumpulan ini. Pada stack ROCm, perangkat PyTorch tetap bernama cuda; ketersediaan pengumpulan akselerator tetap bergantung pada build dan alatnya. Periksa aktivitas yang benar-benar ada di dalam hasil.
from pathlib import Path
import torch
from torch.profiler import (
profile, schedule, record_function,
ProfilerActivity, supported_activities,
)
trace = Path("trace-etape.json")
if trace.exists():
raise FileExistsError("Pilih nama trace baru")
activities = [ProfilerActivity.CPU]
if device.type == "cuda":
if ProfilerActivity.CUDA not in supported_activities():
raise RuntimeError("Pengumpulan GPU tidak tersedia di build ini")
activities.append(ProfilerActivity.CUDA)
iterator = iter(loader)
model.train()
with profile(
activities=activities,
schedule=schedule(wait=1, warmup=1, active=2, repeat=1),
record_shapes=False, profile_memory=False, with_stack=False,
on_trace_ready=lambda p: p.export_chrome_trace(str(trace)),
) as prof:
for _ in range(4):
with record_function("lecture_batch_cpu"):
x, y = next(iterator)
with record_function("transfert"):
x, y = x.to(device), y.to(device)
with record_function("entrainement"):
optimizer.zero_grad(set_to_none=True)
loss = loss_fn(model(x), y)
loss.backward()
optimizer.step()
prof.step()
print(prof.key_averages().table(
sort_by="self_cpu_time_total", row_limit=8,
))Mengubah observasi menjadi hipotesis yang dapat diverifikasi
Mulailah dari jendela aktif dan periksa apakah label yang diharapkan muncul. Setelah itu, perhatikan jeda antaraktivitas, penyalinan, dan pengulangan. Waktu tunggu yang panjang di lecture_batch_cpu mengarah pada pipeline input; hal itu tidak mengukur penyimpanan secara langsung. Penyalinan yang sering mengundang pemeriksaan penempatan tensor, tanpa membuktikan bahwa hal itu tidak berguna.
Rumuskan satu hipotesis saja, lalu usulkan perubahan yang terkendali. Misalnya, jika sebuah konstanta dibangun ulang dan ditransfer pada setiap langkah, periksa apakah masa pakainya dapat mencakup beberapa langkah tanpa mengubah hasil. Jika sebuah operator tampak dominan, periksa bentuk dan jumlah pemanggilannya sebelum mencari penggantinya.
Baris-baris di bawah ini adalah kemungkinan pembacaan, bukan temuan dari trace yang dijalankan. Tidak ada durasi maupun percepatan yang dijanjikan. Kesimpulan yang berguna adalah eksperimen berikutnya yang dapat mengonfirmasi atau menyanggah penyebab yang diusulkan.
Geser tabel untuk membaca semua kolom.| Kemungkinan observasi | Hipotesis | Kontrol berikutnya |
|---|---|---|
| GPU tanpa aktivitas selama pembacaan | Pipeline input tidak mengikuti | Perhitungan yang sama dengan batch yang sudah disiapkan |
| Penyalinan konstanta yang berulang | Penempatan atau masa pakai yang tidak sesuai | Pindahkan sekali, verifikasi outputnya |
| Banyak peluncuran kecil | Pekerjaan yang terfragmentasi | Periksa pengelompokan dan biaya keseluruhan |
| Satu operator yang lama | Bentuk atau algoritma yang menentukan | Bandingkan operator yang sama beserta inputnya |
Membatasi biaya dan informasi instrumentasi
Mulailah dengan pengumpulan singkat dan sedikit opsi. Aktifkan bentuk, stack, atau memori hanya jika ada pertanyaan yang menuntutnya. API PyTorch menjelaskan bahwa informasi ini menambah biaya; pengumpulan bentuk bahkan dapat menahan referensi ke tensor. Profil yang terperinci karena itu dapat mengubah durasi atau pemakaian memori program.
Sebuah trace dapat memuat nama operator, bentuk, dan bergantung pada opsi, jalur kode. Periksa trace tersebut sebelum membagikannya. Label zona harus mendeskripsikan langkah tanpa menyertakan email, token, jalur privat, atau konten masukan. Pilih pembaca trace yang sesuai dengan lingkungan Anda dan jaga pengumpulan tetap dalam kendali Anda.
Jika peristiwa GPU yang diharapkan tidak ada, jangan isi waktunya dengan nol. Nyatakan bahwa peristiwa tersebut tidak teramati dan periksa dukungan pengumpulan. Tidak adanya peristiwa di dalam alat bukanlah bukti tidak adanya komputasi.
Validasi optimasi di luar profiler
Mulailah dari keadaan relevan yang sama dan bandingkan kebenaran sebelum dan sesudah perubahan. Untuk pelatihan, satu langkah tambahan mengubah bobot; dua penangkapan yang dijalankan berturut-turut belum tentu merupakan perbandingan yang setara. Simpan kode, parameter, dan titik awal agar perbedaannya dapat Anda jelaskan.
Selanjutnya ukur skenario tanpa pengumpulan terperinci, dengan pemanasan yang sama dan beberapa kali pengulangan. Laporkan cakupan, nilai mentah, dan sebarannya. Peningkatan lokal bisa hilang dalam keseluruhan loop atau menurunkan kualitas: keduanya harus tetap diperhitungkan dalam keputusan.
Terakhir, gunakan observasi tersebut untuk mempersempit sumber daya yang benar-benar dibutuhkan. Trace dari komputer Anda tidak mengurutkan penawaran Kernodeck dan tidak membuktikan prosesor host maupun jaringan server sewaan. Perbandingan GPU menuntut beban, kondisi, dan hasil yang sebanding pada sumber daya yang bersangkutan.