Qwen 4 หลุด: SGLang แบ่ง Qwen4Exp Prefill เป็นชาร์ด เพื่อให้ TT เร็วขึ้น 18% และได้คืน 1 GiB ต่อ GPU

พูลรีเควสต์ที่ถูกเปิดในรีโพซิทอรี SGLang เมื่อเวลา 03:47 UTC เช้าตรู่ของวันนี้ 2026-10-08 ให้สัญญาสิ่งหนึ่งที่การประกาศเกี่ยวกับ Qwen 4 ใด ๆ ยังไม่เคยให้ได้ นั่นคือ ตัวเลข มีชื่อว่า feat(qwen4-exp): enable LayerNorm sequence parallelism for GR and PLEและบน GPU H20 สี่ตัวที่รันเช็กพอยต์ Qwen3.8-Flash-Nextแบบเปิดน้ำหนักใน FP8 ผู้เขียนรายงานว่าได้เวลาถึงโทเคนแรก (time-to-first-token) ดีขึ้น 17.7–18.4% ที่อินพุต 32K และ 14.6–14.7% ที่อินพุต 235K ได้หน่วยความจำพีกคืนกลับมาประมาณหนึ่งกิกะไบต์ต่อ GPU และปริมาณงานอินพุตเพิ่มขึ้นสูงสุด 22% Qwen 4เอง — ตระกูลที่ผู้ขายตั้งชื่อไว้แต่ไม่ได้ส่งมอบในงานประชุม Apsara ที่หางโจวเมื่อ 2026-09-22 — ยังไม่เปิดตัว โดยไม่มีน้ำหนัก ไม่มีตัวระบุ และไม่มีราคา โมเดลเดียวที่ทำให้สถาปัตยกรรม Qwen4Exp เกิดขึ้นจริงในวันนี้คือ Qwen3.8-Flash-Next ซึ่งเผยแพร่เมื่อ 2026-08-26 และคู่หูแบบ managed ของมันอย่าง Qwen3.8-Flashคือเวอร์ชันที่ผู้เรียก API เข้าถึงได้จริง ดังนั้นจงอ่านสิ่งที่ตามมานี้ในสิ่งที่มันเป็นจริง ๆ นั่นคือ การวัดแบบจับคู่ของวิศวกรคนหนึ่ง แนบมากับพูลรีเควสต์แบบเปิด ร่าง และยังไม่ถูก merge เกี่ยวกับขอบเขตการให้บริการของตระกูลโมเดลที่ยังไม่มีอยู่จริง

เริ่มจากแหล่งที่มาก่อน เพราะนี่เป็นชิ้นงานที่รั่วไหล และการแยกแยะนี้มีผลจริง สัญญาณคือ sgl-project/sglang#43048, เปิดเมื่อ 2026-10-08 เวลา 03:47 UTC โดยบัญชี GitHub shiyang814-cpu, แก้ไขล่าสุดเมื่อ 03:55 UTC และยังคงถูกทำเครื่องหมายว่า ฉบับร่าง, โดยไม่มีการบันทึกการรีวิวที่อนุมัติ และไม่มีการ merge. มันเปลี่ยนแปลงหกไฟล์ — ไฟล์ทดสอบสองไฟล์, ไฟล์โมเดล Qwen4Exp, โมดูล LayerNorm-SP, แฟกทอรีขอบเขตเลเยอร์ และฮุกกลุ่มอาร์กิวเมนต์ — เป็น +345 และ −50 บรรทัด. ตัวเลขประสิทธิภาพทั้งหมดด้านล่างมาจากคำอธิบาย PR, เป็นการวัดแบบ OFF/ON ที่จับคู่โดยผู้เขียนเอง, และยังไม่มีใครทำซ้ำได้. การรัน CI สามครั้งบนรีวิชันที่ปลายสุดของสาขาถูกทำเครื่องหมายว่าล้มเหลว. ไม่มีอะไรที่นี่เป็นความสามารถที่ส่งมอบแล้ว.

สิ่งที่ pull request เปลี่ยนแปลงจริง ๆ

