Generasi autoregresif biasanya maju satu token setiap iterasi: model menghitung distribusi token berikutnya, aturan decoding memilih token, lalu token tersebut masuk ke konteks untuk forward berikutnya. Speculative decoding mengubah jadwal eksekusi ini. Proses draft yang lebih murah mengusulkan beberapa token ke depan, sementara model target tetap menentukan usulan mana yang boleh masuk ke sequence hasil.
Pemisahan peran itu merupakan batas utamanya. Token draft adalah prediksi terhadap keputusan model target di posisi mendatang, bukan distribusi pengganti yang dapat langsung ditambahkan. Implementasi serving harus memverifikasinya memakai skor model target dan menerapkan aturan penerimaan dari algoritma speculative yang digunakan.
Draft mengubah tebakan serial menjadi batch verifikasi
Anggap prefix yang sudah diterima adalah x dan proses draft mengusulkan:
d1, d2, d3, d4Model target dapat mengevaluasi sequence yang diperpanjang tersebut dan menghasilkan distribusi token berikutnya untuk posisi terkait dalam satu pass verifikasi:
p1(. | x)
p2(. | x, d1)
p3(. | x, d1, d2)
p4(. | x, d1, d2, d3)Posisi-posisi itu tetap memiliki urutan kausal. Memverifikasinya sebagai batch tidak mengubah generasi token menjadi non-autoregresif; yang berubah adalah jadwal komputasi model target. Distribusi target pada posisi lebih akhir tetap dikondisikan pada token draft sebelumnya yang disertakan dalam input verifikasi.
Jika token draft yang lebih awal ditolak, posisi draft setelahnya yang bergantung pada token tersebut tidak dapat langsung di-commit seolah prefix yang ditolak sudah diterima. Algoritma menghentikan atau memperbaiki span speculative sesuai aturan yang ditetapkan, lalu melanjutkan dari prefix hasil yang benar-benar diterima.
Semantik penerimaan bergantung pada algoritma decoding
Pada greedy decoding, verifikasi dapat dipandang secara sederhana. Token draft pada suatu posisi diterima ketika sama dengan token yang akan dipilih model target memakai aturan greedy yang sama. Verifikasi bergerak sepanjang span draft sampai mismatch pertama. Token pilihan target kemudian dapat menggantikan usulan yang ditolak, sesuai detail implementasi.
Sampling membutuhkan perlakuan yang lebih ketat. Membandingkan token draft hanya dengan argmax model target tidak mempertahankan distribusi sampling target. Algoritma speculative sampling menetapkan probabilitas penerimaan dari probabilitas draft dan target, lalu saat terjadi penolakan mengambil sampel dari distribusi koreksi. Persamaan tepatnya mengikuti algoritma yang dipilih; menggantinya dengan uji kecocokan informal akan mengubah distribusi output.
Perbedaan ini juga membatasi shortcut implementasi. Speculative decoding bukan sekadar menjalankan model kecil lebih dulu lalu memeriksa apakah model besar menganggap tokennya masuk akal. Threshold probabilitas, uji keanggotaan top-k, atau aturan jarak logit membentuk decoder berbeda kecuali aturan tersebut memang menjadi bagian dari algoritma yang semantiknya sudah ditentukan.
Model target tetap menjadi otoritas distribusi
Invarian implementasi yang berguna adalah confidence draft tidak dapat memberikan penerimaan dengan sendirinya. Model draft dapat memberi probabilitas tinggi pada token yang diberi skor berbeda oleh model target. Verifier harus memakai output model target untuk keputusan penerimaan yang disyaratkan algoritma.
Hal ini tetap berlaku ketika proses draft bukan model kecil konvensional. Usulan dapat berasal dari head lain, jalur komputasi terpotong, struktur cache, atau mekanisme lain. Desain tersebut dapat mengubah biaya dan mutu proposal, tetapi batas perannya tetap sama: pembuatan proposal dan verifikasi target merupakan dua fungsi terpisah.
Proses draft juga tidak harus mereproduksi seluruh distribusi target secara sempurna agar berguna. Proposal perlu cukup sering selaras dengan keputusan target supaya pekerjaan speculative tidak terlalu sering dibuang. Titik operasi yang sesuai bergantung pada biaya draft, panjang span yang diterima, biaya verifikasi target, bentuk batch, hardware, dan implementasi serving. Satu angka acceptance rate saja tidak menjamin peningkatan kecepatan secara universal.
Penolakan memendekkan pekerjaan speculative yang berguna
Misalkan dua proposal pertama diterima dan proposal ketiga ditolak:
draft: d1 d2 d3 d4
status: ok ok reject unusedProposal keempat dihitung dari prefix yang memuat d3. Setelah d3 tidak menjadi bagian dari sequence yang diterima, d4 bukan kelanjutan dari prefix yang di-commit. Komputasi draft untuk token tersebut mungkin sudah memakai resource, tetapi token itu tidak dapat dipertahankan sebagai token masa depan yang terverifikasi secara independen pada jalur kausal semula.
Kondisi ini menimbulkan ketegangan praktis pada panjang span speculative. Span lebih panjang menyediakan lebih banyak posisi kandidat per pass verifikasi saat kesesuaian bertahan. Namun, lebih banyak pekerjaan draft juga dapat menjadi tidak terpakai setelah penolakan dini. Panjang span yang sesuai karena itu bergantung pada workload dan implementasi, bukan konstanta arsitektural tunggal.
State KV cache harus mengikuti token yang di-commit
Eksekusi speculative juga memengaruhi pengelolaan cache. Eksekusi draft dan target dapat sementara menghasilkan state key-value untuk token yang pada akhirnya tidak di-commit. Engine serving harus membedakan entry cache provisional dari state yang mewakili sequence yang diterima.
Setelah penolakan, state cache model target harus merepresentasikan prefix yang benar-benar di-commit sebelum decoding biasa atau speculative dilanjutkan. Implementasi dapat memakai metadata rollback, pengelolaan cache berbasis page, selective commit, recomputation, atau mekanisme internal lain. Representasinya spesifik implementasi; syarat semantiknya tetap sama. Token speculative yang ditolak tidak boleh diam-diam tertinggal sebagai konteks kausal untuk generasi target berikutnya.
Batas ini makin terlihat pada continuous batching, paged KV cache, dan request preemption. Bookkeeping scheduler, panjang sequence, kepemilikan cache, dan jumlah token yang diterima harus merujuk pada prefix yang sama walaupun pekerjaan provisional masih ada secara internal.
Dampak pada throughput dan latency bersifat kondisional
Speculative decoding mengurangi jumlah iterasi decoding model target yang serial hanya ketika cukup banyak token usulan lolos verifikasi dan pekerjaan verifikasi dipetakan dengan baik ke hardware serving. Mekanisme ini juga menambahkan komputasi draft, logika penerimaan, state provisional, dan pada beberapa implementasi tambahan traffic memori.
Akibatnya, konfigurasi yang membantu satu pola serving dapat netral atau merugikan pada pola lain. Output pendek dapat memberi sedikit ruang untuk mengamortisasi setup dan pekerjaan draft. Batching berat dapat mengubah biaya relatif verifikasi target. Mekanisme draft dengan kesesuaian rendah dapat menghabiskan komputasi untuk token yang kemudian dibuang. Dukungan kernel dan layout cache juga dapat mengubah keseimbangannya.
Batas implementasinya karena itu lebih sempit daripada frasa “menghasilkan beberapa token sekaligus”. Speculative decoding membuat token masa depan yang provisional, memverifikasinya dengan semantik model target, hanya meng-commit prefix yang diterima, dan menjaga state cache tetap selaras dengan commit tersebut. Optimasi di sekitar mekanisme ini harus mempertahankan keempat properti tersebut sebelum karakteristik performanya menjadi relevan.