การสุ่มแบบแบ่งส่วนตามแบตช์ของ Qwen4Exp: ภายใน vLLM PR #61018 และสิ่งที่มันกล่าวถึง Qwen 4

ตัวเลขที่ให้ข้อมูลมากที่สุดใน vLLM pull request #61018 คือค่าความสูญเสีย (loss): 1.5% นั่นคือขอบเขตบนที่ผู้เขียนกำหนดให้กับการเปลี่ยนแปลงของตัวเอง — ประมาณ 0.6 ถึง 0.8 มิลลิวินาทีที่ประหยัดได้ จากค่าเฉลี่ย 42 มิลลิวินาทีต่อหนึ่ง step ซึ่งวัดบนเครื่องที่เขาไม่ได้เป็นเจ้าของ ในแพตช์ที่เขาไม่สามารถรันได้เลย pull request นี้มีชื่อว่า "[Model] Qwen4Exp: support batch-sharded sampling (compute_logits_local)" และเปิดเมื่อ 2026-10-10 โดยผู้มีส่วนร่วม kimseunghyun-kr เพิ่มโค้ดโมเดลสามบรรทัดลงในสองไฟล์ เพื่อให้สถาปัตยกรรม Qwen4Exp สามารถใช้เส้นทางการสุ่มตัวอย่างที่ vLLM เปิดตัวไปเมื่อเดือนสิงหาคมได้ มันเป็นฉบับร่าง มันมีโค้ดโมเดล 14 บรรทัดบวกกับเทสต์อีก 57 บรรทัด และมันก็ยังคุ้มค่าที่จะอ่านอย่างละเอียดอยู่ดี เพราะสิ่งที่สามบรรทัดนั้นกำลังปิดทับไว้: Qwen4Exp คือสถาปัตยกรรมที่อยู่ภายใน Qwen3.8-Flash-Next โมเดล open-weight ขนาด 125 พันล้านพารามิเตอร์ที่ผู้พัฒนาเผยแพร่เมื่อ 2026-08-24 ในฐานะ "ตัวอย่างทดลองของสถาปัตยกรรมที่จะเป็นรากฐานของ Qwen4" — และบั๊กแบบสองเส้นทางในครึ่งที่เป็นข้อความล้วนของสถาปัตยกรรมนั้น ก็เป็นรายละเอียดประเภทที่คุณจะรู้ได้ก็ต่อเมื่อเฝ้าดูชั้น serving แทนที่จะดูโพสต์เปิดตัว

เพื่อให้ชัดเจนเกี่ยวกับกรอบการนำเสนอ เพราะเรื่องนี้สำคัญ ณ จุดนี้: Qwen 4 เองยังไม่เปิดตัว ผู้ให้บริการได้ระบุชื่อระดับของ Qwen 4 ไว้สี่ระดับ — Qwen 4 Max, Flash, Plus และ 27B — ในงานประชุม Apsara ของบริษัทเมื่อวันที่ 2026-09-22 และยังไม่ได้เผยแพร่น้ำหนัก (weights), ตัวระบุ (identifier), ราคา, ความยาวบริบท (context length) และผลการทดสอบมาตรฐาน (benchmark) สำหรับรุ่นใดในจำนวนนี้เลย ไม่มีสิ่งใดด้านล่างนี้เป็นการเปิดตัว นี่คือรายงานสรุปสิ่งที่เรารู้จนถึงตอนนี้เกี่ยวกับ pull request ฉบับร่างเพียงฉบับเดียว และทุกสิ่งในนั้นที่มีตัวเลข ล้วนเป็นหนึ่งในสามอย่างนี้: เวลาที่คุณตรวจสอบได้, ตัวเลขที่ผู้มีส่วนร่วมพิมพ์ลงในเนื้อหา PR ของตนเอง, หรือค่าที่อ่านได้จากไฟล์กำหนดค่าโมเดลสาธารณะ

การสุ่มตัวอย่างแบบแบ่งส่วนตามแบทช์คืออะไร ในหนึ่งย่อหน้า