Sequence parallelism ไม่ใช่การเปลี่ยนแปลงของโมเดล และไม่ใช่ความสามารถใหม่ มันเป็นการเดินสายใหม่ของตำแหน่งที่เลเยอร์ไม่กี่ชั้นทำการคำนวณ เชื้อสายของมันย้อนไปถึง sequence parallelism สไตล์ Megatron — เทคนิคจาก arXiv:2205.05198 — และ SGLang ก็มีให้ใช้อยู่แล้ว: docstring ของโมดูลเองอธิบายกลไกที่มันนำกลับมาใช้ ว่าภายใต้ pure tensor parallelism แล้ว row-parallel all_reduce ทางพีชคณิตคือ reduce_scatter ตามด้วย all_gather เพราะว่า collective สองตัวนั้นเคลื่อนย้ายไบต์เท่ากันเป๊ะกับ all_reduce ที่มันแทนที่ การแยกการดำเนินการแบบนั้นไม่มีค่าใช้จ่ายด้านปริมาณการสื่อสารเพิ่มเลย สิ่งที่ได้มาคืออิสระในการปล่อยให้บริเวณ normalization และ residual ทำงานบน sequence-sharded แอ็กติเวชัน — โดยแต่ละ rank ของ tensor-parallel ถือหนึ่ง-1/tpของแถวโทเคน — ซึ่งลดหน่วยความจำแอ็กติเวชันชั่วคราวที่ long-context prefill ต้องเก็บไว้ให้คงอยู่

สิ่งที่ pull request นี้ทำคือการขยายเส้นทางที่มีอยู่แล้วจากสถาปัตยกรรมที่ได้รับการตรวจสอบไปยังสถาปัตยกรรม Qwen4Exp ในระหว่าง prefill การเปิดใช้งาน Gated Residual และ Per-Layer Embedding จะยังคงถูกแบ่งส่วนตามมิติโทเค็นทั่วทั้งกลุ่ม TP ก่อน attention ก่อน GDN ก่อน QSA และก่อนที่บล็อก Mixture-of-Experts จะทำงาน แถวโทเค็นแบบเต็มจะถูก all-gathered กลับมา การคำนวณ tensor-parallel แบบเต็มแถวที่มีอยู่จะทำงานเหมือนเดิมภายใต้ fallback ที่ใช้ร่วมกัน และ reduce-scatter จะรวมส่วนสนับสนุนบางส่วนและคืนค่า shard ของแต่ละ rank การ decode ไม่แตะต้องเส้นทางใหม่เลย คุณสมบัตินี้เข้าถึงได้ผ่านตัวเลือกที่มีอยู่แล้ว — --enable-layernorm-sp — โดยไม่มีแฟล็กเฉพาะสำหรับ Qwen4Exp และเมื่อไม่มีแฟล็ก โค้ดจะทำงานเหมือนเดิมทุกประการ

ทำไม Qwen4Exp จึงเป็นสถาปัตยกรรมที่ต้องการสิ่งนี้

เหตุผลที่เรื่องนี้สำคัญเป็นพิเศษสำหรับ Qwen4Exp โดยเฉพาะ และไม่สำคัญเท่ากันสำหรับทุกโมเดล อยู่ในการออกแบบของสถาปัตยกรรมเอง Qwen3.8-Flash-Next ใช้ Gated Residual projections กับ ทุกแถวโทเค็นในทุกเลเยอร์ดีโคดเดอร์ — การกำหนดค่าประกาศ residual streams สี่สายและ bottleneck rank เป็น 320 ตลอด 48 เลเยอร์ — และ Per-Layer Embedding เพิ่ม projection ชุดที่สองที่ถูกทำซ้ำ แบบทีละแถวโทเค็นซ้อนทับลงไปอีก ภายใต้ tensor parallelism การดำเนินการทั้งสองนั้นถูกทำซ้ำเหมือนกันบนทุก rank เพราะมันไม่มี weight matrix ที่ถูกแบ่งด้วย TP เป็นของตัวเองที่จะบังคับให้เกิดการแยก การ shard มิติโทเค็นของมันจะกำจัดงานที่ทำซ้ำนั้นโดยตรง และตามที่ส่วน motivation ของ PR กล่าวไว้ สิ่งนั้นเกิดขึ้นพร้อมกับการรักษา layout tensor-parallel ที่มีอยู่ และ reduction semantics ของ attention, GDN/QSA และ MoE — ซึ่งเป็นส่วนที่ทำให้การเปลี่ยนแปลงนี้ปลอดภัยมากกว่าจะฉลาด

