เปิด Prompt Caching ทุกจุดแล้ว ทำไมค่าใช้จ่ายบางเดือนกลับสูงขึ้น

ทีมพัฒนาที่เพิ่งเปิดใช้ Prompt Caching ครั้งแรกมักคาดหวังว่าบิลจะลดลงทันทีตั้งแต่เดือนแรก เพราะเอกสารของ Provider หลายเจ้าเขียนไว้ชัดว่าส่วนที่ Cache ได้จะคิดค่าบริการในอัตราที่ต่ำกว่าการประมวลผลใหม่มาก แต่พอเปิดใช้จริงกับทุก Endpoint โดยไม่ได้ดูโครงสร้าง Prompt ของแต่ละจุดก่อน บางทีมกลับพบว่าบิลเดือนถัดมาไม่ได้ลดลงอย่างที่คิด บางกรณีถึงกับสูงขึ้นเล็กน้อยด้วยซ้ำ

สาเหตุที่พบบ่อยไม่ใช่เพราะ Prompt Caching ใช้ไม่ได้ผล แต่เป็นเพราะกลไกเบื้องหลังของมันมีเงื่อนไขที่ทีมส่วนใหญ่ไม่รู้ เช่น Cache ทำงานได้ดีเฉพาะเมื่อส่วนต้นของ Prompt เหมือนกันเป๊ะระหว่าง Request หรือ TTL ของ Cache หมดอายุเร็วกว่าที่ทีมคาดไว้จนแทบไม่เคยได้ Cache Hit จริง

บทความนี้จะอธิบายว่า Prompt Caching ทำงานอย่างไรจริง ๆ เบื้องหลังฉาก จุดไหนที่ช่วยลดต้นทุนได้จริง และจุดไหนที่ทีมมักเข้าใจผิดจนเปิดใช้แล้วไม่ได้ผลลัพธ์ตามที่คาดหวัง

Prompt Caching คืออะไรกันแน่

Prompt Caching คือกลไกที่ Provider LLM เก็บผลการประมวลผลบางส่วนของ Prompt ไว้ชั่วคราว เพื่อนำมาใช้ซ้ำเมื่อมี Request ถัดไปที่มีส่วนต้นของ Prompt ตรงกันเป๊ะ โดยไม่ต้องประมวลผลส่วนนั้นใหม่ตั้งแต่ต้น ส่วนที่ Cache ได้บ่อยที่สุดคือ System Prompt ที่ยาวและไม่เปลี่ยนบ่อย หรือ Context เอกสารอ้างอิงที่ใช้ซ้ำในหลาย Request ติดต่อกัน

กลไกนี้ต่างจาก Cache ทั่วไปในระบบ Backend ตรงที่ Prompt Caching ทำงานที่ระดับ Token Processing ของโมเดล ไม่ใช่การเก็บคำตอบสำเร็จรูปไว้แล้วส่งกลับทันทีแบบ Response Cache ทั่วไป ดังนั้นแม้ Prompt ส่วนต้นจะ Cache ได้ แต่ผลลัพธ์สุดท้ายยังคงถูก Generate ใหม่ทุกครั้งตามส่วนที่เปลี่ยนแปลงของ Request นั้น

ข้อจำกัดสำคัญคือ Cache มักมีอายุจำกัด (TTL) และต้องการให้ส่วนต้นของ Prompt ตรงกันแบบตัวต่อตัว (Prefix Match) หากมีการเปลี่ยนแปลงแม้เพียงเล็กน้อยในส่วนต้น เช่น เพิ่ม Timestamp หรือ Random ID ไว้ต้น Prompt โดยไม่ตั้งใจ Cache นั้นจะใช้ไม่ได้ทันทีและต้องประมวลผลใหม่ทั้งหมด

กลไกเบื้องหลัง Cache Hit และ Cache Miss ทำงานอย่างไร

เมื่อระบบส่ง Request เข้าไป Provider จะตรวจสอบว่าส่วนต้นของ Prompt ตรงกับสิ่งที่เคย Cache ไว้หรือไม่ ถ้าตรงกัน (Cache Hit) ส่วนนั้นจะถูกดึงมาใช้ทันทีโดยไม่ต้องประมวลผลใหม่ ทำให้ทั้ง Latency และต้นทุนของส่วนนั้นลดลง แต่ถ้าไม่ตรงกันแม้เพียงส่วนเล็กน้อย (Cache Miss) ระบบจะต้องประมวลผล Prompt ทั้งก้อนใหม่ตั้งแต่ต้น เสมือนไม่มี Cache อยู่เลย

