VideoJev: מודל וידאו שעונה במספר במקום משפט

VideoJev היא משפחה של מודלים להבנת וידאו שלעולם אינם כותבים תשובה. שאלו אותה מהי חותמת הזמן של אירוע, והיא מחזירה מרווח שהורכב ממשבצות מועמדים מדורגות; שאלו אותה שאלת בחירה מרובה על סרטון, והיא מחזירה את האפשרות בעלת הציון הגבוה ביותר. קיימים שני צ'קפוינטים ששוחררו — VideoJev-4B המבוסס על Qwen3.5-4B, וכן VideoJev-35B-A3B המבוסס על Qwen3.6-35B-A3B — והם לא הושקו. איש לא הוציא הודעה לעיתונות. מאמר הופיע ב-arXiv ב-13 באוקטובר 2026, המשקלים עלו ל-Hugging Face ב-10 באוקטובר 2026, והמאגר עדיין עבר סידורים ארבעה ימים לאחר מכן: נכון ל-14 באוקטובר הוא קיבל קומיטים כמו "Restore inline README video with a public attachment" ו-"Add arXiv paper link and official BibTeX citation." כך נראית השקה שקטה — הארטיפקטים אמיתיים וניתנים לבדיקה, ואין שום הודעה שתספר לך מה המחברים חושבים שחשוב.

כל מה שלהלן מגיע מאחד משלושה מקומות: ה-preprint ב-arXiv (2610.18615, cs.CV, הוגש ב-13 באוקטובר 2026), כרטיסי המודל והקוד שהמחברים פרסמו, והערות השוליים של המאמר עצמו על כיצד נמדדו המספרים. ניסיתי להשאיר את שלושת אלה מופרדים בבירור, כי הדבר המעניין בפרסום הזה אינו המספר הכותרתי — אלא כמה דקה הקרקע שמתחתיו.

מה שהמאמר למעשה טוען

VideoJev לוקח LLM מולטימודלי מאומן מראש, מוחק את ה-MLP האחרון ואת ראש הפלט של מודל השפה, ושם במקומם מדרג מועמדים. שני טוקנים חדשים, <|option_end|> ו-<|decide|>, מפיקים קריאות. מצב ההחלטה וכל מצב מועמד מוקרנים ל-512 ממדים, מנורמלים, ומוכפלים זה בזה בנקודה; מרווחים זמניים מדורגים בעזרת סיגמואיד ומאוגדים לקטע, אפשרויות תשובה מדורגות ומנורמלות בעזרת softmax. שתי המשימות עוברות דרך אותו ראש. שום דבר לא מפוענח באופן אוטורגרסיבי, כי אין מה לפענח.

שלושת המספרים המרכזיים של המאמר, כולם מדווחים על ידי הספקים וכולם מגיעים ממערכת ההערכה של המחברים עצמם:

• איכות העיגון — ‏VideoJev-4B מגיע ל-65.3 mIoU ממוצע על פני שלושה מדדי עיגון זמני, 6.7 נקודות מעל עמוד השדרה Qwen3.5-4B שלו. ‏VideoJev-35B-A3B מגיע ל-67.7, 10.8 נקודות מעל Qwen3.6-35B-A3B.

• שוויון ב-QA ללא הסקה — בארבעה מדדי ייחוס של QA על וידאו, שני המודלים עומדים על ממוצע של 74.3 ו-79.5, בתוך 0.6 נקודות מתחת ו-0.7 נקודות מעל מודלי הבסיס שלהם במצב חשיבה, בהתאמה.

• השהיה — מהירים פי 2.8–3.1 מאשר עמודי השדרה הללו במשימות עיגון, ופי יותר מ-100 במשימות QA. הנתון הנמדד עבור QA הוא פי 129 ב-4B ופי 100 ב-35B-A3B.

הניסוח הישר של טענת המהירות הוא שזו השוואה מול מודל הסקה שעושה משהו קשה בהרבה ממה שהמשימה דורשת. Qwen3.5-4B במצב Thinking שורף 144.9 שניות לשאלה ב-LVBench כדי להשיג ציון 74.9; VideoJev-4B משקיע 1.123 שניות כדי להשיג 74.3. ה-129× הוא חשבון אמיתי לפי טבלת זמני השהיה של המאמר עצמו, והוא גם החשבון שהייתם מקבלים מכל מודל שמסרב לחשוב. השאלה המעניינת אינה אם ההאצה אמיתית — אלא אם אפשר לבנות מערכת שבה הפשרה הזו נכונה.

