כרטיס כותרת ראשי: קריאה לכלים של DeepSeek V4.1 Flash מגיעה ל-vLLM — התגים המרווחים שברו את גלאי V4
Engineering & Research

קריאה לכלים של DeepSeek V4.1 Flash מגיעה ל-vLLM: מה שברו התגיות המרווחות

מחבר

Rowan Sterling

תאריך פרסום

מודלים אחרונים · 20צפו בכל המודלים
בנצ'מרקים: Artificial Analysis · מתעדכן יומית
חזרה לכל הפוסטים

DeepSeek V4.1 Flash זמין באופן כללי מאז 10 בספטמבר 2026, ובשנים עשר הימים הראשונים לחייו היה למודל פער שאיש לא כתב עליו: הוא ידע להפעיל היגיון, הוא ידע לראות תמונות, הוא ידע להחזיק מיליון טוקנים של הקשר — והוא לא ידע לקרוא לכלי באופן אמין דרך מחסנית ההגשה הפתוחה הנפוצה ביותר. הפער הזה נסגר כעת ב-vLLM — לא עם דגל תצורה, אלא עם שכתוב של מנתח. שני Pull requests נושאים את העבודה, והסיבה שנדרשו היא החלק המעניין.

הגרסה הקצרה: DeepSeek V4.1 Flash פולט את קריאות הכלים שלו בפורמט תגיות שמזהה ה-DeepSeek V4 הקיים אינו מזהה, ולכן בפריסת vLLM סטנדרטית, סימון קריאות הכלים מגיע כטקסט רגיל במקום כפלט מובנה. שום דבר לא מחזיר שגיאה. זה נראה כאילו המודל פשוט סירב לקרוא לפונקציה. אם בדקתם לולאות סוכנים מול DeepSeek V4.1 Flash באירוח עצמי והסקתם שהמודל גרוע בכלים, כנראה שזה בדיוק מה שראיתם.

מה באמת השתנה במערכת ההגשה

ניתוח קריאות הכלים של vLLM עבור מודלי DeepSeek מתקיים כבר זמן מה בשני מקומות: פרונטאנד Python ופרונטאנד Rust חדש יותר, כאשר העבודה ברמת הדקדוק מופקדת בידי פרויקט XGrammar. הבאת התמיכה ב-V4.1 Flash הצריכה העברה של המרת ה-C++ של deepseek_xml שבתוך XGrammar אל ה-builder של Rust, ואז חיבור הקידוד של המודל עצמו לתיקיית ה-tokenizer של vLLM.

• עבודת ה-frontend ב-Rust היא PR #56235, אשר מעבירה את המרת XGrammar C++ deepseek_xml אל תוך ה-builder ב-Rust. היא כוללת 18 בדיקות חדשות במיוחד עבור V4.1, וכל החבילות הקיימות — 472 בדיקות ב-vllm-parser ו-326 ב-vllm-chat — נשארות ירוקות.

• עבודת ה-frontend של Python היא PR #56408, שעדיין נמצא בטיוטה. היא תלויה בשינוי במעלה הזרם ב-XGrammar (mlc-ai/xgrammar#885) שייטמע תחילה, ומדווחת על 110 בדיקות שעוברות כאשר התלות הזו מיושמת.

• מודול הקידוד החדש הוא vllm/tokenizers/deepseek_v41_encoding.py — קובץ נפרד ולא ענף בתוך קידוד V4, מה שמעיד שדקדוק התגים שונה באמת ולא רק מהווה הרחבה.

• ההפעלה מפורשת: --tool-parser deepseek_v41. אין מנגנון גיבוי של זיהוי אוטומטי שעושה בשקט את הדבר הנכון.

התגים המרווחים הם כל הסיפור

הסיבה לכך שקיים מנתח חדש במקום ביטוי רגולרי מורחב היא רווחים לבנים. DeepSeek V4.1 Flash כותב את תגי הכלים של DSML שלו עם רווחים בין הטוקנים. התבנית של גלאי V4 מצפה לצורה ללא רווחים, ולכן היא נכשלת בהתאמה, והתאמה שנכשלת במנתח קריאות כלים היא שקטה מעצם תכנונה — הטקסט מועבר הלאה כתוכן במקום להעלות שגיאה.

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

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

למה זה חשוב יותר עבור V4.1 Flash מאשר עבור V4

קריאה לכלים אינה מותרות עבור המודל המסוים הזה. DeepSeek V4.1 Flash הוא מודל תערובת מומחים בעל 552 מיליארד פרמטרים, עם 8 מיליארד פרמטרים פעילים בקלט ו-16 מיליארד פעילים בפלט, חלון הקשר של מיליון טוקנים ופלט מקסימלי של 384 אלף טוקנים. פיצול ההפעלה הוא הרמז: המודל בנוי לקבל קלט גדול — מאגר קוד, סט מסמכים, עקבות כלים ארוכות — ולהפיק תגובה ארוכה ומובנית. זו צורה של סוכן, לא צורה של צ'אט.