การขนานแบบเทนเซอร์จะแบ่งน้ำหนักของโมเดลไปยัง GPU หลายตัว; การฉายภาพคำศัพท์เป็นเทนเซอร์เดี่ยวที่กว้างที่สุดในสแต็ก ดังนั้นโดยปกติแต่ละแรงค์จะคำนวณเฉพาะสไลซ์คำศัพท์ของตัวเอง — จากนั้นทุกแรงค์จะทำ all-gather เพื่อให้แต่ละแรงค์เก็บ logits ทั้งหมดสำหรับทุกคำขอในแบตช์ การสุ่มตัวอย่างแบบแบ่งชาร์ดจะกลับการแลกเปลี่ยนนั้น แทนที่จะทำซ้ำคำศัพท์ข้ามแรงค์ มันจะแบ่งชาร์ด แบตช์: แต่ละแรงค์จะสุ่มตัวอย่างหนึ่งสไลซ์ของคำขอ และแรงค์ต่างๆ จะแลกเปลี่ยนสไลซ์คำศัพท์ระหว่างกันผ่าน all-to-all เอกสาร CLI ของ vLLM เองอธิบายแฟล็กนี้อย่างตรงไปตรงมา — "แต่ละแรงค์จะสุ่มตัวอย่างสไลซ์หนึ่งของแบตช์ แทนที่ทุกแรงค์จะสุ่มตัวอย่างทั้งหมด" — และระบุข้อจำกัดว่า: --enable-batch-sharded-sampling มีค่าเริ่มต้นเป็น False ต้องใช้ tensor_parallel_size มากกว่า 1, อย่างน้อย tensor_parallel_size ซีเควนซ์สูงสุด และค่าที่ไม่เป็นลบของ max_logprobs. บรรทัดสุดท้ายของเอกสารนั้นคือจุดที่ pull request นี้พึ่งพา: "โมเดลเลือกใช้โดยการอิมพลีเมนต์ compute_logits_local."

ฟีเจอร์นี้เองไม่ใช่ของใหม่ vLLM ได้ merge มันเป็น PR #50465 — "[Model Runner V2] batch-sharded sample," โดย Giancarlo Delfin — เมื่อ 2026-08-24 ซึ่งเป็นวันเดียวกับที่ weights ของ Qwen3.8-Flash-Next เปิดให้ใช้งาน แรงจูงใจในตอนนั้นคือหน่วยความจำและความหน่วง: การสร้าง target logits แบบเต็มมีค่าใช้จ่ายอยู่ในหลัก ขนาดแบตช์ × (โทเคนแบบ speculative + 1) × ขนาดคำศัพท์และการแชร์ดจะลดการจัดสรรนั้นลงตามปัจจัยของระดับ tensor-parallel พร้อมกับปล่อยให้งาน top-k และ top-p ของ sampler ทำงานแบบขนาน นี่เป็นขั้นตอนที่ทำให้ทำได้ ไม่ใช่จุดหมายปลายทาง: ข้อความของ PR เองระบุว่า draft-logits แบบแชร์ดเป็นงานในอนาคต

ทำไมสามบรรทัดถึงเป็นงานทั้งหมด

นี่คือข้อบกพร่องจริง และมันเป็นข้อบกพร่องที่ดีเพราะมองไม่เห็นจากภายนอกโค้ด การใช้งาน Qwen4Exp ของ vLLM ถูกส่งมอบเป็นสองคลาส Qwen4ExpForConditionalGeneration เป็นตัวห่อหุ้มแบบวิชัน-ภาษา — หอคอยการมองเห็น Qwen3-VL ที่ถูกยึดติดเข้ากับโมเดลภาษา — และ Qwen4ExpForCausalLM เป็นเส้นทางแบบข้อความเท่านั้น ตัวห่อหุ้มสืบทอด compute_logits_local จาก Qwen3_5ForConditionalGeneration ซึ่งส่งต่อการเรียกไปยัง language_model.compute_logits_local แต่คลาสโมเดลภาษาที่ตัวห่อหุ้มชี้ไปนั้นไม่เคยกำหนดเมธอดนั้นเลย

