Amazon Bedrock ਹੁਣ Claude 4.6 ਲਈ prompt-caching ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਇੱਕ ਅਜਿਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਜੋ generative-AI ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਲੇਟੈਂਸੀ (latency) ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਇਨਫਰੈਂਸ (inference) ਖਰਚੇ ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ। ਇਹ ਸਮਰੱਥਾ ਇੱਕ ਪ੍ਰੋਂਪਟ ਦੇ ਸਥਿਰ ਹਿੱਸੇ ਨੂੰ ਪੰਜ ਮਿੰਟ ਤੱਕ ਯਾਦ ਰੱਖ ਕੇ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਅਗਲੇ ਕਾਲਾਂ ਉਸ ਟੈਕਸਟ ਦੀ ਮਹਿੰਗੀ ਮੁੜ-ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਛੱਡ ਸਕਣ।
ਕੈਸ਼ (cache) ਰਿਕੁਐਸਟ ਚੇਨ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ
ਜਦੋਂ Claude 4.6 ਦੀ ਰਿਕੁਐਸਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਦੋ ਪਰਤਾਂ (layers) ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
Model level – Claude 4.6 GPU ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ key-value (KV) ਕੈਸ਼ ਬਣਾਈ ਰੱਖਦਾ ਹੈ। ਪਹਿਲੀ ਵਾਰ ਜਦੋਂ ਮਾਡਲ ਹਦਾਇਤਾਂ ਦੇ ਇੱਕ ਬਲਾਕ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਨਤੀਜੇ ਦੇ ਅੰਦਰੂਨੀ ਪ੍ਰਤੀਨਿਧਤਾ (internal representation) ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਬਾਅਦ ਦੀਆਂ ਕਾਲਾਂ ਵਿੱਚ, ਜੋ ਉਸੇ ਬਲਾਕ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਮਾਡਲ ਉਸ ਨੂੰ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰਨ ਦੀ ਬਜਾਏ ਉਸ ਪ੍ਰਤੀਨਿਧਤਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।
Bedrock level – Bedrock ਸਥਿਰ ਪ੍ਰੋਂਪਟ ਸੈਗਮੈਂਟ ਦਾ ਇੱਕ ਫਿੰਗਰਪ੍ਰਿੰਟ (fingerprint) ਕੰਪਿਊਟ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਨਵੀਂ ਰਿਕੁਐਸ ਮੈਚਿੰਗ ਫਿੰਗਰਪ੍ਰਿੰਟ ਲਿਆਉਂਦੀ ਹੈ, ਤਾਂ Bedrock ਇਸ ਨੂੰ ਸਿੱਧਾ ਉਸ GPU ਵੱਲ ਭੇਜ ਦਿੰਦਾ ਹੈ ਜਿਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੈਸ਼ ਕੀਤੀ ਹੋਈ ਸਟੇਟ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ “warm-up” ਸਟੇਜ ਨੂੰ ਬਚਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸ ਨੂੰ ਹਰ ਵਾਰ ਨਵਾਂ ਗੇਮ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਸੇਵ ਕੀਤੀ ਹੋਈ ਗੇਮ ਲੋਡ ਕਰਨ ਵਾਂਗ ਸਮਝੋ।
ਨਿਯਮ ਜੋ ਕੈਸ਼ ਨੂੰ ਜਿਉਂਦਾ ਰੱਖਦੇ ਹਨ
Minimum token count – Claude Sonnet 4.6 ਨੂੰ ਕੈਸ਼ ਕੀਤੇ ਸੈਗਮੈਂਟ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 1,024 ਟੋਕਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ; Claude Opus 4.6 ਨੂੰ 4,096 ਟੋਕਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਛੋਟਾ ਕੁਝ ਵੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
Five-minute lifetime – ਗੈਰ-ਹਰਕਤ (inactivity) ਦੇ ਪੰਜ ਮਿੰਟ ਬਾਅਦ ਕੈਸ਼ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਹਰ ਹਿੱਟ (hit) ਟਾਈਮਰ ਨੂੰ ਰੀਸੈੱਟ ਕਰ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਕਾਲਾਂ ਦੀ ਇੱਕ ਲਗਾਤਾਰ ਲੜੀ ਕੈਸ਼ ਨੂੰ ਅਨੰਤ ਕਾਲਾਂ ਤੱਕ ਜਿਉਂਦਾ ਰੱਖ ਸਕਦੀ ਹੈ।
Prompt ordering – Bedrock ਪ੍ਰੋਂਪਟ ਨੂੰ ਕ੍ਰਮਵਾਰ (sequentially) ਪੜ੍ਹਦਾ ਹੈ। ਸਥਿਰ ਹਦਾਇਤਾਂ ਪਹਿਲਾਂ ਆਉਂਦੀਆਂ ਹੋੜੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਉਸ ਤੋਂ ਬਾਅਦ ਇੱਕ
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 Bedrock ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਅਟੱਲ (immutable) ਸੈਗਮੈਂਟ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਪਹਿਲੀ ਕਾਲ ਤੋਂ ਬਾਅਦ, cacheReadInputTokens ਮੈਟ੍ਰਿਕ ਨੂੰ ਇੱਕ ਗੈਰ-ਜ਼ੀਰੋ (non-zero) ਮੁੱਲ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ।
ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਸ ਦੀ ਚਿੰਤਾ ਕਿਉਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ
ਸਥਿਰ ਹਦਾਇਤਾਂ ਨੂੰ ਡਾਇਨਾਮਿਕ ਯੂਜ਼ਰ ਇਨਪੁਟ ਤੋਂ ਵੱਖ ਕਰਨਾ ਕੰਮ ਨੂੰ ਮਹਿੰਗੇ GPU ਸਾਈਕਲ ਤੋਂ ਹਲਕੇ ਰੂਟਿੰਗ ਸਟੈਪ ਵੱਲ ਸਵਿਚ ਕਰ ਦਿੰਦਾ ਹੈ। ਚੈਟਬੋਟਸ, ਰਿਟ੍ਰੀਵਲ-ਔਗਮੈਂਟਡ ਜਨਰੇਸ਼ਨ (RAG) ਪਾਈਪਲਾਈਨਾਂ, ਜਾਂ ਕਿਸੇ ਵੀ ਸੇਵਾ ਲਈ ਜੋ ਇੱਕੋ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਇਸ ਦਾ ਨਤੀਜਾ ਤੇਜ਼ ਜਵਾਬ ਅਤੇ ਘੱਟ ਬਿਲਯੇਬਲ ਟੋਕਨ ਗਿਣਤੀ ਹੈ। ਉੱਚ-ਥਰਪਾਊਟ (high-throughput) ਸਥਿਤੀਆਂ ਵਿੱਚ, ਕੰਪਿਊਟ ਸਮੇਂ ਵਿੱਚ ਮਾਮੂਲੀ ਕਮੀ ਵੀ ਮਹੱਤਵਪੂਰਨ ਲਾਗਤ ਬਚਤ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ।
ਸੀਮਾਵਾਂ ਅਤੇ ਸਮਝੌਤੇ (trade-offs)
ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਉਦੋਂ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਪ੍ਰੋਂਪਟ ਸੈਗਮੈਂਟ ਟੋਕਨ ਦੀ ਘੱਟੋ-ਘੱਟ ਗਿਣਤੀ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਬਿਨਾਂ ਬਦਲੇ ਰਹਿੰਦਾ ਹੈ। ਉਹ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜੋ ਅਕਸਰ ਸਿਸਟਮ ਹਦਾਇਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਕਰਦੀਆਂ ਹਨ, ਜਾਂ ਜੋ ਛੋਟੇ ਪ੍ਰੋਂਪਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਬਹੁਤ ਘੱਟ ਲਾਭ ਮਿਲੇਗਾ। ਪੰਜ ਮਿੰਟ ਦੀ ਵਿੰਡੋ ਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਲੰਬੇ ਆਈਡਲ ਗੈਪ ਵਾਲੇ ਬਰਸਟੀ ਟ੍ਰੈਫਿਕ (bursty traffic) ਦੇ ਕਾਰਨ ਵਾਰ-ਵਾਰ "cold reads" ਹੋ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਲੇਟੈਂਸੀ ਦਾ ਫਾਇਦਾ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਅੰਤ ਵਿੱਚ, ਕੈਸ਼ GPU ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ; ਜੇਕਰ ਕਈ ਮਾਡਲ ਇੱਕੋ ਹਾਰਡਵੇਅਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਟਕਰਾਅ (contention) ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਹਾਲਾਂਕਿ Bedrock ਉਹ ਵੇਰਵੇ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦਾ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- Metric dashboards – ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਉਮੀਦ ਅਨੁਸਾਰ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ,
cacheReadInputTokensਅਤੇ ਸਮੁੱਚੀ ਲੇਟੈਂਸੀ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। - Prompt engineering – ਅਜਿਹੇ ਪ੍ਰੋਂਪਟ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਜੋ ਰਿਕੁਐਸ ਨੂੰ ਵਧਾਏ ਬਿਨਾਂ ਆਕਾਰ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ, ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਨਵਾਂ ਅਨੁਸ਼ਾਸਨ ਹੈ।
- Future extensions – ਜੇਕਰ Bedrock ਕੈਸ਼ ਦੀ ਮਿਆਦ ਵਧਾਉਂਦਾ ਹੈ ਜਾਂ ਟੋਕਨ ਸੀਮਾਵਾਂ ਨੂੰ ਢਿੱਲਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਗੱਲਬਾਤਾਂ ਦਾ ਅਰਥ ਸ਼ਾਸਤਰ ਹੋਰ ਬਦਲ ਸਕਦਾ ਹੈ।
Takeaway: ਪ੍ਰੋਂਪਟ ਕੈਸ਼ਿੰਗ Claude 4.6 ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਮੇਂ ਅਤੇ ਖਰਚੇ ਦੋਵਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਇੱਕ ਠੋਸ ਸਾਧਨ ਦਿੰਦੀ ਹੈ, ਬਸ਼ਰਤੇ ਉਹ ਇੱਕ ਕਾਫੀ ਵੱਡਾ, ਅਟੱਲ ਪ੍ਰੋਂਪਟ ਲਾਕ ਕਰ ਸਕਣ ਅਤੇ ਕਾਲਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਰੱਖ ਸਕਣ। ਕਿਸੇ ਵੀ GenAI ਸੇਵਾ ਲਈ ਜੋ ਇੱਕੋ ਸਿਸਟਮ ਹਦਾਇਤਾਂ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਜਲਦੀ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੈ।