مايكروسوفت Mage-VL: نموذج فيديو 4B أصلي الترميز، أُطلق دون إعلان

لا توجد أي تدوينة من مايكروسوفت حول Mage-VL. لا يوجد أي مدخل في غرفة أخبار Azure، ولا أي قائمة في كتالوج Foundry، ولا أي سلسلة إطلاق، ولا شيء على قنوات المنتجات التي تُقدّم فيها مايكروسوفت عادةً نموذجًا. ما يوجد بدلًا من ذلك هو مستودع على Hugging Face — microsoft/Mage-VL، ستة التزامات، أوزان بحجم 10.8 غيغابايت، رخصة Apache-2.0 — ومجلد على GitHub لسكريبتات الاستدلال، وصفحة مشروع يديرها كيان يطلق على نفسه اسم فريق Microsoft Mage، وتقرير من 23 مؤلفًا على arXiv. عند قراءة هذه القطع معًا، تصف نموذجًا لغويًا بصريًا بمقياس 4B فكرته المركزية غير مألوفة حقًا: بدلًا من فك تشفير الفيديو إلى إطارات متساوية المسافات ودفع شبكة كثيفة من الرقع عبر مشفر مدرَّب مسبقًا على الويب، يقرأ Mage-VL التدفق الثنائي المضغوط نفسه، مستخدمًا مشفرًا مبنيًا من الصفر يُدعى Mage-ViT للاحتفاظ فقط بالرقع التي أنفق عليها الترميز وحدات البت. تذكر مايكروسوفت أن هذا يقلّل الرموز البصرية بأكثر من 75% ويحقق تسريعًا في الزمن الفعلي يصل إلى 3.5x، مع مطابقته لـ Qwen3-VL-4B على الصور الثابتة وتفوّقه على نموذج مايكروسوفت الخاص 15B Phi-4-Reasoning-Vision في الفيديو.

تلك الجملة الأخيرة هي الجزء الذي ينبغي التعامل معه بحذر. كل رقم أداء في هذه المقالة يعود أصله إلى ورقة مايكروسوفت البحثية الخاصة بها أو بطاقة النموذج أو صفحة المشروع. بعد عشرة أيام من ظهور الأوزان، لم يقم أي طرف مستقل بإعادة إنتاج أيٍّ منها، ولا تدرج أي لوحة تصنيف تابعة لجهة خارجية النموذج، وكما تنص صفحة Hugging Face بوضوح، فإنه "غير مُتاح عبر أي مزوّد استدلال"، فلا توجد حتى نقطة نهاية مستضافة يمكن لأي شخص اختبارها بشكل عابر. ما يلي يفصل بين ما يثبته المستودع وما تزعمه مايكروسوفت فحسب، لأنه في إصدارٍ دون أي إعلان، هاتان فئتان مختلفتان تمامًا.

ما الذي يوجد فعليًا، بعد مرور عشرة أيام

السطح القابل للتحقق في هذا الإصدار صغير ويستحق تعدادًا دقيقًا.

• الأوزان، بتاريخ 26 يوليو 2026. جزأين من safetensors بحجم 4.97 جيجابايت و4.52 جيجابايت، بالإضافة إلى ملف منفصل بحجم 1.07 جيجابايت باسم streammind_gate.safetensors. يُبلغ قارئ Hugging Face الخاص عن 5 مليارات معلمة بدقة BF16 — 4 مليارات في وحدة فك ترميز اللغة، والباقي موزع بين المشفر البصري وتلك البوابة.

• تقرير فني، قُدّم في 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 — أي نحو 175 كيلوبايت من كود Python مخصص. ويقوم حقل auto_map في config.json بتوجيه ست فئات من فئات Transformers إلى تلك الملفات، وهذا هو سبب حمل المستودع لوسم custom_code.

• رخصتان، لا رخصة واحدة. Mage-VL مرخّص بموجب Apache-2.0؛ بينما يُصدَر مشفّر Mage-ViT المستقل بشكل منفصل بموجب MIT.

