קאשינג ב-Amazon Bedrock חותך עלויות רק אם יש לכם תעבורה

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

המטמון הזה אינו קסם.

הנחה עם אותיות קטנות

ההבטחה השיווקית נשמעת מפתה: קיצוץ של עד 90 אחוזים בעלות טוקני הקלט וקיצור בזמן ההמתנה לטוקן הראשון (TTFT). המנגנון שומר את מצב החישוב הפנימי (KV cache) של תחיליות טקסט זהות, וחוסך חישוב חוזר במעבדים הגרפיים. לפי החברה, אם תיקחו חוזה בן 10,000 טוקנים ותריצו מולו 50 שאלות של משתמשים שונים, תשלמו על 500,000 טוקנים במחיר מלא בלי זיכרון מטמון. כדי להתמודד עם עלויות כאלה, מפתחים נאלצו עד היום לקצר הנחיות, להקטין חלונות הקשר או לבנות מטמון ברמת האפליקציה, שלא תמיד עוזר כששואלים שאלות שונות על אותו מסמך.

אלא שלפי מחירון Bedrock, השמירה הראשונית במטמון עולה כסף. על טוקנים שנכתבים למטמון מסוג cacheWriteInputTokens משלמים פרמיה של 25 אחוז יותר ממחיר קלט רגיל כבר בקריאה הראשונה. אם תרצו לשמור את המטמון לשעה שלמה במקום ברירת המחדל, תוספת העלות של הכתיבה מזנקת ל-100 אחוז, מחיר כפול עבור טוקני הכתיבה. ברירת המחדל של זמן החיים (TTL) עומדת על 5 דקות בלבד. החשבון פשוט: נדרשות לפחות שתי פניות עוקבות בתוך אותו חלון זמן כדי לכסות את תוספת הכתיבה ולהתחיל להרוויח. אם יש לכם קריאה בודדת שחוזרת פעם ברבע שעה, המנגנון מייקר את החשבון ב-25 אחוזים בכל פעם מחדש.

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

כל פנייה מאחרת היא קנס.

ספי טוקנים לפי מודל

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

Cache checkpoints have a minimum and maximum number of tokens, depending on the model. You can only create a cache checkpoint if your total prompt prefix meets the minimum number of tokens.דוקומנטציית Bedrock הרשמית

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

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

ארבעה צעדים להטמעה בקוד

ההטמעה ב-Converse API מתבצעת באמצעות מבנה נתונים אחיד. לפי הדוקומנטציה, התחביר של cachePoint זהה בין מודלים שונים כמו Anthropic Claude ו-Amazon Nova. כדי שהמודל יידע היכן לחתוך בין החלק הסטטי לחלק המשתנה, מגדירים בלוק מפורש של נקודת מטמון ברצף התוכן. המודל בודק אם התוכן שקדם לנקודה זו תואם לערך קיים במטמון, ומדלג על חישוב מחדש כשיש התאמה מושלמת.

לפני תחילת העבודה יש לוודא שיש לכם גישה למודל המבוקש. בדוקומנטציה על אישור גישה למודלים ב-Bedrock מצוין כי גישה למודלים של צד שלישי דורשת הרשאות ב-AWS Marketplace. עבור מודלים של Anthropic יש למלא טופס הצהרת שימוש (FTU) עם קישור לאתר או לפרופיל GitHub לפני ביצוע הקריאה הראשונה, אחרת הבקשה תיחסם בשגיאת הרשאה.

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

שינוי קטן הורס הכל.

מלכודת הניתוב הגלובלי

השימוש במודלים מתקדמים נעשה לרוב דרך פרופילי ניתוב אזוריים כמו Cross-Region Inference כדי להתגבר על מגבלות מכסה וזמינות. בדוגמאות הרשמיות של AWS משתמשים במזהה מודל גלובלי כמו global.anthropic.claude-sonnet-4-5-20250929-v1:0 באזור us-west-2. כאן מסתתר מוקש: המטמון מתוחם ברמת החשבון הבודד והאזור הגיאוגרפי הספציפי. הבקשות מנותבות אוטומטית בין מרכזי נתונים לפי עומסים, וזה עלול להקפיץ את תדירות כתיבת המטמון.

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

בישראל המצב מורגש במיוחד, משום שבאזור המקומי (il-central-1) המודלים הללו אינם מופעלים ישירות לפי דף הזמינות האזורית ב-Bedrock. מפתחים בארץ מנתבים בקשות לאזורים מעבר לים, מה שמגביר את החשיפה לתנודות הניתוב הללו. כאשר כל קריאה טסה לאירופה או לארצות הברית, ההסתמכות על ניתוב דינמי הופכת לנקודת תורפה שיכולה לרוקן את המטמון.

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

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

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

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

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

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

מה קורה אם הקידומת שלי מכילה פחות טוקנים מסף המינימום של המודל?

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

האם ה-TTL מתאפס בכל פעם שיש Cache Hit?

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

כמה בדיוק עולה שמירה במטמון לחלון של שעה במקום 5 דקות?

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

מדוע השימוש ב-Cross-Region Inference Profile עלול לפגוע בשיעור הפגיעה במטמון?

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

מקורות

1. Optimizing cost and latency with Amazon Bedrock prompt cachingaws.amazon.com · המקור
2. Amazon Bedrock Pricingaws.amazon.com · מחירים
3. Prompt caching for faster model inference - Amazon Bedrockdocs.aws.amazon.com · דוקומנטציה
4. Request access to models - Amazon Bedrockdocs.aws.amazon.com · דוקומנטציה
5. Model support by AWS Region in Amazon Bedrock - Amazon Bedrockdocs.aws.amazon.com · דוקומנטציה
6. Amazon Bedrock prompt caching pricingaws.amazon.com · מקושר מההודעה

איך בדקנו

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