Microsoft Mage-VL: โมเดลวิดีโอ 4B แบบ Codec-Native เปิดตัวโดยไม่มีการประกาศ

ไม่มีบล็อกโพสต์ของ Microsoft เกี่ยวกับ Mage-VL. ไม่มีรายการในห้องข่าว Azure ไม่มีรายการในแคตตาล็อก Foundry ไม่มีเธรดเปิดตัว ไม่มีอะไรในช่องทางผลิตภัณฑ์ที่ Microsoft มักใช้แนะนำโมเดล สิ่งที่มีอยู่แทนคือที่เก็บ Hugging Face — microsoft/Mage-VL, หกคอมมิต, น้ำหนัก 10.8 GB, Apache-2.0 — โฟลเดอร์ GitHub ของสคริปต์อนุมาน, หน้าโปรเจกต์ที่ดูแลโดยบางสิ่งที่เรียกตัวเองว่า Microsoft Mage Team, และรายงาน arXiv ที่มีผู้เขียน 23 คน เมื่ออ่านรวมกัน สิ่งประดิษฐ์เหล่านี้อธิบายโมเดลวิทัศน์-ภาษาขนาด 4B ซึ่งแนวคิดหลักนั้นผิดปกติอย่างแท้จริง: แทนที่จะถอดรหัสวิดีโอเป็นเฟรมที่เว้นระยะเท่ากันแล้วส่งกริดหนาแน่นของแพตช์ผ่านตัวเข้ารหัสที่ฝึกจากเว็บ Mage-VL กลับอ่านบิตสตรีมที่ถูกบีบอัดโดยตรง โดยใช้ตัวเข้ารหัสที่สร้างจากศูนย์ชื่อ Mage-ViT เพื่อเก็บเฉพาะแพตช์ที่โคเดกใช้บิตไป Microsoft รายงานว่าวิธีนี้ลดโทเค็นภาพลงมากกว่า 75% และให้ความเร็วที่เพิ่มขึ้น (wall-clock) ถึง 3.5 เท่า ขณะที่เทียบเท่ากับ Qwen3-VL-4B บนภาพนิ่ง และเอาชนะโมเดล Phi-4-Reasoning-Vision ขนาด 15B ของ Microsoft เองบนวิดีโอ

ประโยคสุดท้ายนั้นคือส่วนที่ควรเก็บเอาไว้ห่าง ๆ ตัวเลขประสิทธิภาพทุกตัวในบทความนี้สืบย้อนไปถึงเอกสารวิจัย โมเดลการ์ด หรือหน้าโปรเจกต์ของไมโครซอฟต์เอง สิบวันหลังจากที่น้ำหนักถูกเผยแพร่ ยังไม่มีหน่วยงานอิสระใดทำซ้ำผลลัพธ์ได้ ไม่มีลีดเดอร์บอร์ดจากบุคคลที่สามที่จัดอันดับโมเดลนี้ และ—ตามที่หน้า Hugging Face ระบุไว้อย่างชัดเจน—โมเดลนี้ "ไม่ได้ถูกใช้งานโดย Inference Provider ใด ๆ" ดังนั้นจึงไม่มีแม้แต่เอนด์พอยน์ที่โฮสต์ไว้ให้ใครก็ตามลองวัดประสิทธิภาพเล่น ๆ เนื้อหาต่อจากนี้จะแยกแยะระหว่างสิ่งที่ที่เก็บโค้ดพิสูจน์ได้กับสิ่งที่ไมโครซอฟต์เพียงแค่อ้าง เพราะในการปล่อยเวอร์ชันโดยไม่มีการประกาศ สองสิ่งนี้เป็นคนละหมวดหมู่กันอย่างสิ้นเชิง

สิ่งที่มีอยู่จริงหลังผ่านไปสิบวัน

พื้นผิวที่ตรวจสอบได้ของการเปิดตัวครั้งนี้มีขนาดเล็กและควรค่าแก่การระบุอย่างแม่นยำ

• น้ำหนัก, ลงวันที่ 26 กรกฎาคม 2026. ชิ้นส่วน safetensors สองชิ้นขนาด 4.97 GB และ 4.52 GB รวมถึงไฟล์แยกขนาด 1.07 GB ที่ชื่อว่า streammind_gate.safetensors ตัวอ่านของ Hugging Face เองรายงานว่ามีพารามิเตอร์ 5B ในรูปแบบ BF16 — โดย 4B อยู่ในตัวถอดรหัสภาษา และส่วนที่เหลือถูกแบ่งระหว่างตัวเข้ารหัสภาพกับเกทนั้น

• รายงานทางเทคนิค ยื่นเมื่อวันที่ 27 กรกฎาคม 2026 (arXiv 2607.24904), หนึ่งเวอร์ชัน, ผู้เขียน 23 คน, ชื่อเรื่อง "Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model."

• โค้ดที่รันได้ ไม่ใช่แค่ค่าน้ำหนัก ที่เก็บโค้ดมาพร้อมกับ modeling_mage_vl.py, processing_mage_vl.py, โปรเซสเซอร์วิดีโอสองตัว รวมถึง codec_video_processing_mage_vl.py ที่ออกแบบมาโดยเฉพาะ และ streammind_gate.py — Python ที่เขียนขึ้นเองประมาณ 175 KB auto_map ใน config.json จัดเส้นทางคลาส Transformers หกคลาสไปยังไฟล์เหล่านั้น ซึ่งเป็นเหตุผลที่ที่เก็บโค้ดนี้ถูกติดแท็ก custom_code