• عرض توضيحي يعمل دون الحاجة إلى تثبيته. تدير Microsoft نموذج microsoft/mage-vl-demo كمساحة Hugging Face على ZeroGPU، وتستخدم مساحتان مجتمعيتان النموذج بالفعل.

• زخم مجتمعي مبكر، يتشكل أسرع من اتصالات المورّد الرسمية. 268 إعجابًا، و435,784 عملية تنزيل مسجلة خلال الشهر الماضي، وتسعة تكميمات مجتمعية وضبطين دقيقين في شجرة النموذج. تشمل عدادات التنزيل السحوبات الآلية والمرآتية، لذا تعامل مع الرقم الخام كمؤشر على الاهتمام وليس على النشر.

• شقيق. Mage-Flow، نموذج لتحويل النص إلى صورة وتحرير التعليمات، مبني بنفس الميزانية الثابتة البالغة 4B، أُطلق قبل ذلك بأربعة أيام في 22 يوليو. يقدّم مستودع GitHub نموذج Mage بوصفه «عائلة من النماذج متعددة الوسائط خفيفة الوزن والملائمة للبحث»، وهذا هو أقرب ما يكون إلى بيان تموضع نشره أي شخص.

في مقابل ذلك، فإن قائمة الأشياء التي لا وجود لها هي بنفس القدر من الإفادة. لا توجد أي تدوينة من مايكروسوفت أو بيان صحفي. ولا يوجد أي إدراج في Azure AI Foundry، مما يعني عدم وجود مسار دعم للمؤسسات، ولا SLA، ولا نقطة نهاية مُدارة. لا يقدمها أي موفر استدلال. لا يوجد دعم من vLLM أو SGLang: فقد تم تقديم طلب مجتمعي لإضافة Mage-VL إلى SGLang في 28 يوليو كقضية رقم #32646، وحتى وقت كتابة هذا النص، لا يزال مفتوحًا دون أي طلب سحب مرتبط أو رد من المشرف. ولا يوجد تقييم مستقل من أي نوع — فالنموذج غائب عن لوحات الصدارة المحايدة حيث يُختبر عادةً ادعاء مثل "يتفوق على نموذج 15B في الفيديو".

الفكرة الواحدة: اقرأ الترميز، وليس الإطارات.

تقريبًا كل نموذج رؤية-لغة (VLM) قادر على معالجة الفيديو في الإنتاج يفعل الأمر نفسه. إنه يفك تشفير الفيديو إلى إطارات RGB، ويأخذ عينات منها بشكل منتظم — إطارًا كل ثانية، أو 32 إطارًا عبر المقطع، أو حسب ما تسمح به الميزانية — ويمرر كل إطار تم اختياره عبر محول رؤية (vision transformer) كشبكة كثيفة من الرقع (patches). كل رقعة من كل إطار مأخوذ منه عينة تصبح رموزًا (tokens). جدار الخلفية الثابت يكلف نفس عدد الرموز تمامًا مثل الشخص الذي يمشي أمامه، ويكلفها مرة أخرى في الإطار التالي، والذي يليه.

هذا قدر هائل من العمليات الحسابية المتكررة، وقد حلّت تقنيات ترميز الفيديو الحديثة المشكلة الأساسية منذ عقود. لا يخزّن H.264 وHEVC كل إطار؛ بل يخزّنان إطارات مرجعية (I) كاملة من حين لآخر، ثم يصفان الإطارات الواقعة بينها باستخدام متجهات حركة وفروقات متبقية — "هذه الكتلة انتقلت إلى هنا، وهذا ما تغيّر." الأجزاء المهمة في الفيديو، بحكم طبيعتها تقريبًا، هي الأجزاء التي أنفق عليها المشفّر وحدات البت.

يستغل نموذج Mage-ViT ذلك مباشرةً. من خلال العمل على مستوى أجزاء بحجم 16×16، فإنه يحتفظ بكل جزء من الإطارات المرجعية، وبالنسبة للإطارات المتوقعة، يُبقي فقط الأجزاء التي يميزها برنامج الترميز نفسه كأجزاء بارزة عبر متجهات الحركة وطاقة المتبقي — أي المناطق التي تحمل معلومات فعلية أو حركة أو تغييرًا في المشهد — بينما يتجاهل الأجزاء منخفضة التكرار والأجزاء المكررة تمامًا. تقدّر مايكروسوفت التخفيض الناتج بأكثر من 75% من الرموز البصرية، مع الحفاظ على السياق المكاني-الزماني لأن الإطارات المرجعية لا تزال تحمل المشهد الكامل. والتصميم مستقل عن نوع برنامج الترميز: فالمسار التقليدي يقبل H.264 أو HEVC، بينما يقبل المسار العصبي DCVC-RT.

الأناقة تكمن في أن تقدير الحركة كان قد تم بالفعل. كل فيديو مضغوط على الإنترنت يصل مع خريطة لمكان الحركة، محسوبة بواسطة المشفّر ومدفوعة ممن رفعه. خط أنابيب تقليدي يتخلص من تلك الخريطة لحظة فك الترميز إلى RGB، ثم ينفق وقت وحدة معالجة الرسومات في إعادة اكتشاف نفس المعلومات. Mage-VL ببساطة يرفض التخلص منها. سواء ثبتت أرقام المعايير أم لا، فإن تلك الملاحظة هي المساهمة الدائمة هنا — وهي السبب في أن هذا الإصدار يستحق القراءة حتى لو لم تقم بتنزيل الأوزان.

أنقى ما في التجربة

مدفون في الإعداد قرار تصميمي يجعل النتائج أكثر قابلية للتفسير بكثير من إطلاق نموذج نموذجي، ولا أحد تقريبًا ممّن غطّى هذا الإصدار أشار إليه: نموذج اللغة يبقى ثابتًا.

وحدة فك الترميز في Mage-VL هي Qwen3-4B-Instruct-2507 دون أي تعديل. يستخدم خط الأساس المقارن، Qwen3-VL-4B، نفس نواة Qwen3 بحجم 4B مع مشفر بصري تقليدي مُدرَّب على الويب. لذا عندما يحسّن Mage-VL من Qwen3-VL-4B، فإن الفرق يُعزى إلى المشفر والترميز الأصلي القائم على codec، وليس إلى نموذج لغوي أكبر أو أفضل تدريبًا. هذه تجربة إزالة مضبوطة (ablation) مقنّعة كمقارنة منتجات، وهي أقوى ميزة منهجية في هذا الإصدار.

وينطبق ذلك في الاتجاه المعاكس أيضًا، والصدق يقتضي قول ذلك. المقارنة على نفس البنية الأساسية هي الاختبار الأكثر إنصافًا لفكرة المُرمِّز، وهي في الوقت نفسه الصياغة الأكثر إطراءً لها — إذ اختارت Microsoft خط الأساس الذي يعزل مساهمتها الخاصة. أما مقارنات Phi-4 فلا تتمتع بتلك الخاصية: فـ Phi-4-Reasoning-Vision-15B وPhi-4-MM-5.6B يعتمدان بنى أساسية مختلفة، ووصفات تدريب مختلفة، وأساليب ما بعد تدريب مختلفة. «التفوق على نموذجنا ذي 15B في الفيديو» نتيجة حقيقية لكنها أقل إحكامًا بكثير، وهي أيضًا مقارنة مع أعمال Microsoft القديمة الخاصة بها، وهو النوع الأسهل كسبًا.

حجم التدريب هو الموضع الآخر الذي تطرح فيه الورقة ادعاءً مفاجئًا حقًا. تم تدريب Mage-ViT مسبقًا من الصفر على ما يقارب 560 مليون صورة غير موسومة و100 مليون إطار فيديو غير موسوم — وهو نص ضخم بالقيم المطلقة، لكنه أقل بكثير من مليارات أزواج الصور والنصوص المنظمة التي تعتمد عليها المشفّرات التي ينافسها. النتيجة الأولى المذكورة في الورقة هي أن مشفّر VLM القوي لا يتطلب بيانات خاضعة للإشراف على نطاق الويب. إذا ثبت هذا الأمر تحت التدقيق المستقل، فإنه يهم أكثر بكثير من أي صفٍّ في جدول معايير التقييم.

الأرقام، ولمن هي أرقام

ما يلي هو ما أبلغت عنه مايكروسوفت بالكامل، على منصة التقييم الخاصة بمايكروسوفت، مقابل خطوط أساس اختارتها مايكروسوفت. لم يتم تكرار أي شيء هنا من قبل طرف ثالث. اقرأه باعتباره فرضية ذات أشرطة خطأ محددة بشكل غير معتاد، وليس كلوحة نتائج.

• 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 مقابل 57.7 مقابل 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 مقابل 94.69 مقابل 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81.80 مقابل 81.60 مقابل 81.70

• ChartQA — 84.88 مقابل 83.96 مقابل 83.40

• MMStar — 67.32 مقابل 62.04 مقابل 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 (streaming) — 64.00 إجماليًا، وُصف بأنه الأحدث بين البنيات المتدفقة؛ مجموعة الإدراك البصري في الزمن الحقيقي يبلغ متوسطها 79.84% مقابل 72.8% لـ Qwen3-VL-4B، بمعدل 1 إطار في الثانية

• Mage-ViT كمشفر مستقل — يتجاوز 86.3% على ImageNet بميزانية 676 توكنًا، ويتجاوز 96.1% على Food-101

ثلاث قراءات لتلك الطاولة تساوي أكثر من الطاولة نفسها.

في الصور، "التكافؤ" هو الكلمة الصادقة.DocVQA بفارق 0.45، وOCRBench بفارق 0.20، وChartQA بفارق 0.92، وMMBench بفارق 0.77 — هذه ضمن النطاق الذي قد يؤدي فيه قالب مطالبة مختلف أو بذرة فك ترميز مختلفة إلى عكس الترتيب، وRealWorldQA يذهب فعليًا إلى Qwen3-VL-4B. تقول Microsoft ذلك صراحةً، إذ تصف أداء الصور بأنه تكافؤ وليس تفوقًا، وهذا الوصف صحيح. إذا كان عبء عملك هو الإجابة عن الأسئلة المتعلقة بالمستندات والصور، فإن هذا الإصدار لا يمنحك أي سبب للانتقال.

فيما يتعلق بالفيديو والتأطير الزمني، فإن الفجوات كبيرة ومتسقة. يقارب Timelens-QVHighlight ضعف خط الأساس؛ وتتحرك كل من Video-MME وNExT-QA وLongVideoBench بمقدار 3.6 إلى 4.3 نقطة في الاتجاه نفسه مع تثبيت الشبكة الأساسية. الاتساق عبر معايير تختبر جوانب مختلفة هو النمط الذي تتوقعه إذا كان تغيير المشفر حقيقيًا وليس مجرد أثر لضبط المعلمات.

لا ينبغي اقتباس صفّين دون سياق. Ref-DAVIS17 عند 25.83 مقابل 7.48 تبدو وكأنها سحق بنسبة 3.5x، وتشمل الفوارق المكانية الرئيسية في الورقة +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 جيجابايت.

يقسم Mage-VL البث إلى عمليتين، مؤطرًا في الورقة على أنهما النظام 1 والنظام 2. النظام 1 هو "بوابة إدراك" خفيفة الوزن تراقب كل نافذة منزلقة من ميزات الترميز وتقدّر احتمال أن شيئًا يستحق الحديث عنه قد انتهى للتو. تحت حد معين، تظل صامتة ولا يعمل الجزء المكلف من النموذج أبدًا. فوقه، يتم استدعاء وحدة فك الترميز الكاملة لإنتاج استجابة. يستخدم الإعداد التجريبي نوافذ سببية مدتها 30 ثانية بمعدل 1 إطار في الثانية، وتكشف الواجهة السطرية الحد مباشرة كـ --gate_threshold، وتعالج نقطة دخول البث الفيديو مقطعًا بمقطع (inference_streaming.py --video_backend codec --segment_sec 8). يتم تدريب البوابة فقط في المرحلة النهائية، على 3.35 مليون عينة بث.

