เปลี่ยนชื่อเครื่องมือเพียงนิดเดียว ก็เสียแคชทั้งหมด

การกำหนดราคาแคชแบบใหม่ของ Anthropic หมายความว่าการปรับเปลี่ยนเพียงตัวอักษรเดียว—เช่น การเปลี่ยนชื่อเครื่องมือ หรือการเพิ่มการระบุเวลา (timestamp) ลงใน system prompt—สามารถเปลี่ยนจาก cache hit ราคาถูก ให้กลายเป็น cache miss ราคาเต็ม ซึ่งอาจทำให้บิลค่าใช้จ่ายพุ่งสูงขึ้นหลายสิบเท่า

การเปลี่ยนแปลงนี้มาจากส่วนลดแคชแบบสองระดับของ Anthropic สำหรับบางโมเดล การอ่านข้อมูลจากแคช (cached read) จะมีราคาเพียง 0.025 × ของราคา input ปกติ ส่วนโมเดลอื่นๆ ส่วนลดจะอยู่ที่ 0.1 × ส่วนลดนี้จะใช้ได้ก็ต่อเมื่อคำขอ (request) ตรงกับข้อมูลที่เคยแคชไว้ก่อนหน้าอย่างแม่นยำเท่านั้น หากไม่ตรง (miss) จะถูกคิดราคาในอัตราพื้นฐาน ดังนั้นช่องว่างระหว่าง hit และ miss จึงกว้างขึ้นอย่างมาก ในทางปฏิบัติ การเปลี่ยนพรอมต์เพียงเล็กน้อยสามารถดันค่าใช้จ่ายให้สูงขึ้นถึง สี่สิบเท่า ของจำนวนที่คาดไว้

ทำไมการเปลี่ยนแปลงนี้จึงสำคัญ

Anthropic เพิ่มระดับแคชเพื่อส่งเสริมการใช้พรอมต์ที่เหมือนเดิมซ้ำๆ ซึ่งเป็นรูปแบบปกติในเอเจนต์ (agents) ที่เรียกใช้ชุดเครื่องมือเดิมซ้ำๆ แนวคิดนั้นเรียบง่าย: จัดเก็บผลลัพธ์ของการผสมผสานระหว่างพรอมต์และเครื่องมือไว้ครั้งเดียว จากนั้นจึงเรียกใช้ใหม่ในราคาถูกในการเรียกครั้งต่อๆ ไป ตัวคูณใหม่ทำให้ฝั่ง "การเรียกคืน" (retrieval) ถูกลงมาก แต่ในขณะเดียวกันก็ทำให้บทลงโทษสำหรับ "การพลาด" (miss) รุนแรงขึ้นมากเช่นกัน

นักพัฒนาที่สร้างเอเจนต์โดยอิงจาก system prompt ที่คงที่ จะพบว่าการเปลี่ยนแปลงใดๆ—ไม่ว่าจะตั้งใจหรือไม่ก็ตาม—จะทำให้สายโซ่ของแคชขาดสะบั้น ผลลัพธ์ที่ได้คือ "ภาษีแฝง" ของบริการ: อัตรา cache-hit ที่ต่ำลงจะส่งผลโดยตรงต่อต้นทุนการดำเนินงานที่สูงขึ้น

สิ่งที่ทำให้แคชเสีย

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

  • การกำหนดเครื่องมือ (Tool definitions) – การเพิ่ม, การลบ, การเปลี่ยนชื่อเครื่องมือ หรือการแก้ไขคำอธิบาย จะล้างแคชของเครื่องมือ, system prompt และประวัติข้อความทั้งหมด
  • สวิตช์เปิด/ปิดการค้นหาเว็บ (Web-search toggle) – การสลับค่า boolean ที่เปิดใช้งานเครื่องมือค้นหาเว็บจะล้างแคชของ system prompt และข้อความ
  • พารามิเตอร์การเลือกเครื่องมือ (Tool-choice parameter) – การปรับแต่งพารามิเตอร์ที่ใช้เลือกเครื่องมือที่จะรัน จะทำให้แคชของข้อความใช้งานไม่ได้เท่านั้น
  • ข้อมูลรูปภาพ (Image payloads) – การเพิ่มหรือลบรูปภาพจะส่งผลต่อแคชของข้อความเท่านั้น

