วิธีที่วิศวกรของ Anthropic ช่วยประหยัดโทเค็น
ผู้เขียนต้นฉบับ: Nate Herk
แปลโดย: Peggy, BlockBeats

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

หัวใจหลักของบทความนี้คือวิธีการประหยัด Token ผ่านกลไกแคช ผู้เขียนสามารถใช้ซ้ำ Token ที่แคชไว้มากกว่า 300 ล้าน Token ในหนึ่งสัปดาห์ โดยมีปริมาณการแคชรายวันถึง 91 ล้าน Token เนื่องจากต้นทุนของ Token ที่แคชไว้เท่ากับเพียง 10% ของ Token ป้อนทั่วไป หมายความว่า 91 ล้าน Token ที่แคชไว้นั้นเทียบเท่ากับการคิดค่าใช้จ่ายประมาณ 9 ล้าน Token ทั่วไป เหตุที่ Claude Code ในเซสชันยาวดูเหมือน “ใช้งานได้นานกว่า” ไม่ใช่เพราะโมเดลทำงานฟรี แต่เพราะบริบทซ้ำๆ จำนวนมากถูกใช้ซ้ำอย่างประสบความสำเร็จ

หัวใจสำคัญของแคชพรอมต์คือ “อย่าขัดจังหวะแคช” Claude Code จะจัดเก็บแคชเป็นชั้นๆ สำหรับคำแนะนำระบบ นิยามเครื่องมือ CLAUDE.md กฎโครงการ และการสนทนาในอดีต; หากคำขอถัดไปมีส่วนนำที่เหมือนกัน Claude จะสามารถอ่านแคชได้ทันที โดยไม่ต้องประมวลผลบริบททั้งหมดอีกครั้ง Anthropic ยังติดตามอัตราการใช้ซ้ำของ prompt cache เนื่องจากไม่เพียงแต่มีผลต่อโควตาผู้ใช้ แต่ยังเกี่ยวข้องโดยตรงกับต้นทุนบริการโมเดลและประสิทธิภาพการดำเนินงาน

สำหรับผู้ใช้ทั่วไป ไม่จำเป็นต้องเข้าใจรายละเอียดพื้นฐานทั้งหมด แค่รักษานิสัยสำคัญไม่กี่ข้อเท่านั้น: อย่าปล่อยเซสชันไว้โดยไม่ใช้งานเกิน 1 ชั่วโมง; ทำ session handoff เมื่อสลับงาน; หลีกเลี่ยงการสลับโมเดลบ่อยๆ; ใส่เอกสารขนาดใหญ่ไว้ใน Projects แทนการวางซ้ำๆ ในบทสนทนา

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

以下为原文：

ฉันประหยัด Token ได้ 300 ล้านในสัปดาห์นี้ โดยหนึ่งวันมี 91 ล้าน และทั้งสัปดาห์เกิน 300 ล้าน

ฉันไม่ได้เปลี่ยนการตั้งค่าใดๆ นี่เป็นเพียงการแคช prompt ที่ทำงานตามปกติในพื้นหลัง

แต่เมื่อฉันเข้าใจอย่างแท้จริงว่าแคชคืออะไร และวิธีหลีกเลี่ยงไม่ให้แคช “ถูกขัดจังหวะ” ฉันสามารถยืดระยะเวลาการสนทนาของฉันได้นานขึ้นภายใต้ขอบเขตการใช้งานเดียวกัน ดังนั้น นี่คือคู่มือเริ่มต้น 80/20 สำหรับการแคช prompt ของ Claude Code โดยไม่ลงลึกถึงรายละเอียดระดับ API

สรุปสั้น

ต้นทุนของ Token ที่แคชไว้เท่ากับ 10% ของ Token แบบปกติ 91 ล้าน Token ที่แคชไว้ มีค่าใช้จ่ายจริงเทียบเท่ากับประมาณ 9 ล้าน Token

ค่า TTL ของแคชสำหรับเวอร์ชันสมัครสมาชิก Claude Code คือ 1 ชั่วโมง; API โดยค่าเริ่มต้นคือ 5 นาที; Sub-agent ตลอดเวลาคือ 5 นาที

แคชแบ่งเป็นสามชั้น: ชั้นระบบ ชั้นโปรเจกต์ และชั้นการสนทนา

การเปลี่ยนโมเดลระหว่างการสนทนาจะทำให้แคชเสียหาย รวมถึงการเปิดใช้งานโหมด «opus plan»

