Qwen 4 QSA ได้รับ decode context parallelism: เจาะลึก draft PR ของ vLLM สำหรับ Qwen3.8-Flash-Next

เมื่อวันที่ 2026-09-29 pull request แบบร่างได้ปรากฏใน repository vLLM โดยมีชื่อว่า “[Model][DCP] Support Qwen4Exp QSA” และสำหรับโมเดลที่มันอธิบาย มันมีตัวเลขการให้บริการที่เป็นรูปธรรมที่สุดเท่าที่มีใครเผยแพร่ตลอดทั้งเดือน: การรันแบบจับคู่ของ Qwen3.8-Flash-Next บน GPU สี่ตัวแสดงความจุ KV token จาก 9,759,529 เป็น 17,603,636, การทำงานพร้อมกันสูงสุดจาก 37.23× เป็น 67.15× และเวลาถึงโทเค็นแรกลดลงจาก 1,869 ms เป็น 767 ms Qwen3.8-Flash-Next คือพรีวิวแบบ open-weight, 125 พันล้านพารามิเตอร์, mixture-of-experts ซึ่งการ์ด Hugging Face ของมันอธิบายว่ามันเป็น “ตัวอย่างสถาปัตยกรรม Qwen4”; pull request นี้เพิ่ม decode context parallelism ให้กับเส้นทาง sparse-attention ที่สถาปัตยกรรมนี้สร้างขึ้นโดยรอบ Qwen4 เอง — ระดับ Qwen4 Max, Flash, Plus และ 27B ที่ผู้ขายตั้งชื่อในการประชุม Apsara ของมันเมื่อวันที่ 2026-09-22 — ยังไม่เปิดตัว โดยไม่มีน้ำหนัก ไม่มีตัวระบุ ไม่มีราคา และไม่มีวันที่ ดังนั้นจงอ่านสิ่งนี้ตามที่มันเป็น: ไม่ใช่การเปิดตัว ไม่ใช่ benchmark แต่เป็นสิ่งประดิษฐ์ทางวิศวกรรมที่บอกคุณว่าขอบเขตการให้บริการของ Qwen4 กำลังถูกขยายอย่างไรก่อนที่ตระกูลนี้จะมีอยู่จริง

นี่คือบทความแบบ "เท่าที่เรารู้จนถึงตอนนี้" และการอ้างอิงแหล่งที่มาสำคัญกว่าปกติ พูลรีเควสต์นี้เป็นฉบับร่าง เปิดอยู่ และยังไม่ถูกผสาน — vllm-project/vllm#59279 เปิดเมื่อ 2026-09-29 โดย Sungsoo Ha วิศวกรซอฟต์แวร์ของ NVIDIA และยังคงอยู่ในสถานะฉบับร่าง ตัวเลขทุกตัวด้านล่างนี้เป็นการวัดแบบจับคู่ของผู้เขียนเอง ซึ่งรายงานไว้ในเนื้อความของ PR จากงานรีวิชันก่อนหน้าของงานชิ้นเดียวกันนี้ ไม่มีสิ่งใด هناผ่านการตรวจสอบอย่างอิสระ ไม่มีสิ่งใดที่นี่ถูกรวมอยู่ในรีลีส และข้อควรระวังที่ผู้เขียนแนบมามีน้ำหนักมากพอที่จะได้มีหัวข้อของตัวเองอยู่ด้านล่าง

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

Decode context parallelism — DCP — เป็นเทคนิคการให้บริการ ไม่ใช่การเปลี่ยนแปลงโมเดล แทนที่จะมีกลุ่ม GPU กลุ่มเดียวถือแคช KV ทั้งหมด DCP กลับแยกแคชนั้นไปยังแรงก์ต่างๆ ดังนั้นแต่ละแรงก์จะอ่านเฉพาะส่วนของบริบทของตน ในขณะที่ผลลัพธ์ของแอตเทนชันจะถูกรวมข้ามแรงก์ในตอนท้าย ประเด็นคือความจุ: เมื่อแคชถูกแบ่งพาร์ติชัน การปรับใช้สามารถรองรับทราฟฟิกบริบทยาวที่เกิดขึ้นพร้อมกันได้มากขึ้นมากบนฮาร์ดแวร์เดียวกัน ซึ่งเป็นข้อจำกัดที่กัดกินเมื่อทุกคำขอมีโทเคนถึงสองแสนห้าหมื่นตัว

