Qwen4-Exp QSA มาถึง Ascend ของ Huawei แล้ว: เจาะลึก PR prefill CANN แบบ opt-in ของ SGLang

เมื่อวันที่ 2026-09-30 ผู้มีส่วนร่วมได้เปิด SGLang pull request #41855 ชื่อ “[NPU] Add opt-in CANN sparse attention for Qwen4-Exp QSA prefill” และส่วนที่น่าสนใจไม่ใช่คณิตศาสตร์ มันคือฮาร์ดแวร์ สถาปัตยกรรม Qwen4Exp ตอนนี้มีเส้นทาง sparse-attention ที่เขียนด้วยมือสำหรับตัวเร่ง Ascend 910C ของ Huawei อยู่หลัง flag ที่ค่าเริ่มต้นเป็นปิด ใน draft pull request ที่ยังไม่ถูก merge — ในขณะที่โมเดลที่ชื่อสถาปัตยกรรมนั้นเป็นของ Qwen4-Exp ยังไม่เคยถูกเผยแพร่ในรูปแบบใด ๆ checkpoint เดียวที่บรรจุสถาปัตยกรรมนี้ใน open weights ยังคงเป็น Qwen3.8-Flash-Next พรีวิว mixture-of-experts ขนาด 125 พันล้านพารามิเตอร์ที่ผู้ขายเปิดตัวบน Hugging Face เมื่อวันที่ 2026-08-24 และการ์ดของมันระบุสถาปัตยกรรมจริง ๆ ว่าเป็นqwen4_exp. Qwen 4 เอง — ระดับ Max, Flash, Plus และ 27B ที่ผู้ขายตั้งชื่อในงานประชุม Apsara เมื่อวันที่ 2026-09-22 — ยังไม่มี weights, ไม่มีตัวระบุ, ไม่มีราคา และไม่มีวันที่ ดังนั้นนี่คือบทความแบบ what-we-know-so-far เกี่ยวกับชิ้นงานวิศวกรรม ไม่ใช่การเปิดตัว: อีกหนึ่ง serving stack ของผู้ขายที่ตัดสินใจเงียบ ๆ ว่าสถาปัตยกรรมที่ยังไม่เปิดตัวนั้นคุ้มค่าที่จะสนับสนุนแต่เนิ่น ๆ

สิ่งที่ pull request เพิ่มเข้ามาจริง ๆ

การเปลี่ยนแปลงนี้เล็กโดยเจตนาและแคบโดยเจตนา ห้าไฟล์ หนึ่งคอมมิต +355 บรรทัดเมื่อเทียบกับสาขาหลักที่คอมมิต b87a241 ซึ่งมาพร้อมป้ายกำกับ SGLang npu และผู้เขียน w1ida ได้ระบุเจตนาไว้ตั้งแต่ต้นว่า เป็นเส้นทาง main-attention ของ CANN แบบเลือกใช้เอง (opt-in) สำหรับ eager prefill ของ Qwen4-Exp QSA ที่สร้างขึ้นบน torch_npu.npu_sparse_flash_attention โดยที่ indexer, การเลือก Top-K, งบโทเคน และเนื้อหาใน KV-cache ทั้งหมดยังคงไว้เหมือนเดิมทุกประการ