จุดที่หลายทีมมองข้ามคือการเขียน Cache ครั้งแรกก็มีต้นทุนของมันเอง บาง Provider คิดค่าบริการการเขียนเข้า Cache สูงกว่าปกติเล็กน้อยในครั้งแรกที่ Cache ยังไม่มี แล้วค่อยได้ราคาถูกกว่าตอน Cache Hit ในครั้งถัดไป ถ้าระบบมี Cache Miss บ่อยเพราะ TTL หมดอายุเร็วเกินไป ต้นทุนของการเขียน Cache ซ้ำ ๆ อาจสูงกว่าประโยชน์ที่ได้จาก Cache Hit ไม่กี่ครั้ง

อีกปัจจัยคือความถี่ของ Traffic ต่อ Endpoint นั้น ถ้า Endpoint มี Traffic เข้าห่าง ๆ จน Cache หมดอายุก่อนจะมี Request ถัดไปมาใช้ซ้ำ Cache นั้นแทบไม่มีประโยชน์เลย เพราะแทบไม่เคยได้ Cache Hit จริงในทางปฏิบัติ

กรณีไหนที่ Prompt Caching ลดต้นทุนได้จริงตามตัวเลขจริง

Prompt Caching ให้ผลชัดเจนที่สุดเมื่อระบบมี Traffic ต่อเนื่องเข้า Endpoint เดียวกันบ่อย และ System Prompt หรือ Context ส่วนต้นเหมือนกันทุกครั้ง เช่น Chatbot ที่มี System Prompt ยาวอธิบายบทบาทและกฎการตอบ ซึ่งเหมือนกันทุก Session ของผู้ใช้ทุกคน

ตารางด้านล่างเปรียบเทียบลักษณะการใช้งานที่เหมาะและไม่เหมาะกับ Prompt Caching เพื่อให้เห็นภาพก่อนตัดสินใจเปิดใช้ทุกจุดในระบบ

ทำไมเปิด Caching ทุกจุดแล้วบิลกลับไม่ลดหรือสูงขึ้น

สาเหตุหลักที่ทำให้บิลไม่ลดลงตามคาดคือทีมเปิด Caching กับทุก Endpoint โดยไม่แยกว่า Endpoint ไหนมีลักษณะ Traffic ที่เหมาะจริง Endpoint ที่มี Traffic เข้าห่าง ๆ หรือ Prompt เปลี่ยนแปลงบ่อยจะได้ Cache Miss เป็นส่วนใหญ่ ทำให้ต้องจ่ายค่าเขียน Cache ซ้ำ ๆ โดยแทบไม่เคยได้ประโยชน์จาก Cache Hit เลย

อีกสาเหตุที่พบบ่อยคือการออกแบบ Prompt ที่ใส่ข้อมูล Dynamic เช่น เวลาปัจจุบันหรือ Session ID ไว้ตอนต้นของ Prompt โดยไม่รู้ตัว ทำให้ส่วนต้นไม่เคยตรงกันระหว่าง Request เลย Cache จึงไม่เคย Hit แม้เนื้อหาส่วนใหญ่จะเหมือนเดิมก็ตาม เพราะกลไก Prefix Match ตรวจจากจุดเริ่มต้นของ Prompt เป็นหลัก

ตัวอย่างประกอบกรอบวิเคราะห์ (ไม่ใช่สถิติจริง): ทีมหนึ่งเปิด Caching กับ Endpoint ที่มี Traffic เข้าเฉลี่ยชั่วโมงละไม่กี่ครั้ง ขณะที่ TTL ของ Cache อยู่ที่ไม่กี่นาที ผลคือแทบทุก Request เป็น Cache Miss แต่ยังต้องจ่ายค่าเขียน Cache ทุกครั้ง สุดท้ายต้นทุนรวมของ Endpoint นั้นสูงกว่าตอนไม่เปิด Caching เล็กน้อย

ออกแบบ Prompt อย่างไรให้ได้ Cache Hit สูงจริง

