Prompt caching คืออะไร? พรอมต์ที่ซ้ำถูกนำกลับมาใช้อย่างไร

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

บอทซัพพอร์ตที่อ่านหน้าเดิมซ้ำแล้วซ้ำเล่า#

สมมติว่าคุณดูแลบอทซัพพอร์ตที่มีตั๋ว 2,000 ใบต่อวัน ทุกคำขอเริ่มต้นด้วย 3,000 โทเคนเดียวกัน: โทนเสียง กฎการคืนเงิน นโยบายการจัดส่ง หลังจากนั้นคือข้อความลูกค้าบรรทัดเดียว ประมาณว่า "พัสดุของฉันอยู่ไหน?" (หากยังไม่คุ้นกับโทเคน เริ่มจาก โทเคนคืออะไร)

หากไม่มีการแคช ผู้ให้บริการจะอ่านกฎ 3,000 โทเคนทั้งหมดอีกครั้งสำหรับตั๋วใบที่ 1 ใบที่ 2 และใบที่ 2,000 หน้าเดิม อ่าน 2,000 ครั้ง ด้วยการแคช คำขอแรกจ่ายเต็มราคาของการอ่าน และคำขอถัดไปที่เริ่มต้นด้วยข้อความเดียวกันสามารถนำงานนั้นกลับมาใช้ได้

คู่มือ API ของ DeepSeek (ตรวจสอบเมื่อ 24 ตุลาคม 2026) อธิบายไว้ตรงนี้ว่า context caching เปิดใช้โดยค่าเริ่มต้น ไม่ต้องแก้โค้ด และคำขอถัดไปที่มีคำนำหน้าทับซ้อนกันนับเป็น "cache hit" เฉพาะอินพุตเท่านั้นที่ถูกแคช คำตอบถูกสร้างใหม่ทุกครั้ง

อะไรนับว่า "เหมือนกัน": กฎคำนำหน้า#

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

นี่คือข้อผิดพลาดที่ฆ่าการแคชอย่างเงียบ ๆ นักพัฒนาต้องการให้บอทรู้เวลาและวางไว้ที่ด้านบน:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

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

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

ตอนนี้ 3,000 โทเคนของกฎมาอยู่ก่อนและคงเดิม ตรรกะเดียวกันครอบคลุมอีกสองกรณีทั่วไป: แชทยาวส่งประวัติทั้งหมดซ้ำในแต่ละรอบ ข้อความเก่าจึงเป็นจุดเริ่มต้นที่ซ้ำได้พร้อมใช้ (เพิ่มเติมใน ทำไมแชทยาวจึงมีค่าใช้จ่ายสูงขึ้น) และเอเจนต์ส่งคำจำกัดความเครื่องมือและคำสั่งซ้ำในทุกขั้นตอน

การแคชยังเป็นแบบ best-effort DeepSeek ระบุว่าแคชใช้เวลาสร้างไม่กี่วินาที การ hit ต้องตรงกับหน่วยคำนำหน้าแคชที่มีอยู่ทั้งหมด ไม่มีการรับประกันอัตราการ hit และแคชที่ไม่ได้ใช้จะถูกล้าง โดยปกติภายในไม่กี่ชั่วโมงถึงหลายวัน ดังนั้นคำขอที่สองที่ยิงห่างจากคำขอแรกครึ่งวินาทีอาจยังไม่ hit และการ hit อาจครอบคลุมน้อยกว่าคำนำหน้าทั้งหมดของคุณ

วิธีดู: ฟิลด์แคชใน usage#

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

DeepSeek ใช้สองฟิลด์:

• prompt_cache_hit_tokens — โทเคนอินพุตที่พบในแคช
• prompt_cache_miss_tokens — โทเคนอินพุตที่ไม่ได้พบ

สมมติตั๋วซัพพอร์ตใบแรกตอบกลับมาด้วย prompt_cache_hit_tokens: 0 และ prompt_cache_miss_tokens: 3200 และตั๋วอีกใบหนึ่งนาทีต่อมาแสดง prompt_cache_hit_tokens: 3000 และ prompt_cache_miss_tokens: 200 กฎ 3,000 โทเคนถูกนำกลับมาใช้ มีเพียงข้อความลูกค้าใหม่และโทเคนอีกเล็กน้อยที่อ่านใหม่ตั้งแต่ต้น หากตัวเลข hit ยังเป็นศูนย์ในทุกการเรียก ให้ดูที่จุดเริ่มต้นของคำขอ: มีบางอย่างในนั้นที่เปลี่ยนแปลง

Anthropic ทำงานต่างออกไป เพราะคุณเป็นผู้กำหนดสิ่งที่จะแคช คุณเพิ่ม cache_control พร้อม type ephemeral ลงในคำขอหรือใน content block:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

ตามเอกสาร prompt caching ของ Anthropic (ตรวจสอบเมื่อ 24 ตุลาคม 2026) คำตอบรายงานสามตัวเลข: cache_creation_input_tokens (เขียนลงแคชตอนนี้), cache_read_input_tokens (อ่านจากแคช) และ input_tokens (สิ่งที่มาหลัง cache breakpoint สุดท้าย) สมมติการเรียกครั้งแรกแสดง cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; ครั้งที่สองแสดง 0 และ 10000 นั่นคือการเขียนแคชตามด้วยการอ่านแคช

