Qwen4-Exp QSA hadir di Ascend milik Huawei: menilik PR prefill CANN yang bersifat opt-in di SGLang

Pada 2026-09-30, seorang kontributor membuka pull request SGLang #41855, berjudul “[NPU] Menambahkan sparse-attention CANN opt-in untuk prefill QSA Qwen4-Exp,” dan bagian yang menarik bukanlah aritmetikanya, melainkan perangkat kerasnya. Arsitektur QwenExp sekarang memiliki jalur sparse-attention yang ditulis tangan untuk akselerator Ascend 910C milik Huawei, di balik flag yang secara default nonaktif, dalam pull request draf yang belum di-merge — sementara model yang memiliki nama arsitektur itu, Qwen4-Exp, belum pernah dipublikasikan dalam bentuk apa pun. Satu-satunya checkpoint yang membawa arsitektur ini dalam bobot terbuka masih Qwen3.8-Flash-Note, pratinjau mixture-of-experts dengan 125 miliar parameter yang dirilis vendor di Hugging Face pada 2026-08-24, dan yang arsitekturnya sebenarnya mendeklarasikan arsitekturnya sebagai qwen4_exp. Qwen 4 sendiri — tier Max, Plus, dan 27B yang disebut vendor pada konferensi Apsara-nya pada 2026-09-22 — tidak memiliki bobot, tidak memiliki pengenal, tidak memiliki harga, dan tidak memiliki tanggal. Jadi ini adalah apa yang kita ketahui sejauh ini tentang sebuah artefak rekayasa, bukan vendor.

Apa yang sebenarnya ditambahkan oleh pull request tersebut

Perubahan ini sengaja dibuat kecil dan sengaja dibuat sempit. Lima berkas, satu commit, +355 baris terhadap cabang main pada commit b87a241, membawa label SGLang npu. Penulisnya, w1ida, menyatakan maksudnya di awal: jalur main-attention CANN yang opt-in untuk prefill eager Qwen4-Exp QSA, dibangun di atas torch_npu.npu_sparse_flash_attention, dengan indexer, pemilihan Top-K, anggaran token, dan isi KV-cache semuanya dibiarkan persis seperti semula.