ความซับซ้อนอยู่ที่ว่า Qwen Sparse Attention — QSA — ไม่ใช่เลเยอร์แอตเทนชันธรรมดา ตามที่การ์ดโมเดล Qwen3.8-Flash-Next ระบุไว้ ตัวจัดดัชนีน้ำหนักเบาจะบีบอัดคีย์เป็นไมโครบล็อกด้วยอัตราส่วนการบีบอัด 4 ให้คะแนนพวกมัน และเก็บ 512 บล็อกที่ดีที่สุด ซึ่งประมาณ 2,048 ตำแหน่งโทเคน ขณะที่ softmax ขั้นสุดท้ายและการรวมค่ายังคงทำงานบน K และ V ที่ไม่ได้บีบอัด นั่นหมายความว่า QSA มีสถานะมากกว่า KV cache: มีแคชหลัก และมีแคชตัวเลือกกับแคชข้างที่ตัวจัดดัชนีดูแลอยู่ การใช้งาน DCP ทั่วไปใน vLLM ไม่รู้อะไรเกี่ยวกับเรื่องเหล่านี้เลย

สิ่งที่ #59279 ทำ ตามคำอธิบายของมัน คือสอนให้ DCP รู้เกี่ยวกับส่วนที่เฉพาะเจาะจงกับ QSA:

• แต่ละแรงก์อ่านส่วนของตัวเองของเมนแคช KV โดยที่ตัวเลือกและแคชด้านข้างของ QSA ยังคงถูกทำสำเนาไปยังแรงก์ต่างๆ แทนที่จะถูกแบ่งส่วน

• ผลลัพธ์ของแอทเทนชันจะถูกรวมข้ามแรงค์หลังจากอ่านแบบแยกส่วน

• selector และ KV cache หลักถูกเก็บไว้ในกลุ่มแคชเดียวกัน จึงไม่สามารถแยกออกจากกันได้

• แบตช์ Synthetic V2 ถูกป้องกันไม่ให้เขียนแคชด้านข้างของ QSA

รายละเอียดคู่สุดท้ายนั่นแหละคือส่วนที่น่าสนใจ ถ้าคุณสนใจเรื่องความถูกต้องมากกว่าอัตราการประมวลผล แคช attention แบบแบ่งชาร์ดที่ไม่ตรงกับ selector แบบทำสำเนาอย่างเงียบ ๆ เป็นบั๊กประเภทที่ปรากฏเป็นการเสื่อมของความแม่นยำอย่างช้า ๆ ในบริบทขนาดยาว แทนที่จะเป็นการแครช และการเปลี่ยนแปลงนี้ก็ระบุชัดเจนเรื่องการทำให้ทั้งสองสอดคล้องกัน ผู้เขียนยังระบุด้วยว่ามีการใช้ความช่วยเหลือจาก AI และ Codex ได้รับเครดิตเป็นผู้เขียนร่วม — ซึ่งควรพูดให้ตรงไปตรงมา เพราะใน PR ฉบับร่างแบบนี้ การถามว่าใครเขียนส่วนไหนเป็นคำถามที่สมเหตุสมผล

ตัวเลขที่จับคู่กัน และวิธีการที่ได้มา

แผนการทดสอบมีความเฉพาะเจาะจงพอที่จะตรวจสอบได้ นี่จึงเป็นเหตุผลว่าผลลัพธ์จึงควรค่าแก่การอ้างอิง ทั้งสองอาร์มให้บริการ Qwen/Qwen3.8-Flash-Next-FP8 บน GPU สี่ตัวด้วย tensor parallelism 4 และเปิดใช้งาน expert parallelism ที่--gpu-memory-utilization 0.90 โดยเปิด prefix caching ไว้ ความแตกต่างเพียงอย่างเดียวระหว่างสองอาร์มคือ--decode-context-parallel-size: ละเว้นสำหรับ DCP=1 ตั้งค่าเป็น 2 สำหรับ DCP=2 โดยมีการรีสตาร์ทระหว่างอาร์มเพื่อให้การทดสอบเริ่มจากแคชที่เย็น ภาระงานคือ AgentX trace ขนาด 256k ที่ผู้ใช้ 128 ราย เป็นเวลา 900 วินาที ส่วนความแม่นยำใช้ EvalScope สำหรับ GSM8K บวกกับตัวประเมิน MRCR ที่เช็กอินไว้ รันหกครั้งต่ออาร์ม โดยทิ้งการรันครั้งแรกหลังการรีสตาร์ท

