Bocoran Qwen 4: SGLang Memecah Prefill Qwen4Exp untuk TTFT 18% Lebih Cepat dan Mengembalikan Satu GiB per GPU

Sebuah pull request yang dibuka di repositori SGLang pada 03.47 UTC pagi ini, 2026-10-08, menjanjikan sesuatu yang belum pernah dihasilkan oleh pengumuman Qwen 4 mana pun hingga saat ini: sebuah angka. Judulnya feat(qwen4-exp): aktifkan paralelisme sekuens LayerNorm untuk GR dan PLE, dan pada empat GPU H20 yang menjalankan open-weight Qwen3.8-Flash-Next checkpoint dalam FP8, penulisnya melaporkan peningkatan time-to-first-token sebesar 17,7–18,4% pada input 32K dan 14,6–14,7% pada input 235K, sekitar satu gigabyte memori puncak yang dikembalikan per GPU, dan throughput input hingga 22% lebih tinggi. Qwen 4 itu sendiri — keluarga yang dinamai vendor tetapi tidak diluncurkan pada konferensi Apsara di Hangzhou pada 2026-09-22 — masih belum dirilis, tanpa bobot, tanpa pengenal, dan tanpa harga. Satu-satunya model yang menginstansiasi arsitektur Qwen4Exp saat ini adalah Qwen3.8-Flash-Next, yang dipublikasikan pada 2026-08-26, dan saudara terkelolanya Qwen3.8-Flash adalah versi yang benar-benar dapat dijangkau oleh pemanggil API. Jadi bacalah yang berikut ini sebagai apa adanya: pengukuran berpasangan dari seorang insinyur, yang dilampirkan pada pull request terbuka, draf, dan belum digabungkan, tentang lingkup penyajian keluarga model yang belum ada.

Pencarian sumber lebih dulu, karena ini adalah artikel bocoran dan perbedaan itu benar-benar penting. Sinyalnya adalah sgl-project/sglang#43048, dibuka 2026-10-08 pukul 03:47 UTC oleh akun GitHub shiyang814-cpu, terakhir disentuh pukul 03:55 UTC, dan masih ditandai draf, tanpa tinjauan persetujuan yang tercatat dan tanpa merge. Ini mengubah enam file — dua file pengujian, file model Qwen4Exp, modul LayerNorm-SP, factory batas lapisan dan hook grup argumen — dengan +345 dan −50 baris. Setiap angka performa di bawah ini berasal dari deskripsi PR, merupakan pengukuran OFF/ON berpasangan milik penulis sendiri, dan belum direproduksi oleh siapa pun. Tiga eksekusi CI pada revisi di ujung cabang ditandai gagal. Tidak ada apa pun di sini yang merupakan kapabilitas yang sudah dirilis.

Apa yang sebenarnya diubah oleh pull request

Paralelisme sekuens bukanlah perubahan model dan bukan pula kemampuan baru. Ini adalah pengaturan ulang tempat beberapa lapisan melakukan aritmetikanya. Silsilahnya kembali ke paralelisme sekuens gaya Megatron — trik dari arXiv:2205.05198 — dan SGLang sudah menyediakannya: docstring modul itu sendiri menjelaskan mekanisme yang digunakan ulang, bahwa di bawah paralelisme tensor murni suatu row-parallel all_reduce secara aljabar adalah reduce_scatter yang diikuti oleh all_gather. Karena kedua kolektif tersebut memindahkan byte yang persis sama dengan satu-satunya all_reduce yang mereka gantikan, memecah operasi dengan cara itu tidak memerlukan volume komunikasi tambahan sama sekali. Yang dibelinya adalah kebebasan untuk membiarkan wilayah normalisasi dan residual berjalan pada terbagi-sekuens aktivasi — setiap rank paralel tensor memegang satu-1/tp dari baris token — yang memangkas memori aktivasi transien yang perlu dipertahankan oleh prefill konteks panjang.