การคำนวณค่าใช้จ่ายของแคชทำได้อย่างไร?

ต้นทุนของทุกโทเค็นที่ถูกแคชคือ 10% ของต้นทุนโทเค็นการป้อนข้อมูลทั่วไป

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

บนแดชบอร์ดมีตัวเลขสองตัวที่ควรให้ความสนใจ:

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

หากตัวเลข Cache read ของคุณสูง แสดงว่าคุณกำลังใช้แคชอย่างมีประสิทธิภาพ; ถ้าตัวเลขนี้ต่ำ หมายความว่าคุณกำลังจ่ายเงินซ้ำๆ สำหรับบริบทเดียวกัน

ธาริก จาก Anthropic กล่าวประโยคหนึ่งที่ทำให้ฉันประทับใจ: “เราจริงจังกับการติดตามอัตราการเข้าถึง prompt cache และเมื่ออัตราการเข้าถึงต่ำเกินไป จะมีการแจ้งเตือน หรือแม้แต่ประกาศเหตุการณ์ระดับ SEV”

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

แต่ถ้าอัตราการถูกต้องต่ำมาก ทุกคนจะเสียหาย

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

แคชเติบโตขึ้นอย่างไรในแต่ละรอบการสนทนา?

Cache ใช้การจับคู่คำนำหน้า หรือที่เรียกว่า “prefix matching”

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

การสนทนาครั้งใหม่ ซึ่งมีลักษณะโดยประมาณดังนี้:

ตามเอกสารของ Claude Code เซสชันใหม่จะทำงานดังนี้:

การสนทนาครั้งแรก: ยังไม่มีแคชใดๆ คำสั่งระบบ บริบทโครงการของคุณ (เช่น CLAUDE.md, memory, กฎเกณฑ์) และข้อความแรกของคุณ จะถูกประมวลผลอีกครั้งทั้งหมด และบันทึกลงในแคช

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

การสนทนารอบที่สาม: เหตุผลเดียวกัน การสนทนาที่ผ่านมา vẫnคงอยู่ในแคช จำเป็นต้องประมวลผลเฉพาะการโต้ตอบล่าสุดเท่านั้น

แคชสามารถแบ่งออกเป็นสามชั้นได้:

จากบทความบน X ของ Thariq:

ชั้นระบบ (System layer): รวมถึงคำสั่งพื้นฐาน นิยามเครื่องมือ (read, write, bash, grep, glob) และรูปแบบการส่งออก ชั้นนี้ถูกแคชแบบทั่วโลก

ชั้นโครงการ (Project layer): รวมถึง CLAUDE.md, memory, กฎโครงการ ชั้นนี้จัดเก็บแบบแคชตามโครงการ

ระดับการสนทนา (Conversation): รวมถึงคำตอบและข้อความ ซึ่งจะเพิ่มขึ้นเรื่อยๆ ตามแต่ละรอบการสนทนา

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

ความสับสนระหว่าง 1 ชั่วโมงและ 5 นาที

นี่คือจุดที่เข้าใจผิดได้ง่ายที่สุด

เวอร์ชันสมัครใช้งาน Claude Code: TTL ค่าเริ่มต้นคือ 1 ชั่วโมง

Claude API: TTL เริ่มต้นคือ 5 นาที คุณสามารถจ่ายค่าใช้จ่ายเพิ่มเติมเพื่อเพิ่มเป็น 1 ชั่วโมง
Sub-agent ภายใต้แผนใดๆ: ตลอดเวลา 5 นาที

การแชทผ่านเว็บไซต์ Claude.ai: ไม่มีการบันทึกอย่างเป็นทางการ อาจเหมือนกับเวอร์ชันแบบสมัครสมาชิก แต่ฉันยังไม่ได้ยืนยัน

เมื่อไม่กี่เดือนก่อน หลายคนบ่นว่าปริมาณการสมัครใช้งาน Claude หมดเร็วเกินไป ในเวลานั้น มีบางคนคิดว่า Anthropic ได้ลด TTL จาก 1 ชั่วโมงเหลือ 5 นาทีโดยไม่แจ้งให้ผู้ใช้งานทราบ แต่ความจริงไม่ใช่เช่นนั้น TTL ของ Claude Code ยังคงเป็น 1 ชั่วโมง

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

หากคุณกำลังรันงาน流 Sub-agent จำนวนมาก หรือใช้ API โดยตรง ตัวเลข 5 นาทีนี้จึงมีความสำคัญ แต่สำหรับผู้ใช้ Claude Code 95% นั้น สิ่งที่ควรให้ความสนใจจริงๆ คือช่วงเวลา 1 ชั่วโมงเท่านั้น

