Qwen 4 หลุด: PR Host-Staging ของ SGLang เผยให้เห็นว่าตาราง PLE ขนาด 47.7 GiB พอดีกับ GPU เพียงตัวเดียวได้อย่างไร

ตัวเลขที่จะตัดสินว่า Qwen 4เป็นโมเดลที่คุณให้บริการเองได้หรือไม่ ไม่ใช่จำนวนพารามิเตอร์ของมัน แต่คือ 47.7 GiB — ขนาดของตาราง embedding แบบ n-gram ที่อยู่เคียงข้างสถาปัตยกรรม Qwen4 แยกจาก weights และต้องมีที่อยู่ในหน่วยความจำสักแห่งระหว่างที่โมเดลถอดรหัส pull request หนึ่งรายการที่เปิดในรีโพซิทอรี SGLang เมื่อวันที่ 18 กันยายน 2026 ในชื่อ [Qwen4-Exp] เพิ่ม host staging สำหรับ PLE ที่อิงไฟล์ เป็นความพยายามที่จะหยุดไม่ให้ตารางนั้นกำหนดว่าเครื่องหนึ่งต้องมี RAM เท่าใดก่อนจึงจะรันได้เลย Qwen 4 ยังไม่เปิดตัว: ไม่มีการ์ดโมเดล ไม่มี weights ไม่มีรายการในแค็ตตาล็อก ไม่มีกำหนดวัน โมเดลเดียวที่ส่งมอบแล้วซึ่งทำให้สถาปัตยกรรมนี้เป็นรูปเป็นร่างคือ Qwen3.8-Flash-Next พรีวิวแบบเปิด weights ที่เผยแพร่เมื่อวันที่ 26 สิงหาคม 2026 ซึ่งการตั้งค่าของมันประกาศว่า model_type=qwen4_exp — สตริงเดียวกับที่ทำให้ pull request ได้ชื่อนี้ พี่น้องฝ่ายโปรดักชันของมัน Qwen3.8-Flash คือเวอร์ชันที่ผู้เรียก API เข้าถึงได้จริงในวันนี้ ทุกอย่างในบทความนี้เกี่ยวกับ Qwen 4 ล้วนเป็นการอนุมานจากพรีวิวนั้นและจากโค้ดของเอนจิน; pull request ยังเปิดอยู่และยังไม่ถูก merge ดังนั้นจงอ่านทั้งหมดนี้เป็นสัญญาณ ไม่ใช่ความสามารถที่ส่งมอบแล้ว

สัญญาณที่แท้จริงคืออะไร

พูลรีเควสต์ sgl-project/sglang#40235 ไม่ใช่การเปิดตัวและยังไม่ถูกเมิร์จ มันอยู่บนคอมมิตเดียว เปิดโดยผู้มีส่วนร่วม Dev-Jahn ซึ่งผสานสาขาชื่อ task/ple-host-staged เข้ากับสายหลักของ SGLang มีเจ้าของโค้ดเก้ารายถูกขอให้รีวิว และทุกรายแสดงสถานะรออยู่ ดังนั้นอย่างน้อยต้องมีรีวิวอนุมัติหนึ่งรายการกั้นระหว่าง PR นี้กับ main งาน CI สามงาน — การทดสอบ PR พื้นฐาน การทดสอบ PR เพิ่มเติม และการรัน AMD ROCm — กำลังล้มเหลวบนคอมมิตที่เปิดอยู่ นั่นคือสภาวะปกติของการเปลี่ยนแปลงเอนจินขนาดใหญ่ที่กำลังดำเนินอยู่ และยังเป็นเหตุผลว่าทำไมส่วนที่น่าสนใจของ PR นี้จึงไม่ใช่ว่ามันจะถูกรวมหรือไม่ แต่เป็น สิ่งที่ผู้เขียนต้องวัดเพื่อโต้แย้งสนับสนุนมัน. คำอธิบายมีบรรทัดเพิ่มเข้ามาประมาณ 1,400 บรรทัดรวมการทดสอบ และตาราง benchmark ที่เป็นข้อมูลสาธารณะที่ชัดเจนที่สุดเท่าที่มีใครเผยแพร่เกี่ยวกับการรันสถาปัตยกรรมนี้บน GPU ตัวเดียว.