• จัดโครงสร้าง Prompt ให้ส่วนที่ไม่เปลี่ยนแปลง (System Prompt, กฎการตอบ, ตัวอย่าง Few-shot) อยู่ต้น Prompt เสมอ และส่วน Dynamic อย่างคำถามของผู้ใช้อยู่ท้ายสุด
• หลีกเลี่ยงการใส่ Timestamp, Random ID หรือข้อมูลที่เปลี่ยนทุกครั้งไว้ตอนต้นของ Prompt แม้จะดูเป็นรายละเอียดเล็กน้อย
• รวม Context ที่ใช้ซ้ำบ่อยไว้เป็นก้อนเดียวกันตอนต้น แทนที่จะสลับลำดับการใส่ Context ในแต่ละ Request
• ตรวจสอบ TTL ของ Cache ที่ Provider กำหนด แล้วเทียบกับความถี่ Traffic จริงของแต่ละ Endpoint ก่อนตัดสินใจเปิดใช้
• ทดสอบด้วย Traffic จำลองก่อนเปิดใช้จริง เพื่อดูอัตรา Cache Hit จริงก่อนที่จะเชื่อว่าการออกแบบ Prompt นั้นเหมาะกับ Caching

Prompt Caching เทียบกับเทคนิคลดต้นทุนอื่นตรงไหน

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

สำหรับทีมที่ยังไม่แน่ใจว่าควรเริ่มลงทุนเรื่องต้นทุน AI จากจุดไหนก่อน ลองอ่านภาพรวมเพิ่มเติมที่ แนวทางตัดสินใจว่าเมื่อไรควรทำ AI Cost Optimization ซึ่งจัดลำดับความสำคัญของแต่ละเทคนิคไว้ตามความยากง่ายในการเริ่มทำ

อีกจุดที่เกี่ยวข้องกันคือ Model Routing เพราะบาง Endpoint ที่ Cache ได้ผลดีอยู่แล้วอาจไม่จำเป็นต้อง Route ไปโมเดลเล็กเพื่อลดต้นทุนเพิ่มอีก ในขณะที่ Endpoint ที่ Cache ไม่ได้ผลอาจต้องพึ่ง Model Routing แทน การพิจารณาสองเทคนิคนี้ควบคู่กันช่วยให้เห็นภาพรวมชัดกว่าดูแยกทีละเทคนิค

วัด Cache Hit Rate อย่างไรให้รู้ว่า Caching ได้ผลจริง

1. เก็บ Log ทุก Request ว่าเป็น Cache Hit หรือ Cache Miss จาก Response Header หรือ Metadata ที่ Provider ส่งกลับมา ไม่ใช่คาดเดาจากความรู้สึก
2. คำนวณ Cache Hit Rate แยกตาม Endpoint เพราะแต่ละ Endpoint มีลักษณะ Traffic ต่างกัน อัตราที่ดีของ Endpoint หนึ่งอาจแย่มากสำหรับอีก Endpoint
3. เปรียบเทียบต้นทุนรวมก่อนและหลังเปิด Caching อย่างน้อยหนึ่งรอบบิล เพื่อดูผลจริงแทนการเชื่อตามทฤษฎีเพียงอย่างเดียว
4. ถ้า Cache Hit Rate ต่ำกว่าที่คาดไว้มาก ให้กลับไปตรวจโครงสร้าง Prompt ว่ามีส่วน Dynamic แทรกอยู่ต้น Prompt โดยไม่ตั้งใจหรือไม่
5. ปิด Caching เฉพาะ Endpoint ที่พิสูจน์แล้วว่าไม่ได้ผล แทนที่จะปิดทั้งระบบทันทีเมื่อเห็นตัวเลขไม่ดีจาก Endpoint เดียว

ข้อผิดพลาดที่พบบ่อยเมื่อเริ่มใช้ Prompt Caching

ข้อผิดพลาดแรกคือเปิด Caching กับทุก Endpoint พร้อมกันโดยไม่ทดสอบทีละจุด ทำให้เมื่อบิลไม่ลดลงตามคาด ทีมไม่รู้ว่าปัญหาอยู่ที่ Endpoint ไหน เพราะเปลี่ยนหลายอย่างพร้อมกันจนแยกสาเหตุไม่ออก ควรเปิดทีละ Endpoint แล้ววัดผลก่อนขยายไปจุดอื่น

ข้อผิดพลาดที่สองคือคิดว่า Cache จะทำงานได้เหมือนกันทุก Provider เพราะแต่ละเจ้ามีเงื่อนไขเรื่อง TTL, ขนาดขั้นต่ำของ Prompt ที่ Cache ได้ และวิธีคิดราคาต่างกัน ควรอ่านเอกสารของ Provider ที่ใช้จริงก่อนตั้งความคาดหวังเรื่องผลลัพธ์

