บทความ › AI

ลดค่า AI API ถูกลง 7 เท่า: prompt caching, เลือกโมเดล, Batch และบิลตัวอย่าง

เงินค่า LLM API หายไปตรงไหน และคันโยกเรียงตามผลตอบแทน: prompt caching, โมเดลเล็กสำหรับงานง่าย, Batch API, ตัด output, cache คำตอบ พร้อมบิลรายเดือนทีละขั้น

กลาง อ่าน 8 นาที 22 ตุลาคม 2569

อ่านจบแล้วจะรู้
  • ค่า API ส่วนใหญ่มาจาก input ที่ส่งซ้ำทุกครั้ง (system prompt, เอกสาร, ประวัติแชต) ไม่ใช่คำตอบ
  • ลำดับที่คุ้มสุด: prompt caching ก่อน แล้วแยกงานง่ายไปโมเดลเล็ก แล้วค่อยตัด output และย้ายงานไม่ด่วนไป Batch
  • ในตัวอย่าง บิล $1,140 ต่อเดือนลงเหลือราว $157 โดยไม่เปลี่ยนโมเดลหลักของงานยาก
  • cache คำตอบเองในแอปช่วยเรื่องความเร็วมากกว่าเงิน ถ้าแยกงานง่ายไปโมเดลเล็กแล้ว

บิล AI API ที่บานปลายมักไม่ได้มาจากคำตอบยาว แต่มาจาก input ที่ส่งซ้ำทุกครั้ง system prompt, เอกสารอ้างอิง, ประวัติแชต ที่วนจ่ายราคาเต็มทุก request บทความนี้แยกให้เห็นว่าเงินไปตรงไหน แล้วเรียงคันโยกที่ควรดึงตามผลตอบแทน พร้อมคิดบิลรายเดือนให้ดูทีละขั้น

ตัวเลขราคาตรวจกับหน้า pricing และเอกสาร prompt caching / Batch ของ Anthropic และหน้า pricing ของ OpenAI ณ ตุลาคม 2026 ราคาเปลี่ยนบ่อย ตรวจหน้าเหล่านั้นอีกครั้งก่อนตัดสินใจ

เงินไปตรงไหน

ทุก request คิดเงินสามก้อน

ก้อนคืออะไรลักษณะ
input ที่ซ้ำsystem prompt, คู่มือ, ตัวอย่าง, นิยาม tool, ประวัติแชตเก่าใหญ่ เหมือนเดิมทุกครั้ง
input ใหม่คำถามล่าสุด, ข้อมูลที่ค้นมาเฉพาะครั้งนี้เล็กถึงกลาง
outputคำตอบ (และ token ที่โมเดลใช้คิด ถ้าเปิด)ราคาต่อ token แพงกว่า input 5 เท่า

ราคา ณ ตุลาคม 2026 ต่อหนึ่งล้าน token (MTok)

โมเดลinputเขียน cache (5 นาที)อ่าน cacheoutput
Claude Sonnet 5.5$2$2.50$0.10$10
Claude Haiku 5.5 (prompt ≤ 100K token)$0.10$0.125$0.01$0.50
OpenAI gpt-6.1-sol$2$2.50 (30 นาที)$0.10$10
OpenAI gpt-6-luna$0.10$0.125 (30 นาที)$0.01$0.50

ฝั่ง OpenAI cache เปิดเองโดยอัตโนมัติ prompt ต้องยาวตั้งแต่ 1,024 token รุ่น GPT-5.6 ขึ้นไปคิดค่าเขียน 1.25 เท่าสำหรับ cache อายุขั้นต่ำ 30 นาที

แอปที่มีเอกสารอ้างอิงใน prompt 6,000 token กับคำถาม 1,000 token จ่ายค่า “ส่วนที่ซ้ำ” 6 ใน 7 ของ input ทุกครั้ง นั่นคือเป้าแรก

ตัวอย่างบิล: แชตบอตตอบลูกค้า