هناك أمران جديران بالملاحظة في ذلك. أولًا، البوابة ليست رأس تصنيف صغيرًا مُثبّتًا في الأعلى: فحوالي 1.07 جيجابايت من أوزان BF16 تعادل تقريبًا نصف مليار معامل، أي نموذج حقيقي بحد ذاته، يُشحن كنقطة تفتيش منفصلة. ثانيًا، اسم الملف هو streammind_gate.safetensors — ويوحي هذا الاسم بأن هذا المكوّن ينحدر من أعمال سابقة في الإدراك المتدفق بدلًا من أن يكون مبتكرًا لهذه الورقة البحثية، رغم أن المستودع نفسه لا يوضح هذا النسب.

لماذا يهم ذلك تجاريًا: بالنسبة للفيديو الذي يعمل باستمرار، فإن التكلفة المهيمنة ليست زمن الاستجابة لكل مكالمة، بل تكرار المكالمات. بث كاميرا يعمل على مدار الساعة عبر VLM تقليدي بمعدل إطار واحد في الثانية يعني 86,400 تمريرة أمامية يوميًا سواء حدث شيء أم لا. البوابة التي تبقى هادئة خلال 99% من اللقطات التي لا يحدث فيها شيء تغيّر شكل تلك الفاتورة، وليس حجمها فقط. ما إذا كانت بوابة Microsoft دقيقة بما يكفي للوثوق بها في هذا القرار هو بالضبط الشيء الذي لم يختبره أحد خارج المختبر.

هل يمكنك فعلاً تشغيله اليوم؟

نعم، إذا كان لديك وحدة معالجة رسومية (GPU) وصبر. الاحتكاك حقيقي ويتركز في الغالب في خط أنابيب الفيديو وليس في النموذج.

الذاكرة.لا تنشر مايكروسوفت متطلبًا لسعة VRAM. من مؤشر الأوزان: 9.49 جيجابايت من الأجزاء بالإضافة إلى 1.07 جيجابايت للبوابة يبلغ حوالي 10.6 جيجابايت من معاملات BF16، لذا فإن بطاقة بسعة 16 جيجابايت هي الحد الأدنى الواقعي لأعمال الصور، و24 جيجابايت أو أكثر هو الهدف المعقول بمجرد إضافة ذاكرة التخزين المؤقت KV لفيديو طويل أو نافذة بث. هذا حساب من أحجام الملفات، وليس مواصفة من البائع — قم بالقياس قبل التجهيز.

الكود المخصص إلزامي. تشير auto_map إلى أن كل نقطة دخول في Transformers موجهة إلى وحدات المستودع نفسها، لذا فإن trust_remote_code مطلوب. أنت تنفّذ Python من Microsoft، وليس مجرد تحميل الموترات. لا يوجد مسار vLLM أو SGLang بعد، مما يعني عدم وجود انتباه مبوَّب، ولا تجميع مستمر، ولا حزمة تقديم إنتاجية — وهي فجوة كبيرة إذا كنت تأمل في وضع هذا خلف نقطة نهاية.

مسار الترميز يتطلب أدوات نظام.يجب أن يكون FFmpeg و ffprobe في PATH. تعتمد الواجهة الخلفية التقليدية للترميز على حزمة codec-video-prep التي توفر خطوة cv-preinfer؛ المسار العصبي يحتاج DCVC-RT؛ الواجهة الخلفية للإطارات العادية تحتاج Decord. كما تتضمن المتطلبات flash-attn و mamba-ssm، اللذين يقومان بتجميع امتدادات CUDA — ثبّت نسخة PyTorch المطابقة لأدواتك أولاً أو خصص فترة ما بعد الظهر للتجميع.