ค่าส่วนต่างของทรูพุตที่รายงานไว้ โดยเปรียบเทียบ DCP=2 กับ DCP=1:

• KV tokens — 9,759,529 vs 17,603,636 เพิ่มขึ้น 1.80 เท่าในความจุแคช

• ความพร้อมกันสูงสุด — 37.23× เทียบกับ 67.15× และ 1.80× เช่นกัน

คำขอต่อวินาที — 1.69 เทียบกับ 2.30, 1.36×

• อินพุตโทเคนต่อวินาที — 128,730 vs 179,702, 1.40×

• เวลาถึงโทเคนแรก — 1,869 ms เทียบกับ 767 ms ต่ำกว่า 2.44 เท่า

• ความหน่วงระหว่างโทเคน — 43.48 ms เทียบกับ 26.27 ms ต่ำกว่า 1.66 เท่า

• อัตราการพบในแคชของ Prefix ในสภาวะคงตัว — 67.85% เทียบกับ 88.98% เพิ่มขึ้น 21.1 จุดเปอร์เซ็นต์

ความแม่นยำ ซึ่งรายงานเป็นค่าเฉลี่ย ± ส่วนเบี่ยงเบนมาตรฐานตัวอย่างจากผลการรันหลังวอร์มอัป แทบจะคงที่: ค่า MRCR รวมเท่ากับ 0.8630 ± 0.0005 ที่ DCP=1 เทียบกับ 0.8697 ± 0.0153 ที่ DCP=2 และ GSM8K เท่ากับ 0.9788 ± 0.0020 เทียบกับ 0.9790 ± 0.0016 ตัวอย่าง MRCR แบบ 2-needle และ 4-needle ถูกตรึงไว้ที่ 0.9960 และ 0.9906 ในทั้งสองกลุ่ม ดังนั้นความแปรผันจากการรันหนึ่งไปอีกรันหนึ่งทั้งหมดจึงมาจากตัวอย่างแบบ 8-needle — และการรันรวมที่ DCP=2 หนึ่งครั้งได้คะแนน 0.8970 ขณะที่อีกสี่ครั้งอยู่ระหว่าง 0.8620 ถึง 0.8632 นั่นคือการกระจายจริง ไม่ใช่สัญญาณรบกวนที่ปัดทิ้งได้ และมันถูกระบุไว้ใน PR แทนที่จะถูกกลบเกลื่อนให้เรียบ

ตัวเลขเหล่านี้คืออะไร

ข้อแม้อยู่ในข้อความ PR และไม่ใช่เรื่องเล็ก ผลลัพธ์ AgentX และความแม่นยำที่จับคู่กันถูกวัดบนเวอร์ชันก่อนหน้าของ QSA DCP โดยใช้ vLLM nightly ที่อิงจากคอมมิต 3df4ae153eb คอมมิตสุดท้ายที่สะอาดใน pull request รวมถึงการแก้ไข QSA localization-kernel ในภายหลัง และผ่านการตรวจสอบ B200 แบบเจาะจงแล้ว — แต่การประเมิน AgentX และความแม่นยำแบบเต็มยังไม่ได้ทำซ้ำบนซอร์สดังกล่าวนั้นจริง ๆ พูดอีกนัยหนึ่ง: เรื่องราวด้าน throughput กับ diff ที่จัดส่งไม่ใช่อาร์ติแฟกต์เดียวกัน และผู้เขียนก็บอกไว้เช่นนั้น

นอกจากนั้น ยังใช้หลักวินัยตามปกติ และในกรณีนี้ยิ่งต้องเข้มงวดเป็นพิเศษ นี่เป็นตัวเลขจากการกำหนดค่าเดียว จากผู้ร่วมสมทบรายเดียว บนเซตอัปสี่ GPU ชุดเดียว สิ่งเหล่านี้อยู่ใกล้ชิดฝั่งผู้ขายมากกว่าเป็นกลาง: การที่ผู้ร่วมสมทบของเฟรมเวิร์กวัดการเปลี่ยนแปลงของเฟรมเวิร์กเป็นเรื่องปกติและมีประโยชน์ แต่ไม่ใช่การตรวจสอบอย่างอิสระ และยังไม่มีบุคคลที่สามรายใดทำการรันซ้ำ มีเวอร์ชัน vLLM ที่เผยแพร่แล้วซึ่งคุณติดตั้งได้ในวันนี้ที่มีการเปลี่ยนแปลงนี้หรือไม่ เพราะการเปลี่ยนแปลงนี้ยังไม่ได้ถูก merge และ DCP=2 คือการแบ่งแบบสองทางของรูปทรงหนึ่งโดยเฉพาะ — ค่าเดลตาไม่ได้เป็นการรับประกันว่า DCP=4 หรือ DCP=8 จะให้ผลอย่างไร และไม่มีอะไรใน PR อ้างเช่นนั้น