• ใบอนุญาตสองฉบับ ไม่ใช่ฉบับเดียว Mage-VL อยู่ภายใต้ Apache-2.0; ตัวเข้ารหัส Mage-ViT แบบสแตนด์อโลน เผยแพร่แยกต่างหากภายใต้ MIT.

• เดโมที่ใช้งานได้โดยไม่ต้องติดตั้ง. Microsoft รัน microsoft/mage-vl-demo เป็น Hugging Face Space บน ZeroGPU และ community Space สองแห่งใช้งานโมเดลนี้แล้ว.

• การตอบรับจากชุมชนในช่วงแรก ซึ่งก่อตัวเร็วกว่าการสื่อสารของผู้พัฒนาของโมเดลเอง ในเดือนที่ผ่านมา มีไลก์ 268 ครั้ง ยอดดาวน์โหลด 435,784 ครั้ง โมเดลควอนไทซ์จากชุมชน 9 ตัว และโมเดลฟินจูน 2 ตัวในโมเดลทรี ตัวนับดาวน์โหลดรวมการดึงจากระบบอัตโนมัติและมิเรอร์ด้วย ดังนั้น จึงควรถือว่าตัวเลขดิบเป็นสัญญาณของความสนใจ มากกว่าเป็นการนำไปใช้งานจริง

• โมเดลพี่น้อง. Mage-Flow โมเดลสำหรับสร้างภาพจากข้อความและแก้ไขตามคำสั่ง ซึ่งสร้างขึ้นด้วยงบประมาณคงที่ 4B เดียวกัน เปิดตัวเมื่อวันที่ 22 กรกฎาคม ซึ่งเร็วกว่าสี่วัน และที่เก็บโค้ดบน GitHub นำเสนอ Mage ว่าเป็น "ตระกูลโมเดลมัลติโมดัลน้ำหนักเบาที่เป็นมิตรต่อการวิจัย" ซึ่งถือเป็นสิ่งที่ใกล้เคียงกับคำชี้แจงการวางตำแหน่งที่สุดเท่าที่ใครเคยเผยแพร่

เมื่อเทียบกับสิ่งนั้น รายการของสิ่งที่ไม่มีอยู่ก็ให้ข้อมูลได้ไม่แพ้กัน ไม่มีบล็อกโพสต์หรือข่าวประชาสัมพันธ์จากไมโครซอฟต์ ไม่มีการลงรายการใน Azure AI Foundry ซึ่งหมายความว่าไม่มีเส้นทางสนับสนุนสำหรับองค์กร ไม่มี SLA ไม่มี managed endpoint ไม่มีผู้ให้บริการ inference รายใดให้บริการ ไม่มีการรองรับ vLLM หรือ SGLang: คำขอจากชุมชนเพื่อเพิ่ม Mage-VL ใน SGLang ถูกยื่นเมื่อวันที่ 28 กรกฎาคมเป็น issue #32646 และในขณะที่เขียนบทความนี้ก็ยังคงเปิดอยู่ โดยไม่มี pull request ที่เชื่อมโยงและไม่มีการตอบกลับจากผู้ดูแล และไม่มีการประเมินอิสระใด ๆ ทั้งสิ้น — โมเดลนี้ไม่มีอยู่ในลีดเดอร์บอร์ดที่เป็นกลาง ซึ่งคำกล่าวอ้างเช่น "เอาชนะโมเดล 15B ในงานวิดีโอ" โดยปกติจะถูกทดสอบที่นั่น

แนวคิดเดียว: อ่านโคเดก ไม่ใช่เฟรม

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

นั่นเป็นปริมาณการคำนวณซ้ำซ้อนมหาศาล และโคเดกวิดีโอสมัยใหม่ได้แก้ปัญหาพื้นฐานนี้มานานหลายทศวรรษแล้ว H.264 และ HEVC ไม่ได้เก็บทุกเฟรม พวกมันเก็บเฟรมอ้างอิง (I-frame) เป็นครั้งคราวในรูปแบบเต็ม แล้วอธิบายเฟรมระหว่างนั้นด้วยเวกเตอร์การเคลื่อนไหวและส่วนต่างที่เหลือ — "บล็อกนี้ย้ายมาตรงนี้ และนี่คือสิ่งที่เปลี่ยนไป" ส่วนที่น่าสนใจของวิดีโอ เกือบจะโดยโครงสร้างแล้ว คือส่วนที่เอ็นโคเดอร์ใช้บิตไปกับมัน

Mage-ViT ใช้ประโยชน์จากสิ่งนั้นโดยตรง มันทำงานที่ความละเอียดระดับแพตช์ 16x16 โดยเก็บทุกแพตช์ของเฟรมอ้างอิง และสำหรับเฟรมที่ถูกทำนาย มันจะเก็บเฉพาะแพตช์ที่ถูกทำเครื่องหมายว่ามีนัยสำคัญโดยเวกเตอร์การเคลื่อนไหวและพลังงานตกค้างของตัวโคเดกเอง — ซึ่งเป็นบริเวณที่นำพาข้อมูลจริง การเคลื่อนไหว หรือการเปลี่ยนฉาก — ในขณะที่ทิ้งแพตช์ที่มีความซ้ำซ้อนต่ำและที่ซ้ำซ้อนโดยสมบูรณ์ Microsoft ระบุว่าการลดลงที่ได้นั้นมากกว่า 75% ของโทเคนภาพ โดยที่บริบทเชิงพื้นที่และเวลายังคงถูกรักษาไว้ เพราะเฟรมอ้างอิงยังคงนำพาฉากทั้งหมดอยู่ การออกแบบนี้ไม่ขึ้นกับโคเดก โดยเส้นทางแบบดั้งเดิมรองรับ H.264 หรือ HEVC และเส้นทางแบบโครงข่ายประสาทรองรับ DCVC-RT

ความงดงามคือการประเมินการเคลื่อนไหวนั้นถูกทำไว้เสร็จสรรพแล้ว วิดีโอที่ถูกบีบอัดทุกไฟล์บนอินเทอร์เน็ตมาพร้อมกับแผนผังระบุตำแหน่งที่มีการเคลื่อนไหว ซึ่งคำนวณโดยตัวเข้ารหัสและชำระค่าใช้จ่ายโดยผู้ที่อัปโหลดมัน ไปป์ไลน์แบบทั่วไปทิ้งแผนผังนั้นทันทีที่ถอดรหัสเป็น RGB แล้วใช้เวลา GPU เพื่อค้นหาข้อมูลเดียวกันนั้นใหม่อีกครั้ง Mage-VL เพียงแค่ปฏิเสธที่จะทิ้งมันไป ไม่ว่าตัวเลข benchmark จะคงอยู่หรือไม่ ข้อสังเกตดังกล่าวคือคุณูปการที่ยั่งยืนตรงนี้ — และนี่คือเหตุผลที่รีลีสนี้คุ้มค่าแก่การอ่านแม้คุณจะไม่เคยดาวน์โหลด weights ก็ตาม

สิ่งที่สะอาดที่สุดเกี่ยวกับการทดลอง

การตัดสินใจเชิงออกแบบที่ซ่อนอยู่ในการตั้งค่านี้ทำให้ผลลัพธ์สามารถตีความได้ง่ายกว่าการเปิดตัวโมเดลทั่วไปมาก และแทบไม่มีใครที่รายงานข่าวการเปิดตัวครั้งนี้ชี้ให้เห็นว่า โมเดลภาษาถูกกำหนดให้คงที่

ตัวถอดรหัส (decoder) ของ Mage-VL คือ Qwen3-4B-Instruct-2507 ที่ไม่มีการดัดแปลงใดๆ เส้นฐานเปรียบเทียบ Qwen3-VL-4B ใช้แกนหลัก Qwen3 ขนาด 4B เดียวกันกับตัวเข้ารหัสภาพ (visual encoder) ที่ผ่านการฝึกด้วยข้อมูลเว็บแบบดั้งเดิม ดังนั้นเมื่อ Mage-VL ทำผลงานได้ดีกว่า Qwen3-VL-4B ความแตกต่างนั้นเกิดจากตัวเข้ารหัสและการแบ่งโทเคนแบบ codec-native ไม่ใช่เกิดจากโมเดลภาษาที่ใหญ่กว่าหรือฝึกมาดีกว่า นี่คือการทดลองแบบควบคุม (controlled ablation) ที่ถูกนำเสนอในรูปแบบการเปรียบเทียบผลิตภัณฑ์ และนี่คือจุดแข็งด้านระเบียบวิธีที่สำคัญที่สุดของการเปิดตัวครั้งนี้

มันกลับให้ผลในอีกทางหนึ่งด้วย และความซื่อสัตย์ก็จำเป็นต้องกล่าวเช่นนั้น การเปรียบเทียบแบบ backbone เดียวกันคือการทดสอบแนวคิดตัวเข้ารหัส (encoder) อย่างยุติธรรมที่สุด และพร้อมกันนั้นก็เป็นกรอบที่น่าจะเชิดชูมันมากที่สุด — Microsoft เลือก baseline ที่แยกการมีส่วนร่วมของตัวเองออกมา การเปรียบเทียบ Phi-4 ไม่มีคุณสมบัตินั้น: Phi-4-Reasoning-Vision-15B และ Phi-4-MM-5.6B ใช้ backbone ที่ต่างกัน สูตรการฝึกที่ต่างกัน และ post-training ที่ต่างกัน "beat โมเดล 15B ของเราบนวิดีโอ" เป็นผลลัพธ์จริง แต่เป็นผลลัพธ์ที่หลวมกว่ามาก และยังเป็นการเปรียบเทียบกับงานเก่าของ Microsoft เอง ซึ่งเป็นประเภทที่ชนะง่ายที่สุด

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

ตัวเลข และว่าตัวเลขเหล่านั้นเป็นของใคร

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

• Video-MME — Mage-VL-4B 64.0 เทียบกับ Qwen3-VL-4B 59.7 เทียบกับ Phi-4-Reasoning-Vision-15B 55.3

• NExT-QA — 83.1 เทียบกับ 79.8 เทียบกับ 69.0

• LongVideoBench — 61.3 vs 57.7 vs 51.2

• VideoEval-Pro — 45.2 เทียบกับ 20.7 สำหรับ Phi-4

• Timelens-QVHighlight (การอ้างอิงเชิงเวลา) — 57.4 เทียบกับ 34.9 เทียบกับ 11.6

• Ref-DAVIS17 (การติดตามอ้างอิง) — 25.83 เทียบกับ 7.48 เทียบกับ 2.15

• DocVQA-val — 95.14 vs 94.69 vs 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81.80 เทียบกับ 81.60 เทียบกับ 81.70

• ChartQA — 84.88 เทียบกับ 83.96 เทียบกับ 83.40

• MMStar — 67.32 vs 62.04 vs 59.63

• RealWorldQA — 70.46 เทียบกับ 70.85 เทียบกับ 70.72 ซึ่งเป็นหนึ่งในแถวที่ Mage-VL แพ้

• MMBench-EN-dev — 84.02 เทียบกับ 83.25 โดย Phi-4-Reasoning-Vision-15B นำหน้าทั้งคู่ที่ 84.19

• CV-Bench-3D / CV-Bench-2D — 94.75 เทียบกับ 92.30 และ 82.13 เทียบกับ 81.00

• EmbSpatial — 82.67 เทียบกับ 77.50

• OVO-Bench (สตรีมมิง)ได้คะแนนรวม 64.00 ถือเป็นสถาปัตยกรรมแบบสตรีมมิงที่ล้ำสมัยที่สุด; ชุดย่อยการรับรู้ภาพแบบเรียลไทม์มีค่าเฉลี่ย 79.84% เทียบกับ 72.8% ของ Qwen3-VL-4B ที่ 1 fps

• Mage-ViT เป็นเอนโค้ดเดอร์แบบสแตนด์อโลน — สูงกว่า 86.3% บน ImageNet ด้วยงบประมาณ 676 โทเคน และสูงกว่า 96.1% บน Food-101

การอ่านตารางนั้นสามครั้งมีค่ามากกว่าตัวตารางเอง

สำหรับภาพ คำว่า "parity" (ความเท่าเทียม) เป็นคำที่ตรงไปตรงมา DocVQA นำ 0.45, OCRBench นำ 0.20, ChartQA นำ 0.92, MMBench นำ 0.77 — ตัวเลขเหล่านี้อยู่ในช่วงที่เทมเพลตพรอมพ์หรือซีดการถอดรหัสที่แตกต่างกันอาจทำให้ลำดับกลับกันได้ และ RealWorldQA จริงๆ แล้วตกเป็นของ Qwen3-VL-4B Microsoft พูดเช่นนั้นไว้แล้ว โดยนำเสนอประสิทธิภาพด้านภาพว่าเท่าเทียมกันมากกว่าจะเป็นชัยชนะ และการนำเสนอแบบนั้นก็ถูกต้อง หากเวิร์กโหลดของคุณคือการตอบคำถามจากเอกสารและภาพ เวอร์ชันนี้ก็ไม่มีเหตุผลให้คุณต้องย้ายไปที่อื่น

ในด้านวิดีโอและการยึดโยงเชิงเวลา ช่องว่างมีขนาดใหญ่และสม่ำเสมอ Timelens-QVHighlight เพิ่มขึ้นเกือบสองเท่าของ baseline; Video-MME, NExT-QA และ LongVideoBench ต่างขยับขึ้น 3.6 ถึง 4.3 จุดในทิศทางเดียวกันโดยที่ backbone คงที่ ความสม่ำเสมอข้ามชุดเกณฑ์มาตรฐานที่เน้นสิ่งที่แตกต่างกันคือรูปแบบที่คุณคาดหวังได้ หากการเปลี่ยนแปลง encoder เป็นของจริง ไม่ใช่เพียงสิ่งประดิษฐ์จากการปรับแต่ง

ไม่ควรอ้างอิงสองแถวโดยไม่มีบริบท. Ref-DAVIS17 ที่ 25.83 เทียบกับ 7.48 ดูเหมือนการถล่ม 3.5 เท่า และเดลต้าเชิงพื้นที่หลักในรายงานรวมถึง +11.0 บน VSI-Bench และ +53.1 บน CrossPoint. เมื่อเบสไลน์ได้คะแนนใกล้ค่าพื้นในงานหนึ่ง เดลต้าส่วนใหญ่จะวัดว่าโมเดลใดถูกฝึกให้เข้าใจรูปแบบของงาน — ไม่ใช่ว่าโมเดลใดมีความสามารถมากกว่า. ข้อควรระวังเดียวกันนี้ใช้กับผลลัพธ์สตรีมมิงในเชิงสัมบูรณ์: บน SoccerNet ตัวเลขที่รายงานของ Mage-VL คือ 55.54 TimVal, 83.14 ROC-AUC และ F1 เท่ากับ 16.35. ค่า F1 ที่ 16.35 เป็นตัวเลขระดับแนวหน้าในการประเมินที่เพิ่งเกิดขึ้นใหม่ ไม่ใช่ปัญหาที่ได้รับการแก้แล้ว. การรับรู้สตรีมมิงเชิงรุกยังอยู่ในช่วงเริ่มต้น และคะแนนสัมบูรณ์ของผู้นำก็บอกเช่นนั้น.

เกต: แบบจำลองที่ตัดสินใจว่าจะพูดเมื่อใด

แนวคิดทางสถาปัตยกรรมชิ้นที่สองเป็นแนวคิดที่มีผลกระทบต่อผลิตภัณฑ์ชัดเจนที่สุด และมันอธิบายถึงไฟล์ลึกลับขนาด 1.07 GB นั้น

Mage-VL แบ่งการสตรีมออกเป็นสองกระบวนการ ซึ่งในบทความเรียกว่า System 1 และ System 2 โดย System 1 เป็น "เกตการรู้คิด" (cognition gate) ที่มีน้ำหนักเบา ซึ่งคอยเฝ้าดูหน้าต่างแบบเลื่อนของฟีเจอร์โคเดกแต่ละตัว และประเมินความน่าจะเป็นว่ามีบางสิ่งที่น่าพูดถึงเพิ่งเกิดขึ้นเสร็จสิ้นหรือไม่ เมื่อต่ำกว่าเกณฑ์ มันจะเงียบและส่วนที่สิ้นเปลืองทรัพยากรของโมเดลจะไม่ถูกเรียกใช้เลย เมื่อสูงกว่าเกณฑ์ ตัวถอดรหัสเต็มรูปแบบจะถูกเรียกขึ้นมาเพื่อสร้างการตอบสนอง การกำหนดค่าในเดโม่ใช้หน้าต่างเชิงเหตุผลขนาด 30 วินาทีที่ 1 fps โดย CLI เปิดเผยเกณฑ์โดยตรงเป็น --gate_threshold และจุดเริ่มต้นการสตรีมจะประมวลผลวิดีโอทีละเซกเมนต์ (inference_streaming.py --video_backend codec --segment_sec 8) เฉพาะเกตเท่านั้นที่ถูกฝึกในขั้นตอนสุดท้าย บนตัวอย่างสตรีมมิ่งจำนวน 3.35 ล้านตัวอย่าง

