เจาะลึกเรื่อง Prompt caching แบบเข้าใจง่าย

กรณีศึกษาว่า Claude ทำ Cache Hit-Rate ได้ถึง 92% ได้อย่างไร

ทุกครั้งที่ AI agent ดำเนินการหนึ่งขั้นตอน มันจะต้องจ่ายภาษี

มันจะอ่านทุกอย่างใหม่ตั้งแต่ต้น

คำแนะนำระบบ (system instructions) นิยามเครื่องมือ (tool definitions) บริบทของโปรเจกต์ที่มันโหลดไปแล้วเมื่อสามรอบก่อน ทั้งหมดนั้น ทุกรอบ

นี่คือ "ภาษีบริบท" (context tax) และสำหรับเวิร์กโฟลว์ของ agent ที่ทำงานยาวนาน มันมักจะเป็นรายการที่แพงที่สุดในโครงสร้างพื้นฐาน AI ของคุณทั้งหมด

ลองคิดเลขดู: system prompt ขนาด 20,000 โทเค็นที่ทำงาน 50 รอบ หมายถึง การคำนวณที่ซ้ำซ้อน 1 ล้านโทเค็น ซึ่งถูกคิดเงินเต็มราคา โดยไม่ได้สร้างมูลค่าใหม่ใดๆ เลย

วิธีแก้คือ prompt caching แต่เพื่อใช้มันให้ดี คุณต้องเข้าใจว่าเบื้องหลังกำลังเกิดอะไรขึ้นจริงๆ

เริ่มจากสิ่งที่เปลี่ยนแปลงกับสิ่งที่ไม่เปลี่ยน

ก่อนที่คุณจะปรับให้เหมาะสมอะไรได้ คุณต้องคิดให้ชัดเจนเกี่ยวกับโครงสร้างของ prompt (บริบท) ของ agent

ทุกคำขอที่ agent ของคุณส่งออกไปมีสองส่วนที่แตกต่างกันโดยพื้นฐาน:

Static prefix (ส่วนนำที่คงที่): รวมถึงคำแนะนำระบบ, นิยามเครื่องมือ, บริบทของโปรเจกต์, แนวทางพฤติกรรม เนื้อหานี้เหมือนกันทุกประการในทุกรอบของเซสชัน

Dynamic tail (ส่วนท้ายที่เปลี่ยนแปลง): ข้อความจากผู้ใช้, ผลลัพธ์จากเครื่องมือ, การสังเกตจากเทอร์มินอล ส่วนนี้จะไม่ซ้ำกันในทุกคำขอและจะใหญ่ขึ้นเรื่อยๆ เมื่อการสนทนาดำเนินไป

ความแตกต่างนี้คือทุกสิ่ง Static prefix คือส่วนที่แพงซึ่งคุณคำนวณซ้ำโดยไม่มีเหตุผล Dynamic tail คือส่วนเดียวที่ต้องการการคำนวณใหม่จริงๆ

Prompt caching ทำงานโดยการจัดเก็บสถานะทางคณิตศาสตร์ของ static prefix เพื่อให้คำขอในอนาคตสามารถข้ามการคำนวณซ้ำทั้งหมดได้ คุณจ่ายเงินเพื่อประมวลผล prefix นั้นครั้งเดียว ทุกรอบถัดไปจะอ่านจากหน่วยความจำแทน

ทำไมถึงได้ผล: สิ่งที่ Transformer ทำจริงๆ

เพื่อให้เข้าใจจริงๆ ว่าทำไม caching ถึงมีประสิทธิภาพมาก คุณต้องเข้าใจสิ่งที่เกิดขึ้นภายในโมเดลเมื่อมันอ่าน prompt ของคุณ

ทุกคำขออินferenceของ LLM มีสองเฟส:

เฟส 1: Prefill

นี่คือขั้นตอนที่โมเดลประมวลผล input prompt ทั้งหมดของคุณ มันเป็น compute-bound หมายความว่ามันจะรัน dense matrix multiplications กับทุกโทเค็นในบริบทของคุณ โมเดลจะอ่านทุกอย่างและสร้างการแสดงผลของมันขึ้นมา นี่คือเฟสที่ช้าและแพง

เฟส 2: Decode