ดังนั้นเส้นทางทั้งสองจึงอยู่ในสถานะที่แตกต่างกัน การดีพลอยแบบ vision-language ของ Qwen3.8-Flash-Next สามารถใช้เส้นทางแบบ sharded ได้ ส่วนแบบข้อความล้วนทำไม่ได้ เพราะเมธอดที่ wrapper มอบหมายงานไปให้นั้นไม่มีอยู่ การแก้ไขคือเมธอดเดียว ซึ่งเหมือนกันในสำเนาของไฟล์โมเดลทั้งของ NVIDIA และ AMD:

• เมธอดนี้คืนค่า self.logits_processor(self.lm_head, hidden_states, skip_gather=True) — ซึ่งเป็น shard ของคลังคำศัพท์ของ rank นั้นเอง โดยไม่มีการ gather และไม่มีการสร้างคลังคำศัพท์ทั้งชุดขึ้นมาในหน่วยความจำบน rank ใด ๆ

• มันเป็นไปตามสิ่งที่ PR เรียกว่า "แพตเทิร์น 3 บรรทัดแบบเดียวกับ Qwen3.5 และ MiniMax M3" ซึ่งน่าหยุดพิจารณาสักหน่อย: ครอบครัวโมเดลอีกสองตระกูลในรีโพซิทอรีเดียวกันได้เลือกเข้าร่วมแล้ว Qwen4Exp เป็นเพียงตัวเดียวที่ยังไม่ได้ทำ

ไฟล์ทดสอบเป็นจุดที่ความซื่อตรงของแพตช์ถูกตรวจสอบได้ง่ายที่สุด และเป็นจุดที่เห็นขีดจำกัดของมันได้ง่ายที่สุด มันมี 57 บรรทัด ถูกกำหนดพารามิเตอร์ให้ครอบคลุมทั้งโมดูล NVIDIA และ AMD และไม่ดาวน์โหลดโมเดลใด ๆ ตัวช่วยสร้างคลาสด้วย object.__new__ แทนที่ nn.Identity สำหรับส่วนหัวของแบบจำลองภาษา และติดตั้งตัวประมวลผลลอจิตปลอมที่คืนค่าอินพุตบวกหนึ่งพร้อมกับบันทึกว่ามันถูกเรียกมาอย่างไร การทดสอบแรกยืนยันว่า 4.0 ที่ป้อนเข้าไปนั้นออกมาเป็น 5.0 และการเรียกที่บันทึกไว้นั้นมี skip_gather=True ติดมาด้วย การทดสอบที่สองห่อแบบจำลองภาษาด้วยคลาสการสร้างแบบมีเงื่อนไขและยืนยันว่าการมอบหมายงานนั้นลงเอยอย่างถูกต้อง นั่นคือการทดสอบการเชื่อมต่ออย่างแท้จริง และไม่ใช่การทดสอบสิ่งอื่นใดเลย — ไม่มีเคอร์เนลใดถูกทดสอบ ไม่มีขอบเขตแรงก์ใดถูกข้าม และจำนวน GPU ที่เกี่ยวข้องเป็นศูนย์

