ค่าใช้จ่าย AI ของคุณเพิ่มขึ้นเป็นสามเท่าเพียงชั่วข้ามคืน ทั้งที่โมเดล ปริมาณทราฟฟิก หรือแม้แต่ข้อความใน Prompt ก็ยังเหมือนเดิม สาเหตุมาจากโค้ดเพียงบรรทัดเดียวที่ไปทำลายระบบ Prompt cache ของ OpenAI

ทำไม Prompt cache ถึงสำคัญ

Prompt cache ของผู้ให้บริการช่วยให้คุณประหยัดเงินได้โดยการข้ามขั้นตอนการประมวลผลซ้ำสำหรับคำขอ (request) ใดๆ ที่เริ่มต้นด้วย prefix ที่เหมือนกันทุกไบต์ (byte-for-byte identical) หาก token แรกๆ ตรงกับคำขอที่เคยเรียกใช้ก่อนหน้า ผู้ให้บริการจะนำการประมวลผลของ token เหล่านั้นที่คำนวณไว้แล้วมาใช้ใหม่ และคิดเงินเฉพาะส่วน suffix ใหม่เท่านั้น กฎนี้เข้มงวดมาก: การจับคู่ต้องแม่นยำ ไม่ใช่แค่คล้ายกัน หากมี token ต่างกันเพียงตัวเดียวที่ส่วนต้น จะทำให้การทำ cache hit ล้มเหลวทั้งหมด

ข้อผิดพลาดที่ทำให้ Hit rate พังทลาย

ใน Agent ของเรา เราได้ใส่ timestamp ปัจจุบันไว้ที่ส่วนบนสุดของ system prompt เพื่อให้โมเดลรับรู้ถึง "เวลาปัจจุบัน" เนื่องจาก timestamp เปลี่ยนแปลงทุกวินาที ลำดับของ token แรกจึงไม่ซ้ำกันเลยในแต่ละ request ทำให้ cache ไม่สามารถหาจุดที่ตรงกันได้เลย ส่งผลให้การเรียกแต่ละครั้งต้องจ่ายราคาเต็มสำหรับ 18,000 static tokens ที่ตามมา ไม่ว่าจะเป็น tool schemas, ตัวอย่างเอกสาร (documentation snippets), few-shot examples และคำสั่งคงที่ (fixed instructions) ผลลัพธ์ที่ได้คือ cache hit rate เป็น 0% และค่าใช้จ่ายพุ่งสูงขึ้นถึงสามเท่า

การจัดลำดับใหม่เพื่อให้ทำ Cache ได้

วิธีแก้ไขนั้นง่ายมาก: ให้เก็บทุกอย่างที่ไม่เปลี่ยนแปลงไว้ที่ส่วนหน้าของ prompt และดันข้อมูลที่มีการเปลี่ยนแปลงตลอดเวลา (volatile data) ไปไว้ด้านหลัง

Static prefix (ทำ cache ได้)

  • Tool definitions
  • Retrieval documents
  • Few-shot examples
  • Fixed system instructions

Volatile suffix (ทำ cache ไม่ได้)

  • Current time
  • Session identifiers
  • User messages
  • Live context

หากโมเดลจำเป็นต้องทราบเวลา ให้ต่อท้าย (append) ไว้หลัง block ของข้อมูล static แทนที่จะใส่ไว้ข้างหน้า (prepend) วิธีนี้จะทำให้ cache สามารถนำส่วนที่เป็น static ขนาดใหญ่มาใช้ซ้ำได้ ในขณะที่คุณยังคงส่ง context ใหม่ล่าสุดไว้ที่ส่วนท้าย

ตัวการร้ายที่ซ่อนอยู่ใน Stack

แม้ว่า template จะดูถูกต้องแล้ว แต่ middleware หรือ SDKs อาจแอบใส่ metadata ไว้ข้างหน้าอย่างเงียบๆ เช่น request IDs, timestamps หรือ header อื่นๆ ก่อนที่ payload จะส่งไปถึง API นอกจากนี้ deployment pipelines บางอย่างอาจมีการสลับลำดับ tool definitions ในทุกครั้งที่มีการ rollout การเปลี่ยนแปลงที่มองไม่เห็นเหล่านี้จะเปลี่ยนลำดับของไบต์และทำลายระบบ cache โดยที่คุณไม่ได้แก้ไขโค้ดในส่วน prompt builder ของคุณเลย

คอยเฝ้าดู Cache hit rate

ให้ถือว่า cache hit rate เป็นตัวชี้วัดสุขภาพหลัก (primary health metric) สำหรับ AI agent ใดๆ ก็ตาม หากค่านี้ลดลงอย่างกะทันหัน แสดงว่ามีบางอย่างในไบต์ส่วนหน้าของ request ที่เริ่มมีความผันแปร เครื่องมือ monitoring ที่แสดงเปอร์เซ็นต์การ hit จะช่วยให้คุณตรวจพบความผิดปกติของค่าใช้จ่ายก่อนที่มันจะบานปลาย

บทสรุป

การทำ prompt caching ขึ้นอยู่กับ prefix ที่ไม่เปลี่ยนแปลง (immutable prefix) อะไรก็ตามที่เปลี่ยนไป—แม้แต่ timestamp เพียงตัวเดียว—ที่ส่วนต้นของทุก request จะทำให้ cache ไร้ผลและอาจทำให้ค่าใช้จ่ายของคุณเพิ่มขึ้นเป็นสามเท่า จงเก็บเนื้อหาที่เป็น static ไว้ก่อน เนื้อหาที่ผันผวนไว้หลังสุด ตรวจสอบ toolchain ของคุณว่ามีการแอบใส่ข้อมูลข้างหน้าหรือไม่ และคอยเฝ้าดู cache hit rate การจัดวาง prompt อย่างมีระเบียบจะช่วยปกป้องทั้งประสิทธิภาพและต้นทุนของคุณ