Claude Opus 4.7 API คิดเงินอย่างไร: คู่มือจับงบสำหรับไฟล์ยาว แชตยาว และงาน batch

ต้นทุนของ Claude Opus 4.7 API ไม่ได้จบที่คำถามว่า “เรียกหนึ่งครั้งกี่บาท” เพราะในงานจริง โดยเฉพาะไฟล์ยาวและแชตยาว สิ่งที่ทำให้บิลพุ่งมักเป็น context เดิมที่ถูกส่งกลับเข้าโมเดลซ้ำทุกตา ถ้า context นั้นถูกใช้ซ้ำได้จริง prompt caching จะกลายเป็นจุดแบ่งสำคัญระหว่างงบที่คุมได้กับงบที่บานปลาย

Anthropic ระบุว่านักพัฒนาสามารถเรียกใช้ claude-opus-4-7 ผ่าน Claude API ได้ บทความนี้คำนวณจากราคา public ของ Claude API เท่านั้น ไม่รวมสัญญา enterprise, endpoint ของผู้ให้บริการคลาวด์, third-party router, ภาษี หรือความต่างของอัตราแลกเปลี่ยน

อ่านราคาต่อ MTok ให้ถูกก่อน

เอกสารราคา Claude API แสดงราคาเป็นหน่วยต่อ 1 ล้าน tokens หรือ MTok สำหรับ base input, output และ prompt caching ของ Opus 4.7

ถ้าไม่ใช้ cache สูตรพื้นฐานคือ

ต้นทุน = 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

เอกสารยาวที่วิเคราะห์ครั้งเดียว: ใช้ input + output ได้ตรง ๆ

ถ้าอัปโหลดหรือส่งเอกสารยาวเพื่อวิเคราะห์ครั้งเดียว ไม่มีการถามต่อหลังจากนั้น งบจะค่อนข้างตรงไปตรงมา: เอกสาร system prompt และคำถามนับเป็น input tokens ส่วนคำตอบของโมเดลนับเป็น output tokens ตัวอย่างต่อไปนี้ใช้ราคา public ของ Claude API

ตัวอย่าง 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%

เช่น เดิมประเมินไว้ 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 เข้าไปในแบบจำลองงบตั้งแต่แรก

สมมติว่า:

• เอกสารยาว 300k tokens
• คำถามใหม่แต่ละครั้ง 2k tokens
• คำตอบแต่ละครั้ง 2k output tokens
• ใช้ prompt cache อายุ 5 นาที

ในตัวอย่างนี้ รอบแรกที่สร้าง cache แพงกว่าการไม่ใช้ cache เล็กน้อย แต่พอเอกสารเดียวกันถูกถามเป็นรอบที่สอง ต้นทุนรวมก็ต่ำกว่าส่งไฟล์เต็มซ้ำทุกครั้งแล้ว:

ไม่ใช้ cache สองรอบ: ประมาณ 1.56 × 2 = 3.12 ดอลลาร์สหรัฐ
ใช้ cache 5 นาทีสองรอบ: ประมาณ 1.935 + 0.21 = 2.145 ดอลลาร์สหรัฐ

ดังนั้นเวลาวางงบฟีเจอร์ถาม-ตอบเอกสารยาว คำถามหลักคือ cache hit rate: ผู้ใช้จะถามไฟล์เดิมซ้ำจริงไหม คำถามถัดไปเกิดภายในอายุ cache หรือไม่ และแต่ละรอบยังพ่วงข้อมูลใหม่ที่ไม่ถูก cache เข้าไปมากแค่ไหน

แชตยาว: อย่าให้ประวัติสนทนาถูกคิดซ้ำทุกตา

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

สมมติว่า:

• ประวัติสนทนา 200k tokens
• ข้อความใหม่แต่ละรอบ 1k tokens
• output แต่ละรอบ 2k tokens

การเลือก 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 ก่อน แล้วค่อยปรับลงเมื่อมีราคาจริง

สูตรอนุรักษนิยมยังเป็น:

ต้นทุนรวม = 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 ข้อมูลลักษณะนี้ใช้เป็นสัญญาณให้ตรวจสอบได้ แต่การจัดซื้อจริงควรยึดหน้าบัญชีของแพลตฟอร์ม สัญญา และเอกสารทางการของคุณเป็นหลัก

ใส่ buffer ก่อนส่งงบจริง

ถ้ายังไม่มี distribution ของ tokens จากการใช้งานจริง การใช้ตัวเลขทฤษฎีอย่างเดียวมักมองโลกสวยเกินไป อย่างน้อยควรเผื่อ 3 เรื่องนี้:

1. ความเสี่ยงจาก tokenizer: Opus 4.7 ใช้ tokenizer ใหม่ และข้อความเดิมอาจมีจำนวน tokens เพิ่มขึ้นได้สูงสุด 35%
2. cache hit rate ยังไม่แน่นอน: cache ลดต้นทุนได้มากก็ต่อเมื่อ context ถูกใช้ซ้ำจริง และยังอยู่ในช่วงอายุ cache
3. พฤติกรรมผู้ใช้จริง: ผู้ใช้อาจขอคำตอบยาวขึ้น กด retry ส่งไฟล์ใหญ่กว่าที่คิด หรือคุยต่อจนประวัติยาวเกินสมมติฐาน

ตัวคูณเผื่องบแบบไม่เป็นทางการที่ใช้ได้ในเชิงปฏิบัติ:

ตัวคูณเหล่านี้ไม่ใช่ราคา 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:

สรุป: ควรจับงบอย่างไร

ถ้าเป็นการวิเคราะห์เอกสารยาวครั้งเดียว ใช้ราคา $5/MTok สำหรับ input และ $25/MTok สำหรับ output คำนวณตรง ๆ ได้

ถ้าเป็นเอกสารเดียวที่ถูกถามซ้ำ หรือแชตยาวที่ทุกตาต้องพ่วงประวัติจำนวนมาก ให้คำนวณ prompt caching ก่อนตัดสินใจ ในตัวอย่างเอกสาร 300k tokens พร้อมคำถาม 2k และ output 2k รอบ cache hit 5 นาทีอยู่ที่ประมาณ $0.21 ขณะที่การส่งเอกสารเต็มซ้ำทุกครั้งอยู่ที่ประมาณ $1.56

สำหรับงาน batch หากยังไม่ยืนยันราคาที่ใช้ได้จริง ให้เริ่มจากราคา synchronous API แบบ public เพื่อกันงบขาด แล้วค่อยปรับตาม batch pricing, ราคาบนแพลตฟอร์มคลาวด์ หรือราคาตามสัญญา หากย้ายจากโมเดลเก่ามา Opus 4.7 ให้เผื่อ input token สูงสุด × 1.35 จาก tokenizer ใหม่ แล้วเติม operating buffer ก่อนส่งงบจริง