Prompt caching และ KV cache คืออะไร ช่วยลดค่า token ได้จริงไหม

แชตบอตที่แนบคู่มือสินค้าหมื่นกว่า token ไปกับทุกคำถาม หรือ coding agent ที่ส่งประวัติงานทั้งก้อนซ้ำทุกรอบ ล้วนจ่ายค่า input ส่วนเดิมซ้ำไปซ้ำมา prompt caching คือกลไกที่ทำให้ส่วนที่ซ้ำนี้ถูกลงหลายเท่า ส่วน KV cache คือกลไกข้างในโมเดลที่ทำให้เรื่องนี้เป็นไปได้

KV cache คืออะไร ทำไมโมเดลต้องมี

KV cache คือหน่วยความจำบน GPU ที่โมเดลเก็บค่า key และ value ของทุก token ที่อ่านหรือเขียนไปแล้ว เพื่อให้ตอนสร้าง token ถัดไปไม่ต้องคำนวณ token เก่าทั้งหมดใหม่ KV cache อยู่แค่ในคำขอเดียว พอตอบเสร็จก็ถูกทิ้ง

การตอบหนึ่งครั้งมีสองช่วง ช่วงแรกเรียก prefill โมเดลอ่าน prompt ทั้งก้อนพร้อมกันแล้วสร้าง KV cache ของทุก token ช่วงที่สองเรียก decode โมเดลเขียนคำตอบทีละ token โดยอ่าน KV cache ที่มีอยู่ แล้วเพิ่มค่าของ token ใหม่ต่อท้าย ถ้าไม่มี KV cache การเขียนคำตอบยาวๆ จะช้าลงเรื่อยๆ เพราะต้องคำนวณย้อนทั้งข้อความทุกครั้ง

ราคาของความเร็วนี้คือหน่วยความจำ ขนาดของ KV cache โตตามจำนวน token

KV cache (bytes) = 2 × จำนวน layer × จำนวน KV head × head dim × bytes ต่อค่า × จำนวน token

ตัวอย่างโมเดลสมมติที่มี 48 layer, 8 KV head, head dim 128 และเก็บค่าแบบ FP16 (2 bytes) จะใช้ 2 × 48 × 8 × 128 × 2 = 196,608 bytes หรือ 192 KB ต่อ token ถ้า context ยาว 128K token (131,072 token) KV cache จะกิน 24 GB ต่อคำขอเดียว นี่คือเหตุผลที่ context ยาวกิน VRAM มาก (ดูสูตรเต็มใน GPU สำหรับรัน LLM ต้องใช้ VRAM เท่าไร)

Prompt caching คืออะไร ต่างจาก KV cache อย่างไร

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

ในเซิร์ฟเวอร์ที่รันเอง สองเรื่องนี้ต่อกันตรงๆ เอกสารของ vLLM อธิบายว่า Automatic Prefix Caching คือการเก็บ KV cache ของคำขอเก่าไว้ ถ้าคำขอใหม่มีส่วนต้นตรงกันก็ใช้ KV cache นั้นซ้ำ และข้ามการคำนวณส่วนที่ซ้ำไป

ผลพลอยได้คือช่วง prefill สั้นลง คำตอบคำแรกจึงมาเร็วขึ้นเมื่อ prompt ยาว เรื่องนี้อธิบายต่อใน TTFT และ Tokens per second คืออะไร

Prompt caching ของ OpenAI, Claude, Gemini และ DeepSeek ต่างกันอย่างไร

ณ พฤศจิกายน 2569 ทั้งสี่เจ้ามี prompt caching แต่เปิดใช้ อายุ cache และวิธีคิดเงินไม่เหมือนกัน ตัวเลขราคาในตารางเทียบกับราคา input ปกติของรุ่นนั้น

ข้อสังเกตจากเอกสารแต่ละเจ้า

• OpenAI รุ่นก่อน GPT-5.6 ทำ cache ให้อัตโนมัติและไม่มีค่าเขียน อายุ cache ตั้งด้วย prompt_cache_retention แบบ in_memory อยู่ราว 5–10 นาทีเมื่อไม่มีคำขอ ส่วน 24h เก็บได้นานสุด 24 ชั่วโมง
• Claude prompt ที่สั้นกว่าขั้นต่ำจะไม่ถูก cache และ API ไม่แจ้ง error
• Gemini 4 ใช้ได้แค่ implicit caching เอกสารแนะนำให้วางเนื้อหาใหญ่ที่ใช้ร่วมกันไว้ต้น prompt
• DeepSeek ระบุว่า cache เป็นแบบ best effort คำขอที่ส่วนต้นตรงกันก็อาจไม่ hit ทุกครั้ง

