מיקרוסופט 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% ומספק האצה של עד פי 3.5 בזמן שעון, תוך התאמה ל-Qwen3-VL-4B בתמונות סטטיות והבסת המודל של Microsoft עצמה, Phi-4-Reasoning-Vision בגודל 15B, בווידאו.

את המשפט האחרון יש להחזיק במרחק זרוע. כל נתון ביצועים במאמר זה מקורו במסמך, בגיליון המודל או בעמוד הפרויקט של מיקרוסופט עצמה. עשרה ימים לאחר שהמשקולות פורסמו, אף גורם עצמאי לא שחזר אף אחד מהם, אף לוח תוצאות של צד שלישי לא כולל את המודל, ו—כפי שדף Hugging Face מציין במפורש—הוא "אינו פרוס על ידי ספק אינפרנס", כך שאין אפילו נקודת קצה מתארחת שמישהו יכול היה להריץ עליה בנצ'מרקים כלאחר יד. המשך הדברים מבדיל בין מה שהמאגר מוכיח לבין מה שמיקרוסופט רק טוענת, כי בהשקה ללא הודעה רשמית אלה קטגוריות שונות מאוד.

מה שבאמת קיים, אחרי עשרה ימים

השטח הניתן לאימות של מהדורה זו קטן, וכדאי למנות אותו במדויק.

• משקלים, מתאריך 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: מודל יסוד מולטי-מודאלי סטרימינג יעיל עם תמיכה מקורית בקודק."

• קוד בר-הרצה, לא רק משקלים.המאגר כולל את 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/mage-vl-demo כ-Hugging Face Space על ZeroGPU, ושתי Spaces קהילתיות כבר משתמשות במודל.

• משיכה קהילתית מוקדמת, שמתגבשת מהר יותר מהתקשורת של הספק עצמו. 268 לייקים, 435,784 הורדות נרשמו בחודש האחרון, תשע קוונטיזציות קהילתיות ושני פיין-טיונים בעץ המודל. מוני ההורדות כוללים משיכות אוטומטיות ומשיכות מראה, אז התייחסו למספר הגולמי כאות לתשומת לב ולא לפריסה בפועל.

• אח.Mage-Flow, מודל טקסט-לתמונה ועריכת הוראות שנבנה עם אותו תקציב קבוע של 4B, הושק ארבעה ימים קודם לכן, ב-22 ביולי. הריפו של GitHub מציג את Mage כ"משפחה של מודלים מולטי-מודאליים קלים וידידותיים למחקר", וזה הדבר הקרוב ביותר להצהרת מיצוב שמישהו פרסם.

לעומת זאת, רשימת הדברים שאינם קיימים היא אינפורמטיבית לא פחות. אין פוסט בבלוג של מיקרוסופט ואין הודעה לעיתונות. אין רישום ב-Azure AI Foundry, מה שאומר שאין מסלול תמיכה ארגוני, אין SLA, ואין נקודת קצה מנוהלת. אף ספק הסקה לא מציע אותו. אין תמיכה ב-vLLM או ב-SGLang: בקשה קהילתית להוסיף את Mage-VL ל-SGLang הוגשה ב-28 ביולי כ-issue #32646, ונכון לכתיבת שורות אלה היא נותרה פתוחה ללא pull request מקושר וללא תגובה של מתחזק. ואין הערכה בלתי תלויה מכל סוג שהוא — המודל נעדר מלוחות התוצאות הנייטרליים שבהם טענה כמו „מנצח מודל 15B על וידאו" הייתה נבחנת בדרך כלל.

הרעיון האחד: קרא את הקודק, לא את הפריימים.

כמעט כל VLM בעל יכולת וידאו שפועל בסביבת ייצור עושה את אותו הדבר. הוא מפענח את הווידאו לפריימים ב-RGB, דוגם אותם באופן אחיד — פריים אחד בכל שנייה, או 32 פריימים על פני הקליפ, או כמה שתקציב הזיכרון מאפשר — ומעביר כל פריים שנדגם דרך vision transformer כרשת צפופה של פאצ'ים. כל פאץ' של כל פריים שנדגם הופך לטוקנים. קיר רקע סטטי עולה בדיוק אותו מספר טוקנים כמו האדם שהולך לפניו, והוא עולה שוב בפריים הבא, ובזה שאחריו.