ما يخبرك به الإعداد أن البطاقة لا تفعله. الحد الأقصى لتضمينات المواضع هو 262,144، لذا يرث مفكك الترميز السياق الطويل من Qwen3-4B. يعمل الجانب البصري بمدخلات 448 بكسل مع رقع 16×16، ومشفّر من 24 طبقة و1024 وحدة مخفية، ودمج مكاني 2×2، وتوكن واحد لكل ثانية من الفيديو ونافذة من أربعة إطارات. وصل التدريب إلى 384 إطارًا من الطول الزمني في المرحلة الثالثة. إن سقف 262 ألفًا ليس هو نفسه 262 ألفًا من السلوك المُتحقَّق منه، و384 إطارًا هو الطول الذي عُلِّم النموذج فعليًا التعامل معه.

حواف خشنة معروفة. نقاش مفتوح على المستودع، أُدرج في 4 أغسطس وما زال دون رد، يبلّغ عن اختلال في التوكنات عند تمرير الصور ومقاطع الفيديو في نفس الطلب. البرمجيات التي عمرها عشرة أيام تتصرف كبرمجيات عمرها عشرة أيام. إذا أردت نظرة سريعة دون أيٍّ من هذا، فإن Space المُدار من Microsoft على ZeroGPU هو الخيار الذي لا يتطلب أي تثبيت.

سطر الترخيص أقل بساطة من "Apache-2.0"

تنصّ بطاقة النموذج على Apache-2.0، بينما يشير مشفّر Mage-ViT إلى MIT. وكلاهما من أكثر تراخيص الأوزان المفتوحة سماحيةً. غير أنّ مستودع العائلة يذكر أنّ «هذه النماذج أُصدرت لأغراض البحث فقط»، مع التشديد على مراجعة الذكاء الاصطناعي المسؤول والإشراف البشري — وهذه الجملة لا تنسجم بسهولة مع ترخيص Apache-2.0 الذي لا يقيّد الاستخدام التجاري. أضف إلى ذلك التبعيات؛ إذ تحمل DCVC-RT وأدوات تهيئة الكوديك شروطها الخاصة، المستقلة عن شروط النموذج.

بالنسبة لمشروع هواية، هذا مجرد ضجيج. أما بالنسبة لأي شيء يُشحن للعملاء، فهو نوع من الغموض الذي يجب أن يُعرض على المستشار القانوني قبل أن يصل إلى مرحلة الإنتاج، وهو أيضًا سؤالٌ يستحق طرحه على المستودع نفسه — حيث، بشكل ملحوظ، لا يوجد حاليًا أي ممثل من Microsoft يجيب عليه.

هل ينبغي أن تبني على هذا؟

ينقسم القرار بوضوح على خط واحد: هل مشكلتك عبارة عن تدفق أم طلب؟

إذا كنت تقوم بإدراك دائم التشغيل — بث كاميرا، بث مباشر، مجال رؤية روبوت، اجتماع يستمر ساعة — فإن Mage-VL موجه إليك تحديدًا، والاقتصاديات الخاصة بالاستضافة الذاتية في صفك. تسعير كل توكن في واجهة البرمجة يعتمد على الإطارات، وهو نموذج قاسٍ للفيديو المستمر؛ نموذج 4B على أجهزتك الخاصة مع بوابة تظل صامتة خلال اللقطات غير المهمة هو منحنى تكلفة مختلف جوهريًا. لكن الجانب السلبي هو أنك أيضًا تسجّل لتكون أول شخص خارج Microsoft يكتشف ما إذا كانت أحكام البوابة جيدة أم لا.

إذا كانت مشكلتك على شكل طلب — حيث يرفع المستخدم مستندًا أو PDF أو لقطة شاشة أو مقطعًا قصيرًا ويتوقع إجابة — فإن الحالة أضعف بكثير. في هذه المهام تحديدًا، يكون Mage-VL على قدم المساواة مع نموذج لا يزال يتعين عليك استضافته بنفسك، كما أن نقاط نهاية الوسائط المتعددة المستضافة ليست سوى مكالمة API واحدة، دون الحاجة إلى GPU أو بناء ffmpeg أو trust_remote_code. على OrcaRouter، Gemini 3.6 Flashتبلغ تكلفته 1.50 دولارًا لكل مليون رمز إدخال و7.50 دولارًا لكل مليون رمز إخراج، وهو سعر القائمة لدى المزود يُمرَّر مباشرة — لا نأخذ أي هامش ربح، لذا عندما يخفض البائع الأسعار، يصبح التخفيض ساريًا في نفس اليوم من جهتنا بدلًا من بعد مراجعة الأسعار. مفتاح واحد يصل إلى أكثر من 200 نموذج مع تجاوز تلقائي للفشل إذا تدهور أداء المزود، وهو السبب العملي للاحتفاظ بنقطة نهاية مستضافة كخيار افتراضي والاحتفاظ بالاستضافة الذاتية لأحمال العمل التي تحتاجها فعلًا.