มีกับดักหนึ่งจุดบนหน้าจอ พรอมต์ที่สั้นกว่าขั้นต่ำของโมเดล (512, 1,024 หรือ 4,096 โทเคน ขึ้นอยู่กับโมเดล) จะถูกประมวลผลโดยไม่มีการแคชและไม่มีข้อผิดพลาด คุณจะเห็นศูนย์ในฟิลด์แคชทั้งสองและไม่มีคำเตือน อายุการใช้งานเริ่มต้นคือ 5 นาที รีเฟรชฟรีทุกครั้งที่ใช้; ttl แบบไม่บังคับของ 1h ทำให้เก็บได้นานขึ้น

มันส่งผลต่อบิลของคุณอย่างไร#

การแคชเปลี่ยนราคาของส่วนที่ซ้ำ จึงคุ้มค่าที่จะคำนวณสักครั้ง Anthropic ระบุตัวคูณบนราคาอินพุตฐาน: การเขียนแคชด้วยอายุ 5 นาทีมีค่า 1.25× การอ่านมีค่า 0.1× (0.05× สำหรับ Opus 5.5 และ Sonnet 5.5) สมมติคำนำหน้า 10,000 โทเคนถูกใช้ซ้ำใน 20 คำขอภายในหน้าต่าง 5 นาที โดยใช้การอ่านมาตรฐาน 0.1×:

10,000 × 20 = 200,000 โทเคนที่ราคาฐานหากไม่มีการแคช

10,000 × 1.25 = 12,500 สำหรับคำขอแรกที่เขียนแคช

19 × 10,000 × 0.1 = 19,000 สำหรับ 19 คำขอที่อ่านแคช

12,500 + 19,000 = 31,500 โทเคนเทียบเท่าด้วยการแคช

ดังนั้นส่วนที่ซ้ำมีค่าใช้จ่ายต่ำกว่าหนึ่งในห้าของจำนวนที่ไม่แคชมาก ข้อควรระวัง: หาก 5 นาทีหมดไประหว่างคำขอ คำขอถัดไปจะเขียนแคชใหม่ที่ 1.25× และคำนำหน้าที่ใช้น้อยอาจมีค่าใช้จ่ายมากกว่าการไม่แคชเลย

ตอนนี้บอทจากตอนต้น เป็น baseline ราคาเต็มธรรมดา 2,000 คำขอต่อวัน อินพุต 3,000 โทเคนและเอาต์พุตประมาณ 300 โทเคนต่อครั้ง:

2,000 × 3,000 = 6,000,000 โทเคนอินพุตต่อวัน

2,000 × 300 = 600,000 โทเคนเอาต์พุตต่อวัน

ตารางแสดงราคาภาระงานของวันนั้นบนทุกโมเดล CheapTokens ที่มี เทียบกับ OpenRouter:

DeepSeek-V4-Flash ถูกกว่า OpenRouter โดยรวม เมื่อนับอินพุตและเอาต์พุตรวมกัน และภาระงานพอดีได้สบาย: context 380K และเอาต์พุตสูงสุด 32,768 โทเคนต่อคำตอบ นี่คือค่าใช้จ่ายราคาเต็มของภาระงาน: โทเคนอินพุต × ราคาต่อโทเคน คำนำหน้ายาวที่คงที่คือจุดที่สัดส่วนอินพุตนั้นมากที่สุด

ลองด้วยตัวเองในห้านาที#

แผน: ส่ง system prompt ยาวเดียวกันสองครั้งด้วยคำถามต่างกัน แล้วดูที่ usage ใส่ข้อความกฎของคุณเองใน support_rules.txt (ข้อความหนึ่งหรือสองหน้าก็เพียงพอ) endpoint คือ CheapTokens API ที่เข้ากันได้กับ OpenAI และคุณสามารถรับคีย์จากบัญชีของคุณ

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

สิ่งที่ต้องตรวจในผลลัพธ์: prompt_tokens บอกคุณว่าคำขอของคุณใหญ่แค่ไหน ทั้งสองคำขอมีข้อความ SYSTEM เดียวกัน ดังนั้นตัวเลขส่วนใหญ่ซ้ำจากคำขอหนึ่งไปอีกคำขอ — ประมาณขนาดไฟล์กฎของคุณ จุดเริ่มต้นที่ซ้ำนั้นคือส่วนที่ผู้ให้บริการที่มีการแคช เช่น DeepSeek API หรือ Anthropic ข้างต้น สามารถนำกลับมาใช้ได้ ตอนนี้แบบฝึกหัดเรื่องลำดับ: เพิ่มบรรทัดที่มีเวลาปัจจุบัน (datetime.now()) ที่ด้านบนของ SYSTEM แล้วรันอีกครั้ง คำขอทั้งสองไม่แชร์จุดเริ่มต้นอีกต่อไป เพราะต่างกันตั้งแต่บรรทัดแรก วางบรรทัดเดียวกันไว้ท้ายพรอมต์แล้วจุดเริ่มต้นที่แชร์ก็กลับมา

เช็กลิสต์สั้น ๆ สำหรับพรอมต์ของคุณเอง:

1. ข้อความคงที่ก่อน: คำสั่ง กฎ คำจำกัดความเครื่องมือ ตัวอย่าง
2. ข้อความที่เปลี่ยนแปลงทีหลัง: วันที่ ชื่อผู้ใช้ ข้อความล่าสุด
3. ทำให้คำนำหน้าเหมือนกันทุกไบต์ — แม้แต่ช่องว่างเกินหนึ่งตัวก็มีผล
4. ตรวจสอบขนาดขั้นต่ำของผู้ให้บริการก่อนสงสัยว่าทำไมไม่มีอะไรถูกแคช
5. ดูฟิลด์ usage หลังการเปลี่ยนแปลง ไม่ใช่ก่อน

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