Apa yang dilakukan pull request khusus ini adalah memperluas jalur yang sudah ada itu dari arsitektur tempat jalur tersebut divalidasi ke arsitektur Qwen4Exp. Selama prefill, aktivasi Gated Residual dan Per-Layer Embedding tetap di-shard sepanjang dimensi token di seluruh grup TP. Sebelum attention, sebelum GDN, sebelum QSA, dan sebelum blok Mixture-of-Experts berjalan, baris token penuh di-all-gather kembali, komputasi tensor-paralel baris penuh yang sudah ada berjalan tanpa perubahan di balik fallback bersama, dan reduce-scatter kemudian menjumlahkan kontribusi parsial serta memulihkan shard setiap rank. Decode sama sekali tidak menyentuh jalur baru. Fitur ini diakses melalui opsi yang sudah ada — --enable-layernorm-sp — tanpa flag khusus Qwen4Exp, dan jika flag tersebut tidak ada, kode berperilaku persis seperti sebelumnya.

Mengapa Qwen4Exp adalah arsitektur yang membutuhkan ini

Alasan hal ini penting khususnya bagi Qwen4Exp, dan tidak sama pentingnya untuk setiap model, terletak pada desain arsitektur itu sendiri. Qwen3.8-Flash-Next menerapkan proyeksi Gated Residual pada semua baris token di setiap lapisan decoder — konfigurasi tersebut mendeklarasikan empat aliran residual dan rank bottleneck 320 di seluruh 48 lapisan — dan Per-Layer Embedding menambahkan proyeksi kedua yang direplikasi, baris token demi baris token, di atasnya. Dalam tensor parallelism, kedua operasi tersebut diduplikasi secara identik pada setiap rank, karena keduanya tidak memiliki matriks bobot ter-shard TP sendiri yang akan memaksa pemisahan. Sharding dimensi token keduanya menghilangkan pekerjaan yang direplikasi secara langsung, dan seperti yang dikatakan bagian motivasi PR, hal itu terjadi sambil mempertahankan tata letak tensor-parallel yang ada dan semantik reduksi dari attention, GDN/QSA dan MoE — itulah bagian yang membuat perubahan ini aman, bukan sekadar cerdik.

Ada baiknya dikatakan secara gamblang apa artinya itu bagi pembaca. Hal yang menarik dari PR ini bukanlah bahwa SGLang menjadi lebih cepat. Melainkan bahwa arsitektur Qwen4 membawa biaya per lapisan yang berskala dengan jumlah token alih-alih dengan jumlah parameter, dan biaya-biaya itulah yang sangat terasa pada prefill panjang. Itu adalah sidik jari desain, dan itulah jenis hal yang tidak pernah disebutkan oleh lembar spesifikasi.

Delta yang terukur

Benchmark penulis menetapkan satu konfigurasi dan mengalihkan flag tersebut: empat GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, tensor parallel 4 dan expert parallel 4, ukuran prefill berchunk 8192, backend prefill dan decode linear-attention FlashInfer, konfigurasi server yang sama untuk OFF dan ON, restart layanan bergantian OFF → ON → OFF → ON, serta input token tetap dengan permintaan warmup. Setiap angka di bawah ini berasal dari pengaturan tersebut dan belum diaudit:

• Masukan 32K, ukuran batch 1 — TTFT meningkat 17,72–18,36%, latensi end-to-end sekitar 16%, throughput masukan sekitar 20%

• Input 235K, ukuran batch 1 — TTFT meningkat 14,63–14,71%, latensi end-to-end sekitar 14%, throughput input sekitar 17%

• Input 32K, ukuran batch 4 — TTFT meningkat 18,74%, latensi end-to-end 18,14%, throughput input 22,14%

• Memori puncak — turun sekitar 1,0 GiB per GPU

• Dekode, ukuran batch 1 — waktu per token keluaran praktis tidak berubah

Baris terakhir adalah yang perlu dibaca dua kali, dan penulisnya terang-terangan soal alasannya: optimasi ini hanya diaktifkan untuk prefill, jadi decode aliran tunggal tidak mendapatkan apa pun darinya. Peningkatan waktu per token pada batch-4, jika memang muncul, mencerminkan berkurangnya penundaan penjadwalan akibat prefill panjang yang berjalan bersamaan, bukan karena kernel decode yang lebih cepat. Jika Anda berharap ini adalah kisah throughput, bukan — ini adalah kisah latensi ke token pertama dan memori, dan itulah dua kendala yang menentukan apakah permintaan 235K token dapat dilayani sama sekali.