นี่คือขั้นตอนที่โมเดลสร้าง output tokens ทีละตัว มันเป็น memory-bound มากกว่า compute-bound เพราะโมเดลใช้เวลาส่วนใหญ่ไปกับการอ่านสถานะที่คำนวณไว้ก่อนหน้านี้ มากกว่าการคำนวณหนักๆ

ระหว่างเฟส prefill transformer จะสร้างเวกเตอร์สามตัวสำหรับแต่ละโทเค็น: Query, Key และ Value กลไก attention ใช้สิ่งเหล่านี้เพื่อหาว่าแต่ละโทเค็นเกี่ยวข้องกับโทเค็นอื่นๆ ในลำดับอย่างไร

นี่คือข้อมูลเชิงลึกที่สำคัญ: เวกเตอร์ Key และ Value ขึ้นอยู่กับโทเค็นที่อยู่ก่อนหน้าเท่านั้น เมื่อคำนวณแล้วสำหรับ prefix ที่กำหนด พวกมันจะไม่ต้องเปลี่ยนแปลงอีก

ภาพประกอบด้านล่างนี้อธิบายสิ่งที่เราเพิ่งพูดถึงด้วยภาพ:

หากไม่มี caching tensors ของ Key-Value เหล่านั้นจะถูกทิ้งไปทันทีที่คำขอเสร็จสิ้น คำขอถัดไปจะเริ่มจากศูนย์และคำนวณใหม่ทั้งหมดอีก 20,000 โทเค็น

KV caching แก้ปัญหานี้โดยการจัดเก็บ tensors เหล่านั้น โครงสร้างพื้นฐานจะเก็บมันไว้บนเซิร์ฟเวอร์อินference โดยจัดทำดัชนีด้วย cryptographic hash ของข้อความที่ป้อนเข้า เมื่อคำขอใหม่เข้ามาพร้อม prefix เดียวกัน hash จะตรงกัน tensors จะถูกเรียกค้นทันที และโมเดลจะข้ามการคำนวณทั้งหมดนั้น

ซึ่งจะลดความซับซ้อนในการคำนวณจาก O(n²) ต่อโทเค็นที่สร้างลงเหลือ O(n) สำหรับ prefix ขนาด 20,000 โทเค็นที่ทำซ้ำ 50 รอบ นั่นคือการลดลงอย่างมหาศาล

เรื่องเศรษฐศาสตร์

การทำความเข้าใจโครงสร้างราคาคือสิ่งที่ทำให้การตัดสินใจทางสถาปัตยกรรมนี้มีความสำคัญมาก

นี่คือวิธีที่ Anthropic กำหนดราคา caching ในกลุ่มโมเดลของพวกเขา:

สามตัวเลขที่ต้องจำขึ้นใจ:

Cache reads มีต้นทุน 10% ของราคา input พื้นฐาน ซึ่งเป็นส่วนลด 90% สำหรับทุกโทเค็นที่อ่านจาก cache
Cache writes มีต้นทุน แพงกว่าราคา input พื้นฐาน 25% ซึ่งเป็นค่าพรีเมียมเล็กน้อยในการจัดเก็บ KV tensors
Extended 1-hour caching มีต้นทุน 2 เท่าของราคาพื้นฐาน

คณิตศาสตร์จะใช้ได้ก็ต่อเมื่อ cache hit rate ของคุณยังคงสูง ซึ่งนำเราไปสู่ตัวอย่างจริงที่ดีที่สุดว่าสิ่งนั้นเป็นอย่างไรในทางปฏิบัติ

Claude Code: การเดินชมเซสชัน 30 นาที

Claude Code สร้างขึ้นโดยมีเป้าหมายเดียว: ทำให้ cache ยังร้อน (keep the cache hot)

เพื่อให้เข้าใจอย่างเป็นรูปธรรมว่าหมายถึงอะไร มาดูกันว่าเซสชันการเขียนโค้ดทั่วไป 30 นาทีเป็นอย่างไร และติดตามว่าสิ่งใดถูกคิดเงินและสิ่งใดไม่ถูกคิดเงิน

นาทีที่ 0: เริ่มเซสชัน

Claude Code โหลด system prompt และ tool definitions ของมัน นอกจากนี้ยังอ่านไฟล์ CLAUDE.md ใน root ของโปรเจกต์ของคุณ ซึ่งอธิบายโค้ดเบสและข้อปฏิบัติ เพย์โหลดนี้มักจะเกิน 20,000 โทเค็น