ตัวอย่างคำขอ Claude API ที่ขอให้ cache คำสั่งระบบซึ่งยาวและไม่เปลี่ยน

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    { "type": "text",
      "text": "<คู่มือสินค้าและนโยบายร้าน ยาวราว 20,000 token>",
      "cache_control": { "type": "ephemeral" } }
  ],
  "messages": [{ "role": "user", "content": "สั่งของวันนี้ ได้ของวันไหน" }]
}

เช็กว่า cache ทำงานจริงจาก usage ในคำตอบ Claude แยกเป็น cache_creation_input_tokens กับ cache_read_input_tokens OpenAI ใช้ usage.input_tokens_details.cached_tokens ส่วน DeepSeek ใช้ prompt_cache_hit_tokens และ prompt_cache_miss_tokens

Prompt caching ลดค่า API ได้เท่าไร

ในงานที่ส่วนต้นของ prompt ยาวและซ้ำทุกคำขอ prompt caching ลดค่า input ได้มากกว่า 90% ตัวอย่างข้างล่างคิดด้วยราคา claude-sonnet-5-5 ณ พฤศจิกายน 2569 คือ input $2, เขียน cache 5 นาที $2.50 และอ่านจาก cache $0.10 ต่อ 1 ล้าน token

สมมติร้านออนไลน์ทำแชตบอตตอบลูกค้า แนบคู่มือและนโยบายร้าน 20,000 token ไปทุกคำถาม มีคำถามวันละ 3,000 ครั้ง ข้อความใหม่ต่อครั้ง 500 token และ cache หมดอายุจนต้องเขียนใหม่วันละ 30 ครั้ง

เดือนละ 30 วัน ค่า input ลดจาก $3,690 เหลือ $313.20 คิดที่ 33.4 บาทต่อดอลลาร์ (อัตราเดียวกับบทความ ราคา LLM API) คือจากราว 123,246 บาท เหลือราว 10,461 บาท ส่วน output ไม่ได้ลด ถ้าคำตอบยาว 300 token จะเป็นค่า output อีกวันละ $9 เท่ากันทั้งสองแบบ

ตัวเลขนี้จะหายไปทันทีถ้าส่วนต้นเปลี่ยนทุกคำขอ เช่น ใส่วันที่และเวลาไว้บรรทัดแรกของคำสั่งระบบ ทุกคำขอจะกลายเป็นการเขียน cache ใหม่ ซึ่งแพงกว่าส่งปกติ 25%

จัด prompt อย่างไรให้ cache ติด

หลักเดียวของ prompt caching คือของที่ไม่เปลี่ยนต้องอยู่หน้าสุด ของที่เปลี่ยนต้องอยู่ท้ายสุด เพราะทุกเจ้าจับคู่จากต้น prompt และ cache จะใช้ได้ถึงตัวอักษรแรกที่ต่างกันเท่านั้น

เช็กลิสต์ก่อนขึ้น production

