พูดง่าย ๆ Prompt Caching ของ Anthropic อนุญาตให้คุณ "ตรึง" (pin) ส่วนของ prompt ที่ใช้ซ้ำบ่อย ๆ ไว้ในแคชความเร็วสูง เช่น system instructions, ตัวอย่าง few-shot, เอกสารอ้างอิง, หรือ tool definitions เมื่อคุณส่ง request ถัดไปที่มี prefix เดียวกัน Claude จะอ่านจากแคชแทนการประมวลผลใหม่ทั้งหมด ผลคือเร็วขึ้นและถูกลงทันที
โครงสร้างราคา (พฤษภาคม 2026)
- Cache write (5 นาที TTL): 1.25× ของราคา input token ปกติ
- Cache write (1 ชั่วโมง TTL): 2× ของราคา input token ปกติ
- Cache hit (read): 0.1× (เพียง 10%) ของราคา input token ปกติ
- Output tokens: ราคาปกติ ไม่เปลี่ยนแปลง
แปลว่า การ "เขียนเข้าแคช" ครั้งแรกแพงขึ้นนิดหน่อย แต่ทุก hit ถัดไปประหยัดถึง 90% สำหรับ tokens ส่วนนั้น สูตรง่าย ๆ ที่ผมใช้ตัดสินใจ: ถ้าคาดว่าจะ hit แคชอย่างน้อย 2-3 ครั้งภายใน TTL ก็คุ้มทุนแน่นอน
เมื่อไหร่ที่ Prompt Caching ทำให้คุ้มค่าที่สุด
1. แชทบอทที่มีบริบทยาว
เก็บประวัติบทสนทนาและ system instructions ไว้ในแคช ผู้ใช้ส่งข้อความสั้น ๆ ก็จริง แต่ Claude มองเห็นทั้งหมด มีเคสจริงที่ผมประทับใจ — บริษัทกฎหมายแห่งหนึ่งใช้ Claude วิเคราะห์สัญญายาว 80K tokens ต่อ session ลดต้นทุนไปได้ 87% หลังเปิดแคช (ใช่ครับ แค่เปิด feature เดียว)
2. RAG pipelines ที่มี knowledge base ขนาดใหญ่
เอกสารอ้างอิงที่ retrieve มาจาก vector database มักซ้ำกันระหว่าง queries หากออกแบบให้ chunks เรียงตามลำดับเดียวกัน คุณจะได้ cache hit สูงมาก
3. Agent ที่ใช้ tools เยอะ
Tool definitions ขนาด 5-10K tokens ถูก resend ทุก turn — เหมาะมากสำหรับ cache จริง ๆ
4. การประมวลผล batch
เมื่อรันการวิเคราะห์เอกสารเดียวกันหลาย queries เช่น "สรุปประเด็นหลัก", "ค้นหา risk", "แปลภาษา" ที่ใช้ document เดียวกัน คุณจะเห็น cache hit ratio เกือบ 100%
โค้ดตัวอย่าง: เริ่มต้นใช้งานใน 5 นาที
การติดตั้ง
pip install anthropic==0.45.0
ตัวอย่างพื้นฐาน: Cache system prompt
import anthropic
client = anthropic.Anthropic()
# เอกสารอ้างอิงขนาดใหญ่ที่จะใช้ซ้ำ
with open("legal_handbook.txt") as f:
handbook = f.read() # สมมติว่ายาว 50,000 tokens
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "คุณเป็นที่ปรึกษากฎหมายที่ตอบคำถามจากคู่มือเท่านั้น"
},
{
"type": "text",
"text": handbook,
"cache_control": {"type": "ephemeral"}
}
],
messages=[
{"role": "user", "content": "ข้อ 7 พูดเรื่องอะไร?"}
]
)
print(response.usage)
# ครั้งแรก: cache_creation_input_tokens=50000, cache_read_input_tokens=0
# ครั้งที่ 2 ภายใน 5 นาที: cache_creation_input_tokens=0, cache_read_input_tokens=50000
สังเกตบรรทัด cache_control นั่นแหละ — แค่ key เดียวเปลี่ยนชีวิต
การใช้ TTL 1 ชั่วโมงสำหรับ workload ที่ต้องการความเสถียร
system=[
{
"type": "text",
"text": handbook,
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}
]
TTL 1 ชั่วโมงเหมาะกับ batch jobs หรือระบบที่มี request เข้ามาเป็นช่วง ๆ ห่างเกิน 5 นาที (เช่น cron ที่รันทุก 10 นาที)
การ Cache หลายชั้น (Cache Breakpoints)
Anthropic อนุญาตให้ตั้ง cache breakpoint ได้สูงสุด 4 จุด ใช้ประโยชน์เพื่อแยก static content ออกจาก dynamic content แบบนี้:
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=[
# ชั้น 1: คงที่ตลอด - system instructions
{
"type": "text",
"text": SYSTEM_INSTRUCTIONS,
"cache_control": {"type": "ephemeral", "ttl": "1h"}
},
# ชั้น 2: คงที่ต่อ user - profile
{
"type": "text",
"text": user_profile,
"cache_control": {"type": "ephemeral"}
},
# ชั้น 3: คงที่ต่อ session - retrieved docs
{
"type": "text",
"text": retrieved_documents,
"cache_control": {"type": "ephemeral"}
}
],
messages=conversation_history + [{"role": "user", "content": query}]
)
การวัดผลและคำนวณ ROI
ทุก response จะมี usage object ที่บอก cache metrics ผมแนะนำให้ wrap ฟังก์ชันแบบนี้ไว้ใช้:
def calculate_savings(usage, model_pricing):
"""คำนวณค่าใช้จ่ายและการประหยัด"""
base_input = model_pricing["input_per_million"] / 1_000_000
# ราคาจริงที่จ่าย
write_cost = usage.cache_creation_input_tokens * base_input * 1.25
read_cost = usage.cache_read_input_tokens * base_input * 0.1
normal_cost = usage.input_tokens * base_input
actual = write_cost + read_cost + normal_cost
# ราคาถ้าไม่ใช้ cache
total_input = (
usage.cache_creation_input_tokens
+ usage.cache_read_input_tokens
+ usage.input_tokens
)
without_cache = total_input * base_input
savings_pct = (1 - actual / without_cache) * 100 if without_cache else 0
return {
"actual_cost_usd": actual,
"without_cache_usd": without_cache,
"savings_pct": round(savings_pct, 1)
}
# ใช้กับ Sonnet 4.6: $3 per million input tokens
pricing = {"input_per_million": 3.0}
print(calculate_savings(response.usage, pricing))
รูปแบบสถาปัตยกรรมขั้นสูง
Pattern 1: Hierarchical Cache สำหรับ Multi-tenant SaaS
แอป SaaS ที่ให้บริการลูกค้าหลายราย ใช้ cache breakpoints แบ่งชั้นแบบนี้:
- Global system prompt (cache 1h) — ใช้ร่วมทุก tenant
- Tenant configuration (cache 5m) — ใช้ซ้ำในระหว่าง active session
- User session context (no cache) — เปลี่ยนทุก message
Pattern 2: Cache Warming
สำหรับ workload ที่คาดเดาได้ ให้ "อุ่นเครื่อง" cache ล่วงหน้า — เทคนิคนี้ช่วย user คนแรกที่เข้ามาในเช้าวันจันทร์ไม่ต้องเป็นคน "จ่ายค่าเขียนแคช":
async def warm_cache(documents):
"""เรียก dummy request เพื่อให้ Anthropic cache เอกสาร"""
await client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1,
system=[{
"type": "text",
"text": documents,
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}],
messages=[{"role": "user", "content": "ping"}]
)
Pattern 3: Cache สำหรับ Tool Use
ใส่ cache_control บน tool definition ตัวสุดท้าย ระบบจะ cache ทั้ง array ให้:
tools = [
{"name": "search_db", "description": "...", "input_schema": {...}},
{"name": "send_email", "description": "...", "input_schema": {...}},
{
"name": "calculate",
"description": "...",
"input_schema": {...},
"cache_control": {"type": "ephemeral"}
}
]
ข้อผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง
1. Cache miss เพราะ prefix เปลี่ยน
การ cache จะ hit ก็ต่อเมื่อ prefix byte-for-byte ตรงกันทุกประการ แม้แต่ช่องว่างหรือเครื่องหมายวรรคตอนเปลี่ยนนิดเดียวก็ miss ได้ (ผมเคยเสียเวลาครึ่งวันเพราะตัว trailing newline เปลี่ยนไป) ตรวจสอบโดย serialize content แบบเดียวกันทุกครั้ง
2. ขนาดต่ำกว่าขั้นต่ำ
Sonnet 4.6 และ Opus 4.7 ต้องการอย่างน้อย 1,024 tokens ต่อ cache breakpoint, ส่วน Haiku 4.5 ต้องการ 2,048 tokens หากต่ำกว่านี้ระบบจะ ignore cache_control ของคุณแบบเงียบ ๆ ไม่บอกอะไรเลย
3. การวาง content แบบ dynamic ก่อน static
Cache คือ prefix cache — ถ้าคุณวาง timestamp หรือข้อมูล dynamic ไว้ก่อน static content ที่ตามมาจะไม่มีวัน cache hit เลยสักครั้ง กฎข้อเดียวที่ต้องจำ: static ก่อน, dynamic หลัง เสมอ
4. ไม่ตรวจ usage metrics
ระบบจะ ไม่ ส่ง error เมื่อ cache miss — มันแค่คิดเงินเต็มราคาให้คุณเฉย ๆ ดังนั้นต้อง log cache_read_input_tokens และตั้ง alert ไว้ ถ้าค่าต่ำกว่าที่คาด
5. ใช้ TTL ไม่เหมาะกับ workload
5 นาทีสำหรับ interactive chat, 1 ชั่วโมงสำหรับ batch หรือ analytics — เลือกผิดก็ต้องจ่าย write cost ซ้ำ ๆ โดยไม่ได้ benefit อะไร
การเปรียบเทียบกับทางเลือกอื่น
| วิธีการ | ลดต้นทุน | ลด latency | ความซับซ้อน |
|---|
| Prompt Caching | สูงสุด 90% | สูงสุด 85% | ต่ำ |
| Batch API | 50% | ไม่ลด (async) | ต่ำ |
| Fine-tuning | แปรผัน | แปรผัน | สูง |
| Smaller model | 5-10× | 2-3× | ปานกลาง (คุณภาพลด) |
ที่หลายคนยังไม่รู้คือ คุณสามารถ รวม Prompt Caching กับ Batch API ได้ ผลลัพธ์ที่ผมเห็นกับตา: ประหยัดสูงสุดถึง 95% สำหรับงาน offline analysis
Checklist ก่อนนำขึ้น production
- วาง static content ทั้งหมดไว้ก่อน dynamic content
- ขนาดของแต่ละ cache breakpoint ≥ 1,024 tokens (Sonnet/Opus) หรือ 2,048 tokens (Haiku)
- ตั้ง logging สำหรับ
cache_read_input_tokens และ cache_creation_input_tokens
- เลือก TTL ตาม access pattern จริง (วัดจาก production traffic ไม่ใช่เดา)
- ทดสอบ cache hit ratio ใน staging ด้วย load ที่ realistic
- มี fallback หาก cache miss (เช่น degrade เป็น smaller context)
คำถามที่พบบ่อย (FAQ)
Prompt Caching ของ Claude แตกต่างจาก OpenAI Prompt Caching อย่างไร?
OpenAI เปิด caching แบบ automatic (ไม่ต้องระบุ cache_control) แต่ลดราคาเพียง 50% และไม่มีตัวเลือก TTL ส่วน Anthropic ต้องตั้ง cache_control เอง แต่ลดได้สูงถึง 90% และเลือก TTL ได้ 5 นาทีหรือ 1 ชั่วโมง — สรุปคือควบคุมได้มากกว่าและประหยัดมากกว่าในงานที่มี long context
Cache ถูก share ระหว่าง API keys หรือไม่?
ไม่ — cache ถูก isolate ตาม organization ดังนั้น request จากองค์กรอื่นจะไม่ hit แคชของคุณแน่นอน ส่วน API keys หลายตัวภายในองค์กรเดียวกันใช้ cache ร่วมกันได้
จะรู้ได้อย่างไรว่า cache hit จริง?
ตรวจ response.usage.cache_read_input_tokens — ถ้า > 0 แสดงว่ามี hit; ส่วน cache_creation_input_tokens > 0 แสดงว่าเป็นการเขียนแคชใหม่ (ครั้งแรกหรือหลัง TTL หมด)
Prompt Caching ใช้ได้กับ streaming responses หรือไม่?
ใช้ได้ทุกโหมดเลย — streaming, non-streaming, tool use และ vision การตั้ง cache_control ไม่กระทบรูปแบบ response แต่อย่างใด
เมื่อไหร่ไม่ควรใช้ Prompt Caching?
หาก prompt ของคุณเปลี่ยนทุก request (เช่น เรียงลำดับ retrieved docs ต่างกันทุกครั้ง) หรือขนาดต่ำกว่าขั้นต่ำของ model การเปิด cache จะทำให้จ่ายเพิ่ม 25% โดยไม่ได้ประโยชน์ — วัด cache hit ratio ก่อนเสมอ
สรุป
Prompt Caching เป็นหนึ่งใน optimization ที่ให้ ROI สูงที่สุดในงาน LLM production เท่าที่ผมเคยใช้มา ติดตั้งใช้เวลาไม่ถึง 30 นาที แต่ลดต้นทุนได้สูงสุด 90% และเร่งความเร็ว 5-10 เท่าสำหรับ workload ที่มี long context
เริ่มจากการระบุส่วน static ที่สุดของ prompt (system instructions, knowledge base, tool definitions) แล้วเพิ่ม cache_control, จากนั้น monitor cache hit ratio จาก usage metrics แล้วค่อย ๆ ขยายไปยัง cache breakpoints หลายชั้นตามขนาด workload
ขั้นถัดไป: ลองรวม Prompt Caching เข้ากับ MCP Server ที่เราได้สร้างไว้ก่อนหน้านี้ เพื่อ cache tool definitions และเอกสารอ้างอิงในงาน agent ที่ซับซ้อน — น่าจะเห็นบิลค่า API ลดลงอย่างมีนัยสำคัญในเดือนถัดไป
