พิมพ์แค่คำว่า "ทำต่อ" แล้วโดนคิดเงินแพงกว่าตอนสั่งงานยาวทั้งย่อหน้า นั่นคือสัญญาณว่า prompt cache หลุดไปแล้ว

ลองจินตนาการว่าลุกไปชงกาแฟสัก 10 นาที พอกลับมาพิมพ์ทักสั้นๆ แค่บรรทัดเดียว แต่ระบบกลับคิดเงินเหมือนเพิ่งส่งบทสนทนาทั้งวันเข้าไปใหม่อีกรอบ

และระบบก็ส่งเข้าไปใหม่จริงๆ

AI agent อย่าง Claude Code, Cursor หรือ Codex คือ AI ที่รับงานแล้วไล่ทำเองทีละขั้น ทั้งเรียกเครื่องมือ อ่านไฟล์ แก้โค้ด แล้วค่อยวนกลับมาถามต่อ ทุกรอบที่วนกลับมา ตัว agent ไม่ได้จำบทสนทนาเดิมไว้ในหัวเหมือนคน แต่ต้องหอบข้อมูลเดิมทั้งหมดส่งกลับไปให้โมเดลประมวลผลใหม่ สิ่งเดียวที่ช่วยกันไม่ให้ประวัติเก่าโดนคิดราคาเต็มซ้ำๆ คือ prompt cache และกลไกนี้ก็หลุดง่ายกว่าที่คิดไว้มาก

เรื่องนี้มีคนไล่อธิบายไว้เป็นขั้นตอนในบทความของ Earendil ทีมพัฒนา AI agent ชื่อ Pi โดยเล่าตั้งแต่กลไกการทำงานว่าแคชเก็บอะไรไว้บ้าง ไปจนถึงพฤติกรรมต่างๆ ที่ทำให้แคชหลุดโดยไม่รู้ตัว

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

โมเดลไม่ได้จำ ทุกรอบคือส่งใหม่ทั้งกอง

ทุกครั้งที่กด Enter เพื่อคุยต่อ ตัว agent ไม่ได้ส่งไปแค่ข้อความใหม่ล่าสุด แต่เป็นการประกอบข้อมูลขึ้นมาใหม่ทั้งชุดแล้วส่งเข้าไปพร้อมกัน

• system prompt คือคำสั่งตั้งต้นที่กำหนดบทบาทและขอบเขตการทำงานของ agent
• นิยามของ tool คือรายการเครื่องมือที่ agent เรียกใช้ได้ เช่น อ่านไฟล์ แก้ไฟล์ หรือค้นหาบนเว็บ พร้อมเงื่อนไขว่าแต่ละตัวต้องรับค่าอะไรบ้าง
• คำสั่งประจำโปรเจกต์ คือไฟล์กฎเกณฑ์ที่วางไว้ให้ agent อ่านก่อนเริ่มงานทุกครั้ง
• ประวัติการคุยทั้งหมด ตั้งแต่ข้อความแรกสุดของเซสชันนั้น
• ผลลัพธ์ที่เครื่องมือคืนกลับมา ทั้งเนื้อหาไฟล์ที่อ่านมา และผลการรันคำสั่งที่เรียกใช้

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

prompt cache จะทำงานได้ เมื่อส่วนหน้าเหมือนเดิมเป๊ะ

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

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

ประเด็นสำคัญยิ่งกว่าคือ ต่อให้ความหมายเหมือนกัน ก็ใช้แทนกันไม่ได้ ถ้าข้อความสื่อความหมายเดียวกันแต่ตัวอักษรต่างกันนิดเดียว ระบบจะมองว่าเป็นคนละชุดข้อมูลทันทีและไม่สามารถใช้แคชร่วมกันได้ หลักการนี้เป็นบทเรียนที่ทีมสร้าง Claude Code สรุปไว้ว่า prompt caching คือทุกอย่างของ agent ไม่ใช่แค่ลูกเล่นประหยัดเงิน

ประวัติ 100,000 โทเคน ราคาต่างกันคนละเรื่อง

ผู้ให้บริการไม่ได้คิดเงินโทเคนทุกตัวในเรตเดียวกัน มีสามเรตที่ต้องแยกให้ออก

บทความยกตัวอย่างตัวเลขให้เห็นภาพชัดเจน โดยสมมุติบทสนทนาที่สะสมประวัติไว้ 100,000 โทเคน แล้วมีคำสั่งใหม่สั้นๆ พิมพ์ต่อท้าย ถ้าแคชยังทำงานอยู่ เนื้อหา 100,000 โทเคนเกือบทั้งหมดจะคิดในเรตอ่านแคชซึ่งถูกที่สุดในสามเรต เหลือแค่ข้อความใหม่ไม่กี่บรรทัดเท่านั้นที่คิดเรต input เต็ม