لنكون صريحين، لأن التمييز مهم: نحن لا نستضيف Mage-VL، ولا يستضيفه أي شخص آخر. صفحة النموذج الخاصة بـ Hugging Face نفسها تقول إنه لا يوجد مزود استدلال نشره. اليوم، تشغيله يعني تشغيله بنفسك.

ما الذي قد يغير هذه القراءة؟

أربعة أشياء، بترتيب تقريبي حسب مدى أهميتها.

التقييم المستقل هو الأمر الكبير. كل رقم أعلاه هو ادعاء، والادعاء الأكثر حاجة للاختبار ليس درجة قياسية بل تسريع 3.5x، الذي قيس مقابل أخذ عينات إطارات موحّد على NExT-QA دون نشر تفاصيل عن العتاد أو الدقة أو عدد الإطارات. المعالجة المسبقة بالكوديك تنقل العمل الفعلي إلى المعالج وإلى ffmpeg؛ الفوز بزمن الحائط المُقاس من البداية إلى النهاية على جهاز شخص آخر هو النسخة الوحيدة من هذا الرقم التي تستحق التخطيط على أساسها.

ثانيًا، دعم التشغيل. إن دمج تنفيذ vLLM أو SGLang سيحوّل هذا من نقطة تفتيش بحثية إلى شيء يمكنك وضعه خلف موازن تحميل. قضية SGLang مفتوحة وغير مُطالَب بها؛ هذا هو الخيط الذي يجب متابعته.

ثالثًا، إدراج في Azure AI Foundry، مما قد يشير إلى أن Microsoft تعتزم اعتبار هذا منتجًا لا ورقة بحثية. لا شيء في الإصدار الحالي يوحي بأن ذلك وشيك.

رابعًا، والأكثر غرابة: ما إذا كانت مايكروسوفت ستقول أي شيء على الإطلاق. تقرير فني من 23 مؤلفًا، وصفحة مشروع مُحدَّثة، ومساحة Space مستضافة للعرض التجريبي، ونموذج توليدي شقيق قبل أربعة أيام — لا تصف تسريبًا أو حادثًا، بل تصف نشرًا بحثيًا متعمدًا تجاوز المكبر الصوتي للمنتج تمامًا. ومع ذلك، ملأ المجتمع هذا الصمت، بتسعة إصدارات مكمّمة ونموذجين مضبوطين بدقة خلال عشرة أيام.

بالنسبة لمعظم الفرق، القرار الصحيح هو قراءة الورقة البحثية بدلاً من تنزيل الأوزان. الفكرة الجوهرية هي الميزة الأصلية لبرنامج الترميز، وهي قابلة للنقل: إذا كانت إعادة استخدام متجهات الحركة التي حسبها المشفر بالفعل تحقق تخفيضًا بنسبة 75% في الرموز المميزة مع دقة مكافئة، فستظهر هذه التقنية في نماذج مصحوبة بمنشورات إطلاق ودعم من المزودين ومعايير مُعاد إنتاجها. أما إذا كنت تشغّل فيديو مستمر اليوم، فالمعادلة مختلفة — استنسخ المستودع، وشغّل مقاطعك الخاصة عبر كلتا الواجهتين الخلفيتين، وقِس تحسين السرعة بنفسك، لأنك في الوقت الحالي ستكون الأول.

أسئلة تستحق أن تُطرح فعلًا

هل Mage-VL مجرد Qwen3-VL مع علامة Microsoft عليه؟

لا، رغم أن الالتباس مفهوم. وحدة فك ترميز اللغة هي Qwen3-4B-Instruct-2507، وتُستخدم كما هي — لم تدرّب Microsoft نموذج لغوي كبير جديدًا. كل ما عدا ذلك جديد: تم تدريب Mage-ViT مسبقًا من الصفر، وترميز الرموز الأصلي للترميز الصوتي (codec-native tokenization) ليس له مقابل في Qwen3-VL، وبوابة البث (streaming gate) هي نموذج إضافي بنصف مليار معامل. إعادة استخدام عمود فقري مفتوح واستبدال الواجهة البصرية الأمامية هو استراتيجية بحثية مشروعة وشائعة بشكل متزايد، وهو هنا أيضًا ما يجعل المقارنة المباشرة (head-to-head) قابلة للتفسير. إذا كانت لديك متطلبات امتثال تتعلق بمصدر النموذج، فلاحظ أن السلالة تمتد عبر أوزان Qwen3 من Alibaba، وتحقق من الترخيصين.

هل يعني "أسرع 3.5 مرات" أن تقديم الخدمة أقل تكلفة بمقدار 3.5 مرات؟

ليس بشكلٍ موثوق. الرقم يمثّل تسريعًا في الزمن الفعلي (wall-clock) على NExT-QA مقارنةً بأخذ عينات الإطارات بشكل موحّد، وتقدّمه Microsoft على أنه «يصل إلى». أمران يُضعفان ذلك في الممارسة العملية: الاستدلال الأصيل في الترميز (Codec-native) يتطلب تمريرة تحضير — ffmpeg وffprobe وخطوة cv-preinfer، أو إعادة ترميز DCVC-RT للمسار العصبي — وهو ما يستهلك وقت CPU لا يستهلكه خط معالجة الإطارات البسيط، ولا يظهر هذا الوقت في قياسات جانب GPU. كما أن الكسب يأتي من تقليل عدد الرموز (tokens)، لذا فهو يتناسب مع درجة تكرار الفيديو لديك: كاميرا مراقبة شبه ثابتة ينبغي أن تحقق نتيجة أفضل من الرقم المذكور، بينما الفيديو المحرّر بقصّات سريعة حيث تتغير كل رقعة تقريبًا ينبغي أن تكون نتيجته أسوأ. اختبر ذلك على مقاطعك الخاصة.

هل أحتاج إلى ملفات فيديو خاصة لاستخدام مسار الترميز؟

في الغالب لا، وهذه هي المفاجأة السارة. ملفات MP4 العادية هي بالفعل H.264 أو HEVC، وهو بالضبط ما يستهلكه المحرك التقليدي للترميز — متجهات الحركة التي يحتاجها موجودة في الملف الذي تملكه بالفعل. ما تحتاج إلى إضافته هو الأدوات: FFmpeg و ffprobe في PATH، بالإضافة إلى حزمة تجهيز الترميز. المحرك العصبي هو الاستثناء؛ DCVC-RT يتوقع فيديو مشفّرًا بهذا الترميز، لذا ستضطر إلى إعادة الترميز. ومحرك الإطارات العادي يظل متاحًا كخيار احتياطي يتصرف مثل أي VLM آخر، وهي أيضًا الطريقة الصادقة لاختبار ادعاء الترميز بنفسك.

هل يمكنني استخدامه تجاريًا؟

الترخيص ينص على أنه Apache-2.0، وهو ما يسمح بالاستخدام التجاري والتعديل وإعادة التوزيع. كما يذكر المستودع أن النماذج "مُطلقة لأغراض البحث فقط". هذان التصريحان يشيران في اتجاهين مختلفين، ولم يتم توضيح هذه الفجوة من قِبل أي شخص في مايكروسوفت — وهو أمر غير مستغرب في إصدارٍ لا يتضمن أي إعلان، ولا قائمة منتجات، ولا وجودًا للبائع في مناقشات المستودع. إذا كان المال يعتمد على الإجابة، فاستشر محاميًا لقراءة الوثيقتين معًا وتراخيص الاعتماديات بدلًا من الثقة بشارة الترخيص وحدها.