ข้อเท็จจริงทั้งสองข้อนี้ถูกระบุไว้ใน PR อย่างตรง ๆ ไม่ได้ถูกซ่อนเอาไว้ docstring ของไฟล์ทดสอบเองก็เรียก Qwen4Exp ว่า "ตัวจำลองการทดสอบขนาดจิ๋วที่ใช้แค่ CPU" ส่วนการตรวจสอบความถูกต้องของผู้เขียนระบุว่าเขาไม่สามารถนำเข้าโมเดลบนเครื่อง macOS ของเขาได้เลย เพราะ transformersบิลด์ที่เขาใช้นั้นไม่ได้มาพร้อมกับ Qwen4ExpConfig การรันบน CUDA ก็ยังค้างอยู่ การทดสอบแบบ end-to-end — ชุดข้อมูล agentic ของ MLPerf, 20 เซสชันที่รันพร้อมกัน, สามช่วง ช่วงละ 60 นาที — ก็ยังค้างอยู่ เส้นทาง logits ของ MTP drafter เองก็ถูกทำเครื่องหมายว่ายังไม่ได้ตรวจสอบ LoRA ถูกปฏิเสธไปแล้วโดยแฟล็กต้นทาง จึงจัดว่าอยู่นอกขอบเขตมากกว่าที่จะเป็น regression นอกจากนี้ยังมีบรรทัดที่เปิดเผยว่า draft นี้เขียนขึ้นโดยใช้ความช่วยเหลือจาก AI และ commit trailer ระบุชื่อ Claude Opus 5.5 เป็นผู้ร่วมเขียน ซึ่งเป็นการเปิดเผยแบบที่ควรจะเป็นเรื่องปกติในสแตกขนาดนี้ แต่ส่วนใหญ่กลับไม่เป็นเช่นนั้น

ประมาณการ 1.5% และผลการวัดที่อยู่เคียงข้างกัน

การประเมินของผู้ร่วมสมทบคือnsysเทรซที่ 16 เซสชันพร้อมกันบน Qwen3.8-Flash-Next-FP8 ด้วย tensor parallelism 8 และ expert parallelism กระจายข้ามการ์ด A100-SXM4-40GB แปดใบ: ประมาณ 1.6 มิลลิวินาทีของสเต็ป 42 มิลลิวินาที ลดลงเหลือราวหนึ่งในสามของจำนวนนั้น สำหรับกำไรแบบ end-to-end 1.5 ถึง 2% ตัวเลขพาดหัวของเขาคือเลขคณิต — 0.6 ถึง 0.8 มิลลิวินาทีจาก 42 มิลลิวินาที สังเกตสิ่งที่แนบมากับสิ่งนั้น: 42 มิลลิวินาทีเป็นตัวเลข latency ระหว่างโทเคน ดังนั้นการตัด 1.7% คือการตัด 1.7% ของเวลาในการสร้างโทเคน ไม่ใช่ข้ออ้างเรื่อง throughput ในเชิงนามธรรม

การเปรียบเทียบที่ตรงไปตรงมาคือเทียบกับตัวเลขที่ merge แล้วของฟีเจอร์แม่เอง เพราะตัวเลขเหล่านั้นถูกวัดแบบ end to end โดยคนที่มีฮาร์ดแวร์ ในการรัน Speed-Bench 2K/2K ที่เผยแพร่ใน PR #50465 การสุ่มแบบ batch-sharded ทำให้ DeepSeek V4 กับ DSpark ที่ 7 speculative tokens และ concurrency 64 ขยับจาก 2.62 เป็น 2.66 requests ต่อวินาที — เพิ่ม throughput 1.53% — โดย median inter-token latency ลดลง 3.09% และ time to first token เพิ่มขึ้น 1.45% บน MiniMax M3 กับ DSpark ที่ 8 speculative tokens request throughput เพิ่มขึ้น 5.38% และ median TPOT ลดลง 8.33% จาก 15.61 เป็น 14.31 มิลลิวินาที และแผนเดียวกันนี้บันทึกไว้ด้วยว่ามันไม่ช่วยตรงไหน: ที่ concurrency 4 ถึง 16 ผลการรันออกมาแบนราบถึงติดลบเล็กน้อย โดยแขนที่ concurrency 16 ลดลง 0.54% ในด้าน throughput และ 1.89% ในด้าน acceptance length

