פרומפט קאשינג (Prompt Caching) ב-OpenAI: איך מורידים את עלות הטוקנים כשכל קריאה שולחת את אותו הקשר

אם כל קריאה ל-API שולחת את אותה טקסונומיה ארוכה, הפתרון הוא לא להפסיק לשלוח אותה, אלא לשלוח אותה תמיד באותו מקום ובאותו נוסח: בתחילת הפרומפט, לפני כל דבר שמשתנה. כך OpenAI שומרת אותה במטמון (Prompt Caching), ובמודל GPT-6.1 Sol כל קריאה חוזרת שלה עולה 5% ממחיר הקלט הרגיל. כשהטקסונומיה גדולה מדי, או שכל שאלה צריכה רק חלק קטן ממנה, עוברים לשליפה (RAG) ושולחים רק את מה שרלוונטי.

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

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

בקצרה

קודם כול: איפה בכלל נוצרת העלות?

לפני שמשנים ארכיטקטורה, שווה לוודא שמשלמים לפי טוקן בכלל. לפי מרכז העזרה של OpenAI (נבדק ב-2026-10-13), ל-ChatGPT ולפלטפורמת ה-API יש מערכות חיוב נפרדות. GPT שרץ בתוך ChatGPT לא מייצר חשבונית לפי טוקן בפלטפורמת ה-API. העלות לפי טוקן נוצרת כשהקוד שלכם קורא ל-API, למשל שרת שמאחורי פעולה (Action) של ה-GPT, או מערכת שעובדת מחוץ ל-ChatGPT.

ועוד נקודה שמשפיעה על התכנון: OpenAI הודיעה שהיא מתכננת להוציא משימוש את ה-Custom GPTs וממליצה להעביר את התהליכים לפלאגינים (Plugins). לפי אותו עמוד (נבדק ב-2026-10-13), בסביבות Enterprise שמושפעות מהשינוי ההוצאה משימוש מתוכננת ל-11 בדצמבר 2026, והתאריכים עשויים להשתנות. מי שמתכנן מערכת לטווח ארוך, שיבנה את הלוגיקה היקרה בצד ה-API, ושם בדיוק נכנס הקאש. מה חדש במודלים עצמם ריכזתי בסיכום ההכרזות של OpenAI DevDay 2026.

איך פרומפט קאשינג (Prompt Caching) עובד ב-OpenAI

OpenAI שומרת את החישוב של תחילת הפרומפט, ואם הקריאה הבאה מתחילה בדיוק באותו טקסט, היא לא מחשבת אותו שוב. לפי מדריך ה-Prompt Caching הרשמי (נבדק ב-2026-10-13), המנגנון פועל כברירת מחדל במודלים הנתמכים, ויכול להוריד את עלות הקלט בעד 95% ולקצר את הזמן עד הטוקן הראשון.

אלה הכללים שחשוב להכיר:

• התאמת תחילית מלאה. כל מה שלפני נקודת השבירה (breakpoint) חייב להיות זהה. שינוי של תו אחד מוקדם בפרומפט מבטל את השימוש החוזר בכל מה שאחריו.
• מינימום אורך. ב-GPT-5.6 ומעלה, התחילית צריכה לפחות 1,024 טוקנים גלויים.
• מה נכנס לקאש: הוראות, הודעות מפתח, הגדרות כלים, והיסטוריית שיחה עם טקסט, תמונות ומסמכים.
• משך חיים. ב-GPT-5.6 ומעלה, תחילית נשארת זמינה לפחות 30 דקות מהשימוש או מהכתיבה האחרונים. אין אפשרות לנקות קאש ידנית.
• מגבלות קצב. טוקנים מהקאש עדיין נספרים במגבלת הטוקנים לדקה.

המחירים של GPT-6.1 Sol

לפי עמוד המחירים של OpenAI (נבדק ב-2026-10-13), במחירי Standard ובהקשר של עד 272 אלף טוקנים:

במודלים מ-GPT-5.6 ומעלה הכתיבה עולה פי 1.25 מקלט רגיל, והקריאה עולה עשירית ממנו. GPT-6.1 Sol הוא החריג הנדיב: הקריאה בו עולה 5% בלבד. במודלים מוקדמים יותר אין תוספת על הכתיבה, ושיעור ההנחה משתנה לפי המודל. השוואה מלאה של המודל מול Astra נמצאת במדריך ל-GPT-6.1 Sol.

כמה זה חוסך: חישוב לדוגמה

זה חישוב להמחשה, לא מקרה של לקוח. נניח טקסונומיה של 20,000 טוקנים שנשלחת בכל קריאה ל-GPT-6.1 Sol, באלף קריאות:

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

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