ทำไม PR ด้าน serving เกี่ยวกับสถาปัตยกรรมที่ยังไม่เปิดตัวจึงยังคุ้มค่ากับเวลาของคุณ

ข้อโต้แย้งที่เห็นได้ชัดก็คือ โมเดลในชื่อเรื่องไม่มีอยู่จริง แล้วจะไปสนใจทำไม? เพราะสิ่งที่กำลังถูกปรับจูนไม่ใช่ Qwen 4 แต่มันคือ Qwen3.8-Flash-Next ต่างหาก และโมเดลนั้นมีอยู่จริง — Alibaba เผยแพร่เมื่อวันที่ 24 สิงหาคม 2026 ในรูปแบบ MoE ขนาด 125B พารามิเตอร์ที่เปิดใช้งาน 6B พร้อมตาราง n-gram embedding ขนาด 51,000 ล้านพารามิเตอร์, หัว MTP ขนาด 4B สำหรับ speculative decoding, 48 เลเยอร์ที่จัดเรียงเป็นการทำซ้ำสิบสองรอบของบล็อก Gated DeltaNet สามบล็อก ตามด้วยบล็อก QSA หนึ่งบล็อก, ผู้เชี่ยวชาญ (experts) 512 ตัว โดยมี 10 ตัวที่ถูกจัดเส้นทางและ 1 ตัวที่แชร์และเปิดใช้งานอยู่ และคอนเท็กซ์เนทีฟขนาด 262,144 โทเคน ซึ่งการ์ดระบุว่าสามารถขยายได้ถึง 1,000,000 มันคือ reference implementation ของสถาปัตยกรรม Qwen4 ในรูปแบบ open weights และ QSA — micro-block sparse attention ที่พูลรีเควสต์นี้กำลังสอนให้ DCP ทำการแบ่งชาร์ด — คือส่วนที่เป็นเอกลักษณ์ที่สุดเพียงอย่างเดียวของมัน

สิ่งที่ตัวเลขเหล่านี้อธิบายคือสิ่งที่เกิดขึ้นเมื่อคุณเลิกมองว่าบริบท 262K นั้นเป็นสิ่งที่กลุ่ม GPU กลุ่มเดียวต้องถือไว้ทั้งหมด การเพิ่มขึ้น 1.80 เท่าของความจุโทเคน KV และการทำงานพร้อมกัน คือเลขคณิตของการแยกแคชออกเป็นสองส่วน ซึ่งเป็นผลลัพธ์ที่ชวนประหลาดใจน้อยที่สุดในรายการ ตัวเลขที่น่าสนใจกว่าคือตัวเลขด้านความหน่วง: เวลาถึงโทเคนแรกต่ำลง 2.44 เท่า และความหน่วงระหว่างโทเคนต่ำลง 1.66 เท่า ภายใต้โหลดที่เสนอเท่ากัน บวกกับการปรับปรุง 21 จุดในอัตราการฮิตของพรีฟิกซ์แคชในสภาวะคงตัว สิ่งเหล่านี้บอกว่าเส้นทาง DCP ไม่ได้แค่ซื้อความจุโดยแลกกับความหน่วง — ในการรันแบบจับคู่นี้ มันได้มาทั้งสองอย่าง นั่นคือรูปแบบของการเปลี่ยนแปลงที่สำคัญสำหรับใครก็ตามที่ให้บริการทราฟฟิกของเอเจนต์ด้วยพรอมป์ระบบที่ยาวมาก เพราะพฤติกรรมของพรีฟิกซ์แคชที่บริบทขนาดยาวมักเป็นจุดที่ทรูพุตของบริบทขนาดยาวค่อย ๆ ตายลงอย่างเงียบ ๆ