สมมติฐานที่ใช้ตลอดบท

  • 2,000 request ต่อวัน × 30 วัน = 60,000 request ต่อเดือน
  • แต่ละ request: ส่วนที่ซ้ำ 6,000 token + ส่วนใหม่ 1,000 token, ตอบเฉลี่ย 500 token
  • ใช้ Claude Sonnet 5.5 ทุกงาน

จุดเริ่ม (ยังไม่ทำอะไร)

  • input: 7,000 × 60,000 = 420M token × $2 = $840
  • output: 500 × 60,000 = 30M token × $10 = $300
  • รวม $1,140 ต่อเดือน

คันโยก 1: prompt caching

prompt caching เก็บผลประมวลผลของส่วนต้นของ prompt ที่เหมือนเดิมทุกตัวอักษร ครั้งต่อไปจ่ายแค่ราคาอ่าน cache บน Sonnet 5.5 อ่าน cache คิด 0.05 เท่าของ input ปกติ ($0.10 แทน $2) แลกกับการเขียน cache ครั้งแรกแพงขึ้น 1.25 เท่า cache แบบ 5 นาทีต่ออายุทุกครั้งที่มีคนอ่าน

วิธีเปิดที่ง่ายสุดคือใส่ cache_control ระดับบนสุดของ request ระบบวางจุด cache ให้เอง

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 600,
  "cache_control": { "type": "ephemeral" },
  "system": "คุณคือผู้ช่วยตอบลูกค้า ... (คู่มือ 6,000 token)",
  "messages": [{ "role": "user", "content": "เปลี่ยนที่อยู่จัดส่งยังไง" }]
}

ดูว่าได้ผลจริงจาก usage ในคำตอบ cache_read_input_tokens ต้องเป็นตัวใหญ่ ถ้าเป็น 0 ตลอด แปลว่า prefix เปลี่ยนทุกครั้ง

คิดบิลใหม่ สมมติว่า cache หมดอายุแล้วต้องเขียนใหม่ราว 300 ครั้งต่อเดือน (ช่วงกลางคืนที่ไม่มีคนใช้เกิน 5 นาที)

  • เขียน cache: 300 × 6,000 = 1.8M × $2.50 = $4.50
  • อ่าน cache: 59,700 × 6,000 = 358.2M × $0.10 = $35.82
  • input ใหม่: 60M × $2 = $120
  • output: $300
  • รวม $460.32 ลดลง 60% โดยไม่แตะคุณภาพ

เรียงของใน prompt จากนิ่งไปเปลี่ยน: tools → system → เอกสาร → ประวัติ → คำถาม อะไรที่เปลี่ยนทุกครั้ง (วันที่, ชื่อผู้ใช้, id) อย่าวางไว้ข้างหน้า

คันโยก 2: ส่งงานง่ายให้โมเดลเล็ก

คำถามส่วนใหญ่ในแชตบอตคือ “เปิดกี่โมง” “ติดตามพัสดุยังไง” โมเดลเล็กตอบได้ดีพอ สมมติวัดแล้วว่า 60% ของ request เป็นงานง่าย ส่งไป Haiku 5.5 ส่วน 40% ที่เหลือยังใช้ Sonnet 5.5 และใช้ Haiku เป็นตัวคัดแยก (อ่านคำถาม 1,000 token ตอบ 20 token)

ส่วนคำนวณเงิน
Sonnet 24,000 reqเขียน $4.50 + อ่าน 142.2M × $0.10 = $14.22 + input ใหม่ 24M × $2 = $48 + output 12M × $10 = $120$186.72
Haiku 36,000 reqเขียน 1.8M × $0.125 = $0.23 + อ่าน 214.2M × $0.01 = $2.14 + input ใหม่ 36M × $0.10 = $3.60 + output 18M × $0.50 = $9$14.97
ตัวคัดแยก60M × $0.10 + 1.2M × $0.50$6.60
รวม$208.29

ข้อควรระวัง: วัดด้วยชุดคำถามจริงของตัวเองก่อนว่า 60% นั้นโมเดลเล็กตอบถูกจริง ไม่ใช่เดา วิธีเลือกโมเดลตามงานเล่าไว้ในบทเลือกโมเดล