שאר מפרט ההשקה מצביע לאותו כיוון. משקלים ברישיון MIT, 890 בייטים של מטמון KV לכל טוקן, 45 טריליון טוקנים של אימון מקדים, ראייה נייטיבית. נתון מטמון ה-KV הוא זה שחשוב תפעולית בחלון הקשר של 1M: הוא מה שמאפשר להחזיק תמלול סוכן ארוך בזיכרון בעלות סבירה, והוא הסיבה לכך שהמודל סביר בתור העובד הזול בלופ שמודל יקר יותר מפקח עליו.

Single-model scoreboard for DeepSeek V4.1 Flash: 552B total parameters in a mixture-of-experts design with 8B active on input and 16B on output, 1M-token context window, 384K max output, $0.15 input and $0.60 output per 1M tokens off-peak, and an 890-byte KV cache per token, footnoted as specs from DeepSeek's own release page with no independent tool-calling score yet

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

Screenshot of DeepSeek's own release page for DeepSeek-V4.1-Flash dated 2026/09/10, showing the 552B-parameter MoE architecture with 8B active for input and 16B for output, a KV-cache memory-reduction graphic, and DeepSeek's own four-benchmark comparison chart

מה עדיין פתוח?

מצב הדברים האמיתי, נכון ל-22 בספטמבר 2026:

• נתיב ה-Frontend של Rust (PR #56235) הוא זה שיש לו כיסוי בדיקות מלא גם במקרי V4.1 החדשים וגם במערכי הבדיקות הקיימים. אם אתם על build של vLLM שכולל אותו, ה-parser זמין לכם כבר היום.

• נתיב ה-Frontend של Python (PR #56408) הוא טיוטה ויש לו תלות חיצונית. אם אתם מוצמדים ל-build שקודם לשינוי של XGrammar, ה-Frontend של Python עדיין לא יספק לכם ניתוח כלים של V4.1.

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

• אין עדיין ראיות פומביות לקיומו של בנצ'מרק עצמאי לקריאה לכלים שהורץ מול V4.1 Flash עם המנתח החדש בפעולה. מה שאנחנו יודעים הוא שהתשתית עובדת והבדיקות עוברות. האם איכות הקריאה לכלים של המודל טובה היא שאלה נפרדת שהמיזוג אינו עונה עליה.

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

אם אינך רוצה להפעיל בעצמך את סטאק ההגשה

יש נתיב קצר יותר. DeepSeek V4.1 Flash זמין דרך נקודת הקצה של OrcaRouter עבורו, מה שאומר שהתנהגות הקריאה לכלים מגיעה כקריאת API רגילה ולא כבעיית בנייה — אין גרסת XGrammar להתאים, אין פרונטאנד לבחור, אין דגל הפעלה לזכור. הסיבה שזה חשוב כאן במיוחד היא שהתיקון נחת בשני מקומות עם בגרות שונה, ונקודת קצה מתארחת מאיינת לחלוטין את ההחלטה הזו.

אותו מפתח מגיע גם אל שאר המודליםשאיתם תשוו, וזו התכונה השימושית כשהשאלה היא לא "האם המפרסר הזה תקין" אלא "האם המודל הזה טוב מספיק ללופ שלי". אפשר להציב את DeepSeek V4.1 Flash מאחורי כלל ניתוב כמבצע הזול, ולעבור למודל חזק יותר כשהקריאה נכשלת, בלי חוזה נוסף או SDK נוסף. לנסות מודל שתמיכת קריאות הכלים שלו בת שבועיים היא בדיוק המצב שעבורו קיים מעבר כשל אוטומטי.

Screenshot of the OrcaRouter model page for deepseek/deepseek-v4.1-flash, showing the model id with a Featured badge, 1M-token context, 384K max output, text and image input, $0.15 input and $0.60 output per 1M tokens, a cache read rate of $0.003, and observed time to first token of 2.63 s at p50 and 9.05 s at p95

מה לצפות בהמשך

שלושה דברים היו הופכים את זה מסיפור צנרת לפסק דין:

• PR #56408 יוצא מטיוטה, מה שיהפוך את מסלול ה-frontend של Python למציאותי ויסיים את מצב התמיכה הדו-רמתי.

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

• האם מערכי הגשה אחרים עוקבים אחר כך. vLLM הוא זה שיש לו PRs פומביים; בעיית התגים המרווחים אינה ייחודית ל-vLLM, ולכן כל מערך שאימץ את גלאי V4 בלי לגזור אותו מחדש מפלט V4.1 נושא בתוכו את אותו כשל שקט.

עד שהראשון מאלה יגיע, הסיכום המדויק הוא מצומצם וראוי להציגו בפשטות: DeepSeek V4.1 Flash הוא מודל GA עם משקולות MIT, חלון הקשר של 1M ותקרת פלט של 384K, וקריאת הכלים שלו עובדת כעת בנתיב Rust ב-vLLM עם דגל מנתח מפורש. זהו צעד אמיתי וזה עדיין לא תוצאה.

השוואות במאמר הזה1

זוהה מתוך המאמר הזה · בנצ'מרקים: Artificial Analysis · מתעדכן יומית