นี่คือช่วงเวลาที่แพงที่สุดของทั้งเซสชัน ทุกโทเค็นเป็นของใหม่ แต่คุณจ่ายต้นทุนนี้เพียงครั้งเดียวเท่านั้น

นาทีที่ 1 ถึง 5: คำสั่งแรก

คุณพิมพ์คำสั่งแรกของคุณ เช่น "ดูโมดูล auth และแนะนำการปรับปรุง"

Claude Code ส่ง Explore Subagent มันนำทางผ่านโค้ดเบส เปิดไฟล์ รันคำสั่ง grep และสร้างภาพของโค้ดที่เกี่ยวข้อง ทั้งหมดนี้จะถูกต่อท้ายไปที่ dynamic tail

รากฐาน static 20,000 โทเค็น? อยู่ใน cache แล้ว กำลังถูกอ่านกลับมาด้วยราคา $0.30/MTok แทนที่จะเป็น $3.00/MTok คุณจ่ายเฉพาะผลลัพธ์เครื่องมือใหม่และข้อความของคุณเท่านั้น

นาทีที่ 6 ถึง 15: งานเชิงลึก

Plan Subagent ได้รับข้อค้นพบจาก Explore Subagent แทนที่จะส่งผ่านผลลัพธ์ดิบแบบคำต่อคำ (ซึ่งจะทำให้ dynamic tail พองตัวโดยไม่จำเป็น) Claude Code ส่งสรุปที่กระชับ ซึ่งช่วยให้ suffix จัดการได้และ cache มีประสิทธิภาพ

นักวางแผนสร้างแผนการดำเนินงานที่มีโครงสร้าง คุณตรวจสอบ อนุมัติ และ Claude Code เริ่มทำการเปลี่ยนแปลง ทุกรอบในลูปนี้อ่าน prefix 20,000 โทเค็นจาก cache cache hit แต่ละครั้งจะรีเซ็ต TTL ทำให้ cache ยังอุ่นสำหรับรอบถัดไป

นาทีที่ 16 ถึง 25: การปรับเปลี่ยน

คุณขอให้ปรับเปลี่ยน Claude Code ปรับเปลี่ยนแนวทาง มีการเรียกใช้เครื่องมือมากขึ้น ผลลัพธ์เทอร์มินอลมากขึ้น dynamic tail กำลังเติบโต แต่มันแสดงเฉพาะเนื้อหาใหม่และไม่ซ้ำกันในเซสชันนี้

ณ จุดนี้ เซสชันได้ประมวลผลโทเค็นหลายแสนตัวแล้ว แต่รากฐาน 20,000 โทเค็นถูกอ่านจาก cache ทุกรอบ

นาทีที่ 28: รัน /cost

หากไม่มี caching เซสชันแบบนี้จะทะลุ 2 ล้านโทเค็นได้ง่ายๆ ในอัตราของ Sonnet 4.5 นั่นคือประมาณ $6.00

หากมี caching ที่ทำงานด้วยประสิทธิภาพสูง:

โทเค็นส่วนใหญ่อ่านจาก cache ในราคา $0.30/MTok
เฉพาะโทเค็น dynamic tail ใหม่เท่านั้นที่ถูกคำนวณสดใหม่

ในทางปฏิบัติ คุณคาดหวังได้ประมาณ การลดต้นทุน 80%+ สำหรับงานเดียว ทีนี้คูณด้วยผู้ใช้ทุกคน ทุกวัน

เพื่อสรุป นี่คือลักษณะเค้าโครง system prompt เมื่อเซสชันดำเนินต่อไป:

กฎที่ทำลายทุกอย่าง

นี่คือสิ่งที่ขัดกับสัญชาตญาณที่สุดเกี่ยวกับ prompt caching

1 + 2 = 3 แต่ 2 + 1 คือ cache miss

โครงสร้างพื้นฐานจะแฮช prompt แฮชคือตัวระบุสำหรับการเข้ารหัส แฮชจะเปลี่ยนไปถ้ามีอะไรในลำดับนั้นเปลี่ยนไป แม้ว่าจะมีเพียงสององค์ประกอบสลับลำดับกัน cache จะว่างเปล่า prefix ทั้งหมดจะถูกคำนวณใหม่ในราคาเต็ม

สามกฎที่ตามมาจากสิ่งนี้:

อย่าเพิ่มหรือลบเครื่องมือระหว่างเซสชัน prefix ที่แคชไว้รวมถึงเครื่องมือด้วย การเปลี่ยนเครื่องมือทำให้ทุกอย่างที่ตามมาใช้ไม่ได้
อย่าเปลี่ยนโมเดลระหว่างเซสชัน Cache เฉพาะกับโมเดล การเปลี่ยนไปใช้โมเดลที่ถูกกว่ากลางการสนทนาต้องสร้าง cache ทั้งหมดใหม่
อย่าเปลี่ยน prefix เพื่อเปลี่ยนสถานะ ให้ Claude Code เพิ่มแท็กในข้อความผู้ใช้ถัดไปเพื่อเตือนระบบแทน prefix จะไม่เปลี่ยนแปลงเลย

มันหมายถึงอะไรสำหรับคุณ

ทุกอย่างข้างต้นอธิบายว่า Claude Code จัดการ caching อย่างไร กฎเดียวกันนี้ใช้หากคุณกำลังสร้าง agent ของคุณเอง

นี่คือวิธีจัดโครงสร้าง prompt ของคุณ:

ด้านบนสุดคือคำแนะนำระบบและกฎ อย่าเปลี่ยนระหว่างกลาง
โหลดเครื่องมือทั้งหมดที่คุณจะต้องใช้ล่วงหน้า อย่าเพิ่มหรือเอามันออก
บริบทและเอกสารที่ดึงมา หลังจากนั้น คงที่ตลอดระยะเวลา
ด้านล่างสุดคือประวัติการสนทนาและผลลัพธ์ของเครื่องมือ

เมื่อเปิด auto-caching จุดแบ่ง (breakpoint) จะเลื่อนไปข้างหน้าโดยอัตโนมัติเมื่อการสนทนาดำเนินไป

Claude Code รับผิดชอบ cache ของตัวเอง Anthropic เพิ่ม auto-caching ใน API ของพวกเขาเมื่อเร็วๆ นี้ ดังนั้นคุณสามารถทำแบบเดียวกันสำหรับ agent ของคุณเองได้

หากไม่มี auto-caching คุณต้องจำว่าโทเค็นแบ่งเขตตรงไหน จุดแบ่งที่ผิดหมายถึงการไม่เข้าถึง cache

ใช้ cache-safe forking เพื่อทำให้กระชับสำหรับขีดจำกัดบริบท ใช้ system prompt, เครื่องมือ และการสนทนาเดียวกัน จากนั้นเพิ่มการทำให้กระชับเป็นข้อความใหม่

การเรียกการทำให้กระชับดูเกือบจะเหมือนกับครั้งที่แล้ว มีการใช้ cached prefix อีกครั้ง สิ่งเดียวที่ถูกคิดเงินเป็นของใหม่คือคำสั่งทำให้กระชับ

เพื่อดูว่า API ทำงานหรือไม่ ให้จับตาดูสามฟิลด์นี้ในทุกการตอบกลับ:

cache_creation_input_tokens⁣: โทเค็นที่ใส่ลงในหน่วยความจำ
cache_read_input_tokens⁣: โทเค็นที่อ่านจากหน่วยความจำ
input_tokens⁣: โทเค็นที่ทำงานตามปกติ

คะแนนประสิทธิภาพ cache ของคุณคือจำนวนโทเค็นที่อ่าน เทียบกับจำนวนโทเค็นที่สร้าง จับตาดูมันแบบเดียวกับที่คุณจับตาดู uptime

ข้อคิดสำคัญ

Prompt caching ไม่ใช่ฟีเจอร์ที่คุณเปิดใช้ มันคือวินัยทางสถาปัตยกรรมที่คุณสร้างรอบๆ

Claude Code เป็นตัวอย่างที่ดีที่สุดว่าสิ่งนั้นเป็นอย่างไรเมื่อทำในระดับใหญ่

Cache hit-rate 92% การลดต้นทุน 81%

นี่คือพิมพ์เขียวหากคุณกำลังสร้าง agent คุณไม่สามารถละเลยภาษีได้ มันมีอยู่จริง สิ่งเดียวที่สำคัญคือคุณกำลังจ่ายเพื่อมัน หรือกำลังกำจัดมันทิ้ง

เริ่มจากสิ่งที่เปลี่ยนแปลงกับสิ่งที่ไม่เปลี่ยน