คันโยก 3: ตัด context และ output

output แพงกว่า input 5 เท่า สั่งให้ตอบสั้นตามรูปแบบที่กำหนด และตั้ง max_tokens เป็นเพดาน สมมติลดคำตอบเฉลี่ยจาก 500 เหลือ 300 token

  • Sonnet output: 7.2M × $10 = $72 (เดิม $120)
  • Haiku output: 10.8M × $0.50 = $5.40 (เดิม $9)
  • รวมใหม่ $156.69

Sonnet 5.5 เปิด adaptive thinking เป็นค่าเริ่มต้น token ที่ใช้คิดคิดเงินเป็น output ด้วย ถ้างานไม่ซับซ้อน ลด effort ลงจากค่าเริ่มต้น high แล้ววัดว่าคุณภาพยังพอ

ฝั่ง input: อย่าส่งประวัติแชตทั้งหมดทุกรอบ ตัดเหลือไม่กี่รอบล่าสุดหรือสรุปของเก่า และถ้าใช้เอกสาร ให้ค้นเฉพาะชิ้นที่เกี่ยวข้องแทนการแปะทั้งคู่มือ แบบในบทความ RAG

คันโยก 4: Batch API สำหรับงานไม่ด่วน

Batch API ลด 50% ทั้ง input และ output ส่งได้ถึง 100,000 request หรือ 256 MB ต่อ batch ส่วนใหญ่เสร็จในหนึ่งชั่วโมง แต่ถ้าไม่เสร็จใน 24 ชั่วโมงจะหมดอายุ (request ที่หมดอายุไม่คิดเงิน) ราคา cache ซ้อนกับส่วนลด Batch ได้ OpenAI ก็มี Batch ราคาครึ่งหนึ่งเช่นกัน

ใช้กับแชตบอตไม่ได้ แต่ใช้กับงานข้าง ๆ ได้ เช่น ทุกเดือนติดป้ายหัวข้อให้ 60,000 บทสนทนา (input 1,500 output 50 token ต่อชิ้น)

วิธีคำนวณเงิน
Sonnet ปกติ90M × $2 + 3M × $10$210
Sonnet Batchครึ่งหนึ่ง$105
Haiku ปกติ90M × $0.10 + 3M × $0.50$10.50
Haiku Batchครึ่งหนึ่ง$5.25

บทเรียน: เลือกโมเดลถูกตัวมีผลมากกว่า Batch แต่ Batch ฟรีครึ่งหนึ่งทุกครั้งที่งานรอได้

คันโยก 5: cache คำตอบในแอปเอง

ถ้าคำถามซ้ำเป๊ะ เก็บคำตอบใน Redis แล้วตอบเลยไม่ต้องเรียก API (แนวเดียวกับบทความ cache ด้วย Redis) สมมติ 15% ของ request (9,000 ครั้ง) ตอบจาก cache และเช็ก cache ก่อนตัวคัดแยก

  • คำถามซ้ำมักเป็นงานง่ายที่ไป Haiku อยู่แล้ว ต้นทุน Haiku ต่อ request = $11.37 ÷ 36,000 ≈ $0.000316
  • ประหยัด 9,000 × $0.000316 + ค่าคัดแยก 15% ($0.99) ≈ $3.83
  • บิลเหลือ ≈ $152.86

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

สรุปบิล

ขั้นต่อเดือน
จุดเริ่ม$1,140
+ prompt caching$460
+ แยกงานง่ายไป Haiku$208
+ ตัด output$157
+ cache คำตอบ$153

ราว 7 เท่า โดยงานยากยังได้โมเดลเดิม

ตั้ง budget alert และดู usage ราย request ก่อนจะลดอะไร ไม่วัด = เดาว่าเงินไปไหน

เริ่มต้น$1,140+ prompt caching$460+ งานง่ายไป Haiku$208+ ตัด output$157+ cache คำตอบ$153ค่า API ต่อเดือน ตามสมมติฐานในบทความ
บิลเดือนเดียวกัน ลดลงทีละคันโยก ก้อนใหญ่มาจาก caching กับเลือกโมเดล