Bug tata letak yang harus mereka perbaiki terlebih dahulu

Bagian paling informatif dari pull ini bukanlah tabel speedup. Bagian itu adalah bagian tentang tata letak baris fisik PLE, karena ini menunjukkan apa yang masih salah pada stack serving Qwen4Exp.

Per-Layer Embedding beroperasi pada bucket fisik CUDA-graph tetap, sementara hanya sebuah prefiks dari baris-baris di bucket tersebut yang mungkin berisi token nyata. Oleh karena itu, padding harus diterapkan sebelum urutan di-shard, bukan sesudahnya. Dalam chunk terakhir dari permintaan 235K token, angka penulis adalah 5.624 token yang diproses di dalam bucket fisik 8.192 baris pada TP 4, dan satu-satunya tata letak yang benar adalah rank 0 memegang 2.048 baris valid, rank 1 memegang 2.048 baris valid, rank 2 memegang 1.528 baris valid plus 520 baris padding, dan rank 3 memegang 2.048 baris padding. Melakukan sharding pada 5.624 baris yang diproses terlebih dahulu — implementasi yang jelas — menyisipkan padding di antara rentang valid yang berdekatan secara global dan merusak hasilnya. Penulis mencatat bahwa uji OFF/ON 235K nyata hanya menghasilkan output greedy 16-token yang identik setelah tata letak ini diperbaiki.

Itu detail kecil dengan implikasi besar. Jalur PLE di SGLang baru ditambahkan cukup belakangan sehingga bug pengurutan token seperti ini masih bisa terjadi, dan orang yang menemukannya sedang menulis ekstensi sequence-parallel. Dukungan serving day-zero untuk arsitektur ini belum selesai; dukungan itu sedang aktif dibangun, secara publik, oleh para kontributor, satu layout demi satu layout.

Apa yang harus Anda korbankan: batasan-batasannya

Sebuah flag yang hanya membantu sebagian deployment hanya berguna jika Anda tahu yang mana. PR tersebut menyatakan persyaratannya secara eksplisit, dan konfigurasi di luar persyaratan itu gagal saat validasi argumen alih-alih terdegradasi secara diam-diam:

• Ukuran paralel tensor harus lebih besar dari 1 — penerapan satu GPU tidak memberikan manfaat apa pun, karena tidak ada rank untuk di-shard

• Ukuran paralel expert harus sama dengan ukuran paralel tensor

• Ukuran paralel pipeline harus sama dengan 1

• Attention paralel data harus dinonaktifkan

• Decoding spekulatif harus dinonaktifkan

Kendala terakhir adalah kendala yang memiliki keputusan nyata di baliknya. Untuk model sparse yang mengaktifkan sekitar 6B parameter per token, dekode spekulatif adalah salah satu dari sedikit tuas yang mempercepat dekode, dan fitur ini secara eksplisit mematikan tuas itu dengan menukarnya dengan keunggulan prefill. Jika beban kerja Anda berupa prompt panjang dan output pendek — analisis dokumen dan basis kode, peringkasan video, konteks besar yang dibaca sekali — pertukarannya jelas menguntungkan. Jika beban kerja Anda adalah prompt pendek dan generasi panjang, Anda mengorbankan hal yang tadinya membantu Anda dan membeli angka yang tidak berlaku bagi Anda. Persyaratan expert-parallel sama dengan tensor-parallel adalah hal lain yang perlu diperhatikan: ini berarti geometri sharding MoE harus sejajar persis dengan geometri TP, yang menyingkirkan beberapa tata letak multi-node yang sebenarnya masuk akal.

Apa arti ini tentang linimasa Qwen 4

Baca diff dengan cara lain dan Anda mendapatkan sebuah kalender. Modul LayerNorm-SP milik SGLang di branch main saat ini membawa allowlist eksplisit arsitektur yang fiturnya telah divalidasi, dan pada saat tulisan ini dibuat allowlist tersebut berisi tepat satu entri, Qwen3ForCausalLM — setiap arsitektur lain ditolak saat konstruksi jika Anda meneruskan flag tersebut. Menambahkan Qwen4Exp ke jalur itu karena itu bukan sekadar penyesuaian pada abstraksi yang sudah matang; ini adalah pertama kalinya arsitektur Qwen4 dibawa ke optimasi yang usianya beberapa generasi lebih tua darinya.