ควรพูดให้ชัดเจนว่าสิ่งนั้นหมายความว่าอย่างไรสำหรับผู้อ่าน สิ่งที่น่าสนใจเกี่ยวกับ PR นี้ไม่ใช่ว่า SGLang กำลังเร็วขึ้น แต่มันคือว่าสถาปัตยกรรม Qwen4 มีต้นทุนต่อเลเยอร์ที่แปรผันตามจำนวนโทเคน แทนที่จะเป็นจำนวนพารามิเตอร์ และต้นทุนเหล่านั้นคือสิ่งที่สร้างปัญหากับ prefill ที่ยาว นั่นคือเอกลักษณ์เฉพาะของการออกแบบ และเป็นสิ่งประเภทที่สเปกชีตไม่เคยกล่าวถึง

ส่วนต่างที่วัดได้

การทดสอบ benchmark ของผู้เขียนกำหนดค่าคอนฟิกูเรชันหนึ่งแบบตายตัวและสลับเปิด-ปิดแฟล็ก: GPU NVIDIA H20 สี่ตัว, Qwen3.8-Flash-Next-FP8, tensor parallel 4 และ expert parallel 4, chunked prefill size 8192, แบ็กเอนด์ prefill และ decode แบบ linear-attention ของ FlashInfer, คอนฟิกูเรชันเซิร์ฟเวอร์เดียวกันทั้งตอน OFF และ ON, สลับรีสตาร์ตเซอร์วิสแบบ OFF → ON → OFF → ON, และอินพุตโทเคนแบบคงที่พร้อมคำขอ warmup ตัวเลขทุกตัวด้านล่างมาจากการตั้งค่านั้นและยังไม่ได้ตรวจสอบ:

• อินพุต 32K, ขนาดแบตช์ 1 — TTFT ดีขึ้น 17.72–18.36%, ความหน่วงแบบ end-to-end ประมาณ 16%, ทรูพุตอินพุตประมาณ 20%

• อินพุต 235K, ขนาดแบตช์ 1 — TTFT ดีขึ้น 14.63–14.71%, ความหน่วงแบบ end-to-end ประมาณ 14%, ทรูพุตอินพุตประมาณ 17%

• อินพุต 32K, ขนาดแบตช์ 4 — TTFT ดีขึ้น 18.74%, ความหน่วงแบบ end-to-end 18.14%, ทรูพุตอินพุต 22.14%

• หน่วยความจำสูงสุด — ลดลงประมาณ 1.0 GiB ต่อ GPU

• การถอดรหัส, ขนาดแบตช์ 1 — เวลาต่อโทเคนเอาต์พุตแทบไม่เปลี่ยนแปลง

บรรทัดสุดท้ายคือบรรทัดที่ต้องอ่านสองครั้ง และผู้เขียนก็ตรงไปตรงมาเกี่ยวกับสาเหตุ: การปรับแต่งนี้เปิดใช้งานเฉพาะสำหรับ prefill เท่านั้น ดังนั้นการถอดรหัสแบบสตรีมเดียวจึงไม่ได้รับประโยชน์ใดๆ จากมัน การปรับปรุงเวลาต่อโทเคนของแบตช์ 4 ในจุดที่ปรากฏ สะท้อนถึงความล่าช้าในการจัดตารางเวลาที่ลดลงจากการเติมข้อมูลล่วงหน้าที่ยาวนานพร้อมกัน มากกว่าที่จะเป็นเคอร์เนลถอดรหัสที่เร็วกว่า หากคุณหวังว่านี่จะเป็นเรื่องของปริมาณงาน มันไม่ใช่ — มันเป็นเรื่องของความหน่วงไปยังโทเคนแรกและหน่วยความจำ และนั่นคือข้อจำกัดสองประการที่ตัดสินว่าคำขอ 235K โทเคนจะสามารถให้บริการได้หรือไม่

บั๊กเลย์เอาต์ที่พวกเขาต้องแก้ไขก่อน

ส่วนที่ให้ข้อมูลมากที่สุดของ pull request ไม่ใช่ตารางความเร็ว แต่เป็นส่วนเกี่ยวกับเลย์เอาต์แถวเชิงกายภาพของ PLE เพราะมันแสดงให้เห็นว่าสแตกการให้บริการ Qwen4Exp ยังทำอะไรผิดพลาดอยู่