รูปแบบนั้นคือสิ่งที่ควรเก็บติดตัวไป การสุ่มแบบ sharded (sharded sampling) ให้ผลคุ้มค่าเมื่อการสุ่มมีภาระหนักและ batch กว้าง — มี concurrency สูง มี speculative token จำนวนมาก และ top-k กับ top-p ทำงานจริง ๆ — แต่กลับมีต้นทุนเล็กน้อยเมื่อ batch เล็กพอที่การสื่อสารแบบ all-to-all จะเป็นภาระล้วน ๆ ค่าประมาณ 1.5% สำหรับโมเดลหนึ่งที่เลือกเปิดใช้นั้นสอดคล้องกับรูปแบบนี้ ไม่ได้ขัดแย้งกันเลย: ตัวเลข 5.38% และ 8.33% เป็นของโมเดลคนละตัวซึ่งมีงบประมาณ speculative ต่างกัน และโมเดลใน PR นี้ก็มีคอนฟิกูเรชันของตัวเอง มีคลังคำศัพท์ 248,320 โทเคนของตัวเอง และมีเส้นทางการถอดรหัสแบบ speculative (speculative-decoding path) ของตัวเอง

ไม่มีส่วนใดเลยที่ได้รับการตรวจสอบ ตัวเลขของ PR หลักคือการรันแบบจับคู่ของผู้มีส่วนร่วมเพียงคนเดียวบนโหนดเดียว ส่วนตัวเลข smoke-test ที่นี่เป็นเทรซบนฮาร์ดแวร์ที่ผู้เขียนไม่มี จากรีวิชันของแพตช์ที่เขากล่าวว่าวัดที่ 16 เซสชันเท่านั้น การวัดโดยผู้มีส่วนร่วมคนเดียวและการกำหนดค่าเดียวเป็นสัญญาณที่มีประโยชน์เกี่ยวกับทิศทาง และเป็นพื้นฐานที่ไม่ดีสำหรับแผนความจุ เหตุผลที่หัวข้อนี้ควรค่าแก่การเขียนถึงเลยก็คือทิศทาง ไม่ใช่ตัวเลขทศนิยม

สิ่งที่กลุ่มแพตช์โดยรอบบอกเกี่ยวกับ Qwen4Exp

หนึ่ง draft PR คงไม่ใช่เรื่องราว เรื่องราวคือ Qwen4Exp ได้กลายเป็นเป้าหมายการให้บริการที่ยั่งยืนในสัปดาห์ที่มันถูก merge และแพตช์ที่เล็กที่สุดในกลุ่มนั้นคือสิ่งที่ทำให้รูปแบบนี้เข้าใจได้ ในช่วงเจ็ดวันจนถึง 2026-10-10 vLLM มีการเปลี่ยนแปลงเหล่านี้จากผู้มีส่วนร่วมคนเดียวกันและคนอื่นๆ: เส้นทาง FP8 main KV cache สำหรับ sparse attention บน Ampere โดยความจุ KV เพิ่มขึ้น 1.83× บน A100 แปดตัว และ 1.87× บน RTX 3090 สี่ตัว และคำขอเพิ่มขึ้นประมาณ 2.7× ที่ concurrency 16 โดยมีค่าใช้จ่ายคือ single-stream decode TPOT สูงขึ้นประมาณ 6%; การแก้ไขสำหรับ W4A4 MoE padding ที่ tensor-parallel 1 และ expert parallelism; เส้นทาง AMD ที่ fallback จาก unsupported AITER FP8 MoE operations และให้บริการใน fp16; การแก้ไขที่นำ PLE short-convolution state ผ่าน align mode; และ decode kernel ที่ unpack e4m3 bytes ครั้งละสี่ไบต์ต่อ register บน sm_80 หนึ่งในนั้น คือการปรับแต่งใหม่ของแผน H200 M=4 merged QSA LL-GEMM ถูก merge เข้า main เมื่อวันที่ 2026-10-09