และนี่ไม่ใช่แพตช์โดด ๆ สัปดาห์เดียวกันยังให้งานเอนจิน Qwen4Exp ออกมาเป็นกลุ่ม: #59214 เพิ่มแผน GEMM สำหรับถอดรหัสความหน่วงต่ำบน SM100 สำหรับเชปของ B200, #59010 เพิ่มเคอร์เนลพรีฟิลแบบสแาร์สเนทีฟ SM90 สำหรับเส้นทาง QSA บน Hopper, #58977 ครอบคลุม BF16 INC PLE embeddings และ #58961 — อันที่ merge จริงแล้วเมื่อ 2026-09-28 — แก้ KV cache สำหรับโปรไฟล์ที่ QSA key views ยังคงยึดให้มีชีวิตอยู่ พออ่านรวมกันแล้ว พวกมันคือขอบเขตการเสิร์ฟของสถาปัตยกรรม Qwen4 ที่กำลังถูกสร้างอย่างเปิดเผย ในรันไทม์ หลายเดือนก่อนตระกูลนี้จะวางจำหน่าย ถ้าคุณกำลังวางแผนสำหรับ Qwen 4 สัญญาณที่มีประโยชน์ไม่ใช่วันเปิดตัว — ซึ่งไม่มี — แต่เป็นสิ่งที่เคอร์เนลและเลย์เอาต์แคชตั้งสมมติฐานไว้แล้วว่าคุณจะต้องเสิร์ฟมันอย่างไร

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

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

ข้อชี้แจงตรงไปตรงมาสองข้อ ข้อแรก Qwen3.8-Flash-Next เอง — น้ำหนัก FP8 ในแผนการทดสอบของ pull request ซึ่งเป็นสิ่งที่คุณจะต้องใช้เพื่อทำซ้ำการวัดใด ๆ เหล่านี้ในเครื่องของคุณ — ไม่มีอยู่ในแคตตาล็อกของเรา; ระดับ Flash ที่ให้บริการคือสายการผลิต QwenCloud ไม่ใช่ checkpoint ตัวอย่างดิบ หากคุณต้องการรันการกำหนดค่าตาม PR เป๊ะ ๆ คุณต้องโฮสต์เองบน GPU สี่ตัว ข้อที่สอง การเปลี่ยนแปลง DCP ยังไม่ถูก merge ดังนั้นไม่มีอะไรที่คุณเรียกใช้ได้ที่ไหนในวันนี้ที่รันมันอยู่ สิ่งที่ระดับที่ให้บริการมอบให้คุณคือวิธีตรวจสอบว่าเวิร์กโหลดของคุณมีรูปร่างเหมาะกับปัญหาที่ DCP แก้หรือไม่: หากพรอมป์ของคุณยาว เป็นแบบเอเจนต์ และมี prefix หนาแน่น แล้วความจุ 1.80× และส่วนต่างของ prefix-cache คือตัวเลขที่ควรจับตาในเทรซของคุณเอง

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

คำถามที่ควรค่าแก่การตอบโดยตรง

#59279 หมายความว่า Qwen 4 ออกแล้ว หรือกำลังจะออกเร็ว ๆ นี้หรือเปล่า

ไม่ พูลรีเควสต์นี้เกี่ยวกับสถาปัตยกรรม Qwen4Exp อย่างที่นำมาใช้ใน Qwen3.8-Flash-Next ซึ่ง Alibaba เปิดตัวเมื่อ 2026-08-24 ตระกูล Qwen 4 — Max, Flash, Plus และ 27B — ถูกตั้งชื่อบนเวทีที่ Apsara เมื่อ 2026-09-22 และถูกบรรจุไว้ในโรดแมปของบริษัท โดยมีสายรุ่นสืบทอดที่คาดการณ์ไว้ที่ 5 ถึง 10 ล้านล้านพารามิเตอร์ และก็ยังไม่มี model card ไม่มี weights ไม่มีตัวระบุ API ไม่มีหน้าต่างบริบท ไม่มีราคา และไม่มีวันที่ PR ของเฟรมเวิร์กที่เพิ่มโหมด parallelism ให้กับสถาปัตยกรรมพรีวิวเป็นก้าวหนึ่งสู่การให้บริการ Qwen 4 ได้ดี มันไม่ใช่ก้าวหนึ่งสู่การที่ Qwen 4 มีอยู่จริง

Decode context parallelism แตกต่างจาก tensor parallelism อย่างไร?