זו כמות עצומה של חישוב מיותר, ומקודדי וידאו מודרניים כבר פתרו את הבעיה הבסיסית לפני עשרות שנים. H.264 ו-HEVC אינם מאחסנים כל פריים; הם מאחסנים פריימי עוגן (I) מזדמנים במלואם ואז מתארים את הפריימים שביניהם כווקטורי תנועה בתוספת שאריות — "הבלוק הזה זז לכאן, והנה מה שהשתנה." החלקים המעניינים של וידאו הם, כמעט מעצם הגדרתם, החלקים שהמקודד השקיע בהם סיביות.

Mage-ViT מנצלת זאת ישירות. פועלת ברזולוציית פאצ'ים של 16x16, היא שומרת על כל פאץ' מפריימי העוגן, ובפריימים החזויים היא שומרת רק על פאצ'ים שסומנו כבולטים על ידי וקטורי התנועה ואנרגיית השארית של ה-codec עצמו — האזורים הנושאים מידע אמיתי, תנועה או שינוי סצנה — תוך השלכת אלה בעלי היתירות הנמוכה ואלה המיותרים לחלוטין. מיקרוסופט מעריכה את ההפחתה הנובעת ביותר מ-75% מהטוקנים החזותיים, כשההקשר המרחבי-זמני נשמר מכיוון שפריימי העוגן עדיין נושאים את הסצנה המלאה. העיצוב הוא אגנוסטי ל-codec: המסלול המסורתי מקבל H.264 או HEVC, ומסלול עצבי מקבל DCVC-RT.

האלגנטיות היא שבדיקת התנועה כבר בוצעה. כל וידאו דחוס באינטרנט מגיע עם מפה של היכן הפעולה מתרחשת, שחושבה על ידי המקודד ושולמה על ידי מי שהעלה אותו. צינור עיבוד קונבנציונלי זורק את המפה הזאת ברגע שהוא מפענח ל-RGB, ואז מבזבז זמן GPU על גילוי מחדש של אותו מידע. Mage-VL פשוט מסרב להשליך אותה. בין אם מספרי ה-benchmark מחזיקים מעמד ובין אם לא, התצפית הזאת היא התרומה המתמשכת כאן — וזו הסיבה שהמהדורה הזאת שווה קריאה גם אם לעולם לא תורידו את המשקלים.

הדבר הנקי ביותר בנוגע לניסוי

בתוך התצורה קבורה החלטה עיצובית שהופכת את התוצאות לניתנות לפרשנות הרבה יותר מאשר השקת מודל טיפוסית, וכמעט אף אחד מהמסקרים את השחרור הזה לא הצביע על כך: מודל השפה נשמר קבוע.

המפענח (decoder) של Mage-VL הוא Qwen3-4B-Instruct-2507, ללא שינוי. קו הבסיס להשוואה, Qwen3-VL-4B, משתמש באותו שלד (backbone) של Qwen3 בגודל 4B עם מקודד חזותי קונבנציונלי שאומן מראש על נתוני אינטרנט. לכן, כאשר Mage-VL משפרת את הביצועים לעומת Qwen3-VL-4B, ההפרש (delta) ניתן לייחוס למקודד ולטוקניזציה המקורית-לקודק (codec-native), ולא למודל שפה גדול או מאומן יותר. מדובר באבלציה מבוקרת (controlled ablation) המוצגת כהשוואת מוצרים, וזהו המאפיין המתודולוגי החזק ביותר של המהדורה.

זה גם פועל בכיוון ההפוך, והכנות מחייבת לומר זאת. השוואה על אותו backbone היא המבחן ההוגן ביותר לרעיון ה-encoder, ובמקביל המסגור שסביר ביותר שיחמיא לו — מיקרוסופט בחרה בקו הבסיס שמבודד את התרומה שלה עצמה. להשוואות Phi-4 אין תכונה זו: Phi-4-Reasoning-Vision-15B ו-Phi-4-MM-5.6B הם backbones שונים, מתכוני אימון שונים, פוסט-אימון שונה. "מנצח את מודל ה-15B שלנו בוידאו" הוא תוצאה אמיתית אבל הרבה יותר רופפת, וזו גם השוואה מול העבודה הישנה יותר של מיקרוסופט עצמה — וזה הסוג הקל ביותר לנצח בו.

