Prompt panjang dapat menempati akselerator selama interval scheduling yang jauh lebih besar dibanding satu iterasi decode. Saat serving engine mencampur prefill baru dengan request yang sudah menghasilkan token, perbedaan ini dapat terlihat sebagai jarak waktu antartoken output yang tidak teratur. Modelnya tidak berubah; interferensi muncul dari cara dua fase inferensi yang berbeda berbagi waktu eksekusi.

Prefill memproses prompt dan membentuk key-value state yang dibutuhkan causal attention berikutnya. Decode kemudian memperpanjang sequence secara autoregresif, umumnya satu token baru per request aktif pada setiap iterasi. Kedua fase memberi tekanan yang berbeda pada hardware, sehingga memperlakukannya sebagai unit scheduling yang setara dapat menimbulkan jeda yang sebenarnya dapat dibatasi.

Chunked prefill mengubah unit scheduling. Alih-alih menerima seluruh prompt panjang sebagai satu prefill yang tidak dapat dipotong, scheduler memproses segmen prefix dengan ukuran terbatas, memberi kesempatan lagi kepada decode aktif untuk berjalan, lalu melanjutkan segmen berikutnya.

Prefill dan decode memberi tekanan scheduling yang berbeda

Untuk prompt berisi (P) token, prefill mengevaluasi token-token prompt sebelum generasi token demi token berjalan normal. Di dalam setiap layer transformer, causal attention pada suatu posisi prompt dapat memakai posisi prompt sebelumnya, lalu tensor key-value yang dihasilkan dipertahankan untuk posisi berikutnya.

Decode dimulai dari state tersebut. Pada satu iterasi decode, setiap sequence aktif menyumbang sedikit kerja token baru sementara attention membaca cache konteks yang sudah ada. Keseimbangan compute dan memory secara tepat bergantung pada arsitektur model, bentuk batch, implementasi kernel, paralelisme, precision, dan akselerator. Meski demikian, sistem serving umumnya memperlihatkan perbedaan yang berguna: pemrosesan prompt membuka kerja paralel dalam jumlah besar, sedangkan decode steady-state berulang kali menangani langkah inkremental yang sempit.

Perbedaan ini menjadi relevan saat kedua fase menempati device yang sama. Scheduler yang menjalankan prefill sangat panjang dalam satu giliran dapat menunda request decode yang sebelumnya mengeluarkan token pada interval pendek.

Gejala yang terlihat tidak harus berupa throughput total yang buruk. Sistem dapat memproses banyak token per detik tetapi tetap memberikan token secara tidak rata pada satu request tertentu.

Prefill besar dapat berubah menjadi jeda decode

Anggap request A sudah berada pada fase decode dan request baru B datang dengan prompt panjang.

Schedule kasar dapat terlihat seperti berikut:

waktu ------------------------------------------------------->

A decode | A decode |       B full prefill       | A decode

Selama prefill B, request A tidak mendapat giliran decode. Jika interval prefill besar dibanding waktu iterasi decode normal, jarak antara token keluaran A ikut membesar.

Ini merupakan efek head-of-line pada level scheduler. A dan B tidak perlu berbagi teks, dan masalah ini berbeda dari tekanan kapasitas KV cache. Memori cache dapat cukup untuk keduanya sementara waktu eksekusi tetap dikuasai operasi prefill besar.

Masalah ini juga berbeda dari static batching biasa. Serving kontinu dapat menerima dan menyelesaikan request dari waktu ke waktu, tetapi prompt yang baru masuk tetap dapat membuat iterasi panjang jika kerja prompt tidak dibatasi.

Chunking membatasi kerja prefill yang masuk sekaligus

Dengan chunked prefill, request B dibagi menjadi rentang token yang berurutan:

prompt B:
[ chunk 1 ][ chunk 2 ][ chunk 3 ][ chunk 4 ]

Scheduler kemudian dapat menyisipkan chunk tersebut di antara kerja decode aktif:

waktu ---------------------------------------------------------------->

A decode | B chunk 1 | A decode | B chunk 2 | A decode | B chunk 3

Sifat utamanya adalah interval scheduling tidak lagi harus mengikuti panjang seluruh prompt. Interval mengikuti chunk yang diterima ditambah kerja lain yang ditempatkan engine di batch yang sama.