สามนิสัยที่ครอบคลุมผู้ใช้ 95%

สิ่งเหล่านี้คือส่วนที่ฉันคิดว่ามีประโยชน์จริงในการใช้งานประจำวัน

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

/s2>/compact หรือ /clear 本来就会ทำลายแคช ดังนั้น不如ใช้จังหวะนี้รีเซ็ตให้จริงจังครั้งเดียว

ฉันสร้างทักษะการส่งต่อเซสชันของตัวเองมาแทน /compact มันจะสรุปสิ่งที่เราได้ทำไปแล้ว ข้อตัดสินใจใดที่ยังค้างอยู่ ไฟล์ใดสำคัญที่สุด และควรดำเนินการต่อจากจุดใดต่อไป จากนั้นฉันจึงรัน /clear แล้ววางสรุปนี้ลงไป เพื่อให้สามารถดำเนินการต่อได้เหมือนไม่มีการหยุดชะงัก

คำสั่ง compact บางครั้งก็ทำงานช้าเช่นกัน ในขณะที่ทักษะ handoff มักเสร็จสิ้นในเวลาไม่เกินหนึ่งนาที

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

การดำเนินการใดบ้างที่จะทำลายแคชโดยไม่แจ้งให้ทราบ?

มีบางสิ่งที่จะรีเซ็ตแคชทั้งหมดโดยไม่มีการแจ้งเตือนที่ชัดเจน

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

โหมด «Opus plan»: การตั้งค่านี้จะใช้ Opus ในขั้นตอนการวางแผน และใช้ Sonnet ในขั้นตอนการดำเนินการ ฉันเคยแนะนำมันในวิดีโอเกี่ยวกับการปรับแต่งโทเค็นบางตัว และมีเหตุผลที่ทำเช่นนั้น แต่คุณต้องเข้าใจว่า การสลับแผนทุกครั้ง 本质上 เป็นการเปลี่ยนโมเดล ซึ่งหมายความว่าต้องสร้างแคชใหม่ทั้งหมด ในระยะยาว มันยังช่วยยืดอายุวงจรการสนทนาได้ แต่คุณต้องรู้ว่าเกิดอะไรขึ้นเบื้องหลัง

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

ภาพหน้าจอที่ฉันแสดงไว้ด้านหน้า มาจากแดชบอร์ดของโทเค็น

https://github.com/nateherkai/token-dashboard

นี่คือรีพอสิทอรี GitHub ที่เรียบง่าย คุณส่งลิงก์ให้ Claude Code เพื่อให้มันปรับใช้บน localhost แบบท้องถิ่น มันจะอ่านบันทึกการสนทนาทั้งหมดของคุณในอดีต แทนที่จะเริ่มนับจากศูนย์ คุณจะเห็นข้อมูลเกี่ยวกับ input, output, cache create และ cache read ของแต่ละวันทันที

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

Summary

Prompt caching เป็นสิ่งที่สามารถศึกษาได้อย่างลึกซึ้ง บทความของ Thariq อธิบายครบถ้วนกว่าที่นี่ หากคุณต้องการดูภาพรวมทั้งหมด ควรอ่านให้จบ

แต่คุณไม่จำเป็นต้องเข้าใจทุกรายละเอียดเพื่อให้ได้ประโยชน์จากมัน คุณแค่ต้องเข้าใจ 80/20 ที่สำคัญที่สุด: Token ที่แคชราคาถูกกว่า Token ทั่วไป 10 เท่า; TTL ของ Claude Code คือ 1 ชั่วโมง; การสลับโมเดลจะทำให้แคชเสีย; การส่งต่ออย่างชัดเจนระหว่างงานมักคุ้มค่ากว่าการใช้เซสชันเก่าจนถึงเมื่อมัน “หมดอายุ” แล้วจึงบังคับใช้ต่อ

[原文链接]

คลิกเพื่อเรียนรู้เกี่ยวกับตำแหน่งที่律动BlockBeats กำลังรับสมัคร

ยินดีเข้าร่วมชุมชนอย่างเป็นทางการของ律动 BlockBeats:

กลุ่มสมัครรับข้อมูลบน Telegram: https://t.me/theblockbeats

กลุ่ม Telegram: https://t.me/BlockBeats_App

บัญชีทางการบน Twitter: https://twitter.com/BlockBeatsAsia