ทำไมตารางจึงเป็นเรื่องทั้งหมด

Per-Layer Embeddings คือความแปลกเชิงโครงสร้างของรุ่นนี้ โดยที่โมเดลปกติจะวางการฝังโทเคนหนึ่งรายการไว้ด้านหน้า การออกแบบของ Qwen4 กลับมีตาราง n-gram ขนาดใหญ่ — ไบแกรมและไตรแกรม ซึ่งถูกแฮชเข้าสู่คำศัพท์ที่ใหญ่กว่าคำศัพท์ของโทเคไนเซอร์มาก — และป้อนการค้นหาการฝังแบบรายชั้นจากตารางนี้ตลอดทั้งสแตก เอกสารตัวอย่างของ Alibaba เองอธิบายว่าองค์ประกอบ n-gram มีพารามิเตอร์หลายหมื่นล้านตัวบนตัว MoE ขนาด 125B พารามิเตอร์; การแกะตรวจสอบโดยชุมชนของเช็กพอยต์ที่เผยแพร่ระบุว่าไฟล์ตารางมีขนาด 47.7 GiB ตัวเลขเหล่านั้นมาจากแหล่งของผู้จำหน่ายและชุมชน ไม่ใช่การทำซ้ำโดยอิสระ และความสัมพันธ์ที่แน่ชัดระหว่างตารางในตัวอย่างกับสิ่งที่ Qwen 4 จะส่งมอบนั้นยังไม่เป็นที่ทราบ

สิ่งที่ไม่ต้องกังขาคือผลที่ตามมาทางวิศวกรรม ตารางด้านข้างขนาด 47.7 GiB ที่ต้องถูกเรียกดูในทุกขั้นตอนการถอดรหัสไม่ใช่สิ่งที่คุณจะแอบผลักไปไว้มุมหนึ่งของ VRAM ได้ บนการ์ด 96 GB มันแข่งขันกับ KV cache โดยตรง ส่วนบนการ์ดที่เล็กกว่านั้นมันก็ใส่ไม่ลงเลย นั่นคือเหตุผลที่ SGLang ซึ่งเปิดให้การสนับสนุนแบบ day-0 สำหรับพรีวิวในปลายเดือนสิงหาคม ได้ใช้เวลาสามสัปดาห์ถัดมาออก pull request หนึ่งแล้วอีกหนึ่งเกี่ยวกับโครงสร้างข้อมูลเดียวนี้ แทนที่จะเป็นเกี่ยวกับโมเดลที่อยู่รายรอบมัน

อะไรที่เสียอยู่ก่อน PR นี้

SGLang มีสองวิธีในการถือตารางอยู่แล้ว และทั้งสองวิธีก็มีข้อจำกัดที่โหดร้าย

• Pinned เก็บตารางทั้งหมดไว้ใน RAM ของโฮสต์และอ่านข้อมูลจากที่นั่น ใช้งานได้ รวดเร็ว และทำให้ความต้องการหน่วยความจำของโฮสต์เป็นแบบตายตัว — ไม่มีเวอร์ชันที่ใช้หน่วยความจำน้อยกว่านี้

• แบบอิงไฟล์ ซึ่งเพิ่มเข้ามาก่อนหน้านี้ในพูลรีเควสต์แยกต่างหาก เก็บตารางไว้ในไฟล์แบบ sparse และปล่อยให้เคอร์เนล gather อ่านแมปปิงได้โดยตรง ดังนั้นแคชเพจของระบบปฏิบัติการจึงเป็นตัวกำหนดว่าส่วนใดของตารางจะพำนักอยู่ในหน่วยความจำ ปัญหาอยู่ที่ฮาร์ดแวร์: เส้นทางการอ่านโดยตรงนั้นต้องการให้ GPU รายงาน cudaDevAttrPageableMemoryAccessUsesHostPageTables — ความสามารถที่ข้อความของ PR เองเรียกง่าย ๆ ว่า "คลาส GB10" บน GPU ที่ไม่มีความสามารถนี้ ไฟล์แบ็กเอนด์จะถูกปฏิเสธโดยสิ้นเชิง และ pinned คือทางเลือกเดียวที่เหลืออยู่