Per-Layer Embedding ทำงานบน bucket ทางกายภาพคงที่ของ CUDA-graph โดยมีเพียงส่วนนำหน้าของแถวใน bucket นั้นเท่านั้นที่อาจมีโทเคนจริง ดังนั้นจึงต้องทำ padding ก่อนที่ลำดับจะถูกแบ่งเป็นชาร์ด ไม่ใช่หลังจากนั้น ใน chunk สุดท้ายของคำขอขนาด 235K โทเคน ตัวเลขของผู้เขียนคือ 5,624 โทเคนที่ประมวลผลแล้วภายใน bucket ทางกายภาพขนาด 8,192 แถวที่ TP 4 และเลย์เอาต์ที่ถูกต้องเพียงแบบเดียวคือ rank 0 มี 2,048 แถวที่ใช้ได้, rank 1 มี 2,048 แถวที่ใช้ได้, rank 2 มี 1,528 แถวที่ใช้ได้บวก 520 แถว padding, และ rank 3 มี 2,048 แถวที่เป็น padding การ shard 5,624 แถวที่ประมวลผลแล้วก่อน — ซึ่งเป็นการนำไปใช้แบบตรงไปตรงมา — จะแทรก padding ระหว่างช่วงที่ใช้ได้ซึ่งต่อเนื่องกันในระดับ global และทำให้ผลลัพธ์เสียหาย ผู้เขียนบันทึกว่าการทดสอบ OFF/ON ขนาด 235K จริงให้เอาต์พุต greedy 16 โทเคนที่เหมือนกันเฉพาะ หลังจากที่เลย์เอาต์นี้ได้รับการแก้ไขแล้ว

นั่นเป็นรายละเอียดเล็ก ๆ ที่มีนัยสำคัญมาก เส้นทาง PLE ใน SGLang ถูกเพิ่มเข้ามาเมื่อไม่นานมานี้พอที่บั๊กการจัดลำดับโทเค็นในลักษณะนี้จะยังเกิดขึ้นได้ และคนที่พบมันกำลังเขียนส่วนขยายแบบ sequence-parallel อยู่ การรองรับการให้บริการตั้งแต่วันแรกสำหรับสถาปัตยกรรมนี้ยังไม่เสร็จสิ้น มันกำลังถูกสร้างขึ้นอย่างจริงจัง ต่อสาธารณะ โดยผู้มีส่วนร่วม ทีละเลย์เอาต์

ราคาที่คุณต้องจ่าย: ข้อจำกัด

แฟล็กที่ช่วยได้เพียงบางการติดตั้งใช้งานจะมีประโยชน์ก็ต่อเมื่อคุณรู้ว่าช่วยอันไหน PR ระบุข้อกำหนดของตัวเองไว้อย่างชัดเจน และการกำหนดค่าที่อยู่นอกเหนือข้อกำหนดเหล่านั้นจะล้มเหลวระหว่างการตรวจสอบอาร์กิวเมนต์ แทนที่จะเสื่อมประสิทธิภาพลงอย่างเงียบ ๆ:

• ขนาดของ tensor parallel ต้องมากกว่า 1 — การปรับใช้บน GPU เดียวไม่ได้รับประโยชน์ใด ๆ เพราะไม่มี rank ให้แบ่งกระจาย

• ขนาด Expert parallel ต้องเท่ากับขนาด Tensor parallel

• ขนาดของ pipeline parallel ต้องเท่ากับ 1

• ความสนใจแบบขนานข้อมูลต้องถูกปิดใช้งาน

• ต้องปิดใช้งาน speculative decoding

