בפוסט שפורסם על ידי דניאל אביב (Daniel Abib), ארכיטקט פתרונות מומחה לתחום ה-Generative AI ב-AWS, מוסבר כיצד שימוש במנגנון ה-Prompt Caching ב-Amazon Bedrock מאפשר להפחית את עלויות טוקני הקלט בעד 90 אחוזים כאשר שולחים שוב ושוב את אותו הקשר למודלי תשתית, וכן לצמצם את זמן התגובה לטוקן הראשון (TTFT). לפי הפוסט, ללא שמירה במטמון, שליחת חוזה באורך 10,000 טוקנים יחד עם 50 שאלות שונות מביאה לחיוב של 500,000 טוקני קלט במחיר מלא עבור תוכן שהמודל כבר עיבד.
המחבר מציין כי דרכים חלופיות להתמודדות עם עלויות כוללות קיצור פרומפטים (שעלול לפגוע באיכות ההקשר), הקטנת חלונות הקשר (הפוגעת ביכולת המודל להסיק מסקנות ממידע מלא), ושמירת תשובות במטמון (Response Caching), אשר אינה מועילה כאשר אותו הקשר משמש לשאלות שונות. שמירת פרומפטים ברמת התשתית מאפשרת למודל לקרוא טוקנים שמורים במקום לעבד אותם מחדש, מבלי לשנות את המודל או את איכות הפרומפט.
כיצד פועל מנגנון ה-Prompt Caching ותמחורו
כאשר בקשה ל-Converse API כוללת סמן מסוג cachePoint, שירות Amazon Bedrock בודק האם התוכן שקודם לסמן תואם לרשומת מטמון קיימת. במקרה של פגיעה במטמון (cache hit), המודל מדלג על עיבוד מחדש ומתחיל ביצירת הפלט ממצב שמור. במקרה של החמצה (cache miss), המודל מעבד את מלוא התוכן וכותב את התוצאה למטמון עבור בקשות עתידיות.
ארבעה עקרונות מגדירים את התנהגות המטמון:
- היקף המטמון (Cache scope): הרשומות מוגבלות לחשבון AWS ולאזור (AWS Region) ספציפיים.
- ספי טוקנים מינימליים: כל נקודת בדיקה חייבת לעמוד בסף מינימלי להפעלת המטמון. למשל, Anthropic Claude Sonnet 4.5 ו-Sonnet 4.6 דורשים לפחות 1,024 טוקנים לנקודת בדיקה, בעוד מודלי Opus דורשים לפחות 4,096 טוקנים.
- זמן חיים (TTL): רשומות פגות לפי ה-TTL המוגדר בבקשה. ברירת המחדל היא 5 דקות, כאשר מודלים מסוימים תומכים בעד שעה אחת.
- תחביר בלתי תלוי במודל: תחביר ה-cachePoint ב-Converse API זהה בכל משפחות המודלים הנתמכות, כולל Anthropic Claude ו-Amazon Nova.
מבחינת תמחור, נוספות שתי קטגוריות טוקנים:
- cacheWriteInputTokens: טוקנים שנכתבים למטמון בבקשה הראשונה, בעלות הגבוהה ב-25 אחוזים מטוקן קלט רגיל. בעת שימוש ב-TTL של שעה אחת, העלות גבוהה ב-100 אחוזים (פי שניים) מקלט רגיל.
- cacheReadInputTokens: טוקנים שנקראים מהמטמון בבקשות עוקבות, בעלות הנמוכה ב-90 אחוזים מטוקן קלט רגיל.
עבור עומסי עבודה עם הקשר חוזר, החיסכון הכולל בעלויות טוקני הקלט מגיע לכ-75 אחוזים (למשל, מסמך של 10,000 טוקנים עם 10 שאלות שונות בתוך חלון ה-TTL).
תרחישי שימוש ב-Converse API
הפוסט מציג שישה תרחישי יישום מעשיים בקוד Python באמצעות Converse API:
- שמירת תוכן הודעות ומסמכים ארוכים: הצבת סמן cachePoint לאחר תוכן המסמך הסטטי ולפני השאלה הדינמית. בתרחישי RAG או ניתוח קוד, שירות Amazon Bedrock שומר את המסמך במטמון בקריאה הראשונה ועשוי לעשות בו שימוש חוזר בקריאות עוקבות. במודלי Claude נתמך ניהול מטמון מפושט שבו סמן יחיד בודק התאמות עד כ-20 מקטעי תוכן קודמים.
- שמירת פרומפט מערכת (System Prompt): הגדרות אישיות, הנחיות מפורטות ומאגרי ידע המוטמעים בפרומפט המערכת נשמרים באמצעות הצבת cachePoint בתוך פרמטר ה-system, בנפרד מהודעות המשתמש.
- שמירת הגדרות כלים (Tool Definitions): ביישומים מבוססי סוכנים (Agentic workflows), סכמות JSON רבות של כלים עשויות לכלול אלפי טוקנים. הוספת cachePoint בסוף מערך הכלים ב-toolConfig מאפשרת שימוש חוזר ללא עיבוד מחדש בכל סיבוב שיחה.
- שילוב זמני חיים שונים (Mixed TTL): הקצאת זמני תפוגה שונים לשכבות תוכן שונות באותה בקשה — למשל שעה אחת לחומרי ייחוס והגדרות כלים, ו-5 דקות להקשר שיחה רגעי. הממשק מחייב סדר שבו זמני TTL ארוכים יותר מופיעים לפני זמני TTL קצרים יותר.
- בידוד דיירים במערכות Multi-Tenant: כדי למנוע קריאת מטמון בין דיירים שונים באותו חשבון ואזור AWS, מוצמדת תחילית גיבוב SHA-256 של מזהה הדייר לתוכן השמור. פעולה זו יוצרת רשומת מטמון נפרדת לכל דייר בתוספת תקורה של כ-16 טוקנים בלבד (64 תווים).
- אינטגרציה עם LangChain: שימוש במחלקה ChatBedrockConverse ובפונקציה create_cache_point ליצירת נקודות מטמון ישירות במבני הודעות או בתוך תבניות ChatPromptTemplate ושרשראות LCEL.
השוואה בין Converse API ל-InvokeModel API והמלצות יישום
המחבר משווה בין הממשקים ומציין כי בעוד שב-Converse API התחביר אחיד לכל המודלים, סמן המטמון מוצב כמקטע עצמאי ונתמך פירוט cacheDetails בתגובה, ב-InvokeModel API התחביר שונה עבור מודלי Anthropic (שימוש ב-cache_control מסוג ephemeral בתוך מקטע התוכן, ללא פירוט cacheDetails בתגובה). לכן מומלץ להשתמש ב-Converse API ביישומים חדשים.
לסיום, מומלץ לבצע פרופילינג לפרומפטים לזיהוי רכיבים סטטיים, לוודא עמידה בסף הטוקנים הנדרש בכל מודל, לבחור זמני TTL מתאימים, לנטר מדדי מטמון בלוגים, לשלב מנגנוני סינון ובקרה כמו Amazon Bedrock Guardrails, ולשלב שמירה בו-זמנית של הודעות, פרומפט מערכת והגדרות כלים באותה בקשה.