Qwen3.8-27B Text+Video กำลังจะมาที่ CPU: สิ่งที่ PR torchcodec ของ SGLang เปลี่ยนแปลง

ขณะนี้คำขอ pull request ฉบับร่างใน SGLang มีชื่อว่า “[CPU] Support Qwen3.8 text+video: adding torchcodec, ffmpeg and removing pin_memory.” เมื่อตัดรายละเอียดเชิงเทคนิคออกไป ก็จะอ่านได้เหมือนแผนงาน: Qwen3.8-27B — โมเดล vision-language ขนาด 27 พันล้านพารามิเตอร์ของ Alibaba ภายใต้สัญญาอนุญาต Apache-2.0 ซึ่งเปิดซอร์สเมื่อห้าวันก่อน — กำลังถูกปรับแต่งให้โหมด text+video ทำงานบนฮาร์ดแวร์ที่ไม่มี GPU อยู่ในเครื่อง นี่คือสัญญาณรูปธรรมแรกที่แสดงว่าโมเดลมัลติโมดัล 27B กำลังได้รับเส้นทางให้บริการบน CPU จริงในหนึ่งในรันไทม์สำหรับ inference ที่ทีมงานนำไปใช้งานจริง และมันสำคัญสำหรับทุกคนที่รอคอยจะรันการทำความเข้าใจวิดีโอในเครื่องโดยไม่ต้องซื้อการ์ดจอ 48GB

ยังไม่มีอะไรใน PR นั้นถูก merge — มันเป็นเพียงร่าง, CI ยังแดงอยู่, และการกำหนดเวอร์ชันยังคงมีการเปลี่ยนแปลง แต่นั่นคือเหตุผลว่าทำไมมันถึงควรอ่านอย่างละเอียด โมเดลที่อยู่เบื้องหลังมันเป็นของจริงและถูกปล่อยออกมาแล้ว, ระบบนิเวศการ serving ได้ตามทันบน GPU แล้ว, และ PR นี้แสดงให้เห็นว่าเส้นทางที่ไม่มี GPU กำลังมุ่งหน้าไปทางไหน นี่คือสิ่งที่การเปลี่ยนแปลงนี้ทำจริง, ว่าทำไมการอนุมานวิดีโอบน CPU สำหรับโมเดล 27B จึงเป็นเรื่องใหญ่กว่าที่คิด, สิ่งที่ได้รับการยืนยันเกี่ยวกับ Qwen3.8-27B, และคุณสามารถเรียกใช้งานมันได้ที่ไหนในวันนี้

แบบจำลองในหนึ่งย่อหน้า

Qwen3.8-27B เป็นโมเดลน้ำหนักเปิดขนาด 27B ของรุ่น Qwen 3.8: โมเดลวิทัศน์-ภาษาแบบ dense ที่มีพารามิเตอร์ประมาณ 27.8B (64 เลเยอร์ ขนาดซ่อน 5,120) พร้อมวิทัศน์ทาวเวอร์เฉพาะ เปิดตัวภายใต้ Apache 2.0 บน Hugging Face และ ModelScope ในช่วงเย็นของวันที่ 14 สิงหาคม 2026 (เวลาปักกิ่ง) รองรับอินพุตข้อความ รูปภาพ และวิดีโอ และส่งออกเป็นข้อความ — โดยธรรมชาติ ไม่ผ่านอะแดปเตอร์เสริม — มีหน้าต่างบริบทแบบเนทีฟ 262,144 โทเคน และขยายได้ถึงประมาณล้านโดยใช้ YaRN ใบอนุญาตเป็นแบบเปิดกว้าง: ใช้งานเชิงพาณิชย์ ปรับแต่ง และเผยแพร่ต่อได้ ไม่มีเกณฑ์รายได้และไม่ต้องมีข้อตกลงเชิงพาณิชย์แยกต่างหาก ต่างจากข้อกำหนดของเช็คพอยต์เรือธง

