Serving autoregresif tidak membuat semua request selesai pada titik yang sama. Sebuah sequence dapat menghasilkan token akhir setelah beberapa langkah decode, sedangkan sequence lain masih aktif hingga ratusan langkah. Jika engine mempertahankan batch request awal sampai seluruh anggotanya selesai, sequence yang sudah berakhir meninggalkan kapasitas eksekusi yang tidak terisi di belakang sequence yang lebih panjang.
Scheduling per iterasi memindahkan batas keputusan ke bagian yang lebih kecil. Request tidak lagi menjadi satu-satunya unit scheduling yang tidak dapat dipecah. Setelah satu iterasi model, kontrol kembali ke scheduler. Sequence yang selesai dapat keluar, pekerjaan yang menunggu dapat masuk, dan iterasi berikutnya dapat memakai kumpulan sequence aktif yang berbeda.
Batch request dapat menyusut selama generasi
Empat request yang masuk bersamaan dapat berubah seperti ini:
iterasi 1: A B C D
iterasi 2: A B C D
iterasi 3: A B D
iterasi 4: A D
iterasi 5: DPada kebijakan berbasis request yang menahan batch sampai D selesai, posisi kosong belum tentu dapat diisi oleh request dari antrean. Decode tetap berjalan pada accelerator, tetapi lebar batch yang benar-benar membawa pekerjaan berguna terus turun ketika sequence pendek selesai.
Kondisi ini berasal dari sifat generasi autoregresif. Panjang output bergantung pada data, dan terminasi dapat terjadi pada iterasi berbeda meskipun request masuk bersamaan. Batch tetap akhirnya mengikat penerimaan pekerjaan baru pada anggota yang bertahan paling lama.
Scheduling per iterasi memutus ikatan tersebut:
iterasi 1: A B C D
iterasi 2: A B C D
iterasi 3: A B E D
iterasi 4: A F E D
iterasi 5: G F E DHuruf hanya menunjukkan keanggotaan batch. Scheduler produksi tetap harus memperhitungkan anggaran token, batas jumlah sequence, kapasitas KV cache, prioritas, pekerjaan prefill, serta batas eksekusi yang spesifik pada implementasi.
Unit scheduling berubah, dependensi autoregresif tetap ada
Rescheduling setelah satu iterasi tidak membuat sebuah sequence menghasilkan token masa depan secara paralel. Token decode berikutnya tetap bergantung pada state sequence yang dibentuk oleh token sebelumnya.
Perubahannya terjadi di antara request. Pada batas iterasi, server memiliki sekumpulan sequence yang siap menerima pekerjaan model berikutnya. Scheduler dapat memilih batch baru dari kumpulan tersebut tanpa mempertahankan keanggotaan dari keputusan admission sebelumnya.
Dua bentuk concurrency ini berbeda:
di dalam satu sequence:
token t -> token t+1 -> token t+2
di antara sequence:
iterasi k = {A_k, B_k, C_k, ...}
iterasi k+1 = {A_k+1, D_k+1, E_k+1, ...}Kumpulan pada iterasi berikutnya dapat berubah walaupun setiap sequence tetap autoregresif.
KV state membuat penggantian praktis sekaligus membatasi admission
Sequence yang masih berjalan tidak semestinya memproses ulang seluruh teksnya pada setiap iterasi karena pendekatan itu membuang sebagian besar manfaat incremental decoding. Engine serving menyimpan state key/value dari token sebelumnya agar langkah decode berikutnya dapat melanjutkan sequence dari state cache.
State tersebut juga menambahkan dimensi memori pada scheduling. Menerima request dari antrean bukan hanya soal tersedianya slot batch. Prompt dan token generasi berikutnya membutuhkan kapasitas KV cache, sedangkan sequence aktif memakai cache lebih banyak saat jumlah tokennya bertambah.
Scheduler dapat memiliki ruang komputasi untuk sequence tambahan tetapi tidak memiliki kapasitas cache yang aman. Sebaliknya, selesainya sebuah sequence dapat melepaskan posisi scheduling sekaligus alokasi cache terkait.
Mekanisme alokasi persisnya bergantung pada implementasi. Cache kontigu, paged cache, kebijakan eviction, recomputation, dan prefix reuse memiliki biaya yang berbeda. Scheduling per iterasi menyediakan titik keputusan yang lebih rapat; mekanisme ini tidak menentukan satu kebijakan memori KV yang berlaku universal.
Prefill dan decode membawa beban iterasi yang berbeda
Request baru umumnya dimulai dengan pemrosesan prompt, sedangkan request yang sudah berjalan mungkin hanya membutuhkan token decode berikutnya. Jumlah token dan karakteristik eksekusinya berbeda.
Scheduler yang menerima request baru di antara iterasi decode perlu menentukan cara pekerjaan prompt berbagi iterasi dengan generasi aktif. Sebagian sistem memisahkan fase, sebagian mendukung mixed atau selective batching, dan sebagian memecah prefill panjang menjadi beberapa chunk.
Karena itu, “langsung mengganti request yang selesai” adalah abstraksi, bukan jaminan bahwa request apa pun dari antrean dapat masuk tanpa biaya. Batch berikutnya tetap harus memenuhi anggaran token dan kontrak eksekusi engine.
Konfigurasi serving modern mengekspos batas ini secara eksplisit. vLLM, misalnya, memiliki batas jumlah token dan sequence yang dapat diproses dalam satu iterasi. Nilai tersebut merupakan konfigurasi implementasi, bukan properti arsitektur Transformer.
Batas iterasi membuka ruang kebijakan latency dan throughput
Rescheduling yang sering memberi engine lebih banyak kesempatan untuk menerima pekerjaan, tetapi kebijakan scheduler tetap menentukan pekerjaan mana yang mendapat kesempatan tersebut.
Admission first-come-first-served dapat mengikuti urutan antrean. Priority scheduling dapat mendahulukan request tertentu. Anggaran token dapat membatasi prefill besar. Tekanan cache dapat menahan admission meskipun sebuah request sudah menunggu lebih lama.
Scheduling per iterasi karena itu tidak identik dengan jaminan fairness atau latency tertentu. Mekanisme ini mengubah granularitas tempat kebijakan dapat bekerja. Disiplin antrean, perhitungan resource, dan aturan preemption tetap merupakan keputusan terpisah.
Mekanisme yang diperkenalkan oleh sistem seperti Orca lebih sempit: scheduling pada granularitas iterasi model memungkinkan keanggotaan batch mengikuti perubahan state request, alih-alih tetap sama sepanjang umur batch awal.
Keanggotaan dinamis adalah invariant utama
Properti pentingnya bukan ukuran batch tertentu. Selesainya satu sequence tidak harus membuat kapasitas bekasnya tetap terikat pada sequence panjang lain yang tidak terkait.
Pada setiap batas scheduling, engine dapat menyelaraskan tiga kumpulan yang terus berubah:
sequence berjalan
sequence selesai
sequence menungguEngine lalu membentuk batch eksekusi berikutnya sesuai batas komputasi dan memori. Panjang output yang bervariasi berubah dari persoalan okupansi batch tetap menjadi keputusan alokasi resource yang berulang.
Batasnya tetap konkret: scheduler hanya dapat bereaksi saat execution engine mengembalikan kontrol. Scheduling per iterasi menempatkan titik tersebut di antara iterasi model, sehingga server LLM dapat membentuk ulang batch seiring proses generasi.