Scheduler produksi tidak harus bergantian persis seperti diagram. Scheduler dapat menggabungkan satu chunk prefill dengan beberapa token decode dalam mixed batch, menerapkan token budget, memprioritaskan prefill yang menunggu, menyisihkan kapasitas untuk decode, atau memakai queue terpisah. Chunking menyediakan unit scheduling yang lebih halus; policy tetap menentukan unit mana yang berjalan berikutnya.

Batas chunk harus mempertahankan causal state

Membagi prefill bukan berarti mengevaluasi setiap chunk sebagai sequence independen. Chunk berikutnya membutuhkan causal state yang dihasilkan chunk sebelumnya.

Untuk sequence token prompt

[ x_1, x_2, \ldots, x_P ]

anggap chunk pertama berakhir pada token (c). Setelah chunk tersebut diproses, server mempertahankan tensor key-value untuk posisi (1) sampai (c). Chunk berikutnya memproses posisi (c+1) dan seterusnya dengan akses ke prefix state tersebut.

Alur sederhananya:

chunk 1: token 1..c
         -> KV state untuk 1..c

chunk 2: token c+1..2c
         + KV state untuk 1..c
         -> KV state untuk 1..2c

chunk 3: token 2c+1..
         + KV state sebelumnya
         -> KV state diperpanjang

Penanganan posisi juga harus tetap konsisten dengan sequence tanpa chunk. Token pada chunk kedua tetap berada pada posisi aslinya; posisinya tidak dimulai lagi dari nol.

Dengan penanganan cache dan posisi yang benar, chunking merupakan transformasi serving, bukan perubahan pada struktur dependensi kausal yang dimaksud. Hasil numerik masih dapat bergantung pada detail implementasi seperti pilihan kernel, precision aritmetika, dan urutan batching, sehingga identitas bit demi bit tidak layak diasumsikan kecuali serving stack mendokumentasikannya.

Ukuran chunk menentukan granularitas latency

Ukuran chunk bukan sekadar pengaturan memori. Nilai ini mengendalikan banyaknya kerja prefill yang dapat ditempatkan scheduler di antara kesempatan bagi request lain untuk berjalan.

Chunk lebih besar cenderung mengurangi overhead scheduling dan membuka lebih banyak kerja prompt per operasi. Namun, chunk tersebut juga dapat membuat interval lebih panjang sebelum decode aktif dijadwalkan kembali.

Chunk lebih kecil menciptakan lebih banyak titik interupsi. Ini dapat mengecilkan jeda terpanjang akibat prefill, tetapi pada beberapa stack dapat menambah aktivitas scheduler, kernel launch atau penanganan metadata, serta menghasilkan bentuk eksekusi yang kurang sesuai.

Ukuran yang tepat karena itu bergantung pada target konkret, misalnya batas inter-token latency, time to first token, throughput agregat, atau kombinasi service-level constraint. Tidak ada ukuran chunk yang unggul untuk semua model, hardware, dan workload.

Token budget membuat policy lebih eksplisit

Salah satu formulasi praktis adalah memberi setiap iterasi scheduling token budget (B). Request decode aktif memakai sebagian budget, lalu kerja prefill memakai sisanya.

Contoh:

iteration token budget: 2048
active decode tokens:    192
remaining budget:       1856

next prefill chunk <= 1856 tokens

Serving engine nyata dapat menghitung kerja dengan cara berbeda, dan satu token bukan unit biaya konstan untuk semua konteks. Biaya attention berubah mengikuti panjang sequence, sedangkan eksekusi terdistribusi menambahkan efek komunikasi. Meski begitu, budget membuat satu batas utama menjadi eksplisit: prompt yang baru datang tidak dapat memasukkan kerja tanpa batas ke satu giliran scheduling.

Scheduler juga dapat membatasi bagian prefill di bawah sisa total budget jika latency decode yang lebih ketat dibutuhkan.

Time to first token dan inter-token latency dapat bergerak berlawanan

Chunking mengubah lebih dari sekadar kelancaran decode.

Prompt yang menunggu belum dapat menghasilkan token pertama sampai kerja prefill yang dibutuhkan selesai. Jika chunk-nya berulang kali mengalah kepada traffic decode yang sudah aktif, time to first token dapat meningkat dibanding policy yang langsung menjalankan seluruh prompt.