รายละเอียดทางสถาปัตยกรรมสองประการสำคัญต่อผู้ปรับใช้มากกว่าสเปกหลัก ประการแรกคือไฮบริดแอตเทนชัน (hybrid attention): ชั้นส่วนใหญ่ใช้ Gated DeltaNet linear attention และมีเพียงหนึ่งในสี่ที่เก็บ full KV cache ดังนั้นหน่วยความจำบริบทยาวจึงเป็นเศษส่วนของสิ่งที่โมเดลหนาแน่น 64 ชั้นทั่วไปต้องใช้ — เทคนิคเดียวกันที่ทำให้หน้าต่าง 262K เป็นจริงได้ในการ์ดจอผู้ใช้ทั่วไปเพียงใบเดียว ประการที่สองคือการทำนายหลายโทเคน (multi-token prediction, MTP) ซึ่งมาพร้อมกับเช็คพอยต์ที่มี speculative-decoding head ของตัวเอง และช่วยเร่งความเร็ว decode ได้อย่างวัดผลได้เมื่อระบบ serving ใช้งาน

มันยังเป็นรุ่นที่รองรับวิดีโอของตระกูลนี้ด้วย เช็คพอยต์เปิดเรือธง Qwen3.8-2.4T-A95B ในรูปแบบที่ดาวน์โหลดได้นั้นในทางปฏิบัติรองรับเฉพาะข้อความ และ API Qwen3.8-Max ที่โฮสต์ไว้เพิ่มความสามารถด้านภาพบนพื้นฐานของน้ำหนักเหล่านั้น ส่วนรุ่น 27B คือน้ำหนักที่คุณดาวน์โหลดและรันได้จริง ซึ่งรองรับข้อความ รูปภาพ และวิดีโอได้ทันที — นี่คือเหตุผลที่เส้นทาง CPU สำหรับโหมดวิดีโอของมันน่าจับตามอง

สิ่งที่ SGLang PR เปลี่ยนแปลงจริง