ทั้งสองอย่างแบ่งสิ่งต่างกันและล้มเหลวด้วยวิธีที่ต่างกัน Tensor parallelism แบ่งพาร์ติชันน้ำหนักและการคำนวณของแต่ละเลเยอร์ไปยัง GPU ต่างๆ ดังนั้นทุกแรงก์มีส่วนร่วมในทุกโทเค็นแต่เห็นลำดับทั้งหมด Decode context parallelism แบ่งพาร์ติชัน แคช KVเอง ดังนั้นแต่ละแรงก์จัดเก็บและอ่านเพียงส่วนย่อยของบริบท และผลลัพธ์แอตเทนชันบางส่วนจะถูกรวมเข้าด้วยกันภายหลัง TP เป็นเรื่องของการทำให้โมเดลพอดี; DCP เป็นเรื่องของการทำให้บริบทและทราฟฟิกที่เกิดขึ้นพร้อมกันซึ่งวิ่งอยู่บนบริบทนั้นพอดี ความแตกต่างนี้คือเหตุผลว่าทำไม PR นี้จึงไม่ง่าย: selector และแคชด้านข้างของ QSA ไม่สามารถถูกแบ่งพาร์ติชันแบบง่ายๆ ได้เหมือนที่แคช KV หลักทำได้ ดังนั้นการเปลี่ยนแปลงนี้จึงต้องแบ่งพาร์ติชันตัวหนึ่งและทำสำเนาตัวอื่นๆ แล้วพิสูจน์ว่าทั้งสองยังคงสอดคล้องกัน

ถ้าฉันเรียก Qwen3.8-Flash-Next วันนี้ผ่าน hosted API ฉันจะได้ตัวเลขเหล่านี้แล้วหรือยัง

ไม่ และช่องว่างนี้มีสามส่วน การเปลี่ยนแปลงยังไม่ถูก merge ดังนั้นไม่มี build vLLM ที่เผยแพร่แล้วตัวใดมีสิ่งนี้อยู่ แม้เมื่อ merge แล้ว ผู้ให้บริการก็ต้องรับ build นั้นไปใช้ และเลือกที่จะรันด้วยขนาด DCP มากกว่าหนึ่ง — มันเป็นการกำหนดค่าการให้บริการ ไม่ใช่ค่าเริ่มต้น และค่า delta ที่วัดได้มาจาก revision ก่อนหน้าของแพตช์ ไม่ใช่ commit สุดท้าย ซึ่งผู้เขียนระบุว่าจนถึงตอนนี้มีเพียงการตรวจสอบ B200 แบบเจาะจงเท่านั้น ให้ถือว่า delta ที่รายงานเป็นขอบเขตบนที่มีเอกสารประกอบชัดเจนสำหรับสิ่งที่แนวทางนี้ให้ได้ในหนึ่งการกำหนดค่า ไม่ใช่ข้อกำหนดของ endpoint ใด ๆ ที่คุณเช่าได้ในสัปดาห์นี้

คำถามที่เปิดอยู่

สิ่งที่ต้องจับตาไม่ใช่ว่าร่างเฉพาะนี้จะถูก merge หรือไม่ — มันน่าจะถูก merge ในรูปแบบใดรูปแบบหนึ่ง เพราะการจัดการแคชเฉพาะ QSA ที่มันเพิ่มเข้ามาเป็นช่องว่างจริง ไม่ใช่แค่ความชอบ สิ่งที่ต้องจับตาคือคอมมิตสุดท้ายจะได้รับการประเมินแบบจับคู่แบบเดียวกับที่ revision ระหว่างทางได้รับหรือไม่ การเปลี่ยนแปลงฝั่ง serving ที่ข้ออ้างเรื่อง throughput มาจากบิลด์หนึ่ง และข้ออ้างเรื่องความถูกต้องมาจากอีกบิลด์หนึ่ง ตอนนี้เป็นข้อเสนอที่มีเหตุผลหนุนดี ไม่ใช่ผลลัพธ์ที่วัดได้ และการกระจายของความแม่นยำที่ตัวอย่าง MRCR แบบ 8-needle นั้นกว้างพอที่การรันซ้ำบนซอร์สที่ปล่อยจริงจะเป็นการเผยแพร่ที่มีประโยชน์ที่สุดเพียงสิ่งเดียวที่ใครก็ตามทำได้เกี่ยวกับเรื่องนี้ จนกว่าจะถึงตอนนั้น: ทิศทางอ่านออก บัญชียังไม่ปิด และโมเดลสถาปัตยกรรม Qwen4 เพียงตัวเดียวใน open weights ยังคงเป็นตัวจากเดือนสิงหาคม