กำไร:
- อธิบายตรรกะการจับคู่คำนำหน้าของการแคชพร้อมท์
- เพิ่มการเข้าถึงแคชโดยใส่บริบทคงที่ไว้ก่อนและบริบทตัวแปรตามหลัง
- สามารถคำนวณแคชการเขียน/อ่านเศรษฐศาสตร์และจุดคุ้มทุน
ผลิตภัณฑ์ LLM ดูราคาถูกในต้นแบบ เมื่อคุณก้าวขึ้นสู่ระดับ บิลจะเซอร์ไพรส์ ในปริมาณงานส่วนใหญ่ การเรียกเก็บเงินส่วนใหญ่มาจากบริบทคงที่แบบเดียวกันที่ถูกส่งซ้ำแล้วซ้ำเล่าพร้อมกับคำขอแต่ละรายการ: ข้อความแจ้งของระบบที่ยาว หนังสือกฎเกณฑ์ เอกสารอ้างอิง การแคชทันทีช่วยขจัดการสูญเสียนี้อย่างแน่นอน ในหน่วยการเรียนรู้นี้ คุณจะได้เรียนรู้วิธีการทำงานของแคช วิธีจัดเตรียมพรอมต์ที่จะเข้าถึง และวิธีการคำนวณจุดคุ้มทุนของเศรษฐกิจแคช เมื่อติดตั้งอย่างถูกต้อง เพียงอย่างเดียวก็สามารถลดค่าใช้จ่ายของคุณลงครึ่งหนึ่งหรือต่ำกว่านั้นได้
แคชทำงานอย่างไร? กฎข้อเดียวที่ไม่เปลี่ยนรูป
การแคชพร้อมท์คือการจับคู่คำนำหน้า ผู้ให้บริการจะจัดเก็บโทเค็นที่ประมวลผลไว้ชั่วคราวตั้งแต่เริ่มต้นการแจ้งเตือนของคุณ ถ้าพร้อมท์เริ่มต้นด้วยคำนำหน้าเดียวกันในคำขอถัดไป ส่วนทั่วไปนี้จะไม่ถูกคำนวณใหม่ การอ่านถูกกว่าแคชมาก
กฎหนึ่งที่ไม่เปลี่ยนรูปเป็นไปตามนี้: หากไบต์เดียวเปลี่ยนแปลงที่ใดก็ได้ในส่วนนำหน้า แคชทั้งหมดจะไม่ถูกต้องนับจากจุดนั้นเป็นต้นไป นั่นคือเนื้อหาคงที่ควรอยู่ที่จุดเริ่มต้นและเนื้อหาที่แปรผันควรอยู่ตอนท้าย หากคุณใส่บรรทัดไว้ที่จุดเริ่มต้นของพรอมต์ระบบที่เปลี่ยนแปลงกับคำขอแต่ละรายการ เช่น "วันที่วันนี้: 18.07.2026" ทุกอย่างที่อยู่ข้างหลังจะไม่สามารถเข้าสู่แคชได้
โดยปกติลำดับการประมวลผลจะเป็น: เครื่องมือ → ข้อความแจ้งของระบบ → ข้อความ คุณใส่จุดแคช (เบรกพอยต์) ที่ส่วนท้ายของส่วนที่คงที่
เศรษฐกิจแคช
แคชมีระดับราคาสามระดับ:
- การเขียนแคช: การจัดเก็บเป็นครั้งแรก ~1.25x ราคาอินพุตปกติ (สำหรับการจัดเก็บ 5 นาที)
- แคชที่อ่าน: การอ่านคำขอที่ตามมา ~0.1 เท่าของราคาอินพุตปกติ — นั่นคือ หนึ่งในสิบ
- อินพุตปกติ: ส่วนที่ไม่ได้เข้าสู่แคชและประมวลผลด้วยต้นทุนเต็มในแต่ละครั้ง
จุดคุ้มทุน: คำขอแรกจ่ายเบี้ยประกันภัยการเขียน (1.25×) จากคำขอที่สอง การอ่าน (0.1×) จะเข้ามามีบทบาท โดยคร่าวๆ คุณจะคอและคอกับสองคำขอ; หลังจากนั้นก็เป็นเงินออมสุทธิ ยิ่งบริบทคงที่มีขนาดใหญ่ขึ้นและยิ่งมีการร้องขอซ้ำมากขึ้นเท่าใด กำไรก็จะยิ่งมากขึ้นเท่านั้น
สถานการณ์
แคชทำงานหรือไม่
พรอมต์ระบบคงที่ขนาดใหญ่ คำขอนับพัน
ใช่ — รายได้สูงสุด
คำถามมากมายเกี่ยวกับเอกสารอ้างอิงเดียวกัน
ใช่
ข้อความสั้นที่แตกต่างกันอย่างสิ้นเชิงสำหรับแต่ละคำขอ
ไม่ — โบนัสการเขียนสูญเปล่า
ขอครั้งเดียว
ไม่ — ไม่มีการอ่านเลย
วันที่/ID เปลี่ยนแปลงไปตามแต่ละคำขอที่พร้อมท์ของระบบ
ไม่ — คำนำหน้าใช้งานไม่ได้ จำนวนการเข้าชมเป็นศูนย์
ทีละขั้นตอน: วิธีการตั้งค่า Hit Prompt?
- แยกค่าคงที่และตัวแปร เนื้อหาใดบ้างที่ไม่เคยเปลี่ยนแปลง (พรอมต์ของระบบ หนังสือกฎ เอกสารประกอบ) การเปลี่ยนแปลงใดกับแต่ละคำขอ (คำถามของผู้ใช้, วันที่, ID)
- ใส่ค่าคงที่ไว้ที่จุดเริ่มต้น ในระหว่างการประมวลผล ส่วนที่มาก่อน (เครื่องมือ ระบบ) จะต้องมีความเสถียร
- ใส่ตัวแปรไว้ท้ายสุด คำถามปัจจุบันของผู้ใช้คือคำถามสุดท้าย
- วางป้ายไว้ที่ส่วนท้ายของเส้นขอบ วางจุดแคชไว้ในบล็อกสุดท้ายของส่วนที่คงที่
- ยืนยันการตี ตรวจสอบว่า cache_read_input_tokens มากกว่าศูนย์ในช่องการใช้งานในการตอบกลับหรือไม่ ถ้าเป็นศูนย์ แสดงว่ามีสิ่งขัดขวางซ่อนอยู่ในคำนำหน้า
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ชั่วคราว" } } ], "ข้อความ": [ { "role": "user", "content": "{{user_current_question}}" } ]}
เคล็ดลับ: อย่าคาดเดาการเข้าถึงแคช แต่ให้วัดดู หากการใช้งาน.cache_read_input_tokens ยังคงเป็นศูนย์ในคำขอที่ต่อเนื่องกัน เบรกเกอร์แบบเงียบ (datetime.now() ที่พรอมต์ของระบบ, JSON ที่ไม่ได้เรียงลำดับ, รายการเครื่องมือที่เปลี่ยนแปลงพร้อมกับคำขอแต่ละรายการ) กำลังทำงานอยู่ เปรียบเทียบพรอมต์ดิบของคำขอทั้งสองแบบไบต์ต่อไบต์และค้นหาความแตกต่าง
ผู้ทำลายความเงียบ
รูปแบบทั่วไปที่ทำให้แคชเสียหายโดยไม่รู้ตัว:
# BREAKER: การฝังข้อมูลในระบบแจ้งให้เปลี่ยนแปลงในแต่ละคำขอ "วันที่วันนี้: {{now}} คุณเป็นผู้ช่วย..." ← คำนำหน้าเปลี่ยนแปลงไปพร้อมกับคำขอแต่ละรายการ hit เป็นศูนย์# TRUE: ย้ายตัวแปรไปที่ระบบข้อความ: "คุณเป็นผู้ช่วย..." ← ค่าคงที่เข้าสู่ข้อความแคช: [{role: ผู้ใช้ เนื้อหา: "วันนี้คือ {{ตอนนี้}} คำถาม: ..."}] ← ตัวแปรในตอนท้าย
เบรกเกอร์อื่นๆ: JSON เรียงลำดับแตกต่างกันในแต่ละคำขอ (เก็บคีย์ไว้ในลำดับคงที่) รายการเครื่องมือที่แตกต่างกันตามผู้ใช้ (เครื่องมือจะได้รับการประมวลผลก่อน ไม่มีสิ่งใดเข้าไปในแคชหากมีการเปลี่ยนแปลง) การเปลี่ยนโมเดลระหว่างการสนทนา (แคชเป็นแบบเฉพาะรุ่น)
พรอมต์ที่อ่อนแอ / พรอมต์ที่รัดกุม (โครงสร้างที่เป็นมิตรกับแคช)
# WEAK (ระบบป้องกันแคช): "วันที่: 18.07.2026 14:32 น. ผู้ใช้: Ahmet (id 8842) คุณเป็นบอทสนับสนุน กฎ: ...(2000 โทเค็น)..."
# ที่แข็งแกร่ง (โครงสร้างที่เป็นมิตรกับแคช) ระบบ: "คุณเป็นบอทสนับสนุน กฎ: ...(โทเค็น 2000 ไม่เคยเปลี่ยนแปลง)..." [เครื่องหมายแคช]ข้อความ: [ { บทบาท: ผู้ใช้ เนื้อหา: "วันที่: 18.07.2026 14:32. รหัสผู้ใช้: 8842 คำถาม: ฉันจะเริ่มการคืนเงินได้อย่างไร" }]
ในเวอร์ชันที่ไม่รัดกุม บล็อกกฎจำนวน 2,000 โทเค็นจะได้รับการประมวลผลด้วยต้นทุนเต็มสำหรับแต่ละคำขอ ในเวอร์ชันที่แข็งแกร่ง บล็อกเดียวกันจะถูกเขียนเพียงครั้งเดียวและอ่านคำขอที่ตามมาทั้งหมดในราคาหนึ่งในสิบ
มินิเคสสามอัน
กรณีที่ 1 — การแคชหนังสือกฎ ระบบการบัญชีอัตโนมัติกำลังเพิ่มสมุดกฎโทเค็น 12,000 รายการไปยังใบแจ้งหนี้แต่ละใบ 5,000 คำขอต่อวัน ต้นทุนอินพุตแบบไร้แคช ~$180 ต่อวัน พวกเขาเก็บกฎเกณฑ์ไว้คงที่และแคชไว้: คำขอแรกจ่ายเบี้ยประกันภัยการเขียน ตามมาอ่าน 0.1× ต้นทุนวัตถุดิบลดลง ~90% เหลือ ~$18 ต่อวัน
กรณีที่ 2 — ต้นทุนของบรรทัดวันที่ที่ซ่อนอยู่ ทีมหนึ่งตั้งค่าแคชแต่ไม่โดนโจมตี cache_read_input_tokens มีค่าเป็นศูนย์เสมอ เหตุผล: มี datetime.now() ในบรรทัดแรกของพรอมต์ระบบ คำนำหน้าเปลี่ยนไปตามแต่ละคำขอ เมื่อเราย้ายวันที่ไปที่ข้อความของผู้ใช้ อัตราการเข้าชมก็เพิ่มขึ้นจาก 0% เป็น 94%
กรณีที่ 3 — แคชวางผิดที่ แอปพลิเคชันการค้นหาส่งข้อความค้นหาสั้น ๆ ที่แตกต่างกันอย่างสิ้นเชิงกับคำขอแต่ละรายการ พวกเขาเพิ่มเครื่องหมายแคชอย่างกระตือรือร้น เนื่องจากไม่มีคำนำหน้าร่วมกัน แต่ละคำขอจึงจ่ายเฉพาะค่าพรีเมียมในการเขียนเท่านั้น ไม่มีการอ่าน — ทำให้ต้นทุนเพิ่มขึ้น พวกเขาถอดป้ายออก บทเรียน: แคชจะจ่ายก็ต่อเมื่อมีคำนำหน้าขนาดใหญ่และคงที่ซึ่งถูกนำมาใช้ซ้ำ
ข้อผิดพลาดทั่วไป
- การผสมค่าคงที่และตัวแปร: เมื่อเนื้อหาตัวแปรอยู่ในคำนำหน้า Hit จะถูกรีเซ็ต
- การฝังวันที่/ID ในพรอมต์ระบบ: ตัวขัดขวางแบบเงียบที่พบบ่อยที่สุด
- ไม่วัดการเข้าชม: หากไม่ได้ตรวจสอบ cache_read_input_tokens จะไม่มีการสังเกตเห็นของเสีย
- การเพิ่มแคชเมื่อไม่มีคำนำหน้าสาธารณะ: คุณจ่ายเฉพาะค่าพรีเมียมการเขียนเท่านั้น ต้นทุนจะเพิ่มขึ้น
- การเปลี่ยนรายชื่อหรือรุ่นรถ: คำนำหน้าพังตั้งแต่ต้น; ทุกอย่างถูกเขียนใหม่
- การลืมขนาดแคชขั้นต่ำ: แคชที่สั้นมาก (ต่ำกว่าโทเค็น ~ 1–4k ขึ้นอยู่กับรุ่น) จะไม่เข้าสู่แคชโดยไม่แจ้งให้ทราบ
เจาะลึก: การออกแบบแคชตามประเภทปริมาณงาน
ผลลัพธ์ที่แท้จริงของการแคชจะแตกต่างกันไปขึ้นอยู่กับลักษณะของปริมาณงานของคุณ เพื่อทำความรู้จักกับการเข้าชมของคุณก่อน สามรูปแบบทั่วไปและการติดตั้งที่ถูกต้อง:
ระบบแจ้งทั่วไป คำถามที่แตกต่างกัน รูปแบบองค์กรที่พบบ่อยที่สุด: พรอมต์ระบบขนาดใหญ่ (บทบาท กฎ อาจเป็นเอกสารอ้างอิง) พร้อมคำถามผู้ใช้ที่แตกต่างกันหลายร้อยข้อ ที่นี่ส่วนที่คงที่ (ระบบ) จะถูกแคชไว้ตั้งแต่แรก คำถามใหม่แต่ละข้อจะจ่ายราคาเต็มเฉพาะในส่วนเล็กๆ เท่านั้น กำไรนั้นสูงมากเพราะท่องส่วนใหญ่ซ้ำ ๆ ในราคาหนึ่งในสิบของราคา
บทพูดคนเดียวหลายรอบ ขณะที่บทสนทนาดำเนินไป แต่ละรอบใหม่จะต่อยอดมาจากประวัติศาสตร์ที่ผ่านมาทั้งหมด หากคุณใส่แฟล็กแคชไว้ที่ส่วนท้ายของรอบที่แล้ว แต่ละคำขอจะใช้คำนำหน้าการสนทนาก่อนหน้าอีกครั้ง ความนิยมสะสมเมื่อการสนทนาเติบโตขึ้น สิ่งนี้ทำให้ต้นทุนของเซสชั่นผู้ช่วยที่ยาวนานลดลงอย่างมาก
คำนำหน้าที่ใช้ร่วมกันคือบิตสุดท้ายที่ต้องเปลี่ยนแปลง คำขอหลายรายการใช้ชุดลำดับความสำคัญคงที่ร่วมกันจำนวนมาก (ชุดตัวอย่าง คำแนะนำ) แต่จะคั่นด้วยคำถามเดียวในตอนท้าย คุณวางตัวชี้แคชไว้ที่ส่วนท้ายของส่วนที่แชร์ มิฉะนั้น แต่ละคำขอจะเขียนแคชแยกกันและจะไม่มีการอ่านแคชใดเลย
ข้อแม้ประการหนึ่ง: แคชขึ้นอยู่กับรุ่นและขนาดขั้นต่ำที่แน่นอน คำนำหน้าที่มีขนาดเล็กมาก (ภายใต้โทเค็นไม่กี่พันรายการ ขึ้นอยู่กับรุ่น) จะไม่เข้าสู่แคชอย่างเงียบๆ แม้ว่าคุณจะตั้งค่าสถานะก็ตาม — cache_creation_input_tokens ยังคงเป็นศูนย์ นอกจากนี้ การเปลี่ยนโมเดลระหว่างการสนทนาจะทำให้แคชทั้งหมดเป็นโมฆะ หากงานอื่นต้องใช้โมเดลราคาถูก ให้เก็บโฟลว์หลักไว้ในโมเดลเดียว และแยกงานรองออกจากกัน
โดยสรุป
การแคชพร้อมต์เป็นการจับคู่คำนำหน้า: เนื้อหาคงที่ควรอยู่ที่จุดเริ่มต้น เนื้อหาที่แปรผันควรอยู่ที่ส่วนท้าย สำหรับบริบทขนาดใหญ่ที่นำกลับมาใช้ใหม่ ค่าใช้จ่ายในการอ่านคือหนึ่งในสิบของราคาเต็ม ซึ่งคิดเป็นสองเท่าโดยประมาณ ข้อผิดพลาดที่พบบ่อยที่สุดคือการทำให้คำนำหน้าเสียหายโดยการฝังข้อมูลตัวแปรไว้ในพรอมต์ของระบบ คุณตรวจสอบการเข้าชมโดยการวัดในช่องการใช้งาน
งานสมัคร
เลือกปริมาณงาน (1) แบ่งเนื้อหาออกเป็นสองคอลัมน์: "ไม่เคยเปลี่ยนแปลง" และ "เปลี่ยนแปลงทุกคำขอ" (2) วาดโครงสร้างพร้อมต์ใหม่ โดยวางส่วนที่คงที่ไว้ที่จุดเริ่มต้นและส่วนที่แปรผันอยู่ที่ส่วนท้าย (3) ประมาณขนาดโทเค็นของชิ้นส่วนที่คงที่ และเปรียบเทียบค่าใช้จ่ายรายเดือนที่มี/ไม่มีแคช (4) สังเกตว่าฟิลด์ใด (cache_read_input_tokens) ที่คุณจะตรวจสอบการเข้าชม
รายการตรวจสอบ
- [ ] ฉันสามารถอธิบายได้ว่าแคชเป็นการจับคู่คำนำหน้าและเป็นกฎเดียวที่ไม่เปลี่ยนรูป
- [ ] ฉันสามารถเพิ่มความแม่นยำได้โดยใส่เนื้อหาคงที่ไว้ที่จุดเริ่มต้นและใส่ตัวแปรไว้ท้ายสุด
- [ ] ฉันรู้เศรษฐศาสตร์การเขียน/การอ่าน และจุดคุ้มทุนสองคำขอ
- [ ] ฉันสามารถจดจำผู้รบกวนแบบเงียบๆ ได้ (วันที่, JSON ที่ไม่ได้เรียงลำดับ, รายชื่อยานพาหนะที่เปลี่ยนแปลง)
- [ ] ฉันสามารถตรวจสอบ Hit ได้ด้วยการใช้งาน.cache_read_input_tokens