แต่พอแคชหลุด ทางฝั่งผู้ให้บริการก็ต้องไล่คำนวณของเก่าที่สะสมไว้ 100,000 โทเคนใหม่ทั้งหมดในเรต input เต็ม แถมยังอาจโดนค่าเขียนแคชซ้ำอีกรอบเพื่อฝากข้อมูลชุดใหม่ไว้ นี่คือเหตุผลว่าทำไมข้อความที่สั้นที่สุดในเซสชัน ถึงกลายเป็นข้อความที่แพงที่สุดได้

8 จังหวะที่ทำให้ prompt cache หลุด

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

• ทิ้งช่วงนานเกินอายุแคช ผู้ให้บริการเก็บแคชไว้ให้ในเวลาจำกัด ซึ่งฝั่ง Anthropic เจ้าของโมเดล Claude ตั้งไว้ที่ห้านาทีเป็นพื้นฐาน ลุกไปประชุมสิบนาทีแล้วกลับมาทักคำเดียว ประวัติทั้งกองก็ต้องคำนวณใหม่
• เปลี่ยนโมเดลหรือย้ายผู้ให้บริการระหว่างงาน สถานะของแคชผูกอยู่กับโมเดลตัวนั้นโดยตรง และโดยทั่วไปย้ายข้ามผู้ให้บริการไม่ได้เลย
• ถอยกลับไปคุยจากจุดเดิมหรือแตกสาขาใหม่ การ rewind กลับไปคุยใหม่จากจุดก่อนหน้า จะเปลี่ยนลำดับข้อความที่ส่งจริง ถึงยังอยู่ในเซสชันเดิมและไฟล์เดิมก็ตาม
• สั่ง compact หรือเข้าไปแก้ประวัติด้วยมือ การย่อความประวัติให้สั้นลงคือการสร้างส่วนหน้าขึ้นมาใหม่ทั้งชุด เท่ากับส่งข้อมูลที่ระบบไม่เคยเห็นเข้าไป
• เพิ่ม ถอด สลับที่ หรือแก้นิยามของ tool นิยามของ tool อยู่รวมกับ system prompt ตรงส่วนต้นสุด ถ้าขยับตรงนั้นจุดเดียว ทุกอย่างที่ตามมาจะกลายเป็นของใหม่ทันที การเปิดปิด MCP ซึ่งเป็นมาตรฐานให้ agent ต่อกับเครื่องมือภายนอกก็นับเป็นการขยับแบบเดียวกัน การสลับระดับ reasoning ที่เลือกให้โมเดลคิดละเอียดต่างกันก็ส่งผลเหมือนกัน ปลั๊กอินหรือสกิลที่ลงไว้แต่ไม่ได้ใช้ก็กินพื้นที่ตรงส่วนต้นนี้เช่นกัน ซึ่งเป็นเหตุผลว่าทำไมการไล่เช็กว่าสกิลตัวไหนลงไว้เฉยๆ แต่ยังกินโควตาทุกข้อความถึงคุ้มที่จะทำสักรอบ
• system prompt ที่ไม่นิ่ง การใส่เวลาปัจจุบัน ค่าสุ่ม หรือข้อมูลโปรเจกต์ที่เปลี่ยนทุกรอบไว้ตรงส่วนหัว เท่ากับทำให้ทุกอย่างหลังจากนั้นใช้แคชซ้ำไม่ได้ตั้งแต่รอบแรก
• ส่วนขยายเข้าไปปรับข้อความเก่าก่อนส่ง บนหน้าจออาจดูปกติดี แต่ตัวส่วนขยายแอบเข้าไปแก้ข้อความที่ส่งออกไปจริงระหว่างทาง ซึ่งเป็นอาการที่มองไม่เห็นจากฝั่งผู้ใช้เลย
• การจ่ายงานและการเคลียร์แคชที่ฝั่งผู้ให้บริการ ต่อให้ข้อความเหมือนเดิมทุกตัวอักษร แคชก็ยังหลุดได้ ถ้าก้อนแคชไม่ได้อยู่บนเครื่องเซิร์ฟเวอร์ที่คำขอรอบนั้นวิ่งไปถึง ข้อนี้อยู่นอกเหนือการควบคุมของผู้ใช้

สามข้อแรกมักเกิดขึ้นระหว่างการทำงานปกติ และเป็นสามข้อที่แก้ได้ง่ายๆ แค่จัดลำดับการทำงานใหม่ โดยไม่ต้องไปตั้งค่าอะไรเพิ่ม

ไล่ลบประวัติเก่า ไม่ได้แปลว่าประหยัดเสมอไป

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

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

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

กับดักอีกอย่างที่คล้ายกันคือ การโหลด tool เฉพาะตอนที่จะใช้ ซึ่งเป็นวิธีที่ระบบปลั๊กอินและ MCP นิยมใช้กัน ฟังดูเหมือนจะประหยัดเพราะไม่ต้องแบกนิยามเครื่องมือที่ไม่จำเป็น แต่บทความชี้ว่าสำหรับโมเดลส่วนใหญ่ การเพิ่มเครื่องมือเข้ามากลางทางจะทำให้แคชบทสนทนาที่สะสมไว้พังทั้งหมด ประหยัดโทเคนค่านิยามเครื่องมือไปนิดเดียว แต่ต้องแลกกับการคำนวณบทสนทนาใหม่หลายหมื่นโทเคน เว้นแต่เป็นโมเดลรุ่นใหม่บางตัวที่รองรับการต่อท้ายเครื่องมือโดยไม่แตะรายการเดิม กรณีนั้นข้อมูลส่วนหน้าถึงจะยังอยู่ครบ

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