1. מסדרים את הפרומפט מהקבוע למשתנה. קודם הוראות המערכת, אחר כך הטקסונומיה, אחר כך הגדרות הכלים, ורק בסוף השאלה של המשתמש. כל מה שמשתנה (תאריך, שם לקוח, מזהה שיחה) יורד לסוף.
2. מקפיאים את הנוסח. הטקסונומיה נטענת מקובץ אחד עם גרסה, באותו סדר ובאותו פורמט. סידור מחדש של שדות JSON או רווח נוסף שובר את ההתאמה.
3. מסמנים נקודת שבירה מפורשת אחרי הטקסונומיה. במודלים מ-GPT-5.6 ומעלה, במצב ברירת המחדל נקודת השבירה נקבעת בסוף ההודעה האחרונה, ולכן גם החלק המשתנה עלול להיכתב לקאש במחיר הכתיבה. במצב מפורש אתם קובעים בדיוק איפה הקאש נגמר:

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "prompt_cache_key": "taxonomy_v3:customer_123",
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "הוראות קבועות + הטקסונומיה המלאה, גרסה 3",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "השאלה של המשתמש" }
  ]
}

4. משתמשים ב-prompt_cache_key. ב-GPT-5.6 ומעלה הוא משמש להפרדת חשבונאות הקאש לפי לקוח, משתמש או סביבת עבודה, ועוזר למנוע ניסיונות לגשש מה נמצא בקאש של אחרים. במודלים מוקדמים יותר הוא משפר את הניתוב, והתיעוד ממליץ על כ-15 בקשות לדקה לכל מפתח.
5. מחממים מראש כשיש צורך. הגדרת "prewarm": true בתוך prompt_cache_options מכינה את הקאש בלי לייצר פלט. הכתיבה הזו מחויבת במחיר כתיבה רגיל, ולכן היא שווה רק כשברור שתגיע תנועה.
6. מודדים. בכל תשובה חוזרים השדות usage.input_tokens_details.cached_tokens ו-cache_write_tokens. אם cached_tokens נשאר אפס, משהו בתחילית משתנה.

למה Files API לא פתר את הבעיה

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

גם כלי File Search לא חינמי. לפי עמוד המחירים (נבדק ב-2026-10-13), הוא עולה 2.50 דולר לכל אלף קריאות לכלי, ואחסון וקטורי עולה 0.10 דולר לג'יגה ליום, עם ג'יגה ראשון בחינם. לפי מדריך File Search, הגבלת מספר התוצאות (max_num_results) מקטינה את השימוש בטוקנים ואת זמן התגובה, במחיר אפשרי באיכות.

מתי לעבור לשליפה (RAG) במקום לשלוח הכול

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

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

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

עוד שלוש דרכים להוריד את החשבון

• לכווץ את הטקסונומיה עצמה. השואל ציין שהיא "חוזרת על עצמה". מזהים קצרים במקום שמות מלאים, הסרת כפילויות ופורמט טבלה במקום JSON מפורט מקטינים את התחילית עוד לפני הקאש.
• Batch למה שלא דחוף. לפי עמוד המחירים, ב-Batch קלט של GPT-6.1 Sol עולה 1 דולר ופלט 5 דולר למיליון טוקנים, כמחצית ממחיר Standard. מתאים לסיווג לילי של אלפי רשומות.
• Flex. באותו עמוד, ב-Flex קלט של GPT-6.1 Sol עולה 1 דולר, קלט מהקאש 0.05 דולר ופלט 5 דולר. ובכיוון ההפוך, מי ששוקל את Ultrafast ישלם פי שישה ממחיר Standard, כפי שפירטתי במדריך ל-OpenAI Ultrafast.

טעויות שמאפסות את הקאש

• תאריך או שעה בהוראות המערכת. הטעות הנפוצה ביותר. התאריך יורד לסוף הפרומפט.
• שם המשתמש בשורה הראשונה. "שלום דנה, את עוזרת..." הופך כל משתמש לקאש נפרד.
• הסרת כלים בין קריאות. התיעוד ממליץ להשאיר את הגדרות הכלים יציבות ולהשתמש ב-tool_choice: "none" או ב-allowed_tools במקום למחוק כלים.
• סיכום או קיצור של היסטוריית השיחה. כל כתיבה מחדש של ההיסטוריה מאפסת את השימוש החוזר. מוסיפים הודעות, לא משכתבים.
• עדכון קטן בטקסונומיה באמצע היום. כל גרסה חדשה מתחילה קאש מאפס. מרכזים עדכונים לחלון אחד.

שורה תחתונה

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

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

רוצים להכיר לעומק את GPT-6.1 Sol ואת Ultrafast לפני שבוחרים מודל למערכת? יש קורס אינטראקטיבי ב-9.90 שקלים: GPT-6.1 Sol ו-Ultrafast 2026, המודלים החדשים של OpenAI למפתחים ולעסקים.

מקורות

• OpenAI: מדריך Prompt Caching (נבדק ב-2026-10-13)
• OpenAI: עמוד המחירים של ה-API (נבדק ב-2026-10-13)
• OpenAI: מדריך File Search (נבדק ב-2026-10-13)
• מרכז העזרה של OpenAI: החיוב של ChatGPT ושל ה-API נפרד (נבדק ב-2026-10-13)
• מרכז העזרה של OpenAI: הוצאת Custom GPTs משימוש ומעבר לפלאגינים (נבדק ב-2026-10-13)