Kebocoran Qwen 4: PR Host-Staging SGLang Menunjukkan Bagaimana Tabel PLE 47,7 GiB Muat di Satu GPU

Angka yang akan menentukan apakah Qwen 4 adalah model yang dapat Anda layani sendiri bukanlah jumlah parameternya. Angka itu adalah 47,7 GiB — ukuran tabel embedding n-gram yang menyertai arsitektur Qwen4, terpisah dari bobot, dan harus berada di suatu tempat saat model melakukan decoding. Sebuah pull request yang dibuka di repositori SGLang pada 18 September 2026, berjudul [Qwen4-Exp] Tambahkan host staging untuk PLE berbasis file, merupakan upaya untuk menghentikan tabel itu menentukan berapa banyak RAM yang dibutuhkan sebuah mesin sebelum dapat menjalankannya sama sekali. Qwen 4 masih belum dirilis: tidak ada model card, tidak ada bobot, tidak ada entri katalog, tidak ada tanggal. Satu-satunya model yang sudah dirilis yang menginstansiasi arsitektur ini adalah Qwen3.8-Flash-Next, pratinjau berbobot terbuka yang diterbitkan pada 26 Agustus 2026, yang konfigurasinya mendeklarasikan model_type=qwen4_exp — string yang sama yang memberi nama pull request tersebut. Saudara produksinya Qwen3.8-Flash adalah versi yang benar-benar dapat dijangkau oleh pemanggil API hari ini. Semua hal dalam artikel ini tentang Qwen 4 adalah inferensi dari pratinjau tersebut dan dari kode engine; pull request-nya masih terbuka dan belum digabungkan, jadi bacalah semuanya sebagai sinyal, bukan kemampuan yang sudah dirilis.

Apa sebenarnya sinyal itu

Pull request sgl-project/sglang#40235 bukanlah sebuah peluncuran dan belum di-merge. Ia berada pada satu commit, dibuka oleh kontributor Dev-Jahn, yang menggabungkan cabang bernama task/ple-host-staged ke jalur utama SGLang. Sembilan code owner telah diminta untuk meninjau dan semuanya tampil sebagai menunggu, jadi setidaknya satu tinjauan yang menyetujui memisahkan ini dari main. Tiga job CI — uji PR dasar, uji PR tambahan, dan jalannya AMD ROCm — gagal pada commit terbuka tersebut. Itulah kondisi normal dari perubahan mesin besar yang sedang berjalan, dan itu pula sebabnya bagian menarik dari PR ini bukanlah apakah ia akan masuk, melainkan apa yang harus diukur oleh penulisnya untuk memperjuangkannya. Deskripsinya memuat sekitar 1.400 baris tambahan termasuk pengujian, dan tabel benchmark yang merupakan data publik paling konkret yang pernah diterbitkan siapa pun tentang menjalankan arsitektur ini pada satu GPU.

Mengapa tabel adalah seluruh ceritanya

Embedding per Lapisan adalah keanehan struktural generasi ini. Jika model normal menempatkan satu embedding token di bagian depan, desain Qwen4 membawa tabel n-gram besar — bigram dan trigram, yang di-hash ke dalam kosakata yang jauh lebih besar daripada kosakata tokenizer — dan menyuplai lookup embedding per lapisan darinya di seluruh stack. Materi pratinjau Alibaba sendiri menggambarkan komponen n-gram sebagai puluhan miliar parameter di atas badan MoE berparameter 125B; pembedahan komunitas terhadap checkpoint yang dirilis menaksir file tabel sebesar 47,7 GiB. Angka-angka tersebut berasal dari sumber vendor dan komunitas, bukan dari reproduksi independen, dan hubungan persis antara tabel pratinjau dan apa pun yang dirilis Qwen 4 tidak diketahui.

