Amazon Bedrock מציעה כעת prompt-caching עבור Claude 4.6, תכונה שיכולה לקצר את זמן התגובה (latency) ולהפחית את עלויות ה-inference עבור יישומי AI גנרטיבי. היכולת פועלת על ידי שמירת חלק סטטי מה-prompt למשך עד חמש דקות, כך שקריאות עוקבות מדלגות על העיבוד מחדש והיקר של הטקסט הזה.

כיצד המטמון (cache) משתלב בשרשרת הבקשות

כאשר מגיעה בקשה ל-Claude 4.6, שתי שכבות משתפות פעולה.

  • ברמת המודל – Claude 4.6 שומר מטמון key-value (KV) בזיכרון ה-GPU. בפעם הראשונה שהמודל מנתח בלוק של הוראות, הוא שומר את הייצוג הפנימי שנוצר. בקריאות מאוחרות יותר המשתמשות באותו בלוק, המודל יכול לשלוף את הייצוג במקום לחשב אותו מחדש.

  • ברמת Bedrock – Bedrock מחשבת fingerprint של קטע ה-prompt הסטטי. אם בקשה חדשה נושאת fingerprint תואם, Bedrock מפנה אותה ישירות ל-GPU שכבר מחזיק את המצב המטמון, ובכך מדלגת על שלב ה-"warm-up".

חשבו על זה כעל טעינת משחק שמור במקום להתחיל משחק חדש בכל פעם.

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

  1. מינימום מספר טוקנים – Claude Sonnet 4.6 דורש לפחות 1,024 טוקנים בקטע המטמון; Claude Opus 4.6 זקוק ל-4,096 טוקנים. כל דבר קטן יותר נתעלם ממנו.

  2. תקופת תוקף של חמש דקות – המטמון פוקע לאחר חמש דקות של חוסר פעילות. כל פגיעה (hit) במטמון מאפסת את הטיימר, כך שזרם קבוע של קריאות יכול לשמור על המטמון פעיל ללא הגבלת זמן.

  3. סדר ה-prompt – Bedrock קוראת את ה-prompt באופן רציף. ההוראות הסטטיות חייבות להופיע ראשונות, ולאחריהן מגיע סימון cachePoint, כשכל ההודעות שנוצרו על ידי המשתמש מופיעות אחרי הסימון הזה. שינוי אפילו תו אחד לפני הסימון שובר את ה-fingerprint ומאלץ קריאה קרה (cold read).

יישום התכונה בפועל

ה-Bedrock Converse API הוא נקודת הכניסה. להלן קטע קוד Python מינימלי המדגים את המבנה הנדרש.

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"

# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."

system_configuration = [
    {"text": BASE_SYSTEM_PROMPT},
    {"cachePoint": {"type": "default"}}
]

conversation_history = []

def run_chat_turn(user_input):
    global conversation_history
    conversation_history.append(
        {"role": "user", "content": [{"text": user_input}]}
    )

    response = bedrock.converse(
        modelId=MODEL_ID,
        system=system_configuration,
        messages=conversation_history,
        inferenceConfig={"maxTokens": 500, "temperature": 0.4}
    )

    assistant_message = response["output"]["message"]
    conversation_history.append(assistant_message)

    metrics = response["usage"]
    print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")

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

למה למפתחים כדאי לשים לב

הפרדה בין הוראות סטטיות לבין קלט משתמש דינמי מעבירה את העבודה ממחזורי GPU יקרים לשלב ניתוב (routing) קל משקל. עבור צ'אטבוטים, תהליכי RAG (retrieval-augmented generation), או כל שירות שחוזר על אותו system prompt, התוצאה היא תגובות מהירות יותר ומספר טוקנים נמוך יותר לחיוב. בתרחישים של תפוקה גבוהה (high-throughput), אפילו הפחתה מתונה בזמן החישוב יכולה לתרגם לחסכון ניכר בעלויות.

מגבלות ופשרות (trade-offs)

התכונה עוזרת רק כאשר קטע ה-prompt עומד במינימום הטוקנים ונשאר ללא שינוי. אפליקציות שמשנות לעיתים קרובות הוראות מערכת, או כאלו המסתמכות על prompts קצרים, יראו תועלת מועטה. חלון חמש הדקות משמעותו גם שתעבורה מקוטעת (bursty traffic) עם הפסקות ארוכות של חוסר פעילות עלולה לגרום שוב ושוב לקריאות קרות (cold reads), מה שישחק את יתרון השיהוי (latency). לבסוף, המטמון חי בזיכרון ה-GPU; אם מודלים מרובים חולקים את אותה חומרה, עומס (contention) עלול להשפיע על הביצועים, אם כי Bedrock אינה חושפת את הפרטים הללו.

מה כדאי לעקוב אחריו בהמשך

  • לוחות בקרה של מדדים (Metric dashboards) – עקבו אחר cacheReadInputTokens והשיהוי (latency) הכולל כדי לוודא שהמטמון בשימוש כמצופה.
  • Prompt engineering – תכנון prompts שעומדים בספי ה-size מבלי לנפח את הבקשה הוא תחום חדש עבור מפתחים.
  • הרחבות עתידיות – אם Bedrock תרחיב את משך זמן המטמון או תקל על מגבלות הטוקנים, הכלכליות של שיחות ארוכות עשויה להשתנות עוד יותר.

שורה תחתונה: prompt caching מעניק למשתמשי Claude 4.6 כלי מוחשי לצמצום הן זמן התגובה והן ההוצאות, בתנאי שהם יכולים לנעול prompt גדול מספיק ובלתי משתנה ולשמור על הקריאות בתוך חלון זמן קצר. עבור כל שירות GenAI שחוזר על אותן הוראות מערכת, כדאי לבדוק את התכונה בשלב מוקדם.