พรุ่งนี้เปลี่ยนอะไรได้บ้าง

• หากมีงานก้อนใหญ่ ควรทำรวดเดียวให้เสร็จ ถ้าคิดว่าจะหายไปนาน ให้ปิดงานก้อนนั้นให้เรียบร้อยก่อนลุกไปทำอย่างอื่น
• เลี่ยงการสลับโมเดลระหว่างทำงานในเซสชันเดียวกัน ควรเลือกโมเดลที่จะใช้ให้จบตั้งแต่ก่อนเริ่มงาน
• ตั้งค่าเครื่องมือและ MCP ที่ต้องใช้ให้ครบตั้งแต่ต้น แล้วอย่าไปเปิดปิดเพิ่มกลางทาง รวมถึงระดับ reasoning ก็ควรเลือกให้เรียบร้อยตั้งแต่แรก
• ดึงเวลาปัจจุบันและค่าที่ขยับทุกรอบ ออกจากไฟล์คำสั่งประจำตัว ถ้าจำเป็นต้องใส่จริงๆ ให้ขยับไปไว้ท้ายข้อความแทน เพราะอะไรก็ตามที่ขยับทุกรอบและอยู่ส่วนหัว จะลากให้ข้อมูลทั้งหมดที่ตามมาต้องคำนวณใหม่
• เลิกรื้อประวัติเก่าทิ้งด้วยความหวังว่าจะช่วยประหยัด เว้นแต่จะคำนวณจุดคุ้มทุนแล้วว่าคุ้มจริง
• คอยเช็กอัตราแคชติดของเซสชันตัวเองให้เห็นกับตา แทนที่จะนั่งเดาจากยอดบิลปลายเดือน

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

หลักการทั่วไป กับของที่มีแค่ในเครื่องมือตัวเดียว

เนื่องจากผู้เขียนบทความต้นทางพัฒนา agent ของตัวเองด้วย ตัวอย่างบางส่วนจึงมีอยู่แค่ใน Pi เท่านั้น ไม่ใช่สิ่งที่ agent ทุกตัวมี

• แถบสถิติด้านล่างจอที่แสดงยอดอ่านและเขียนแคชสะสม พร้อมอัตราแคชติดของคำขอล่าสุด
• คำสั่ง /session ที่กางรายละเอียดทั้งเซสชัน เห็นทั้งโทเคนที่แคชติดและไม่ติด อัตราสะสม ค่าใช้จ่าย รวมถึงประมาณการว่าแคชที่หลุดไปทำให้โดนคิดเงินซ้ำเท่าไร
• ตัวเลือก showCacheMissNotices ใน settings.json ที่จะแจ้งเตือนทันทีเมื่อแคชหลุดครั้งที่มีนัยสำคัญ
• ค่า PI_CACHE_RETENTION=long ที่ตั้งค่าก่อนเปิดโปรแกรม เพื่อขอให้ผู้ให้บริการบางรายเก็บแคชไว้นานขึ้น ซึ่งเป็นเพียงคำขอ ไม่ใช่การรับประกันว่าจะไม่ถูกล้าง

ในบทความยังได้กางตัวเลขจากเซสชันจริงให้ดู โดยมี input สะสม 7,129,883 โทเคน ทำอัตราแคชติดได้ 95.0% คิดเป็นค่าใช้จ่ายรวม 6.054 ดอลลาร์ ซึ่งในจำนวนนั้นมีเงินที่จ่ายซ้ำเพราะแคชหลุดอยู่ 0.728 ดอลลาร์ จากการแคชหลุดเพียงสองครั้ง แต่คิดเป็นประวัติสูงถึง 161,744 โทเคนที่ต้องนำมาคำนวณใหม่

หลักการที่ว่าส่วนหน้าต้องตรงกันเป๊ะ ใช้ได้กับ agent ทุกเจ้า ส่วนวิธีเก็บแคชและระยะเวลาที่เก็บไว้ เป็นเรื่องของผู้ให้บริการแต่ละเจ้า บางแห่งให้ฝั่งผู้เรียกกำหนดจุดตัดเองว่าส่วนไหนนิ่งแล้ว แลกกับการจ่ายค่าเขียนแคชและสิทธิ์เลือกระยะเวลาฝาก ส่วนบางแห่งจะคอยตรวจหาส่วนที่ซ้ำกับรอบก่อนให้เองโดยไม่ต้องสั่ง

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

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

ทว่าราคาของอิสระเหล่านั้น คือการยอมให้ระบบกลับไปอ่านบทสนทนาใหม่ทั้งหมดตั้งแต่บรรทัดแรก

---

ที่มา: บทความ Prompt Caching In Agents จาก Earendil