อ่านรายการนั้นโดยรวมแล้วมันบอกอะไรที่ชัดเจน สถาปัตยกรรม Qwen4Exp — ตัวที่ผู้ขายยังไม่เปิดตัว — กำลังถูกปรับแต่งสำหรับ Ampere, Hopper, ROCm และ fp16 fallback ไปพร้อมกัน ในโปรเจกต์ที่ปล่อยการรองรับตั้งแต่วันแรกสำหรับโมเดลที่ผู้คนดาวน์โหลดได้จริง เหตุผลไม่ใช่เรื่องลึกลับ: Qwen3.8-Flash-Next เป็นโมเดลจริง ดาวน์โหลดได้ ถูกใช้อย่างหนัก และมันสร้างบนสถาปัตยกรรมที่ Qwen 4 จะใช้ ไม่รู้ว่าเวตของ Qwen 4 จะออกมาในลักษณะนี้หรือไม่ และผู้ขายไม่ได้พูดอะไร แต่ขอบเขตการให้บริการกำลังถูกขยายอย่างเปิดเผย และนั่นเป็นข้อมูลที่ตรวจสอบได้ ในแบบที่หน้าต่างช่วงตุลาคมถึงพฤศจิกายนที่เป็นข่าวลือไม่ใช่

รูปทรงสถาปัตยกรรมบางส่วนก็เป็นสาธารณะเช่นกัน สำหรับใครก็ตามที่อ่านไฟล์คอนฟิกูเรชันแทนที่จะอ่านประกาศ คอนฟิกของ Qwen3.8-Flash-Next ระบุรายการคำศัพท์ 248,320 โทเคนครอบคลุม 48 เลเยอร์, ผู้เชี่ยวชาญ (experts) 512 ตัว โดยมี 10 ตัวที่ถูกจัดเส้นทาง (routed) บวกหนึ่งตัวที่แชร์และทำงานต่อโทเคน ที่ความกว้าง intermediate ของผู้เชี่ยวชาญ 640, ขนาด hidden 2,560, และ context แบบเนทีฟ 262,144 โทเคน ซึ่งอธิบายว่าสามารถขยายได้ถึงหนึ่งล้าน มันเป็นแบบไฮบริด: รายการชนิดเลเยอร์สลับกันระหว่างบล็อก linear-attention สามบล็อกกับบล็อก full-attention หนึ่งบล็อก และบล็อก full-attention ใช้เส้นทาง sparse-attention พร้อมตัวจัดดัชนี (indexer) หนึ่งหัวที่บีบอัดคีย์ด้วยแฟกเตอร์สี่ และคงงบตำแหน่งไว้ 2,048 ตำแหน่ง มีตาราง embedding ต่อเลเยอร์ที่เลเยอร์ 2, embedding แบบ n-gram ที่มีคำศัพท์ 20 ล้านรายการ — นั่นคือตารางขนาด 47.7 GiB ที่แพตช์อื่นๆ ในคลัสเตอร์นี้กำลังยุ่งอยู่กับการ host-staging — และ MTP head หนึ่งเลเยอร์สำหรับการถอดรหัสแบบ speculative สรุปใน model card ของมันเองคือ "125B โดยเปิดใช้งาน 6B บวก embedding แบบ n-gram 51B และ MTP 4B" คำศัพท์ 248,320 รายการคือเหตุผลว่าทำไมการฉายภาพ logits จึงคุ้มค่าที่จะทำ sharding ตั้งแต่แรก

สิ่งที่สิ่งนี้ไม่ได้เปลี่ยนแปลงสำหรับคุณ

