Amazon Bedrock ಈಗ Claude 4.6 ಗಾಗಿ prompt-caching ಅನ್ನು ನೀಡುತ್ತಿದೆ, ಇದು generative-AI ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಪ್ರತಿಕ್ರಿಯೆಯ ವಿಳಂಬವನ್ನು (latency) ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಇನ್ಫರೆನ್ಸ್ ವೆಚ್ಚವನ್ನು (inference spend) ತಗ್ಗಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಈ ಸಾಮರ್ಥ್ಯವು ಪ್ರಾಂಪ್ಟ್‌ನ ಸ್ಥಿರವಾದ (static) ಭಾಗವನ್ನು ಐದು ನಿಮಿಷಗಳವರೆಗೆ ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದರಿಂದ ಮುಂದಿನ ಕರೆಗಳು ಆ ಪಠ್ಯವನ್ನು ಮತ್ತೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ (re-processing) ದುಬಾರಿ ಕೆಲಸವನ್ನು ತಪ್ಪಿಸುತ್ತವೆ.

ರಿಕ್ವೆಸ್ಟ್ ಚೈನ್‌ನಲ್ಲಿ ಕ್ಯಾಶ್ ಹೇಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ

Claude 4.6 ರಿಕ್ವೆಸ್ಟ್ ಬಂದಾಗ, ಎರಡು ಪದರಗಳು ಸಹಕರಿಸುತ್ತವೆ.

  • Model level – Claude 4.6 ತನ್ನ GPU ಮೆಮೊರಿಯಲ್ಲಿ key-value (KV) ಕ್ಯಾಶ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಮೊದಲ ಬಾರಿಗೆ ಮಾಡೆಲ್ ಸೂಚನೆಗಳ ಬ್ಲಾಕ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಿದಾಗ, ಅದು ಅದರ ಆಂತರಿಕ ಪ್ರತಿನಿಧಿಯನ್ನು (internal representation) ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಅದೇ ಬ್ಲಾಕ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ನಂತರದ ಕರೆಗಳಲ್ಲಿ, ಮಾಡೆಲ್ ಅದನ್ನು ಮತ್ತೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಬದಲು ಆ ಪ್ರತಿನಿಧಿಯನ್ನು ಪಡೆಯಬಹುದು.

  • Bedrock level – Bedrock ಸ್ಥಿರ ಪ್ರಾಂಪ್ಟ್ ಸೆಗ್ಮೆಂಟ್‌ನ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತದೆ. ಹೊಸ ರಿಕ್ವೆಸ್ಟ್ ಹೊಂದಿಕೆಯಾಗುವ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, Bedrock ಅದನ್ನು ಈಗಾಗಲೇ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿರುವ GPU ಗೆ ನೇರವಾಗಿ ಕಳುಹಿಸುತ್ತದೆ, ಇದರಿಂದ “warm-up” ಹಂತವನ್ನು ತಪ್ಪಿಸಬಹುದು.

ಇದನ್ನು ಪ್ರತಿ ಬಾರಿಯೂ ಹೊಸದಾಗಿ ಪ್ರಾರಂಭಿಸುವ ಬದಲು, ಉಳಿತಾಯ ಮಾಡಲಾದ (saved) ಗೇಮ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿಕೊಳ್ಳುವಂತೆ ಭಾವಿಸಿ.