קנה המידה של האימון הוא המקום הנוסף שבו המאמר טוען טענה מפתיעה באמת. 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 vs 34.9 vs 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 (סטרימינג) — 64.00 בסך הכל, מתואר כמתקדם ביותר מבין ארכיטקטורות הסטרימינג; תת-קבוצת התפיסה החזותית בזמן אמת משיגה ממוצע של 79.84% לעומת 72.8% עבור Qwen3-VL-4B, ב-1 fps

• Mage-ViT כמקודד עצמאי — מעל 86.3% ב-ImageNet בתקציב של 676 טוקנים, ומעל 96.1% ב-Food-101

שלוש קריאות של הטבלה הזו שוות יותר מהטבלה עצמה.

בתמונות, "שוויון" היא המילה הכנה. DocVQA ב-0.45, OCRBench ב-0.20, ChartQA ב-0.92, MMBench ב-0.77 — אלה נמצאים בטווח שבו תבנית פרומפט אחרת או seed פענוח שונה יכולים להפוך את סדר הדירוג, ולמעשה RealWorldQA הולך ל-Qwen3-VL-4B. מיקרוסופט אומרת זאת בעצמה, וממסגרת את ביצועי התמונה כשוויון ולא כניצחון — ומסגרת זו נכונה. אם עומס העבודה שלך הוא מענה על שאלות במסמכים ובתמונות, המהדורה הזו לא נותנת לך שום סיבה לעבור.

בנוגע לוידאו ולעיגון זמני, הפערים גדולים ועקביים.Timelens-QVHighlight כמעט מכפיל את קו הבסיס; Video-MME, NExT-QA ו-LongVideoBench זזים כולם ב-3.6 עד 4.3 נקודות בכיוון זהה, כשהשלד נותר קבוע. עקביות על פני מדדים שבוחנים דברים שונים היא התבנית שהיית מצפה לה אם השינוי במקודד הוא אמיתי, ולא תוצר לוואי של כוונון.

אין לצטט שתי שורות ללא הקשר. 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 מפצל את הסטרימינג לשני תהליכים, המוצגים במאמר כמערכת 1 ומערכת 2. מערכת 1 היא "שער קוגניציה" קל משקל, אשר צופה בכל חלון זז של מאפייני codec ומעריך את ההסתברות שמשהו שכדאי לדבר עליו בדיוק הסתיים. מתחת לסף, הוא נשאר שקט והחלק היקר של המודל לעולם אינו מופעל. מעל לסף, מופעל המפענח המלא כדי להפיק תגובה. תצורת ההדגמה משתמשת בחלונות סיבתיים של 30 שניות בקצב של 1 fps, ה-CLI חושף את הסף ישירות כ---gate_threshold, ונקודת הכניסה לסטרימינג מעבדת את הווידאו מקטע לקטע (inference_streaming.py --video_backend codec --segment_sec 8). בשלב הסופי, רק השער מאומן על 3.35 מיליון דגימות סטרימינג.

שני דברים בנושא זה ראויים לציון. ראשית, ה-gate אינו ראש סיווג קטן שהוצמד על גבי המודל: 1.07 GB של משקלי BF16 הם בערך חצי מיליארד פרמטרים, מודל אמיתי בפני עצמו, שמופץ כ-checkpoint נפרד. שנית, שם הקובץ הוא streammind_gate.safetensors — השם מרמז שרכיב זה נובע מעבודות streaming-perception קודמות ולא הומצא למאמר זה, אם כי ה-repo עצמו אינו מבהיר את השושלת הזו.

למה זה חשוב מבחינה מסחרית: עבור וידאו פעיל תמידית, העלות הדומיננטית היא לא השהייה לכל קריאה, אלא תדירות הקריאות. הזנת מצלמה הפועלת 24/7 דרך VLM קונבנציונלי בקצב של 1 fps משמעותה 86,400 מעברי חישוב ביום, בין אם קרה משהו ובין אם לא. שער שנשאר שקט במהלך 99% מהצילומים שבהם לא קורה כלום משנה את הצורה של החשבון הזה, לא רק את גודלו. האם השער של מיקרוסופט מדויק מספיק כדי להפקיד בידיו החלטה כזו, הוא בדיוק הדבר שאיש מחוץ למעבדה לא בדק.

האם אתה באמת יכול להריץ את זה היום?

כן, אם יש לך GPU וסבלנות. החיכוך אמיתי והוא בעיקר בצנרת הווידאו, לא במודל.