Trik yang digunakannya untuk sampai ke sana layak mendapat satu paragraf, karena ini menjelaskan mengapa ini adalah adaptor tata letak, bukan kernel atensi baru. Untuk Q dan K yang sudah dirotasi, jalur ini mengemas cache sebagai C = [K, V] dan kueri sebagai Q' = [Q, 0]. Hasil kali Q' @ C.T kemudian sama dengan Q @ K.T, dan karena kueri yang dipadkan tidak memberikan kontribusi apa pun, softmax(scale * Q' @ C.T) @ C menghasilkan [P @ K, P @ V] yang ditumpuk — sehingga bagian V dapat diiris keluar. Dalam kata-kata penulis sendiri, ini adalah “embedding tata letak atensi, bukan perubahan pada atensi model atau kompresi KV berperingkat rendah.” Setiap head KV menjadi batch independen dalam tata letak MLA asli, skala D256 asli dipertahankan, dan RoPE tambahan dinolkan.

Detail operasional sama pentingnya dengan perhitungan matematis:

• Pengaktifan — SGLANG_NPU_QSA_NATIVE_PREFILL=1, default nonaktif. Hanya ForwardMode.EXTEND biasa yang ikut serta; decode, mode spekulatif, forward campuran, dan graph capture semuanya tetap pada jalur yang ada, dan graph capture melewati adapter sepenuhnya.

• Perangkat keras dan dtype — BF16 dengan dimensi head 256, Ascend 910C (Ascend910_93*, diuji terhadap CANN 9.0 dan torch-npu 2.10. Dtype atau bentuk yang tidak didukung akan kembali secara diam-diam ke jalur referensi.

• Bentuk head — pasangan lokal yang didukung (head Q, head KV) adalah (16,2), (24,2), (12,1), (6,1) dan (3,1). CANN menolak rasio query/KV 12 mentah-mentah — tiler-nya hanya menerima pangkat dua — jadi head di-pad 12→16, 6→8 atau 3→4 dan output tambahan dibuang. Ini tanda paling jelas di seluruh PR bahwa perangkat keras tidak dirancang dengan mempertimbangkan rasio head sparse-attention, dan adapter menyerap ketidakcocokan itu alih-alih model mengubah bentuk untuknya.

• Batas ukuran — hanya cakupan cache fisik yang direferensikan yang dipadatkan, dibatasi pada 262.144 token, yang menurut perhitungan penulis paling banyak 512 MiB untuk tensor K/V BF16 yang dipadatkan pada dua KV head. Padding interior -1 dideteksi dan dialihkan ke fallback, karena CANN memerlukan slot valid yang bersebelahan; baris yang sepenuhnya bertopeng mempertahankan konvensi keluaran nol yang sudah ada.

• Mengapa hanya prefill — pemeriksaan extent dan layout menyalin dua skalar ke host, dan salinan sementara ditambah workspace native mengonsumsi memori. Sinkronisasi itulah alasan jalur ini dibatasi hanya untuk eager prefill dan tidak dijalankan selama capture.

Sembilan tes yang lulus, dan angka kecepatan yang tidak berasal dari cabang ini

Bukti kebenarannya spesifik dan dapat direproduksi, yang lebih dari apa yang ditawarkan sebagian besar PR kernel. Penulis melaporkan 9 tes lulus dalam 40,772 detik pada Ascend 910C (Ascend910_9362) dengan CANN 9.0 dan torch-npu 2.10.0, tanpa memerlukan checkpoint: Q/K/V BF16 acak bukan nol terhadap referensi CPU FP32 yang dihitung dari input BF16 yang sama, slot fisik tak berurutan pada lebar 1/63/64/65/2051, skala default dan eksplisit, baris yang sepenuhnya bertopeng, baris nol, lebar seleksi nol, tensor non-kontigu, sisa ekor kausal rasio-kompresi-4 dari 0 hingga 3, pemetaan fisik dua permintaan dengan prefiks bersama, penggunaan ulang konten cache, dan bentuk head lokal Flash-Next pada 1 dan 257 baris kueri.

Kasus utama adalah prefill panjang: 7.810 token kueri terhadap cache 65.536 token dengan 2.051 slot terpilih per kueri, semua keluaran finite, dengan delapan baris sampel dibandingkan terhadap referensi FP32. Kesalahan L2 relatif yang teramati mencapai 0,209% pada kasus bentuk kepala kecil dan 0,231% pada baris prefill panjang yang disampel, terhadap ambang uji atol=0.025, rtol=0.025 dan L2 relatif di bawah 0,008, dengan baris kosong diharuskan tepat nol. Memori NPU teralokasi puncak untuk proses tersebut dikutip sebesar 1.042,7 MiB — dan penulis melabelinya sebagai metrik alokator PyTorch, bukan HBM board dan bukan memori model penuh, yang justru merupakan peringatan yang tepat untuk dilampirkan.

Lalu ada angka yang akan dikutip dan seharusnya tidak. Badan PR memuat tabel kecepatan yang menunjukkan jalur attention lokal yang ada pada 2.270,79 token baru per detik dan attention utama packed native pada 3.890,06 — keuntungan 1,713× / +71,3%, dengan rata-rata waktu ke token pertama turun dari 3,109 dtk menjadi 1,812 dtk. Penulis menegaskan bahwa ini adalah pengukuran prototipe historis yang diambil pada 2026-09-29 pada versi adaptasi dari Whittle-Next-26B-A3B checkpoint, dijalankan pada TP1 dengan bobot W8A8 dan attention BF16 pada 910C di bawah CANN 9.0, menggunakan sglang.bench_serving harness resmi pada concurrency 1 dengan enam permintaan, masing-masing satu token keluaran, dan 36.096 token prefiks cache dikecualikan dari throughput token baru. Hasil ini bukan benchmark untuk branch upstream di PR tersebut, artefak JSON serving asli tidak ada di checkout, dan hasil lokal selanjutnya sekitar 5.000 token per detik menggunakan pekerjaan indexer native dan block4 tambahan yang secara eksplisit tidak dikaitkan dengan perubahan ini. Penulis juga mencatat bahwa bobot indexer pada checkpoint yang diadaptasi bersifat inert dan anggarannya berbeda dari aslinya, jadi tidak satu pun dari itu menjadi bukti tentang kebenaran indexer atau kualitas generasi anggaran penuh.

Satu klarifikasi penamaan, karena ini akan membingungkan siapa pun yang mencari checkpoint tersebut: model benchmark itu adalah artefak adaptasi milik kontributor sendiri. Secara terpisah, “Whittle-Next” juga merupakan nama seri publik fine-tune MoE turunan Qwen3.8 yang diterbitkan oleh akun Hugging Face pihak ketiga, termasuk varian 26B-A3B yang diunggah pada September. Itu bukan model Qwen4Exp yang menjadi target PR ini, dan tidak boleh ditafsirkan sebagai konfigurasi benchmark di balik angka 1.713× tersebut.

Dua catatan tambahan berasal dari penulis, bukan dari saya. Integrasi serving penuh, paralelisme tensor terdistribusi, dan model Qwen3.8-Flash-Next lengkap belum divalidasi pada cabang ini; kontributor mengatakan bahwa mempertahankannya sebagai draf sementara pertanyaan integrasi dan dependensi didiskusikan adalah disengaja, dan bahkan menanyakan di badan PR apakah adaptor tersebut termasuk dalam SGLang atau di repositori sgl-kernel-npu yang terpisah. CI juga tidak bersih — blok status di badan PR menunjukkan kegagalan pada PR Test (Base), PR Test (Extra), dan eksekusi AMD ROCm 10. Kebenaran yang dijelaskan di atas berada pada tingkat operator; tidak ada apa pun dalam PR yang mengklaim hasil akurasi atau throughput end-to-end pada stack terintegrasi.

Mengapa QSA adalah bagian yang janggal, dalam angka

Qwen Sparse Attention bukanlah lapisan attention konvensional, dan konfigurasi yang dipublikasikan menunjukkan mengapa vendor akselerator harus menulis jalur khusus untuknya. Dari konfigurasi Qwen3.8-Flash-Next: 48 lapisan yang tersusun sebagai dua belas pengulangan tiga blok Gated DeltaNet diikuti oleh satu blok full-attention, full_attention_interval 4, ukuran hidden 2.560, dimensi head attention 256, 24 head query terhadap 2 head KV, dimensi RoPE 64. Pengindeks yang membuat attention menjadi sparse adalah struktur multi-query dengan 4 head query yang berbagi 1 head key, dimensi head 128, rasio kompresi 4, dan anggaran 2.048 micro-block terpilih per query.

Anggaran itu adalah yang dijaga tetap oleh PR. Ukuran blok sparse 1, mode sparse 0, mode attention 2, dan token terpilih; pengindeks native dan optimisasi blok secara eksplisit di luar cakupan. Jadi ini adalah adaptor di bawah mekanisme seleksi yang sudah ada, bukan implementasi ulang QSA — yang juga menjadi alasan penulis dapat secara kredibel mengklaim bahwa isi KV-cache tidak berubah.

Kartu model menggambarkan maksud desainnya secara gamblang: alih-alih memilih token individual, QSA bekerja pada tingkat blok-mikro untuk memangkas latensi konteks panjang, dan granularitas blok-mikro itu, ditambah status selektor yang direplikasi yang menyertainya, justru itulah yang tidak dapat dipetakan dengan bersih ke kernel paged-attention generik pada silikon kedua vendor.

Di mana posisi ini dalam pembangunan layanan Qwen4Exp

Jika dilihat sendiri, satu draft PR pada satu akselerator hanyalah sebuah keunikan. Jika dibandingkan dengan sisa bulan September, itu adalah papan keempat atau kelima dari sebuah platform yang sedang dirakit di depan publik sebelum keluarga yang dilayaninya ada:

• Arsitektur dalam bobot terbuka — Qwen3.8-Flash-Next, 2026-08-24, sebuah MoE berparameter 125B dengan 6B diaktifkan, tabel embedding n-gram berparameter 51 miliar dan kepala MTP 4B, yang membawa model_type: qwen4_exp dan arsitektur Qwen4ExpForConditionalGeneration.

• Sisi vLLM — #53909, PR “qwen4 fuse op” yang menambahkan kernel HyperConnection, QSA, dan PLE, masih terbuka dan belum digabungkan sejak 2026-08-26; #59279, yang menambahkan paralelisme konteks decode ke jalur QSA yang sama, draf yang dibuka pada 2026-09-29; dan pekerjaan PLE-offload yang berhasil digabungkan sepanjang September.

• Sisi SGLang — #38642 untuk penangkapan hidden-state DFlash, #39548 untuk offload CPU PLE Qwen4-Exp pada Ascend, #40235 yang menambahkan staging host untuk tabel PLE berbasis file, dan kini #41855 untuk jalur attention Ascend.

• Lini pengaktifan NPU — sglang #37570, yang menambahkan Qwen3.8-Flash-Next ke SGLang pada NPU dengan graph replay, MTP, dan kernel Triton (dibuka 2026-09-02, masih terbuka, +2.590 baris di 20 file), dan sgl-kernel-npu #807 untuk kernel Triton pendampingnya (dibuka 2026-09-17, +4.643 baris). Keduanya berasal dari kontributor yang sama. #41855 adalah lapisan attention yang berada di dalam upaya pengaktifan yang lebih besar itu.

Dua pengamatan yang bisa ditindaklanjuti oleh pembaca. Pertama, seluruh kisah Ascend Qwen4Exp bertumpu pada sangat sedikit kontributor — PR pemberdayaan (enablement) dan repositori kernel berbagi satu penulis yang sama, sementara adaptor attention-nya adalah penulis yang berbeda. Konsentrasi itu adalah perkiraan yang wajar tentang seberapa jauh penyajian Ascend Qwen4Exp dari menjadi jalur produk yang didukung, bukan sekadar eksperimen. Kedua, hambatan kernel bukanlah hal yang spesifik vendor: dua issue SGLang yang diajukan pada 2026-08-28 mendokumentasikan decode Qwen4Exp di NVIDIA DGX Spark, di mana waktu kernel QSA, PLE, dan Gated DeltaNet mendominasi, dan di mana cache KV NVFP4 terukur mengalami regresi decode sekitar 29% dibandingkan fp8_e4m3. Lapisan attention dan embedding dari arsitektur ini adalah bagian yang sulit di mana pun.

Apa yang tidak dimaksudkan oleh ini

Ini tidak berarti Qwen 4 sudah dirilis, atau hampir dirilis. Keluarga Qwen 4 yang dinamai Alibaba pada 2026-09-22 — Max, Flash, Plus dan tier 27B — tetap hanya peta jalan tanpa kartu model, tanpa bobot, tanpa pengenal API, tanpa jendela konteks, tanpa lisensi dan tanpa harga. Adaptor kerangka kerja yang menyasar nama arsitektur internal adalah langkah menuju penyajian keluarga itu dengan baik suatu hari nanti; itu bukan langkah menuju keberadaan keluarga tersebut.

Itu tidak berarti Anda dapat menjalankannya hari ini. PR ini masih berupa draf dengan CI yang gagal dan tanpa tanggal merge. Bahkan jika sudah di-merge, jalur ini memerlukan Ascend 910C, BF16, CANN 9.0 dengan torch-npu 2.10, dan salah satu dari lima bentuk head lokal tertentu, serta bersifat opt-in — artinya suatu deployment harus memilihnya. Penulisnya juga menolak mengklaim validasi tingkat server, yang justru merupakan bagian yang benar-benar akan memberi tahu Anda apakah ini bertahan dalam batching nyata.

Dan itu tidak berarti Qwen3.8-Flash-Next adalah produk yang didukung di Ascend, atau di mana pun dalam build engine yang telah dirilis. Jalur Qwen4Exp di kedua runtime terbuka utama masih berupa pull request yang belum di-merge. Tidak ada versi SGLang atau vLLM yang telah dirilis yang dapat Anda pasang yang menyajikan arsitektur ini secara native — kemudahan ala FastAPI dari endpoint yang dihosting adalah hal yang berbeda dari kernel yang dapat Anda jalankan sendiri, dan jarak di antara keduanya justru adalah tujuan PR seperti ini.

Apa yang sebenarnya dapat Anda hubungi selagi menunggu

Jika alasan Anda peduli pada Qwen4Exp adalah karena Anda ingin menguji perilaku konteks panjang arsitektur tersebut, bukan bagian internal kernel-nya, model yang perlu Anda gunakan adalah tier yang benar-benar dilayani Alibaba. Qwen3.8-Flash — lini produksi yang dibangun di atas Qwen3.8-Flash-Next, dengan alat bawaan resmi dan konteks 1.000.000 token — sudah aktif di OrcaRouter sebagai qwen/qwen3.8-flash: input teks, gambar, dan video, output maksimum 131.072 token, $0,15 per juta token input dan $0,47 per juta token output, dengan pembacaan cache sebesar $0,0184. Itu adalah harga daftar penyedia yang diteruskan dengan markup 0% di sisi kami, sehingga perubahan harga atau batas dari vendor akan sampai kepada Anda pada hari yang sama saat diumumkan. Dalam jendela tujuh hari terakhir, kartu live menunjukkan latensi token pertama p50 sebesar 4.416 ms, sekitar 106 token output per detik, dan tingkat kesalahan 2,68% — profil tier teks bervolume tinggi, bukan pratinjau lab.

Dua kualifikasi yang jujur, dan keduanya sama dengan dua hal yang dibawa oleh tulisan-tulisan pendamping tentang arsitektur ini. Qwen3.8-Flash-Next sendiri — checkpoint pratinjau FP8, hal yang Anda perlukan untuk mereproduksi salah satu pengukuran kernel ini secara lokal — tidak ada di katalog kami; tier Flash yang dilayani adalah deployment produksi yang dibangun darinya, bukan artefak pratinjau mentah. Dan tidak ada pekerjaan Ascend atau DCP yang dijelaskan di atas yang ada dalam apa pun yang dapat Anda panggil, karena tidak ada satu pun yang telah di-merge. Apa yang diberikan oleh tier yang dilayani adalah cara murah untuk mengetahui apakah beban kerja Anda cocok untuk masalah yang dipecahkan oleh kernel ini — prompt agen yang panjang dan padat prefiks terhadap konteks yang sangat panjang. Jika ya, throughput dan perilaku cache yang Anda amati di sana adalah perilaku yang sama yang akan disetel oleh stack penyajian Qwen 4 untuk dilindungi.

Ada juga argumen pipa untuk tidak menunggu keluarga yang belum punya tanggal. Tingkat mana pun yang akhirnya memenangkan jajaran Qwen 4, biaya peralihannya adalah pertanyaan routing, bukan proyek integrasi, dan satu API untuk 200+ modeladalah cara Anda menjaga opsi itu tetap terbuka tanpa kontrak kedua atau perubahan kode saat bobotnya mendarat. Failover penting karena alasan yang sama di sini dengan cara yang spesifik: jika Anda ingin membangun terhadap tingkat yang belum terbukti, Anda ingin permintaan itu dialihkan ke sesuatu yang stabil alih-alih gagal ketika jalur yang Anda pertaruhkan sedang mengalami menit buruk.

Tiga pertanyaan yang layak dijawab secara langsung

Apakah SGLang #41855 berarti Qwen 4 sudah dirilis, atau bisa dipratinjau?

Tidak, pada kedua hal itu. Pull request ini menargetkan arsitektur Qwen4Exp sebagaimana diimplementasikan dalam Qwen3.8-Flash-Next, yang dirilis Alibaba pada 2026-08-24. Ini tidak menyentuh bobot Qwen 4, dan tidak ada tier Qwen 4 yang memiliki bobot untuk disentuh. Sinyal yang perlu dibaca di sini adalah tentang kapasitas penyajian untuk arsitektur pratinjau, bukan tentang ketersediaan keluarga model tersebut.

Jika kartu model bertuliskan qwen4_exp, apakah itu Qwen 4?

Tidak — dan inilah jebakan penamaan di seluruh cerita ini. qwen4_exp adalah pengidentifikasi arsitektur internal, dan itulah yang akan Anda temukan di config.json untuk Qwen3.8-Flash-Next dan saudara FP8-nya. “Arsitektur eksperimental” adalah kata kuncinya: bobotnya dipublikasikan, arsitekturnya nyata, dan model ini adalah pratinjau dari apa yang diharapkan menjadi fondasi keluarga Qwen 4. Menelusuri pengidentifikasi tersebut dan menemukan PR SGLang atau vLLM dengan Qwen4Exp di judulnya memberi tahu Anda tentang pekerjaan engine, bukan tentang rilis.

Apakah ini kisah Ascend versus NVIDIA?

Tidak juga. Jalur atensi yang sama juga memerlukan adapter khusus di sisi NVIDIA — paralelisme konteks decode untuk QSA di vLLM, dan kernel prefill sparse native untuk Hopper — dan masalah DGX Spark menunjukkan bahwa waktu kernel QSA, PLE, dan Gated DeltaNet juga mendominasi decode di sana. Pengindeks blok mikro milik QSA dan status selektor yang direplikasinya memang bukan seperti yang diasumsikan oleh kernel paged-attention generik. Kontribusi Ascend terhadap pola ini adalah batasan yang lebih tajam: tiler rasio head yang hanya menerima pangkat dua, yang memaksa padding yang harus disembunyikan oleh adapter.

Hal yang perlu diperhatikan

Bukan soal apakah ini akan digabungkan. Adaptor ini jujur mengakui dirinya sebagai adaptor, uji kebenarannya dapat direproduksi tanpa checkpoint, dan penulisnya telah menandai pertanyaan integrasi alih-alih berpura-pura bahwa hal itu sudah selesai. Yang perlu diperhatikan adalah apa yang terjadi setelah baris pengaktifan NPU dan jalur atensi ini digabungkan — apakah cabang terintegrasi akan mendapatkan uji end-to-end yang belum pernah dimiliki keduanya, pada batching nyata dengan model lengkap alih-alih tensor bentuk head lokal. Angka 1,713× adalah angka yang akan beredar, dan itulah yang dihitung pada build yang berbeda, pada checkpoint yang diadaptasi, dengan pengindeks yang inert. Angka yang terukur pada stack yang sudah selesai akan jauh lebih bernilai daripada angka historis.

Sampai saat itu, ringkasan jujur adalah yang tetap dipegang oleh PR itu sendiri: perhitungannya benar, flag-nya nonaktif secara default, CI-nya merah, dan model dalam judulnya masih belum ada.