ಕ್ಯಾಶ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿರಿಸುವ ನಿಯಮಗಳು

  1. ಕನಿಷ್ಠ ಟೋಕನ್ ಸಂಖ್ಯೆ – Claude Sonnet 4.6 ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಸೆಗ್ಮೆಂಟ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ 1,024 ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿರಬೇಕು; Claude Opus 4.6 ಗೆ 4,096 ಟೋಕನ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಇದಕ್ಕಿಂತ ಕಡಿಮೆ ಇದ್ದರೆ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ.

  2. ಐದು ನಿಮಿಷಗಳ ಜೀವಿತಾವಧಿ – ಯಾವುದೇ ಚಟುವಟಿಕೆ ಇಲ್ಲದಿದ್ದರೆ ಐದು ನಿಮಿಷಗಳ ನಂತರ ಕ್ಯಾಶ್ ಅವಧಿ ಮುಗಿಯುತ್ತದೆ. ಪ್ರತಿ ಬಾರಿ ಕ್ಯಾಶ್ ಬಳಕೆಯಾದಾಗಲೂ ಟೈಮರ್ ಮರುಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ (reset), ಆದ್ದರಿಂದ ನಿರಂತರ ಕರೆಗಳ ಮೂಲಕ ಕ್ಯಾಶ್ ಅನ್ನು ಅನಿರ್ದಿಷ್ಟ ಕಾಲದವರೆಗೆ ಸಕ್ರಿಯವಾಗಿಡಬಹುದು.

  3. ಪ್ರಾಂಪ್ಟ್ ಕ್ರಮ (Prompt ordering) – Bedrock ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಅನುಕ್ರಮವಾಗಿ ಓದುತ್ತದೆ. ಸ್ಥಿರವಾದ ಸೂಚನೆಗಳು ಮೊದಲು ಬರಬೇಕು, ನಂತರ ಒಂದು cachePoint ಮಾರ್ಕರ್ ಇರಬೇಕು ಮತ್ತು ಆ ಮಾರ್ಕರ್ ನಂತರ ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಸೃಷ್ಟಿಸಿದ ಸಂದೇಶಗಳು ಇರಬೇಕು. ಮಾರ್ಕರ್ לפני ಕೇವಲ ಒಂದು ಅಕ್ಷರವನ್ನು ಬದಲಾಯಿಸಿದರೂ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ತಪ್ಪಾಗುತ್ತದೆ ಮತ್ತು ಅದು '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 ಬದಲಾಗದ (immutable) ಸೆಗ್ಮೆಂಟ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂದು Bedrock ಗೆ ತಿಳಿಸುತ್ತದೆ. ಮೊದಲ ಕರೆಯ ನಂತರ, cacheReadInputTokens ಮೆಟ್ರಿಕ್ ಶೂನ್ಯವಲ್ಲದ ಮೌಲ್ಯವನ್ನು ತೋರಿಸಬೇಕು, ಇದು ಕ್ಯಾಶ್ ಬಳಕೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಇದನ್ನು ಏಕೆ ಗಮನಿಸಬೇಕು

ಸ್ಥಿರ ಸೂಚನೆಗಳನ್ನು ಡೈನಾಮಿಕ್ ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದರಿಂದ, ಕೆಲಸವು ದುಬಾರಿ GPU ಸೈಕಲ್‌ಗಳಿಂದ ಹಗುರವಾದ ರೂಟಿಂಗ್ ಹಂತಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ. ಚಾಟ್‌ಬಾಟ್‌ಗಳು, retrieval-augmented generation (RAG) ಪೈಪ್‌ಲೈನ್‌ಗಳು ಅಥವಾ ಒಂದೇ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುವ ಯಾವುದೇ ಸೇವೆಗೆ, ಇದರ ಫಲಿತಾಂಶವೇ ವೇಗವಾದ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಮತ್ತು ಕಡಿಮೆ ಬಿಲ್ ಮಾಡಬಹುದಾದ ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು. ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ (high-throughput) ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ಕಂಪ್ಯೂಟ್ ಸಮಯದಲ್ಲಿನ ಸಣ್ಣ ಕಡಿತವೂ ಕೂಡ ಗಮನಾರ್ಹವಾದ ವೆಚ್ಚ ಉಳಿತಾಯಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.

ಮಿತಿಗಳು ಮತ್ತು ವಹಿವಾಟುಗಳು