הטיעון שמתחת לזה: החלטות, לא דורות

מה שהופך את זה למעניין יותר מטבלת בנצ'מרק הוא הטענה הארכיטקטונית. המחברים ביצעו כיוונון עדין ל-Qwen3.5-4B אוטורגרסיבי רגיל על בדיוק אותם נתוני פוסט-אימון, באותו שלב יחיד, עם אותן הגדרות, והורו לו להפיק מרווחים או להשיב באותיות. טבלה 3 במאמר אומרת ש-VideoJev-4B מנצח את מודל הבקרה הזה ב-1.3 נקודות של mIoU ממוצע של עיגון וב-1.9 נקודות של ציון QA ממוצע. שני המודלים ראו פיקוח זהה; רק צורת הקריאה הייתה שונה.

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

שני פרטי מימוש שווים יותר מאשר מספרי הכותרת, משום שהם אלה שהופכים אותו לשמיש ולא רק למהיר. הסקה ממוטנת מקודדת ומבצעת מילוי מקדים לווידאו פעם אחת ומאפשרת לשאילתות שמגיעות להסתעף מאותה תחילית ממוטנת — מעבר קדימה אחד לכל שאילתה. הסקה משותפת מציבה כמה שאילתות מאחורי תחילית וידאו אחת וקוראת <|decide|> נפרד עבור כל אחת, כך שקבוצת שאלות עולה בסך הכול מעבר קדימה אחד. על עשר שאילתות grounding מול וידאו אחד המאמר מודד 0.39 שניות עבור VideoJev לעומת 5.98 שניות עבור בסיס Instruct; בצד ה-QA, עשר שאילתות מגיעות ל-1.67 שניות. המאמר גם בוחן את מצב הכשל המובן מאליו של הסקה משותפת — ששאלה מוקדמת מדליפה את תשובתה אל שאלה מאוחרת — ומדווח שאימת שלא מוכנסות תשובות ייחוס או תשובות חזויות לתחילית המשותפת. ראוי לציין שזו בדיקה של המחברים עצמם, ושהסקה משותפת משיגה תוצאה טובה יותר מאשר מצב המטמון המבודד (65.3 לעומת 64.5 mIoU ב-4B), שאותו הם מייחסים לאימון על אותה פריסה משותפת.

מה שהכרטיס לא מספר לך

ארבעה דברים נעדרים באופן בולט, והם חשובים יותר מכל מה שנאמר לעיל אם אתם מחליטים אם זה מוכן לייצור.

• נתוני האימון אינם מפורסמים. הריפו מתעד את הפורמט ומספק לך את הכלים לבנות JSONL משלך, אך הקורפוס, גודלו ומקורו אינם מצוינים. אינך יכול להעריך זיהום מול שבעת הבנצ'מרקים שעליהם הוא מדווח.

• המשקולות של 35B מתחילות ב-FP32. עמוד הפרויקט מציין FP32 עבור הסקה במצב Cached ו-BF16 עבור Joint — כלומר תצורת הדגל של המודל הגדול יותר היא זו עם טביעת הזיכרון הכבדה יותר, והעמוד אינו מציין נתון VRAM עבור אף אחד מהם.

• הביטחון הוא ביטחון-יתר. המאמר מדווח על שגיאת כיול ממוצעת של 8.65 נקודות עבור 4B ו-8.13 עבור 35B-A3B. הציון הוא אות דירוג שמיש, ולא הסתברות שכדאי להסתעף עליה בלי סף שכוונתם בעצמכם.

• אף אחד לא בדק את המספרים באופן עצמאי. כל נתון כאן מגיע מהקבוצה שאימנה את המודלים. נכון לכתיבת שורות אלה אין שכפול מצד שלישי, אין רשומה בלוח המובילים ותמיכת פריימוורק לא נחתה — נתיב ההסקה הוא trust_remote_code=True מול ארכיטקטורה מותאמת אישית, ודורש PyTorch 2.8/CUDA 12.8 ו-FlashAttention 2 לכל הפחות.

הנקודה האחרונה חלה גם על המודל הקטן יותר, והיא עומדת בניגוד להנחה המתבקשת. VideoJev-4B הוא זה שהייתם מצפים שירוץ על חומרה צנועה, ומדריך ההתחלה המהירה של הכרטיס עצמו מניח H200 בקצב של 2 fps עם עד 2,048 פריימים. יש הדגמה זולה יותר — קליפ של עשר שניות, עשרה מרווחים מועמדים, הסתברויות מודפסות — אבל תוצאות הווידאו הארוך במאמר משתמשות בהקשר קבוע של 262,144 טוקנים עם פריימים המוגבלים ל-640×640. ה-4B קטן בפרמטרים, לא בהכרח בעלות ההגשה.