การพูดให้แม่นยำเป็นสิ่งที่มีค่า เพราะกลุ่มแพตช์ที่หนาแน่นขนาดนี้อาจอ่านดูเหมือนการเปิดตัวได้ ยังไม่มีสิ่งใดข้างต้นที่ถูก merge และส่วนหนึ่งของมัน — งาน Ampere FP8 KV cache — ถูกระบุอย่างชัดเจนว่ายังไม่ได้รับการตรวจสอบความถูกต้องใน CI เพราะ CI ของ vLLM ไม่มี A100 ไม่มีเวอร์ชัน vLLM ที่เผยแพร่แล้วซึ่งคุณสามารถติดตั้งได้ในวันนี้ที่มี Qwen4Exp sharded-sampling opt-in และไม่มีการวัดประสิทธิภาพ (benchmark) อิสระต่อพฤติกรรมการให้บริการของ Qwen3.8-Flash-Next ภายใต้การเปลี่ยนแปลงใด ๆ เหล่านี้เลย ตัวเลขทุกตัวที่อ้างถึงข้างต้นมาจากเนื้อความของ PR ซึ่งทำให้เป็นข้อมูลที่ผู้ร่วมพัฒนารายงานเองและยังไม่ผ่านการตรวจสอบ ในความหมายเฉพาะว่ายังไม่มีบุคคลที่สามรายใดทำการรันซ้ำ และตัวเลขพาดหัวใน PR ที่เริ่มบทความนี้คือ 1.5% ซึ่งเป็นกำไรจริงในสแตกการให้บริการ และไม่ใช่เหตุผลที่จะเปลี่ยนการเลือกโมเดล

สิ่งที่อาจเปลี่ยนการตัดสินใจได้คือการรันให้บริการแบบเต็มรูปแบบที่ผ่านการตรวจสอบ และยังไม่มีสิ่งนั้นในตอนนี้ การวัดค่า pacing ที่มีอยู่สำหรับ Qwen3.8-Flash-Next นั้นอยู่นอกแพตช์เหล่านี้ทั้งหมด: โมเดลนี้ได้คะแนน Intelligence Index 40 บน Artificial Analysis ซึ่งสูงกว่าค่ามัธยฐานที่ 18 ของโมเดล open-weight ขนาดใกล้เคียงกันมาก และตัวเลขนั้นไม่ขึ้นอยู่กับทุกสิ่งที่กล่าวถึงตรงนี้

สิ่งที่คุณสามารถเรียกได้ในวันนี้ และแง่มุมด้านการกำหนดเส้นทาง

นี่คือจุดที่เรื่องนี้กลายเป็นเรื่องใช้งานได้จริงสำหรับใครก็ตามที่อ่านมาถึงตรงนี้และอยากใช้โมเดลแบบโฮสต์แทนที่จะไปจัดเครื่องมือให้มัน Qwen3.8-Flash-Next ไม่ได้อยู่ในแคตตาล็อกของ OrcaRouter — มันไม่ใช่หนึ่งใน 205 โมเดลที่เราให้บริการ และที่นี่ไม่มีปลายทางแบบโฮสต์สำหรับมัน แต่รุ่นพี่ระดับโปรดักชันที่มันเป็นตัวอย่างให้เห็นนั้นมีอยู่: qwen/qwen3.8-flash ซึ่งเป็นรุ่นเปิดตัวอย่างเป็นทางการของ Qwen3.8-Flash ที่โมเดลการ์ดของผู้ผลิตเองระบุว่ามีฟีเจอร์มากกว่ารุ่นพรีวิว รวมถึงบริบทหนึ่งล้านโทเคนเป็นค่าเริ่มต้นและเครื่องมือในตัว เปิดให้ใช้ในราคา $0.15 ต่อหนึ่งล้านโทเคนอินพุต และ $0.47 ต่อหนึ่งล้านโทเคนเอาต์พุต โดยคิดตามราคาที่ผู้ให้บริการตั้งไว้และไม่บวกเพิ่ม สำหรับขนาดที่เทียบกันได้ในตระกูลเดียวกัน qwen/qwen3.8-27b คิดราคา $0.33 และ $2.40 และ qwen/qwen3.8-max คิดราคา $2.00 และ $6.00 — ทั้งหมดเข้าถึงได้ด้วยคีย์เดียว