มีสองสิ่งที่น่าสังเกตเกี่ยวกับเรื่องนี้ ประการแรก เกตไม่ใช่หัวจำแนกประเภทขนาดเล็กที่ถูกนำมาเสียบติดไว้บนโมเดลหลัก: น้ำหนัก BF16 จำนวน 1.07 GB คิดเป็นพารามิเตอร์ประมาณครึ่งพันล้านตัว ซึ่งเป็นโมเดลจริงในตัวของมันเอง ที่ถูกเผยแพร่เป็น checkpoint แยกต่างหาก ประการที่สอง ชื่อไฟล์คือ streammind_gate.safetensors — การตั้งชื่อเช่นนี้บ่งบอกว่าคอมโพเนนต์ดังกล่าวสืบทอดมาจากงานด้าน streaming-perception ก่อนหน้านี้ มากกว่าจะถูกคิดค้นขึ้นสำหรับงานวิจัยนี้ แม้ว่าตัว repo เองจะไม่ได้ระบุถึงที่มานั้นอย่างชัดเจน

เหตุผลที่เรื่องนี้สำคัญในเชิงพาณิชย์: สำหรับวิดีโอที่ทำงานตลอดเวลา ต้นทุนหลักไม่ใช่ความหน่วงต่อการเรียกใช้ แต่คือความถี่ในการเรียกใช้ ฟีดกล้องที่ทำงาน 24/7 ผ่าน VLM ทั่วไปที่ 1 เฟรมต่อวินาที หมายถึงการคำนวณไปข้างหน้า 86,400 ครั้งต่อวัน ไม่ว่าจะมีเหตุการณ์เกิดขึ้นหรือไม่ เกตที่นิ่งเฉยในช่วง 99% ของฟุตเทจที่ไม่มีอะไรเกิดขึ้น จะเปลี่ยนโครงสร้างของค่าใช้จ่ายนั้น ไม่ใช่แค่ขนาดของมัน เกตของ Microsoft จะแม่นยำพอที่จะไว้วางใจให้ตัดสินใจเรื่องนั้นหรือไม่ คือสิ่งที่ไม่มีใครนอกห้องแล็บเคยทดสอบ

วันนี้คุณรันมันได้จริงๆ หรือ

ใช่ หากคุณมี GPU และความอดทน อุปสรรคมีอยู่จริง และส่วนใหญ่อยู่ในไปป์ไลน์วิดีโอ มากกว่าที่ตัวโมเดล

หน่วยความจำ. Microsoft ไม่ได้เผยแพร่ข้อกำหนด VRAM จากดัชนีน้ำหนัก: ชาร์ด 9.49 GB รวมกับเกต 1.07 GB รวมประมาณ 10.6 GB ของพารามิเตอร์ BF16 ดังนั้นการ์ด 16 GB จึงเป็นขั้นต่ำที่สมจริงสำหรับงานภาพ และ 24 GB ขึ้นไปเป็นเป้าหมายที่เหมาะสมเมื่อคุณเพิ่ม KV cache สำหรับวิดีโอยาวหรือหน้าต่างสตรีมมิ่ง นั่นคือการคำนวณจากขนาดไฟล์ ไม่ใช่สเปกจากผู้จำหน่าย — วัดก่อนจะจัดเตรียม

โค้ดแบบกำหนดเองเป็นสิ่งจำเป็น auto_map ชี้จุดเข้าใช้งานทุกจุดของ Transformers ไปยังโมดูลของรีโพสิทอรีเอง ดังนั้น trust_remote_code จึงเป็นสิ่งที่จำเป็น คุณกำลังรัน Python ของ Microsoft ไม่ใช่แค่โหลดเทนเซอร์ ยังไม่มี path สำหรับ vLLM หรือ SGLang ซึ่งหมายความว่าไม่มี paged attention ไม่มี continuous batching ไม่มี stack สำหรับ serving ในระดับ production ซึ่งเป็นช่องว่างที่สำคัญหากคุณหวังจะนำไปใช้เป็น endpoint

พาธโคเดกต้องการเครื่องมือระดับระบบ FFmpeg และ ffprobe ต้องอยู่ใน PATH ของคุณ แบ็กเอนด์โคเดกแบบดั้งเดิมขึ้นอยู่กับแพ็กเกจ codec-video-prep ซึ่งจัดเตรียมขั้นตอน cv-preinfer; เส้นทางนิวรัลต้องใช้ DCVC-RT; แบ็กเอนด์เฟรมธรรมดาต้องใช้ Decord ข้อกำหนดเหล่านี้ยังดึง flash-attn และ mamba-ssm ซึ่งคอมไพล์ส่วนขยาย CUDA — ให้ติดตั้ง PyTorch ที่ตรงกับชุดเครื่องมือของคุณก่อน หรือเผื่อเวลาสักครึ่งวันสำหรับการคอมไพล์

สิ่งที่คอนฟิกบอกคุณแต่การ์ดไม่บอก.ค่าเอมเบดดิ้งตำแหน่งสูงสุดคือ 262,144 ดังนั้นตัวถอดรหัสจึงสืบทอดบริบทระยะยาวของ Qwen3-4B ฝั่งวิทัศน์ทำงานด้วยอินพุต 448 พิกเซลพร้อมแพตช์ 16x16 เอ็นโค้ดเดอร์ 24 ชั้นที่มี hidden size 1024 การรวมเชิงพื้นที่แบบ 2x2 หนึ่งโทเคนต่อวินาทีของวิดีโอ และหน้าต่างสี่เฟรม การฝึกในระยะที่สามถึงความยาวเชิงเวลา 384 เฟรม เพดาน 262K ไม่เหมือนกับพฤติกรรมที่ผ่านการตรวจสอบแล้ว 262K และ 384 เฟรมคือความยาวที่โมเดลถูกสอนให้จัดการจริงๆ.

จุดบกพร่องที่ทราบแล้ว.มีกระทู้เปิดในที่เก็บโค้ดเมื่อวันที่ 4 สิงหาคม และยังไม่มีใครตอบ รายงานว่าโทเค็นไม่ตรงกันเมื่อส่งรูปภาพและวิดีโอในคำขอเดียวกัน ซอฟต์แวร์อายุสิบวันก็ทำตัวเหมือนซอฟต์แวร์อายุสิบวัน ถ้าอยากลองดูโดยไม่ต้องเจออะไรแบบนี้ Space ที่ Microsoft รันบน ZeroGPU คือตัวเลือกแบบไม่ต้องติดตั้งอะไรเลย

บรรทัดใบอนุญาตไม่เรียบง่ายเท่ากับ "Apache-2.0"

บัตรข้อมูลโมเดลระบุว่า Apache-2.0 ตัวเข้ารหัส Mage-ViT ระบุว่า MIT ทั้งคู่เป็นใบอนุญาตที่ผ่อนปรนพอ ๆ กับโอเพนเวตเท่าที่จะสามารถเป็นได้ แต่รีโพสิทอรีของตระกูลโมเดลระบุว่า "โมเดลเหล่านี้เผยแพร่เพื่อวัตถุประสงค์ในการวิจัยเท่านั้น" โดยเน้นการตรวจสอบ AI อย่างรับผิดชอบและการกำกับดูแลโดยมนุษย์ — และประโยคนั้นวางตัวไม่เข้ากันกับการอนุญาตแบบ Apache-2.0 ซึ่งไม่ได้จำกัดการใช้ในเชิงพาณิชย์ เพิ่มการพึ่งพา: DCVC-RT และเครื่องมือเตรียมโคเดกมีข้อกำหนดของตนเอง ซึ่งเป็นอิสระจากข้อกำหนดของโมเดล

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

คุณควรต่อยอดจากสิ่งนี้หรือไม่?

การตัดสินใจแบ่งแยกได้อย่างชัดเจนตามเส้นแบ่งเดียว: ว่าปัญหาของคุณเป็นแบบสตรีมหรือแบบคำขอ

หากคุณกำลังทำงานด้านการรับรู้แบบตลอดเวลา — ฟีดกล้อง การถ่ายทอดสด มุมมองของหุ่นยนต์ การประชุมที่ยาวนานหนึ่งชั่วโมง — Mage-VL ถูกชี้มาที่คุณโดยตรง และความคุ้มค่าของการโฮสต์ด้วยตนเองก็เข้าข้างคุณ การคิดราคา API แบบต่อโทเคนจะแปรผันตามจำนวนเฟรม ซึ่งเป็นรูปแบบที่โหดร้ายสำหรับวิดีโอต่อเนื่อง โมเดล 4B บนฮาร์ดแวร์ของคุณเองพร้อมกับเกตที่เงียบอยู่ตลอดในฟุตเทจที่ไม่มีเหตุการณ์สำคัญ คือเส้นต้นทุนที่แตกต่างกันโดยสิ้นเชิง ข้อแม้ก็คือ คุณกำลังสมัครเป็นคนแรกนอก Microsoft ที่จะได้รู้ว่าการตัดสินใจของเกตนั้นดีพอหรือไม่

หากปัญหาของคุณมีลักษณะเป็นคำขอ — ผู้ใช้อัปโหลดเอกสาร ไฟล์ PDF ภาพหน้าจอ หรือคลิปสั้น ๆ แล้วคาดหวังคำตอบ — เหตุผลนี้จึงอ่อนแอกว่ามาก ในงานเหล่านั้น Mage-VL อยู่ในระดับเดียวกันกับโมเดลที่คุณยังต้องโฮสต์ด้วยตัวเอง และ multimodal endpoints แบบโฮสต์ก็อยู่ห่างแค่การเรียก API ครั้งเดียว โดยไม่ต้องมี GPU ไม่ต้อง build ffmpeg และไม่ต้องใช้ trust_remote_code บน OrcaRouter Gemini 3.6 Flashมีราคา $1.50 ต่อล้านโทเคน input และ $7.50 ต่อล้านโทเคน output ซึ่งเป็นราคารายการของผู้ให้บริการที่ส่งผ่านตรงมา — เราคิดมาร์กอัป 0% ดังนั้นเมื่อผู้ให้บริการลดราคา การลดราคาจะมีผลในฝั่งเราทันทีในวันเดียวกัน แทนที่จะต้องรอหลังการทบทวนราคา คีย์เดียวเข้าถึงโมเดลมากกว่า 200 รายการ พร้อม failover อัตโนมัติหากผู้ให้บริการมีประสิทธิภาพลดลง ซึ่งเป็นเหตุผลเชิงปฏิบัติที่จะใช้ endpoint แบบโฮสต์เป็นค่าเริ่มต้น และสำรองการโฮสต์ด้วยตัวเองไว้สำหรับงานที่จำเป็นจริง ๆ เท่านั้น