לנסות את זה בלי להמר על זה

מכיוון שהצ'קפוינטים הם מה שבאמת קיים, הדרך בעלת הסיכון הנמוך להיכנס היא להריץ את VideoJev באופן מקומי על הצילומים שלכם לפני שאתם בונים עליו משהו — מסלול ההדגמה הוא הורדה ותריסר שורות, ומקרי הכשל שהמאמר עצמו מתעד (ספירת עצמים קטנים ב-Video-MME, שבו שני הגדלים מפספסים תשובה של ארבעה ספרים) הם בדיוק אלה שתרצו לפגוש בנתונים שלכם ולא ב-Charades.VideoJev-4B ו-VideoJev-35B-A3B הם תחת רישיון Apache-2.0, כך ששום דבר לא עוצר בעדכם.

המקום שבו OrcaRouter משתלב הוא החצי השני של זרימת העבודה. ממשק לקבלת החלטות וידאו הוא נדיר כשלעצמו; מה שנפוץ הוא צינור עיבוד שזקוק גם למודל גנרטיבי שיכתוב את הסיכום, למסווג זול שיסנן את הקריאה היקרה, ולמשהו שינתב ביניהם. OrcaRouter מציב יותר מ-200 מודלים מאחורי API אחד עם 0% תוספת מחיר — מחיר המחירון של הספק מועבר כמו שהוא, כך שהורדת מחיר של ספק נכנסת לתוקף כאן באותו יום — עם מעבר אוטומטי בין ספקים בעת כשל, DSL לניתוב להרכבת כמה מודלים לקריאה אחת, ומיזוג מודלים לפאנלים. אף אחד מהצ'קפוינטים של VideoJev לא מתארח כאן, והמאמר הזה לא הולך להעמיד פנים אחרת; שני המקומות שבהם הוא מצדיק את מקומו הם כרגל השנייה של צינור עיבוד שהרגל הראשונה שלו היא מודל מקומי, וכסיבה לכך שמודל מחקרי כמו זה יכול להיבחן בלי חוזה ספק שני לכל מה שמסביבו.

מה יהפוך את זה לסיפור גדול יותר?

השער על הקטע הזה נקי באופן יוצא דופן, ולכן ראוי לומר זאת בפשטות: VideoJev הוא מהדורת מחקר, לא השקת מוצר. אין יומן שינויים, אין עמוד תמחור, אין נקודת קצה מתארחת, אין רשימת המתנה ואין פוסט בבלוג של הספק. מה שקיים הוא פריפרינט שהוגש ב-13 באוקטובר 2026, שני צ'קפוינטים Apache-2.0 שהועלו ב-10 באוקטובר, ומאגר שעדיין נערך ב-14 באוקטובר — יום לפני המאמר הזה. היעדר הכרזה אינו ראיה לבעיה, אבל הוא כן אומר שהמסגור חייב להיות "מה שהארטיפקטים אומרים", לא "מה שהספק טוען".

שלושה פיתוחים ישנו את הצורה של זה. הערכה של צד שלישי המשחזרת את השיפורים של +6.7 ו-+10.8 mIoU מול אותם עמודי שדרה תחת אותו פרוטוקול. מימוש של vLLM או SGLang, שיעביר אותו מ-trust_remote_code כסקרנות למשהו שאפשר לשרת בתפוקה. או נקודת קצה מתארחת ממישהו, שתהפוך את טענת ה-100× למספר שאתה יכול למדוד על הווידאו שלך במקום אחד שאתה לוקח מטבלה בעמוד השישי. עד שאחד מאלה יתממש, העמדה השימושית היא זו שהמאמר עצמו נוקט: ממשק הניקוד הישיר הוא דרך שונה באמת לבנות סוכן וידאו, והראיות לכך הן כרגע preprint בן תשעה עמודים של קבוצה אחת.

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

שחרור הוא גם הרגע לבדוק מה השתבש קודם: תקריות ה-AI המתועדות וכשלי סוכנים סביב מודלים בקטגוריה הזו מרוכזים בארכיון תקריות ה-AI של OrcaRouter , כאשר כל רשומה נושאת את המקורות שלה, חומרה, דירוג ביטחון ודגל מחלוקת.