มีสองเหตุผลที่สำคัญกว่าปกติสำหรับบทความเกี่ยวกับสถาปัตยกรรมที่ยังไม่เปิดตัว เหตุผลแรกคือต้นทุนการสลับ หากคุณต้องการปรับเทียบว่าโมเดล sparse-attention ให้ความรู้สึกอย่างไรกับทราฟฟิกของคุณก่อนที่ Qwen 4 จะมีอยู่ การเปรียบเทียบที่คุณอยากรันคือกับ qwen/qwen3.8-flash ในราคาตามรายการ — และการทำผ่านเราเตอร์หมายความว่าโมเดลที่คุณกำลังวัดและโมเดลที่คุณอาจถอยกลับไปใช้ อยู่เบื้องหลังปลายทางเดียวกัน SDK เดียวกัน และคีย์เดียวกัน โดยไม่ต้องเซ็นสัญญาฉบับที่สอง เหตุผลที่สองคือการเปลี่ยนแปลงด้านการให้บริการทุกอย่างในชุดแพตช์นี้มุ่งเป้าไปที่ vLLM ที่โฮสต์เอง หากคุณไม่ได้รัน A100s แปดตัว ความจุ KV 1.83× และความได้เปรียบด้านการสุ่ม 1.5% ก็เป็นสิ่งที่คุณอ่านเจอ ไม่ใช่สิ่งที่คุณได้รับ ปลายทางที่ผ่านเราเตอร์คือเวอร์ชันของสิ่งนี้ที่มาถึงโดยไม่ต้องมีขั้นตอนการบิลด์: การสลับไปใช้สำรองอัตโนมัติหากผู้ให้บริการมีประสิทธิภาพลดลง และ routing DSL ที่ช่วยให้คุณวางการเรียกแบบโฮสต์ไว้เคียงกับการเรียกแบบโฮสต์เองในปลายทางเดียว เมื่อคุณมีฮาร์ดแวร์ของคุณเองไว้วัดจริง ๆ

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

เวอร์ชันสั้น

สามบรรทัดที่ปิดช่องว่างระหว่างเส้นทางข้อความล้วนกับเส้นทางภาษาภาพของไฟล์โมเดลไฟล์หนึ่ง ไม่ถือเป็นข่าวในตัวเอง มันเป็นแพตช์แบบที่จะถูกฝังอยู่ใน merge commit หากมีใครมีเวลารีวิว และอาจถูกพับรวมเข้ากับการเปลี่ยนแปลงที่ใหญ่กว่าหรือถูกปิดทิ้งไปเลยก็ได้ — แนวทางสำหรับเอเจนต์ของบอต vLLM เอง ซึ่งถูกอ้างใน PR สั่งให้ผู้มีส่วนร่วมที่ใช้ AI ช่วยปิดงานของตนหากไม่มีประโยชน์อย่างมีนัยสำคัญ และ 1.5% ก็เป็นตัวเลขที่ชวนให้ตั้งคำถามนั้น สิ่งที่ทำให้มันน่าสนใจคือสิ่งที่มันบันทึกไว้: ตาราง n-gram ขนาด 20 ล้านรายการ, MoE แบบ 512 ผู้เชี่ยวชาญที่มีผู้เชี่ยวชาญทำงานพร้อมกันสิบรายต่อโทเค็น, ไฮบริดของ linear attention และ compressed sparse attention, speculative head — ทั้งหมดนี้กำลังถูกปรับจูนข้าม NVIDIA และ AMD ตั้งแต่ Ampere ถึง Hopper ก่อนที่ผลิตภัณฑ์ที่จะนำมันไปใช้จะมีอยู่จริง ถ้าคุณสนใจขอบเขตการให้บริการของ Qwen4 เนื้อหาใน PR คือที่ที่ข้อกำหนดจริงของมันอยู่ตอนนี้ ถ้าคุณอยากเรียกใช้โมเดลวันนี้ Qwen3.8-Flash คือตัวที่อยู่ตรงนั้นจริง ๆ

API เดียวสำหรับโมเดลกว่า 200 รายการ พร้อมการสลับใช้งานอัตโนมัติเมื่อระบบขัดข้อง และ routing DSLสำรวจแค็ตตาล็อกโมเดลของ OrcaRouter