ช่องว่างที่เกิดขึ้นไม่ใช่เรื่องทฤษฎี รายงานแยกฉบับหนึ่งที่ยื่นต่อเส้นทางโค้ดเดียวกันบันทึกว่ามีผู้ใช้บน RTX 3090 สองการ์ด ซึ่งส่วนแบ่งต่อแรงก์ของตารางมีค่า 23.84 GiB เทียบกับหน่วยความจำที่ใช้งานได้ 23.56 GiB — ขาดไป 0.28 GiB โดยมี RAM ของโฮสต์ว่างอยู่ 188 GiB ในการตั้งค่านั้น ไฟล์แบ็กเอนด์ถูกปฏิเสธโดยการตรวจสอบฮาร์ดแวร์ และแฟล็ก CPU-offload ธรรมดาจะเกิดข้อผิดพลาดเมื่อใช้ร่วมกับแฟล็ก PLE offload การขาดไปสามร้อยเมกะไบต์ทั้งที่มีพื้นที่ว่างหนึ่งร้อยแปดสิบกิกะไบต์ คือรูปแบบของปัญหาที่ pull request นี้มีไว้เพื่อกำจัดอย่างแม่นยำ

การเปลี่ยนแปลงการสเตจจิงของโฮสต์คืออะไร

กลไกที่ PR นี้เพิ่มเข้ามาคือชั้น staging ระหว่างไฟล์กับอุปกรณ์ แทนที่จะให้ GPU ไป dereference หน้าหน่วยความจำของโฮสต์ คอมโพเนนต์ฝั่ง CPU จะอ่านแถวที่ต้องการผ่าน mapping ที่มีอยู่แล้วของตัวโหลด และแนะนำให้เคอร์เนลดึงหน้าเหล่านั้นเข้ามาล่วงหน้า ตัวแปรสภาพแวดล้อม SGLANG_QWEN4_PLE_FILE_PREFETCH ใช้ปิดคำแนะนำนี้ได้หากต้องการวัดผลโดยไม่มีมัน จากนั้นแต่ละเลเยอร์ PLE จะได้ pinned buffer สองตัวขนาด 8,192 แถว — ประมาณ 1.25 MiB ต่อตัวที่ FP8 — และ worker หนึ่งตัว แถวจะถูก gather เข้าไปในบัฟเฟอร์ตัวหนึ่งขณะที่อีกตัวกำลังถูกคัดลอกไปยังอุปกรณ์ ทำให้การ gather และการถ่ายโอนทำงานคาบเกี่ยวกันแทนที่จะเรียงลำดับกัน ตัวระบุ N-gram ถูกแฮชบนโฮสต์แทนที่จะเป็นบนอุปกรณ์ Graph replay จะได้รับการเรียกเตรียมความพร้อมก่อนการ replay แต่ละครั้ง และเธรดที่สั่งงานจะรอขั้นตอนก่อนหน้า

รายละเอียดสุดท้ายนั้นคือต้นทุนที่ต้องจ่าย และ PR ระบุไว้อย่างตรงไปตรงมาว่า ประมาณ 0.5 ถึง 1 มิลลิวินาทีที่เพิ่มขึ้นต่อแต่ละขั้นตอนการถอดรหัส เมื่อเทียบกับเส้นทางที่ตรึงไว้ ส่วนที่เหลือทั้งหมดคือผลตอบแทนที่ได้ วัดบน RTX PRO 6000 Blackwell เครื่องเดียวที่มี 96 GB โฮสต์ AMD EPYC ที่มี RAM 377 GiB, CUDA 13.2 โดยใช้เช็คพอยต์ FP8 และ NVFP4 แบบสาธารณะของ Qwen3.8-Flash-Next:

• แคชเพจของโฮสต์, FP8 TP4/EP4 — ตรึงไว้ที่ 71 GB และไม่จำกัด เทียบกับ 49 GB เมื่อจำกัดที่ 64 GB, 15 GB ที่ 32 GB และ 6 GB เมื่อจำกัดที่ 24 GB

