DeepSeek V4 יוצא רשמית: חלון הקשר של מיליון טוקנים ותמחור לפי שעות עומס

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

מה בדיוק הכריזה DeepSeek ומתי V4 יוצא?

לפי הדיווח של TechNode מסוף יוני 2026, הגרסה הרשמית של DeepSeek V4 תושק באמצע יולי. ההכרזה כוללת שלושה מרכיבים מרכזיים: חלון הקשר של מיליון טוקנים שיחול על כל קו המודלים של החברה ולא רק על גרסת דגל אחת, שיפורי יכולת בשלושה תחומים שהם ליבת השימוש המסחרי כיום (משימות סוכניות, הסקה מתמטית וכתיבת קוד), ומודל תמחור חדש שבו מחיר הקריאה ל-API משתנה לפי שעת היום.

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

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

מה נותן חלון הקשר של מיליון טוקנים בפרודקשן?

חלון הקשר של מיליון טוקנים מאפשר להזין למודל בבקשה אחת כמות טקסט שמקבילה בקירוב לכמה ספרים עבים, בסיס קוד בינוני שלם, או היסטוריית שיחה של סוכן שרץ שעות. חלון הקשר (context window) הוא כמות הטוקנים המקסימלית שהמודל יכול לעבד בקריאה אחת, כולל ההנחיות, המסמכים והתשובה. עד לאחרונה, חלונות של מאתיים עד ארבע מאות אלף טוקנים נחשבו לרף העליון בשימוש מסחרי רחב, ומיליון טוקנים היה נחלתם של מודלים בודדים ויקרים.

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

האם הקשר ארוך מייתר RAG?

לא, אבל הוא משנה את נקודת האיזון. RAG (Retrieval-Augmented Generation, אחזור מסמכים רלוונטיים והזרקתם להקשר) עדיין עדיף כשמאגר הידע גדול ממיליון טוקנים, כשהוא מתעדכן בתדירות גבוהה, או כשצריך לשלוט במקורות לצורכי ציות ואבטחה. אבל עבור מאגרים בינוניים ויציבים, טעינה מלאה להקשר חוסכת שכבת תשתית שלמה: אין וקטורים, אין embedding, אין כוונון של אחזור. שיקול נגדי שחייבים לזכור: עלות. כל טוקן בהקשר נספר בחיוב, ומיליון טוקנים בכל קריאה זה סעיף תקציבי אמיתי. כאן בדיוק נכנס לתמונה מודל התמחור החדש, ולכן שני החידושים האלה קשורים זה לזה יותר משנדמה.

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

איך עובד תמחור API לפי שעות שיא ושפל?

תמחור דיפרנציאלי לפי שעות עומס אומר שאותה קריאת API עולה יותר בשעות שבהן הביקוש לתשתית גבוה, ופחות בשעות שפל. זה מודל מוכר היטב משוק החשמל ומענן המחשוב (למשל Spot Instances), אבל לפי הדיווח זו הפעם הראשונה ש-DeepSeek מטמיעה אותו כמדיניות תמחור רשמית לכל קו המודלים החדש. הרציונל התפעולי ברור: מקבצי GPU הם משאב יקר וקשיח, והביקוש אליו תנודתי. הנחה בשעות שפל מסיטה עומסים לא דחופים לשעות שבהן החומרה ממילא פנויה, ומשפרת את ניצולת התשתית של הספק.

🚀 DeepSeek-V4 Preview is officially live & open-sourced! Welcome to the era of cost-effective 1M context length.

🔹 DeepSeek-V4-Pro: 1.6T total / 49B active params. Performance rivaling the world's top closed-source models.
🔹 DeepSeek-V4-Flash: 284B total / 13B active params.… pic.twitter.com/n1AgwMIymu

— DeepSeek (@deepseek_ai) 24 באפריל 2026

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

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

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

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

1. מפו את הקריאות שלכם לשני סוגים: אינטראקטיביות (המשתמש מחכה לתשובה, חייבות לרוץ מיד) ואסינכרוניות (אף אחד לא מחכה, אפשר לדחות בשעות).
2. הפרידו את הצנרת: קריאות אינטראקטיביות ממשיכות לרוץ בזמן אמת. קריאות אסינכרוניות נכנסות לתור (למשל דרך SQS, Pub/Sub או תור מבוסס Redis) עם מדיניות עיבוד לפי חלון זמן.
3. בנו שכבת ניתוב מודעת-מחיר: רכיב תזמון שקורא את לוח התעריפים, ומשחרר משימות מהתור כשהמחיר יורד מתחת לסף שהגדרתם.
4. הוסיפו מדידה לפי משימה: תייגו כל קריאה בעלות בפועל (טוקנים כפול תעריף באותה שעה), כדי שתוכלו לראות בדשבורד כמה כל פיצ'ר עולה באמת.
5. הגדירו מנגנון גלישה: אם התור מתארך מעבר ל-SLA פנימי, המערכת מריצה את המשימות גם בתעריף גבוה. חיסכון לא שווה פגיעה במוצר.

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

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

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

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

חלון הקשר (Context Window)

כמות הטוקנים המקסימלית שהמודל מעבד בקריאה אחת - כולל ההנחיות, המסמכים והתשובה.

RAG

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

משימות סוכניות (Agentic Tasks)

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

עיבוד אצווה (Batch)

עומסים אסינכרוניים שאף משתמש לא מחכה להם - סיכומים, אינדוקס, דוחות - ולכן אפשר לדחות אותם לשעות זולות.

תמחור דיפרנציאלי

מחיר קריאת API שמשתנה לפי שעת היום: יקר בשעות ביקוש שיא, זול בשעות שפל.

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

למה תמחור דיפרנציאלי חשוב במיוחד לצוותי פיתוח ישראליים?

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

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

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

מבט קדימה: איך להתכונן להשקה של DeepSeek V4

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

צ'קליסט הכנה להשקת V4

• מפו כל קריאת API כאינטראקטיבית (המשתמש מחכה) או אסינכרונית (ניתנת לדחייה)
• הכניסו עומסי אצווה לתור עם מדיניות עיבוד לפי חלון זמן
• בנו שכבת ניתוב מודעת-מחיר שמשחררת משימות כשהתעריף יורד מתחת לסף
• תייגו כל קריאה בעלות בפועל כדי לדעת כמה כל פיצ'ר עולה באמת
• הגדירו מנגנון גלישה: אם התור חורג מה-SLA, מריצים גם בתעריף גבוה
• הכינו סט משימות ייחוס להשוואת V4 מול המודל הנוכחי שלכם
• עקבו אחרי פרסום לוח התעריפים המלא ביום ההשקה

אם אתם רוצים להעמיק בבניית מערכות מבוססות LLM, מ-RAG ועד סוכנים בפרודקשן, תמצאו מסלולים מעשיים בעמוד קורסי הבינה המלאכותית שלנו. ולסיקור שוטף של מודלים חדשים, מלחמות תמחור ומגמות בשוק ה-AI של 2026, המשיכו לעקוב אחרי מגזין ה-AI של AICourse.