Batch berpadding dibentuk oleh sequence terpanjang, bukan panjang rata-ratanya. Jika sebuah batch berisi jumlah token 120, 124, 131, dan 900, setiap sequence dapat direpresentasikan dengan panjang 900. Sebagian besar posisi pada tiga baris pertama kemudian berisi padding, bukan token input.
Length bucketing mengubah komposisi batch tanpa mengubah model. Contoh dengan jumlah token serupa ditempatkan berdekatan sebelum batch dibentuk. Panjang maksimum dalam setiap batch menjadi lebih dekat dengan panjang anggotanya, sehingga jumlah posisi padding yang diproses oleh operasi yang masih memakai bentuk batch persegi panjang berkurang.
Biaya padding mengikuti maksimum lokal
Untuk batch berisi B sequence dengan panjang l_1 ... l_B, misalkan
L = max(l_1, ..., l_B)Representasi dense berpadding berisi B * L posisi token. Jumlah posisi token nyata adalah
sum_i l_isehingga jumlah padding adalah
B * L - sum_i l_iAritmetika ini membuat komposisi batch menjadi penting. Empat sequence dengan panjang 120, 124, 131, dan 136 membutuhkan total 544 posisi pada tensor berpadding, dan 511 di antaranya berisi token nyata. Mengganti sequence terakhir dengan panjang 900 menaikkan bentuk persegi panjang menjadi 3600 posisi sementara jumlah token nyata hanya 1275.
Padding mask mencegah posisi padding diperlakukan sebagai konten biasa, tetapi keberadaan mask tidak berarti setiap kernel di bawahnya melewati seluruh aritmetika atau storage yang terkait dengan posisi tersebut. Penghematan aktual dari pengurangan padding bergantung pada arsitektur model, implementasi attention, bentuk tensor, perilaku compiler, dan hardware. Karena itu, okupansi token merupakan metrik batching yang berguna, bukan janji langsung tentang pengurangan runtime yang proporsional.
Ukuran okupansi sederhana adalah
occupancy = real_tokens / padded_tokensdengan padded_tokens bernilai B * L untuk batch dense konvensional. Melacak nilai ini memperlihatkan properti yang disembunyikan oleh metrik jumlah contoh per batch saja.
Bucketing mengubah distribusi di dalam setiap batch
Skema bucketing paling langsung mengurutkan contoh berdasarkan jumlah token lalu mengambil group berurutan. Cara ini menghasilkan batch yang rapat, tetapi pengurutan global juga membentuk pola urutan yang kuat. Contoh pendek muncul bersama selama interval panjang, lalu diikuti contoh yang semakin panjang.
Urutan tersebut dapat tidak diinginkan dalam optimisasi stokastik karena komposisi batch menjadi berkorelasi dengan panjang sequence di sebagian besar epoch. Panjang sequence juga dapat berkorelasi dengan properti data lain, sehingga pengurutan ketat dapat mengelompokkan lebih dari sekadar bentuk tensor.
Desain yang umum mempertahankan bucketing secara lokal. Pipeline data dapat mengacak contoh, mengumpulkan pool sementara yang lebih besar, mengurutkan atau mempartisi pool itu berdasarkan panjang, mengeluarkan batch dari panjang yang berdekatan, lalu melanjutkan dengan pool acak berikutnya. Desain lain memasukkan contoh ke rentang panjang kasar dan melakukan shuffle di dalam setiap rentang.
Pendekatan ini menukar sedikit kerapatan packing dengan urutan yang tidak terlalu deterministik. Lebar bucket yang tepat bergantung pada workload: rentang sempit mengurangi padding tetapi membatasi contoh yang dapat berbagi batch, sedangkan rentang lebar meningkatkan pencampuran dengan konsekuensi variasi maksimum lokal yang lebih besar.
Token budget berperilaku berbeda dari batch size tetap
Jumlah contoh tetap masih dapat menghasilkan variasi besar pada total token. Batch berisi delapan sequence 100 token memiliki bentuk tensor yang sangat berbeda dari batch berisi delapan sequence 2.000 token.
Token budget membatasi pembentukan batch menggunakan panjang sequence, bukan hanya jumlah contoh. Salah satu kebijakan sederhana menambahkan contoh selama estimasi bentuk berpadding masih berada di bawah batas yang dikonfigurasi:
candidate_cost = candidate_batch_size * candidate_max_lengthEstimasi ini cocok dengan jumlah posisi token dalam input persegi panjang dense, meskipun tidak merepresentasikan setiap alokasi memori selama forward atau backward pass.
Length bucketing dan token budget menangani masalah yang berkaitan tetapi berbeda. Bucketing mengurangi variasi di antara contoh yang ditempatkan bersama. Token budget menyesuaikan jumlah contoh agar batch sequence panjang tidak menjadi terlalu besar dalam jumlah token. Menggabungkan keduanya dapat menghasilkan jumlah contoh kecil untuk sequence panjang dan jumlah contoh lebih besar untuk sequence pendek sambil menjaga jumlah token berpadding dalam rentang yang lebih sempit.
Hal ini mengubah makna sebuah training batch. Jika optimizer update terjadi setelah setiap physical batch, jumlah contoh yang bervariasi juga menghasilkan jumlah contoh per update yang bervariasi. Sistem yang memerlukan definisi effective batch tertentu dapat mengakumulasi gradient sampai target jumlah token, jumlah contoh, atau batas eksplisit lain tercapai.
Panjang harus diukur setelah transformasi yang relevan
Bucketing hanya seakurat estimasi panjangnya. Jumlah karakter, byte, kata, dan token tidak dapat dipertukarkan. Untuk input transformer, besaran yang berguna umumnya adalah panjang sequence yang benar-benar mencapai proses batching setelah tokenization serta truncation atau penyisipan special token yang relevan.
Menghitung jumlah token secara tepat sebelumnya dapat menyederhanakan perencanaan batch ketika contoh yang sudah ditokenisasi disimpan. Pada pipeline yang melakukan tokenization secara dinamis, estimasi murah dapat menghindari preprocessing pass tambahan, tetapi error estimasi mengurangi kualitas bucket. Efeknya bersifat operasional, bukan semantik: contoh tetap membawa data yang sama, tetapi group dengan estimasi buruk dapat kembali memiliki sebaran padding yang hendak dikurangi bucketing.
Input berpasangan atau multi-field menambah detail lain. Jika tokenizer menggabungkan field menjadi satu model sequence, panjang untuk batching harus mencerminkan representasi gabungan tersebut. Bucketing hanya berdasarkan satu field dapat menyesatkan ketika field lain sangat bervariasi.
Truncation juga mengubah distribusi yang relevan. Jika semua input di atas batas tertentu dipotong ke batas tersebut, panjang efektifnya berkumpul pada ceiling yang sama. Bucketing berdasarkan ukuran mentah sebelum truncation dapat memisahkan contoh yang akhirnya menghasilkan panjang tensor identik.
Distributed training memerlukan pembagian batch yang seimbang
Dalam data-parallel training, setiap worker biasanya memproses local batch sebelum worker melakukan sinkronisasi untuk update berikutnya. Jika satu worker berulang kali menerima batch berpadding lebih panjang daripada peer-nya, worker yang lebih cepat dapat menghabiskan waktu menunggu di titik sinkronisasi.
Length-aware batching dapat mengurangi padding pada setiap worker tetapi tetap menciptakan ketimpangan antarworker jika batch dibagikan dengan buruk. Misalnya, menempatkan beberapa batch panjang pada satu worker dan beberapa batch pendek pada worker lain menghasilkan workload lokal berbeda meskipun setiap batch individual memiliki okupansi tinggi.
Distributed sampler karena itu memiliki dua tugas yang berkaitan: membentuk batch dengan variasi panjang internal yang dapat diterima dan mendistribusikan batch tersebut agar worker menerima pekerjaan yang sebanding sepanjang interval sinkronisasi. Keseimbangan tepat tidak dijamin dengan menyamakan jumlah contoh karena jumlah yang sama dapat mewakili jumlah token berpadding yang sangat berbeda.
Randomness juga perlu ditangani secara eksplisit. Jika setiap worker secara independen membentuk bucket dari data global yang sama tanpa partisi terkoordinasi, contoh dapat terduplikasi atau terlewat. Aturan partitioning dan shuffling harus tetap sesuai dengan kontrak distributed sampling framework.
Metrik padding memerlukan konteks
Rasio padding yang lebih rendah merupakan bukti berguna bahwa bucketing mengubah okupansi tensor, tetapi tidak dengan sendirinya membuktikan speedup end-to-end. Persiapan input dapat menjadi lebih kompleks, bentuk dinamis dapat memengaruhi compilation atau pemilihan kernel, dan bucket yang sangat sempit dapat memecah contoh yang tersedia menjadi batch size yang kurang ideal.
Pengukuran yang berguna memisahkan efek tersebut. Rasio padding menunjukkan seberapa banyak input persegi panjang berisi data nyata. Token yang diproses per satuan waktu menangkap throughput eksekusi. Peak device memory menunjukkan apakah bentuk berpadding yang lebih kecil menciptakan headroom memori yang dapat dimanfaatkan. Waktu tunggu data loader dapat memperlihatkan apakah sorting, tokenization, atau queueing memindahkan bottleneck ke luar model.
Perbandingan juga harus memakai effective workload yang sama. Mengukur dua run dengan truncation, semantik optimizer update, atau jumlah token berbeda dapat membuat perubahan batching tampak bertanggung jawab atas efek yang sebenarnya berasal dari tempat lain.
Length bucketing paling bernilai ketika panjang sequence cukup bervariasi sehingga maksimum lokal menghasilkan padding yang besar. Jika ukuran input sudah berdekatan, hanya ada sedikit padding yang dapat dihilangkan oleh mekanisme batching. Memperlakukan distribusi panjang yang teramati sebagai bagian dari desain sistem menjaga optimisasi tetap terikat pada workload, bukan pada satu resep batching yang tetap.