• ความหน่วงในการถอดรหัส ในการรันเดียวกัน — 8.62 มิลลิวินาทีต่อโทเคนที่ concurrency 1 แบบ pinned เทียบกับ 9.16 / 9.20 / 9.12 มิลลิวินาที จากการรันไฟล์แบบ capped ทั้งสามครั้ง

• การทำงานพร้อมกัน 16 — 16.54 ms แบบ pinned เทียบกับ 17.62 / 17.85 / 17.37 ms แบบ capped ซึ่งลดจาก 893 โทเค็นต่อวินาที เหลือ 827–840

• อัตราการประมวลผล Prefill — 620 โทเคนต่อวินาทีที่ 8k แบบ pinned เทียบกับ 624 / 630 / 631 แบบ capped; ที่ 32k, 1,347 เทียบกับ 1,358 / 1,359 / 1,361

• NVFP4 TP2 — 69 GB แบบ pinned เทียบกับ 24 GB เมื่อใช้ file backend ที่ขีดจำกัด 32 GB โดยอยู่ที่ 8.87 ms เทียบกับ 9.18 ms

• NVFP4 บน GPU เดียว — 69 GB แบบ pinned เทียบกับ 51 GB ที่เพดาน 64 GB ใช้เวลา 6.44 ms เทียบกับ 6.73 ms

• ทางเลือกที่มันเอาชนะได้ — การอ่านไฟล์เดียวกันผ่านการจัดการหน่วยความจำของโฮสต์บน GPU ตัวนั้นใช้เวลา 10.8 ms ที่ concurrency 1 และ 46.5 ms ที่ concurrency 16 ซึ่ง PR อธิบายว่าเป็น 2.8 เท่าของ latency แบบ pinned ที่ concurrency นั้น

ด้านความแม่นยำถูกรายงานว่าไม่มีปัญหา เอาต์พุตแบบ greedy ที่กำหนดได้แน่นอน (deterministic) จากแปดพรอมป์ต์ พรอมป์ต์ละ 256 โทเคน มีโทเคนเหมือนกันทุกประการระหว่างเส้นทาง pinned กับ file บน FP8 TP4 และ GSM8K ได้ 97.6% สำหรับ pinned เทียบกับ 98.0% สำหรับ file ที่ขีดจำกัด 64 GB — ช่องว่างหกข้อที่ผู้เขียนอ้างว่าเป็นความแปรปรวนระหว่างการรันมากกว่าเกิดจากเส้นทาง offload ตัวเลขทั้งหมดนี้เป็นของผู้เขียน pull request เอง วัดเพียงครั้งเดียว บนเครื่องเดียว และยังไม่มีใครทำซ้ำได้

ค่าใช้จ่ายที่ PR ยอมรับ

การอ่าน pull request นี้อย่างเป็นธรรมย่อมรวมถึงสิ่งที่มันปฏิเสธที่จะทำด้วย โหมดการทำงานหลายแบบถูกปฏิเสธตั้งแต่ตอนสร้าง แทนที่จะถูกทำให้เสื่อมประสิทธิภาพอย่างเงียบ ๆ และการปฏิเสธแต่ละครั้งก็ระบุ backend ที่ถูกปักหมุดไว้เป็น fallback: prefill CUDA graphs, data-parallel attention, เส้นทาง prefill-decode multiplexing, two-batch overlap, decode graphs ของ DLLM และ compact ragged verify graphs ล้วนถูกตัดออก ที่สำคัญไม่แพ้กันคือมันไม่เพิ่ม flag ใหม่และไม่มีสวิตช์ใหม่ที่ผู้ใช้เห็น — staging path คือสิ่งที่ file backend ทำบนฮาร์ดแวร์ที่ก่อนหน้านี้ไม่สามารถใช้งานมันได้เลย และการรัน accuracy มีข้อแม้ที่ผู้เขียนยอมรับเอง: การรันแบบมีเพดานไม่เคยบรรจุตารางทั้งหมดไว้ เพราะตารางมีขนาด 47.7 GiB และเพดานต่ำสุดอยู่ที่ 24 GB ดังนั้น workload ที่มีรูปแบบการเข้าถึงที่แบนราบและคาดเดาไม่ได้จริง ๆ ทั่วทั้งตารางจึงไม่ใช่สิ่งที่ถูกวัด