Yang tidak diragukan lagi adalah konsekuensi teknisnya. Tabel samping 47,7 GiB yang harus diakses pada setiap langkah decode bukanlah sesuatu yang bisa Anda dorong begitu saja ke sudut VRAM. Pada kartu 96 GB, ia bersaing langsung dengan KV cache; pada kartu yang lebih kecil, ia sama sekali tidak muat. Itulah sebabnya SGLang, yang menyediakan dukungan hari-0 untuk pratinjau pada akhir Agustus, telah menghabiskan tiga minggu berikutnya untuk menghasilkan satu pull request setelah pull request lainnya tentang satu struktur data ini alih-alih tentang model di sekitarnya.

Apa yang rusak sebelum PR ini

SGLang sudah memiliki dua cara untuk menahan tabel, dan keduanya memiliki batas yang keras.

• Pinned menyimpan seluruh tabel di RAM host dan membacanya dari sana. Cara ini berfungsi, cepat, dan membuat kebutuhan memori host menjadi mutlak — tidak ada versi yang lebih kecil darinya.

• Berbasis file, yang ditambahkan sebelumnya dalam pull request terpisah, menyimpan tabel dalam file sparse dan memungkinkan kernel gather membaca pemetaan tersebut secara langsung, sehingga page cache sistem operasi yang menentukan berapa banyak bagiannya yang residen. Persoalannya bersifat perangkat keras: jalur baca langsung itu mengharuskan GPU melaporkan cudaDevAttrPageableMemoryAccessUsesHostPageTables — kemampuan yang dalam teks PR itu sendiri disebut sebagai "kelas GB10". Pada GPU yang tidak memilikinya, backend file langsung ditolak dan pinned menjadi satu-satunya opsi yang tersisa.

Celah yang ditimbulkan bukanlah hal teoretis. Laporan terpisah yang diajukan terhadap jalur kode yang sama mendokumentasikan seorang pengguna pada dua RTX 3090 yang bagian tabel per-rank-nya mencapai 23,84 GiB dibandingkan 23,56 GiB memori yang dapat digunakan — kurang 0,28 GiB, dengan 188 GiB RAM host yang tersisa bebas. Dalam konfigurasi itu, backend file ditolak oleh pemeriksaan perangkat keras dan flag CPU-offload biasa memunculkan error saat digabungkan dengan flag PLE offload. Kekurangan tiga ratus megabita padahal masih ada seratus delapan puluh gigabita cadangan adalah persis bentuk masalah yang ingin dihilangkan oleh pull request ini.

Apa perubahan staging host?

Mekanisme yang ditambahkan PR ini adalah lapisan penahapan antara file dan perangkat. Alih-alih meminta GPU melakukan dereferensi halaman host, komponen di sisi CPU membaca baris yang dibutuhkan melalui pemetaan yang sudah ada milik loader dan menyarankan kernel untuk menarik halaman-halaman tersebut lebih awal; variabel lingkungan, SGLANG_QWEN4_PLE_FILE_PREFETCH, menonaktifkan saran tersebut jika Anda ingin mengukur tanpanya. Setiap lapisan PLE kemudian mendapatkan dua buffer pinned berisi 8.192 baris — sekitar 1,25 MiB masing-masing pada FP8 — dan satu worker. Baris dikumpulkan ke satu buffer sementara buffer lainnya sedang disalin ke perangkat, sehingga pengumpulan dan transfer tumpang tindih alih-alih diserialkan. Pengenal N-gram di-hash di host, bukan di perangkat. Pemutaran ulang graf mendapatkan panggilan persiapan sebelum setiap pemutaran ulang, dan thread peluncur menunggu langkah sebelumnya.

Detail terakhir itu adalah biayanya, dan PR menyatakannya secara gamblang: kira-kira 0,5 hingga 1 milidetik yang ditambahkan per langkah dekode dibandingkan jalur pinned. Selebihnya adalah imbalannya. Diukur pada satu RTX PRO 6000 Blackwell dengan 96 GB, host AMD EPYC dengan RAM 377 GiB, CUDA 13.2, menggunakan checkpoint FP8 dan NVFP4 publik dari Qwen3.8-Flash-Next:

• Cache halaman host, FP8 TP4/EP4 — 71 GB dipin dan tanpa batas, dibandingkan dengan 49 GB pada batas 64 GB, 15 GB pada 32 GB, dan 6 GB pada batas 24 GB

• Latensi decode, run yang sama — 8,62 ms per token pada konkurensi 1 yang dipin, dibandingkan dengan 9,16 / 9,20 / 9,12 ms pada tiga run file yang dibatasi

• Konkurensi 16 — 16,54 ms pinned versus 17,62 / 17,85 / 17,37 ms capped, yaitu dari 893 token per detik turun menjadi 827–840

• Throughput prefill — 620 token per detik pada 8k yang dipin versus 624 / 630 / 631 yang dibatasi; pada 32k, 1.347 versus 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB pinned dibandingkan 24 GB dengan backend file pada batas maksimum 32 GB, yaitu 8,87 ms dibandingkan 9,18 ms

• NVFP4 GPU Tunggal — 69 GB pinned versus 51 GB pada batas 64 GB, pada 6,44 ms versus 6,73 ms

• Alternatif yang berhasil dikalahkannya — membaca file yang sama melalui manajemen memori host pada GPU tersebut menghasilkan 10,8 ms pada konkurensi 1 dan 46,5 ms pada konkurensi 16, yang menurut PR tersebut setara 2,8× latensi pinned pada konkurensi itu

Sisi akurasi dilaporkan bersih. Keluaran greedy deterministik atas delapan prompt berisi 256 token identik secara token antara jalur pinned dan jalur file pada FP8 TP4, dan GSM8K menghasilkan 97,6% untuk pinned berbanding 98,0% untuk file pada batas 64 GB — selisih enam pertanyaan yang penulisnya atribusikan ke variasi antar-eksekusi, bukan ke jalur offload. Semua angka ini adalah milik penulis pull request itu sendiri, diukur sekali, di satu mesin, dan belum ada yang mereproduksinya.

Biaya yang diakui oleh PR

Pembacaan yang adil atas pull request ini mencakup apa yang ditolaknya untuk dilakukan. Beberapa mode eksekusi ditolak pada waktu konstruksi alih-alih diturunkan secara diam-diam, dan setiap penolakan menyebut backend yang dipatok sebagai fallback: prefill CUDA graphs, attention paralel-data, jalur multiplexing prefill-decode, tumpang tindih dua batch, DLLM decode graphs, dan compact ragged verify graphs semuanya tidak disertakan. Yang tak kalah penting, ini tidak menambahkan flag baru maupun switch baru yang dihadapi pengguna — jalur staging adalah apa yang dilakukan file backend pada perangkat keras yang sebelumnya sama sekali tidak dapat menggunakannya. Dan uji akurasi membawa catatan yang disampaikan sendiri oleh penulis: uji dengan batas tidak pernah memuat seluruh tabel, karena tabelnya 47,7 GiB dan batasnya serendah 24 GB, sehingga beban kerja dengan pola akses yang benar-benar datar dan tak terduga di seluruh tabel bukanlah yang diukur.

Mengapa ini penting khususnya untuk Qwen 4

Singkirkan detail mesinnya, dan polanya menjadi jelas. Alibaba merilis pratinjau arsitektur pada 26 Agustus dengan instruksi bagi komunitas open-source untuk menyiapkan runtime, kuantisasi, dan mesin inferensi sebelum keluarga lengkapnya hadir. SGLang melakukannya, lalu menghabiskan tiga minggu mengajukan pull request tentang satu komponen yang membuat arsitektur ini sulit untuk di-deploy. Jika dibaca sebagai ramalan, itu adalah pernyataan tentang apa yang akan dibutuhkan Qwen 4 dari perangkat keras Anda, bukan tentang apa yang bisa dilakukannya di benchmark.