เพื่อความชัดเจน เนื่องจากความแตกต่างนี้สำคัญ: เราไม่ได้โฮสต์ Mage-VL และก็ไม่มีใครโฮสต์เช่นกัน หน้าตัวแบบของ Hugging Face เองระบุว่าไม่มีผู้ให้บริการอินเฟอเรนซ์รายใดปรับใช้มัน ปัจจุบัน การจะรันมัน คุณต้องรันด้วยตัวเอง

อะไรจะทำให้การอ่านนี้เปลี่ยนไป

สี่สิ่ง เรียงตามลำดับคร่าวๆ ว่ามันจะมีความสำคัญมากน้อยแค่ไหน

การประเมินอย่างอิสระคือสิ่งที่สำคัญที่สุด ตัวเลขทุกตัวข้างต้นเป็นเพียงข้อกล่าวอ้าง และข้อกล่าวอ้างที่จำเป็นต้องทดสอบมากที่สุดไม่ใช่คะแนน benchmark แต่เป็นความเร็วที่เพิ่มขึ้น 3.5 เท่า ซึ่งวัดเทียบกับการสุ่มเฟรมแบบสม่ำเสมอบน NExT-QA โดยไม่มีการเปิดเผยรายละเอียดฮาร์ดแวร์ ความละเอียด หรือจำนวนเฟรม การประมวลผลล่วงหน้าด้วยโคเดกย้ายงานจริงไปยัง CPU และเข้าไปใน ffmpeg; ชัยชนะที่วัดจากเวลาจริง (wall-clock) แบบ end-to-end บนเครื่องของผู้อื่นเป็นเพียงรูปแบบเดียวของตัวเลขนั้นที่ควรนำมาใช้ในการวางแผน

ประการที่สอง การสนับสนุนการให้บริการ การผสานรวมการใช้งาน vLLM หรือ SGLang จะเปลี่ยนสิ่งนี้จากจุดตรวจสอบงานวิจัยให้กลายเป็นสิ่งที่คุณสามารถนำไปวางไว้หลังตัวปรับสมดุลโหลดได้ ส่วน issue ของ SGLang ยังคงเปิดอยู่และยังไม่มีใครรับไปดำเนินการ นั่นคือเธรดที่ต้องจับตามอง

ประการที่สาม การขึ้นทะเบียนใน Azure AI Foundry ซึ่งจะส่งสัญญาณว่า Microsoft ตั้งใจให้สิ่งนี้เป็นผลิตภัณฑ์มากกว่าบทความวิจัย ไม่มีสิ่งใดในการเผยแพร่ครั้งปัจจุบันที่บ่งชี้ว่าสิ่งนั้นใกล้จะเกิดขึ้น

ประการที่สี่ และที่แปลกที่สุดคือ ว่าทาง Microsoft จะออกมาพูดอะไรหรือไม่ รายงานทางเทคนิคที่มีผู้เขียน 23 คน หน้าโปรเจกต์ที่ได้รับการดูแลอย่างต่อเนื่อง Space สาธิตที่โฮสต์ไว้ และโมเดล generative ที่เป็นคู่กันเมื่อสี่วันก่อนหน้านั้น ไม่ได้บ่งบอกถึงการหลุดหรืออุบัติเหตุ — แต่บ่งบอกถึงการตีพิมพ์งานวิจัยโดยเจตนาที่ข้ามการโปรโมตเชิงผลิตภัณฑ์ไปโดยสิ้นเชิง ชุมชนก็เติมเต็มความเงียบนั้นอยู่ดี ด้วยการทำ quantization เก้าชุดและ fine-tune สองชุดภายในสิบวัน

สำหรับทีมส่วนใหญ่ การตัดสินใจที่ถูกต้องคืออ่าน paper มากกว่าที่จะดาวน์โหลด weights มาใช้ สาระสำคัญคือแนวคิดแบบ codec-native และมันนำไปใช้ต่อได้จริง: ถ้าการนำ motion vectors ที่ encoder คำนวณไว้แล้วกลับมาใช้ใหม่ ช่วยลดจำนวน token ได้ถึง 75% โดยที่ความแม่นยำเท่าเดิม เทคนิคแบบนั้นจะถูกนำไปใช้ในโมเดลต่างๆ ที่มาพร้อมกับโพสต์เปิดตัว การสนับสนุนจากผู้ให้บริการ และ benchmark ที่ทำซ้ำได้ หากคุณรัน continuous video ในตอนนี้ หลักคิดจะต่างออกไป — clone repo เอาโค้ดไปรันคลิปของคุณเองผ่าน backend ทั้งสอง แล้ววัดความเร็วที่เพิ่มขึ้นด้วยตัวเอง เพราะตอนนี้คุณจะเป็นคนแรกที่ทำ

คำถามที่ควรค่าแก่การถามจริงๆ

Mage-VL เป็นเพียงแค่ Qwen3-VL ที่ติดป้าย Microsoft หรือเปล่า