ข้อผิดพลาดสุดท้ายที่เชื่อมกับ Reliability ของระบบคือ การไม่มีแผนสำรองเมื่อ Cache หมดอายุหรือ Provider มีปัญหาชั่วคราวจน Cache ใช้ไม่ได้ ระบบควรทำงานได้ตามปกติแม้ Cache Miss ทุกครั้ง เพียงแค่ต้นทุนสูงขึ้นเล็กน้อย ไม่ใช่ระบบล่มเพราะพึ่งพา Cache มากเกินไป หากสนใจการออกแบบระบบให้ทนต่อความล้มเหลวลักษณะนี้ ดูเพิ่มเติมได้ที่ แนวทางออกแบบ LLM Fallback Strategy

ทีมต้องเตรียมอะไรก่อนเปิด Prompt Caching ใน Production จริง

ก่อนเปิด Prompt Caching ใน Production จริง ทีมควรมี Log ที่แยกแยะได้ว่า Request แต่ละครั้งเป็น Cache Hit หรือ Cache Miss ตั้งแต่วันแรกที่เปิดใช้ ไม่ใช่เปิดใช้ไปก่อนแล้วค่อยคิดเรื่องการวัดผลทีหลัง เพราะถ้าไม่มีข้อมูลนี้ตั้งแต่ต้น ทีมจะไม่มีทางรู้เลยว่าการเปลี่ยนแปลงที่เห็นในบิลเดือนถัดมาเกิดจาก Caching จริงหรือเกิดจากปัจจัยอื่นที่เปลี่ยนไปพร้อมกัน

อีกสิ่งที่ควรเตรียมคือกระบวนการ Rollback ที่ทำได้เร็ว หากพบว่า Endpoint ใดเปิด Caching แล้วต้นทุนสูงขึ้นแทนที่จะลดลง ทีมควรปิดการใช้งาน Caching เฉพาะ Endpoint นั้นได้ทันทีโดยไม่ต้อง Deploy ใหม่ทั้งระบบ เช่น ผ่าน Feature Flag ที่แยกควบคุมแต่ละ Endpoint ได้อิสระจากกัน

ทีมที่มี Prompt Template เปลี่ยนแปลงบ่อยควรระวังเป็นพิเศษ เพราะทุกครั้งที่มีการแก้ System Prompt แม้เพียงเล็กน้อย Cache เดิมจะใช้ไม่ได้ทันทีและต้องเริ่มสร้างใหม่ ถ้าทีมแก้ Prompt บ่อยกว่าที่ Cache จะทันได้ประโยชน์จริง การลงทุนเรื่อง Caching อาจยังไม่คุ้มค่าเท่ากับการทำ Prompt ให้นิ่งก่อนแล้วค่อยเปิด Caching ทีหลัง

สรุป

Prompt Caching ลดทั้ง Latency และต้นทุนได้จริงเมื่อใช้กับ Endpoint ที่มี Traffic สม่ำเสมอและ Prompt ส่วนต้นเหมือนกันทุกครั้ง แต่ไม่ใช่เทคนิคที่เปิดแล้วได้ผลดีทุกจุดในระบบโดยอัตโนมัติ ทีมที่เปิดใช้แบบไม่เลือกจุดมักพบว่าบิลไม่ลดลงตามคาด หรือในบางกรณีสูงขึ้นเล็กน้อยจาก Cache Miss ที่บ่อยเกินไป

การใช้ Prompt Caching ให้ได้ผลจริงต้องเข้าใจกลไก Prefix Match และ TTL ของ Provider ที่ใช้ ออกแบบโครงสร้าง Prompt ให้ส่วนคงที่อยู่ต้นเสมอ และวัด Cache Hit Rate จริงก่อนขยายไปทุก Endpoint ไม่ใช่เชื่อตามทฤษฎีเพียงอย่างเดียว

• Cache ทำงานที่ระดับ Token Processing ไม่ใช่ Response Cache สำเร็จรูป ต้องมีส่วนต้น Prompt ตรงกันเป๊ะถึงจะ Hit
• เปิด Caching ทีละ Endpoint แล้ววัด Cache Hit Rate จริงก่อนขยาย ไม่เปิดพร้อมกันทั้งระบบโดยไม่ทดสอบ
• จัดลำดับ Prompt ให้ส่วนคงที่อยู่ต้นเสมอ และหลีกเลี่ยงข้อมูล Dynamic แทรกอยู่ต้น Prompt เพื่อให้ Cache Hit สูงขึ้น

คำถามที่พบบ่อย