ಪ್ರಾಂಪ್ಟ್ ಸೆಗ್ಮೆಂಟ್ ಕನಿಷ್ಠ ಟೋಕನ್ ಮಿತಿಗಳನ್ನು ತಲುಪಿದಾಗ ಮತ್ತು ಬದಲಾಗದೆ ಇದ್ದಾಗ ಮಾತ್ರ ಈ ಫೀಚರ್ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಸೂಚನೆಗಳನ್ನು ಪದೇ ಪದೇ ಬದಲಾಯಿಸುವ ಅಥವಾ ಚಿಕ್ಕ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದರಿಂದ ಹೆಚ್ಚಿನ ಪ್ರಯೋಜನವಾಗುವುದಿಲ್ಲ. ಐದು ನಿಮಿಷಗಳ ಕಾಲಾವಧಿಯ ಅಂದರೆ, ದೀರ್ಘ ವಿರಾಮಗಳಿರುವ ಅನಿರೀಕ್ಷಿತ ಟ್ರಾಫಿಕ್ (bursty traffic) ಪದೇ ಪದೇ 'cold reads' ಗೆ ಕಾರಣವಾಗಿ ವಿಳಂಬದ ಪ್ರಯೋಜನವನ್ನು ಕುಗ್ಗಿಸಬಹುದು. ಅಂತಿಮವಾಗಿ, ಕ್ಯಾಶ್ GPU ಮೆಮೊರಿಯಲ್ಲಿ ಇರುತ್ತದೆ; ಒಂದೇ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಹಲವಾರು ಮಾಡೆಲ್‌ಗಳು ಹಂಚಿಕೊಂಡರೆ, ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು, ಆದರೆ Bedrock ಆ ವಿವರಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

  • ಮೆಟ್ರಿಕ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು – ಕ್ಯಾಶ್ ಉದ್ದೇಶಿತವಾಗಿ ಬಳಕೆಯಾಗುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು cacheReadInputTokens ಮತ್ತು ಒಟ್ಟಾರೆ ವಿಳಂಬವನ್ನು (latency) ಗಮನಿಸುತ್ತಿರಿ.
  • ಪ್ರಾಂಪ್ಟ್ ಎಂಜಿನಿಯರಿಂಗ್ – ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಅತಿಯಾಗಿ ದೊಡ್ಡದು ಮಾಡದೆ, ಗಾತ್ರದ ಮಿತಿಗಳನ್ನು ಪೂರೈಸುವ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಒಂದು ಹೊಸ ಶಿಸ್ತಾಗಿದೆ.
  • ಭವಿಷ್ಯದ ವಿಸ್ತರಣೆಗಳು – Bedrock ಕ್ಯಾಶ್ ಅವಧಿಯನ್ನು ಹೆಚ್ಚಿಸಿದರೆ ಅಥವಾ ಟೋಕನ್ ಮಿತಿಗಳನ್ನು ಸಡಿಲಗೊಳಿಸಿದರೆ, ದೀರ್ಘಕಾಲದ ಸಂಭಾಷಣೆಗಳ ಆರ್ಥಿಕತೆ ಮತ್ತಷ್ಟು ಬದಲಾಗಬಹುದು.

ಸಾರಾಂಶ: ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ Claude 4.6 ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯ ಮತ್ತು ವೆಚ್ಚ ಎರಡನ್ನೂ ಕಡಿಮೆ ಮಾಡಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಅವರು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾದ ಮತ್ತು ಬದಲಾಗದ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತಾ, ಕರೆಗಳನ್ನು ಅಲ್ಪಾವಧಿಯ ಒಳಗಡೆ ಇರಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಒಂದೇ ಸಿಸ್ಟಮ್ ಸೂಚನೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವ ಯಾವುದೇ GenAI ಸೇವೆಗೆ, ಈ ಫೀಚರ್ ಅನ್ನು ಮೊದಲೇ ಪರೀಕ್ಷಿಸುವುದು ಉತ್ತಮ.