ข้อจำกัดสุดท้ายคือข้อที่มีการตัดสินใจจริงอยู่เบื้องหลัง สำหรับโมเดลแบบ sparse ที่เปิดใช้งานพารามิเตอร์ราว 6B ต่อโทเคน การถอดรหัสแบบ speculative เป็นหนึ่งในไม่กี่กลไกที่เร่งdecode และฟีเจอร์นี้ปิดกลไกนั้นอย่างชัดเจนเพื่อแลกกับผลตอบแทนด้าน prefill หากเวิร์กโหลดของคุณเป็นพรอมป์ยาวและเอาต์พุตสั้น — การวิเคราะห์เอกสารและโค้ดเบส การสรุปวิดีโอ การอ่านบริบทขนาดใหญ่เพียงครั้งเดียว — การแลกเปลี่ยนนี้ถือว่าดีอย่างตรงไปตรงมา หากเวิร์กโหลดของคุณเป็นพรอมป์สั้นและการสร้างยาว คุณกำลังสละสิ่งที่ช่วยคุณอยู่ และซื้อตัวเลขที่ไม่เกี่ยวข้องกับคุณ ข้อกำหนดที่ว่า expert-parallel เท่ากับ tensor-parallel เป็นอีกข้อที่ควรสังเกต: มันหมายความว่าเรขาคณิตของการแบ่ง shard ของ moe ต้องสอดคล้องกับเรขาคณิตของ TP อย่างแม่นยำ ซึ่งตัดเลย์เอาต์แบบหลายโหนดที่ไม่เช่นนั้นก็สมเหตุสมผลหลายแบบออกไป

สิ่งนี้บอกอะไรเกี่ยวกับไทม์ไลน์ของ Qwen 4

อ่าน diff ในอีกมุมหนึ่ง แล้วคุณจะเห็นปฏิทิน โมดูล LayerNorm-SP ของ SGLang บนแบรนช์ main ในปัจจุบันมี allowlist ที่ระบุสถาปัตยกรรมซึ่งฟีเจอร์นี้ผ่านการตรวจสอบความถูกต้องแล้วอย่างชัดเจน และ ณ ขณะที่เขียนนี้ allowlist นั้นมีรายการอยู่เพียงรายการเดียวพอดี Qwen3ForCausalLM — สถาปัตยกรรมอื่นทั้งหมดจะถูกปฏิเสธตั้งแต่ขั้นตอนการสร้าง หากคุณส่งแฟล็กนี้เข้าไป ดังนั้นการเพิ่ม Qwen4Exp เข้าไปในเส้นทางนั้นจึงไม่ใช่การปรับแต่งเล็กน้อยบนนามธรรมที่เติบโตเต็มที่แล้ว หากแต่เป็นครั้งแรกที่สถาปัตยกรรม Qwen4 ถูกนำมาสู่ออปติไมเซชันที่ถือกำเนิดมาก่อนมันหลายเจนเนอเรชัน

เมื่อนำไปเทียบกับบันทึกสาธารณะ ภาพก็สอดคล้องกัน ผู้จำหน่ายประกาศเมื่อวันที่ 22 กันยายน 2026 ว่า Qwen 4 อยู่ระหว่างการฝึก และเปิดตัวชื่อระดับสี่ชื่อ — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus และ Qwen 4 27B — โดยไม่มีข้อมูลจำเพาะใด ๆ แนบมากับชื่อเหล่านั้น ตัวอย่างน้ำหนักเปิดที่ใช้สถาปัตยกรรมร่วมกัน คือ Qwen3.8-Flash-Next สามารถดาวน์โหลดได้ตั้งแต่วันที่ 26 สิงหาคม 2026 สิ่งที่เกิดขึ้นในสามสัปดาห์นับจากนั้นคือสิ่งที่คุณคาดหวังได้ระหว่าง "อยู่ระหว่างการฝึก" กับ "เปิดตัว" นั่นคือผู้พัฒนาเอนจินกำลังทดสอบรันไทม์เพื่อให้การสนับสนุนตั้งแต่วันแรกเป็นจริง ไม่ใช่เพียงในนาม พูลรีเควสต์ที่ทำให้การปรับประสิทธิภาพการให้บริการทำงานบนสถาปัตยกรรมนี้ ซึ่งเปิดเมื่อเช้าวันที่ 8 ตุลาคม 2026 และยังอยู่ในฉบับร่าง เป็นสัญญาณที่ดีกว่าวันใด ๆ ที่มีคนเสนอ เกี่ยวกับว่า Qwen 4 ใกล้จะให้บริการได้แค่ไหน และมันไม่ใช่วันเปิดตัวอย่างหนักแน่น — แฟล็กถูกปิดโดยค่าเริ่มต้น การเปลี่ยนแปลงยังไม่ถูกผสาน และโมเดลที่ใช้ทดสอบประสิทธิภาพคือตัวอย่าง ไม่ใช่ Qwen 4

