Prompt Caching คืออะไร? เทคนิคลดต้นทุน API AI สำหรับ SME ไทย

Prompt caching คือเทคนิคที่ผู้ให้บริการ LLM ใช้เก็บผลการคำนวณส่วนต้นของ prompt ไว้ในหน่วยความจำชั่วคราว เมื่อมีคำขอใหม่ที่ขึ้นต้นด้วยข้อความเดิม ระบบจะดึงผลนั้นมาใช้ต่อ แทนที่จะประมวลผลโทเคนเดิมทั้งหมด ผลลัพธ์คือค่า API ลดลงและความหน่วงลดลง โดยไม่ต้องเปลี่ยนโมเดลหรือลดคุณภาพเนื้อหา สำหรับ SME ไทยที่ใช้ AI กับงานซ้ำ เช่น ตอบลูกค้า สรุปเอกสาร หรือวิเคราะห์รีวิว วิธีนี้คือมาตรฐานที่ควรทำก่อนตัดสินใจลดขนาดโมเดลหรือจำกัดการใช้งาน

Prompt caching คืออะไร และทำงานอย่างไร

เวลาส่ง prompt ไปยังโมเดลภาษา ข้อความจะถูกแปลงเป็นโทเคน และโมเดลต้องคำนวณความสัมพันธ์ระหว่างโทเคนผ่านกลไก attention ยิ่ง prompt ยาว ยิ่งต้องคำนวณมาก ยิ่งคิดต้นทุน input token สูง Prompt caching คือการเซฟสถานะการคำนวณบางส่วนของ prefix ไว้ เมื่อผู้ใช้ส่ง prefix เดิมซ้ำ API จะไม่ต้องคำนวณโทเคนเหล่านั้นใหม่ทั้งหมด แต่จะดึงสถานะที่เซฟไว้มาใช้ แล้วประมวลผลเฉพาะโทเคนใหม่ที่ต่อท้าย

การทำงานแบ่งเป็นสองสถานะหลัก: cache hit คือส่วนที่ผู้ให้บริการพบ prefix ตรงกับแคชและคิดราคาพิเศษ ส่วน cache miss คือส่วนที่ต้องประมวลผลใหม่ทั้งหมด เช่น คำขอแรกของวัน ข้อมูลที่เปลี่ยน หรือ prefix ที่ไม่ตรงกัน ผู้ให้บริการแต่ละรายมีระยะเวลาที่เก็บแคชต่างกัน เรียกว่า TTL เมื่อครบกำหนดหรือเมื่อไม่มีเรียกซ้ำ cache จะหายไปและต้องสร้างใหม่

สิ่งสำคัญคือ cache นี้ทำงานกับ prefix แบบตรงตามตัวอักษร ไม่ใช่ความหมาย ถ้าเว้นวรรคผิด พิมพ์ผิด หรือสลับลำดับข้อความในส่วนต้นแม้ตัวเดียว ทั้ง prefix จะไม่ตรงและเสียโอกาส cache ทันที นี่คือเหตุผลที่การออกแบบ prompt ต้องให้ความสำคัญกับความเสถียรของส่วนต้นมากกว่าส่วนท้าย

ทำไม Prompt caching ถึงช่วยลดต้นทุน API AI สำหรับ SME ไทย

SME ไทยส่วนใหญ่เริ่มใช้ AI จากงานบริการลูกค้า ซึ่งมี system prompt ค่อนข้างยาวและถูกเรียกซ้ำทุกครั้ง แชทบอตหนึ่งตัวอาจมี system prompt ความยาว 500 ถึง 2,000 โทเคน และเมื่อมีลูกค้าสอบถามหลายร้อยถึงหลายพันครั้งต่อวัน โทเคนเดิมเหล่านั้นก็ถูกส่งไปประมวลผลซ้ำโดยไม่เกิดประโยชน์ใหม่ ผู้ให้บริการ API คิดเงินจากปริมาณโทเคนที่ประมวลผล ไม่ใช่จากจำนวนคำถามที่ตอบได้ต่างระดับกัน

ลองคิดตามตัวอย่างร้านค้าออนไลน์ที่มีแชทบอต 2,000 ครั้งต่อวัน โดย system prompt และนโยบายร้านยาว 1,500 โทเคน ถ้าไม่ใช้ cache วันหนึ่งต้องประมวลผล input 3 ล้านโทเคนจากเนื้อหาชุดเดิม แม้ราคาต่อล้านโทเคนจะดูไม่สูง แต่เมื่อรวมทั้งเดือนก็เป็นค่าใช้จ่ายที่เห็นชัด Prompt caching ลดส่วน input token ที่ซ้ำกันลงได้มาก โดยเฉพาะถ้า prefix ครอบคลุม 80-90% ของ prompt ทั้งหมด