เคล็ดลับที่มันใช้เพื่อไปถึงจุดนั้นคุ้มค่ากับหนึ่งย่อหน้า เพราะมันอธิบายว่าทำไมนี่จึงเป็นอะแดปเตอร์เลย์เอาต์แทนที่จะเป็นเคอร์เนลความสนใจใหม่ สำหรับ Q และ K ที่หมุนแล้ว เส้นทางจะแพ็กแคชเป็น C = [K, V]และคิวรีเป็น Q' = [Q, 0] ผลคูณ Q' @ C.T แล้วเท่ากับ Q @ K.T และเนื่องจากคิวรีที่แพดไว้ไม่มีส่วนช่วยอะไรเลย softmax(scale * Q' @ C.T) @ C ส่งคืน [P @ K, P @ V] ที่ซ้อนกัน — ดังนั้นครึ่ง V สามารถตัดออกได้ ในคำพูดของผู้เขียนเอง นี่คือ “การฝังเลย์เอาต์ความสนใจ ไม่ใช่การเปลี่ยนแปลงความสนใจของโมเดลหรือการบีบอัด KV แบบจัดอันดับต่ำ” แต่ละหัว KV กลายเป็นแบตช์อิสระในเลย์เอาต์ MLA แบบเนทีฟ สเกล D256 เดิมยังคงอยู่ และ RoPE เสริมถูกตั้งเป็นศูนย์

รายละเอียดเชิงปฏิบัติการสำคัญพอ ๆ กับคณิตศาสตร์:

• การเปิดใช้งาน — SGLANG_NPU_QSA_NATIVE_PREFILL=1 โดยค่าเริ่มต้นคือ ปิด เฉพาะ ForwardMode.EXTENDแบบปกติเท่านั้นที่เลือกเปิดใช้ ส่วน decode โหมด speculative, mixed forward และ graph capture ยังคงใช้เส้นทางเดิมทั้งหมด และ graph capture จะข้ามอะแดปเตอร์ไปเลย

• ฮาร์ดแวร์และ dtype — BF16 ที่มีมิติ head 256, Ascend 910C (Ascend910_93*), ทดสอบกับ CANN 9.0 และ torch-npu 2.10 dtype หรือ shape ที่ไม่รองรับใด ๆ จะ fallback ไปยังเส้นทางอ้างอิงอย่างเงียบ ๆ

• รูปร่างหัว — คู่ภายในที่รองรับ (หัว Q, หัว KV) คือ (16,2), (24,2), (12,1), (6,1) และ (3,1). CANN ปฏิเสธอัตราส่วน query/KV ที่ 12 โดยสิ้นเชิง — tiler ของมันรับเฉพาะกำลังของสองเท่านั้น — ดังนั้นหัวจึงถูกแพด 12→16, 6→8 หรือ 3→4 และเอาต์พุตที่เพิ่มเข้ามาก็ถูกทิ้งไป นี่เป็นสัญญาณที่ชัดเจนที่สุดใน PR ทั้งหมดว่าฮาร์ดแวร์ไม่ได้ถูกออกแบบโดยคำนึงถึงอัตราส่วนหัวแบบ sparse-attention และอะแดปเตอร์กำลังดูดซับความไม่ลงรอยนั้น แทนที่โมเดลจะเปลี่ยนรูปร่างเพื่อสิ่งนั้น

• ขอบเขตการกำหนดขนาด — เฉพาะขอบเขตแคชทางกายภาพที่ถูกอ้างอิงเท่านั้นที่ถูกแพ็ก โดยจำกัดไว้ที่ 262,144 โทเคน ซึ่งผู้เขียนคำนวณว่าไม่เกิน 512 MiB สำหรับเทนเซอร์ K/V แบบ BF16 ที่แพ็กแล้วเมื่อมี KV head สองหัว ส่วน-1การแพดดิ้งภายในจะถูกตรวจพบและส่งต่อไปยังเส้นทางสำรอง เนื่องจาก CANN ต้องการสล็อตที่ต่อเนื่องและถูกต้อง ส่วนแถวที่ถูกมาสก์ทั้งหมดยังคงใช้แนวปฏิบัติเดิมที่ให้เอาต์พุตเป็นศูนย์

• ทำไมจึงใช้เฉพาะ prefill — การตรวจสอบ extent และ layout จะคัดลอกสเกลาร์สองค่าไปยังโฮสต์ และสำเนาชั่วคราวรวมกับ native workspace กินหน่วยความจำ การซิงโครไนซ์ดังกล่าวเป็นเหตุผลที่เส้นทางนี้ถูกจำกัดให้ใช้เฉพาะ eager prefill และปิดไว้ระหว่างการ capture

การทดสอบเก้าอย่างที่ผ่าน และตัวเลขความเร็วที่ไม่ได้มาจากแบรนช์นี้

หลักฐานยืนยันความถูกต้องมีความเฉพาะเจาะจงและสามารถทำซ้ำได้ ซึ่งมากกว่าที่ PR ของ kernel ส่วนใหญ่มีให้ ผู้เขียนรายงานว่ามีการทดสอบ 9 รายการผ่านใน 40.772 วินาทีบน Ascend 910C (Ascend910_9362) ด้วย CANN 9.0 และ torch-npu 2.10.0 โดยไม่ต้องใช้ checkpoint: BF16 Q/K/V แบบสุ่มที่ไม่เป็นศูนย์เทียบกับ FP32 CPU reference ที่คำนวณจากอินพุต BF16 ชุดเดียวกัน, physical slots ที่ไม่เรียงลำดับที่ความกว้าง 1/63/64/65/2051, scales แบบค่าเริ่มต้นและแบบระบุชัดเจน, แถวที่ถูก mask ทั้งหมด, แถวที่เป็นศูนย์, ความกว้างการเลือกเป็นศูนย์, เทนเซอร์แบบ non-contiguous, เศษที่เหลือของ causal tail ที่ compression ratio 4 ตั้งแต่ 0 ถึง 3, การแมป physical แบบสองคำขอที่มี shared prefix, การนำเนื้อหา cache มาใช้ซ้ำ และรูปทรง head แบบ local ของ Flash-Next ที่จำนวนแถว query 1 และ 257

กรณีเด่นคือพรีฟิลล์แบบยาว: 7,810 โทเคนคิวรีเทียบกับแคชขนาด 65,536 โทเคน โดยมี 2,051 สล็อตที่เลือกต่อคิวรี เอาต์พุตทั้งหมดมีค่าจำกัด โดยมีแปดแถวที่สุ่มตัวอย่างมาเปรียบเทียบกับข้อมูลอ้างอิง FP32 ค่าความคลาดเคลื่อน L2 สัมพัทธ์ที่สังเกตได้สูงถึง 0.209% ในกรณีรูปทรงหัวขนาดเล็ก และ 0.231% ในแถวพรีฟิลล์แบบยาวที่สุ่มตัวอย่าง เทียบกับเกณฑ์การทดสอบที่ atol=0.025, rtol=0.025 และค่า L2 สัมพัทธ์ต่ำกว่า 0.008 โดยแถวว่างต้องเป็นศูนย์พอดี หน่วยความจำ NPU สูงสุดที่จัดสรรสำหรับการรันนั้นระบุไว้ที่ 1,042.7 MiB — และผู้เขียนระบุว่าเป็นเมตริกของตัวจัดสรรหน่วยความจำ PyTorch ไม่ใช่ HBM ของบอร์ด และไม่ใช่หน่วยความจำของโมเดลเต็มรูปแบบ ซึ่งเป็นข้อแม้ที่เหมาะสมที่สุดที่จะแนบไว้

จากนั้นก็มีตัวเลขที่จะถูกนำไปอ้างกันและไม่ควรเป็นเช่นนั้น เนื้อความใน PR มีตารางความเร็วที่แสดงเส้นทางการให้ความสนใจแบบโลคัลที่มีอยู่ที่ 2,270.79 โทเคนใหม่ต่อวินาที และการให้ความสนใจหลักแบบแพ็กเนทีฟที่ 3,890.06 — คิดเป็นการเพิ่มขึ้น 1.713× / +71.3% โดยค่าเฉลี่ยเวลาถึงโทเคนแรกลดลงจาก 3.109 วินาที เหลือ 1.812 วินาที ผู้เขียนระบุชัดเจนว่าสิ่งเหล่านี้เป็นการวัดจากต้นแบบในอดีตที่ทำเมื่อวันที่ 2026-09-29 บนเช็กพอยต์ Whittle-Next-26B-A3B ที่ดัดแปลงแล้ว รันที่ TP1 ด้วยน้ำหนัก W8A8 และการให้ความสนใจแบบ BF16 บน 910C ภายใต้ CANN 9.0 โดยใช้ฮาร์เนส sglang.bench_serving อย่างเป็นทางการที่ความพร้อมกันระดับ 1 กับหกคำขอ เอาต์พุตคำขอละหนึ่งโทเคน และมีโทเคนคำนำหน้าที่แคชไว้ 36,096 โทเคนที่ถูกตัดออกจากอัตราทรูพุตของโทเคนใหม่ สิ่งเหล่านี้ ไม่ใช่ การวัดประสิทธิภาพของแบรนช์ต้นทางใน PR อาร์ติแฟกต์ JSON ของการให้บริการต้นฉบับไม่มีอยู่ในเช็กเอาต์ และผลลัพธ์แบบโลคัลในภายหลังที่ราว 5,000 โทเคนต่อวินาทีนั้นใช้ตัวจัดทำดัชนีแบบเนทีฟเพิ่มเติมและงาน block4 ซึ่งไม่ได้ถูกระบุว่าเป็นผลจากการเปลี่ยนแปลงนี้อย่างชัดเจน ผู้เขียนยังตั้งข้อสังเกตด้วยว่าน้ำหนักตัวจัดทำดัชนีของเช็กพอยต์ที่ดัดแปลงแล้วนั้นไม่ทำงาน และงบประมาณของมันแตกต่างจากต้นฉบับ ดังนั้นจึงไม่มีส่วนใดเป็นหลักฐานเกี่ยวกับความถูกต้องของตัวจัดทำดัชนีหรือคุณภาพการสร้างแบบเต็มงบประมาณ

ขอชี้แจงเรื่องการตั้งชื่อหนึ่งประการ เนื่องจากมันจะทำให้ใครก็ตามที่ค้นหาเช็กพอยต์สับสน: โมเดล benchmark คืออาร์ติแฟกต์ที่ดัดแปลงขึ้นเองของผู้มีส่วนร่วม อีกส่วนหนึ่ง “Whittle-Next” ยังเป็นชื่อของซีรีส์สาธารณะของงาน fine-tune แบบ MoE ที่ได้มาจาก Qwen3.8 ซึ่งเผยแพร่โดยบัญชี Hugging Face ของบุคคลที่สาม รวมถึงเวอร์ชัน 26B-A3B ที่อัปโหลดในเดือนกันยายน สิ่งเหล่านั้นไม่ใช่โมเดล Qwen4Exp ที่ PR นี้มุ่งเป้า และไม่ควรตีความว่าเป็นการตั้งค่า benchmark ที่อยู่เบื้องหลังตัวเลข 1.713× นั้น

ข้อควรระวังเพิ่มเติมอีกสองประการมาจากผู้เขียน ไม่ใช่จากผม การผสานรวมการให้บริการเต็มรูปแบบ การขนานเทนเซอร์แบบกระจาย และโมเดล Qwen3.8-Flash-Next ฉบับสมบูรณ์ยังไม่ได้รับการตรวจสอบบนสาขานี้ ผู้มีส่วนร่วมกล่าวว่าการคงไว้เป็นฉบับร่างในระหว่างที่กำลังหารือเกี่ยวกับการผสานรวมและโมเดลนั้นเป็นความตั้งใจ และยังถามในเนื้อความ PR ว่าอะแดปเตอร์ควรอยู่ใน SGLang หรือใน sgl-kernel-npu รีโพซิทอรีแยกต่างหาก CI ก็ไม่สะอาดเช่นกัน — บล็อกสถานะในเนื้อความ PR แสดงความล้มเหลวใน PR Test (Base), PR Test (Extra) และการรัน AMD ROCm 10 ความถูกต้องที่อธิบายข้างต้นเป็นระดับโอเปอเรเตอร์ ไม่มีสิ่งใดใน PR อ้างว่ามีผลลัพธ์ความแม่นยำหรือปริมาณงานแบบ end-to-end บนสแต็กที่ผสานรวมแล้ว

ทำไม QSA จึงเป็นส่วนที่ยุ่งยาก เมื่อมองผ่านตัวเลข

Qwen Sparse Attention ไม่ใช่เลเยอร์ attention แบบดั้งเดิม และการกำหนดค่าที่เผยแพร่แสดงให้เห็นว่าเหตุใดผู้จำหน่ายตัวเร่งความเร็วจึงต้องเขียนเส้นทางเฉพาะสำหรับมัน จากคอนฟิกของ Qwen3.8-Flash-Next: 48 เลเยอร์จัดเรียงเป็นการทำซ้ำ 12 รอบของ 3 บล็อก Gated DeltaNet ตามด้วย 1 บล็อก full-attention full_attention_interval 4, hidden size 2,560, มิติ attention head 256, 24 query heads ต่อ 2 KV heads, มิติ RoPE 64 indexer ที่ทำให้ attention เบาบางนั้นเป็นโครงสร้าง multi-query ซึ่งมี 4 query heads ใช้ร่วมกัน 1 key head, มิติ head 128, อัตราส่วนการบีบอัด 4 และโควตา 2,048 ไมโครบล็อกที่เลือกต่อ query

งบประมาณนั้นคือสิ่งที่ PR ตรึงไว้ให้คงที่ ขนาดบล็อกแบบ sparse ยังคงเป็น 1 โหมด sparse ยังคงเป็น 0 โหมด attention ยังคงเป็น 2 และอินเทอร์เฟซของโทเคนที่ถูกเลือกนั้นไม่ถูกแตะต้อง ส่วนการปรับประสิทธิภาพของ indexer แบบเนทีฟและ block4 นั้นถูกระบุไว้อย่างชัดเจนว่าอยู่นอกขอบเขต ดังนั้นนี่จึงเป็นอะแดปเตอร์ที่ถูกยึดติดไว้ใต้กลไกการเลือกที่มีอยู่แล้ว ไม่ใช่การนำ QSA มาทำใหม่ ซึ่งเป็นเหตุผลว่าทำไมผู้เขียนจึงอ้างได้อย่างน่าเชื่อถือว่าเนื้อหาของ KV-cache ไม่เปลี่ยนแปลง

การ์ดโมเดลวางกรอบเจตนาการออกแบบไว้อย่างตรงไปตรงมา: แทนที่จะเลือกทีละรายการ Q ทำงานในระดับไมโครบล็อกเพื่อลดความหน่วงของบริบทยาว และความละเอียดระดับไมโครบล็อก พร้อมด้วยสถานะตัวเลือกที่ถูกทำสำเนาซึ่งมาพร้อมกันนั้น คือสิ่งที่ทำให้ไม่สามารถแมปเข้ากับเคอร์เนล paged-attention ทั่วไปบนซิลิคอนของผู้จำหน่ายทั้งสองรายได้อย่างลงตัว

ตำแหน่งของสิ่งนี้ในงานสร้างระบบให้บริการ Qwen4Exp

เมื่อมองเพียงลำพัง PR ฉบับร่างหนึ่งรายการบนแอคเซลเลอเรเตอร์หนึ่งตัวก็เป็นเพียงเรื่องน่าพิศวง แต่เมื่อมองเทียบกับช่วงที่เหลือของเดือนกันยายน มันคือแผ่นกระดานแผ่นที่สี่หรือห้าของแพลตฟอร์มที่กำลังถูกประกอบขึ้นอย่างเปิดเผยต่อสาธารณะ ก่อนที่ครอบครัวที่มันให้บริการจะมีอยู่จริง:

• สถาปัตยกรรมในเวอร์ชันเปิดน้ำหนัก — Qwen3.8-Flash-Next, 2026-08-24, MoE ขนาด 125B พารามิเตอร์ที่เปิดใช้งาน 6B, ตาราง embedding แบบ n-gram ขนาด 51 พันล้านพารามิเตอร์ และ MTP head ขนาด 4B, พร้อมด้วย model_type: qwen4_exp และสถาปัตยกรรม Qwen4ExpForConditionalGeneration.

• ฝั่ง vLLM — #53909 PR “qwen4 fuse op” ที่เพิ่มเคอร์เนล HyperConnection, QSA และ PLE ยังคงเปิดอยู่และยังไม่ถูก merge ตั้งแต่ 2026-08-26; #59279 ซึ่งเพิ่ม decode context parallelism ให้เส้นทาง QSA เดียวกัน เป็นฉบับร่างที่เปิดเมื่อ 2026-09-29; และงาน PLE-offload ที่ถูก merge ตลอดเดือนกันยายน

• ฝั่ง SGLang — #38642 สำหรับการจับ hidden state ของ DFlash, #39548 สำหรับการ offload PLE CPU ของ Qwen4-Exp บน Ascend, #40235 เพิ่ม host staging สำหรับตาราง PLE ที่อิงกับไฟล์ และตอนนี้ #41855 สำหรับเส้นทาง attention บน Ascend

• สายงานการเปิดใช้งาน NPU — sglang #37570 ซึ่งเพิ่ม Qwen3.8-Flash-Next เข้าใน SGLang บน NPU พร้อม graph replay, MTP และ Triton kernels (เปิดเมื่อ 2026-09-02 ยังเปิดอยู่ +2,590 บรรทัดใน 20 ไฟล์) และ sgl-kernel-npu #807 สำหรับ Triton kernels ที่เป็นคู่กัน (เปิดเมื่อ 2026-09-17 +4,643 บรรทัด) ทั้งสองมาจากผู้มีส่วนร่วมคนเดียวกัน #41855 คือเลเยอร์ attention ที่อยู่ภายในความพยายามเปิดใช้งานที่ใหญ่กว่านั้น

ข้อสังเกตสองข้อที่ผู้อ่านนำไปใช้ได้ ประการแรก เรื่องราวทั้งหมดของ Ascend Qwen4Exp ตั้งอยู่บนผู้มีส่วนร่วมจำนวนน้อยมาก — PR ที่เปิดใช้งานและที่เก็บโค้ดเคอร์เนลมีผู้เขียนคนเดียวกัน และอะแดปเตอร์ attention เป็นอีกคนหนึ่งที่แตกต่างออกไป ความกระจุกตัวนั้นเป็นการประเมินที่สมเหตุสมผลว่าการให้บริการ Ascend Qwen4Exp ยังห่างไกลแค่ไหนจากการเป็นเส้นทางผลิตภัณฑ์ที่ได้รับการสนับสนุน แทนที่จะเป็นเพียงการทดลอง ประการที่สอง คอขวดของเคอร์เนลไม่ได้จำเพาะเจาะจงกับผู้จำหน่ายรายใดรายหนึ่ง: ปัญหา SGLang สองรายการที่แจ้งเมื่อ 2026-08-28 บันทึกการทำงานของ Qwen4Exp decode บน NVIDIA DGX Spark ซึ่งเวลาของเคอร์เนล QSA, PLE และ Gated DeltaNet ครองสัดส่วนหลัก และซึ่งแคช KV แบบ NVFP4 ถูกวัดว่าทำให้ decode ถดถอยลงราว 29% เมื่อเทียบกับ fp8_e4m3 เลเยอร์ attention และ embedding ของสถาปัตยกรรมนี้เป็นส่วนที่ยากในทุกที่

สิ่งที่สิ่งนี้ไม่ได้หมายความถึง

ไม่ได้หมายความว่า Qwen 4 ออกแล้ว หรือใกล้จะออก ตระกูล Qwen 4 ที่ Alibaba ตั้งชื่อเมื่อวันที่ 22 กันยายน 2026 — Max, Flash, Plus และระดับ 27B — ยังคงเป็นเพียงแผนงานที่ไม่มีโมเดลการ์ด ไม่มีเวท ไม่มีตัวระบุ API ไม่มีหน้าต่างบริบท ไม่มีใบอนุญาต และไม่มีราคา อะแดปเตอร์เฟรมเวิร์กที่กำหนดเป้าหมายไปที่ชื่อสถาปัตยกรรมภายในเป็นก้าวหนึ่งไปสู่การให้บริการตระกูลนั้นได้ดีในสักวันหนึ่ง ไม่ใช่ก้าวไปสู่การมีอยู่จริงของตระกูลนั้น

มันไม่ได้หมายความว่าคุณจะรันสิ่งนี้ได้วันนี้ PR ยังเป็นฉบับร่างที่มี CI ล้มเหลวและไม่มีกำหนด merge แม้จะ merge แล้ว เส้นทางนี้ก็ยังต้องใช้ Ascend 910C, BF16, CANN 9.0 ที่มี torch-npu 2.10 และต้องเป็นหนึ่งในห้า local head shape ที่ระบุเจาะจง อีกทั้งยังเป็นแบบ opt-in — หมายความว่าการดีพลอยต้องเลือกใช้เอง ผู้เขียนยังปฏิเสธที่จะอ้างว่าผ่านการตรวจสอบระดับเซิร์ฟเวอร์ ซึ่งเป็นส่วนที่จะบอกได้จริงว่ามันทนทานภายใต้การทำ batching จริงหรือไม่

และมันไม่ได้หมายความว่า Qwen3.8-Flash-Next เป็นผลิตภัณฑ์ที่รองรับบน Ascend หรือที่อื่นใดในบิลด์เอนจินที่จัดส่งแล้ว เส้นทาง Qwen4Exp ในรันไทม์โอเพนซอร์สหลักทั้งสองเป็น pull request ที่ยังไม่ถูก merge ไม่มีเวอร์ชัน SGLang หรือ vLLM ที่เผยแพร่แล้วซึ่งคุณสามารถติดตั้งและให้บริการสถาปัตยกรรมนี้ได้โดยเนทีฟ — ความสะดวกแบบ FastAPI ของเอนด์พอยต์ที่โฮสต์ไว้เป็นคนละเรื่องกับเคอร์เนลที่คุณรันเองได้ และช่องว่างระหว่างสองสิ่งนี้คือสิ่งที่ PR แบบนี้มีไว้เพื่อ

สิ่งที่คุณสามารถโทรได้จริงระหว่างรอ

หากเหตุผลที่คุณสนใจ Qwen4Exp คือคุณต้องการทดสอบพฤติกรรมบริบทยาวของสถาปัตยกรรมนี้ มากกว่าส่วนภายในเคอร์เนล โมเดลที่คุณควรเลือกใช้คือระดับที่ Alibaba ให้บริการจริง Qwen3.8-Flash — รุ่นโปรดักชันที่สร้างบน Qwen3.8-Flash-Next พร้อมเครื่องมือในตัวอย่างเป็นทางการและบริบทขนาด 1,000,000 โทเคน — เปิดใช้งานจริงบน OrcaRouter ในชื่อ qwen/qwen3.8-flash: อินพุตข้อความ รูปภาพ และวิดีโอ, เอาต์พุตสูงสุด 131,072 โทเคน, $0.15 ต่อล้านโทเคนอินพุต และ $0.47 ต่อล้านโทเคนเอาต์พุต, โดยการอ่านแคชอยู่ที่ $0.0184 เหล่านี้คือราคาตามรายการของผู้ให้บริการที่ส่งผ่านมาโดยบวกเพิ่ม 0% ในส่วนของเรา ดังนั้นการเปลี่ยนแปลงราคาหรือขีดจำกัดของผู้ขายสำหรับโมเดลนี้จะไปถึงคุณในวันเดียวกันกับที่ประกาศ ในช่วงเจ็ดวันที่ผ่านมา การ์ดแบบเรียลไทม์แสดงความหน่วงของโทเคนแรกที่ p50 เท่ากับ 4,416 มิลลิวินาที, ประมาณ 106 โทเคนเอาต์พุตต่อวินาที และอัตราข้อผิดพลาด 2.68% — เป็นโปรไฟล์ของระดับข้อความปริมาณสูง มากกว่าจะเป็นตัวอย่างทดลองในแล็บ

ข้อแม้อย่างตรงไปตรงมาสองข้อ และเป็นสองข้อเดียวกับที่บทความพี่น้องเกี่ยวกับสถาปัตยกรรมนี้กล่าวไว้เช่นกัน ตัว Qwen3.8-Flash-Next เอง — ซึ่งเป็นเช็กพอยต์พรีวิวแบบ FP8 สิ่งที่คุณจะต้องมีเพื่อทำซ้ำการวัดเคอร์เนลเหล่านี้ในเครื่องของคุณ — ไม่ได้อยู่ในแคตตาล็อกของเรา ส่วนระดับ Flash ที่ให้บริการอยู่นั้นคือดีพลอยเมนต์โปรดักชันที่สร้างขึ้นจากมัน ไม่ใช่ชิ้นงานพรีวิวดิบ และงาน Ascend หรือ DCP ที่อธิบายไว้ข้างต้นไม่มีอยู่ในสิ่งที่คุณเรียกใช้ได้เลย เพราะยังไม่มีส่วนใดถูก merge เข้าแล้ว สิ่งที่ระดับที่ให้บริการมอบให้คุณก็คือวิธีราคาถูกในการค้นหาว่าเวิร์กโหลดของคุณมีรูปร่างเหมาะกับปัญหาที่เคอร์เนลเหล่านี้แก้หรือไม่ — พรอมป์ต์แบบเอเจนต์ที่ยาวและมีพรีฟิกซ์หนัก ๆ เทียบกับบริบทที่ยาวมาก หากใช่ ทรูพุตและพฤติกรรมแคชที่คุณสังเกตเห็นที่นั่นก็เป็นพฤติกรรมเดียวกับที่สแต็กการให้บริการของ Qwen 4 จะถูกปรับจูนเพื่อรักษาไว้

ยังมีเหตุผลเชิงโครงสร้างพื้นฐานสำหรับการไม่รอตระกูลโมเดลที่ยังไม่มีกำหนดเปิดตัวด้วย ไม่ว่าจะระดับใดก็ตามที่กลายเป็นผู้ชนะในไลน์อัป Qwen 4 ต้นทุนการสลับเป็นเรื่องของการจัดเส้นทาง มากกว่าจะเป็นโปรเจกต์การผสานรวม และ API เดียวสำหรับมากกว่า 200 โมเดลคือวิธีที่คุณรักษาทางเลือกนั้นไว้โดยไม่ต้องมีสัญญาที่สองหรือเปลี่ยนแปลงโค้ดเมื่อน้ำหนักโมเดลพร้อมใช้งาน การสลับไปใช้ระบบสำรอง (failover) จึงสำคัญด้วยเหตุผลเดียวกันในแบบเฉพาะเจาะจง: ถ้าคุณต้องการพัฒนาโดยอิงกับระดับที่ยังไม่ผ่านการพิสูจน์ คุณอยากให้คำขอสลับไปยังสิ่งที่มั่นคง แทนที่จะล้มเหลว เมื่อเส้นทางที่คุณเดิมพันไว้กำลังมีช่วงเวลาที่ไม่ดี

สามคำถามที่คุ้มค่าที่จะตอบโดยตรง

SGLang #41855 หมายความว่า Qwen 4 ออกแล้ว หรือแค่เปิดให้ดูตัวอย่างได้?

ไม่ครับ ทั้งสองข้อไม่จริง พูลรีเควสนี้พุ่งเป้าไปที่สถาปัตยกรรม Qwen4Exp ตามที่นำมาใช้ใน Qwen3.8-Flash-Next ซึ่ง Alibaba เปิดตัวเมื่อ 2026-08-24 มันไม่ได้แตะ weights ของ Qwen 4 และไม่มี tier ใดของ Qwen 4 ที่มี weights ให้แตะ สัญญาณที่ควรอ่านตรงนี้เป็นเรื่องเกี่ยวกับความจุในการให้บริการสำหรับสถาปัตยกรรมพรีวิว ไม่ใช่เกี่ยวกับความพร้อมใช้งานของตระกูลนี้

ถ้าการ์ดโมเดลเขียนว่า qwen4_exp นั่นคือ Qwen 4 ใช่ไหม

ไม่ — และนี่คือกับดักด้านการตั้งชื่อในเรื่องราวทั้งหมด qwen4_exp คือตัวระบุสถาปัตยกรรมภายใน และเป็นสิ่งที่คุณจะพบใน config.json สำหรับ Qwen3.8-Flash-Next และโมเดลพี่น้อง FP8 ของมัน “สถาปัตยกรรมเชิงทดลอง” คือคำสำคัญที่ต้องจับตา: ค่าน้ำหนักถูกเผยแพร่แล้ว สถาปัตยกรรมมีอยู่จริง และโมเดลนี้เป็นตัวอย่างล่วงหน้าของสิ่งที่คาดว่าตระกูล Qwen 4 จะถูกสร้างขึ้นบนพื้นฐานนั้น การค้นหาตัวระบุนี้แล้วพบ PR ของ SGLang หรือ vLLM ที่มี Qwen4Exp ในชื่อเรื่อง บอกคุณได้แค่ว่าเป็นงานของเอนจิน ไม่ใช่การเปิดตัว

นี่คือเรื่องราวการแข่งขันระหว่าง Ascend กับ NVIDIA ใช่ไหม

ไม่เชิง เส้นทาง attention แบบเดียวกันนี้ก็ต้องใช้อะแดปเตอร์เฉพาะทางฝั่ง NVIDIA เช่นกัน — การทำ context parallelism ระดับ decode สำหรับ QSA ใน vLLM และเคอร์เนล prefill แบบ sparse ที่เป็นเนทีฟสำหรับ Hopper — และปัญหาของ DGX Spark ก็แสดงให้เห็นว่าเวลาเคอร์เนลของ QSA, PLE และ Gated DeltaNet ก็ครองเวลา decode ที่นั่นเช่นกัน ตัวจัดทำดัชนี micro-block ของ QSA และสถานะ selector ที่ถูกทำสำเนาของมันไม่ใช่สิ่งที่เคอร์เนล paged-attention ทั่วไปคาดคิดไว้เลย สิ่งที่ Ascend นำมาเสริมในรูปแบบนี้คือข้อจำกัดที่คมชัดกว่า: ตัวจัดเรียงแบบ head-ratio ที่รับเฉพาะเลขยกกำลังของสอง ซึ่งบังคับให้ต้องมี padding ที่อะแดปเตอร์ต้องซ่อนไว้

สิ่งที่ต้องจับตา

ไม่ใช่ว่ามันจะ merge หรือไม่ ตัว adapter นั้นซื่อตรงว่ามันเป็น adapter การทดสอบความถูกต้องสามารถทำซ้ำได้โดยไม่ต้องมี checkpoint และผู้เขียนได้ชี้ธงคำถามเรื่องการรวมระบบไว้ แทนที่จะทำเป็นว่ามันได้ข้อสรุปแล้ว สิ่งที่ต้องจับตาคือสิ่งที่เกิดขึ้นหลังจากไลน์เปิดใช้งาน NPU กับเส้นทาง attention นี้ถูกรวมเข้าด้วยกัน — ว่าแบรนช์ที่รวมแล้วจะได้รับการรันแบบ end-to-end ที่ทั้งสองอย่างไม่เคยมีหรือไม่ บนการแบตช์จริงกับโมเดลเต็ม แทนที่จะเป็นเทนเซอร์รูปทรงหัวเฉพาะที่ ตัวเลข 1.713× คือตัวที่จะถูกพูดถึงกันไปทั่ว และมันเป็นตัวที่คำนวณบน build ที่ต่างออกไป บน checkpoint ที่ถูกดัดแปลง โดยมี indexer ที่ไม่ทำงาน ตัวเลขที่วัดได้บนสแตกที่เสร็จสมบูรณ์จะคุ้มค่ามากกว่าตัวเลขในอดีตอย่างมาก

จนกว่าจะถึงตอนนั้น สรุปที่ตรงไปตรงมาคือสรุปที่ตัว PR เองยึดถือ: การคำนวณถูกต้อง แฟล็กถูกปิดโดยค่าเริ่มต้น CI แดง และโมเดลในชื่อเรื่องยังไม่มีอยู่จริง