קאשינג ב-Bedrock יכול לחתוך 90 אחוז מעלויות הסוכן

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

זה בדיוק מה שקורה כשאין זיכרון.

לפי מדריך התבניות שפרסמה AWS, שימוש נכון במנגנון שנקרא Prompt Caching עבור מודלי OpenAI מעל Bedrock חותך את המחיר בעד 90 אחוז ומקצר את זמני התגובה. מודלי השפה לא שומרים זיכרון פנימי בין הבקשות השונות שלכם, ולכן ללא תכנון נכון אתם סופגים חיוב כפול ומשולש על אותם נתונים סטטיים בדיוק. בסוף המדריך הזה תדעו בדיוק איך להגדיר את המטמון בלולאת הריצה שלכם, איך לעבור את סף המינימום הדרוש ואיך להימנע מפספוסי מטמון שקטים שיעלו לכם ביוקר.

סוכנים חיים ביום המרמיטה

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

התשלום מגיע על כל טוקן שנשלח שוב ושוב.

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

מפורש, סמוי, והשילוב ביניהם

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

שילוב של שתי הגישות מעניק נקודת התחלה הניתנת לשימוש חוזר, בעוד ש-Bedrock מנהלת את השיחה הגדלה באופן אוטומטי.AWS

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

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

הכללים לשמירה על המטמון

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

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

כדי שהתשתית תדע לשייך את המטמון בין בקשות שונות, יש להקפיד על מבנה עקבי של מפתח prompt_cache_key. המפתח צריך להכיל את סוג הסוכן, גרסת ההוראות ושם המודל, למשל support-agent:v7:gpt-6-astra. שינוי בהוראות המערכת מצריך קידום גרסה במפתח כדי למנוע דריסת מצב קיים ושימוש בטקסט שאינו תואם להוראות העדכניות. ניהול נכון של המפתחות מונע התנגשויות בין סוכנים בעלי תפקידים שונים שפועלים במקביל באותו חשבון ענן.

הטמעה בלולאת הריצה

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

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

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

המלכודת הישראלית של הניתוב

כאן מגיעה הנקודה שבה התאוריה פוגשת את המציאות המקומית. מודלי OpenAI בתוך Amazon Bedrock זמינים באזור תל אביב (il-central-1) באמצעות פרופילי Cross-Region inference (פרופיל Global), כפי שמופיע ברשימת התאימות האזורית של Bedrock. המשמעות היא שכל ארגון ישראלי שמריץ את המודלים האלה מעל התשתית של AWS נעזר במנגנוני ניתוב מרובי אזורים (Cross-Region). המצב הזה יוצר מורכבות תפעולית שלא קיימת כאשר מריצים שירותים מקומיים סטנדרטיים.

הניתוב הזה מייצר שתי בעיות קריטיות. הראשונה היא ש-Prompt Caching תלוי בזיכרון של אשכול שרתים פיזי ספציפי. אם פרופיל הניתוב של AWS מעביר בקשה אחת בתוך הלולאה לאזור us-east-1 ואת הבקשה העוקבת לאזור us-west-2, המטמון לא יהיה קיים באזור היעד ותחטפו Cache Miss מיידי במחיר מלא. השנייה נוגעת לרגולציה: ארגונים ביטחוניים, מוסדות פיננסיים וגופים הכפופים לפרויקט נימבוס נדרשים לעמוד במגבלות רגולטוריות וסיווגי מידע מחמירים לפני אישור הוצאת מידע לאזורי ענן מחוץ לישראל.

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

שאלות ותשובות

מה שואלים על זה

מה קורה אם רשימת הכלים וההוראות שלי קצרה מ-1,024 טוקנים?

המערכת תתעלם מהבקשה לשמירה במטמון ותחייב אתכם במחיר קלט מלא על כל הבקשה.

למה משמש הפרמטר prompt_cache_key?

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

האם המטמון נשמר אם הבקשה הבאה שלי נותבה לאזור גיאוגרפי (Region) אחר?

לא בהכרח. ניתובי Cross-Region עשויים לגרום לפספוס מטמון (Cache Miss) אם הבקשה נוחתת באשכול שבו המצב המעובד לא קיים.

האם חובה לשמור את טוקני החשיבה (Reasoning Tokens) של OpenAI בהיסטוריה?

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

מקורות

1. Groundhog Day for AI agents: Prompt caching patterns for using OpenAI models on Amazon Bedaws.amazon.com · המקור
2. current lookup rulesdevelopers.openai.com · מקושר מההודעה
3. Supported models by AWS Region in Amazon Bedrockdocs.aws.amazon.com · מקושר מההודעה

איך בדקנו

30 עובדות בכתבה נבדקו אחת־אחת מול המקורות המקושרים ומול חיפוש ברשת ב־26 באוקטובר 2026. מה שלא אומת הוסר או מסומן כטענה של החברה. הכתיבה נעשתה בעזרת AI מהמקורות האלה בלבד, בעריכה ובאחריות של סלבה מלנדוביץ׳. טעות? כתבו לנו.