זיכרון.Microsoft לא מפרסמת דרישת VRAM. ממדד המשקלים: 9.49 GB של shards ועוד 1.07 GB של gate הם כ-10.6 GB של פרמטרים מסוג BF16, כך שכרטיס עם 16 GB הוא רף ריאלי לעבודה עם תמונות, ו-24 GB או יותר הוא היעד ההגיוני ברגע שמוסיפים KV cache עבור וידאו ארוך או חלון סטרימינג. זהו חישוב מגדלי הקבצים, לא מפרט יצרן — מדוד לפני שתקצה.

קוד מותאם אישית הוא חובה. ה-auto_map מצביע על כל נקודות הכניסה של Transformers אל המודולים של המאגר עצמו, ולכן נדרש trust_remote_code. אתה מריץ את ה-Python של מיקרוסופט, לא רק טוען טנזורים. אין עדיין נתיב vLLM או SGLang, כלומר אין paged attention, אין continuous batching, אין ערימת הגשה לייצור — פער משמעותי אם קיווית לשים את זה מאחורי endpoint.

נתיב ה- codec דורש כלי מערכת. FFmpeg ו- ffprobe חייבים להיות ב- PATH שלך. מנוע ה- codec המסורתי תלוי בחבילת codec-video-prep המספקת שלב cv-preinfer; הנתיב העצבי דורש DCVC-RT; ומנוע ה- frames הרגיל דורש Decord. הדרישות כוללות גם את flash-attn ו- mamba-ssm, שמהדרים הרחבות CUDA — התקן תחילה גרסת PyTorch התואמת ל- toolkit שלך, או פנה אחר צהריים לבנייה.

מה שהתצורה אומרת לך שהכרטיס לא עושה.מקסימום הטמעות המיקום הוא 262,144, ולכן המפענח יורש את ההקשר הארוך של Qwen3-4B. צד הראייה פועל עם קלט של 448 פיקסלים, פאצ'ים של 16x16, מקודד בעל 24 שכבות ו-1024 ממדים נסתרים, מיזוג מרחבי של 2x2, טוקן אחד לשניית וידאו וחלון של ארבע פריימים. האימון הגיע לאורך זמני של 384 פריימים בשלב השלישי. תקרה של 262K אינה זהה ל-262K של התנהגות מאומתת, ו-384 פריימים הוא האורך שהמודל הוכשר בפועל להתמודד איתו.

קצוות גסים ידועים. דיון פתוח במאגר, שנפתח ב-4 באוגוסט ועדיין לא נענה, מדווח על חוסר יישור של טוקנים כאשר תמונות וסרטונים מועברים באותה בקשה. תוכנה בת עשרה ימים מתנהגת כמו תוכנה בת עשרה ימים. אם אתם רוצים הצצה בלי כל זה, ה-Space של מיקרוסופט על ZeroGPU הוא האפשרות ללא התקנה.

שורת הרישיון פחות פשוטה מ-"Apache-2.0"

כרטיס המודל מציין Apache-2.0. מקודד Mage-ViT מציין MIT. שניהם חופשיים בערך כמו שרישיונות משקולות פתוחים יכולים להיות. אבל מאגר המשפחה קובע ש"המודלים הללו משוחררים למטרות מחקר בלבד", עם דגש על בדיקת בינה מלאכותית אחראית ופיקוח אנושי — ומשפט זה יושב באי-נוחות לצד רישיון Apache-2.0, שאינו מגביל שימוש מסחרי. נוסף על כך, התלויות: DCVC-RT וכלי ההכנה של ה-codec נושאות תנאים משלהן, בלתי תלויים באלה של המודל.

עבור פרויקט תחביב, זה רעש. עבור כל דבר שמגיע ללקוחות, זה סוג העמימות שצריך להגיע לייעוץ משפטי לפני שהוא עולה לפרודקשן, וסוג השאלה שכדאי לשאול ב-repo עצמו — שבו, יש לציין, אין כיום נציג של מיקרוסופט שעונה.

האם כדאי לבנות על זה?

ההחלטה מתחלקת בצורה ברורה לאורך קו אחד: האם הבעיה שלך היא זרם או בקשה.

