ลดค่า AI API ถูกลง 7 เท่า: prompt caching, เลือกโมเดล, Batch และบิลตัวอย่าง
เงินค่า LLM API หายไปตรงไหน และคันโยกเรียงตามผลตอบแทน: prompt caching, โมเดลเล็กสำหรับงานง่าย, Batch API, ตัด output, cache คำตอบ พร้อมบิลรายเดือนทีละขั้น
- ค่า 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 นาที) | อ่าน cache | output |
|---|---|---|---|---|
| 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 ก่อนจะลดอะไร ไม่วัด = เดาว่าเงินไปไหน
ข้อผิดพลาดที่เจอบ่อย
- ใส่ของที่เปลี่ยนทุกครั้งไว้ต้น 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 ชั่วโมง เหมาะกับงานกลางคืน เช่น ติดป้ายข้อมูล สรุปรายงาน ประเมินผล ไม่ใช่งานที่คนนั่งรอคำตอบ
ควรเปลี่ยนไปใช้โมเดลถูกสุดเลยไหม
ไม่ควรเปลี่ยนทั้งระบบ ให้วัดก่อนว่างานไหนโมเดลเล็กทำได้ดีพอด้วยชุดทดสอบของตัวเอง แล้วส่งเฉพาะงานนั้นไป งานที่ตอบผิดแล้วเสียหายยังใช้โมเดลใหญ่ต่อ
คำสั่งและค่าตั้งในบทความทดสอบบนระบบตัวอย่าง ลองบนเครื่องทดสอบก่อนใช้กับระบบจริงเสมอ