ต้นทุนของ Claude Opus 4.7 API ไม่ได้จบที่คำถามว่า “เรียกหนึ่งครั้งกี่บาท” เพราะในงานจริง โดยเฉพาะไฟล์ยาวและแชตยาว สิ่งที่ทำให้บิลพุ่งมักเป็น context เดิมที่ถูกส่งกลับเข้าโมเดลซ้ำทุกตา ถ้า context นั้นถูกใช้ซ้ำได้จริง prompt caching จะกลายเป็นจุดแบ่งสำคัญระหว่างงบที่คุมได้กับงบที่บานปลาย
Anthropic ระบุว่านักพัฒนาสามารถเรียกใช้ claude-opus-4-7 ผ่าน Claude API ได้ [11] บทความนี้คำนวณจากราคา public ของ Claude API เท่านั้น ไม่รวมสัญญา enterprise, endpoint ของผู้ให้บริการคลาวด์, third-party router, ภาษี หรือความต่างของอัตราแลกเปลี่ยน
อ่านราคาต่อ MTok ให้ถูกก่อน
เอกสารราคา Claude API แสดงราคาเป็นหน่วยต่อ 1 ล้าน tokens หรือ MTok สำหรับ base input, output และ prompt caching ของ Opus 4.7 [2]
| รายการคิดเงิน | ราคา public ของ Claude Opus 4.7 |
|---|---|
| Base input tokens | $5 / 1M tokens |
| Output tokens | $25 / 1M tokens |
| 5 นาที cache write | $6.25 / 1M tokens |
| 1 ชั่วโมง cache write | $10 / 1M tokens |
| Cache hit / refresh | $0.50 / 1M tokens |
ถ้าไม่ใช้ cache สูตรพื้นฐานคือ [2]
ต้นทุน = input_tokens / 1,000,000 × 5
+ output_tokens / 1,000,000 × 25แต่ถ้าใช้ prompt caching ต้องแยก context ที่นำกลับมาใช้ซ้ำออกจากข้อความใหม่: ส่วนที่เขียนเข้า cache ครั้งแรกแบบ 5 นาทีคิด $6.25/MTok, แบบ 1 ชั่วโมงคิด $10/MTok, ส่วนที่เป็น cache hit / refresh คิด $0.50/MTok ส่วนคำถามใหม่หรือข้อความใหม่ที่ไม่ถูก cache ยังคิดเป็น input ปกติ และ output ของโมเดลยังคิดตามราคา output [2]
เอกสารยาวที่วิเคราะห์ครั้งเดียว: ใช้ input + output ได้ตรง ๆ
ถ้าอัปโหลดหรือส่งเอกสารยาวเพื่อวิเคราะห์ครั้งเดียว ไม่มีการถามต่อหลังจากนั้น งบจะค่อนข้างตรงไปตรงมา: เอกสาร system prompt และคำถามนับเป็น input tokens ส่วนคำตอบของโมเดลนับเป็น output tokens ตัวอย่างต่อไปนี้ใช้ราคา public ของ Claude API [2]
| สถานการณ์ | Input | Output | ต้นทุนโดยประมาณ |
|---|---|---|---|
| สรุปเอกสารยาวขนาดไม่ใหญ่มาก | 100k | 5k | ประมาณ $0.625 |
| วิเคราะห์เอกสารขนาดกลางถึงใหญ่ | 300k | 8k | ประมาณ $1.70 |
| วิเคราะห์เอกสารใหญ่มาก | 1M | 10k | ประมาณ $5.25 |
ตัวอย่าง 300k input + 8k output:
300,000 / 1,000,000 × 5 = 1.50
8,000 / 1,000,000 × 25 = 0.20
รวม = 1.70 ดอลลาร์สหรัฐถ้ากำลังย้ายจากโมเดลเก่ามา Opus 4.7 อย่าใช้ประมาณการ token เดิมแบบทื่อ ๆ เอกสารราคาของ Anthropic ระบุว่า Opus 4.7 ใช้ tokenizer ใหม่ และข้อความชุดเดิมอาจมีจำนวน tokens เพิ่มขึ้นได้สูงสุด 35% [2]
เช่น เดิมประเมินไว้ 300k input หากเผื่อแบบอนุรักษนิยมเป็น 405k input และมี 8k output:
405,000 / 1,000,000 × 5 = 2.025
8,000 / 1,000,000 × 25 = 0.20
รวม ≈ 2.23 ดอลลาร์สหรัฐไฟล์ยาวที่ต้องถามซ้ำ: cache คือจุดเปลี่ยน
สำหรับผลิตภัณฑ์ที่ให้ผู้ใช้ถามเอกสารเดียวกันหลายรอบ ต้นทุนที่มักถูกประเมินต่ำไม่ใช่คำตอบแต่ละรอบ แต่คือการส่งเอกสารยาวชุดเดิมกลับเข้าโมเดลซ้ำ ๆ ถ้าไฟล์นั้นจะถูกถามต่อหลายครั้ง ควรใส่ prompt caching เข้าไปในแบบจำลองงบตั้งแต่แรก [2]
สมมติว่า:
- เอกสารยาว 300k tokens
- คำถามใหม่แต่ละครั้ง 2k tokens
- คำตอบแต่ละครั้ง 2k output tokens
- ใช้ prompt cache อายุ 5 นาที
| วิธีทำ | องค์ประกอบต้นทุน | ต้นทุนโดยประมาณ |
|---|---|---|
| รอบแรก: เขียนเอกสารเข้า cache 5 นาที | 300k × $6.25/MTok + 2k × $5/MTok + 2k × $25/MTok | ประมาณ $1.935 |
| รอบถัดไป: cache hit | 300k × $0.50/MTok + 2k × $5/MTok + 2k × $25/MTok | ประมาณ $0.21 |
| ไม่ใช้ cache: ส่งเอกสารเต็มทุกครั้ง | 302k × $5/MTok + 2k × $25/MTok | ประมาณ $1.56 |
ในตัวอย่างนี้ รอบแรกที่สร้าง cache แพงกว่าการไม่ใช้ cache เล็กน้อย แต่พอเอกสารเดียวกันถูกถามเป็นรอบที่สอง ต้นทุนรวมก็ต่ำกว่าส่งไฟล์เต็มซ้ำทุกครั้งแล้ว:
ไม่ใช้ cache สองรอบ: ประมาณ 1.56 × 2 = 3.12 ดอลลาร์สหรัฐ
ใช้ cache 5 นาทีสองรอบ: ประมาณ 1.935 + 0.21 = 2.145 ดอลลาร์สหรัฐดังนั้นเวลาวางงบฟีเจอร์ถาม-ตอบเอกสารยาว คำถามหลักคือ cache hit rate: ผู้ใช้จะถามไฟล์เดิมซ้ำจริงไหม คำถามถัดไปเกิดภายในอายุ cache หรือไม่ และแต่ละรอบยังพ่วงข้อมูลใหม่ที่ไม่ถูก cache เข้าไปมากแค่ไหน [2]
แชตยาว: อย่าให้ประวัติสนทนาถูกคิดซ้ำทุกตา
แชตยาวใช้ตรรกะเดียวกับเอกสารยาว หากระบบส่งประวัติสนทนาจำนวนมากกลับเข้าโมเดลทุกครั้ง input cost จะสะสมเร็วมาก context ที่นิ่งและใช้ซ้ำได้ เช่น ประวัติหลัก กติกา หรือข้อมูลโปรเจกต์ ควรถูกประเมินว่าจะใช้ prompt caching ได้หรือไม่ [2]
สมมติว่า:
- ประวัติสนทนา 200k tokens
- ข้อความใหม่แต่ละรอบ 1k tokens
- output แต่ละรอบ 2k tokens
| วิธีทำ | ต้นทุนโดยประมาณ |
|---|---|
| ไม่ใช้ cache: ทุกตาส่งประวัติ 200k + ข้อความใหม่ 1k + output 2k | ประมาณ $1.055 / รอบ |
| เขียนประวัติ 200k เข้า cache 5 นาที: รอบแรก | ประมาณ $1.305 |
| หลังจาก cache 5 นาที hit: ต่อรอบ | ประมาณ $0.155 / รอบ |
| เขียนประวัติ 200k เข้า cache 1 ชั่วโมง: รอบแรก | ประมาณ $2.055 |
| หลังจาก cache 1 ชั่วโมง hit: ต่อรอบ | ประมาณ $0.155 / รอบ |
การเลือก cache 5 นาทีหรือ 1 ชั่วโมงไม่ควรดูแค่ราคาเขียนเข้า cache แต่ต้องดูพฤติกรรมผู้ใช้:
- ถ้าผู้ใช้มักถามต่อภายใน 5 นาที ให้เริ่มจาก cache 5 นาที
- ถ้าผู้ใช้มักหายไปเกิน 5 นาที แต่กลับมาภายใน 1 ชั่วโมง cache 1 ชั่วโมงอาจคุ้มกว่า แม้รอบแรกแพงกว่า
- ถ้ารูปแบบการใช้งานยังไม่ชัด ให้เก็บตัวอย่าง traffic จริง วัด cache hit rate แล้วค่อยปรับสถาปัตยกรรม
งาน batch: เริ่มจากราคาปกติเพื่อกันงบขาด
งาน batch มักเจอในงานวิเคราะห์ออฟไลน์ ทำ data labeling สรุปเอกสารจำนวนมาก หรือจัดหมวดหมู่ข้อมูลจำนวนมาก แต่ถ้ายังไม่ได้ยืนยันว่า account, สัญญา หรือแพลตฟอร์มที่ใช้มี batch pricing แบบใด ไม่ควรรีบใส่ส่วนลดที่ยังตรวจสอบไม่ได้ลงในงบทางการ วิธีที่ปลอดภัยคือประเมินด้วยราคา synchronous API แบบ public ก่อน แล้วค่อยปรับลงเมื่อมีราคาจริง [2]
สูตรอนุรักษนิยมยังเป็น:
ต้นทุนรวม = total input tokens / 1,000,000 × 5
+ total output tokens / 1,000,000 × 25ตัวอย่าง: งาน 10,000 รายการ แต่ละรายการมี 2k input + 500 output
total input = 10,000 × 2,000 = 20,000,000 tokens
total output = 10,000 × 500 = 5,000,000 tokens
ต้นทุน input = 20 × 5 = 100 ดอลลาร์สหรัฐ
ต้นทุน output = 5 × 25 = 125 ดอลลาร์สหรัฐ
รวม = 225 ดอลลาร์สหรัฐตัวเลข $225 นี้คือประมาณการแบบไม่ใส่ batch discount ใด ๆ หากภายหลังยืนยันราคาสำหรับ batch ได้แล้ว ก็นำราคาจริงมาแทนในสูตรเดียวกัน
อีกจุดที่ควรระวังคือเส้นทางที่ใช้เรียกโมเดล หากไม่ได้เรียก Anthropic Claude API โดยตรง แต่ผ่านแพลตฟอร์มคลาวด์หรือผู้ให้บริการ route ภายนอก บิลจริงอาจไม่ตรงกับราคาหน้า Claude API ตัวอย่างเช่น CloudPrice ซึ่งเป็นข้อมูล third-party แสดง Opus 4.7 แบบ Anthropic / global ที่ $5 input และ $25 output ต่อ MTok และยังแสดงบางรหัสของ AWS Bedrock แบบ regional ที่ $5.50 input และ $27.50 output ต่อ MTok ข้อมูลลักษณะนี้ใช้เป็นสัญญาณให้ตรวจสอบได้ แต่การจัดซื้อจริงควรยึดหน้าบัญชีของแพลตฟอร์ม สัญญา และเอกสารทางการของคุณเป็นหลัก [12]
ใส่ buffer ก่อนส่งงบจริง
ถ้ายังไม่มี distribution ของ tokens จากการใช้งานจริง การใช้ตัวเลขทฤษฎีอย่างเดียวมักมองโลกสวยเกินไป อย่างน้อยควรเผื่อ 3 เรื่องนี้:
- ความเสี่ยงจาก tokenizer: Opus 4.7 ใช้ tokenizer ใหม่ และข้อความเดิมอาจมีจำนวน tokens เพิ่มขึ้นได้สูงสุด 35% [
2]
- cache hit rate ยังไม่แน่นอน: cache ลดต้นทุนได้มากก็ต่อเมื่อ context ถูกใช้ซ้ำจริง และยังอยู่ในช่วงอายุ cache [
2]
- พฤติกรรมผู้ใช้จริง: ผู้ใช้อาจขอคำตอบยาวขึ้น กด retry ส่งไฟล์ใหญ่กว่าที่คิด หรือคุยต่อจนประวัติยาวเกินสมมติฐาน
ตัวคูณเผื่องบแบบไม่เป็นทางการที่ใช้ได้ในเชิงปฏิบัติ:
| ระยะของโครงการ | ตัวคูณงบที่แนะนำ |
|---|---|
| PoC / ทดลองใช้งาน | ค่าทฤษฎี × 1.2 ถึง 1.5 |
| ขึ้น production และ traffic ค่อนข้างนิ่ง | ค่าทฤษฎี × 1.35 ถึง 1.6 |
| ย้ายจากโมเดลเก่ามา Opus 4.7 และใช้ context ยาวมาก | ค่าทฤษฎี × 1.5 ถึง 1.8 |
ตัวคูณเหล่านี้ไม่ใช่ราคา official ของ Anthropic แต่เป็นวิธีจับงบแบบระมัดระวัง หลัง上线จริงควรนำ token logs, cache hit rate และข้อมูลใบแจ้งหนี้กลับมาอัปเดตแบบจำลองต้นทุนเสมอ
Template คิดงบแบบเร็ว
ถ้าไม่ใช้ cache คำนวณรายเดือนได้คร่าว ๆ แบบนี้:
ต้นทุนรายเดือน ≈ จำนวน request ต่อวัน × 30
× (input เฉลี่ย / 1,000,000 × 5
+ output เฉลี่ย / 1,000,000 × 25)ถ้าใช้ cache ต้องแยกเป็น 4 ก้อน:
ต้นทุนรายเดือน ≈ ต้นทุน input ปกติ
+ ต้นทุน cache write
+ ต้นทุน cache hit / refresh
+ ต้นทุน outputก่อนเริ่มทำจริง อย่างน้อยควรมีตัวแปรเหล่านี้ใน spreadsheet:
| ตัวแปร | ตัวอย่าง |
|---|---|
| input tokens เฉลี่ยต่อ request | 300,000 |
| output tokens เฉลี่ยต่อ request | 8,000 |
| request ต่อวัน | 1,000 |
| cache write tokens | 300,000 ต่อเอกสาร |
| cache hit tokens | 300,000 ต่อครั้งที่ hit |
| cache hit rate | 60% |
| buffer จาก tokenizer migration | เผื่อสูงสุด × 1.35 |
| operating buffer | เช่น × 1.35 ถึง 1.6 |
สรุป: ควรจับงบอย่างไร
ถ้าเป็นการวิเคราะห์เอกสารยาวครั้งเดียว ใช้ราคา $5/MTok สำหรับ input และ $25/MTok สำหรับ output คำนวณตรง ๆ ได้ [2]
ถ้าเป็นเอกสารเดียวที่ถูกถามซ้ำ หรือแชตยาวที่ทุกตาต้องพ่วงประวัติจำนวนมาก ให้คำนวณ prompt caching ก่อนตัดสินใจ ในตัวอย่างเอกสาร 300k tokens พร้อมคำถาม 2k และ output 2k รอบ cache hit 5 นาทีอยู่ที่ประมาณ $0.21 ขณะที่การส่งเอกสารเต็มซ้ำทุกครั้งอยู่ที่ประมาณ $1.56 [2]
สำหรับงาน batch หากยังไม่ยืนยันราคาที่ใช้ได้จริง ให้เริ่มจากราคา synchronous API แบบ public เพื่อกันงบขาด แล้วค่อยปรับตาม batch pricing, ราคาบนแพลตฟอร์มคลาวด์ หรือราคาตามสัญญา หากย้ายจากโมเดลเก่ามา Opus 4.7 ให้เผื่อ input token สูงสุด × 1.35 จาก tokenizer ใหม่ แล้วเติม operating buffer ก่อนส่งงบจริง [2]