ไม่ใช่ แม้ว่าความเข้าใจผิดนั้นจะเข้าใจได้ก็ตาม ตัวถอดรหัสภาษาคือ Qwen3-4B-Instruct-2507 ซึ่งถูกใช้ตามสภาพเดิม — Microsoft ไม่ได้ฝึก LLM ตัวใหม่ ทุกอย่างอื่นเป็นของใหม่หมด: Mage-ViT ถูก pretrain ตั้งแต่เริ่มต้น การทำ tokenization แบบ codec-native ไม่มีสิ่งที่เทียบเท่าใน Qwen3-VL และ streaming gate เป็นโมเดลที่เพิ่มเข้ามาอีก 500 ล้านพารามิเตอร์ การนำ backbone แบบเปิดมาใช้ซ้ำและเปลี่ยนส่วนนำเข้าภาพ (visual front end) เป็นกลยุทธ์การวิจัยที่ถูกต้องและเป็นที่นิยมเพิ่มขึ้นเรื่อย ๆ และที่นี่ก็เป็นสิ่งที่ทำให้การเปรียบเทียบแบบตัวต่อตัวสามารถตีความได้เช่นกัน หากคุณมีข้อกำหนดด้านการปฏิบัติตามข้อกำหนดเกี่ยวกับที่มาของโมเดล โปรดทราบว่าสายเลือดของโมเดลสืบเนื่องมาจากน้ำหนัก Qwen3 ของ Alibaba และตรวจสอบใบอนุญาตทั้งสองฉบับ

'3.5x faster' หมายความว่า มีต้นทุนการให้บริการที่ถูกลง 3.5x หรือ?

ไม่น่าเชื่อถือเต็มร้อย ตัวเลขนี้คือความเร็วแบบวอลล์คล็อก (wall-clock) บน NExT-QA เทียบกับการสุ่มเฟรมแบบสม่ำเสมอ และ Microsoft ระบุไว้ว่า "สูงถึง" (up to) ในทางปฏิบัติมีสองสิ่งที่ทำให้ตัวเลขนี้เจือจางลง ประการแรก การอินเฟอร์เรนซ์แบบโคเดกเนทีฟต้องมีขั้นตอนเตรียมข้อมูล — ffmpeg, ffprobe และขั้นตอน cv-preinfer หรือการรีเอนโคดด้วย DCVC-RT สำหรับเส้นทางนิวรัล — ซึ่งกินเวลา CPU ที่ไปป์ไลน์เฟรมแบบธรรมดาไม่ต้องเสีย และไม่ปรากฏในการวัดผลฝั่ง GPU ประการที่สอง อัตราเร่งที่ได้มาจากการลดจำนวนโทเคน จึงแปรผันตามความซ้ำซ้อนของฟุตเทจของคุณ: กล้องวงจรปิดที่ภาพนิ่งเป็นส่วนใหญ่ควรได้ผลดีกว่าตัวเลขที่กล่าวถึง ส่วนวิดีโอตัดต่อแบบตัดสลับเร็วที่แทบทุกแพตช์เปลี่ยนไปควรได้ผลแย่กว่า ลองวัดผลจากคลิปของคุณเองดู

ฉันจำเป็นต้องมีไฟล์วิดีโอพิเศษเพื่อใช้เส้นทาง codec หรือไม่

ส่วนใหญ่ก็ไม่ใช่ และนี่คือความประหลาดใจที่น่ายินดี ไฟล์ MP4 ทั่วไปนั้นเป็น H.264 หรือ HEVC อยู่แล้ว ซึ่งตรงกับสิ่งที่ backend โคเดกแบบดั้งเดิมใช้ — เวกเตอร์การเคลื่อนไหวที่มันต้องการมีอยู่ในไฟล์ที่คุณมีอยู่แล้ว สิ่งที่คุณต้องเพิ่มคือเครื่องมือ: FFmpeg และ ffprobe ใน PATH ของคุณ พร้อมด้วยแพ็กเกจเตรียมโคเดก backend แบบโครงข่ายประสาทเป็นกรณีพิเศษ; DCVC-RT คาดหวังวิดีโอที่เข้ารหัสด้วยโคเดกนั้น คุณจึงต้องเข้ารหัสใหม่ และ backend แบบเฟรมธรรมดายังคงใช้ได้เป็นตัวสำรองที่ทำงานเหมือน VLM ทั่วไป ซึ่งเป็นวิธีที่ตรงไปตรงมาในการทดสอบ A/B ข้อกล่าวอ้างเรื่องโคเดกด้วยตัวเอง

ฉันใช้มันในเชิงพาณิชย์ได้ไหม

ใบอนุญาตระบุว่าเป็น Apache-2.0 ซึ่งอนุญาตให้ใช้เชิงพาณิชย์ แก้ไข และเผยแพร่ต่อได้ ขณะเดียวกัน repository ก็ระบุว่าโมเดล "เผยแพร่เพื่อวัตถุประสงค์ทางการวิจัยเท่านั้น" ข้อความทั้งสองนี้ชี้ไปคนละทิศทาง และยังไม่มีใครจาก Microsoft ออกมาชี้แจงช่องว่างดังกล่าว — ซึ่งก็ไม่น่าแปลกใจสำหรับการเผยแพร่ที่ไม่มีประกาศ ไม่มีรายการผลิตภัณฑ์ และไม่มีตัวแทนผู้จำหน่ายในเธรดสนทนาของ repository หากเงินขึ้นอยู่กับคำตอบนี้ ควรจ้างทนายความให้อ่านเอกสารทั้งสองฉบับและใบอนุญาตของ dependency ต่างๆ แทนที่จะเชื่อเพียงป้ายใบอนุญาตเพียงอย่างเดียว