1. เรียงจากนิ่งไปเปลี่ยน Claude อ่านตามลำดับ tools, system แล้วจึง messages ให้วางนิยามเครื่องมือ คำสั่งระบบ และเอกสารอ้างอิงไว้ก่อน แล้วค่อยต่อประวัติแชตกับคำถามใหม่
2. ย้ายของที่เปลี่ยนทุกครั้งไปท้าย วันที่ เวลา ชื่อผู้ใช้ เลขคำสั่งซื้อ หรือ request id ถ้าอยู่ในคำสั่งระบบ จะทำให้ cache พังทุกคำขอ
3. นิยามเครื่องมือต้องคงที่ เอกสารของ Claude ระบุว่าการแก้ชื่อ คำอธิบาย หรือพารามิเตอร์ของ tool ทำให้ cache ของ tools, system และ messages ใช้ไม่ได้ทั้งหมด การเปิดปิด MCP server กลางงานก็เข้าข่ายนี้
4. serialize ให้เหมือนเดิม สร้าง JSON ด้วยลำดับ key และการเว้นวรรคที่คงที่ เพราะต่างกันแค่ช่องว่างเดียวก็ไม่ hit
5. ประวัติแชตต่อท้ายอย่างเดียว อย่าแก้หรือตัดข้อความเก่าตรงกลาง ถ้าจำเป็นต้องย่อ ให้ยอมรับว่ารอบนั้นจะต้องเขียน cache ใหม่
6. ส่งให้ถี่พอ cache ที่ไม่ถูกใช้จะหมดอายุ เอกสารของ OpenAI แนะนำ prompt_cache_key สำหรับรุ่นก่อน GPT-5.6 และเตือนว่าทราฟฟิกที่เกินราว 15 คำขอต่อนาทีอาจถูกกระจายไปเครื่องอื่นที่ไม่มี cache
7. ดูตัวเลขจริง ถ้า token อ่านจาก cache ยังเป็น 0 ทั้งที่คิดว่าควร hit แปลว่ามีอะไรสักอย่างในส่วนต้นเปลี่ยน ให้เทียบ prompt สองคำขอทีละบรรทัด

ทำไม coding agent ได้ประโยชน์จาก prompt caching มากที่สุด

coding agent ส่งคำสั่งระบบ นิยามเครื่องมือ และประวัติงานทั้งหมดซ้ำทุกรอบ แต่ละรอบเพิ่มของใหม่แค่ผลจากเครื่องมือล่าสุด ส่วนที่ซ้ำจึงมักเป็นสัดส่วนใหญ่ของ input ทุกรอบ ซึ่งเป็นงานที่ prompt caching ช่วยได้มากที่สุด

ลองนึกถึงงานที่ agent วน 40 รอบ แต่ละรอบส่ง context 60,000 token ถ้าไม่มี cache ทุกรอบคิดราคา input เต็ม พอมี cache รอบหนึ่งจะคิดราคาเต็มหรือราคาเขียนเฉพาะส่วนที่เพิ่งเพิ่มเข้ามา ที่เหลือคิดราคาอ่าน จำนวน token ไม่ได้ลดลง แต่บิลลดลงมาก (พื้นฐานเรื่องนี้อยู่ใน Token คืออะไร)

มีอีกสองเรื่องที่คนใช้ agent ควรรู้

• พักนานเกินอายุ cache ข้อความแรกหลังกลับมาต้องเขียน cache ใหม่ทั้งก้อน ถ้า context ใหญ่ รอบนั้นจะแพงกว่ารอบปกติชัดเจน
• cache ช่วยเรื่อง rate limit ด้วย เอกสารของ Anthropic ระบุว่าโควตา input token ต่อนาที (ITPM) ของ Claude คิดเฉพาะ input ที่ไม่ได้อ่านจาก cache ทีมที่ cache ติดดีจึงส่งงานได้มากขึ้นโดยไม่ต้องขอเพิ่ม limit

ใช้ buzzAI ต้องสนใจ prompt caching ไหม

buzzAI เป็น API แบบเหมาจ่ายสำหรับ coding agent ที่ไม่คิดค่า token ชื่อโมเดลคือ Qwen3.8-27B โมเดล open-weight ที่รันบนการ์ด GPU ที่ buzzAI ดูแลเอง ใช้กับ Claude Code, Codex CLI และเครื่องมือที่ตั้ง base URL เองได้ เพราะไม่คิดเงินตาม token ราคาอ่านและเขียน cache ในบทความนี้จึงไม่มีผลกับบิลของคุณ แต่ถ้าทีมยังใช้ API แบบจ่ายตาม token คู่กันไปด้วย หลักการจัด prompt ข้างบนยังใช้ได้เต็มที่

สิ่งที่มีขอบเขตแทน token คือจำนวน agent ที่รันพร้อมกัน ขนาด context ตามแพ็ก และคิวในช่วงที่คนใช้เยอะ ตอนนี้ API ยังไม่เปิดให้ใช้ทั่วไป กดขอร่วมทดสอบได้ที่หน้าแรก รอบปัจจุบันจะเปิดเมื่อมีผู้สมัครครบโควต้าที่กำหนด แล้วเราจะส่ง API key ให้ทางอีเมล ดูแพ็กทั้งหมดได้ที่หน้าราคา