Amazon Bedrock เปิดตัวฟีเจอร์ prompt-caching สำหรับ Claude 4.6 ซึ่งเป็นฟีเจอร์ที่สามารถช่วยลดความหน่วงในการตอบสนอง (latency) และลดค่าใช้จ่ายในการประมวลผล (inference) สำหรับแอปพลิเคชัน Generative AI ความสามารถนี้ทำงานโดยการจดจำส่วนที่คงที่ (static portion) ของ prompt ไว้ได้นานสูงสุดห้านาที ทำให้การเรียกใช้งานในครั้งต่อๆ ไปสามารถข้ามขั้นตอนการประมวลผลซ้ำที่มีค่าใช้จ่ายสูงได้

การทำงานของ cache ในลำดับการส่งคำขอ (request chain)

เมื่อมีการส่งคำขอไปยัง Claude 4.6 จะมีสองเลเยอร์ที่ทำงานร่วมกัน

  • ระดับโมเดล (Model level) – Claude 4.6 จะรักษา KV cache (key-value cache) ไว้ในหน่วยความจำ GPU เมื่อโมเดลประมวลผลชุดคำสั่ง (block of instructions) เป็นครั้งแรก มันจะจัดเก็บรูปแบบการแทนค่าภายใน (internal representation) ที่ได้ไว้ ในการเรียกใช้งานครั้งต่อๆ ไปที่มีการใช้ชุดคำสั่งเดิม โมเดลจะสามารถดึงรูปแบบการแทนค่านั้นมาใช้ได้ทันทีแทนที่จะต้องคำนวณใหม่

  • ระดับ Bedrock (Bedrock level) – Bedrock จะคำนวณ fingerprint ของส่วน prompt ที่คงที่ หากคำขอใหม่มี fingerprint ที่ตรงกัน Bedrock จะส่งคำขอนั้นไปยัง GPU ที่มีสถานะแคช (cached state) นั้นอยู่แล้วโดยตรง ซึ่งจะช่วยข้ามขั้นตอนการ "warm-up" ไปได้

เปรียบเสมือนการโหลดเกมที่บันทึกไว้ (saved game) แทนที่จะต้องเริ่มเล่นใหม่ทุกครั้ง

กฎเกณฑ์ในการรักษา cache ให้คงอยู่

  1. จำนวน token ขั้นต่ำ – Claude Sonnet 4.6 ต้องการอย่างน้อย 1,024 tokens ในส่วนที่ทำแคช ส่วน Claude Opus 4.6 ต้องการ 4,096 tokens หากมีจำนวนน้อยกว่านี้จะไม่มีการทำแคช

  2. อายุการใช้งานห้านาที – Cache จะหมดอายุหลังจากไม่มีการใช้งานเป็นเวลาห้านาที อย่างไรก็ตาม ทุกครั้งที่มีการเรียกใช้งาน (hit) จะเป็นการรีเซ็ตตัวจับเวลา ดังนั้นหากมีการเรียกใช้งานอย่างต่อเนื่อง ก็จะสามารถรักษา cache ให้คงอยู่ได้ตลอดไป

  3. ลำดับของ prompt – Bedrock จะอ่าน prompt ตามลำดับ ดังนั้นคำสั่งที่คงที่ (static instructions) จะต้องปรากฏขึ้นเป็นอันดับแรก ตามด้วยเครื่องหมาย 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) ที่ใช้ทรัพยากรน้อยกว่า สำหรับแชทบอท, ไปป์ไลน์ retrieval-augmented generation (RAG) หรือบริการใดๆ ที่มีการใช้ system prompt ซ้ำๆ ผลลัพธ์ที่ได้คือการตอบกลับที่เร็วขึ้นและจำนวน token ที่ถูกคิดค่าบริการลดลง ในสถานการณ์ที่มีปริมาณการใช้งานสูง แม้การลดเวลาประมวลผลเพียงเล็กน้อยก็สามารถเปลี่ยนเป็นความประหยัดด้านต้นทุนที่เห็นได้อย่างชัดเจน

ข้อจำกัดและสิ่งที่ต้องแลก (trade-offs)

ฟีเจอร์นี้จะช่วยได้ก็ต่อเมื่อส่วนของ prompt มีจำนวน token ถึงเกณฑ์ขั้นต่ำและไม่มีการเปลี่ยนแปลง แอปพลิเคชันที่มีการปรับเปลี่ยนคำสั่งระบบ (system instructions) บ่อยครั้ง หรือแอปพลิเคชันที่ใช้ prompt สั้นๆ จะได้รับประโยชน์น้อยมาก นอกจากนี้ ช่วงเวลาห้านาทีหมายความว่าหากทราฟฟิกมาเป็นช่วงๆ (bursty) และมีช่วงว่างที่ไม่มีการใช้งานนานๆ อาจทำให้เกิดการทำ cold read ซ้ำๆ ซึ่งจะทำให้ข้อได้เปรียบด้านความหน่วงลดลง สุดท้ายนี้ cache จะถูกเก็บไว้ในหน่วยความจำ GPU หากมีโมเดลหลายตัวใช้งานฮาร์ดแวร์เดียวกัน การแย่งชิงทรัพยากร (contention) อาจส่งผลต่อประสิทธิภาพได้ แม้ว่า Bedrock จะไม่ได้เปิดเผยรายละเอียดในส่วนนี้ก็ตาม

สิ่งที่ควรติดตามต่อไป

  • แดชบอร์ดเมทริกซ์ (Metric dashboards) – คอยตรวจสอบ cacheReadInputTokens และความหน่วงโดยรวม เพื่อยืนยันว่าแคชถูกใช้งานตามที่ตั้งใจไว้
  • Prompt engineering – การออกแบบ prompt ให้มีขนาดถึงเกณฑ์ที่กำหนดโดยไม่ทำให้คำขอบวมจนเกินไป กลายเป็นทักษะใหม่ที่นักพัฒนาต้องเรียนรู้
  • การขยายความสามารถในอนาคต – หาก Bedrock ขยายระยะเวลาการเก็บแคชหรือผ่อนปรนขีดจำกัดของ token ความคุ้มค่าทางเศรษฐศาสตร์ของการสนทนาที่ยาวต่อเนื่องอาจเปลี่ยนแปลงไปอีกระดับ

สรุปสาระสำคัญ: Prompt caching มอบเครื่องมือที่เป็นรูปธรรมให้แก่ผู้ใช้ Claude 4.6 ในการลดทั้งเวลาตอบสนองและค่าใช้จ่าย หากพวกเขาสามารถกำหนด prompt ที่มีขนาดใหญ่เพียงพอและไม่เปลี่ยนแปลง รวมถึงรักษาการเรียกใช้งานให้อยู่ภายในช่วงเวลาที่กำหนด สำหรับบริการ GenAI ใดๆ ที่มีการใช้คำสั่งระบบซ้ำๆ ฟีเจอร์นี้คุ้มค่าที่จะทดสอบตั้งแต่เนิ่นๆ