אם אתה עוסק בתפיסה מתמדת — פיד מצלמה, שידור חי, שדה הראייה של רובוט, פגישה שנמשכת שעה — Mage-VL מכוון בדיוק אליך, והכלכלה של אירוח עצמי לצידך. תמחור API לפי טוקן מתקנה עם מספר הפריימים, שזה מודל אכזרי לוידאו רציף; מודל 4B על החומרה שלך עם שער שנשאר שקט במהלך קטעים לא־אירועיים הוא עקומת עלות שונה ביסודה. המלכוד הוא שאתה גם נוטל על עצמך להיות האדם הראשון מחוץ למיקרוסופט שמגלה אם השיפוט של השער טוב בכלל.

אם הבעיה שלך היא בצורת בקשה — משתמש מעלה מסמך, קובץ PDF, צילום מסך, קליפ קצר ומצפה לתשובה — המקרה הרבה יותר חלש. במשימות האלה בדיוק, Mage-VL נמצא בשוויון עם מודל שתצטרך עדיין לארח בעצמך, ונקודות קצה מולטי-מודליות מתארחות נמצאות במרחק קריאת API אחת, ללא GPU, ללא בניית ffmpeg, וללא trust_remote_code. ב-OrcaRouter, Gemini 3.6 Flash עולה $1.50 למיליון אסימוני קלט ו-$7.50 למיליון אסימוני פלט, שזה המחיר הרשמי של הספק שמועבר ישירות — אנחנו לוקחים 0% עמלה, כך שכאשר ספק מוריד מחירים, ההורדה נכנסת אצלנו באותו יום במקום אחרי בדיקת מחירים. מפתח אחד מגיע ליותר מ-200 מודלים עם מעבר אוטומטי אם ספק מתדרדר, וזו הסיבה המעשית להשאיר נקודת קצה מתארחת כברירת מחדל ולשמור אירוח עצמי לעומסי עבודה שבאמת זקוקים לו.

כדי להיות מפורשים, כי ההבחנה חשובה: אנחנו לא מארחים את Mage-VL, וגם אף אחד אחר לא.דף המודל של Hugging Face עצמו אומר שאף ספק הסקה לא פרס אותו. כיום, להריץ אותו פירושו להריץ אותו בעצמך.

מה ישנה את הקריאה הזו?

ארבעה דברים, בסדר גס לפי מידת החשיבות שלהם.

הערכה בלתי תלויה היא החשובה ביותר. כל מספר לעיל הוא טענה, והטענה שהכי דורשת בדיקה אינה ציון השוואתי (benchmark), אלא האצת פי 3.5, שנמדדה מול דגימת פריימים אחידה על NExT-QA ללא פרסום פרטי חומרה, רזולוציה או ספירת פריימים. עיבוד מקדים של Codec מעביר עבודה אמיתית למעבד ול-ffmpeg; ניצחון במדידת זמן שעון (wall-clock) מקצה לקצה על מערכת של מישהו אחר הוא הגרסה היחידה של המספר הזה שכדאי לתכנן לפיה.

שנית, תמיכת הגשה. יישום מאוחד של vLLM או SGLang היה הופך את זה מנקודת ביקורת מחקרית למשהו שניתן להציב מאחורי מאזן עומסים. הנושא של SGLang פתוח וללא בעלים; זה השרשור שכדאי לעקוב אחריו.

שלישית, רישום ב-Azure AI Foundry, אשר יאותת שמיקרוסופט מתכוונת לכך כמוצר ולא כמאמר. שום דבר במהדורה הנוכחית אינו מרמז שזה קרוב.

רביעית, והמוזר ביותר: האם מיקרוסופט אומרת אי פעם משהו. דוח טכני עם 23 מחברים, דף פרויקט מתוחזק, Space הדגמה מתארח, ומודל גנרטיבי נלווה, שיצא ארבעה ימים קודם לכן, אינם מתארים הדלפה או תאונה — הם מתארים פרסום מחקרי מכוון שדילג לחלוטין על מגאפון המוצר. הקהילה מילאה את השתיקה בכל זאת, עם תשע קוונטיזציות ושני פיין-טיונים בתוך עשרה ימים.

