ก่อน token แรกของคำตอบจะออกมา โมเดลต้องทำงานหนักก้อนหนึ่ง นั่นคืออ่าน input ทั้งหมดแล้วคำนวณ key-value pairs ของทุก token ในทุก layer ของ transformer เพื่อเก็บข้อมูลว่าคำแต่ละคำสัมพันธ์กันอย่างไร และ context ตรงไหนสำคัญ งานช่วงนี้เรียกว่า prefill ซึ่งกินทั้งเวลาและเงิน

prompt caching ลดงานตรงนี้ด้วยการเก็บ KV pairs ที่คำนวณเสร็จแล้วไว้ใช้ต่อ ถ้า prompt ในการเรียกครั้งถัดไปขึ้นต้นด้วยเนื้อหาชุดเดิม โมเดลก็นำค่าที่เก็บไว้มาใช้แทนการคำนวณใหม่ จึงลดทั้ง latency และ cost ได้โดยไม่ต้องเปลี่ยนโมเดล

cache ที่คุ้นกันอีกแบบคือเก็บคำตอบที่เสร็จแล้วไว้ พอเจอคำถามเดิมเป๊ะก็ส่งคำตอบเดิมกลับไปโดยไม่เรียกโมเดล แต่ prompt caching เป็นคนละกลไก เพราะทำงานเฉพาะฝั่ง input โมเดลยังคิดคำตอบใหม่ทุกครั้ง เพียงแค่ไม่ต้องอ่าน prompt ส่วนเดิมใหม่ทั้งก้อน

cache hit หรือ miss ดูที่ token แรกที่ต่างกัน

ระบบใช้ prefix matching จับคู่ prompt ใหม่กับก้อนที่เก็บไว้ โดยไล่เทียบทีละ token ตั้งแต่ตัวแรก ตรงกันถึงจุดไหนก็นำ KV pairs ชุดเดิมมาใช้ได้ถึงจุดนั้น แต่เมื่อเจอ token แรกที่ต่างออกไป ส่วนที่เหลือตั้งแต่ตรงนั้นจนจบ prompt จะกลับไปคำนวณตามปกติ

cache จะช่วยได้มากน้อยแค่ไหนจึงขึ้นอยู่กับลำดับที่โค้ดฝั่งเรานำส่วนต่างๆ มาประกอบเป็น prompt โดยตรง ถ้าวางคำถามของผู้ใช้ไว้บนสุด token ก็จะต่างกันตั้งแต่แรก โมเดลจึงต้องคำนวณใหม่ทั้งก้อน ราวกับไม่มี cache

วางส่วนที่ไม่เปลี่ยนไว้หน้าสุด

ถ้าจะให้ prefix ยังตรงกันเมื่อเรียกหลายครั้ง ต้องเรียงจากส่วนที่ไม่ค่อยเปลี่ยนไปหาส่วนที่เปลี่ยนทุกครั้ง เริ่มจาก system instructions ตามด้วยเอกสารหรือ context ก้อนใหญ่ ต่อด้วย few-shot examples แล้วจึงปิดท้ายด้วยคำถามของผู้ใช้

ส่วนที่คุ้มกับการย้ายมาไว้ด้านหน้ามีอยู่ไม่กี่อย่าง

• เอกสารอ้างอิงก้อนใหญ่ ที่โยนเข้า context window เช่น คู่มือสินค้า งานวิจัย หรือสัญญา
• system prompt ที่รวมทั้งกติกาและบุคลิกของ chatbot ซึ่งคลิปจากช่อง IBM Technology บอกว่าเป็นเคสที่พบบ่อยที่สุด
• few-shot examples ชุดตัวอย่างที่แนบไปเหมือนเดิมทุกครั้ง
• tool/function definitions ที่ agent ต้องส่งไปพร้อมทุก call
• conversation history ที่ต่อยาวขึ้นเรื่อยๆ ตามรอบสนทนา

ตัวอย่างที่เห็นภาพคือ chatbot ตอบคำถามเกี่ยวกับสินค้า โดยประกอบ prompt จาก system instructions คู่มือ 20 หน้า และ few-shot examples ตามลำดับ ก่อนปิดท้ายด้วยคำถามเรื่องเงื่อนไขการรับประกัน เมื่อคำถามถัดมาเปลี่ยนเป็นนโยบายคืนสินค้า token ในส่วนหน้าทั้งหมดยังเหมือนเดิม ระบบจึงใช้ cache ต่อได้จนจบส่วน few-shot โมเดลจึงต้องคำนวณจริงเพียงคำถามใหม่ประโยคเดียว

เคสไหนที่ยังไม่ต้องลงแรง

อย่างแรกที่ควรดูคือขนาดของ prompt ถ้ายังไม่ถึงราว 1,024 tokens ค่าจัดการ cache ก็จะกินส่วนที่ประหยัดได้จนหมด งานที่จะเห็นผลจริงจึงเป็นงานที่ต้องส่ง context ก้อนใหญ่ไปด้วยทุกครั้ง

ถัดมาคืออายุของ cache ปกติระบบจะล้างข้อมูลภายใน 5 ถึง 10 นาทีเพื่อไม่ให้ข้อมูลเก่าค้างอยู่ ขณะที่บางแห่งยืดอายุได้ถึง 24 ชั่วโมง ถ้าแต่ละ call ของงานเราทิ้งช่วงกันเป็นชั่วโมง cache ที่หวังว่าจะช่วยประหยัดก็อาจถูกล้างก่อนทุกครั้ง

สุดท้ายต้องดูเงื่อนไขของ provider บางรายเปิด prompt caching ให้อัตโนมัติเมื่อ prompt เข้าเกณฑ์ ส่วนบางรายต้องระบุใน API call เองว่าจะให้ cache ตรงไหน คลิปเดียวกันบอกไว้เพียงว่ามีทั้งสองแบบ แต่ไม่ได้บอกว่า provider รายไหนใช้แบบไหน จึงต้องเปิดเอกสารของ provider ที่ใช้อยู่เช็กเอง

สิ่งที่ทำได้ทันทีคือย้ายคำถามของผู้ใช้ไปไว้ท้าย prompt และวางส่วนที่ไม่เปลี่ยนไว้หน้าสุด เพราะถ้าลำดับยังสลับกัน ต่อให้ provider รองรับ prompt caching เต็มที่ cache ก็จะ miss ตั้งแต่ token แรก

---

ที่มา: คลิป What is Prompt Caching? Optimize LLM Latency with AI Transformers จากช่อง IBM Technology