Bandingkan itu dengan catatan publik, dan gambarannya menjadi koheren. Vendor mengumumkan pada 2026-09-22 bahwa Qwen 4 sedang dalam pelatihan dan menampilkan pratinjau empat nama tier — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus, dan Qwen 4 27B — tanpa spesifikasi yang dilampirkan pada satu pun dari mereka. Pratinjau berbobot terbuka yang berbagi arsitektur tersebut, Qwen3.8-Flash-Next, telah dapat diunduh sejak 2026-08-26. Apa yang terjadi dalam tiga minggu sejak itu persis seperti yang Anda perkirakan antara "sedang dilatih" dan "peluncuran": para penulis engine menguji coba runtime agar dukungan hari-nol benar-benar nyata, bukan sekadar nominal. Sebuah pull request yang membuat optimasi serving berfungsi pada arsitektur tersebut, dibuka pada pagi hari 2026-10-08 dan masih berupa draf, adalah sinyal yang lebih baik tentang seberapa dekat Qwen 4 dengan kondisi dapat dilayani daripada tanggal apa pun yang telah dilontarkan siapa pun. Itu juga, secara tegas, bukan tanggal rilis — flag-nya nonaktif secara default, perubahan tersebut belum di-merge, dan model yang dijadikan tolok ukur adalah pratinjau, bukan Qwen 4.

Apa yang dapat Anda sebut hari ini

Tak satu pun dari itu mengubah apa yang benar-benar tersedia sore ini. Qwen3.8-Flash-Next itu nyata, bobotnya ada di Hugging Face, dan Anda bisa menghostingnya sendiri — tetapi model itu tidak ada di katalog kami, dan kami tidak akan berpura-pura sebaliknya. Tingkat yang kami layani adalah qwen/qwen3.8-flash, saudara terkelolanya yang menjalankan arsitektur Qwen4-preview yang sama dengan jendela konteks 1 juta token serta masukan teks, gambar, dan video, dengan harga $0,15 per juta token masukan, $0,47 per juta keluaran, dan $0,0184 per juta pembacaan cache. Itu adalah harga daftar yang diteruskan tanpa markup 0%, jadi ketika vendor mengubahnya, angka di faktur Anda ikut berubah pada hari yang sama, bukan menunggu kapan seorang perantara menerbitkan ulang tabel harga.

Ada alasan kedua yang kurang jelas untuk memedulikan lapisan routing di sini. Semua yang dibahas dalam artikel ini adalah tentang pratinjau yang belum terbukti plus patch draf — hal yang ingin Anda uji tanpa mempertaruhkan jalur produksi padanya. Itulah gunanya failover: letakkan pratinjau di balik kunci yang sama dengan model yang sudah Anda percaya, amati perilakunya pada lalu lintas Anda, dan biarkan permintaan jatuh ke rute yang sudah terbukti baik saat penyedia goyah atau endpoint-nya tidak ada. Satu API untuk 200+ model, satu set kredensial, tanpa perlu menandatangani kontrak kedua untuk mengetahui apakah arsitektur baru layak mendapat perhatian Anda.

Ada dua hal yang perlu diperhatikan mulai dari sini, yang keduanya tidak dapat kita prediksi. Yang pertama adalah apakah patch ini akan di-merge sama sekali: ini adalah draf dengan tiga eksekusi CI yang gagal pada perubahan enam berkas dari akun kontributor tanpa riwayat sebelumnya di repositori, dan keluwesan pekerjaan tata letak baris PLE menunjukkan bahwa penulisnya masih melakukan iterasi. Yang kedua adalah apakah allowlist bertambah — jika Qwen4Exp bergabung dengan Qwen3ForCausalLM sebagai arsitektur yang tervalidasi, maka ini tidak lagi menjadi kebocoran dan menjadi cara default model keluarga Qwen4 dilayani pada konteks panjang. Sampai salah satu dari hal itu terjadi, anggap 18% sebagai janji tentang ke mana runtime ini menuju, bukan angka yang bisa Anda sewa.