Speculative Execution — הפעלת כמה מסלולי AI ובחירת המנצח

מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳

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

צוות שבנה מנוע לניתוח חוזים משפטיים ניצב בפני דילמה: קריאה אחת למודל היקר ביותר עם budget חשיבה גבוה לוקחת 40 שניות ומדויקת ב-91% מהמקרים; קריאה זולה יותר עם מודל בינוני לוקחת 12 שניות ומדויקת ב-78%. הפתרון שבחרו לא היה "לבחור אחד" אלא להריץ את שניהם וגם מסלול שלישי — מודל זול עם prompt ממוקד יותר — במקביל, ולתת ל-verifier קל לבחור בין שלוש התשובות שחוזרות. משך הריצה ירד ל-14 שניות (כי מחכים למהיר מביניהם שמספק תשובה שעוברת אימות) והדיוק עלה מעל 93%. זו בדיוק ההיגיון של Speculative Execution ברמת אורקסטרציה — לא להמר על מסלול אחד, אלא להריץ כמה מסלולים ולתת למנגנון בחירה מהיר להכריע.

מאיפה הרעיון מגיע ולמה הוא רלוונטי ל-agents

המונח שאול מ-CPU architecture: מעבד מודרני מריץ ספקולטיבית הוראות שהוא עדיין לא בטוח שיידרשו, ופשוט זורק את התוצאה אם ניחש לא נכון. באותה רוח, אפשר להריץ בפועל כמה נתיבי פתרון AI במקביל — לא כי אנחנו לא יודעים איזה יהיה נכון, אלא כי אנחנו לא יודעים איזה יהיה הכי טוב תחת אילוצי זמן ועלות נתונים, ומוכנים לשלם על כמה ניסיונות כדי לקבל את התוצאה הכי טובה או המהירה ביותר. זה שונה מ-Best-of-N שתואר בהקשר של inference-time compute: שם מריצים את אותו מודל כמה פעמים כדי לייצב תשובה; כאן מריצים מודלים או אסטרטגיות שונות — מודל גדול מול קטן, פרומפט אחד מול אחר, tool chain אחת מול חלופה — ובוחרים לפי איזה קריטריון מגיע ראשון או מדורג הכי גבוה.

שלוש תבניות נפוצות של הרצה ספקולטיבית

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

• Race-to-first — מריצים מודל מהיר וזול ומודל איטי ויקר במקביל, ומחזירים למשתמש את הראשון שמסיים ועובר סף איכות בסיסי. אם הזול לא הגיע לסף — ממתינים ליקר. מוריד latency ב-p50 בלי לפגוע ב-p99.
• Diversity voting — מריצים כמה אסטרטגיות שונות (לא רק מודלים שונים, גם prompts שונים או סדר כלים שונה) ובוחרים בתשובה שמסכימה עם הכי הרבה מסלולים אחרים, בדומה ל-self-consistency אבל על אסטרטגיות מגוונות ולא עותקים זהים.
• Fallback מקדים — מריצים מסלול זול ברקע תוך כדי שהמסלול היקר עדיין רץ, כדי שאם היקר נכשל (timeout, rate limit, שגיאת API) יש כבר תשובה חלופית מוכנה בלי להמתין לכשל ואז להתחיל retry מאפס.

הדפוס השלישי חופף חלקית לתחום ה-Model Failover Architecture, אבל ההבדל המהותי הוא שב-failover קלאסי המסלול החלופי מופעל רק אחרי כשל, ואילו בהרצה ספקולטיבית הוא כבר רץ מראש, מה שחוסך את זמן ה-detection של הכשל.

בחירת התבנית הנכונה תלויה בפרופיל התעבורה. Race-to-first הכי מתאים למוצרים מול משתמש קצה שרגישים ל-latency נתפס — צ'אט חי, חיפוש, השלמת טקסט. Diversity voting מתאים למשימות שבהן טעות עולה ביוקר ואין לחץ latency קיצוני, כמו סיווג מסמכים משפטיים או ניתוח פיננסי. Fallback מקדים מתאים בעיקר לתשתיות עם SLA קשיח שבהן זמינות חשובה יותר מעלות שולית, כמו מערכות תמיכה בשעות שיא. שילוב של יותר מתבנית אחת באותה מערכת — למשל race-to-first לשאלות פשוטות ו-diversity voting למשימות מורכבות — נפוץ בפועל ודורש שכבת ניתוב שמחליטה איזה מסלול ספקולטיבי להפעיל על כל בקשה, לא רק אם להפעיל אחד בכלל.

מנגנון הבחירה בין המנצחים

הרצה מקבילה בלי מנגנון בחירה מהיר וזול היא רק בזבוז כפול. הבחירה בין תשובות מועמדות חייבת להיות זולה משמעותית מיצירתן — אחרת מאבדים את כל היתרון. שלוש שיטות נפוצות: סף confidence שהמודל עצמו מדווח עליו (זול אבל לא תמיד אמין), Verifier Model ייעודי וקטן שמדרג תשובות מועמדות מול קריטריונים ברורים (יקר מעט יותר אבל אמין הרבה יותר), או כלל עסקי דטרמיניסטי כשהפלט מובנה (JSON שעובר validation סכימה, למשל). בפרויקטים רגישים — משפטי, רפואי, פיננסי — משתלם לשלב את שתי השיטות האחרונות יחד, כי המחיר של תשובה שגויה גבוה בהרבה מהעלות השולית של verifier נוסף.

מתי העלות הכפולה לא משתלמת

הרצה ספקולטיבית מכפילה עלות בפועל (פי 2 עד פי 3, תלוי במספר המסלולים), ולכן היא לא ברירת מחדל טובה לכל בקשה. היא משתלמת כשמתקיים לפחות אחד משני תנאים: latency קריטי (המשתמש מחכה בזמן אמת, ושבריר שנייה שווה יותר מהעלות הנוספת), או דיוק קריטי (טעות עולה יותר מהעלות הכפולה של הרצה נוספת). במשימות batch לא רגישות לזמן, עדיף בדרך כלל להשקיע את אותו תקציב ב-Dynamic Reasoning Budget גבוה יותר על מסלול יחיד, כי זה בדרך כלל משיג שיפור דיוק דומה בעלות נמוכה יותר מהרצה כפולה מלאה. שילוב נכון בין הכלים דורש להבין את הפרופיל של כל משימה — לא רק לזרוק compute נוסף בכל כיוון אפשרי.

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

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

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

תגיות: Speculative Execution · Race-to-First · Best-of-N · Model Failover · Model Economics

← חזרה לבלוג · צור קשר