Ini juga mempertajam pertanyaan soal garis waktu. Qwen 4 belum dirilis, dan spekulasi September tentangnya mengarah ke Apsara Conference Alibaba pada 22–24 September di Hangzhou — tempat generasi Qwen sebelumnya diumumkan. Tidak ada satu pun tentang itu yang terkonfirmasi, dan pola dari siklus pratinjau terakhir adalah bahwa pratinjau arsitektur mendahului keluarga lengkapnya selama beberapa bulan, bukan beberapa minggu. Pull request yang dibuka tiga hari sebelum konferensi itu hanya memberi petunjuk dan tidak lebih dari itu.

Ringkasan jujur tentang posisi pembaca setelah semua ini: Qwen 4 tidak ada, Qwen3.8-Flash-Next ada, dan yang kedua memberi tahu Anda berapa biaya yang akan Anda keluarkan untuk menjalankan yang pertama. Jika tabel 47.7 GiB terus menyusut dalam jejak efektifnya — dan tiga minggu pull request menunjukkan bahwa hal itu sedang digarap dengan gencar — maka ambang deployment untuk keluarga Qwen 4 lebih rendah daripada yang disiratkan oleh minggu peluncuran preview.

Apa yang sebenarnya bisa Anda lakukan dengan ini hari ini

Tidak ada apa pun dalam pull request ini yang tersedia di main, dan model yang menjadi targetnya bukanlah sesuatu yang dapat Anda panggil melalui API. Checkpoint Qwen3.8-Flash-Next dengan bobot terbuka adalah kisah self-hosting: Anda menarik bobotnya, Anda menyajikannya sendiri, dan jalur PLE berbasis file adalah yang sedang Anda baca. Model ini tidak dirutekan di sini. Yang dirutekan adalah varian produksi — Qwen3.8-Flash, dapat diakses sebagai qwen/qwen3.8-flash dengan $0.15 per juta token input dan $0.47 per juta output, dengan konteks 1M token serta input teks, gambar, dan video — dan yang lebih besar Qwen3.8-Max dengan $2.00 dan $6.00.

Perbedaan itulah yang berguna bagi pembaca yang sedang memutuskan apa yang harus dilakukan minggu ini. Preview adalah riset yang Anda jalankan sendiri; varian yang disajikan adalah jalur produksi dari arsitektur yang sama, dan jaraknya hanya satu endpoint.markup 0%, sehingga perubahan harga vendor pada endpoint tersebut muncul di hari yang sama alih-alih pada siklus penagihan berikutnya, dan setiap model pada key itu dapat diakses melalui satu base URL yang kompatibel dengan OpenAI, bukan melalui kontrak, SDK, dan kredensial terpisah untuk tiap vendor. Untuk arsitektur yang masih sesingkat ini — di mana pekerjaan mesinnya masih dirilis setiap minggu dan roadmap-nya belum dipublikasikan — failover otomatis antarpenyedia adalah cara praktis untuk bergantung pada varian yang disajikan tanpa mempertaruhkan jalur produksi pada uptime satu penyedia saja. Semua itu tentang model yang bisa Anda panggil hari ini. Itu tidak mengatakan apa pun tentang Qwen 4, yang bukan salah satunya.

Apa yang masih belum kita ketahui

Apakah Qwen 4 akan merilis tabel yang sama pada ukuran yang sama. Apakah pull request itu di-merge sama sekali — ada tiga run CI yang gagal dan belum ada ulasan. Apakah penalti 0,5 hingga 1 milidetik per langkah tetap berlaku di luar konfigurasi konkurensi rendah milik penulisnya. Dan apakah Alibaba mengatakan sesuatu di Apsara pada 22 September. Berdasarkan bukti saat ini, hal teraman yang bisa disimpulkan tentang Qwen 4 bukanlah apa skornya, melainkan seberapa banyak perangkat yang dibangun industri hanya untuk membuatnya muat — yang itu sendiri merupakan hal berguna untuk diketahui sebelum model tersebut punya nama di katalog mana pun.