Pada saat yang sama, request yang sudah aktif dapat memperoleh jarak antartoken yang lebih kecil karena tidak ada satu prefill yang menempati device terlalu lama.

Kondisi ini menimbulkan tegangan scheduling antara:

  • latency penerimaan prompt untuk request baru;
  • keteraturan pengiriman token untuk request aktif;
  • utilisasi akselerator secara agregat;
  • fairness queue pada campuran panjang prompt.

Policy serving perlu menyatakan metrik latency mana yang dijaga. Mengoptimalkan throughput request saja dapat menutupi perilaku antartoken yang buruk, sedangkan terlalu memprioritaskan keteraturan decode dapat membuat prompt panjang menunggu terlalu lama.

Prompt panjang dan pendek perlu dinilai secara berbeda

Efeknya bergantung pada workload. Jika prompt pendek, full prefill mungkin sudah masuk dengan nyaman ke dalam latency budget, sehingga chunking dapat menambah kompleksitas tanpa manfaat berarti.

Prompt panjang membuat asimetri scheduling lebih terlihat. Request dengan retrieved context besar, state percakapan panjang, atau input kode berukuran besar dapat membawa kerja prefill jauh lebih banyak dibanding request interaktif yang pendek.

Workload campuran sangat sensitif karena satu queue berisi request dengan biaya prompt yang sangat berbeda. Batas berdasarkan jumlah request tidak menangkap perbedaan tersebut. Dua request dalam queue dapat mewakili volume token yang sangat jauh berbeda.

Prompt-token budget, estimasi biaya eksekusi, atau phase-aware scheduling menyediakan permukaan kontrol yang lebih langsung daripada sekadar menghitung request.

Chunking berbeda dari pemisahan prefill dan decode

Desain lain menempatkan prefill dan decode pada worker yang berbeda. Cara itu menghapus interferensi langsung pada waktu device di antara kedua fase, tetapi memperkenalkan batas baru: KV state yang dihasilkan saat prefill harus tersedia bagi worker decode.

Chunked prefill mempertahankan kedua fase pada resource serving yang sama dan mengurangi interferensi melalui granularitas scheduling. Pemisahan fase mengubah penempatan resource dan dapat memungkinkan provisioning terpisah untuk pemrosesan prompt serta generasi.

Kedua pendekatan menangani tekanan yang berkaitan pada level arsitektur berbeda. Keduanya juga dapat membawa bottleneck berbeda: chunking tetap menghadapi contention lokal, sedangkan pemisahan fase harus memperhitungkan transfer state, topologi jaringan, keseimbangan queue, dan kapasitas pada kedua pool worker.

Ukur distribusi jeda, bukan hanya throughput rata-rata

Benchmark serving yang hanya melaporkan token per detik tidak menangkap perilaku yang hendak dikendalikan oleh chunking. Paling tidak, pengujian mixed-phase perlu mengamati time to first token dan distribusi waktu antartoken saat prompt panjang masuk ke sistem.

Skenario stress yang berguna mempertahankan beberapa request pada fase decode, lalu memasukkan prompt dengan rentang panjang berbeda. Jika scheduler menerima full prefill, prompt panjang dapat muncul sebagai lonjakan pada jarak token. Jika chunking bekerja sesuai policy, lonjakan itu seharusnya dibatasi oleh aturan scheduling yang dipilih, bukan oleh ukuran seluruh prompt.

Batas waktu yang tepat bersifat implementation-specific karena ukuran chunk, batching, durasi kernel, queue policy, dan eksekusi paralel semuanya berkontribusi pada wall-clock latency.

Chunked prefill karena itu paling tepat dipandang sebagai kontrol atas granularitas scheduling. Mekanisme ini tidak menghapus komputasi prompt, tidak mengurangi causal state yang dibutuhkan model, dan tidak menjamin peningkatan throughput universal. Mekanisme ini memberi serving layer cara agar satu prompt panjang tidak berubah menjadi satu interupsi yang sama panjangnya bagi semua request yang sudah berada pada fase decode.

Kecerdasan Buatan Model Bahasa Inferensi Serving LLM Scheduling