ทำไมเรื่องนี้จึงสำคัญสำหรับ Qwen 4 โดยเฉพาะ

ถอดรายละเอียดของเอนจินออกไป แล้วรูปแบบก็อ่านออกได้ชัด Alibaba เปิดตัวพรีวิวสถาปัตยกรรมเมื่อวันที่ 26 สิงหาคม พร้อมคำแนะนำสำหรับชุมชนโอเพนซอร์สให้เตรียมรันไทม์ การควอนไทซ์ และเอนจินสำหรับการอนุมาน ล่วงหน้าก่อนตระกูลเต็มรูปแบบจะมา SGLang ทำตามนั้น แล้วใช้เวลาสามสัปดาห์ยื่น pull request เกี่ยวกับองค์ประกอบเดียวที่ทำให้สถาปัตยกรรมนี้ติดตั้งใช้งานได้อย่างลำบาก หากอ่านในฐานะการคาดการณ์ นั่นคือข้อความเกี่ยวกับสิ่งที่ Qwen 4 จะต้องการจากฮาร์ดแวร์ของคุณ ไม่ใช่เกี่ยวกับสิ่งที่มันทำได้บนเบนช์มาร์ก

นี่ยังทำให้คำถามเรื่องกรอบเวลาชัดเจนยิ่งขึ้นด้วย Qwen 4 ยังไม่ถูกเปิดตัว และกระแสคาดเดาในเดือนกันยายนที่ surround อยู่ก็ชี้ไปที่งาน Apsara Conference ของ Alibaba ระหว่างวันที่ 22–24 กันยายนที่หางโจว ซึ่งเป็นสถานที่ที่ Qwen เจนเนอเรชันก่อน ๆ ถูกประกาศเปิดตัว ไม่มีอะไรเกี่ยวกับเรื่องนี้ที่ได้รับการยืนยัน และรูปแบบจากรอบพรีวิวครั้งล่าสุดคือ การพรีวิวสถาปัตยกรรมจะมาก่อนตระกูลเต็มรูปแบบเป็นเวลาหลายเดือน ไม่ใช่หลายสัปดาห์ การเปิด pull request สามวันก่อนการประชุมนั้นเป็นเพียงการบอกเป็นนัยเท่านั้น ไม่ได้สื่ออะไรมากไปกว่านั้น

บทสรุปที่ตรงไปตรงมาว่าเรื่องนี้ทำให้ผู้อ่านอยู่ในจุดไหน: Qwen 4 ไม่มีอยู่จริง Qwen3.8-Flash-Next ต่างหากที่มีอยู่ และตัวที่สองบอกคุณว่าการรันตัวแรกจะทำให้คุณต้องเสียค่าใช้จ่ายเท่าไร หากตาราง 47.7 GiB ยังคงลดขนาดพื้นที่ใช้งานจริงลงเรื่อย ๆ — และสามสัปดาห์ของ pull request บอกว่ามีการทำงานกับมันอย่างหนัก — เกณฑ์การนำไปใช้งานสำหรับตระกูล Qwen 4 ก็ต่ำกว่าที่สัปดาห์เปิดตัวของพรีวิวชี้ให้เห็น

สิ่งที่คุณทำได้จริง ๆ กับสิ่งนี้ในวันนี้