นอกจากต้นทุนแล้ว cache hit ยังลด latency ลงด้วย เพราะโมเดลไม่ต้องประมวลผลใหม่ทั้งชุด ผลที่ตามมาคือผู้ใช้รู้สึกว่าบอตตอบไวขึ้น และธุรกิจสามารถรองรับปริมาณคำขอได้มากขึ้นโดยไม่ต้องเพิ่มงบ API เทคโนโลยีนี้ไม่ได้ลดคุณภาพเนื้อหา เพราะโมเดลยังเป็นตัวเดิม เพียงแต่ไม่ทำงานซ้ำในส่วนที่เคยคำนวณแล้วเท่านั้น

cache hit ถูกกว่าแค่ไหน และควรใช้กับงานแบบไหนของ SME ไทย

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

OpenAI ระบุว่า automatic prompt caching จะเกิดขึ้นกับ prompt ที่ยาวพอ โดยส่วน cache read จะถูกกว่าการคิด input ปกติราว 50% เช่น รุ่น GPT-4o ช่วงตัวอย่างมี input ปกติ 2.50 ดอลลาร์ต่อล้านโทเคน และ cached input 1.25 ดอลลาร์ต่อล้านโทเคน (ผู้ให้บริการระบุ / ผลจริงขึ้นกับบริบท)

Anthropic ใช้การเพิ่ม cache_control ใน prompt โดย cache read ถูกลงอย่างมาก ตัวอย่าง Claude Sonnet มี base input 3 ดอลลาร์ต่อล้านโทเคน, cache write 3.75 ดอลลาร์ และ cache read 0.30 ดอลลาร์ต่อล้านโทเคน (ผู้ให้บริการระบุ / ผลจริงขึ้นกับบริบท) นี่คือส่วนต่างที่ทำให้งานที่ใช้ prefix ยาวและซ้ำบ่อยคุ้มค่ามาก

Gemini ใช้กลไก context caching ซึ่งต้องสร้าง CachedContent ขึ้นมาก่อน แล้วจึงส่ง cachedContent ไปในคำขอ ผู้ให้บริการระบุว่าส่วน input token ที่ cache hit ลดค่าใช้จ่ายได้สูงสุด 75% แต่มีค่าเก็บ cache ตามเวลาและขนาดเนื้อหา (ผู้ให้บริการระบุ / ผลจริงขึ้นกับบริบท)

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

จะเริ่มใช้ Prompt caching กับ OpenAI, Anthropic และ Gemini ได้อย่างไร

OpenAI มีระบบ automatic prompt caching หมายความว่าถ้าใช้ API ปกติผ่าน chat completions และ prompt prefix ยาวถึงเกณฑ์ที่กำหนด ระบบจะสร้าง cache ให้เองโดยไม่ต้องเพิ่มพารามิเตอร์พิเศษ หน้าที่ของผู้ใช้คือออกแบบ prompt ให้ส่วนต้นคงที่ และตรวจสอบค่า prompt_tokens_details.cached_tokens ใน response เพื่อยืนยันว่ามี cache hit

Anthropic ไม่ได้เปิด cache อัตโนมัติเหมือน OpenAI ต้องระบุจุด breakpoint ใน system block หรือ message block โดยเพิ่ม cache_control เช่น

{
  "type": "text",
  "text": "คุณคือผู้ช่วยอัจฉริยะที่ดูแลลูกค้าร้านค้าออนไลน์",
  "cache_control": { "type": "ephemeral" }
}

จุดนี้จะบอก API ว่าเนื้อหาตั้งแต่ block ก่อนหน้าถึง block นี้ควรถูกเก็บไว้ใน cache เมื่อมีการเรียกซ้ำ ระบบจะใช้ cached token แทนการคำนวณใหม่

Gemini ใช้ context caching ที่ต้องสร้าง CachedContent ผ่าน Gemini SDK หรือ REST API ก่อน โดยระบุ model, เนื้อหาที่ต้องการแคช และ TTL เช่น 60 นาที จากนั้นให้เลือกใช้ cachedContentName แทนการส่ง system prompt เต็มทุกครั้ง วิธีนี้ลด input token ส่วนที่ซ้ำกันและยังช่วยให้ระบบตอบสนองเร็วขึ้น

เทคนิคออกแบบ prompt ให้ cache มีประสิทธิภาพสูงสุดทำอย่างไร

เริ่มจากการวางของที่คงที่ไว้ข้างหน้าเสมอ system prompt, บทบาท, กติกา, รูปแบบ output, few-shot examples และนโยบายบริษัทควรเป็นส่วนแรกสุด ส่วนที่เปลี่ยนแปลงในแต่ละคำขอ เช่น ชื่อลูกค้า วันที่ เลขคำสั่งซื้อ หรือคำถามใหม่ ให้ไว้ท้ายคำถาม เพราะ cache เป็นแบบ prefix หากตัวแปรอยู่หน้าสุด จะทำให้ cache miss ทุกรอบ

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

สำหรับงานที่ใช้ข้อมูลอ้างอิงจากฐานความรู้ เช่น RAG อย่าใส่ผลการค้นหาที่เรียงลำดับไม่แน่นอนไว้กลาง system prompt ควรให้ system prompt คงที่แล้วต่อข้อมูลเอกสารที่จะใช้ในรอบนั้นท้ายสุด หากลำดับข้อมูลจากการค้นหาไม่เสถียร prompt จะเปลี่ยนทุกครั้งและ cache ไม่เกิด

งาน multi-turn ควรเก็บประวัติการสนทนาตามลำดับเวลา และให้รอบต่อๆ ไปแนบประวัติเดิมทั้งชุดก่อนคำถามใหม่ ถ้าเกลาประวัติหรือสลับข้อความ ระบบจะมองว่าเป็น prefix ใหม่และคำนวณใหม่ทั้งหมด สำหรับ Anthropic ให้แทรก cache breakpoint เฉพาะจุดที่มั่นใจว่าเป็น prefix ซ้ำ เช่น หลัง system prompt และหลังตัวอย่างคำตอบ ไม่ควรใส่ breakpoint มากเกินจำเป็นเพราะ cache write มีต้นทุนเช่นกัน

ส่วน TTL ควรเลือกให้สอดคล้องกับรอบการใช้งาน Gemini ต้องจ่ายค่าเก็บ cache ดังนั้นถ้างานมี burst สั้นก็เลือก TTL 60 นาที ถ้าต้องใช้ทั้งวันก็เลือกหลายชั่วโมง แต่ไม่ควรตั้งยาวเกินไปเพราะเนื้อหาอาจเปลี่ยนและเสียค่าเก็บโดยไม่จำเป็น

ควรระวังอะไรบ้างด้านความเป็นส่วนตัว TTL ข้อมูลปนเปื้อน และการวัดผล

ความเป็นส่วนตัว เป็นข้อกังวลแรกของ SME ไทยที่ต้องดูแลข้อมูลลูกค้าตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล การใช้ prompt caching หมายถึงข้อความบางส่วนถูกจัดเก็บบนเซิร์ฟเวอร์ผู้ให้บริการระยะหนึ่ง จึงต้องตรวจสอบนโยบายการเก็บข้อมูล ข้อตกลงประมวลผลข้อมูล และตำแหน่งศูนย์ข้อมูลของแต่ละผู้ให้บริการ ไม่ควรใส่เลขบัตรประชาชน เลขบัญชี หรือข้อมูลสุขภาพลงใน prompt ที่ตั้งใจให้แคช ควรให้ prefix เป็นข้อความระบบคงที่ ส่วนข้อมูลเฉพาะบุคคลให้อยู่ท้ายคำขอและทำตามนโยบายข้อมูลขององค์กร

TTL คือระยะเวลาที่ผู้ให้บริการเก็บ cache ไว้ ถ้าไม่มีคำขอใหม่มาก่อนหมดอายุ cache จะหายไปและรอบต่อไปกลายเป็น cache miss งานที่ถูกเรียกครั้งเดียวแล้วจบไม่เหมาะกับเทคนิคนี้ งานที่ควรใช้คืองานที่มีการเรียกซ้ำถี่พอ เช่น ตลอดวันทำงานของแชทบอตหรือรอบ batch ทุก 10-15 นาที

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

การวัดผล เป็นขั้นตอนที่ขาดไม่ได้ ผู้ให้บริการทุกรายส่ง usage statistics กลับมา ไม่ว่าจะเป็น cached tokens, prompt tokens, output tokens หรือ cache creation tokens ควรเก็บ log ทุกครั้งและสร้าง dashboard เพื่อดูอัตรา cache hit หากพบว่าอัตราลดลงผิดปกติ อาจเกิดจากการเปลี่ยน system prompt, สลับลำดับข้อมูล หรือ TTL สั้นเกินไป การวัดก่อน-หลังช่วยให้ SME ยืนยันได้ว่าค่าใช้จ่ายลดลงจริง ไม่ใช่แค่เดาจากราคาทฤษฎี

สรุป: เริ่มต้นลดค่า API วันนี้ได้อย่างไร

Prompt caching เป็นเทคนิคที่ SME ไทยควรทำเป็นลำดับต้นๆ ก่อนตัดสินใจเปลี่ยนโมเดลหรือลดความสามารถ AI เริ่มจากงานที่เรียก API ซ้ำมากที่สุด แก้ไข prompt ให้ส่วนต้นคงที่ เปิดใช้ cache ตามผู้ให้บริการ และตรวจสอบ usage เพื่อยืนยันผลประหยัด สิ่งที่ต้องแลกคือการออกแบบ prompt ให้เป็นระบบและมีวินัยในการรักษาโครงสร้างเดิม แต่ผลตอบแทนคือค่าใช้จ่ายที่ลดลงและความเร็วที่ดีขึ้นโดยคุณภาพงานยังเท่าเดิม

สำหรับธุรกิจที่กำลังเริ่มใช้ AI automation การมีกลยุทธ์ prompt caching ตั้งแต่ต้นจะช่วยให้งบประมาณมีประสิทธิภาพมากขึ้น และยังเตรียมโครงสร้างให้รองรับการขยายจำนวนผู้ใช้ได้โดยไม่ต้องกังวลว่า API bill จะเพิ่มกระโดดตามปริมาณงาน ทีม Flowtica แนะนำให้เริ่มจาก workflow เล็กๆ ก่อน แล้วขยายไปงานอื่นเมื่อเห็นผลจริง