ข้อผิดพลาดที่เจอบ่อย

  • ใส่ของที่เปลี่ยนทุกครั้งไว้ต้น prompt เช่น timestamp ใน system prompt cache ไม่เคย hit
  • prompt สั้นกว่าขั้นต่ำ Sonnet 5.5 / Haiku 5.5 cache ได้เมื่อยาวตั้งแต่ 512 token สั้นกว่านั้นระบบไม่ cache และไม่แจ้ง error
  • แก้นิยาม tool บ่อย การเปลี่ยน tools ล้าง cache ของ system และ messages ทั้งหมดที่อยู่ถัดไป
  • เทียบราคาข้ามรุ่นด้วยจำนวน token เดิม Claude ตั้งแต่ 4.7 ขึ้นไปใช้ tokenizer ใหม่ ข้อความเดียวกันได้ token มากขึ้นราว 30% วัดใหม่กับรุ่นที่จะใช้
  • Haiku 5.5 กับ prompt เกิน 100K token ราคากระโดดเป็น $0.50 / $2.50 ต่อ MTok ถ้าแปะเอกสารยาว ๆ ต้องคิดใหม่
  • cache ราย 1 ชั่วโมงทั้งที่ traffic ถี่ เขียนแพง 2 เท่า คุ้มเฉพาะเมื่อช่องว่างระหว่าง request เกิน 5 นาทีบ่อย

แหล่งอ้างอิง

คำถามที่พบบ่อย

prompt caching ทำให้คำตอบเปลี่ยนไหม

ไม่เปลี่ยน cache เก็บผลประมวลผลส่วนต้นของ prompt ที่เหมือนเดิมทุกตัวอักษร โมเดลยังคิดคำตอบใหม่ทุกครั้ง สิ่งที่ต่างคือราคาและความเร็วของส่วนที่ซ้ำ

ใช้ Batch API กับแชตบอตได้ไหม

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

ควรเปลี่ยนไปใช้โมเดลถูกสุดเลยไหม

ไม่ควรเปลี่ยนทั้งระบบ ให้วัดก่อนว่างานไหนโมเดลเล็กทำได้ดีพอด้วยชุดทดสอบของตัวเอง แล้วส่งเฉพาะงานนั้นไป งานที่ตอบผิดแล้วเสียหายยังใช้โมเดลใหญ่ต่อ

คำสั่งและค่าตั้งในบทความทดสอบบนระบบตัวอย่าง ลองบนเครื่องทดสอบก่อนใช้กับระบบจริงเสมอ

อ่านต่อ

#AIขั้นสูง

CaMeL: กัน prompt injection ด้วยการออกแบบระบบ ไม่ใช่ด้วย prompt ที่ดีกว่า

งานวิจัย CaMeL จาก Google DeepMind แยก control flow ออกจากข้อมูลที่ไม่น่าเชื่อถือ ติดป้าย capability ให้ทุกค่า แล้วตรวจ policy ตอนเรียก tool ผลบน AgentDojo และข้อจำกัด

อ่าน 8 นาที
#AIกลาง

Context rot: ยิ่งใส่ข้อมูลให้ AI ยาว ยิ่งตอบพลาด แล้วควรใส่อะไรใน context

งานวิจัยของ Chroma ทดสอบ 18 โมเดล พบว่าคุณภาพคำตอบลดลงเมื่อ input ยาวขึ้น และข้อมูลที่คล้ายแต่ผิดทำให้แย่ลงอีก พร้อมกฎใช้งานจริงว่าควรใส่อะไรใน context

อ่าน 9 นาที
#AIกลาง

ทดสอบฟีเจอร์ AI แบบเขียนเทส: ชุด eval 30-100 เคส รันทุกครั้งที่แก้ prompt

ทำชุดทดสอบ LLM จาก input จริง ตรวจด้วยโค้ดหรือ LLM-as-judge รันทุกครั้งที่เปลี่ยน prompt หรือโมเดล พร้อมคำนวณว่าต้องกี่เคสถึงจะเห็นคะแนนตก 10%

อ่าน 11 นาที