ไม่มีสิ่งใดใน pull request นี้ที่พร้อมใช้งานบน main และโมเดลที่มันมุ่งเป้าไปหานั้นก็ไม่ใช่สิ่งที่คุณจะเรียกใช้ผ่าน API ได้ checkpoint Qwen3.8-Flash-Next แบบเปิดน้ำหนักเป็นเรื่องของการโฮสต์เอง: คุณดึงน้ำหนักออกมา คุณให้บริการมันด้วยตัวเอง และเส้นทาง PLE ที่อิงไฟล์คือสิ่งที่คุณกำลังอ่านอยู่ มันไม่ได้ถูกจัดเส้นทางที่นี่ สิ่งที่ถูกจัดเส้นทางคือตัวแปรสำหรับโปรดักชัน — Qwen3.8-Flash ซึ่งเข้าถึงได้ในชื่อ qwen/qwen3.8-flash ในราคา 0.15 ดอลลาร์ต่ออินพุตหนึ่งล้านโทเคน และ 0.47 ดอลลาร์ต่อเอาต์พุตหนึ่งล้านโทเคน พร้อมบริบทขนาด 1M โทเคน และรองรับอินพุตแบบข้อความ รูปภาพ และวิดีโอ — ส่วนรุ่นที่ใหญ่กว่าอย่าง Qwen3.8-Max อยู่ที่ 2.00 และ 6.00 ดอลลาร์

ความแตกต่างนี้คือสิ่งที่มีประโยชน์สำหรับผู้อ่านที่กำลังตัดสินใจว่าจะทำอะไรในสัปดาห์นี้ พรีวิวคืองานวิจัยที่คุณรันเอง ส่วนเวอร์ชันที่ให้บริการคือเส้นทางโปรดักชันของสถาปัตยกรรมเดียวกัน และมันห่างออกไปเพียงหนึ่งปลายทาง OrcaRouter ส่งผ่านราคาตามรายการของผู้ให้บริการที่มาร์กอัป 0% ดังนั้นการเปลี่ยนแปลงราคาของผู้ให้บริการบนปลายทางนั้นจะปรากฏให้เห็นในวันเดียวกัน แทนที่จะเป็นรอบบิลถัดไป และทุกโมเดลบนคีย์นั้นเข้าถึงได้ผ่าน base URL เดียวที่เข้ากันได้กับ OpenAI แทนที่จะต้องมีสัญญา SDK และข้อมูลรับรองแยกต่างหากต่อผู้ให้บริการแต่ละราย สำหรับสถาปัตยกรรมที่ยังใหม่ขนาดนี้ — ซึ่งงานของเอนจินยังลงทุกสัปดาห์และยังไม่ได้เผยแพร่โรดแมป — การสลับสำรองอัตโนมัติข้ามผู้ให้บริการเป็นวิธีปฏิบัติจริงในการพึ่งพาเวอร์ชันที่ให้บริการ โดยไม่เดิมพันเส้นทางโปรดักชันกับ uptime ของผู้ให้บริการรายเดียว ทั้งหมดนี้เป็นเรื่องเกี่ยวกับโมเดลที่คุณเรียกใช้ได้ในวันนี้ ไม่ได้พูดอะไรเกี่ยวกับ Qwen 4 ซึ่งไม่ใช่หนึ่งในนั้น

สิ่งที่เรายังไม่รู้

ว่า Qwen 4 จะปล่อยตารางเดียวกันในขนาดเดียวกันหรือไม่ ว่า pull request จะถูก merge หรือไม่เลย — ตอนนี้มีการรัน CI ที่ล้มเหลวสามครั้งและยังไม่มีการรีวิว ว่าค่าปรับ 0.5 ถึง 1 มิลลิวินาทีต่อสเต็ปจะยังคงอยู่หรือไม่ภายนอกการตั้งค่าคอนเคอร์เรนซีต่ำของผู้เขียน และว่า Alibaba จะพูดอะไรที่ Apsara ในวันที่ 22 กันยายนหรือไม่ จากหลักฐานในปัจจุบัน สิ่งที่ปลอดภัยที่สุดที่จะสรุปเกี่ยวกับ Qwen 4 ไม่ใช่สิ่งที่มันทำคะแนนได้ แต่เป็นปริมาณเครื่องไม้เครื่องมือที่อุตสาหกรรมกำลังสร้างขึ้นเพียงเพื่อทำให้มันเข้ากันได้ — ซึ่งตัวมันเองก็เป็นสิ่งที่มีประโยชน์ที่ควรรู้ก่อนที่โมเดลนี้จะมีชื่อในแคตตาล็อกใด ๆ