לרוב הצוותים {{1}}המהלך הנכון הוא לקרוא את המאמר, לא להוריד את המשקלים{{/1}}. {{2}}הרעיון הטבעי לקודק הוא התובנה המרכזית, והוא נייד{{/2}}: {{3}}אם שימוש חוזר בוקטורי התנועה שהמקודד כבר חישב אכן מניב הפחתה של 75% בטוקנים ברמת דיוק זהה, הטכניקה הזו תופיע במודלים עם פוסטי השקה, תמיכת ספקים ובנצ'מרקים משוחזרים{{/3}}. {{4}}אם אתה מריץ וידאו רציף היום, החישוב שונה{{/4}} — {{5}}שכפל את הריפו, הרץ את הקליפים שלך דרך שני הבקאנדים, ומדוד את ההאצה בעצמך{{/5}}, {{6}}כי כרגע אתה תהיה הראשון{{/6}}.

שאלות שכדאי באמת לשאול

האם Mage-VL הוא פשוט Qwen3-VL עם תווית של Microsoft?

לא, אם כי הבלבול מובן. מפענח השפה הוא Qwen3-4B-Instruct-2507, בשימוש כפי שהוא — מיקרוסופט לא אימנה מודל שפה חדש. כל השאר חדש: Mage-ViT אומן מראש מההתחלה, לטוקניזציה המקומית-לקודק אין מקבילה ב-Qwen3-VL, ושער הסטרימינג הוא מודל נוסף של חצי מיליארד פרמטרים. שימוש חוזר בעמוד שדרה פתוח והחלפת הקצה הקדמי החזותי היא אסטרטגיית מחקר לגיטימית והולכת ונעשית נפוצה, וכאן היא גם מה שהופך את ההשוואה הישירה (head-to-head) לניתנת לפרשנות. אם יש לך דרישות ציות בנוגע למקור המודל, שים לב ששושלת היוחסין עוברת דרך משקולות Qwen3 של עליבאבא, ובדוק את שני הרישיונות.

האם "מהיר פי 3.5" אומר פי 3.5 זול יותר לשרת?

לא באופן אמין. הנתון הוא האצת זמן-שעון על NExT-QA לעומת דגימת פריימים אחידה, ומיקרוסופט ממסגרת אותו כ״עד״. שני דברים מדללים אותו בפועל. הסקה מובנית-קודק דורשת מעבר הכנה — ffmpeg, ffprobe, ושלב cv-preinfer, או קידוד מחדש של DCVC-RT עבור הנתיב העצבי — שצורך זמן מעבד ש-pipeline של פריימים נאיבי אינו צורך, ושאינו מופיע במדידה בצד ה-GPU. והרווח נובע מהפחתת טוקנים, כך שהוא מתרחב בהתאם לרמת הכפילויות בצילומים שלך: מצלמת אבטחה סטטית ברובה אמורה להשיג תוצאה טובה יותר מהנתון המוצג, בעוד וידאו ערוך עם קאטים מהירים שבו כמעט כל פאץ׳ משתנה אמור להשיג תוצאה גרועה יותר. מדוד זאת על הקליפים שלך.

האם אני צריך קבצי וידאו מיוחדים כדי להשתמש במסלול ה-codec?

בעיקר לא, וזו ההפתעה הנעימה. קובצי MP4 רגילים הם כבר H.264 או HEVC, שזה בדיוק מה שהבקאנד המסורתי של ה-codec צורך — וקטורי התנועה שהוא צריך נמצאים בקובץ שכבר יש לך. מה שצריך להוסיף הוא הכלים: FFmpeg ו-ffprobe ב-PATH שלך, ובנוסף חבילת ההכנה של ה-codec. הבקאנד העצבי הוא היוצא מן הכלל; DCVC-RT מצפה לווידאו שמקודד עם אותו codec, כך שתצטרך לבצע קידוד מחדש. ובקאנד של הפריימים הפשוטים נשאר זמין כגיבוי שמתנהג כמו כל VLM אחר, וזו גם הדרך הכנה לבצע A/B על טענת ה-codec בעצמך.

האם אני יכול להשתמש בו מסחרית?

הרישיון קובע Apache-2.0, המתיר שימוש מסחרי, שינוי והפצה מחדש. המאגר גם אומר שהמודלים "שוחררו למטרות מחקר בלבד". שתי ההצהרות הללו מצביעות לכיוונים שונים, והפער לא הובהר על ידי איש במיקרוסופט — דבר שאינו מפתיע בהשקה ללא הודעה, ללא רישום מוצר, וללא נוכחות ספק בדיוני המאגר. אם כסף תלוי בתשובה, שכרו עורך דין שיקרא את שני המסמכים ואת רישיונות התלות במקום לסמוך רק על תג הרישיון.