รูปแบบทั่วไปที่นักพัฒนามักทำโดยไม่ตั้งใจ:

  1. การจัดลำดับเครื่องมือใหม่ (Reordering tools) – โค้ดบางชุดมีการเรียงลำดับ dictionary ของเครื่องมือใหม่ในทุกครั้งที่มีการ deploy ลำดับใหม่จะสร้าง cache key ที่ต่างออกไป ทำให้เกิดการ miss ทุกครั้ง
  2. พรอมต์ที่มีการระบุเวลา (Timestamped prompts) – การใส่ข้อความ "generated at HH:MM:SS" ลงใน system prompt ทำให้ทุกคำขอมีความเฉพาะตัว (unique) และรับประกันว่าจะเกิดการ miss
  3. การสลับเปลี่ยนส่วนประกอบของพรอมต์ (Rotating prompt fragments) – การเปลี่ยนคำทักทายหรือแบนเนอร์เวอร์ชัน จะทำให้ค่า hash ของพรอมต์เปลี่ยนไปและทำให้แคชเสีย

การตรวจจับต้นทุนแฝง

บันทึกการใช้งานของ Anthropic แสดงให้เห็นถึงกลไกของแคชผ่านสามฟิลด์:

  • cache_read_input_tokens – จำนวนโทเคน (tokens) ที่อ่านจากรายการแคช
  • cache_creation_input_tokens – จำนวนโทเคนที่เป็นสาเหตุให้มีการจัดเก็บรายการแคชใหม่
  • input_tokens – จำนวนโทเคนที่มีการคิดราคาในอัตราปกติ (ส่วนที่เหลือหลังจากหักการอ่านจากแคชแล้ว)

การเพิ่มขึ้นอย่างกะทันหันของ input_tokens พร้อมกับการลดลงของ cache_read_input_tokens เป็นสัญญาณว่ามีบางอย่างในพรอมต์เปลี่ยนไป การตรวจสอบเมทริกซ์เหล่านี้จะช่วยให้ทีมสามารถตอบสนองได้ก่อนที่ค่าใช้จ่ายจะบานปลาย

การตอบสนองของนักพัฒนา

เมื่อต้องเผชิญกับความเป็นจริงของราคาใหม่ หลายทีมจึงเริ่มปฏิบัติกับความเสถียรของพรอมต์ (prompt stability) ในฐานะตัวชี้วัดประสิทธิภาพที่สำคัญ กลยุทธ์ทั่วไป ได้แก่:

  • พรอมต์ระบบแบบคงที่ (Static system prompts) – จัดเก็บพรอมต์ไว้ในไฟล์ที่ควบคุมเวอร์ชัน (version-controlled file) และฉีด (inject) เข้าไปโดยไม่มีการแก้ไขในขณะรันไทม์ (runtime)
  • การจัดลำดับเครื่องมือแบบกำหนดผลลัพธ์ได้แน่นอน (Deterministic tool ordering) – กำหนดรายการเครื่องมือโดยตรงในโค้ด แทนที่จะพึ่งพาการเรียงลำดับของ dictionary หรือตัวสร้างภายนอก
  • การลบการระบุเวลา (Timestamp removal) – ย้ายข้อมูลการบันทึก (logging) หรือข้อมูลเวลาไปยังช่องทาง metadata แยกต่างหาก ซึ่งไม่ส่งผลกระทบต่อข้อความพรอมต์
  • การทดสอบที่คำนึงถึงแคช (Cache-aware testing) – เพิ่ม unit tests เพื่อตรวจสอบว่าค่า hash ของพรอมต์ทั้งหมด (system + tools + messages) ยังคงเดิมในทุกๆ build

แนวทางปฏิบัติเหล่านี้อาจเพิ่มภาระงานด้านวิศวกรรมเล็กน้อย แต่ช่วยป้องกัน "ภาษีแฝง" ที่เกิดจากการพลาดแคช (cache miss) ในปัจจุบัน

มุมมองของ Anthropic

Anthropic แย้งว่าส่วนลดที่มากขึ้นจะช่วยกระตุ้นการใช้ซ้ำ ซึ่งสามารถลดภาระการประมวลผลโดยรวมบนเซิร์ฟเวอร์ของบริษัทได้ การทำให้การอ่านจากแคชถูกลงอย่างมาก พวกเขาหวังว่านักพัฒนาจะออกแบบเอเจนต์ที่เรียกใช้ชุดเครื่องมือเดิมซ้ำๆ แทนที่จะคอยปรับเปลี่ยนพรอมต์อยู่ตลอดเวลา ข้อแลกเปลี่ยนคือบทลงโทษที่สูงขึ้นสำหรับการเรียกใช้งานที่ไม่สามารถใช้ซ้ำได้ ซึ่งบริษัทกล่าวว่าเป็นการผลักดันให้นักพัฒนาให้ความสำคัญกับ "สุขอนามัยของพรอมต์" (prompt hygiene) ที่ดีขึ้น

นักวิจารณ์ตั้งข้อสังเกตว่าเอเจนต์ในโลกความเป็นจริงจำนวนมากจำเป็นต้องปรับเปลี่ยนพรอมต์แบบทันทีทันใด—การเพิ่มบริบท (context), การระบุเวลา (timestamps) หรือการเลือกเครื่องมือแบบไดนามิก (dynamic tool selections) มักเป็นสิ่งจำเป็น สำหรับเวิร์กโหลดเหล่านั้น โครงสร้างราคาใหม่นี้อาจทำให้ Anthropic มีความน่าดึงดูดน้อยลงเมื่อเทียบกับผู้ให้บริการที่คิดราคาคงที่ (flat rate) โดยไม่คำนึงถึง cache hits

สิ่งที่ควรจับตามองต่อไป

  • การปรับปรุงราคา (Pricing revisions) – Anthropic อาจปรับจูนตัวคูณ (multipliers) หากผลตอบรับจากชุมชนแสดงให้เห็นว่าช่องว่างระหว่าง hit และ miss นั้นกว้างเกินไป
  • ฟีเจอร์ Cache-control – การอัปเดต API ในอนาคตอาจช่วยให้นักพัฒนาสามารถระบุได้ว่าส่วนใดของพรอมต์ที่ไม่ควรถูกรวมอยู่ใน cache key เพื่อเป็นทางเลือกสายกลาง
  • การตอบโต้จากคู่แข่ง – ผู้ให้บริการ LLM รายอื่นอาจปรับเปลี่ยนโมเดลแคชของตนเองเพื่อรักษาความสามารถในการแข่งขัน ไม่ว่าจะเป็นการเสนอราคาที่คงที่มากขึ้น หรือการเปิดให้มีการควบคุมแคชที่ละเอียด (granular) ยิ่งขึ้น

บทสรุป

ด้วยการกำหนดราคาแคชแบบใหม่ของ Anthropic ต้นทุนจากการที่พรอมต์ไม่พบในแคช (prompt miss) ไม่ใช่เพียงความไม่สะดวกเล็กน้อยอีกต่อไป แต่มันคือตัวแปรทางการเงินที่สามารถส่งผลกระทบต่องบประมาณของโครงการได้อย่างมหาศาล การทำให้ system prompts, การกำหนดเครื่องมือ (tool definitions) และ metadata ที่เกี่ยวข้องมีความคงที่ (immutable) กลายเป็นเรื่องสำคัญพอๆ กับการเขียนโค้ดที่มีประสิทธิภาพ ทีมที่ปฏิบัติกับความแน่นอนของพรอมต์ (prompt determinism) ในฐานะตัวชี้วัดที่วัดผลได้ จะสามารถหลีกเลี่ยงบิลค่าใช้จ่ายที่คาดไม่ถึง และควบคุมค่าใช้จ่ายของ AI-agent ได้อย่างต่อเนื่อง