สิ่งที่คุณสามารถโทรหาได้ในวันนี้

ทั้งหมดนี้ไม่ได้เปลี่ยนแปลงสิ่งที่พร้อมใช้งานจริงในบ่ายวันนี้ Qwen3.8-Flash-Next มีอยู่จริง น้ำหนักของมันอยู่บน Hugging Face และคุณสามารถโฮสต์เองได้ — แต่มันไม่ได้อยู่ในแคตตาล็อกของเรา และเราจะไม่แสร้งทำเป็นอย่างอื่น ระดับที่เราให้บริการจริงคือ qwen/qwen3.8-flash ซึ่งเป็นรุ่นพี่น้องแบบมีผู้ดูแลจัดการที่รันสถาปัตยกรรม Qwen4-preview เดียวกัน ด้วยหน้าต่างบริบท 1 ล้านโทเคน และรองรับอินพุตทั้งข้อความ รูปภาพ และวิดีโอ ราคาอยู่ที่ $0.15 ต่อล้านโทเคนอินพุต $0.47 ต่อล้านโทเคนเอาต์พุต และ $0.0184 ต่อล้านโทเคนที่อ่านจากแคช นั่นคือราคาตามรายการที่ส่งผ่านโดยบวกกำไร 0% ดังนั้นเมื่อผู้ขายปรับราคา ตัวเลขในใบแจ้งหนี้ของคุณก็จะเปลี่ยนตามในวันเดียวกัน แทนที่จะรอให้คนกลางประกาศตารางราคาใหม่

ยังมีเหตุผลประการที่สองที่ชัดเจนน้อยกว่าในการให้ความสำคัญกับเลเยอร์การกำหนดเส้นทางตรงนี้ ทุกอย่างในบทความนี้เกี่ยวกับพรีวิวที่ยังไม่ผ่านการพิสูจน์ บวกกับแพตช์ฉบับร่าง — สิ่งที่คุณอยากทดสอบโดยไม่เดิมพันเส้นทางโปรดักชันกับมัน นั่นคือสิ่งที่ระบบสำรองเมื่อขัดข้องมีไว้สำหรับ: วางพรีวิวไว้หลังคีย์เดียวกับโมเดลที่คุณเชื่อถืออยู่แล้ว เฝ้าดูว่ามันทำงานอย่างไรกับทราฟฟิกของคุณ แล้วปล่อยให้คำขอไหลต่อไปยังเส้นทางที่รู้ว่าใช้งานได้ดีเมื่อผู้ให้บริการสะดุดหรือปลายทางไม่มีอยู่ API เดียวสำหรับโมเดล 200+ ตัว ข้อมูลรับรองชุดเดียว ไม่ต้องเซ็นสัญญาฉบับที่สองเพื่อค้นหาว่าสถาปัตยกรรมใหม่คุ้มค่ากับความสนใจของคุณหรือไม่

สองสิ่งที่ต้องจับตาจากตรงนี้ ซึ่งเราไม่อาจคาดการณ์ได้ทั้งคู่ สิ่งแรกคือแพตช์นี้จะถูก merge หรือไม่: มันเป็นฉบับร่างที่มีการรัน CI ล้มเหลวสามครั้งบนการเปลี่ยนแปลงหกไฟล์จากบัญชีผู้มีส่วนร่วมที่ไม่มีประวัติในรีโพซิทอรีมาก่อน และความไม่นิ่งของงานจัดวางแถว PLE บ่งชี้ว่าผู้เขียนยังคงวนปรับแก้อยู่ สิ่งที่สองคือ allowlist จะขยายหรือไม่ — หาก Qwen4Exp เข้าร่วม Qwen3ForCausalLM ในฐานะสถาปัตยกรรมที่ผ่านการตรวจสอบแล้ว นี่จะเลิกเป็นการรั่วไหลและกลายเป็นวิธีเริ่มต้นในการให้บริการโมเดลตระกูล Qwen4 บนบริบทยาว จนกว่าหนึ่งในสิ่งเหล่านั้นจะเกิดขึ้น ให้มอง 18% เป็นคำสัญญาเกี่ยวกับทิศทางที่รันไทม์กำลังมุ่งไป ไม่ใช่ตัวเลขที่คุณเช่าใช้ได้