Pull request (sgl-project/sglang #35492) นี้มีขอบเขตแคบและอ่านง่าย คำอธิบายของมัน: “PR นี้มีวัตถุประสงค์เพื่อรองรับ Qw​en3.8 text+video โดยเพิ่ม torchcodec, ffmpeg และลบ pin_memory” ในทางปฏิบัติ นั่นคือการเปลี่ยนแปลงสามอย่าง

• torchcodec — ไลบรารีถอดรหัสวิดีโอที่ใช้ ffmpeg ของ PyTorch — ถูกเพิ่มเข้าไปในสแตก เพื่อให้เฟรมวิดีโอสำหรับ Qw​en3.8 text+video สามารถถอดรหัสและประมวลผลล่วงหน้าบน CPU ของโฮสต์ได้ PR นี้กำหนดให้ torchcodec 0.12.0 ใช้กับ torch 2.12 และระบุว่า ffmpeg ต้องเป็นเวอร์ชันต่ำกว่า 9

• pin_memory ถูกลบออกจากเส้นทางมัลติโมดัล pin_memory คือการปรับแต่งเพื่อเพิ่มประสิทธิภาพการถ่ายโอนข้อมูลไปยัง GPU โดยตรึงบัฟเฟอร์ของโฮสต์ไว้สำหรับการคัดลอกแบบอะซิงโครนัสที่รวดเร็วไปยังอุปกรณ์ การตัดทิ้งบนเส้นทางที่ใช้ CPU เพียงอย่างเดียวเป็นข้อบ่งชี้ว่าฮาร์ดแวร์เป้าหมายไม่มีตัวเร่งความเร็วแบบแยกส่วนอยู่ในเส้นทางข้อมูล

• คำสั่งการสร้างใหม่เปิดใช้โมเดลจริง — Qwen/Qwen3.8-27B — ผ่าน sglang.launch_server บน CPU โดยเปิดใช้งานเส้นทางอินพุตข้อความ+วิดีโอ

อ่านป้ายสถานะก่อนจะสร้างอะไรจากมัน: PR นี้ยังเป็นดราฟต์, การรัน CI ทั้งสองครั้งกำลังล้มเหลว, และ ณ วันนี้ยังรอการรีวิวจากเจ้าของโค้ดของ SGLang อยู่ มันเป็นเพียงทิศทาง ไม่ใช่เวอร์ชันเผยแพร่ บริบทสำคัญคือ SGLang รองรับ Qwen3.8-27B บน GPU อยู่แล้ว — cookbook ครอบคลุม H200, RTX PRO 6000, RTX 5090 และ DGX Spark พร้อมอิมเมจเฉพาะ lmsysorg/sglang:qwen38-27b — ดังนั้นเส้นทาง CPU ที่รองรับข้อความ+วิดีโอจึงเป็นสิ่งที่ใหม่จริง ๆ

ทำไม CPU text+video ถึงสำคัญมากกว่าที่ฟังดู

อาลีบาบาวางตำแหน่ง 27B สำหรับ Edge AI ตั้งแต่วันแรก — MediaTek ปรับให้เข้ากับชิปมือถือ Dimensity และระบบ cockpit ในรถยนต์ C-X1 ในวันเดียวกับที่ปล่อย weights ออกมา เรื่องราวการปรับใช้ในเครื่องตัวเอง (local deployment) ยิ่งตอกย้ำ: การทำ quantization แบบ Q4_K_M มีขนาดประมาณ 17.1GB ซึ่งพอดีกับ GPU สำหรับผู้บริโภคขนาด 24GB หรือ Mac ที่ใช้ Apple Silicon พร้อมหน่วยความจำรวม 32GB สิ่งเดียวที่เรื่องราวนั้นทำไม่ได้คือการประมวลผลวิดีโอบนเครื่องที่ไม่มี GPU เลย นั่นคือช่องว่างที่ PR นี้เข้ามาแก้

เส้นทางประมวลผลข้อความ+วิดีโอด้วย CPU ทำให้การเข้าใจวิดีโอสามารถนำไปใช้งานบนเครื่อง CPU ทั่วไปได้ เช่น เครื่องเสมือน เซิร์ฟเวอร์ขนาดเล็ก หน่วยแร็คภายในองค์กร เกตเวย์เอดจ์ ซึ่งงานเหล่านี้เป็นแบบอะซิงโครนัสและให้ความสำคัญกับปริมาณงานมากกว่าความหน่วง การสร้างคำบรรยายวิดีโอ การกลั่นกรองเนื้อหา การแยกเอกสารและไดอะแกรม การค้นหาบันทึกแบบออฟไลน์ ล้วนเป็นงานแบตช์ที่ไม่จำเป็นต้องใช้ GPU แต่ปัจจุบันงานเหล่านี้ยังถูกสมมติว่าต้องใช้ GPU สำหรับ VLM ใดๆ ที่รับอินพุตวิดีโอ

การแลกเปลี่ยนที่ตรงไปตรงมาคือ Qwen3.8-27B เป็นโมเดลที่มีพารามิเตอร์ 27 พันล้านพารามิเตอร์ และไม่มีเส้นทาง CPU ใดที่จะทำให้ 27B เร็วได้ คาดหวังได้เพียงหลักหน่วย tokens ต่อวินาทีบนเซิร์ฟเวอร์ระดับ AVX-class ที่จริงจัง โดยมีเฟรมวิดีโออยู่ในบริบท — เหมาะสำหรับงานแบตช์และงานข้ามคืน ไม่เหมาะสำหรับการแชทแบบโต้ตอบผ่านวิดีโอ จุดประสงค์ของเส้นทาง CPU คือการมีตัวเลือกนี้ไว้จริง ๆ: การปรับใช้งานแบบไม่มี GPU สามารถรันโหมดวิดีโอของโมเดลเดียวกันได้ แทนที่จะลดระดับไปใช้โมเดลวิทัศน์ที่เล็กกว่า หรือส่งทุกเฟรมไปยัง GPU บนคลาวด์

Qwen3.8-27B ทำงานที่ไหนในปัจจุบัน

ระบบนิเวศตามทันโมเดลอย่างรวดเร็ว ฝั่งโฮสต์เองก็มี llama.cpp และ LM Studio พร้อมแพ็ก GGUF ที่ลดขนาดลงไปจนถึงประมาณ 10.7GB แบบ 2-bit quant, Ollama สำหรับคำสั่งบรรทัดเดียว และ vLLM กับ SGLang สำหรับการเสิร์ฟอย่างจริงจัง ส่วนใหญ่ตอนนี้เป็นข้อความหรือรูปภาพ; ส่วนวิดีโอบน CPU ยังเป็นส่วนที่กำลังพัฒนา

หากคุณไม่ต้องการรันโมเดล 27B ด้วยตัวเอง เส้นทางแบบโฮสต์มีอยู่แล้ว: OrcaRouter ให้บริการqwen/qwen3.8-27b ด้วยอินพุตข้อความ รูปภาพ และวิดีโอ หน้าต่างบริบทขนาด 262,144 โทเคน และเอาต์พุตข้อความ ในราคา $0.33 ต่อล้านโทเคนอินพุต และ $2.40 ต่อล้านโทเคนเอาต์พุต มันอยู่เบื้องหลังเอนด์พอยต์ที่เข้ากันได้กับ OpenAI เช่นเดียวกับโมเดลอื่นๆ ทั้งหมดบนแพลตฟอร์ม — คีย์ API เดียว ไม่ต้องมีสัญญาเพิ่มเติม — และการเฟลโอเวอร์อัตโนมัติและ routing DSL ของแพลตฟอร์มใช้ได้กับโมเดลมากกว่า 200 รายการบนคีย์นั้น โมเดลที่เพิ่งเปิดตัว 5 วันพร้อมเส้นทาง CPU ที่ยังไม่ได้รับการพิสูจน์ เป็นกรณีตัวอย่างที่ชัดเจนสำหรับการใช้ routing แทนการเชื่อมต่อแบบตายตัว: คุณสามารถลอง Qwen3.8-27B กับปริมาณงานจริงผ่าน route โดยไม่ต้องเดิมพันเส้นทางการเรียกทั้งหมดของคุณกับสแตกการให้บริการเพียงตัวเดียว และสลับระหว่างเวอร์ชันที่โฮสต์ด้วยตัวเองกับเวอร์ชันที่โฮสต์โดยไม่ต้องแก้ไขโค้ด

ตัวเลข — รายงานโดยผู้ขาย และน่าตรวจสอบ

ตัวเลขสำคัญทุกตัวด้านล่างนี้เป็นของอาลีบาบาเอง จากโมเดลการ์ดและเอกสารเปิดตัว โมเดลนี้เพิ่งออกมาได้ห้าวัน และการทดลองซ้ำโดยอิสระเพิ่งเริ่มปรากฏให้เห็น ดังนั้นควรถือว่าสิ่งเหล่านี้เป็นข้อกล่าวอ้างที่มีทิศทางชัดเจน มากกว่าจะเป็นบทสรุป สำหรับโมเดลขนาด 27B คะแนนด้านการเขียนโค้ดและเอเจนต์เป็นสิ่งที่ดึงดูดความสนใจ:

• SWE-bench Pro — 61.7 (รายงานโดย Alibaba; ตารางของตัวเองแสดง Claude Opus 4.6 Max ที่ 53.4)

• Terminal-Bench 2.1 — 73.0 (การเขียนโค้ดในเทอร์มินัลโดยใช้เอเจนต์)

• OSWorld-Verified — 84.3 (งานเอเจนต์ที่ใช้คอมพิวเตอร์)

• AndroidWorld — 81.9

• DeepSWE 1.1 — 42.2, ประมาณสามเท่าของ 13.3 ของ open 27B รุ่นก่อนหน้า

ในด้านวิทัศน์ — ด้านที่บทความนี้พูดถึงจริงๆ — Alibaba รายงาน VideoMME 87.0 สำหรับความเข้าใจวิดีโอ และ MathVision 90.0 สำหรับการให้เหตุผลเชิงภาพโดยไม่ใช้เครื่องมือ การประเมินเบื้องต้นของ Artificial Analysis ให้โมเดลนี้ได้ 52 ในดัชนีความฉลาด (Intelligence Index) และ 51 ในดัชนีเชิงตัวแทน (Agentic Index) ซึ่งแข่งขันได้กับโมเดลปิดขนาดใหญ่กว่ามากในการตั้งค่าการให้เหตุผลบางอย่าง; คะแนนเหล่านี้ยังเป็นคะแนนเบื้องต้นสำหรับโมเดลที่มีอายุเพียงห้าวัน

ข้อควรระวังข้อหนึ่งส่งผลอย่างไม่สมส่วนต่อผู้ที่รันโมเดลในเครื่องหรือบน CPU นั่นคือแป้นปรับระดับการใช้เหตุผล Qwen3.8-27B มาพร้อมโหมดคิด (thinking mode) ที่เปิดอยู่และการตั้งค่า reasoning_effort แบบต่อคำขอ (low / medium / xhigh) ค่าเริ่มต้น xhigh คิดมากเกินไปอย่างร้ายแรง: การรันครั้งแรกอันโด่งดังของ GGUF ขนาด 17GB ใช้เวลาประมาณ 21 นาทีและโทเค็นการให้เหตุผล 22,000 โทเค็นเพื่อวาดภาพง่าย ๆ โดยเฉพาะบน CPU ต้องตั้งค่า reasoning_effort อย่างรอบคอบ — ความแตกต่างระหว่างการใช้งานได้อย่างโต้ตอบกับใช้ไม่ได้นั้นคือพารามิเตอร์ตัวเดียว

ดูอะไรดี

สามสิ่งจะบอกคุณว่าเส้นทาง CPU กลายเป็นจริงหรือไม่:

• PR #35492 จะถูกผสานหรือไม่.มันเป็นดราฟต์ที่ CI ยังแดงอยู่ตอนนี้ จุดที่เวอร์ชันที่ถูกผสานและผ่าน CI (เขียว) ลงในรีลีสคือตอนที่พาธ text+video ของ CPU เริ่มทำงานได้สำหรับพวกเราที่เหลือ.

• การวัดประสิทธิภาพอิสระ ตัวเลข 61.7 SWE-bench Pro และ 87.0 VideoMME เป็นข้อมูลที่รายงานโดยผู้ผลิต การทดสอบของ LMArena และ Artificial Analysis ในอีกสองสามสัปดาห์ข้างหน้าจะแสดงให้เห็นว่าผลลัพธ์จะคงอยู่ได้มากเพียงใดนอกกรอบทดสอบของ Alibaba เอง

• ไม่ว่าเวอร์ชันคอนเท็กซ์ 1M แบบโฮสต์จะเกิดขึ้นจริงหรือไม่ เนทีฟ 262K ก็ถือว่ามากอยู่แล้ว; โหมดมัลติโมดัลล้านโทเค็นคือจุดที่การประหยัดแคชของไฮบริดแอตเทนชันคุ้มค่ากับที่ลงทุนไป

สำหรับตอนนี้การตัดสินใจนั้นง่าย หากคุณมีฮาร์ดแวร์ที่รองรับ โมเดล Q4 GGUF ขนาด 17GB พร้อมด้วย SGLang หรือ llama.cpp ก็สามารถรันโมเดลได้ในวันนี้ และ PR ข้อความ+วิดีโอบน CPU ก็แสดงให้เห็นว่าเส้นทางที่ไม่ใช้ GPU กำลังมุ่งหน้าไปทางไหน หากคุณไม่มี Qwen3.8-27B ก็สามารถเรียกใช้ผ่าน OrcaRouter ได้ในราคา $0.33 ต่อล้านโทเคน input และ $2.40 ต่อล้านโทเคน output ภายใต้คีย์เดียว ไม่ว่าทางไหน โมเดลโอเพน 27B ที่รองรับวิดีโอก็เป็นโมเดลที่น่าจับตามองที่สุดในเจเนอเรชัน Qw​en 3.8 — และมันเพิ่งเปิดตัวมาได้ห้าวันเท่านั้น